Re: [gtk-list] Looking for internationalization info

[David Monniaux <monniaux clipper ens fr>]

On Mon, 31 May 1999 robert_gasch@peoplesoft.com wrote:

> 1) How do I tell a GTK app that I want to use a different
> language (assuming the translated language files do
> exist)?

Setting environment variable LANG to the appropriate value. For instance,
French / Canada is fr_CA. German / Germany using ISO-8859-15 is
de_DE.ISO-8859-15.

> 2) Can anybody point to towards a document which
> explains the whole internationalization thing in a bit
> greater detail?

I'd personnally like some kind of serious discussion about I18N. My
personal impression about I18N in many GNU programs is of some sloppiness.

I think this slopiness comes from:
A Some lack of interest, mainly from some US developers
  (a RedHat engineer, speaking on his own behalf, once said to me:
  "[I don't] see any problem with just ignoring all the lame french
  fucks.". This speaks for itself.

  The same developer also expressed incredulity on the fact that here,
  people just don't all speak English. No comment.

  [I personnally don't see any problem with that kind of attitude, except
  when the same people claim to make international quality products.]

B Some lack of quality control. For instance, often, French translations
  are not very good. More specifically:

  - Some words are not translated consistently.
  - Words are not translated into the generally accepted translation for
    this word. This is highly confusing for the user.
  - Bad spelling. Actually, I'm investigating the use of ispell for .po
    files.
  - Some sentences just don't make any sense.
  - There is a consistent pattern of translating English compounds like
    Window Info into something that means Information Window. This is of
    course wrong.

C Some well-meaning but misguided attempts at I18N. For instance, some
  internal error messages in Gimp have been gettextized. This is useless;
  these messages are meaningful only to the developers. The end-user who
  sees the translated messages can't make head or tail of them;
  furthermore, if he tries to report the bug, the original author won't
  recognize the translated message.

D Sentences split between different lines are split between several print
  instructions. This makes internationalizing the whole sentence
  impossible. Such a long sentence should be put as a single C string,
  maybe containing \n. Also, there are lots of constructs that depend on
  the word order in the sentence. With a C-library that understands the $
  specifier in xxprintf(), it is possible to solve this elegantly.

A can't easily be alleviated. If people in country A pretend to make
world-class free software but don't recognize the fact that it can't work
properly in country B, that's their own brain damage. Maybe some of them
will get it when we start making free software that uses algorithms that
are patented in their country and say "We don't care, just change your
institutions."

B, C  and D could be addressed with some clearly written guidelines. When
I have a little more time I'll write a paper and ask for comments on these
issues, but I'd like people to send me ideas.

The final point is D is a bit of a problem. The only way I know to reorder
arguments of a xxprintf() elegantly is the $ construct, which may or may
not be supported on all systems.

-- David