I think we need to distinguish between what's installed and what the language-options script outputs.
Installing a language means that a set of language pack packages are installed. (Let's disregard the language support packages for now.) So when installing French, the French langpacks are installed with the fr translations. It's the same langpacks whether you install from France, Canada, or somewhere else. There is only one French language option in the installer as well as in language-selector, so you don't really install fr_FR - you install French. All the French locales are generated as well: $ locale -a | grep ^fr fr_BE.utf8 fr_CA.utf8 fr_CH.utf8 fr_FR.utf8 fr_LU.utf8 The reason why the language-options script does not only list fr is that there exist fr_CA translations in the /usr/share/locale folder. So in order to make those dialect translations selectable for those users who prefer them, the language-options script outputs both fr_CA and fr_FR. (It's still fewer options compared to listing all the five locales.) Most language packs contain only one language dialect. There are a few exceptions: English Portuguese Catalan (maybe some more which I don't recall right now) For instance, if you install Portuguese (as spoken in Portugal) or Brazilian Portuguese, you get both, since they are both shipped with the language-pack-pt-base etc. packages. This way to organize the language packs isn't a natural law, of course. I don't know if there is a rationale behind it. One thing I can think of is that if you want Portuguese, it's not unlikely that you want to use Brazilian Portuguese as fallback language, and this makes a natural fallback language handy available. It's also worth mentioning that installing the langpacks for a language (ll) triggers the generation of all available ll_* UTF-8 locales. Same with the English dialects, as you already pointed out. Given this way to organize the language packs, you could argue that French (Canada) should be included in the French language packs. I'm not sure why it's not, but it may be because too few strings are translated into French (Canada) - a threshold is applied. Now over to your items in comment #2: 1. It sounds like you'd like to split the English language packs into dialect specific langpacks. Might make sense; I have no firm opinion yet. One thing which must be cleared in that case is how to deal with locale generation - installing the English language packs triggers the creation of all the en_* UTF-8 locales. Subscribed Łukasz, since he is currently responsible for the langpack handling. 1.5. I can't reproduce that fr item. In Cosmic I get: $ /usr/share/language-tools/language-options | grep ^fr fr_CA fr_FR which is the intended output (see above). 2. I think we can consider en and en_US to be equivalent in practice. I can't tell why the English langpacks (and locales) are always kept, when the user picks a non-English language in the installer. Probably it's not necessary, and it sounds like it would make sense to make that change in the installer. 3. Yes, indeed (assuming you are talking about check-language-support when used by language-selector). I mentioned my idea on how to deal with it in comment #1. But that idea would be somewhat obsoleted if we decide to split the English langpacks. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to language-selector in Ubuntu. https://bugs.launchpad.net/bugs/1797860 Title: Language selection installs too many packages Status in language-selector package in Ubuntu: New Bug description: Multiple issues arise when installing any languages in ubuntu: 1. if you select en_GB, en_US is selected instead 2. if you select fr_FR, fr_FR + en_US is selected 3. As soon as en_US is selected (which is always right now), en is then selected, which in turns requests installing all en_* languages. 4. ubiquity, if en_US is selected, only install en_US + en packages, but then, check-language-support wants to bring back all en_* variants (hunspell-en-au hunspell-en-ca hunspell-en-gb hunspell-en-za hyphen-en-ca hyphen-en-gb libreoffice-help-en-gb libreoffice-l10n-en-gb libreoffice-l10n-en-za mythes-en-au thunderbird-locale-en-gb in cosmic for instance) which were discared by ubiquity. The last point is due to /usr/share/language-tools/language-options reporting needing (in the fr_FR default installation for instance): en_US fr_FR en en_AU fr en_GB en_CA A big rework/revamp would be needed in language support, account-services and ubiquity, backed up with tests. Ideally, the seed and check-language-support will always be in sync, the list of package to install is strictly regulated by check-language-support (which is supposed to be the case below, but we see in 4. that it's not), and we limit the number of components disagreeing in which languages are installed/supported. We need to take into account ofc the debian singularirity about generated locales. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1797860/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
