On 2018-10-17 08:14, Didier Roche wrote:
> 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 now understand that we have been talking past each other wrt to the definition of "language packs".

With language packs I usually refer to the Ubuntu specific language packs which provide translations from LP. So for English, for instance, there is one set of language packs:

language-pack-en-base
language-pack-en
language-pack-gnome-en-base
language-pack-gnome-en

Such a set includes all the dialects of a language if there are more than one.

Also, the "Installed Languages" window in Language Support checks for those very packages when determining whether a language is installed or not.

The other language related packages (spell checking, firefox translations, input methods...) I usually call "language support". Some of those are indeed split into dialects, which mostly is the result of how Debian organizes it in e.g. libreoffice-dictionaries.

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

For me there isn't. If some fr_BE translation would end up in /usr/share/locale due to some universe package, the script would include fr_BE too in the output. The output is dynamically generated.

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

They probably don't differ much. When you install French, all the French UTF-8 locales provided by glibc are installed. There is no mechanism in place to determine their usefulness.

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 really think that if we decide to always ship all variants (as the
> script requires right now),

That script isn't the center of it. Its only purpose is to provide a list of options for selecting the display language which consists of the installed translations.

So again, it's the "language packs" (se "my" definition above) which makes it sensible (IMHO) to ship all language support variants.

It may be worth mentioning that many cycles ago, the Language Support GUI had the ability to distinguish between translations, spell checking, writing aids etc., but that was dropped. I think you'd need to install Lucid to check out what that looked like. :)

> it should be one single package: easier
> maintenance, list and logic.

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? If so, I can see the advantage with being able to maintain them in one place. Possibly it should be limited to those languages which are on the ISO. On the downside I see that the current setup with regexes sometimes allows the inclusion of new dictionaries without any action.

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

Apparently I misunderstood your intention in my previous comments.

I think it should be done via meta packages, in that case. For instance, libreoffice-dictionaries is currently synced with Debian. We don't want to create an Ubuntu/Debian delta with some other way to build the binaries, do we?

> 1.5: we can debug that later on, but it seems we want to have "fr"
> anyway as we have "en", correct?

No. "en" is a special case, an exception. It actually represents the bar in the Language Support GUI which separates the languages included in the LANGUAGE environment variable from other installed languages. It should probably better be dropped from the output, but I haven't found the time/motivation to do that. So let's disregard that "en" item when talking about other languages.

In practice, and from a user perspective, selecting "en" is equivalent to selecting "en_US".

> 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".)

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

As said above, it's equivalent to en_US. But it has nothing to do with currency or date formats; that's a separate setting.

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

Great, then we are agreed on one thing so far. :)

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

Yeah, that's about the inconsistency in how the installer works compared to language-selector. I'd like to remind of bug #1294858 (comment #3) again.

Then we have the similar but even more important issue reported in bug #1732222 (comment #13).

I think it would be good if we could get those two fixed (if you think the proposed solution to the first of them makes sense) before going on with a possible reorganization of the packages.

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

I understand that now. Sorry for being slow-witted. ;)