Ayuda:Extensión:Linter

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

La extensión Linter identifica patrones de texto wiki que deben o pueden ser arreglados en las páginas junto con algunas instrucciones sobre cuáles son los problemas con esos patrones y cómo solucionarlos.

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.

Hay una nueva función «Mostrar todos los errores de sintaxis para una página concreta» en la parte inferior de la página Errores de sintaxis que permite a un editor obtener un informe de todos los errores en una sola página. El informe contiene la categoría y otra información útil y cada error cuenta con un enlace que carga la página y destaca el error. (Nota: si tu editor de código tiene habilitado el resaltado sintáctico, este resaltado puede no funcionar.) Al trabajar desde el final de la lista hasta el principio, los cambios en la página no invalidarán los desfases de caracteres de errores anteriores. Esta es la manera recomendada de trabajar si pretendes corregir todos los errores de una página.

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.

Documentación de los errores de sintaxis

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.

Goal: Improve content portability and presentation

Writing templates for content that works across different devices, different browser resolutions, different skins (and their themes e.g. dark mode), different websites (e.g. Wikiwand, Kiwix, Wikimedia Apps) is tricky. While skins do their best to adapt to content, they are restricted in what they can do given the myriad of templates used across our sites. Where we can, issues are flagged for editors to assist. night-mode-unaware-background-color, large-tables, lint categories affect this goal.

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.