Not necessarily the content direction. More like the page language direction fetched from Title.

Actually, the toolbar happens to be mostly OK and the toolbar should match the interface language. Some toolbar buttons must be adjusted for RTL, but that's a separate bug.

Confirmed bug is still present in new version - CE takes language cue from uselang when should take it from the wiki (?). Note that toolbar/chrome issues also appear.

The direction should be taken from Title->getPageLanguage(), which in the case of the special page depends on the user language. But because that is also the case on mw:VisualEditor:Welcome, there is indeed a bug. Looking at the source, the <div class="mw-content-ltr/rtl"> is unused and instead a <div class="ve-surface"> is added. I think adding there the same attributes as on the other div will fix this bug.

Mass-moving items into VisualEditor product

Mass-move out of "General" to "ContentEditable".

orbit wrote:

Rob, it looks like this might be as easy as copying the lang and dir attributes from the #mw-content-text element and applying them to the .ve-surface element.

orbit wrote:

Switching to integration.

If you haven't already, take a look at
https://www.mediawiki.org/wiki/VisualEditor/Internationalization_requirements

It is supposed to give an idea about the general framework of how language is handled in MW.

... Sorry, saved before completing.

If you haven't already, take a look at
https://www.mediawiki.org/wiki/VisualEditor/Internationalization_requirements

It is supposed to give an idea about the general framework of how information about content language should be stored and used in MW in the VE age. It is up for discussion, of course.

(In reply to comment #7)

Rob, it looks like this might be as easy as copying the lang and dir attributes
from the #mw-content-text element and applying them to the .ve-surface element.

Yep, that's what I said in comment 4 :-)

The content direction issues were resolved in Iaf61fb9e8ad0ba3ab70ffa00c75da4c6f01aad61 by copying the dir and lang attributes from the #mw-content-text div to the document.

The toolbar issues should be reported separately and with greater detail.

(In reply to comment #12)

The content direction issues were resolved in
Iaf61fb9e8ad0ba3ab70ffa00c75da4c6f01aad61 by copying the dir and lang
attributes from the #mw-content-text div to the document.

The toolbar issues should be reported separately and with greater detail.

With my gerrit 9860, the attribs of #mw-content-text don't always belong to $wgContLang now.

Reopening, the issue will still appear when someone visits [[kk:pagename]] with variant=kk-arab set where wikitext is written in kk-latn. (where kk and kk-latn is ltr and kk-arab is rtl).

Assigning to current milestone, as it's been sitting around for four months untouched at this point.

(In reply to comment #14)

Reopening, the issue will still appear when someone visits [[kk:pagename]]
with
variant=kk-arab set where wikitext is written in kk-latn. (where kk and
kk-latn
is ltr and kk-arab is rtl).

Yup, that's a bug. We need to use Title::getPageLanguage() instead of looking at #mw-content-text (which is controlled by getPageViewLanguage()).

However, MW core doesn't quite get this right either, see bug 46463.

This didn't make it to the milestone; pushing back.

(In reply to comment #12)

The content direction issues were resolved in Iaf61fb9e8ad0ba
by copying the dir and lang attributes from the #mw-content-text
div to the document.

The toolbar issues should be reported separately and with greater detail.

Can someone confirm that the edit surface in VisualEditor is now properly using the directionality of the wiki content language (instead of the user language)?

From what I can see this bug is fixed in that regard by change Iaf61fb9e8ad0ba indeed.

(In reply to comment #16)

(In reply to comment #14)

Reopening, the issue will still appear when someone visits [[kk:pagename]]
with
variant=kk-arab set where wikitext is written in kk-latn. (where kk and
kk-latn
is ltr and kk-arab is rtl).

Yup, that's a bug. We need to use Title::getPageLanguage() instead of looking
at #mw-content-text (which is controlled by getPageViewLanguage()).

However, MW core doesn't quite get this right either, see bug 46463.

So there is a case where the #mw-content-text isn't set to the wiki content language but to the user language, if the content language has a variation? That sounds like a MediaWiki core bug perhaps. Though we could export Title::getPageLanguage() in VisualEditor specifically, looks like this should be fixed in core instead, given that it sounds like the regular view of an article when reading articles would be broken now as well. And I think the VisualEditor edit surface should match what the regular page view does.

(In reply to comment #18)

So there is a case where the #mw-content-text isn't set to the wiki content
language but to the user language, if the content language has a variation?
That sounds like a MediaWiki core bug perhaps. Though we could export
Title::getPageLanguage() in VisualEditor specifically, looks like this should
be fixed in core instead, given that it sounds like the regular view of an
article when reading articles would be broken now as well. And I think the
VisualEditor edit surface should match what the regular page view does.

On wikis with variation, there're three language codes. One for user language (to fetch interface messages), another for content language (wikitext written in) and the third for page view language (after wikitext gets rendered, it's converted to another language / variant then displayed to user, by LanguageConverter). The third can be the same as or different from the first; they're used for different things. However in practice they're usually set to the same one by users but we shouldn't assume this. #mw-content-text has the third language code mentioned above, and if VisualEditor and Parsoid are not aware of variation / conversion, they're processing content in the first language (code).

(In reply to comment #19)

(In reply to comment #18)

So there is a case where the #mw-content-text isn't set to the wiki content
language but to the user language, if the content language has a variation?
That sounds like a MediaWiki core bug perhaps. Though we could export
Title::getPageLanguage() in VisualEditor specifically, looks like this should
be fixed in core instead, given that it sounds like the regular view of an
article when reading articles would be broken now as well. And I think the
VisualEditor edit surface should match what the regular page view does.

On wikis with variation, there're three language codes. One for user language
(to fetch interface messages), another for content language (wikitext written
in) and the third for page view language (after wikitext gets rendered, it's
converted to another language / variant then displayed to user, by
LanguageConverter). The third can be the same as or different from the first;
they're used for different things. However in practice they're usually set to
the same one by users but we shouldn't assume this. #mw-content-text has the
third language code mentioned above, and if VisualEditor and Parsoid are not
aware of variation / conversion, they're processing content in the first
language (code).

^ I guess this should be explained on some MW.org page. I have been asked about this stuff several times.

(In reply to comment #19)

and if VisualEditor and Parsoid are not
aware of variation / conversion, they're processing content in the first
language (code).

Sorry I mean the second in this sentence.

@liangent: Some developer-focussed documentation of this area of MW would be wonderful - all I can find is about how it works for the user (and mostly from 2004).

(In reply to comment #22)

@liangent: Some developer-focussed documentation of this area of MW would be
wonderful - all I can find is about how it works for the user (and mostly
from
2004).

I updated https://www.mediawiki.org/w/index.php?title=Language_in_MediaWiki&diff=677107&oldid=599175 which is related to this bug... Actually the whole conversion system needs some re-design, though it doesn't have any timetable, but it still occurs to me that documenting the old stuff is not so worthwhile.

Related URL: https://gerrit.wikimedia.org/r/63148 (Gerrit Change Ica006404227dcd286c387de4f637036341b17eae)

Finally closed! Yay. (Merged, will go out in wmf4.)