Parsing/Replacing Tidy/FAQ/es

¿Qué es Tidy?
Tidy («ordenado» en inglés) es una biblioteca que MediaWiki utiliza para arreglar algunos errores que se encuentran en páginas wiki. Es común que las páginas wiki tengan marcado mal formado cuando los editores emplean etiquetas HTML en plantillas y en la propia página. (Por ejemplo, son comunes las etiquetas HTML no cerradas, como un  sin un  .) En algunos casos, es el propio MediaWiki el que genera HTML erróneo. Tidy arregla estos errores de marcado, pero también realiza otras tareas de «limpieza» que no son necesarias para que el código sea correcto. Por ejemplo, elimina elementos vacíos y añade espacios en blanco entre etiquetas HTML que a veces pueden cambiar la presentación. Como Tidy se basa en la semántica de HTML4 y la web ha migrado a HTML5, también hace algunas modificaciones incorrectas para «arreglar» cosas que no solían funcionar; por ejemplo, Tidy podrá sacar una lista con viñetas de una tabla a pesar de que es HTML válido.

¿Por qué se está reemplazando? ¿Y con qué?
La tecnología de Tidy data de los años 90, cuando los navegadores web no estaban estandarizados. El comportamiento de Tidy se basa más o menos en la semántica de HTML4, pero no coincide con el de ningún navegador actual. Tras años sin mantenimiento activo, se ha revivido Tidy como «tidy-html5», con un comportamiento muy diferente. Ya no se empaqueta el Tidy antiguo. Como se ha dicho antes, Tidy realiza tareas de limpieza HTML no relacionadas con la corrección de errores. Todos estos asuntos han conllevado que se registraran muchas incidencias en Phabricator, y se ha reclamado la sustitución de la herramienta al menos desde 2013. En la actualidad, HTML5 es el estándar web, y el algoritmo de análisis de HTML5 tiene las especificaciones claramente definidas, lo que ha supuesto el desarrollo de implementaciones compatibles para distintos navegadores y otras bibliotecas. Este algoritmo también especifica claramente de qué manera se debe arreglar el marcado roto. En este panorama tecnológico, es necesario de verdad reemplazar Tidy con un analizador HTML5 que arregle el marcado roto y genere marcado HTML válido y bien formado de la manera estándar. Sin embargo, los wikis de Wikimedia cuentan con un enorme corpus de páginas cuyo marcado depende de las correcciones de Tidy. Reemplazar directamente Tidy sin más dilación no es factible, ya que una herramienta basada en HTML5 repararía parte del marcado de otra manera y eso podría estropear la presentación de las páginas. Así, estamos reemplazando Tidy con nuestra propia herramienta basada en la especificación de HTML5, pero que también añade algo de retrocompatibilidad para minimizar su impacto. Tras experimentar con tres soluciones diferentes, nos hemos decidido por RemexHTML, un analizador HTML5 basado en PHP sobre el cual hemos programado algunas condiciones de retrocompatibilidad para replicar cierto comportamiento de Tidy que necesitamos proporcionar de momento. En el futuro, también se podría utilizar RemexHTML para habilitar nuevas características en el núcleo de MediaWiki, como una edición más robusta de secciones de páginas, un soporte más equilibrado de plantillas y una actualización más eficiente de páginas una vez se han editado las plantillas que contienen. Para quienes se lo estén preguntando, nótese que utilizar tidy-html5 no nos eximiría de tener que ocuparnos con la corrección de errores de marcado, ya que parte de la limpieza requerida se debe al cambio de la semántica de HTML4 a la de HTML5. Hay otros motivos relacionados con la gestión de cambios para preferir una herramienta propia, incluyendo la posibilidad de habilitar otras características como se ha mencionado anteriormente.

Si tienes interés en saber más desde el punto de vista técnico, puedes consultar https://phabricator.wikimedia.org/T89331 o Reemplazar Tidy.

¿Cuántas pruebas habéis realizado hasta ahora?
Con el fin de identificar el impacto de reemplazar Tidy con una herramienta basada en HTML5, hemos recurrido a una estrategia basada en pruebas (mediante una herramienta llamada «VisualDiff») que compara, píxel por píxel, la imagen resultante de MediaWiki con Tidy habilitado con la imagen resultante con su sustitución. Ya al principio, hallamos que una diferencia habitual consistía en cambios menores de espaciado vertical. Desde la creencia de que estos cambios serían imperceptibles o bien tolerables, creamos una herramienta llamada «UprightDiff», capaz de identificar desplazamientos verticales dentro de una imagen y descontar dichos desplazamientos para las pruebas automatizadas. Esto también nos ha permitido asignar un valor numérico a las diferencias e identificar rápidamente las más notorias. Exportamos un subconjunto de unos 64 000 artículos (algunos del flujo de cambios recientes, los demás escogidos aleatoriamente) de varios wikis de Wikimedia (40 wikis entre Wikipedia, Wikisource, Wikcionario y Wikiviajes), los visualizamos con Tidy y con RemexHTML y utilizamos «UprightDiff» para analizar el resultado. Esto requiere muchos ciclos de procesador, memoria y espacio de disco, y hacen falta 2 días para completar una ronda de pruebas. Esto limita el tamaño del corpus utilizado para las pruebas, pero creemos que 64 000 es una muestra suficiente para averiguar qué tipo de correcciones necesitamos.

