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!

July 8th
''I started typing and writing this update, and then my VM crashed. It took me a bit to get over the loss of what I wrote, so I apologize for the lateness of this update.''

Quite a lot of good news happened, and many updates.

Language Inspector
IT WORKS! Well, almost completely. The Language Inspector recognizes existing language annotations, marks them, and creates new ones. There's a working icon in the toolbar and a widget that pops up when an annotation is edited. And, more importantly, ULS is activated (as expected) when language needs to be changed.

The problem of colliding with the textStyle/span annotation was fixed by Inez's observation about my code. Now it works brilliantly, and I hope that with a couple of tweaks at least the ce/dm piece will be ready.

Git & Tech
So, the Language Inspector prototype became rather large with almost 30 patchsets; I've split the branch up to two - the ce/dm piece (which is almost ready to be merged) and the UI piece which I can continue work on. This would make work easier, and allow for at least some of the features to be merged in the master code.

Bugs Bugs Bugs
I've found a couple of extra RTL-related bugs and submitted them to bugzilla, but the main focus this week was (and probably will remain) the Language Inspector. One notable exception is a CSS fix that Roan and Trevor are busy implementing. This would make many of my previous "quick fix" css changes obsolete, because it will finally allow CSSJanus to act inside iFrames. Beyond the fact this is a pretty cool code fix, it was also the first time I am asked to review someone else's code. It might be silly, but I was rather honored.

July 15th
The Language Inspector was transformed from an input-driven widget to a display widget, which will likely remain its incarnation in the prototype stage. The widget shows language information (language name, direction, and language code) and a button to switch language that opens up the ULS interface.

The prototype works fairly well, with minor bugs that are currently being worked on, namely a slight problem in recognizing the "base" language when new language block is set up (which should be based on the wiki/system language initially) and a couple of extra features, like how to deal with a span that contains "dir" property without a language specified.

We are starting to consider how to handle paragraph-level language and directionality settings, both in terms of user functionality planning and in terms of the technical method to reach the goal.

The plan at the moment is to fix up the code so it serves as a working prototype that can be merged -- in "experimental mode" for the moment -- into the VisualEditor core. We will continue with the rest of the improvements as we go.

July 18th
The Language Inspector prototype is ready for final review stages. We're now working on the next steps, where we will try to plan on how to add functionality beyond inner text (span) and move to changing direction and language of other elements, like paragraphs and lists.

July 22nd
The Language Inspector prototype is awaiting review and (hopefully soon) a merge. Alongside it, there were a couple of bugs that were also fixed:
 * Bug 51819 - VisualEditor: Location of the inspector menu is wrong for floated content in RTL wikis

This bug raised the need to create an easy way to get the directionality of the GUI vs the content; most of the time the coordinates (rtl or ltr) are set by the GUI but in this case, the transclusion icon should appear above the infobox, whose float direction depends on the content and not GUI. So, on top of fixing the transclusion icon, I've added two "getDir" methods - one in the CE component (page direction) and the other in the UI component (for GUI direction).

The transclusion fix works, though we may want to re-examine the way the icon appears in general, since infoboxes and templates may also appear in the center or opposite side of the screen regardless of the content.
 * Bug 51490 - In RTL (hewiki and arwiki) wikis, can't remove categories and Bug 51828 - VisualEditor: Autocompletion for template names doesn't work in RTL

This was a fun one, actually, since it was an indication of a bigger problem. The popups were relatively easy to fix by flipping the coordinates -- but when I tried to fix the "suggestion" popup (the one that opens up when you start typing into the 'new category' input) then the same suggestion popup in the Link inspector got all screwey. Fix one, mess up the other, fix the other, mess up the one....

Eventually, it became clear that the difference between these two are their positioning inside surfaces. The category suggestion popup was inserted inside another frame (that is, a suggestion frame popped up inside the category dialog frame) but the link inspector suggestion was inserted into the general editor, outside the scope of a second frame. The "correction" for RTL coordinates was implemented only on frames-inside-frames popups. Yup, as I said, that was a fun one.