GNOME Bugzilla – Bug 317103
RTL direction in Yelp
Last modified: 2008-07-05 09:52:48 UTC
Version details: I've not checked Distribution/Version: Ubuntu 5.04 Yelp cannot show Persian, Arabic, Herbew and other RTL language XML documents in Right To Left direction...
The Ubuntu translators have been hit by this when translating the Breezy FAQ. If anyone wants to create some test data for GNOME, http://kvota.net/doc-l10n/by-modules.html has all the modules that have been moved to the xml2po framework. geyes is pretty tiny: get the pot file, translate to Arabic and then generate the xml (stick the po file in a geyes/docs/ar dir, edit Makefile.am, make & make install). I'm trying to ifnd out if thee problem lies in xml2po or yelp. Of course, I suspect of yelp first.
Well, this needs to be solved step by step. For what it's worth, it does render something useful in ltr mode. I mean, the script is rendered correctly (attaching shots.) xml2po seems to be working perfectly fine. IIRC yelp was switching backend to use gecko. Is that the case? In that case, a decent right-to-left support is granted, all needs to be done is a bit of hacking to make it understand when to switch to rtl. After that, remains a bit of work, on arrow images, tables, and other tweaks a bidirectional UI needs. Mehdi, maybe you have more specific problems we can start tackling?
Created attachment 52612 [details] Persian geyes.xml Persian geyes.xml junk for testing (and testing only.) Something like this installs it: su - cd cd /usr/share/gnome/help/geyes/ cp -r C fa cp [attachment] fa/geyes.xml To test, do: killall geyes_applet2 LANG=fa_IR /usr/libexec/geyes_applet2 [click reload on the dialog that has popped up] [right click on geyes, select help]
Created attachment 52613 [details] Shot of the test translation Screenshot of it. Fedora Core 4.
Behdad, I just looked at the xml file you've created for geyes... You know, the problem starts when I have a sentense with a combination of Persian & English words... There is no problem with Enlish only or Persian only sentences like what you've done in geyes xml The other thing I would like to tell you is Yelp shows phrases in RTL direction in it's left column but every thing is LTR in it's right column... Please have a look at the shot...
Created attachment 52624 [details] Shot of the prob. Shot of the problem in Ubuntu 5.04
Thanks Mehdi, It's just that the contents are rendered as LTR. When we switch to RTL, the problem with mixed text disappears. I'll take a look at it...
Created attachment 52641 [details] [review] Patch to fix Attaching short patch that sets the default direction of mozilla embedding to the default direction of gtk+. Should be a good start. Can be applied? Mehdi, can you please test and enumerate further problems?
Commenting on the patch: It sets mozilla direction to that of current locale unconditionally. This works fine as long as docs in the current locale are found. What we want instead, is to fallback to left-to-right if docs in the current locale are not found and C docs are used. Given the current patch, that's probably rather easy to implement for somebody familiar with the yelp code, rather than I poking around yelp.
Can a Yelp developer look into this please.
Created attachment 56880 [details] [review] My Attempt Hi, Can someone please test this? I have no idea if it works or what to expect if it does. It *should* work by looking up the language of the document as registered with scrollkeeper. If one has been registered that isn't "C", runs gtk_widget_get_default_direction and sets RTL according to that. As I say, I'm not entirely certain I'm even approaching this right, so can someone have a look and let me know. Cheers
I guess I just don't understand why Gecko doesn't always render those scripts as RTL. I realized that I'm not setting the lang or xml:lang attributes on the XHTML output, so I tried adding those, in the hopes that it would give Gecko a clue. But that didn't work. The problem with both of the patches is that they'll set the direction for all Yelp windows, viewing all documents. Anything set with one of the gecko_prefs_set functions gets applied to all the Gecko windows open in Yelp. So if you're viewing an English document in window 1, and you load up a Persian document in window 2, the second patch would cause window 1 to switch to RTL. Surely this shouldn't be so stupidly difficult. I mean, we can visit web pages in Arabic and have the text displayed correctly, right? So what's causing Gecko not to display these pages correctly?
Sounds like a question for Christian Persch - <cue superman music>
Shaun, the reason gecko does not switch to rtl automatically is that according to XHTML/CSS standards, default direction is always ltr. The way rtl documents are set rtl on the web is using the short CSS "body {direction: rtl}". Is adding a CSS to set direction:rtl on the root element easy enough to do in yelp?
Created attachment 56920 [details] [review] Another attempt Once more... This time, the code to figure out whether the direction should be RTL or LTR is still the same: If the doc is registered in scrollkeeper as a language other than "C" and the default direction is RTL, use that. This is passed into the CSS for generating the HTML where is is added to the root <html> element. This seems to work for me. I've also obsoleted the 2 patches prior to this in line with shauns comments.
The correct fix is to put this in gnome-doc-utils then.
seems that scrollkeeper is not translated to many RTL languages. This is blocking me from testing this bug, since the fix gets the language code from scrollkeeper. See http://mail.gnome.org/archives/gnome-i18n/2005-November/msg00053.html I'm investigating a fix for scrollkeeper ATM so that we don't have this stupid limitation Shaun: you're just talking about the CSS part of DonS' patch?
I've committed a fix for this into gnome-doc-utils.
Created attachment 56929 [details] [review] shaun's patch so us mere mortals can tell what he did shaun's patch so us mere mortals can tell what he did this was committed to gnome-doc-utils _not_ yelp
Thanks Shaun. Looks good. I will test as soon as I have a working laptop again...
Works here. Thanks. I see some weird artifacts though.
Was this in for gnome-2-18? Because I still see the problem with 2.17.92
Djihed, you need to update your translations for it to detect rtl.