Bug#448216: Support 3-letter codes for package description translations in APT (was: Re: Bug#448216: Waiting 2 years ago...)
David Kalnischkies wrote:
> 2010/2/6 Frans Pop <elendil@planet.nl>:
>> A correct implementation of l10n support automatically falls back to the
>> next best translation. The LANGUAGE environment variable can contain a
>> list of languages to fall back to.
> Never saw this colon-syntax for fallbacks before, but a quick test
> suggests that the LC_MESSAGES variable which APT uses currently to get
> the language doesn't support this syntax?
Correct. But if you set MESSAGES and then run 'locale' you will see that it
is listed besides all the LC_* variables, which shows that it is part of
the official l18n system.
> APT tries to detect which language to download by inspecting LC_MESSAGES
> extract long (de_DE) and short (de) languagecode. The current code APT
> would download "de" in this case, but "de_DE" if it is defined in the
> whitelist. My patch currently downloads (in LANG=de_DE) "en" and "de"
> unconditional and "de_DE" if it would be included in the whitelist (plus
> whatever Acquire::Languages lists as well).
OK. That's a reasonable start.
But a whitelist, besides potentially ignoring the user's preferences, is a
rather unmaintainable solution in the long run: it will always lag behind
translation efforts and translators will probably not even be aware that
they might need to request an addition to the whitelist.
> So additional needed is that APT switches to LANGUAGE and supports colon?
No, it cannot "switch". It should consider LANGUAGE *in addition to*
LC_MESSAGES. Remember LANGUAGE isn't always set.
> The only problem i can see with this is, that the acquire method is
> currently thick as a brick: It doesn't check if the file is listed in
> corresponding Index file (this index isn't even downloaded) and
That's bad. IMHO it really should download the index and parse it for
supported translations. IIUC the current system means 404s for any
language that doesn't have translated descriptions. I would guess that's
most of the languages supported in Debian Installer...
> will try to download all translations, so
>> - for Northern Sami: LANGUAGE=se_NO:nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en
> would generate 10 requests (for every component) resulting
> in 6 with a 404 response (if we assume LongDesc becomes
> real and therefore en exists).
That's why I suggested taking only the first 2 or 3 from LANGUAGE, not the
whole list. It's reasonable IMO to compromise between download needed and
using the whole list, but it's not reasonable to completely ignore
fallbacks the user has defined.
> I don't know if this has visible side effects beside being silly,
> but i believe this will be unfixable for APT without a (more or less)
> rewrite of the acquire system (as Translations seems to be
> implemented as a hack in the current version already) and
> that this will not happen for squeeze… (not even started).
Understandable. But it would be good to have a description of a proper
implementation on the ToDo list.
> So as ugly as this whitelist is i guess we need it to save the
> mirrors from a lot of silly requests ~ luckily in a stable release
> the list shouldn't vary to much… ?
I would expect not.
Cheers,
FJP
Reply to: