Re: GTK internationalization, right-to-left languages
- From: Nimrod Zimerman <zimerman earthling net>
- To: gtk-list redhat com
- Subject: Re: GTK internationalization, right-to-left languages
- Date: Sun, 10 May 1998 00:01:55 +0300
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:
Fascinating reading. Thanks. It sure sounds more complicated now. ;-)
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
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
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
> 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
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
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
> > 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
] [Thread Prev