Ayuda:Extensión:Linter

This page is a translated version of the page Help:Extension:Linter and the translation is 70% complete.

La extensión Linter identifica patrones de wikitexto que deberían o podrían arreglarse en las páginas, junto con algunas guías sobre qué problemas hay con dichos patrones y cómo arreglarlos.

La página Errores de sintaxis agrupa los errores por tipo. Algunos de estos errores pueden ser más fáciles de hallar mediante Expandir plantillas. En esta página, clasificaremos los problemas de sintaxis de acuerdo con la gravedad del problema, teniendo en cuenta las metas que estos problemas impiden alcanzar. A continuación se muestra más información y se discutirán estos puntos.

There is a new feature "Show all linter errors for a specific page" at the bottom of Errores de sintaxis page which allows an editor to get a report of all errors on a single page. The report contains the category and other useful information and each error has a clickable link that loads the page and highlights the error. (Note: if your source editor has syntax highlighting enabled, the highlighting may not work). By working from the end of the list upward, changes to the page will not invalidate the character offsets of earlier errors and is the recommended way to work if you are fixing all errors on a page.

Seguiremos mejorando la funcionalidad para eliminar la interferencia, arreglar errores y facilitar el rendimiento del analizador, aunque el rendimiento actual está listo para usar y actuar.

Documentation of lint issues

Qué arreglar y por qué

En adelante, el equipo de análisis sintáctico piensa hacer uso de la extensión Linter para identificar patrones de wikitexto:

que son erróneos (por ejemplo, opciones de imagen inexistentes – creadas habitualmente por errores tipográficos o porque el análisis de opciones para archivos multimedia en MediaWiki es frágil);
que están obsoletos (por ejemplo, etiquetas autocerradas);
que pueden dejar de funcionar debido a cambios en el analizador sintáctico (por ejemplo, reemplazar Tidy por RemexHTML);
que ya no son válidos en HTML5 (por ejemplo, etiquetas obsoletas como center o font);
que tienen la potencialidad de no funcionar o de ser mal interpretados por el analizador con respecto a la intención del editor original (por ejemplo, etiquetas HTML no cerradas o etiquetas HTML mal anidadas).

No todos estos patrones deben corregirse con prontitud o incluso en absoluto (dependiendo de tu tolerancia hacia los errores sintácticos). Se avanzan distintos objetivos mediante la corrección de distintos subconjuntos de los problemas descritos anteriormente. Nosotros (el equipo de análisis sintáctico) trataremos de ser transparentes en lo que se refiere a estos objetivos, y trataremos de proporcionar asistencia sobre qué correcciones avanzan qué objetivos.

Se proporcionan instrucciones simplificadas en la página de preguntas frecuentes.

Objetivo: reemplazar Tidy

Como parte del tratamiento de la deuda técnica en lo referente al analizador sintáctico de MediaWiki, hemos estado sustituido Tidy por una herramienta basada en HTML5. Sin embargo, hacer esto habría dado lugar a errores en la presentación de un pequeño subconjunto de las páginas a menos que se arreglaran ciertos patrones de wikitexto. Específicamente, problemas hallados en las categorías deletable-table-tag, pwrap-bug-workaround, self-closed-tag, tidy-whitespace-bug, html5-misnesting y tidy-font-bug. Para poder asegurar una sustitución puntual de Tidy, clasificamos todos estos problemas con prioridad alta.

Objetivo: mejorar la conformidad entre la presentación del analizador PHP y Parsoid

Ahora mismo, el HTML generado por el analizador PHP se utiliza para la lectura y el HTML generado por Parsoid es utilizado por herramientas de edición y la aplicación de Android, entre otras. El equipo de análisis sintáctico, como uno de sus objetivos a largo plazo, quiere habilitar el uso de la salida de Parsoid para la lectura así como para la edición. Como tanto Parsoid como RemexHTML son herramientas basadas en HTML5, las categorías sintácticas que afectan la presentación de RemexHTML también afectan la de Parsoid. De momento, no hemos identificado ninguna categoría nueva de errores sintácticos que afecten la presentación de Parsoid, pero actualizaremos esta lista a medida que vayamos identificando categorías nuevas.

Objetivo: conformidad de la salida con HTML5

Este es un objetivo algo complejo y de momento no hemos llegado a un entendimiento sobre la importancia de alcanzar este objetivo o cuán lejos deberíamos ir. Además, no tenemos claro qué mecanismos querríamos utilizar para acercarnos a él. Por ejemplo, basándose en varias discusiones en otras reuniones, User:Legoktm/HTML+MediaWiki esboza una propuesta para tratar la etiqueta big, obsoleta en HTML5. En cualquier caso, arreglar problemas en las categorías obsolete-tag y self-closed-tag nos acercan a este objetivo. Dada la falta de claridad de ideas en torno a él, hemos marcado convenientemente la categoría obsolete-tag como un objetivo de prioridad baja.

Objetivo: aclarar la intención del editor

Conseguir que el marcado sea correcto es difícil. Los errores se acaban colando inadvertidamente. Aunque el analizador hace su trabajo lo mejor que puede para obviar estos errores, en muchos casos, lo que hace el analizador no refleja la intención original del editor. Teniendo esto en cuenta, pensamos que lo mejor es arreglar los problemas identificados aquí para aclarar cuál es la intención del editor. Los asuntos categorizados en bogus-image-options, fostered-content, misnested-tag y missing-end-tag parecen afectar este objetivo. Como se trata de un objetivo de importancia considerable, hemos marcado la mayoría de estas categorías con prioridad media. Sin embargo, hemos marcado la categoría missing-end-tag con prioridad baja porque, en la gran mayoría de los casos, parece que el analizador se resincroniza con bastante precisión. De todas formas, recomendamos arreglar todo aquello que no suponga demasiado esfuerzo, aunque solo sea para contribuir a la comprensión sintáctica por parte de otros editores humanos y otras herramientas.

Objetivo: un marcado limpio

Conseguir que el marcado sea correcto es difícil. Incluso en presencia de errores, el analizador hace en la mayoría de los casos un buen trabajo en averiguar con precisión de qué manera debería visualizarse tal o cual pieza de marcado. Sin embargo, de la misma manera en que los errores tipográficos, los errores de puntuación y los errores de gramática pueden incomodar a más de uno, algunos editores, entre ellos, los que tienen una mentalidad de desarrollador, pueden sentirse incómodos con estas categorías. No recomendamos invertir demasiado tiempo en arreglar estos problemas, y, en muchos escenarios, los bots también pueden ayudar a arreglarlos. Las categorías misnested-tag, missing-end-tag y stripped-tag afectan este objetivo.

Preguntas frecuentes

When are lint errors for a page updated?

Currently, all lint categories are populated by errors identified by Parsoid while parsing a page. When a page (or, template transcluded on a page) is edited, ChangeProp requests a re-parse of that page from Parsoid, which will send the fresh results to the Linter extension.

This means that when a new category is introduced (or a correction is made to a previous category), it may take a while for all the results to be updated (if ever for pages that are rarely touched). Making a null edit would speed up the process individually. However, in phab:T161556, we're exploring ways to reprocess all pages.

Should pages in X namespace (e.g. talk) be fixed

The priority is content namespaces. The rest largely depend on the wiki. A lot of pages are used as a sandbox, and as such deliberately contain errors.