[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using gettext for runtime translations
From: |
Bruno Haible |
Subject: |
Re: Using gettext for runtime translations |
Date: |
Tue, 12 Apr 2005 16:26:20 +0200 |
User-agent: |
KMail/1.5 |
Torsten Bronger wrote:
> > If you use setlocale() without using setenv(), code that uses gettext()
> > will not work on non-glibc platforms.
>
> Ah, I see, thank you. And is there a difference between LANG and
> LANGUAGE, only as far as *portability* is concerned?
> ...
> Is LANGUAGE to prefer in favour of LANG?
LANG and LANGUAGE designate different things: LANG is the fallback locale,
used if LC_MESSAGES and LC_ALL are not specified. LANGUAGE is a colon-
separated list of languages.
Portability of LANG: The locale names are system dependent; for example
an Uzbek locale can be designated differently on a glibc system than on
a MacOS system. What is fr_FR.UTF-8 on one system, is fr_FR on another
system.
Portability of LANGUAGE: No portability problem is known, since LANGUAGE
is only considered by libintl, not by system code.
> For example, "January" is "Januar" in German, but "Jänner" in
> Austrian German. So an Austrian Texinfo author could select the
> IANA language code "de-AT" for his document.
>
> However, if Texinfo doesn't support Austrian (yet), there won't be a
> file in the "de_AT" locale directory. Does the new gettext then
> look for it in "de_DE"?
If there is no translation for a string in "de_AT", gettext (both the
existing API and the future gl_dgettext() one) will look also in "de".
It will _not_ look in "de_DE". Therefore you can install German translations
that are unacceptable for Austrian under "de_DE", and those which are
acceptable for Austrian under "de".
Note that converting from a IANA language code to a locale name
("de-AT" -> "de_AT") consists not only of changing the '-' to '_'.
You also have to take care of a few special cases, such as
"zh-Hans" -> "zh_CN", "zh-Hant" -> "zh_TW".
Bruno