Help:Extension:Linter/uk

Розширення  визначає шаблони вікі-тексту, які повинні чи можуть бути виправлені на сторінках, разом із деякими настановами щодо того, які саме проблеми з цими шаблонами та як їх виправити.

Сторінка Спеціальна:LintErrors групує помилки за типом. Деякі з цих проблем може бути легко знайти з Спеціальна:Expandtemplates. На цій сторінці ми класифікуватимемо проблеми lint відповідно до гостроти проблеми щодо цілей, які блокуються цими проблемами. Більше інформації й обговорення про це надається нижче.

Ми продовжуватимемо поліпшувати функційність для усунення шуму, виправлення помилок і збільшення дієвості виведення linter, але поточне виведення готове до використання та дій.

'''Див. також деякі спрощені інструкції для редакторів.'''

Чому і що виправляти
Забігаючи наперед, синтаксична команда планує використовувати розширення Linter для ідентифікації шаблонів вікі-тексту: Не всі з них необхідно виправити негайно чи навіть будь-коли (залежно від вашого терпіння для lint). Різні цілі досягаються виправленням різних підмножин вищенаведених проблем lint. Ми (синтаксична команда) намагатимемося бути прозорими щодо цих цілей і надаватимемо настанови про те, які цілі досягаються виправленням яких проблем.
 * які є помилковими (наприклад: фальшиві опції зображень — зазвичай спричинені одруками чи крихкістю парсингу опцій медіа на MediaWiki).
 * які є застарілими (наприклад: самозакривні теги)
 * які можуть зламатися через зміни в parsing pipeline (наприклад: заміна Tidy на RemexHTML)
 * які більше недійсні в HTML5 (наприклад: застарілі теги на кшталт center, font)
 * які потенційно зламані та можуть хибно інтерпретуватися парсером порівняно з тим, як цього очікує редактор (наприклад: незакриті та хибно вкладені теги HTML)

Спрощені інструкції надано на сторінці ЧАПів.

Мета: Заміна Tidy
As part of addressing technical debt in the parsing pipeline of MediaWiki, we have been working to replace Tidy with a HTML5-based tool. However, doing so will break the rendering of a small subset of pages unless certain wikitext patterns are fixed. Specifically, issues found in the,  ,  ,  ,  , and   categories. In order to ensure that we don't stretch out this Tidy replacement too long, we have accordingly marked all these issues as high priority.

Verifying fixes for these lint categories
You can verify the fixes for these lint categories via the ParserMigration extension. If you enable "ParserMigration" in your preferences, a link will be added to the toolbox of all articles ("Edit with migration tool"). If you edit the wikitext for a page with this link, the preview will show you current output (Tidy) and new output (RemexHTML, the Tidy replacement) side-by-side and check how your edit changes the rendering.

Goal: Improving compliance between rendering of the PHP parser and Parsoid
Right now, the HTML generated by the PHP parser is used for read views and the HTML generated by Parsoid is used by editing tools and the Android app among others. The parsing team, as one of its long-term objectives, wants to enable the use of Parsoid's output for both read views as well as for editing. Since Parsoid and RemexHTML are both HTML5-based tools, the lint categories that affect RemexHTML's rendering also affect Parsoid's rendering. We haven't yet identified any newer lint issues that affect Parsoid's rendering at this time, but will update this list as we identify any such.

Goal: HTML5 output compliance
This is a somewhat complex goal and we haven't yet arrived at an understanding about how important it is to pursue this goal or how far we should go with this. Additionally, it is not yet clear what mechanisms we wish to leverage towards this goal. For example, based on a bunch of discussions in different venues, User:Legoktm/HTML+MediaWiki outlines a proposal for handling the html5-deprecated big tag. In any case, fixing issues in the,   categories advance this goal. Given lack of clarity around this goal, we have accordingly marked the obsolete-tag category as a low-priority goal.

Goal: Clarifying editor intent
Getting markup right is hard. 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.

Ціль: Очистити розмітку
Getting markup right is hard. Even in the presence of errors, the parser does a fairly decent job in most cases in figuring out accurately how that piece of markup is supposed to render. But, in much the same way that typos, punctuation and minor grammatical errors can feel unsettling, some editors or those with a developer-mindset might find lint issues in these categories unsettling. We don't recommend spending an inordinate amount of time fixing these issues and, in many scenarios, bots might be able to fix these up as well. ,,   lint categories affect this goal.

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

Інструменти

 * w:en: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.

Див. також

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