Re: Right-to-left Gnome


On Tue, Jul 23, 2002 at 04:36:14PM +0430, Roozbeh Pournader wrote:
> I just saw a screen shot from the Arabic translation of Gnome 2 at:
> Which clearly has two major problems, one is that the widgets are not 
> mirrored and the other is underlining breaks Arabic joining.

The non mirrorization in that screenshot is due to gtk2.po being incomplete
and missing the RTL directive;
here is a screenshot that shows the situation is a bit better:

However, there are still some widgets not mirrored:
- the menu bar (it should be right aligned, with "file" on the right
  and "help" on the left, it isn't)
- same for toolbars 
- the menu entries (not shown on the screenshots; but they have icons
  and shortcuts still in the LTR direction, the icons should be on the 
  right, and shortcuts on the left. the "..." are correctly positionned,
  as they are part of the text)
- the handlers of menu bars (those vertical bits that allow taking the
  bars out of the window) should be on the right.
- tabs, they should be right aligned and starting from the right to
  the left.
- drop down menus and vertical scrollbars, the arrow part is on the
  wrong side.

also, all stock icons for which the direction is important should be
verified and if needed mirrored depending on the direction of the
widget placing (in particular the arrows of previous/next kind of
buttons, the do/undo ones, etc. but not those telling right/left
directions (like the gnobots keyboard settign (well, there aren't arrow
icons there, but the West/East widgets should not be mirrored; they
currently are, that's a bug).

I haven't tested, but the placement of items in the panel should also be
right aligned, and the default "hidding" direction should be to the right
of the screen, etc.
icons on the rootwindow in the desktop should also be aligned to the right
and in columns from right to left.

I haven't tested either, but sawfish should have titlebar buttons mirrored.

> About the first, I remember Robert Brady telling me he had a patch for
> mirroring GTK widgets, but unfortunately the guy has disappeared from the
> Net. Does anyone have such a patch? Is there any chance of inclusion into
> GTK? (I can take responsibility.)

A lot of widgets already are automatically mirrored for RTL languages;
the remaining problems are that some others still are not.
And that programs must be checked for some exceptions cases where some
widgets must not be mirrored (like in the case of gnobots2, the indiviadual
widgets of the direction keys configuration must not be mirrored; but
the whole set of widgets of the direction keys must be mirrored:

as it is now:
as it should be:
in LTR languages:

> And about the latter, does anyone have a clue about the possible source
> and how to fix that? I just wanted to ask before jumping to code.

For the not mirrored widgets, it has to be fixed inside of gtk+ I suppose.
For the other problem (widgets mirrored but that shouldn't) it has to
be fixed in the source of the particular programs; howevr I don't know
how to tell that a particular widget or group of widgets should not be
mirrored; is there a special way to handle that ?
if not, it should be added to gtk, it is necessary for proper and easy
support of real bidi applications.

So, to summarize: everything should be mirrorized, unless those widgets
that represent a spatial layout: either geographic cardinal points
(east/west) or right/left.
However, in the case of right/left, while the spatial dispostion of widgets
should not be mirrored in order to preserve the right/left meaning,
if there is a default value for left in LTR mode it should default to
right in RTL mode (or better, default it to directionality direction) 

It would be nice too if the "3D shadow" effect on widgets could be mirrored
too (that is, the virtual light source being on top right corner instead
of top left); that is however much less important than the other problems,
just the final eye candy touch.
On the other hand, it maybe is the easier thing to do ?

The problem of discontinued ligaturing when a shortcut is present is
due to the fact that "_" is not a joining char.
Maybe pango is called to earlier ? and itshould be called with the
"_" removed from the string (and instead having an "underline" attribute
for the shortcut letter).
If that is already what is done, then it is a bug of pango; a change
in font style (like having some chars underlined) should not break
the joining. 

Well, currently the Arabic translation "solved" the problem by removing
all accelerators.

A last thing: in the "about" windows of EOG there is a line completly
in English, but the ending period is on the left.
Isn't that a bug of pango/fribidi ?
If a line has no RTL character at all, and has at least one LTR char
(that is not a digit), then all the directionality-agnostic chars,
like punctuation, should follow LTR.

And if some of the Arabic translators is reading me: the "(c)" sign should
be translated with the right copyright symbol (U+00A9); as Arabic requires
utf-8 for proper writing anyway (iso-8859-6 is way deficient, due to the
lack of ZWJ and ZWNJ that are in some cases required to have a proper
display) there would be no problem to put it in the utf-8 po file;
it avoids the problem of the bad positioning of the parenthesis,  and
it would be nicer than the ascii only "(c)" trigraph.
That also means that the string with "Copyright (c) foo" should always
be made translatable.


> roozbeh

Ki a vos vye bn,
Pablo Saratxaga		PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Italian or Portuguese]

Attachment: pgpcwLFTKoc6A.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]