[Bug 1797860] Re: Language selection installs too many packages

[Gunnar Hjalmarsson]

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 Ubuntu
Foundations Bugs, 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