Para minimizar las diferencias y reducir el impacto de las correcciones que serían necesarias para los editores, añadimos algunas correcciones de compatibilidad con Tidy. Como hallamos que las etiquetas autocerradas eran extremadamente comunes en los wikis de Wikimedia, añadimos una corrección de compatibilidad para tratarlas como etiquetas vacías (por ejemplo, tratar  como  ). Añadimos asimismo algunas correcciones más de compatibilidad. Tras establecer todas estas correcciones y repetir las pruebas, hallamos que en el 93,4% de las páginas no hubo cambios en la presentación. Además, en el 96,9% de las páginas, o bien no hubo diferencias de píxeles (93,4%) o bien solamente diferencias insignificantes de espaciado vertical (3,5% = 96,9 - 93,4). El 3,1% restante (100 - 96,9) presentó diferencias de píxeles debidas a otros motivos.

Basándonos en estas pruebas, identificamos varias clases de errores de marcado que se visualizarán de forma diferente con las dos herramientas. Para una clase de errores de marcado (etiquetas autocerradas que no son válidas en HTML5), añadimos una categoría de mantenimiento que los editores ya han estado utilizando para arreglar plantillas y páginas. Sin embargo, las demás clases de errores de marcado no son fáciles de detectar automáticamente a fecha de hoy, y es necesaria la asistencia de los editores para identificarlas y arreglarlas.

¿Qué va a pasar? ¿Cuándo se producirán estos cambios?
Como se ha dicho antes, aún no podemos hacer un reemplazo puntual de Tidy por una herramienta basada en HTML5. Hemos añadido una categoría de mantenimiento para una clase de errores de marcado que ayudará a los editores a arreglarlos. Para ayudar a los editores a identificar y arreglar otros errores de marcado, también hemos construido una extensión ParserMigration (MigraciónDeAnalizador) que les ayudará a comparar la presentación en producción y arreglar errores de marcado. Por otra parte, hemos creado la Linter para identificar algunas de las correcciones necesarias.

A fecha de marzo de 2017, hemos desplegado las extensiones ParserMigration en todos los wikis. A 20 de junio de 2017, Linter está desplegado en todos los wikis de gran tamaño. Mediante estas extensiones, esperamos que los editores puedan arreglar las páginas para poder reemplazar efectivamente Tidy en 2017. Una vez se hayan hecho suficientes correcciones y estemos convencidos de que el impacto que tenga la migración en los editores y lectores será menor y tolerable, reemplazaremos efectivamente Tidy. De todas formas, no nos gustaría tener que alargar esto indefinidamente. Sería, pues, ideal si los editores priorizasen los problemas identificados por la extensión Linter como de alta prioridad.

Por otra parte, las correcciones de compatibilidad con Tidy (mencionadas en la sección anterior) están pensadas para seguir en pie hasta que reemplacemos Tidy. Después de esto, empezaremos a reemplazar gradualmente estas correcciones apoyándonos en pruebas y herramientas similares.

¿Qué tendrán que hacer los editores?
La extensión Linter está desplegada en todos los wikis. Como se indica en la página de ayuda, te invitamos a arreglar los patrones de wikitexto y las plantillas identificadas en las Help:Extension:Linter/es en la página Especial:Errores_de_sintaxis (Special:LintErrors) de tu wiki. Todo elemento de esta categoría tiene una página de ayuda con ejemplos que ilustran qué hace falta arreglar. A continuación se muestran unas instrucciones simplificadas.

To assist editors in migrating wikitext to verify the fixes they make, we have deployed the ParserMigration extension. If you enable "ParserMigration" in your preferences, a link will be added to the toolbox of all articles, which can show the current (Tidy) and expected (RemexHTML) output side-by-side. You can preview article text changes in the same side-by-side view and see how your edits changes / fixes rendering.

What is the impact on my wiki?
Please see the wikitext deprecation tool for this information. Note that in several cases the count refers to pages affected, but that includes template-generated issues. In other words, once a given template is fixed, all the pages featuring that template will disappear from the list. So it's highly likely that you won't have to fix thousands or millions pages, but a handful of templates. We are working to make this even more clear. You can also see some progress on Parsing/Replacing Tidy/Linter/Stats/July31, and the results of visual differences tests on a sample of ~73K articles from 60 wikis at http://mw-expt-tests.wmflabs.org/.

Simplified instructions for fixing pages
Here are some simplified instructions for handling all the high-priority linter categories. Some of the linked help pages may contain instructions to use assisting tools such as WPCleaner.

