Installer does not install all language support packages

Bug #1294858 reported by Gunnar Hjalmarsson on 2014-03-19
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Dimitri John Ledkov

Bug Description

My very first own package, mythes-sv, has just been sponsored into Debian and Ubuntu. :)

It's a Swedish thesaurus for LibreOffice, and if I install Swedish via language-selector, it's pulled as expected through /usr/share/language-selector/data/pkg_depends.

However, when I did a fresh install with Swedish as the selected language, and connected to Internet, mythes-sv was not installed at first login. My first theory was that it might be due to the fact that it's in universe, but when I opened language-selector, there were several other language support packages missing, most of them in main.

I would think that the desired behavior is that as long as you are connected to the net while installing, the installer should pull all the applicable language support packages, not only some of them. So the only situation when language-selector should need to prompt you about not installed language support packages when you open it should be if one or more packages were added to the archive.

Martin Pitt (pitti) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Incomplete
Gunnar Hjalmarsson (gunnarhj) wrote :

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.

Gunnar Hjalmarsson (gunnarhj) wrote :

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:


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

tags: added: patch
Changed in ubiquity (Ubuntu):
status: Incomplete → New
Dimitri John Ledkov (xnox) wrote :

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.

Changed in ubiquity (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
status: New → Confirmed
Gunnar Hjalmarsson (gunnarhj) wrote :

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:

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.

Gunnar Hjalmarsson (gunnarhj) wrote :

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

Akerbeltz (fios) wrote :

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.

GunChleoc (gunchleoc) wrote :

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.

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:


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

Gunnar Hjalmarsson (gunnarhj) wrote :

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.

GunChleoc (gunchleoc) wrote :

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?

Gunnar Hjalmarsson (gunnarhj) wrote :

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.

Tom K. C. Chiu (tomchiukc) wrote :

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

Gunnar Hjalmarsson (gunnarhj) wrote :

@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

Akerbeltz (fios) wrote :

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


After running

$ export LC_ALL="de_DE.UTF-8
$ cd /ApplicationS/
$ ./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

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.

Mathew Hodson (mhodson) on 2016-03-27
Changed in ubiquity (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers