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.

Screenshot of current implementation

Attached:

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.

Attached:

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).