21/11/12 15:36, intrigeri wrote:
> anonym wrote (21 Nov 2012 13:46:45 GMT) :
>> Could someone that trusts my tests or want to replicate them (it
>> took only a few minutes by running in a VM and saving/restoring
>> state to Tails Greeter) please merge this into devel?
>
> I do trust your tests, but nevertheless, I feel the need for
> peer-review (surprise, surprise). So here's a quick static one.
Great!
> The proposed change adds a dependency on the 7z command,
> which is provided in Tails 0.14 by the p7zip-full package,
> which we do not explicitly install.
> I think this package should be added to
> config/chroot_local-packageslists/tails-common.list, instead of
> relying on file-roller pulling it as a dependency (this is the
> case in Wheezy too, but IMHO, better safe than sorry and make the
> dependency resolution explicit).
Thanks, done in commit 8bce603.
> A refresh-translations run would be welcome, to update the PO files
> for this script.
Done in commit ad364f9. Also took care of conflicts against devel.
>> I think I got the detection of which Iceweasel translation that will
>> be used (depending on $LANG) right, which arguably is the most
>> complex part of this procedure.
>
>> + SHORT=$(echo ${LANG} | cut -b1-2)
>> + LONG=$(echo ${LANG} | cut -b1-5 | tr _ -)
>
> This seems to assume everything that can be in $LANG starts with the
> xx_XX form, which is, unfortunately, not true.
True.
> I wonder how this script behaves when one chooses e.g. "Filipino" as
> their language, and "Filipinas" as their region (=> fil_PH), or with
> the Furlan language (iceweasel-l10n-fur-it).
If the language pack cannot be found, for whatever reason (we look for
the wrong one, or there is none for that language) we assume that it
uses the default (en-US) and change it there. So there will be two cases:
1. We looked for the wrong language package (e.g. because of the bug you
found): the Unsafe Browser will be named Iceweasel, or whatever it's
translated into by the language pack.
2. The language has no (installed) language pack: en-US will be used,
and it will be named "Unsafe Browser".
> Given the already quite broken state of things, as long as the
> proposed change does not break things in ugly ways for users of
> non-xx_XX locales, I don't think it's a blocker, and I could find it
> acceptable to add another instance of this bug.
Then it's not a blocker, per the above. I'd like to fix this now any
way. What do you think about commit d7c9f9a?
> Are there languages for which both the short and long form exist?
> If there are, then I'd like to be sure it works fine for them.
There are no such packages in Debian AFAICT.
> If there are not, then I'd rather see the code go from the most
> specific (long form) to the least specific (short form), which would
> be less surprising to my eye and probably more robust on the long
> term.
Good point! Done in commit a4768db.
I re-merged the branch into experimental if any one wants to test.
Cheers!
