VisualEditor/RTL support, GSoC 2013/Project Updates

Below are continuous updates regarding the project progress.

Before June 17th
So far I have concentrated on:
 * Familiarizing myself with VisualEditor codebase and style
 * Submitting several bug fixes related to RTL work in VisualEditor
 * Setting up the system with Linux VM, git/gerrit, MediaWiki installation on both Windows and Linux environments and other tools
 * Making a preliminary plan of how to approach the project in practical terms with Inez, James and Amir.
 * The decision is that it's best to start with a Language Inspector (general, regardless of RTL) to serve as a base for the RTL-related support.
 * The language inspector will also serve as some base for conventions, trying to make the use of language tags across wikis more or less conventional. That is anticipated to be one of the primary challenges, especially in terms of reading pages and recognizing existing language tags.
 * I have also started reviewing pages in the Hebrew Wikipedia to try and get a better user experience myself and encounter and deal with the challenges first-hand.

Challenges

 * (PROBLEM SOLVED) I am having a problem installing Parsoid on my system; I've been working without Parsoid so far without reading or saving the pages. I'm not sure what is the problem in my Linux VM but I am trying to solve with with the help of the Parsoid team.
 * Update: I solved the problem with Amir's help with reinstalling nodejs. All systems are a go!

June 17th
This week's goals will be the fixing of two urgent bugs in VE RTL support: I've started the bug fix process, and so far, progress looks good:
 * Bug 49416 - VisualEditor: Link inspector surface doesn't pop up when the user language is right-to-left
 * VisualEditor: {Ctrl,Option}+{Delete,Backspace} doesn't delete a word in an RTL wiki

Bug 48912 (handleDelete)
Inez has recently redesigned the code of the 'handleDelete' method. When I tested the issue in my local installation, the Ctrl+Delete and Ctrl+Backspace work as intended. They do not work as intended on the hebrew Wikipedia, which may mean this is due to his recent changes.

I'm waiting for confirmation that the behavior is as expected on another local (and updated) installation of an RTL wiki in the current version before we can declare this bug fixed.

Bug 49416 (Link Inspector)
I went over this bug carefully and I believe I found the issue. On activation of the link surface, VE calculates the absolute position of the link inspector and writes them to the element style property as "left: xx; top: yy". However, in RTL wikis, the html tag includes a "dir='rtl'" property that switches the entire window the other way around. This results in throwing the surface popup outside view.

I corrected these issues in the code and submitted a bug. However, I ran into a problem with the sub-popup (the link suggestions) - the calculations for where it should appear turn out to be slightly more elaborate than I initially thought, and I am hoping to work this out in the next few days.



Update (6/19)
I have settled the issue by adding a small correction factor in the right property of the suggestion popup to correct the position. I am not sure it's the most beautiful way to fix it, but the alternative may involve redoing some of the back-end property reading for the surface, which may not be necessary.

You can see how the position is viewed without the manual 20px fix in the image on the left.

Bug 49613 (Page Setting Dialog)
I've taken the fixing of this bug as well, and I believe I fixed the issue. The main problem was inheritance of directionality inside iframes. Since iframes read entirely new html documents, they don't include the usual "class=rtl" or directionality pages inside MediaWiki do. I have added a directionality property to the Frame object that's updated on every Load (so each frame, theoretically, can have its own directionality based on its parent).

Then, I've added a rearrangement process to the Grid view, so the left panel appears on the right and vise versa when the language is RTL.

June 24th
Working on the RTL/LTR bug fixes has so far been incredibly satisfying, and included some interested challenges. I've published a blog post regarding some of those challenges on my site: The Issues of Coordinate Systems (or: Mirroring XY, Oh My!)

Bug Statuses
I'm waiting for review on the bug fixes from last week. Bug 49613 (Page Settings Dialog) has expanded to include RTL fixes for frames, grid views and icon labels. I have also corrected the issue about the 20px repositioning in the link inspector popup (the solution is detailed in the above blog post.)

Language Inspector Prototype
As I work on the two bugs (and fix according to the reviews) I've also began planning the Language Inspector. That would serve as a language popup (similar to the 'link' popup in VisualEditor) that would allow the user to define a certain word or piece of the text as a certain language. The initial stages would define lang properties only, but the plan is to add directionality for RTL language in the future as well.

I've created a planning page for the Language Inspector, as I go over the code. There's a huge difference between fixing up existing code and creating a new one; I'm trying to go by the example of the Link annotation.
 * You can see the planning page here, I will update it as I go.
 * Also, the prototype code will be updated in this gerrit branch: https://gerrit.wikimedia.org/r/#/c/70560/

Update (6/28)
I've started taking a look at the jquery ULS - the idea is to utilize it as the core of the Language Inspector and updated the prototype code accordingly.

I'm currently stuck on an issue related to the fragment selection and data that's behind the inspector.

July 1st
Work on the Language Inspector Prototype is going full force, while awaiting review on the other complete bug fixes.

After the deployment of VE last week, Bug 49416 (RTL fix for the link inspector) seems to have been fixed without the need of my corrections. I'm going to research what exactly fixed it and see if there may still be need to the ve.ce.getRTLPosition method I have added as part of the fix for future use.

I am a bit stuck on a rather weird and unexpected behavior in the Language Inspector Prototype, probably resulting from some collision between the language annotation (that is made up of tags with dir/lang attributes) and the textStyle/span annotations that look for general. I am not entirely sure what the problems are, but I've outlined the problem, my tests, analyses and hypotheses in the Language Inspector Prototype notes page. I hope to try and get these solved as soon as possible so I can continue to work on the core and combine jQuery ULS into the inspector gui.

July 4th
This week the VisualEditor crew has launched the product officially as default in Wikipedia, and started work on refactoring the code. The plan is to split the core of VisualEditor from the MediaWiki-specific components and plan for future (future-future) plugin development. I had to wait with code adjustments and fixes as these changes were made. However, that meant my focus could go to translation which is another essential part of the language support.

I've finished translating the VisualEditor FAQ page in Hebrew, and I'm in the process of translating the VisualEditor User Guide in Hebrew.

Bug Statuses
My frame direction fix was merged; I've also noticed a secondary bug regarding the [edit|edit source links in RTL], which was also fixed and merged. I've also submitted a bug fix for layout correction in RTL for the link surface.

Language Inspector
So while last week I solved the issue that got me stuck (with Inez and Amir's help) this week the refactoring changed the way the code works, and I had to redo some of it. Overall the process is good since it will allow for a lot more flexibility in the long run, but I had to get back into a new code structure.

For the moment, the Language annotation collides with the textStyle/span annotations. The system only recognizes Language annotations if the textStyle/span annotation is commented out, despite the fact I have added a designated "matchFunction" to the Language annotation -- which is supposed to be tested on a higher priority than the "matchTagNames" that textStyle/span uses. Inez believes there may be a small bug in the core that ignores this prioritization, but for the moment I am working on the Inspector with the textStyle/span annotation commented out, hoping it won't break too many of the features while I work the kinks out.

Oh, and -- Happy Fourth of July!