Installer does not install all language support packages

It was moved to main yesterday. Can you please try again? During the installer we indeed only have apt sources from main available.

Great about main; thanks for letting me know. :)

Would like to add that I had bug #1134364 in mind when I filed this bug. language-selector checks for all installed languages nowadays, and I suspect that the installer does not (but I think it would desirable that it did).

Anyway, I'll provide some more details after my next Swedish install.

I did a new Swedish install, and this time mythes-sv was pulled by the installer as expected. :) So mythes-sv has no longer anything to do with this bug report.

However, if I do an English install, and instantly run check-language-support (without options), I get this list:

hunspell-en-ca
libreoffice-help-en-gb
libreoffice-l10n-en-gb
libreoffice-l10n-en-za
mythes-en-au
thunderbird-locale-en-gb

It's the packages I'm prompted to install if I open language-selector.

So, why is this not an ideal behavior?

First: Some users, who just did a fresh install while connected to the net and asked for updates to be taken into consideration, find it confusing to be told that language support is not completely installed. That prompt in itself indicates an error.

Also, consider these steps:
- Do a fresh install with en_US.
- Create a new standard user via User Accounts and set the language en_GB.

When logging in as that new user, the language support won't be complete. Not even opening language-selector from that user helps, since standard users are not prompted to install missing language support.

This reasonably applies to language packs with multiple translations - English, Spain, Portuguese, Catalan... OTOH, since English is always there, it affects all users.

I attached a patch which I think would fix this bug. It may be a little hackish, but the point is that I would like the installer to pull language support packages by calling check-language-support without options (or with the -a option).

I had noticed that before that incomplete english packs are installed. But i also dislike that language selector considers that I must have "en-za" libreoffice language packs to have a complete "en-gb" locale installation. But i guess those are not that big anyway. I'll need to read more context on the patch before applying and testing it.

On 2014-03-31 13:27, Dimitri John Ledkov wrote:
> But i also dislike that language selector considers that I must have
> "en-za" libreoffice language packs to have a complete "en-gb" locale
> installation.

Better then that you don't see it be installed. ;-)

We changed language-selector in this respect a while ago to prevent situations where a user selects a language without even knowing that available language support is missing. That change should have been accomplished by a change in the installer back then. Now I'm hoping that we can fix this inconsistency for 14.04 instead.

In 14.04 fresh install in which location is denoted as Canada, the Canadian english spelling package is not installed:
hunspell-en-ca

As a result, users by default do not get any spell checking in Libreoffice or etc. Worse, when they play with the settings in, say, Libreoffice, it looks like they have various choices (Australian English with spellchecking, US English with spellchecking, etc), but although Canadian English is an option, it does not come with spell-checking.

If I've got this all correct, then hunspell-en-ca simply needs to be installed whenver the default location is Canada.

@Christopher: Actually, what I suggest above is that it should be installed whenever English (any English) is installed, i.e. always. (Taking the location into consideration would complicate things.)

@Gunnarhj: yes, please! I meant what the smart person said!
Thanks Gunnar (here and on askubuntu...)

I'm having the same issue but with Firefox, it's too quick to screenshot but when I ran the upgrade to 14.10 two days ago, I saw it flash a message about removing the langpacks for Firefox for my locale - which after restart had reverted to English. I had to go to Language Support afterwards to get them back.

Me too - my language was just gone. Another odd thing I noticed that might be related, when I first installed Ubuntu, I had to pick English, because my languages doesn't have the coverage yet - which is fine. The problem is, why do I have to install all Englishes under the sun?

I think we should follow the fallback locale scheme defined in the CLDR/ICU here. http://userguide.icu-project.org/locale#TOC-Fallback

Which means that "en" and only "en" is the one locale that always gets installed (and not "en_CA" , "en_GB" etc in addition to that), and then everything in your chosen locale's fallback chain. For example, for the "fr_FR.utf8@EURO" locale, the installed locales in order of preference would be:

fr_FR@EURO
fr_FR
fr
en

The locale selection behaviour should be identical for all installers/updaters/language option changes, because of orthogonality. The chain for an individual package would ideally be:

Preliminary: The user is not allowed to select plain "en" as a locale, but it has to be "en_CA", "en_US", or "en_GB" etc)

1. Try to get the locale selected by user for the particular package, e.g. Firefox (unless it's plain "en", so the user will be able to get new language packages as they become available).

2. Try to get the system locale or any of its fallback locales (e.g. for Breton, try French before you try English).

3. All else failing, get "en".

Akerbeltz, GunChleoc:

Please note that this bug report is not about language packs which are unsolicitedly uninstalled. Neither is it a proper place to discuss Ubuntu's overall l10n design.

This bug is best explained in comment #3. It's about a small improvement within the scope of the current design, including the fact that some of Ubuntu's language packs contain multiple translations.

Even if I referred to this bug report in a mailing list discussion, it was not my intention to move a broad l10n discussion here.

Sorry, I mistook your comment on the mailing list, and the general problem was also discussed here before. Do you know which package we should file a new bug report against?

On 2014-11-24 17:02, GunChleoc wrote:
> Do you know which package we should file a new bug report against?

It depends on the issue, and if it's easily attributable to a specific package.

But let's keep talking on the list. I'll reply there later tonight.

I got this when I check the language:

tom@MW-GAMP103240:~$ check-language-support
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
 LANGUAGE = "en_US:en",
 LC_ALL = (unset),
 LC_PAPER = "sv_SE.UTF-8",
 LC_ADDRESS = "sv_SE.UTF-8",
 LC_MONETARY = "sv_SE.UTF-8",
 LC_NUMERIC = "sv_SE.UTF-8",
 LC_TELEPHONE = "sv_SE.UTF-8",
 LC_IDENTIFICATION = "sv_SE.UTF-8",
 LC_MEASUREMENT = "sv_SE.UTF-8",
 LC_TIME = "sv_SE.UTF-8",
 LC_NAME = "sv_SE.UTF-8",
 LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
gimp-help-en thunderbird-locale-en thunderbird-locale-en-gb thunderbird-locale-en-us wbritish
tom@MW-GAMP103240:~$

@Tom: It probably means that the Swedish locale is not available (for some reason), even if it's selected in the Regional Formats tab of Language Support. You can fix it with this command:

sudo locale-gen sv_SE.UTF-8

We had what looks like exactly the same headache with GIMP on Mac a month ago. In case it helps, here's the writeup of the problem and solution:

>
Fault finding eventually got us to running
$ locale
which on my machine resulted in LANG and LC_ALL being blank whereas Partha's machine offered

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

After running

$ export LC_ALL="de_DE.UTF-8
$ cd /ApplicationS/Gimp-2.8.app/Contents/MacOS
$ ./gimp-bin

It came up in German and following
$ export LC_ALL="gd.UTF-8

it came up in Gaelic. Partha diagnosed that "The previous default you had was "C" which mean gtk will always provide you an English interface." Partha's current build has some fix that means that the dropdown now shows all languages and implements them correctly.

And Partha added:
>
I use a script to launch Gimp and make all the libraries available. The script is inspired by Simone's 2.6.x script and modified for my
builds.

So, I set the language in the script and you all set. The script obviously creates a local environment and so it does not interfere
with the User Interface language.

Without the language setting, GTK will set the locale to "C" and Gimp will not be able to change it. With a language setting, GTK is happy and Gimp is happy.