Last modified: 2013-05-10 18:16:03 UTC
The default direction for text in the Visual Editor should match the direction of the site. Currently it appears to match the direction of the user's content language. This also affects all the help panes - JSON, preview, keyboard shortcuts help, etc.
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".
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.
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 change #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.)
