Deprecate Language Selector

Registered by Jason Warner

(from original description)
It would be good to use the upstream "region" panel code and deprecate language-selector next cycle (better to have capplets integrated in system settings than have "launchers" for standalone apps there).

The ubuntu-specific language-selector should be removed as GNOME upstream now provides a suitable alternative.

We will maybe need some design input on the ui and to finish the coding part started this cycle.


From original description:

+1. The main missing bit here is integrating the ibus module chooser.

Blueprint information

Not started
Sebastien Bacher
Iain Lane
Iain Lane
Series goal:
Accepted for raring
Not started
Milestone target:
milestone icon ubuntu-13.04-feature-freeze

Related branches



Test Plans:
All functionality of the language selection UI should be tested, such as

  - Adding (and installing) display/input languages
  - Removing (disabling) languages
  - Changing input method


2012-07-11, seb128: dropping the language-selector -> region port again for this cycle, upstream is in the middle of refactoring their input methods and keyboard handling and we can't really build on code that is being rewriten

Pre-session notes

[Aron] Please make sure im-switch is dropped as well, in favor of im-config.
[cjwatson] Please note that the installer makes use of check-language-support, which is currently part of language-selector.
[mpt] Here's a design I prepared earlier:

Session notes

 Missing features/work items:
 - add input method selection -> in the keyboard layout tab in GNOME 3.6 (
 - add defining languages order? ($LANGUAGE) -> see GNOME design spec
 - install language support packages (in Rodrigo's branch)
 - drop the fontconfig-voodoo hacks and replace them with proper by-language fontconfig snippets
1. Show a hard-coded (plus other languages in use on system by accountsservice) set of common languages (Fedora does this)
2. When a language is added via + button, show all possible languages (including the uninstalled ones) and offer to install. How does user know which ones are uninstalled?
3. Provide typeahead search when adding languages
Decoupling language support bundles for mozilla/libreoffice (e.g. installing French show too many spellcheck dictionaries - Bug #651586)
the check-language-support backend will stay, only the ui is being replaced
the language_support python module and pkg_depends data file are being used in packagekit/aptdaemon backends

Some notes about the current (2012-10-28) differences

LANGUAGE priority list
l-s, unlike g-c-c, has the ability to maintain a language priority list in the LANGUAGE environment variable. When considering the importance of this, we should bear in mind that many countries have incomplete translations, and that for non-native English speakers English isn't always the second language.
Some people consider the GUI of l-s for selecting languages to be not enough user friendly. Possibly the style of this Kubuntu GUI could serve as a model:

Lists of language options
l-s makes use of the list of language options that accountsservice (a-s) provides. It consists of the language codes of the installed translations, so e.g. 'pt_PT' and 'pt_BR' are both included if Portuguese is installed. So are @variants if corresponding locales exist. g-c-c (if I remember it correctly) displays a long list of locale names, of which many are redundant due to a lack of country specific translations.
Another aspect of the a-s provided list of language options is that it consists of language codes, and not locale names. As long as there is only one translation under a language, that translation is represented by the language part only, e.g. 'de' rather than 'de_DE'. This makes it easier for apps that make use of the list – they can convert to the English language and country names directly and use iso-codes for translation. lightdm + lightdm-gtk-greeter provides a language chooser using rather few lines of code compared to e.g. user-accounts in g-c-c.

List of options for regional formats
l-s displays the options as “language (country)”, while g-c-c displays them as “country (language)”. g-c-c has the better idea here.

Keyboard layout
l-s does not include any controls for setting the keyboard layout, while such controls are an integrated part of the region capplet in g-c-c.

Input methods
l-s lets the user decide per display language which input method system (if any) should be started automatically at login. Assuming that im-switch will be exchanged for im-config in the Raring cycle, and considering that im-config does not support per language configuration, it isn't at all obvious that anything IM should be added to g-c-c. im-config may well be handled separately.

Installation / removal of languages
l-s provides a well working feature in this area. I'm not sure how GNOME does it. At some point I was told that the GNOME os is shipped with all translations installed, but I'm not able to confirm it right now.

Storing of data and setting the environment
Ubuntu uses ~/.pam_environment for setting the locale environment. Hence a-s stores language and regional formats both as a-s properties and in ~/.pam_environment.
GNOME stores a locale name in the Language property of a-s and lets gdm set LANG. As regards regional formats, GNOME stores a locale name in gsettings and lets g-s-d set a few LC_* variables.

Options / how to proceed

Is it realistic to hope that GNOME soon will adopt all the Ubuntu choices above? Probably not.
So basically we can
1. Try to make GNOME adopt some of our choices, and patch the rest.
2. Keep l-s for the time being.
Of course, we could just drop the Ubuntu specific stuff above, and use GNOME's code all through. Personally I think that i18n should be considered too important to Ubuntu for the latter to be a serious option.

gunnarhj / 2012-10-28

UDS-R session notes:

Post UDS-R session thoughts

[gunnarhj] Since language-selector needs to be kept for use in Xubuntu and Lubuntu, and since the g-c-c region module only sets a single language, we concluded at UDS-R that the drag-and-drop interface in language-selector for maintaining LANGUAGE should be replaced. However, it's easier to just make accountsservice capable of serving both g-c-c region and language-selector.

[gunnarhj] The switch to g-c-c region has been postponed once again. The reason is that the old 3.4 codebase of g-c-c region is used in Raring, and it wouldn't be effective to write the necessary code for the Ubuntu langpack handling for 3.4.

[gunnarhj] Since it was considered important to replace im-switch with im-config, and considering the postponement, the im-switch interface in language-selector has been replaced with an im-config interface. im-config is now in use in Raring.

[gunnarhj] g-c-c region needs to be patched due to differences between Ubuntu and GNOME with respect to storing of data and how the locale environment is set.


Work Items

Work items:
[laney] Investigate the status of Rodrigo's branch ( and what else needs to be added: POSTPONED
[laney] Move fontconfig-voodoo hacks into ls-common and kill -voodoo: DONE
[laney] Move fontconfig config files into the correct packages: DONE
[laney] Investigate how best to make the LANG guards work for users: DONE
[laney] Drop language-selector from g-c-c and remove patch to upstream capplet to expose upstream functionality (in PPA: POSTPONED
[laney] Check up on upstream discussion about input method selection (upstream going with ibus): DONE
[gunnarhj] Port language-selector to im-config: DONE
[gunnarhj] Make accountsservice handle also single language setting: POSTPONED
[gunnarhj] Write g-c-c patch that makes g-c-c region talk well with accountsservice as patched for Ubuntu: DONE