I feel somewhat responsible for putting James Forrester on the hot seat concerning [this article][Visual Editor post] as I was the one who asked him to take out time from his busy schedule to explain some of the challenges faced by the team concerning the project and manage expectations somewhat concerning the release.
I hope it is clear from the post that the [VisualEditor project] has to overcome many “firsts” to become a reality. Some of the ones mentioned include:
1. The criteria to support 290 languages is beyond the scope of support of existing software.
2. The VisualEditor UI needs to be programmable in such a manner that “free form” HTML editing cannot be permitted unless those edits can be synced with an internal, client-side “data model.”
3. The VisualEditor needs to leave room for extensibility in all fronts to adapt to the extensible nature of current WikiText capabilities like transclusions and templates.
4. A **two-way** representation needs to be created out of wikitext to HTML *back to wikitext*. This cannot be emphasized enough since before the [parsoid project], it was actually unclear if this was even possible.
5. In both the parser and in all points of the VisualEditor, edits must be made in a manner that only manipulates the areas intended by the editor so was to not introduce “dirty diffs”.
6. All of this must be done in a forward thinking transactional manner to allow things like real-time collaboration, micro-edits, and the ability to walk through actions.
[Visual Editor post]: http://blog.wikimedia.org/2012/12/07/inventing-as-we-go-building-a-visual-editor-for-mediawiki/ “Inventing as we go: building a visual editor for MediaWiki—Wikimedia”
[VisualEditor project]: http://www.mediawiki.org/wiki/VisualEditor “VisualEditor—MediaWiki”
[parsoid project]: http://www.mediawiki.org/wiki/Parsoid “Parsoid—MediaWiki”Continue reading