Last modified: 2011-07-24 11:35:51 UTC
If a message is translated into an RTL language, it must be displayed as RTL in the resulting page. See http://translatewiki.net/wiki/MediaWiki:Mwe-embedplayer-fullscreen-tip-osx/he for an example of a confused page - it has text in Hebrew and English that appears in the wrong order. Simply adding div dir="rtl" around the message if the language is RTL will solve this bug.
(In reply to comment #0) > Simply adding div dir="rtl" around the message if the language is RTL will > solve this bug. It's just that that exact thing is nowhere near simple to do in MediaWiki.
(In reply to comment #0) > Simply adding div dir="rtl" around the message if the language is RTL will > solve this bug. Unfortunately, it might also be producing wrong nestings of HTML inline and block elements, producing invalid HTML. It is usually better to find the nearest enclosing block element (<div>, <td>, <li> or so) and set its dir= and lang= attributes - provided, there is nothing else in this container.
I think MediaWiki:-namespace subpages are next to impossible to put a right direction on. However in translation in a jQuery ui dialog box on Special:Translate I think this is possible by using getDir() for the input textarea. Note that this case is limited to scenarios where a non-RTL langauge user is editing an RTL-language, since otherwise the direction is inherited from the page user language.
(In reply to comment #3) > I think MediaWiki:-namespace subpages are next to impossible to put a right > direction on. Contrary, it is easy. The subpage name contains the language or locale code at its end, which gives the intended directionality for the message rendered and the textarea, if any. All other parts of the page may have a directionality of their own. Of course, the idea that the page had a directionality common to all its parts is (generally) wrong, and the directionality of the outer parts of the page should likely be derived from the combinations of wiki and interface language (or locale) used, in the usual way. > Note that this case is limited to scenarios where a non-RTL langauge user is > editing an RTL-language, since otherwise the direction is inherited from the > page user language. Not true. Of course, it applied as well to an RTL user language being used while editing an LTR language message. Btw., while inheritance can of course be used to save an HTML attribute being output, this is of little practical concern, imho. I do not see any difference between the normal editing interface and the scripted one. In either case, the server can output everything correctly to the client, and no script interaction concerning directionality is required.
I think this bug can be marked as fixed with my recent commits. Amir, can you confirm this?
(In reply to comment #5) > I think this bug can be marked as fixed with my recent commits. Amir, can you > confirm this? Seems so! Thank you.
Good, marking as fixed.
Seems to work for me, too, but I did no thorough tests.
