Análisis sintáctico/Sustitución de Tidy/Preguntas frecuentes
¿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.
Tidy is a library formerly used by MediaWiki to fix some HTML errors found in wiki pages.
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 <small> sin un </small>.) 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 phab: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 <b /> como <b></b>). 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 una sustitución 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 extensión 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 categorías de alta prioridad 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.
Hemos desplegado la extensión ParserMigration para ayudar a los editores a verificar sus correcciones en la migración de wikitexto. Si habilitas «ParserMigration» en tus preferencias, se añadirá un enlace a la caja de herramientas de todos los artículos que permitirá mostrar la salida actual (Tidy) y la esperada (RemexHTML), la una al lado de la otra. Podrás previsualizar los cambios en el texto del artículo en la misma vista en paralelo y ver de qué manera tus ediciones cambian o arreglan la presentación.
¿Cuál es el impacto en mi wiki?
Te invitamos a consultar la herramienta de obsolescencia del wikitexto para obtener esta información. Nótese que, en varios casos, el contador se refiere al número de páginas afectadas, pero que eso incluye problemas generados por plantillas. En otras palabras, una vez se haya arreglado una plantilla dada, todas las páginas que utilicen esa plantilla desaparecerán de la lista. Así, es muy probable que no tengas que arreglar miles o millones de páginas, sino un puñado de plantillas. [$phab Estamos trabajando para que esto quede aún más claro]. También puedes ver parte del progreso en Parsing/Replacing Tidy/Linter/Stats/July31, y los resultados de las pruebas de diferencias visuales en una muestra de alrededor de 73 000 artículos de 60 wikis en http://mw-expt-tests.wmflabs.org/ .
Instrucciones simplificadas para arreglar páginas
Aquí mostramos una serie de instrucciones simplificadas para abordar todas las categorías de Linter de prioridad alta. Algunas de las páginas de ayuda que se enlazan pueden contener instrucciones para utilizar herramientas tales como WPCleaner.
Eliminar o arreglar tablas mal anidadas
{| <-- Table 1 starts here
| foo
|-
{| <-- Table 2 starts here. You can remove this code.
|- <-- Row for Table 2. You may remove this too if you wish so.
| bar
|} <-- this closing tag is now useless and should be removed too
|}
En este ejemplo, Tidy borrará la tabla 2. Sin embargo, RemexHTML no la borrará. Esto puede cambiar la presentación de las páginas. Para evitarlo, los editores deberían arreglar el wikitexto y retirar la tabla 2. Aunque la etiqueta de nueva fila no necesita borrarse, recomendamos hacerlo de todas formas. Como la etiqueta de cierre de tabla ya no es necesaria, también debería borrarse.
Como alternativa, si necesitas utilizar tablas anidadas, añadir explícitamente una celda | en la fila que empieza por la línea anterior al comienzo de la tabla 2. El cambio correcto dependerá de la página, pero, en la mayoría de los casos, el borrado descrito anteriormente será la solución correcta.
Solució para corregir un error del analizador en el paquete de párrafos
En la mayoría de los wikis, parece que el mayor generador de estos errores de sintaxis son las plantillas nowrap o nowrap begin. La corrección más sencilla es añadir una nueva línea antes de la etiqueta <span> de apertura en el código fuente de estas plantillas.
En todos los demás casos, cuando el wikitexto contenga un span al lado de un div o un td (y otras plantillas similares de bloque) y tenga una propiedad CSS white-space:nowrap, añade una nueva línea después de la etiqueta div.
<div><span style='white-space:nowrap'> <!-- <== ADD NEWLINE AFTER THE <div>. -->
foo bar
</span>
</div>
- Note that this has the effect of enclosing the whole span in a paragraph element. Here the bug comes from newlines within the div element that cause a new paragraph to be generated for "foo".
- The alternative, if you don't want a paragraph element automatically inserted (with its additional margins) by MediaWiki to surrounding the "span" inside the "div", is to not use any newline at all in the content of the "div" element, or to "hide" these newlines within HTML comments:
<div><span style='white-space:nowrap'>foo bar</span></div>
<div><!--
--><span style='white-space:nowrap'><!--
-->foo bar<!--
--></span><!--
--></div>
Arreglar etiquetas autocerradas no válidas
Las etiquetas autocerradas tales como <div/>, <span/>, <b/>, etc. no son válidas en HTML5. Deben arreglarse en función de la intención del editor. En algunos casos, se trata de un error tipográfico donde la intención era poner </b>. En otros casos, deben que borrarse. En algunos casos más, deben reemplazarse por un <nowiki/>. Por favor, consulta la página de ayuda detallada para esta categoría.
They need to be fixed according to what the editor intent might have been. In some cases, it is a typo where a </b> is intended. In other cases, they need to be deleted. In some other cases, they need to be replaced with a <nowiki />. Please see the detailed help page for this category.
Fix pages affected by a Tidy whitespace bug
| Input wikitext | Tidy output | Remex output | Proposed wikitext fix |
|---|---|---|---|
<span class='nowrap'>a </span><span class='nowrap'>b</span>
|
<span class='nowrap'>a</span> <span class='nowrap'>b</span>
|
<span class='nowrap'>a </span><span class='nowrap'>b</span>
|
<span class='nowrap'>a</span> <span class='nowrap'>b</span>
|
Fix HTML5 vs Tidy misnested tag problems
Here is an example to illustrate the problem.
| Input wikitext | Tidy output | Remex output | Proposed wikitext fix |
|---|---|---|---|
<span>a
b</span>
|
<p><span>a</span></p>
<p><span>b</span></p>
|
<p><span>a</span></p>
<p>b</p>
|
<span>a</span>
<span>b</span>
|
That was just one example to demonstrate the problem. There are other instances - ''foo<sup>''bar</sup> (an enwiki talk page) or <span>\n*x</span> (many itwiki pages via the use of citazione necessaria template) are other instances.
font tag with color attribute wrapping wikilinks
Here is an example to illustrate the problem.
| Wikitext | Tidy | Remex | Proposed Fix |
|---|---|---|---|
<font color="green">[[Foo]]</font>
|
<a href=".."><font color="green">Foo</font></a>
|
<font color="green"><a href="..">Foo</a></font>
|
[[Foo|<font color="green">Foo</font>]] or better yet, [[Foo|<span style="color:green;">Foo</span>]].
|
NOTE: Only a small set of font tags used on wikis are affected as explained above. All other uses don't need to be fixed. See the help page below for more details.
Multiple unclosed formatting tags
| Wikitext | Proposed Fix |
|---|---|
<s>foo<s> bar
|
<s>foo</s> bar
|
Multi-line HTML table in lists
| Wikitext | Tidy | RemexHTML | Proposed Fix |
|---|---|---|---|
* <table>
<tr><td>foo</td></tr>
</table>
bar
|
<table>
<tr>
<td>foo</td>
</tr>
</table>
<p>bar</p>
|
<ul><li>
<table>
<tbody><tr><td>foo</td></tr>
</tbody></table>
<p>bar</p>
</li></ul>
|
<table>
<tr><td>foo</td></tr>
</table>
bar
|
Unclosed quotes in heading
| Wikitext | Proposed Fix |
|---|---|
text
==''foo==
bar
|
text
==''foo''==
bar
|
Consideraciones
- Aún no sabemos cómo determinar de forma automática todas las páginas y plantillas afectadas, pero esperamos que la lista de plantillas y sugerencias se vaya completando a medida que estemos al corriente de los problemas que no se hayan detectado antes. El personal de enlace comunitario (community liaisons) se pondrá en contacto con los expertos en plantillas, los usuarios habituales en las páginas de Café, etc., para asegurarse de que estén al tanto de los cambios necesarios y de los recursos que les puedan ser de ayuda.
- Estamos pensando en otras maneras sencillas y sostenibles en las que podamos apoyar a los wikignomos y a todos los wikimedistas dispuestos a echar una mano.
Otras preguntas frecuentes
P: ¿Qué ocurre con <pre /> y otras etiquetas similares si se usan de forma autocerrada?
R: Como se indica en T134423, las únicas etiquetas HTML autocerradas válidas son $area, $base, $br, $col, $embed, $hr, $img, $input, $keygen, $link, $meta, $param, $source, $track, $wbr. Otras etiquetas autocerradas que no son de HTML (como $references y $funnynowiki) no están afectadas por este cambio. $pre es un caso especial porque, aunque se trata de una etiqueta HTML, MediaWiki la trata como una etiqueta de extensión, y por ello no está afectada. Cualquier otra etiqueta HTML autocerrada deben corregirse (y ya están siendo corregidas por editores en estos momentos).
Non-HTML self-closing tags (like <references /> and <nowiki />) are not affected by this change. <pre> is a special case because while it is an 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).
Como este uso se ha hallado en muchas páginas de nuestras pruebas, con el fin de prevenir comportamientos inesperados en la presentación (por ejemplo, tratar <b /> como <b>, marcando en negrita más texto del que se esperaba), añadimos una corrección al analizador para convertirlas en etiquetas vacías (por ejemplo, <b /> pasará a ser <b></b>). Sin embargo, no es nuestra intención retener este arreglo indefinidamente, así que nos gustaría que los editores siguieran corrigiendo este uso obsoleto.
P: ¿Cuáles fueron los resultados de las pruebas en idiomas distintos del inglés, o en proyectos hermanos?
R: No hay nada en lo que hace Tidy o RemexHTML que es específico de Wikipedia o de la lengua inglesa. Este proyecto concierne principalmente un cambio de la semántica de HTML4 a la de HTML5 y el deseo de deshacernos de algunas modificaciones de HTML que hace Tidy. Estos cambios afectan a todos los proyectos e idiomas por igual, excepto si algunos proyectos o idiomas tienden a tener más errores de marcado o utilizan más etiquetas autocerradas que otros.
P: ¿Qué otros cambios es probable que vean los editores después de esta sustitución?
R: El efecto de esta sustitución va a afectar principalmente a los lectores, porque podrán percibir que la página no se muestra correctamente (por ejemplo, cuadros de navegación excesivamente anchos sin saltos de línea ni ajustes). Sin embargo, en todo caso, esto podría dar lugar a que la presentación que se ve en el editor visual corresponda con mucha mayor fidelidad que antes a la que se ve fuera, ya que la salida de Parsoid ha cumplido desde el principio con las especificaciones de HTML5, y ahora estamos migrando a que la salida para lectura también cumpla con HTML5. No esperamos que esto afecte de ninguna manera a las ediciones del editor visual, pero abordaremos puntualmente cualquier error relacionado con la suciedad en el código. Además de esto, no tenemos pensado añadir mensajes o advertencias de error a las páginas si no se corrigen los errores de marcado.
P: ¿Cómo afecta esta sustitución a otros proyectos en los que estáis trabajando?
R: Al habilitar la migración a la semántica de HTML5, este es uno de los pasos de la evolución del marcado en nuestro corpus con el fin de adaptarnos a los estándares web. También esperamos impulsar esta herramienta para fomentar una presentación equilibrada de las plantillas. Por otra parte, pero también en relación con esto, la sustitución también hará que la salida del analizador de PHP (utilizado para la lectura) sea más consistente con la salida de Parsoid (utilizado para las ediciones en el editor visual o el traductor de contenidos), ya que Parsoid ya utiliza la semántica de HTML5. Uno de nuestros objetivos es que las dos salidas sean totalmente consistentes entre sí y poder utilizar un solo analizador tanto para las lecturas como para las ediciones.
--El Equipo de Análisis Sintáctico
Voluntarios disponibles para apoyar esta iniciativa
Los enlaces comunitarios invitan a los wikimedistas interesados a añadir su nombre en las secciones a continuación y apotar los esfuerzos de participación de la comunidad. Gracias. Al igual que en iniciativas similares en el pasado, la adhesión es opcional. Te invitamos a consultar Parsing/Get involved y añadirla a tus marcadores, pues las futuras peticiones de asistencia pasarán por esta página.
- Estoy disponible para hacer pruebas con la herramienta ParserMigration.
- (añade tu firma aquí)
- ...
- ...
- Estoy disponible para arreglar plantillas.
- Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
- Samuele2002 (talk)
- TheDragonFire (talk)
- Stryn (talk) 14:22, 17 July 2017 (UTC)
- Already did some in fawiki Ladsgroup (talk) 15:40, 18 September 2017 (UTC)
- My bot can fix multiple-unclosed-formatting-tags error. --星耀晨曦 (talk) 07:19, 6 April 2018 (UTC)
- ネイ (talk) 09:36, 7 April 2018 (UTC)
- Been at it a long time already at en.Wikipedia. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 3 May 2019 (UTC)
- Estoy disponible para estudiar y discutir sobre correcciones para las plantillas.
- Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
- Been at it a long time already at en.Wikipedia. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 3 May 2019 (UTC)
- Estoy disponible para difundir la información a mi comunidad.
- (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
- See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)
- See this page. ネイ (talk) 09:36, 7 April 2018 (UTC)
- See meta:User:SMcCandlish/lint.css; w:Linter#User CSS tool: lint.css; w:Template:Mxt/User CSS for a monospaced coding font; etc. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 3 May 2019 (UTC)