Re: Bug#448216: Support 3-letter codes for package description translations in APT (was: Re: Bug#448216: Waiting 2 years ago...)
2010/2/6 Frans Pop <elendil@planet.nl>:
> (CCing as I'm not sure if you are subscribed to d-i18n)
(i am not, so thanks for cc'ing me :) )
> 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?
> And I think that it would probably also be good if APT downloaded at least
> the first two or three languages listed in LANGUAGES (again both 'xx_YY'
> and 'xx' files for each). This would ensure that e.g. for Portuguese,
> Brazilian is available as fallback.
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).
So additional needed is that APT switches to LANGUAGE and supports colon?
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
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).
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).
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… ?
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
Reply to: