GNOME Bugzilla – Bug 686630
"<app> has been added to your favorites." message appears as left-to-right in Hebrew locale
Last modified: 2012-10-25 17:41:36 UTC
[I'm sorry if I'm filing this at the wrong component. I'm a newbie in bugzilla.gnome.org.] To reproduce: 0. Open GNOME in the Hebrew locale. 1. Go to the apps list. 2. Right-click an icon. 3. Click "Add to favorites". Notice the messages at the bottom: The full stop is on the right-hand end of the message. It must be on the left-hand end. The directionality of that element must be set to RTL in right-to-left languages.
(In reply to comment #0) > Notice the messages at the bottom: The full stop is on the right-hand end of > the message. It must be on the left-hand end. It works correctly here if the message is fully RTL, but not if it starts in LTR (which is the case for untranslated application names) - I did suspect our text direction handling in notifications[0], but it's actually Pango itself: the first character with a "strong direction" determines the overall text direction. I don't know if it is possible to change the wording of the translated message so it always starts in Hebrew - it's lame, but should work correctly. Other than that I can't think of anything we could do to fix this - mixed text is hard :-( [0] http://git.gnome.org/browse/gnome-shell/commit?id=1d2eadb9c0300f
Hmm. The first-strong algorithm is useful in text editors, where it's hard to find out the direction otherwise. Hard, but not entirely impossible: One can use the RLM character. It is rarely used in practice, because it's invisible and too tricky to type. The first-strong algorithm can also be used in HTML5 when it's completely impossible to find out the direction of an element (dir="auto"). Is it really impossible in Gtk to define a piece of text explicitly as RTL? (Sorry, I program in Perl, PHP and JS and not in Gtk.)
(In reply to comment #2) > Is it really impossible in Gtk to define a piece of text explicitly as RTL? No, but just forcing notifications to be RTL will mess up latin text (notifications from applications with missing translations, English chat messages, ...)
Oh, so the direction of all notifications is automatic?
Yes, I guess you could say it is. The direction of the text itself (inlcuding the period ;-) is determined by Pango (the text rendering library used by GTK+/Clutter), in the case of notifications we then use that information to place other elements like the icon or action buttons.
You can certainly include an RLM mark at the beginning of the hebrew translation for "%s has been added to your favorites."
Created attachment 227087 [details] [review] po: Enforce RTL in he for messages that might end up as LTR As the messages start with a string placeholder that might be untranslated, we need an explicit mark to ensure that the string does not end up as LTR.
(In reply to comment #6) > You can certainly include an RLM mark at the beginning of the hebrew > translation for "%s has been added to your favorites." Bingo! There were quite a couple of strings affected, so I'll request review from Yaron. A quick test with the "add/remove from favorites" notifications suggests that the patch does fix the issue though (well, all I can really tell is that application name and period are in the correct position).
Great work Florian! Thank you for your time and dedication. This is a good fix and you can go ahead and merge it in. Kind regards! Yaron Shahrabani.
Attachment 227087 [details] pushed as 8b796d8 - po: Enforce RTL in he for messages that might end up as LTR
Shouldn't this be done for Arabic (ar), Farsi (fa), and Uyghur (ug) also?
Created attachment 227121 [details] [review] po: Enforce RTL in fa/ug for messages that might end up as LTR See commit 8b796d80a7ea. (In reply to comment #11) I had checked Arabic, which already does that; here's a patch for Farsi and Uyghur.
I checked my language Farsi/Persian, and the notice is shown correctly. The Problem in Hebrew might be because they have started the sentence with English alphabet. The best way to fix these kind of issues is to determine direction based on the number of Latin and RTL alphabets in the sentences. This is the solution that is used in websites like identi.ca, G+ or twitter. The code for Direction Detector in Status.net might be a help [1] [1] http://gitorious.org/statusnet/mainline/trees/master/plugins/DirectionDetector
identi.ca, Twitter etc, have to make these guesses because they don't have an easy way to specify the direction explicitly. In Gnome the direction is supposed to be known. I know almost nothing about Gtk, so forgive my ignorance, but it seems to me that the really right thing to do is to have a general way to set the direction of a component. I haven't done any GUI development on X platforms at all, but from the little GUI development that I did on Windows, it's definitely possible in MFC and .NET. Also, it's probably better not to do it per-language, but to define a group of RTL languages somewhere. In MediaWiki, my main project, every language code is an object that has a boolean $rtl property. Again, forgive my ignorance - I don't know almost anything about Gtk and GNOME internals.
(In reply to comment #13) > I checked my language Farsi/Persian, and the notice is shown correctly. The > Problem in Hebrew might be because they have started the sentence with English > alphabet. Yes, sorry for not being clear - the particular messages mentioned in the bug report are not an issue for Farsi, but there are other translations that start with "%s" and likely show the same problem (most of those are chat related). > The best way to fix these kind of issues is to determine direction based on the > number of Latin and RTL alphabets in the sentences. I disagree, let's pick the first affected message in Farsi: "%s is now known as %s" Here, both "%s" are IM names ("florian is now known as fmuellner"). If we based the text direction on the number of characters, it would end up depending on something as arbitrary as the length of the username someone chooses in a conversation. (In reply to comment #14) > In Gnome the direction is supposed to be known. I know almost nothing about > Gtk, so forgive my ignorance, but it seems to me that the really right thing to > do is to have a general way to set the direction of a component. This is possible, but would introduce issues for LTR text - we don't control at all what applications users install (read: they may or may not be translated), or with whom they have conversations. So we cannot just assume that a single text direction will be correct for everything (the same is of course for RTL text in LTR locales, though it's less frequent to cause problems). > In MediaWiki, my main project, every language code is an object that has > a boolean $rtl property. We have something similar, where every ClutterActor/GtkWidget has a text direction. But again, it is fine to use that for laying out UI elements (e.g. whether window buttons should be in the top-left or top-right corner), but not to force a text direction on text which uses a foreign script.
Ping? I have approval of the Uyghur translator, should I strip out the Farsi changes?
(In reply to comment #16) > Ping? I have approval of the Uyghur translator, should I strip out the Farsi > changes? Sorry. Go ahead. That's fine :)