bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting a list of available locales


From: Bruno Haible
Subject: Re: Getting a list of available locales
Date: Sun, 9 Sep 2007 18:14:34 +0200
User-agent: KMail/1.5.4

Anssi Hannula wrote on 2007-08-19:
> The VDR project (GPL set-top-box style software) has an option in the 
> setup menu to change the language (as commercial devices do). ...

That's a glibc based system, I assume?

> However, having the ability to switch language during run-time is 
> problematic; setlocale() can only be called with specific locale names, 
> that vary depending on system. The correct one could be "fi", "fi_FI", 
> address@hidden" etc.
> 
> It would help if there was some call that would return all the installed 
> locales in "locale -a" style.
> Even better would be a call that returns a list of the locales that have 
> a translation for a given text domain.
> 
> Is providing such a function a possibility? Should it be implemented in 
> gettext, or glibc?

"locale -a" is indeed the starting point, then for each returned locale name
check whether a PO file is available. You cannot do it the other way around,
because it's too hard to guess the country, encoding, and variant suffixes
that the locale name may contain.

So, you can write a function doing this:
  - Execute the "locale -a" command (via posix_spawn() or similar),
    retrieving its output,
  - For each locale name, strip off the encoding and variant suffixes, and
    try if you find a $prefix/share/locale/$locale/LC_MESSAGES/domain.mo or
    - stripping off the country part from the locale name as well -
    a $prefix/share/locale/$language/LC_MESSAGES/domain.mo.

> Using LANGUAGE variable is independant from the 
> actually installed locales, so it can be used to select a language.

You cannot reliably use LANGUAGE in a locale that doesn't fit. For example,
trying zh_CN in an en_US.ISO-8859-1 locale will just not work (wrong encoding).

Also, some hidden parts of the GUI may depend on the sorting order (LC_COLLATE
locale category); setting LANGUAGE has no effect on that, so you may end up
with e.g. French strings sorted according to Spanish rules - arghhh.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]