When you are telling that you select French, or English, and so, all
dialects should be installed for them, why do we have that separation in
different packages though? Shouldn't we only have one "English",
"French", … package?

I don't understand the difference between:
$ locale -a | grep ^fr
fr_BE.utf8
fr_CA.utf8
fr_CH.utf8
fr_FR.utf8
fr_LU.utf8

and the script outputting only fr/fr_FR/fr_CA. There is no translation 
available in /usr/share/locale for fr_BE for instance? How this does differ 
fr_BE, from fr_FR, as it's the same currency, time format and no specific 
string (as no separate langpack) and so on? It seems that a little bit later in 
the comment, you reach to the same conclusion.
I really think that if we decide to always ship all variants (as the script 
requires right now), it should be one single package: easier maintenance, list 
and logic.

On 1.: on the contrary, if we go to install all dialects selecting a
given language, I would rather packs them all in a single (well, single
as "per type", keeping dict, libreoffice and such  separated) package.
As we require them to be installed on the system anyway, this doesn't
make any difference for the user, but ease our side.

1.5: we can debug that later on, but it seems we want to have "fr" anyway as we 
have "en", correct? 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.
So my question in that case would be: what is "en", then? People would rather 
select a specific one, like en_US to have $ as currency and a weird date 
format, rather than en_GB, which would use £ and anotter date format :)

2. -> agreed, we can work towards that. I don't understand though why we
would have "en" and "en_US", but not "fr", and "fr_FR" as told in my
previous paragraph.

3. Hum, I still don't understand the "if we decide to split the english 
langpacks", they are already splitted. The original issue which triggered that 
discussion is that on a fresh install, check-language-support complains about 
missing:
"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"

(I'm not only talking about the main langpacks, but for everything we
split in langpacks: dictionaries, libreoffice, main applications…)

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

Reply via email to