Hi,
Ague Mill wrote (26 Sep 2012 10:43:31 GMT) :
> These directories match Iceweasel localization packages. For 'es':
> [...]
Now I understand better -- given it was not clear to me right from the
beginning, perhaps this rationale should be part of the branch
history?
Anyway, I tested this branch, and indeed it works both for locales
that get their own searchplugins directory (e.g. es-MX) and for
locales that don't have an iceweasel l10n package (e.g. es-NI):
both get Spanish Startpage as a default search engine.
This is great :)
> Do you have any idea of how to do it better?
> The only one that comes up to my mind is that we move all search
> plugins somewhere else in the chroot tree and use a local hook to
> add links in directories corresponding to given the installed
> localization package set. It feels unnecessarily complicated.
I agree it is a bit complicated, but I disagree on the "unnecessarily"
part: I think it's the only way to fix this bug in a robust way, that
is, to avoid seeing this bug re-appear, without us noticing, as soon
as the list of iceweasel localization packages changes (e.g. if fr_BE
appears, or if es_MX disappears). We don't want to test every language
setting at release time for such regressions.
>> > f9d73a5 Be consistent when giving a locale to check.torproject.org
>>
>> OK, great. (FTR, the previous setting made sense when our syslinux
>> menu allowed to pick "Portuguese", and that's all -- considering there
>> are many more Portuguese speakers in Brasil than in Portugal.)
>>
>> I have a feeling that this commit is too much or too little, and
>> causes a tiny regression for Brasilian users -- while we're at it, we
>> should add support for pt-BR in our branding extension.
> Yes, that'd be the way to go.
Added to the branch, then (commit 5ba8642).
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
