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

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

Re: Accessing a message catalog independently of the system locales


From: Bruno Haible
Subject: Re: Accessing a message catalog independently of the system locales
Date: Sun, 24 Oct 2010 03:04:27 +0200
User-agent: KMail/1.9.9

Hi Sylvain,

> I'm loading a message catalog in my application.  It generally works
> ok.  I'm initializing the locale using 'setlocale(LC_MESSAGES, "");'.

You also need to use setlocale(LC_CTYPE, ""); - see the doc at
<http://www.gnu.org/software/gettext/manual/html_node/Triggering.html>.

> However (under GNU/Linux):
> 
> - If that locale is not enabled in the system, gettext will fail to
>   use it.
>   (I typically use 'dpkg-reconfigure locales' to enable a locale.)

The reason for this design choice in glibc is that gettext and LC_MESSAGES
is only part of internationalization. There are also the issues with
string upcasing/downcasing, string sorting (collation), number formatting,
date/time formatting, currency formatting, interpretation of regular
expressions, and others. If a program presents to a French user french
messages but dates are formatted in US format or numbers are formatted
like 3.1415926, the program is not correctly internationalized.

So, in general, programs need a locale for internationalization support.

In _rare_ cases, it may be that programs really need no sorting, no
number formatting, etc., only LC_CTYPE and LC_MESSAGES. In these cases,
the programmers can set
  - LC_CTYPE and LC_MESSAGES to en_US.UTF-8,
  - LANGUAGE to the desired abbreviated locale identifier, as
    described in
    
<http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html>

> - More irritatingly, if the locale is enabled, but with a different
>   encoding (e.g. '.UTF-8'), then gettext will also fail to use it.

This is normal. fr_FR.UTF-8 and fr_FR.ISO-8859-15 are different locales.
They just share the same source file, but from setlocale()'s point of
view they are just different.

> Interestingly, gettext for windows does not have any of these
> limitations.

This is because mingw doesn't have POSIX compliant locales. gettext now contains
a setlocale() override that maps Unix locale names to Windows locale names.

> Is there a way to access a .mo file without asking the user to enable
> a specific encoding of a specific locale at the system level?

You can call bind_textdomain_codeset(domain,"UTF-8"); This will cause the
gettext() calls on that domain to return strings in UTF-8 encoding, regardless
of the encoding of the current locale (but it must not be the "C" locale).

See also the threads with similar topics at
  <http://lists.gnu.org/archive/html/bug-gnu-utils/2009-11/msg00046.html>
  <http://lists.gnu.org/archive/html/bug-gnu-utils/2007-09/msg00034.html>

Bruno



reply via email to

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