Kaixo! 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: > > http://amaoui.free.fr/gnome2/images/gnome2ar.png > > 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: http://chanae.stben.be/pablo/gnome2ar.png 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: http://chanae.stben.be/pablo/gnobots2rtl1.png as it should be: http://chanae.stben.be/pablo/gnobots2rtl2.png in LTR languages: http://chanae.stben.be/pablo/gnobots2ltr.png > 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. Thanks > roozbeh > -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.stben.be/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese]
Attachment:
pgp00000.pgp
Description: PGP signature