Re: supporting obscure languages

[Bruno Haible]

Hi Albert,

You did not state what you are trying to do. I understand it like this:
"How do I add support for a specific, rarely used language to my system
 in such a way that I can localize programs for this language?"

The answer is:

1) You need to define a locale identifier for it. This is important,
   because the users and all translators must agree on it - if a
   translator uses a different identifier than the user, her
   translations will not be found. The standardized identifiers
   are those in ISO 639-1 and ISO 639-2, and also found in glibc's
   glibc/locale/iso-639.def.

   If your language is a distinct one, you should find the language
   identifier in this list. If your language is a dialect of another
   language, you can use a variant tag. For example, if by "zam" you
   mean the language "Zapotec, Miahuatlán", it is a dialect of
   Zapotec, which has the identifier "zap". So you will likely
   choose the language identifier "address@hidden" (all ASCII please).

2) You may need to define a glibc locale. This is necessary for a
   distinct language and optional for a variant (need it only if you
   want to override some localizations). You need it because things
   like month name, time display rules and the like are not defined
   by .po files but through a locale definition. To create a locale, use the
   "localedef" command together with a locale definition file. There
   are dozens of examples of these locale definition files in a
   directory mentioned in the output of "localedef --help".

3) Then you can create .mo files from .po files for that language,
   as described in the GNU gettext documentation.

Albert Cahalan wrote:
> Given a fairly normal program, how can the user force the use of a
> specific known messages file? Consider /tmp/testfile.mo in a locale
> that isn't otherwise defined in any way.

You can set the environment variable LOCALEDIR to, say, /tmp/locale,
and then store the file as /tmp/locale/$localeID/LC_MESSAGES/testfile.mo.

> Now suppose that the file is stored in the expected place. The user
> wants to use /usr/share/locale/zam/LC_MESSAGES/someprog.mo with a
> program that claims to be someprog. Again, the locale isn't supported
> in any other way; there is merely a *.mo file installed.

This is only supported in the dialect case. If you choose the
language identifier "address@hidden" and the user's locale identifier
is address@hidden, you need only a zap_MX.UTF-8 locale; a
address@hidden locale does not need to exist.

> How can a program offer a non-environment way to override the source
> of messages? The obvious setlocale(LC_ALL,"zam") does not work, nor
> does the troublesome (because other locales need more) substitution
> of setlocale(LC_MESSAGES,"zam").

There is setlocale, and there is bindtextdomain. But you should have a
locale first.

> BTW, please consider it a bug that that doesn't just work.

No, not a bug. This is the way locales are designed.

Bruno