Last modified: 2011-07-24 11:37:31 UTC
Just relaying http://translatewiki.net/wiki/Thread:Support/RTL_doesn't_work I don't know when this happened or why.
Shouldn't <link rel="stylesheet" href="/w/load.php?debug=false&lang=he&modules=mediawiki.legacy.commonPrint%7Cmediawiki.legacy.shared%7Cskins.vector%7Ctranslate-css&only=styles&skin=vector"> get a &dir=rtl ? Or make load.php set dir=rtl as default for all rtl scripts
(In reply to comment #1) > Shouldn't > <link rel="stylesheet" > href="/w/load.php?debug=false&lang=he&modules=mediawiki.legacy.commonPrint%7Cmediawiki.legacy.shared%7Cskins.vector%7Ctranslate-css&only=styles&skin=vector"> > > get a &dir=rtl ? > > Or make load.php set dir=rtl as default for all rtl scripts The dir parameter is inferred from the lang parameter if it's not set, so &lang=he will set RTL mode. Or should do so at least, some of that code changed and I don't know what's what any more.
(In reply to comment #2) > The dir parameter is inferred from the lang parameter if it's not set, so > &lang=he will set RTL mode. Or should do so at least, some of that code changed > and I don't know what's what any more. Hmm, now it's inferred from the *content* language instead. I wonder why.
Since it would make english articles left-aligned. Imo, the best way would be to 1. Infer the dir from the display language (Atleast mediawiki & commons forced the display language to set the direction previously.) 2. protect #bodyContent etc. with dir=contentLanguageDir
(In reply to comment #4) > Since it would make english articles left-aligned. > Imo, the best way would be to > 1. Infer the dir from the display language (Atleast mediawiki & commons forced > the display language to set the direction previously.) > 2. protect #bodyContent etc. with dir=contentLanguageDir This is kind of over my head. Niklas, could you weigh in on this?
(In reply to comment #3) > (In reply to comment #2) > > The dir parameter is inferred from the lang parameter if it's not set, so > > &lang=he will set RTL mode. Or should do so at least, some of that code changed > > and I don't know what's what any more. > Hmm, now it's inferred from the *content* language instead. I wonder why. r81622?
(In reply to comment #6) > r81622? Was just about to say that.
Created attachment 8175 [details] Screenshot of current implementation
Created attachment 8176 [details] How the method from comment 4 would look like This is how a patch from comment 4 would look like: Correct outer layout; and the content has the correct direction of wgContentLanguage.
We have the very general problem in MediaWiki, that we often do not know the language/script, and thus directionality, of a piece of text. For instance, when fallback languages mix with either content language or uselang= language in a page, each of those different pieces and snippets should be properly tagged with lang= and dir= attributes in HTML. But wfMsg*() neither tells, which actual language was picked (can even return mixed languages) nor does it add such tagging where appropriate.
Since a fix has been made and Roan has merged it to 1.17, I'm closing this bug.
What fix?
(In reply to comment #12) > What fix? r81622 unless I'm missing something.
That wasn't a proper fix: "This makes the content readable and the ''UI messed up''" And this bug is about the wrongly aligned UI
Indeed it's not a fix, it's the cause (or half of it, if resource loader is the other half?)
(In reply to comment #15) > it's the cause Thanks for helping me understand this better :)
Removing 1.17 tarball blocker because Tim writes this in his explanation for the change: > It's not ideal, but at least it's no worse than it was in 1.16. It's > preferable because the content area is more likely to have bidirectional text > than the UI area. The UI is split up into short strings, generally in a > consistent language, so there is less chance of the UBA moving fragments of > text around.
*** Bug 28228 has been marked as a duplicate of this bug. ***
Marking as fixed, because bug 6100 is fixed, which appears to be about the same... (r91518).
