Bidi behaivour of text field

After talking to someone who knows html it seems adding "DIR=RTL" property
to the entry field in langauges which are RTL should fix the problem.

This URL is interesting for this bug (thanks Matt!):

http://www.w3.org/TR/html4/struct/dirlang.html#adef-dir

This bug severity is normal but it's actually making it close to impossible to translate to hebrew text which has both english and hebrew in it.

Just to mention this bug actually exists...

Ely

We can use GTK's PO files to get an initial list of languages with RTL as the global text direction.

During initialisation, GTK tries to translate the string "default:LTR". If the translation is "default:RTL" it uses RTL as the default direction for the interface. So the list of PO files for GTK that translate "default:LTR" to "default:RTL" should give a good starting point for a list of RTL languages.

Doing a grep over my CVS checkout of GTK, I get the following RTL languages:

  ar, az_IR, fa, he, yi

The translations currently in Rosetta might indicate some more ones.

Another summary of the IRC conversation from earlier:

We should be using both the "dir" and "lang" attributes when displaying the translated content (both in text boxes and for the "similar languages" display).

The "dir" attribute is needed to set the global direction for the text fragment, and the "lang" attribute is required to correctly render some text (e.g. for CJK languages, different fonts may be picked for a string of code points depending on language).

The lang attribute should be of the form "en-AU" (i.e. with a dash rather than an underscore).

I just merged a patch to set the "lang" and "dir" attributes on translation entry boxes and suggestion text. Once it gets rolled out to production, the bug should be fixed.