Comment 1 for bug 1797860

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Hey Didier,

On 2018-10-15 11:13, Didier Roche wrote:
> 1. if you select en_GB, en_US is selected instead

Yes, if you do a British install, the installer keeps the en_US language support instead. It's bug #1732222.

> 2. if you select fr_FR, fr_FR + en_US is selected

Well, yes. English is always present. It has been that way all since I started to use Ubuntu in 2010.

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

I think this is related to the fact that the English language packs include all the English dialects. So if we don't want all the dialects installed always, one way to deal with it would be to split the English language packs into dialect specific ditto.

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

Yes, that's an obvious inconsistency. My idea for a solution is to make Ubiquity install them all. It's bug #1294858 (please see comment #3).

> 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

The idea with that script is to provide a list of options representing available translations (rather than a list with all available locales). Originally it was created as a fix of bug #693337. Personally I like that idea, possibly because I brought it up. :)

I'm surprised to see both fr_FR and fr in that list, though. Only one of them should be there.

But besides that, what's the problem you see with the script?

> A big rework/revamp would be needed in language support,
> account-services and ubiquity, backed up with tests.

I agree there are some loose ends with respect to this area. You point at some of them above; there are a couple of other Ubiquity bugs in my mind as well.

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

I'd be happy to help with achieving a better consistency. I think we need to talk about the approach, though. For instance: Would it be worth it to split the English language packs?

How do we continue?