Last modified: 2013-05-28 23:16:04 UTC
This is using Firefox under Ubuntu 13.x: The problem: If the wiki is RTL (Hebrew, for instance), start editing an empty page. The caret appears on the left side and the typing is done LTR. I did a quick check, and noticed that there is a class added to the content box - "ve-ui-surface mw-content-ltr" even when the page language is rtl (defined in the <html dir="rtl"..> I found this addition in the ve.init.mw.ViewPageTarget line 786: this.surface.$.addClass( 'mw-content-' + mw.config.get( 'wgVisualEditor' ).pageLanguageDir ); In my system this produced "mw-content-ltr" despite the fact the page language was Hebrew and the html direction was defined as rtl. However, I then tried to forcefully change it to rtl, just to test, and while the class appeared correctly (mw-content-rtl), the direction of the typed text was still LTR. It remained LTR when I changed the language to English.
Okay, I figured out the problem, but this isn't precisely a bug and it depends on what you want the behavior to be. First off, the issue seemed to be that the definition of the page language was always LTR in VE, regardless of what language I was using. Even when my page was Hebrew/RTL, VE's config showed it as english/ltr. That was quite frustrating, I was starting to think the problem is that the hooks page reads the language too early (which made no sense, really, since all other extensions read it the same way) Not so. Here's the issue: I didn't notice that when I switched languages in MediaWiki, I did that through my own user preferences (since I was going frequently from English to Hebrew and back for testing). That meant that the *page* and global language was indeed English, and so VE read the global/page language *correctly* as EN/LTR. So, while I was working in my own rtl preferences, VE corrected me by injecting LTR in there, and switching my marker to the left. When I changed the global settings of my wiki to hebrew, it all worked out perfectly again, and all is well. So now a question for you guys -- this seems to be a decent behavior (though maybe for the sake of users it may be nice to say it somewhere?) -- however, there *is* an option to read the user language instead of the global language in the VisualEditor.hooks.php page, by using the $context->getLanguage() method instead of the currently used $out->getTitle()->getPageLanguage() That would mean that the direction of the marker will be defined by the *user* defined language rather than by the page- or wiki-defined language direction. I can think of reasons this can be good, but I can also think of reasons this can be bad. I am not sure which is better. On one hand, the page probably defines the proper language, and the user language is mostly for the GUI, but on the other, if the user language is RTL, we usually expect the marker to follow suit. Whatever is decided, this will definitely affect any and all RTL buttons (direction changes for paragraphs/page/etc) and the marker movement (whose bug I was going to look at next. Should it stay with page language, or switch to user language when deciding marker direction in VE?
(In reply to comment #1) > Okay, I figured out the problem, but this isn't precisely a bug and it > depends > on what you want the behavior to be. > > First off, the issue seemed to be that the definition of the page language > was > always LTR in VE, regardless of what language I was using. Even when my page > was Hebrew/RTL, VE's config showed it as english/ltr. That was quite > frustrating, I was starting to think the problem is that the hooks page reads > the language too early (which made no sense, really, since all other > extensions > read it the same way) > > Not so. Here's the issue: > > I didn't notice that when I switched languages in MediaWiki, I did that > through > my own user preferences (since I was going frequently from English to Hebrew > and back for testing). That meant that the *page* and global language was > indeed English, and so VE read the global/page language *correctly* as > EN/LTR. > > So, while I was working in my own rtl preferences, VE corrected me by > injecting > LTR in there, and switching my marker to the left. > > When I changed the global settings of my wiki to hebrew, it all worked out > perfectly again, and all is well. > > So now a question for you guys -- this seems to be a decent behavior (though > maybe for the sake of users it may be nice to say it somewhere?) -- however, > there *is* an option to read the user language instead of the global language > in the VisualEditor.hooks.php page, by using the $context->getLanguage() > method > instead of the currently used $out->getTitle()->getPageLanguage() > > That would mean that the direction of the marker will be defined by the > *user* > defined language rather than by the page- or wiki-defined language > direction. > > I can think of reasons this can be good, but I can also think of reasons this > can be bad. I am not sure which is better. On one hand, the page probably > defines the proper language, and the user language is mostly for the GUI, but > on the other, if the user language is RTL, we usually expect the marker to > follow suit. > > Whatever is decided, this will definitely affect any and all RTL buttons > (direction changes for paragraphs/page/etc) and the marker movement (whose > bug > I was going to look at next. > > Should it stay with page language, or switch to user language when deciding > marker direction in VE? I think that the behaviour is as intended - language of content is a wiki-level not user-level decision. This means that if your interface is in RTL but the content is LTR (or vice versa) the buttons need to work in the content context, not the user language, yes. Do they currently not?
As agreed.
