Re: C/en

[Christian Rose <menthos menthos com>]

Malcolm Tredinnick wrote:
> > Looking at various GNOME projects (and even the gdp example project), I
> > don't understand why English manuals are installed and registered via
> > ScrollKeeper as being written in the C language. Why would you want to do
> > this instead of registering it as "en"?
> 
> Because there is no "en" locale? There is en_GB, en_AU, en_NZ, en_US and
> _many_ others.

But the locale system accepts "en" as an alias for en_GB, en_AU, en_NZ,
en_US or any other en_ locale. At least that's true for how gettext and
libc locales work. If you use en_GB on a system, the system will first
look for an "en_GB" catalog, if that fails it will look for "en", and
then finally "C".


> By default, most *nix systems come setup with the locale as C

I doubt this is true today, many modern Linux distributions default to
en_US, and I believe the same is true for many other Unix systems.


> and will also often fall back to the C locale looking for things if no
> locale-specific document is available.

That is true.


> Putting everything under en_US
> (for better or worse, we seem to have decided on US spellings and
> grammar for our documents) would then mean we have to try the locale
> that is set, then en_US and then C. This sounds like a lot of work for
> not a lot of gain.

Yes, it also would break the lookup chain, as "C" should be the fallback
for all locales that don't have their own documentation. I.e., if there
is no Swedish docs, "sv_SE" will fail first, then "sv", and then I
should get the "C" docs. At least I believe so.

I don't know if there is an advantage to providing "en_US" documentation
in addition to the "C" one. In the translation world, the advantage is
being able to use latin1 instead of only 7-bit ASCII in the translation,
so that there can be proper multiplication marks, coyright characters
and the like.


Christian