Re: Accessing a message catalog independently of the system locales

[Sylvain Beucler]

Hi Bruno,

On Sun, Oct 24, 2010 at 03:04:27AM +0200, Bruno Haible wrote:
> 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>.

OK, I did my tests with and without.

(Btw I'm concerned that a part of the code (the script parser) may be
influenced by locale-specific behavior.)


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

I understand the concern that locales need to be installed at the
system level to get complete i18n.

However this sounds "all or nothing".

I think it would be nice to still translate the message strings when
the requested locale is not installed.

My concern is about simple language selection by the user.

In this particular case, users will want to try a game's translation
(shipped as a .mo file), but to do that, they will have to configure
the matching locale, which:
- they don't know the mere existence of
- is long (locales generation)
- is complex (no simple GUI for my proverbial grand'ma)

The use cases for selecting a locale that is not the user's primary
language are:
- show off the translation system and make users realize that there's
  one, even if their language is not supported yet
- exercise one's foreign language skills
- test what languages such as Macedonian or Vietnamese look like
  (and improve one's culture)
- ease testing for translators
- not believing too easily that the translation system is just broken


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

Well, I guess FreeDink is in that _rare_ case (only text strings and
only integer numbers) - but, this technique requires that the
en_US.UTF-8 is installed, which typically is not the case for
non-english GNU/Linux installs!

I also think this could work even in non-rare cases.

I wouldn't mind if that only worked for the game domain (I have 2
domains: the static game engine domain, and the dynamic game data
domain).


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

Does it means that Windows essentially have all locales for all
languages pre-installed (or created on request)?

Is there a similar system under GNU/Linux?

(Btw, Debian has a 'locales-all' package now, with all locales
pre-generated, but that's fairly recent, not installed by default, and
I don't know about other distros / Unices, so I'm not sure that's a
good-enough work-around.)


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

Actually, I already use 'bind_textdomain_codeset(domain,"UTF-8")'
because the program is graphical and requires UTF-8 strings - through
SDL_TTF's TTF_RenderUTF8_Solid :)  But that's a separate question.

My question is about an easy way for the user to select a translation.


Thanks!

-- 
Sylvain