2010/2/6 Frans Pop <[email protected]>: > (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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
