Re: about gettext



Lauris Kaplinski <lauris helixcode com> said:
>My main point was still about the meaning of "C" locale (!= "en_US")
>Theoretically you do not have to use human language at all for "C" - just
>mark all text as "x01", "x02" etc.
>Of course you have probably to do all translation yourself then... ;)

True in theory - I agree with the principle - but I recommend just using
English in the program strings as is standard practice.

Many real systems don't set the locales at all when English is intended,
so these programs will appear to be "busted" on them (and the users will say
"but everything else works...").  Yes, US people should really set their
locale to en_US (not expecting that every program is written in English), but
using English strings supports backwards compatibility.  In fact, the whole
"locale" system was designed to permit this situation, so many systems
still depend on it -- and there's little need to bust it now.

Other problems with using anything other than English text in the code are:
* When programs go south, sometimes environment variables get erased;
  using text like "x01" makes debugging a real nightmare.
* Translating "x01" is rough on the human translators.  X/Open's approach
  is similar, and programmers didn't like it. gettext() is
  MUCH easier to use BECAUSE the index is natural language text.
* You stated that the "C" locale supports only 7bit ASCII, so
  you cannot code most languages other than english in it.  I'm not sure
  if that's really enforced by anything, but if that causes a problem on any
  system, that's a _real_ problem for using other languages.  And I'm not
  sure I could "guarantee" that it wouldn't cause problems somewhere.
* It violates the GNU style guides.  Okay, by itself that's not a disaster,
  but it means that the program is "different" in an unnecessary way,
  which adds difficulties in supporting it. For example, see the next bullet.
* As Ian Peters noted: If you [don't] write your program in English
  you cut yourself off from the established translation team.
  There are already people set up to do English->[native language],
  but no such a team for another language.

There's nothing wrong with writing the code initially in another language,
and when it's to be internationalized, switching.
But if it stays in another language, it's going to be harder for the
established teams to translate it.


"The difference between theory and practice is smaller in theory
than in practice."


-- 

--- David A. Wheeler
    dwheeler ida org





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