Page MenuHomePhabricator

VisualEditor: Content is LTR even when the page language is RTL
Closed, DeclinedPublic

Description

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.


Version: unspecified
Severity: normal
OS: Linux

Details

Reference
bz48765

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:27 AM
bzimport set Reference to bz48765.

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?