Help:Extension:Linter/es

La extensión  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 Especial:Errores de sintaxis (Special:LintErrors) agrupa los errores por tipo. Algunos de estos errores pueden ser más fáciles de hallar mediante Special:Expandtemplates. 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 Special:LintErrors 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.

We will continue to improve functionality to eliminate noise, fix bugs, and make the linter output more actionable, but the current output is ready to use and act on.

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.


 * that are erroneous (ex: bogus image options – usually caused by typos or because media option parsing in MediaWiki is fragile).
 * that are deprecated (ex: self-closing tags)
 * that can break because of changes to the parsing pipeline (ex: replacing Tidy with RemexHTML)
 * that are no longer valid in HTML5 (ex: obsolete tags like center, font)
 * that are potentially broken and can be misinterpreted by the parser compared to what the editor intended them to be (ex: unclosed HTML tags, misnested HTML tags)

Not all of them need to be fixed promptly or even ever (depending on your tolerance for lint). Different goals are advanced by fixing different subsets of the above lint issues. We (the parsing team) will try to be transparent about these goals and will provide guidance about which goals are advanced by fixing which issues.

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 trabajado para poder reemplazar Tidy por una herramienta basada en HTML5. Sin embargo, hacer esto estropeará la presentación de un pequeño subconjunto de las páginas a menos que se arreglen ciertos patrones de wikitexto. Específicamente, problemas hallados en las categorías,  ,  ,  ,   y. Para poder asegurar que no prorrogaremos esta sustitución de Tidy por mucho tiempo, hemos marcado apropiadamente 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  y   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. Involuntariamente, acabamos cometiendo errores. 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,  ,   y   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  con prioridad baja porque, en la gran mayoría de los casos, el analizador parece que hace un buen trabajo. 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. Errors inadvertently creep through. While the parser does its best in recovering from these errors, in many cases, what the parser does might not truly reflect the editor's original intent. Given that, we recommend that it is best to fix the issues identified here to clarify the editor's intention. Issues in the,  ,  ,   categories seem to affect this goal. Since this is a fairly important goal, we have marked most of them with medium priority. However, we have marked the missing-end-tag category with a low priority since in a vast majority of cases, the parser does seem to recover fairly accurately. Nevertheless, we recommend fixing whatever can be fixed without too much effort, if only to assist comprehension by other human editors and tools.

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,   y   afectan este objetivo.

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 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.

Herramientas

 * w:User:PerfektesChaos/js/lintHint – a JavaScript gadget that shows a list of LintErrors (Parsoid messages) live
 * WPCleaner – a Java program that interfaces with Linter and can also detect some of the errors
 * ja:User:MawaruNeko/ShowPageLintError.js – a user script that shows all lint errors on a page
 * Bot by User:星耀晨曦 that can fix multiple-unclosed-formatting-tags errors.

Véase también

 * Parsoid/API#Wikitext to lint
 * Parsing/Replacing Tidy
 * w:Wikipedia:Linter