Wikimedia Blog/Drafts/Parsoid: How Wikipedia catches up with the web

es

Traducción de: https://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with-the-web/

Parsoid: Poniendo Wikipedia al día con la web

Sintaxist Wiki, como un editor de Wikipedia lo ha escrito (arriba), y el resultado al cargar el HTML que el lector puede ver en su navegador (abajo)

Cuando la primera wiki vió la luz en 1995, la sintaxis HTML se simplificó de una forma revolucionaria, su inventor Ward Cunningham eligió el nombre debido a que en hawaiano esta palabra quiere decir “rápido”. Cuando Wikipedia se lanzó el 2001, su éxito se debió a la fácil colaboración que permite la utilización de wiki. En aquel entonces, la simplicidad de la sintaxis wiki hizo que fuera posible comenzar a escribir Wikipedia con Netscape 4.7 cuando la edición de WYSIWYG era tecnicamente imposible. Un script PHP relativamente sencillo convertía el formato wiki a HTML. Desde entonces, el formato wiki siempre ha proporcionado tanto la interface de edición como el almacenamiento en el formato MediaWiki, el software subyacente de Wikipedia.

Cerca de 12 años despues, Wikipedia contiene 25 millones de artículos enciclopédicos escritos en formato wiki, pero el mundo a su alrededor ha cambiado un poco. El formato wiki hace que sea muy difícil implementar la edición visual, que en la actualidad es compatible en navegadores para documentos HTML, y esperada por los usuarios de otros sitios web familiarizados con la edición visual. Además, ésto se ha convertido en un problema de velocidad: Con varias caracterísitcas nuevas, la conversión del formato wiki a HTML puede ser demasiado lenta. Para las páginas más grandes de Wikipedia, puede demorar al rededor de 40 segundos cargar una nueva versión luego de guardar una edición.

El proyecto Parsoid de la Fundación Wikimedia está trabajando en resolver estos problemas complementando el texto wiki existente con una versión equivalente de su contenido en HTML5 . En el corto plazo, esta representación HTML nos permitirá utilizar la tecnología HTML para la edición visual. A largo plazo, utilizar HTML como formato de almacenamiento puede eliminar la sobrecarga de conversión cuando se cargan las páginas, y además permitir actualizaciones más eficientes luego de editar, de manera que sólo se afecta parte de la página. Todo esto suena bastante sencillo; entonces, ¿porqué no se ha hecho antes?

Conversión sin pérdida entre formato Wiki y HTML es en verdad difícil

Para que el formato wiki y su representación HTML5 sean considerados equivalentes, debe ser posible realizar conversiones entre ambos formatos sin introducir ninguna diferencia semántica. Esto resulta en que la estructura ad-hoc del texto wiki hace que una conversión sin pérdida a HTML y viceversa sea extremadamente difícil.

• Análisis sensitivo contextual: La única especificación completa de la sintaxis y semántica del texto wiki es la implementación en tiempo de ejecución de MediaWiki basado en PHP en sí misma, ......

which is still heavily based on regular expression driven text transformation. The multi-pass structure of this transformation combined with complex heuristics for constructs like italic and bold formatting make it impossible to use standard parser techniques based on context-free grammars to parse Wikitext.

Text-based templating: MediaWiki’s PHP runtime supports an elaborate text-based preprocessor and template system. This works very similar to a macro processor in C or C++, and creates very similar issues. As an example, there is no guarantee that the expansion of a template will parse to a self-contained DOM structure. In fact, there are many templates that only produce a table start tag (

), a table row (...) or a table end tag (

). They can even only produce the first half of an HTML tag or Wikitext element (e.g. ...</tabl), which is practically impossible to represent in HTML. Despite all this, content generated by an expanded template (or multiple templates) needs to be clearly identified in the HTML DOM.

• No invalid Wikitext: Every possible Wikitext input has to be rendered as valid HTML – it is not possible to reject a user’s edit with a “syntax error” message. Many attempts to create an alternative parser for MediaWiki have tried to simplify the problem by declaring some inputs invalid, or modifying the syntax, but at Wikimedia we need to support the existing corpus created by our users over more than a decade. Wiki constructs and HTML tags can be freely mixed in a tag soup, which still needs to be converted to a DOM tree that ideally resembles the user’s intention. The behavior for rare edge cases is often more accident than design. Reproducing the behavior for all edge cases is not feasible nor always desirable. We use automated round-trip testing on 100,000 Wikipedia articles, unit test cases and statistics on Wikipedia dumps to help us identify the common cases we need to support.

• Character-based diffs: MediaWiki uses a character-based diff interface to show the changes between the Wikitext of two versions of a wiki page. Any character difference introduced by a round-trip from Wikitext to HTML and back would show up as a dirty diff, which would annoy editors and make it hard to find the actual changes. This means that the conversion needs to preserve not just the semantics of the content, but also the syntax of unmodified content character-by-character. Put differently, since Wikitext-to-HTML is a many-to-one mapping where different snippets of Wikitext all result in the same HTML rendering (Example: The excess space in “* list” versus “*list” is ignored), a reverse conversion would effectively normalize Wikitext syntax. However, character-based diffs forces the Wikitext-to-HTML mapping to be treated as a one-to-one mapping. We use a combination of complementary techniques to achieve clean diffs:

• we detect changes to the HTML5 DOM structure and use a corresponding substring of the source Wikitext when serializing an unmodified DOM part (selective serialization), see below.
• we record variations from some normalized syntax in hidden round-trip data (example: excess spaces, variants of table-cell Wikitext).
• we collect and record information about ill-formed HTML that is auto-corrected while building the DOM tree (example: auto-closed inline tags in block context).