Tails

#1 Updated by anonym 2014-10-09 07:00:46

This is because there are no localized TBBs for most languages for the nightly builds. See commit 74069e0. This ticket will be a good reminder for the revert of that commit.

#2 Updated by intrigeri 2014-10-09 07:31:38

> This is because there are no localized TBBs for most languages for the nightly builds.

Well, I’m not sure: as I also see this bug for a language that has a localized TBB (Arabic).

#3 Updated by anonym 2014-10-09 09:54:07

intrigeri wrote:
> > This is because there are no localized TBBs for most languages for the nightly builds.
>
> Well, I’m not sure: as I also see this bug for a language that has a localized TBB (Arabic).
Maybe I’m confused, but in config/chroot_local-includes/usr/share/amnesia/browser/searchplugins/locale/ we do not have e.g. ar, so isn’t that expected? In there we only have de, es, fr, it and pt, but none of those have langpacks at the moment, and that’s why we get no localized startpage plugins at all right now.

#4 Updated by intrigeri 2014-10-10 01:14:02

anonym wrote:
> […] that’s why we get no localized startpage plugins at all right now.

OK. I do hope you’re right :) Let’s keep this ticket open so that we notice if that’s fixed when you update the Tor Browser to one that has more langpacks, then.

#5 Updated by anonym 2014-10-10 05:36:30

intrigeri wrote:
> anonym wrote:
> > […] that’s why we get no localized startpage plugins at all right now.
>
> OK. I do hope you’re right :)

If I am wrong, this is not a regression from Tails 1.1.2; in that versions the startpage search plugin is only available for the languages (and corresponding locales) I mentioned above. From a running Tails 1.1.2:

$ find /etc/iceweasel/ -iname "*startpage*"
/etc/iceweasel/profile/searchplugins/startpage-https-en.xml
/etc/iceweasel/searchplugins/locale/de/startpage-https-de.xml
/etc/iceweasel/searchplugins/locale/es-AR/startpage-https-es.xml
/etc/iceweasel/searchplugins/locale/es-CL/startpage-https-es.xml
/etc/iceweasel/searchplugins/locale/es-ES/startpage-https-es.xml
/etc/iceweasel/searchplugins/locale/es-MX/startpage-https-es.xml
/etc/iceweasel/searchplugins/locale/fr/startpage-https-fr.xml
/etc/iceweasel/searchplugins/locale/it/startpage-https-it.xml
/etc/iceweasel/searchplugins/locale/pt-BR/startpage-https-pt.xml
/etc/iceweasel/searchplugins/locale/pt-PT/startpage-https-pt.xml

Now, there is a loss of locales, at least with the current state of things where TBB only ships a langpack for e.g. pt but not pt-BR and pt-PR. However, commit ca50caa in Tails Greeter will deal with all this correctly by falling back to the “short” (language-wide) locale if no langpack is available for the “long” (region-specific) locale. End result: once the langpacks for de, es, fr, it and pt are available, everything will be exactly the same as in Tails 1.1.2.

#6 Updated by intrigeri 2014-10-11 03:56:30

> End result: once the langpacks for de, es, fr, it and pt are available, everything will be exactly the same as in Tails 1.1.2.

Great. Let’s keep this ticket open so that this has to be explicitly checked when preparing the final release.

#7 Updated by intrigeri 2014-10-14 02:12:42

> End result: once the langpacks for de, es, fr, it and pt are available, everything will be exactly the same as in Tails 1.1.2.

Unfortunately, this didn’t work so well: it is not fixed, at least for French and German, in feature/tor-browser-4.0.

#13 Updated by anonym 2014-10-14 09:26:22

intrigeri wrote:
> > End result: once the langpacks for de, es, fr, it and pt are available, everything will be exactly the same as in Tails 1.1.2.
>
> Unfortunately, this didn’t work so well: it is not fixed, at least for French and German, in feature/tor-browser-4.0.

While the links are created as I promised, the Tor Browser indeed doesn’t look in the directories the symlinks are located in. I can see with strace that e.g. $TBB_INSTALL/distribution/searchplugins/locale/de is being accessed, but nothing is loaded from there, only from $TBB_INSTALL/browser/searchplugins.

#14 Updated by anonym 2014-10-14 10:08:15

I pushed bugfix/8036-workaround-for-localized-searchplugins which works around this issue, if worse comes to worse and we don’t find a real solution.

#15 Updated by intrigeri 2014-10-15 06:37:56

Code looks as good as this workaround allows.

#23 Updated by anonym 2014-11-06 21:42:25

Just reporting back that I haven’t yet found a proper solution. I’m sort of dreading having to fire up the Tor Browser in a debugger… my experiences of doing that with anything Mozilla-produced have been very painful.

#24 Updated by intrigeri 2014-11-07 08:51:50

> Just reporting back that I haven’t yet found a proper solution. I’m sort of dreading having to fire up the Tor Browser in a debugger… my experiences of doing that with anything Mozilla-produced have been very painful.

I suggest asking Sylvestre Ledru for help on that one — you can tell him I’m behind the request. Ideally, pointing him at an URL to our ISO to reproduce the problem, and pointers at the relevant profile and scripts inside the SquashFS so that he can look at it from the inside, without having to figure out how all this is created from source.

#25 Updated by intrigeri 2014-11-23 18:49:04

Was this resolved at the same time as Bug #8139?

#30 Updated by BitingBird 2015-01-14 23:51:03

in 1.2.3 localized startpage in fr, it, de, pt, es work. Localized wikipedia work too. Not sure if that’s the dirty or the real fix, just wanted to give an up-to-date status report :)

#35 Updated by intrigeri 2015-04-01 15:10:36

> Still, we want to get rid of the
> workaround, which this bug has turned into being about, but I’m opening a new one for
> that instead: Bug #9146. It think a fresh ticket will make things clearer, especially
> since I’m gonna involve the Tor Browser devs, and perhaps Sylvestre, like
> intrigeri suggested.

Excellent idea!