Re: GTK internationalization, right-to-left languages

[Nimrod Zimerman <zimerman earthling net>]

On Thu, May 07, 1998 at 06:34:45PM -0400, Owen Taylor wrote:

> As far as I know, no work has been done on right-to-left
> internationalization of GTK+. But if someone wanted to work on it, I
> think it would be great, and I'd provide whatever help I could.

I might be interested in doing that in the future, once I establish that it
can be done without breaking gtk too much and without using up all of my
non-existent free time.

Forgive me for removing the rest of your reply. I think I mention most of the
points below.

I've been doing some thinking of my own regarding the issue of multi-lingual
applications involving both LTR and RTL. It includes a bit more than output
routines and fonts, but generally shouldn't be too complicated. I'll try to
list some of the points. Note that the following is purely my own - I've not
read any documentation regarding these issues, though I assume some exist,
hence I do not know if there are better ways to make these things work.

1. Fonts rendering.

This should be, indeed, rather straight forward. 
I feel that adding support to X itself is a complicated task not quite
worth the time, especially now, when The Open Group is no longer open.
Making gtk draw the fonts on its own looks like a better idea, though I do
not quite understand the consequences as far as X is involved - does it
matter? A possible way to integrate RTL might be using special font names
that would be captured by gdk and handled in this higher level.

Arabic's ligatures which are context dependent shouldn't pose too much of
a problem. As far as I remember, they are rather straight forward. A letter
can have different form if it appears as the first letter of a word, as a
letter in the middle of a word, or as the last letter of a word. I believe
that, with a few exceptions, should be enough.
Considering I was able to 'master' this myself when I learned Arabic quite
a few years ago, it should be obvious it couldn't be too complicated (as of
this moment, I hardly remember how to draw the letters, not to talk about
whole words...).

Are there any other difficulties which are specific to a language? What
other languages are written right to left, aside of Arabic and Hebrew?

2. RTL cursor movement.

Even if we only require RTL writing, there has to be a way to insert
numerics as usual, LTR. Hence there is no good reason to prevent arbitrary
switching from RTL to LTR and vice versa (not to mention that entering
proper LTR English text is common requirement regardless of the main
language).

3. Multi-linguality.

I feel that an application shouldn't be RTL *or* LTR. Rather, an application
should have a main language, probably English, as well as secondary
languages. The user interface should be totally switchable from one
interface to the other with a menu choice, without breaking a thing.
The main language shouldn't dictate how text is to be entered (direction and
language). It should only choose defaults and control general alignments
of text messages.

Generally speaking, if you take an English user interface, the following,
for example:

    File   Edit                                     Help
   ------------------------------------------------------

          ******************************
          *                            *
          *                ******      *
          *                * AA *      *
          *                ******      *
          *                            *
          ******************************


You can 'transform' it into an Hebrew, or Arabic user interface by flipping
the image:

    Help                                     Edit   File
   ------------------------------------------------------

                    ******************************
                    *                            *
                    *      ******                *
                    *      * AA *                *
                    *      ******                *
                    *                            *
                    ******************************
   

And, obviously, by changing the labels to the appropriate language, oriented
to the right.

This is true, as far as I can tell, for any 'logical' user interface (logical
user interface - a user interface that doesn't depend on certain layout of
its components).
This doesn't work right for user interfaces which are 'physical', such as an
amusing bit found in Hebrew MS-Word 6.0 for Windows, in an alignment dialog:

                         Right   Center   Left
                          ( )     ( )     ( )

It appears as if whoever translated this dialog to Hebrew, forgot that
'right' stays 'right' even if it is written in Hebrew... ;-)
                          
It appears as if most of the generic user interfaces are logical in nature,
and can be flipped using a dumb algorithm. I've not yet worked out the
details, so there might be some mines along the way, but it appears as if
this suggests a fairly quick way to allow multi-lingual user interfaces in a
matter of merely translating labels.

As I see it, every component should have a field identifying its behavior.
If it is 'automatic', it should be automatically flipped if the user
interface is flipped. It is is 'constant', it shouldn't. There should be
some parent-child relationship here, because things can get complicated.
Comments on this would be appreciated, because I consider this the most
important part of multi-linguality.

4. Multi-lingual strings.

If multi-linguality is to be considered, all viewable strings should be able
to represent arbitrary text, including direction changes and special
characters. Unicode looks like a good candidate, but I do not know too much
about it.
How much of gtk would this break?

5. Language files.

It appears that encoding various languages into the source code isn't a
terribly good idea, mainly because it is quite complicated technically.
A useful solution might be to use some sort of language files, generated
using a utility that is capable of entering text in all supported languages.
These language files should have keys and values, where a key is composed of
an id and a language. For example, the key (fileMenu, English) would
correspond to the value "File", whereas the key (fileMenu, Hebrew) would
correspond to the value "Af841h45", which just might represent "File" in
Hebrew in the internal multi-lingual string format.

The file might actually be saved in a C source, and compiled along with the
application.
This allows for quick translations of applications to other languages simply
by creating appropriate keys for that language, and recompiling them using
the new language file (that supports *all* languages - not only a single
language).
An external database might also be used (paying in speed, but earning
memory and avoiding re-compilations).


All in all, I don't think it is an awfully complicated task. I'm just afraid
that it could break gtk too much to be useful.
I don't know enough about gtk to decide whether this prediction is
accurate, though.

                                                   Nimrod