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

[Didier Roche]

I think we should answer some questions first in term of fundamentals.

1.
For instance, if I install fr_FR, I don't expect to have fr_CA installed (and it's not the case here), nor fr.
Why would that be different for English? I thinks en_US should only install en_US + the common (shared) packages. However, that doesn't count as "en" being installed, and doesn't pull en_GB for instance.

^ this is the first inconsistency we should fix IMHO.

1.5 -> fr shouldn't be installed, that's just a bug from what you told
in the perl script.

2.
I don't understand why we install en_US when selecting !en. If a translation is missing, it will fallback to C, which is the program string, which is most of the time in english. Or, if we really want a fallback, shouldn't that be "en" (always installed then), which doesn't pull any en_*?

3.
Keep in sync the list with the seeds + installer.

I don't know if there will be or not a new desktop installer yet (that
will be soon decide), but it's something to take into account. At least,
we can try solving those first two and get a good use/case direction,
what do you think? (there is certainly some points I'm missing by not
being an expert though, I'm aware of this and happily will listen to
your knowledge there ;))

-- 
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