Re: [gtk-list] Re: GTK internationalization, right-to-left languages
- From: Tom Tromey <tromey cygnus com>
- To: gtk-list redhat com
- Cc: Owen Taylor <otaylor gtk org>
- Subject: Re: [gtk-list] Re: GTK internationalization, right-to-left languages
- Date: 07 May 1998 20:03:38 -0600
Nimrod> Are there any other difficulties which are specific to a
Nimrod> language? What other languages are written right to left,
Nimrod> aside of Arabic and Hebrew?
Ok, I was somewhat wrong in my previous reply. There are other
languages that are written r-to-l, but apparently they are written
using the Arabic script. The Unicode book mentions Persian and Urdu
as two such (and some more obscure languages too).
Devanagari seems to have its own set of rules for ligatures. From
skimming this section I can't tell if these are required (in Arabic
some ligatures are required) or not. The same apparently holds for
Nimrod> The user interface should be totally switchable from one
Nimrod> interface to the other with a menu choice, without breaking a
I wonder if this is really all that useful. I don't have a real
feeling for it. My guess would be that most people will set up their
preferences once and then never touch them. It's hard to see how
magically switching would be useful (aside from the high gee-whiz
It does make a difference which approach is taken. If everything must
be auto-switchable, then applications must be written in a different
For instance, suppose an application computes the name of a menu item
to be "Open <filename>". Then the application has to be aware of the
language shift in order to recompute the filename using the translated
template ("Open %s").
On a more mundate note, if hot switching is required, then you'd want
things like labels to keep track of the original text, and have them
run dgettext for you. That way for most widgets the switching could
My personal view is that hot switching isn't required. But what do I
know? I only speak English.
If people have other views on this topic, I'd really like to hear
them. It's a problem that's been bugging me for a while, and I am
still somewhat uncomfortable with my chosen position...
Nimrod> Right Center Left
Nimrod> ( ) ( ) ( )
Nimrod> It appears as if whoever translated this dialog to Hebrew,
Nimrod> forgot that 'right' stays 'right' even if it is written in
Nimrod> Hebrew... ;-)
That's pretty funny! A similar example would be a display like those
in xfig which tell you what commands your mouse buttons map to.
Automatically reversing that would be completely wrong.
Nimrod> It appears as if most of the generic user interfaces are
Nimrod> logical in nature, and can be flipped using a dumb
Nimrod> algorithm. I've not yet worked out the details, so there might
Nimrod> be some mines along the way, but it appears as if this
Nimrod> suggests a fairly quick way to allow multi-lingual user
Nimrod> interfaces in a matter of merely translating labels.
I think the basic idea is to have each layout object know whether
l-to-r or r-to-l is in use. Ordinarily this flag would switch with
the locale. However, it would also be possible to set the flag one
way or the other for those cases which warrant absolute
I think this requires the minimal number of changes to applications.
Basically it amounts to finding all locale-independent displays and
arranging to set the flag. All other windows and dialogs, which I
believe to be the largest class, could remain unchanged.
Nimrod> 5. Language files.
The message database problem is already solved in the free software
world. Take a look at GNU gettext.
It uses a different model than the one you propose. I believe the
gettext model is superior, but I won't go into the reasons why here.
Gnome is using gettext. So is every other GNU program (that I know
Nimrod> I'm just afraid that it could break gtk too much to be useful.
If it is important enough, then it should be done regardless of what
it breaks. I personally think it is very important (though,
predictably, I actually spend my time working on other things).
] [Thread Prev