Definite's Extractor

My findings on Life, Linux, Open Source, and so on.

Tag Archives: langpack

langpack management (yum langpack plugin).

After I discussed with Jens, he said that we should start with langpack first. He is right, let’s solve this piece by piece.

The problem we are trying to address

Currently, langpacks are either:

  1. binded with main package, like firefox, thunderbird, and other small-to-medium packages with translation files. So you install main package implies you need all the langpacks.
  2. split into numerous langpack sub-packages. Such as KDE, OpenOffice and Eclipse. So you install main package implies you only need the English US version. Langpack are to be installed individually.

1) is not good for resource-limit systems, because you have to install all the language packs, even you won’t be using them in the rest of your life. 2) is another extreme, you need to remember to manually install the langpack, or they won’t work as expected. To sum up, current language policy is either all or none.

We offer an additional choice: langpacks are automatically installed only if you need it.

How do we know which languages to be installed

These languages can be specified in /etc/sysconfig/lang-setting/langpack.

Whenever yum is invoked to install a package, if the package has langpacks, the langpack plugin will check against this file and pull out the required langpacks.
Don’t worry about langpack removal, as langpacks depend on the main package and will be removed as well. Simple, no?

How do we get user’s languages preference?

Notting and others mentioned the user preference should be exclusive stored in they home. Yes, I agree that we also need the per-user setting in their home, so they specify what language they want to see by themselves.

But system wide setting file is also essential, unless you want to scan through thousands of users’ preference files to determine what to install.

Another benefit of system wide/user home combination is that the langpack plugin can quickly detected what need to be installed by doing a set difference calculation, i.e. UserPref – SysPref.

Contingency plan

You can turn of the automatic langpack installation by removing the langpack plugin, and start manually installing langpacks.

Up coming I18n package management

Yesterday, Jens and I was discussing about the yum langpack plugin, and a recent bugzilla bug ([Bug 518395] add @input-methods to Package Selection screen). During the discussion, we find out that there are at least following issues to be considered:

  1. Aspect of Language Support:
    1. Language pack
    2. Input Method/Keyboard layouts
    3. Fonts
    4. Spell Checking
    5. ….
  2. Type of package i18n support
    1. Translation files, such as .mo
    2. Language packs. This may involve naming pattern detection.
    3. None

At first stage, we postpone the technical details of handling internationalized packages, but concentrate on obtaining and storing the users’ i18n preference.

For example, Caius wants a set of fonts that covers all language, as far as possible, an he understands English, Chinese, and Japanese, thus he needs corresponding input methods and spell checking. He prefers to see menus and items in Japanese, so Japanese langpacks are required. He also need an English spell checker


His preference can be stored as:









Jens’ langpack plugins gets benefit from this approach. The plugin determines whether to add or remove langpacks according to langpacks.

And for anaconda and system-config-language, this approach provide further knobs to tune. For example, IBus will be pulled in as dependency if there is at least one Asian languages in input_methods. Spell checkers and even voice data can be dealt with the similar way.

Fonts are a bit different. By default, we installed a set of fonts that cover languages as much as possible. But on resource-limited systems, system admin can exclude fonts by adding a “-” in front of the languages to be excluded. Or alternatively, just list the language you want. Say, the OLPC to Uganda can be loaded with:


User Interface in setting dialog.

Regarding UI, I suggest something like:

Overview Language Pack Input Method Font
Language Name
English (US)
Chinese (HK)
Japanese (JP)
Language Group↓ Language↓
Language pack Input method
Fonts Spell check
Add Delete Ok Cancel

Please forgive my terrible html table drawing skill. Mmm, may be I should use glade to produce a real dialog. 🙂

On top of the “dialog(?)” are pages of GNotebook. Click on other pages for more advance settings. This page is for overall setting.

In overall setting page, we have an active list for showing current active languages, the degree of support can be either listed here or in individual advance setting.

In the middle of setting page, there is a language group pull-down which lists the geographic division of languages, such as Eastern Asia, Middle East,… etc.

The contents language pull-down is narrow down by the language group. Thus a user do not need to scroll through hundreds of languages.

Below the pull-downs are aspects of support checkboxes. They are self-explaining.

On the bottom there are buttons that add/delete the language from/to the active list.
and Ok/Cancel to confirm the modification.