Re: GTK internationalization, right-to-left languages

[Nimrod Zimerman <zimerman earthling net>]

On Fri, May 08, 1998 at 01:14:55PM -0400, Owen Taylor wrote:

> > 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.
> 
> I think this is a dangerous way to think of things. The only
> way X is going to be saved from the Open Group is if people continue
> working on it and contribute the results to the XFree86 project.

Yes, this might be true, but I think that in this case, changing X instead
of building on it is the wrong approach, due to two reasons.
First, Open Group's version of X won't support it, which is not good.
Second, not too many people install X manually (I didn't, for example).
Obviously, binaries can be supplied, but it would take much longer to
propagate and be tested.

>                                    The other alternative is
> to have GTK do the conversion from the logical ordering to the
> on-screen ordering, then pass the string on to X for the 
> final rendering.

This appears like the right thing to do, assuming fonts are available.
One thing that I've been trying to 'discover' for some time is how may I
create X fonts. Do you have any pointers on the issue?

> Here are two references:
> 
>   http://www.opengroup.org/public/pubs/catalog/c616.htm

Fascinating reading. Thanks. It sure sounds more complicated now. ;-)

>   ftp://ds.internic.net/rfc/rfc2070.txt

As far as I could tell when I read that (a few weeks ago), it doesn't say
anything too concrete.


> Hmmm. The benefits of being able to switch on the fly seem
> to be mostly the gee-whiz factor. ("Gee, I picked this menu
> item and everything turned into Arabic and all the dialogs
> flipped around. Now, what does "English" look like written
> in Arabic...")

Well, yes. It is an amusing feature, you have to admit. Maybe it isn't all
that important. <g>

> The ability to enter multi-lingual text is a different matter.  From
> my experience, most localized input methods allow a small amount of
> multi-lingualism. Text can be entered in the localized script or in
> English/ASCII.

In the multi-lingual version of Windows 95, a user can type in any of the
installed languages, intermixed. I don't know how useful it is, but assuming
various languages are supported anyhow, and in a manner that should be
independent of the current interface language (see below), it might be
implemented. 

In Windows 95, choice of language is done in a selection box at the bottom
of the screen, which is an unacceptable solution for gtk. Possibly, a
right-click on any text widget should by default open a widget
of some sort that allows choosing a language. 
In addition, there should be keyboard shortcuts used to switch the current
language and English (in Hebrew Windows 3.11, this is done using 
Right-Alt-Shift for Hebrew, and Left-Alt-Shift for English, but in
Windows 95 they've ruined this completely by making both of these keystrokes
*switch*, instead of *choose* a language. This might look okay in general,
but it forces the user to keep track of the current language while typing
quickly, which is a problem. Often users fine themselves typing in the wrong
language.

> My current thought is to stick to this degree of
> multilingualism for Entries, but to allow, in the Text widget,
> language as an extra attribute, as Color and Font are now.

This is less important, as I see it.
Text widgets should, in general, support *several* fonts, one for each
language. I'm not certain how this can be implemented without requiring
huge storage if many languages are added to gtk, however.

> This does mean that where different languages have different glyph
> variants for the same Unicode character, the display of GTK widgets
> without specific language markup may be incorrect.  For instance,
> Chinese Labels in program being viewed by someone with LANG=ja_JP,
> will be slightly misdisplayed. But this doesn't seem to be a major
> issue.

I didn't understand that paragraph.

In general, I believe that text should be displayed correctly regardless
of the interface language. That might be a problem when the fonts are not
available, but assuming all required fonts are available, all unicode
characters should be handled correctly.

> A slightly tricky part is user interfaces that include pixmaps
> that should be flipped. (For instance the down and to-the-left
> arrow for "OK" that GNOME uses). I think, there, it has to
> be up to the application (or up to gnome-stock) to make the
> determination. GTK+ shouldn't be in the business of mirroring
> pixmaps.

Yes, I agree. Flipping pixmaps generally is not a good idea.
However, there should be some mechanism to allow these issues to be handled
in a consistent manner, similar to that GNU gettext has. I don't know how
this can be done in a general manner, though.

> > characters. Unicode looks like a good candidate, but I do not know too much
> > about it.
> > How much of gtk would this break?
> 
> It depends what you mean by "break". Unicode is going into GTK+ one
> way or the other - and yes it is a potentially backwards incompatible
> change. But it is one for the better, so I wouldn't call it breakage.

Unicode should solve a large portion of the problems. It also supports RTL
and LTR characters (which are required for correct rendering of logical
text), as far as I know.

> One possibility is to make the old names for text-dependent
> functions convert automatically from the locale-dependent encoding
> to UTF-8, and provide new names for UTF-8 functions.

Given gettext is to be used anyway, this might be a non-issue to a certain
degree.

> > 5. Language files.
> 
> [ As Tom says, gettext is the right way to go here ] 

gettext alone, however, doesn't seem to be sufficient. Some wrapper, written 
using gtk, should be used to enter Unicode strings (using whatever
encoding fits - I assume UTF-8 is one). I believe emacs supports Unicode,
or at least parts thereof, but emacs shouldn't be a requirement here (I,
for example, don't have the space to install it).

> I think it is an important issue. Except for Japanese, and to
> some extent Chinese, internationalization to non-Roman scripts
> really hasn't been addressed in the free-software community,
> and I think such support would really be a valuable feature
> for GTK+.

In Israel, the lack of localized Hebrew software is probably the number one
problem Linux has.


I am currently looking for Unicode information. The two Unicode Standard
books in my university's library are both on permanent loan, and there is
very little chance I could put my hands on a copy unless I'm going to buy
one. Is there any on-line information? My searches resulted in almost
nothing.

                                                   Nimrod