GNOME Bugzilla – Bug 81330
hebrew input, English interface?
Last modified: 2008-09-11 16:51:03 UTC
When I use Hebrew (LANG = he_IL.ISO-8859-8), all the interface changes to right-to-left interface, even when the application has not been localized to Hebrew. This means the titles, options etc. are in English, but they are displayed adjusted to the right, the period is on their left (as if a Hebrew sentence ended), the option buttons sweep locations, the icon is left of the text in menus etc. I want to emphasize that the English text is presented okay (i.e., the English letters and words are arranged left-to-right), but everything else looks Hebrew. Examples would be: [icon] ...Preferences rather than: Preferences... [icon] or: (Do background check quietly (no messages in status bar [checkbox] rather than: [checkbox] Do background check quietly (no messages in status bar) [The parenthesis are also wrong, as can be seen). This happens in all application I saw in GNOME 2.0. The problem is that right-to-left should be determined by the contents of the line (if it is indeed Hebrew), not just by the $LANG variable. [I hope I open the bug for the correct package, please let me know if it's another package responsibility.]
There are a couple of things going on here: - The interface being flipped even if you don't have Hebrew translations. Nothing we (GTK+/Pango can really do about this.) When you set LC_MESSAGES to he_IL (by setting LANG, which affects all locale categories), GTK+ assumes that you have a Hebrew interface. - A dup of bug 70451 ... GTK+ probably should determine the directionality of strings from their contents rather than the locale. - ? Perhaps we need to do more to support LC_CTYPE=he_IL, LC_MESSAGES=en_US ... that is, don't flip the interface, but default text entries to RTL. Not sure exactly what is needed here, but it probably doesn't work very well to run Hebrew in this mode. (See also bug 50770)
Regarding the third point: I now tried this combination: LC_CTYPE=he_IL, LC_MESSAGES=en_US. It indeed improves the interface, but there is an inherent problem here: The text is left aligned, so when I write Hebrew it looks aligned to the end of the sentence. On the other hand, when I write English, it's OK. In gedit or balsa, for example, there are times when I write in English and times when in Hebrew. I can't see how GTK+ or pango can know which one I prefer in the current run. The user should be given the option to choose: One way is the environment variables, but this is not enough too: If I have a running balsa and I answer e-mails in English, I don't want to quit and run again with different environment just to answer e-mails in Hebrew, etc. (In balsa, for example, I can't have two of them running concurrently, because of IMAP'ed mailboxes.) Another obvious solution is to ask each application to provide the user with an RTL button, but I guess we would like to refrain from this, because (unfortunately ;-) most application writers are not native speakers of Hebrew. This is what happens in that big company which already has (bad) Hebrew localization (but they control all relevant applications, so they can localize all of them...). I thought of a different attitude, but I'm not certain of how acceptable it would be. As I mentioned, the problem is with *writing* RTL or LTR text. The problem of reading RTL or LTR is the second point you mentioned (bug 70451), which we know the way to solve (determine by contents). The only way I see to allow the user select which direction he/she uses in a general enough way would be to add a selection button for the direction. In order for the solution to be general (rather than application specific), I suggest that when widgets for entering text are displayed and also LC_CTYPE=he_IL (or any other RTL language), a button or checkbox or whatever is displayed along with the basic widget (as a part of the widget, without any change in the application), and this button/ checkbox/radio button/whatever would determine the RTL/LTR behavior of the widget. The use of LC_TYPE would prevent non-Hebrew users from having this (ugly :) button on screen. In other words, I suggest that text-entering widgets would, in some cases be displayed as a combination of the text-entering widget and a direction selection method (button etc.). This combination would compose the text-entering widget (i.e., these would NOT be two widgets, but a single one from an application point of view). The cases when the extra selector is displayed would be determined by the LC_TYPE. I'd be glad to know if this solution makes sense. BTW, the text-entering problem would exist regardless of the localization effort. Even if I had LC_MESSAGES=he_IL, and all the interface was in Hebrew, I still need a way to write English e-mails, English letters in a word processor, etc. and it happens too often to change the environment variables each time. I can't have *everything* RTL.
Moving various feature enhancements to the 2.4.0 milestone.
I think the auto-bidi-directoin changes that just went in will make this much better, and maybe nothing else is needed, but I'll leave this open for right now until people get some experience with the new code.
Interface flipping for non localized application (mentioned in comment #1) has been fixed in bug 503071. Regarding comment #4, I'm using gnome from version 2.6 and never seen issues with entering hebrew text (not counting gtkhtml )-;).