Delete OR fix badly nested tables
In this example, Tidy will delete Table 2 above. But, RemexHTML will not delete that table. This can change how pages look. To prevent this, editors should fix the wikitext and remove Table 2. While the following row-tag need not be removed, we recommend removing it. Since the closing table tag is no longer needed, it should be removed as well.

Alternatively, add an explicit  cell on the row started by the previous line before the start of Table 2 if you need nested tables. What is the correct fix depends on the page. But, in most cases deletion as above is going to be the right fix.


 * Help:Extension:Linter/deletable-table-tag

Work around a parser bug for paragraph wrapping
On most wikis, it looks like the biggest generator of these linter warnings are the nowrap or nowrap begin templates. The simplest fix that will handle the vast majority of these linter cases is to add a newline before the opening &lt;span&gt; tag in the template source of these templates.

In all other cases, when wikitext has a span next to a div/td (and other such "block" tags) and has a  CSS property, please add a newline after the div tag.


 * Help:Extension:Linter/pwrap-bug-workaround

Fix invalid self-closing tags
Self-closing tags like &lt;div/>, &lt;span/>, &lt;b/>, etc are not valid in HTML5. They need to be fixed according to what the editor intent might have been. In some cases, it is a typo where a &lt;/b> is intended. In other cases, they need to be deleted. In some other cases, they need to be replaced with a &lt;nowiki/>. Please see the detailed help page for this category.


 * Help:Extension:Linter/self-closed-tag

Caveats

 * We don't yet know how to automatically determine all affected pages and templates, but we expect that the list of templates and suggestions will get more complete as we learn about problems that were not caught before. Community Liaisons will reach out to template experts, regulars at technical village pumps, etc. to make sure they become aware of the necessary changes and of resources that may help them.
 * We are thinking about other easy, sustainable ways in which we may support "gnomes" and all the Wikimedians willing to help with this effort.

Other FAQs
Q: What happens to  and similar tags if they are used in self-closed form?

A: As noted in T134423, the only valid self-closed HTML tags are:,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,. Non-HTML self-closing tags (like  and  ) are not affected by this change. is a special case because while it is a HTML tag, MediaWiki treats it like an extension tag and hence remains unaffected. All other self-closing HTML tags should be fixed (and are already being fixed by editors at this time).

Since this usage is found in a lot of pages in our testing, in order to prevent unexpected rendering effects (e.g.  being treated as    and causing more text being bolded than intended), we added a fix to the parser to convert them to an empty tag (eg.   will be converted to  ). But, we don't intend to retain this fix indefinitely. So, we would like for editors to continue fixing this deprecated usage.

Q: What were the results of tests on languages other than English, or on sister projects?

A: There is nothing in what Tidy, RemexHTML do that is specific to Wikipedia or English. This project is primarily about a change from HTML4 to HTML5 semantics and getting rid of some Tidy cleanups of HTML. These changes affects all projects and languages equally, except if some projects and languages tend to have more markup errors or use more self-closed tags than others.

Q: What other changes are editors likely to see, after this replacement?

A: The effect of this replacement is primarily going to affect readers, as they may notice that the page doesn't look right (for example, excessively wide navboxes without line breaks or wrapping). However, if anything, this might lead to the rendering seen in VisualEditor to match the rendering seen outside it much more than before, since Parsoid's output has been HTML5-compliant since the beginning, and we are now moving the read output to HTML5. We do not expect any impact on VisualEditor edits, but we will promptly address any bugs reported with respect to dirty diffs. In addition, we do not plan to add any error messages or warnings displayed on pages if the markup errors are not fixed.

Q: How does the replacement relate to other projects you are working on?

A: By enabling the move to HTML5 semantics, this is one of the steps evolving markup in our corpus to keep up with web standard. We also expect to leverage this tool to support well-balanced template output. Separately, but relatedly, this will also make the output of the PHP parser (used for reads) and the output of Parsoid (used for edits in VE, Content Translation) more consistent since Parsoid already uses HTML5 semantics. One of our goals is to make the two outputs fully consistent with each other and use one parser for both reads and edits.

--The Parsing Team

Volunteers available to support this effort
''Community Liaisons invite interested Wikimedians to please add their name in the sections below and support their community engagement efforts. Thank you. As with similar past initiatives, signing up is optional.'' Please see Parsing/Get_involved, and add it to your bookmarks, as future requests for assistance will go through that page!
 * 1) Estoy disponible para hacer pruebas con la herramienta ParserMigration.
 * 2) (añade tu firma aquí)
 * 3) Estoy disponible para arreglar plantillas.
 * 4) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 5) Samuele2002 (talk)
 * 6) TheDragonFire (talk)
 * 7) Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 8) Estoy disponible para estudiar y discutir sobre correcciones para las plantillas.
 * 9) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 10) Estoy disponible para difundir la información a mi comunidad.
 * 11) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 12) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 1) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 2) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)