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

[Didier Roche]

Yeah, sorry that we had different terms for the same things :) Ok, I
understand now as well. I'm trying to look at this whole thing globally
and not from the technical split (which is a little bit artificial) that
we did.

> Please note that the language-options script serves the purpose of
providing a list of languages only, i.e. it let's the user select the
display language. That should be distinguished from selecting the locale
for regional formats. For the latter purpose the user is offered an
option list consisting of all the generated UTF-8 locales.

I'm unsure to understand this split; but that's probably due to my inexperience. Let's take from the user's point of view:
- they have a list of language, let's say (randomly :p) that I select French here
- then I have a list of countries, I select "France", then I have Euro and a particular date format configured.

The second part is pre-configured based on the country I selected, but
this is basically fr_FR default, correct?

If I select Portuguese (Brasil), I would have Portuguse (+Brazil dialect
installed) and BRL currency + their date format.

Then, of course, I can mix and match in some other UI to change the
currency and have Portuguese (Brazil + USD + european date format) if I
want.

If I understand you correctly, we need to have locales generated on disk
to know about the avaiable variants, like _foo?

I'm trying to see how we can rationalize in the hypothese of a new installer, and ensuring that both GNOME Control Center (which isn't in a very good state regarding displaying locales) can be enhanced, not really focus on "there is that script or that script". Does it makes sense?
One of the issue in Control Center is that it expects to have all locales generated to display them IIRC for currency, language and date options, that's correct, isn't it?

> Are you talking about creating meta packages to pull the language support instead of what's currently in the seed and in language-selector's pkg_depends?
I don't really know, it's an opened question. I wonder how we can minimize and have the best layout for what we want to achieve.
(Not quoting all your sentence, but ack on not diverging from Debian for the dictionaries for isntance).

>> Or we want people to specifically
>> select, like fr_BE (to have the specifics for this locale), but still
>> install all langpaks without having "fr" listed.
> That's how it currently works. I think it makes sense. (Well, for languages without alternative dialects present, like German or Swedish, the list only shows "de" respective "sv".)

Ok, so we always include "base language", and even if for some packages (like libreoffice-dictionnaries, thunderbird), we have splitted by regional settings (due to debian), we install them all, considering the impact in installed size is minimal.
We would thus change "en" to apply the same semantic, and be included as soon as en en_* something option is selected, and thus, install all en_*. (which is what check-langage-support wants to do already, but no ubiquity…). That would prevents bugs like #1732222 to exists. For the "sync with ubiquity", the all_langpacks sounds like a good solution, do you mind doing a MP for bionic (as this is really what we want to fix with a new image respin)?

I guess your idea of a metapackage isn't bad, and would simplify the
logic in scripts and ubiquity (or rather new ubiquity). We would have
though language-foo and language-minimal-foo. Is there any corner cases
that we are obviously missing here? It almost seems too simple :p

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