Re: Getting a list of available locales

[Anssi Hannula]

CC'ing Klaus Schmidinger, VDR maintainer.

Bruno Haible wrote:
> 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?

Yes.

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

I considered this, but I didn't really like executing external program 
for retrieving this list.

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

Actually, LANGUAGE is ignored when locale is C, so it does not really 
work exactly as we wanted it to.

However, unlike setlocale(), it allows us to use .mo files even if the 
corresponding locale is not installed, though I guess we could live 
without that.

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

I don't think we consider that a big problem, though of course it would 
be nice to fix.
However, we would need to change the charset, and we don't really know 
what charset is wanted.

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

--
Anssi Hannula