VisualEditor/RTL support, GSoC 2013/Project Updates
Below are continuous updates regarding the project progress.
Before June 17th
[edit]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
[edit]- (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
[edit]This week's goals will be the fixing of two urgent bugs in VE RTL support:
- 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
I've started the bug fix process, and so far, progress looks good:
Bug 48912 (handleDelete)
[edit]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)
[edit]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)
[edit]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)
[edit]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
[edit]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
[edit]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
[edit]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)
[edit]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
[edit]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 â<span> tags with dir/lang attributes) and the textStyle/span annotations that look for general â<spans>s. 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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]The Language Inspector prototype is awaiting review and (hopefully soon) a merge. Alongside it, there were a couple of bugs that were also fixed:
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.
July 29th
[edit]I've created a new TemplateData Generator extension, and we're now testing it in hopes of installing it on the Hebrew Wikipedia so RTL'ers can finally edit and generate templatedata json without typing it manually (which can be a real challenge). The extension can be found in GitHub for now.
The Language Inspector prototype was reviewed several times, and now awaits final review and merge, hopefully by the end of the week. I've started working on the second stage of the Language tool which will allow choosing languages and directions for paragraphs, lists and sections.
August 1st
[edit]Work is ongoing on the Language Block tool, which will add <div lang='xx' dir='ltr|rtl'> to blocks of wikitext in articles. Beyond that, I've been working on a TemplateData Generator extension, and got a lot of help from Krinkle. Both Krinkle and Roan suggested I test the new extension first as a gadget, which is now available in mediawiki.org; it's also made in such a way where I can use the same code for both the extension and the gadget as I update.
August 5th
[edit]Amir and Inez (and most of the VisualEditor team) are in Wikimania, and I am working on the code while they're away. The new TemplateData Generator extension is on GitHub and Krinkle helped me set it up with travis-ci and redesign its UI.
TemplateData Generator Extension / Gadget
[edit]The most crucial thing as far as the TemplateData Generator goes is to make sure it works well with RTL wikis and with RTL parameters, as these are incredibly difficult to edit as json strings inside an rtl textbox. For the moment, I'm awaiting some more testing, but it seems to be working well. Here are some screenshots of the extension at work on an Hebrew wiki (RTL):
August 12 - Wikimania Week
[edit]During Wikimania I've worked on finalizing the TemplateData extension and gadget and starting the creation of the LanguageBlock Inspector for the <div> functionality, but work has been somewhat slowed, as pretty much the entire team was in Hong Kong, having fun.
TemplateData Generator gadget is now also ported into the Hebrew Wikipedia, and I hope people start testing it out so we can eventually decide if it is good enough to make as a proper (and active) extension in this and other wikis. So far so good, but I also plan to announce the gadget in the Hebrew wiki and get RTL testers on it.
As far as the language block inspector is concerned, I have a couple of issues I am stuck with and must await the team's return from Wikimania.
August 15th
[edit]A couple of issues became evident when trying to create the new LanguageBlock inspector -- the first was that I should use the same widget that I have used for the annotation, for the node inspector as well -- <span> languages functionality and <div> languages functionality should use the same widget. However, the way that the widget was built in VE (based on the Link inspector) kept the annotation functionality inside the widget itself. In order to make the widget work for both the annotation (span) and node (div) I had to be creative.
The main issue, however, is that both LanguageInspector and LinkInspector rely on AnnotationInspector base functionality, and it, in turn, asks the widget for the value of the annotation. If I was to change the LanguageInspector widget, I had to change the AnnotationInspector -- and with that, I had to also edit the link inspector.
So I did.
The better idea in general is to have all the actual functionality (either annotation or node) outside the widget and in the inspector itself. The widget, for that matter, should be oblivious to what it's servicing. So, the change made sense, and I worked on rewriting the LanguageInputWidget (and the inspector(s)) in preparation to move the functionality into the inspector. That way, LanguageInspector will deal with spans, LanguageBlockInspector will deal with divs and the only thing LanguageInputWidget would do is read and preserve the attribute values (lang / dir) so the two other inspectors can read them and translate them into the relevant actions.
The (merged) change is available in gerrit.
August 19th
[edit]After figuring out the issue with the LanguageInputWidget and reorganizing it, adding the node functionality became a bit easier. I've split up the work to two dependent commits -- the ce/dm piece that defines the language block node, and the ui commit that defines the inspector, the toolbar button and the actual 'wrap' functionality. They mostly work with some minor problems that I'm working on right now.
The main next step is to find proper UI behavior, since we're basically inventing the wheel here. There is no other application (on or off line) that gives the same type of functionality to the user, so we have no real example to take from -- but this is also exciting, because we're making something new and potentially awesome.
We'll have to settle on a logical first-start and see how the users react to it, adjusting as we go.
Transclusion / Template inspector-popup position
[edit]This is a bug that's been bugging me (and other rtl'ers) for a while, and my first attempt to fix it (a couple of weeks ago) resulted in having to regress because of an unforseen complication (in other words, it created other bugs).
The issue is that the inspector popup button appears in the wrong side of the screen on RTL wikis; when I tried to fix it last time, I made a bigger mess, but this time, I tried a different approach - and it seemed to work, but the entire method that I added my fix to ('updateDimensions' in ve.ui.Context) was pretty unclear and patchy.
So, I took Trevor's advice and rewrote it, making it a lot cleaner and more logical. there are still a couple of issues with the embedded functionality that are a bit vague, but they're required because of the issues of floating content inside divs. Still, my new method places the inspector on top of the position of the node, rather than attach it to the corner (and have it flip in RTL, resulting in the wrong corner) The fix is now under review in gerrit.
August 25th - September 2nd
[edit]I've spent the week in San Francisco with the amazing VisualEditor team, and I've had an absolute blast! I've had the chance to get face-to-face lectures (whiteboards are great) about VisualEditor structure and inner works, and to work on my project and bug fixes. The week was great, and a lot was done code-wise, too.
Language Block Inspector
[edit]A couple of usability questions came up as I was working on the new language block inspector. Some of those are easily solved, some might require further discussion, but one thing was clear - there is a need to find a good visual way to represent the language blocks and the way to edit them inside VisualEditor. For that, we agreed that I will begin developing a "sticker"-like functionality where menu appears above the language nodes and lets the user edit its attributes or delete them.
I've started work on the "StickeredNode" (temporary name) as a mixin so it can also be used for other editable blocks.
TemplateData Generator
[edit]The gadget is now on the Hebrew wiki and being tested. I've added an "Import Parameters" button that takes parameters directly from templates, based on a tool developed by users in the Hebrew Wikipedia. Overall, the gadget (and the extension) seems to work, with minor problems I am dealing with now as we test.
I've found out that there may be an issue with TemplateData Generator and a local gadget in the Hebrew Wiki that was, initially, meant for similar functionality. I will contact the developers in hewiki to see what could be done about fixing the incompatibilities.