Help talk:Extension:Linter

Might be good to list tools that can be used to help clean up errors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

See: Extension talk:Linter#h-Suggestion:_Add_a_basic_html_validator_to_the_extension-2017-04-15T11:58:00.000Z.

Tools such as :

• Special:Expandtemplates
• Special:TemplateSandbox

Also external html validators for the raw html, since mediawiki doesn't provide any.

• 197.218.81.124 (talk) 14:16, 16 April 2017 (UTC)

@SSastry (WMF), ideas? Elitre (WMF) (talk) 15:31, 27 April 2017 (UTC)

Special:Expandtemplates is already mentioned on the help page. Feel free to update the Help:Extension:Linter page with additional suggestions, as useful. SSastry (WMF) (talk) 15:50, 27 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Obsolete tt tag

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Does Special:LintErrors pick up the tt tags that are seen in pages such as Translations:Help:Namespaces/27/fr ? Whatamidoing (WMF) (talk) 22:28, 24 April 2017 (UTC)

Yes, it should.

[subbu@earth parsoid] parse.js --prefix mediawikiwiki --page 'Translations:Help:Namespaces/27/fr' --lint < /dev/null > /dev/null

[info/lint/obsolete-tag][mediawikiwiki/Translations:Help:Namespaces/27/fr] {"type":"obsolete-tag","params":{"name":"tt"},"dsr":[126,215,31,5]}

But, right now, it is only picked up on edits to the page or to transcluded templates until we deploy a fix for T161556 SSastry (WMF) (talk) 22:43, 24 April 2017 (UTC)

I don't know how to fix <tt style="white-space:nowrap">. Just plain <code>, or should the "style" part be retained? Whatamidoing (WMF) (talk) 19:57, 27 April 2017 (UTC)

<code style="white-space:nowrap"></code> should suffice. 197.218.91.181 (talk) 21:07, 27 April 2017 (UTC)

See :

http://www.computerhope.com/jargon/h/html-tt-tag.htm

https://developer.mozilla.org/en/docs/Web/HTML/Element/tt 197.218.91.181 (talk) 21:08, 27 April 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Discussion page backgrounds using missing /div

Several users on nl.wiktionary create a background for the comments on their Discussion page by opening a div and not closing it. This results in each new comment being part of this div. For an example see [1]. The parser migration tool suggests that this effect will be preserved in the near future, so a change does not seem urgent. But is there presently a HTML5 compliant way to get the same result? MarcoSwart (talk) 09:43, 24 May 2017 (UTC)

I think that someone like @Jonesey95 or @ Facenapalm could probably tell you if there is a good way to do this. Whatamidoing (WMF) (talk) 19:32, 29 May 2017 (UTC)

I think the only solution is to add a closing /div tag. I thought there was a CheckWiki error for this, but I do not see one. I do not know how they are detected on en.WP. Jonesey95 (talk) 20:08, 29 May 2017 (UTC)

CheckWiki can't find this case, because it can't analyse page code after tempate substitution (and because that page is not in main namespace as well).

I see 2 possible good ways and both of them are not applicable to this case. First is CSS, applicable only to personal design. Second is using a subpage with topics, which will be included to this one using something like "<div style=[design]>{{/topics}}</div>", and custom buttons "add topic", leading to subpage. A particle for world to form (talk) 22:14, 29 May 2017 (UTC)

Thanks for the information. So it seems there is no alternative for this trick. In that case my approach would be:

a. not doing anything to change these pages (at least in this respect: some other errors already have been resolved)

b. wait and see if and when a future change will break these pages, and then explain the users concerned that a solution is not available

c. if anyone asks at an earlier date, point to this discussion.

My reasoning: at Dutch Wiktionary only a handful of users used this trick on their Talk-page and none of them are very active at present. At the moment no one is having a problem. Even if this would change in the future, chances are there will be many things more important for our project to spend resources on. MarcoSwart (talk) 07:31, 30 May 2017 (UTC)

I somehow missed this topic earlier since I didn't have this page on my watchlist till recently. But, yes, we are aware of this usage pattern on user talk pages on many wikis (not just nl.wiktionary). We might eventually break this pattern, but we will try to figure out reasonable alternatives that addresses the common use cases. For example, this could be a page property that specifies a wrapper / CSS that is automatically applied by the parser. This would address the common use cases like the one you refer to, but won't address use cases where editors add the unclosed <div> tag in the middle of the page. But, yes, we are aware of this use case and have discussed this in the past. We will do what we can to support this cleanly without relying on hacks like unclosed-div tags. SSastry (WMF) (talk) 22:35, 29 June 2017 (UTC)

Supporting this use case makes very little sense. Extension:TemplateStyles looks like the best solution primarily because the lack of a personal stylesheet won't be a problem if / when templatestyles is deployed.

Such open html tags also cause loads of other issues, for example someone could easily break it by closing the div earlier than expected (e.g. using an unbalanced template). Beyond that, it can be quite confusing to newbies and even experienced users if someone adds something like the html below.

<div style="display:none">

197.218.90.226 (talk) 23:15, 29 June 2017 (UTC)

Right, we won't support unclosed <div> tags. I indicated that we would support the use-case for styling using whatever clean / sane mechanism that might be. SSastry (WMF) (talk) 23:19, 29 June 2017 (UTC)

Is there any progress on this issue? These are the only Lint errors that remain on nl.wiktionary for more than a few days... MarcoSwart (talk) 16:19, 13 February 2024 (UTC)

Document lint API

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I added some documentation to the parsoid api page, some of it may not be following the preferred format:

https://www.mediawiki.org/w/index.php?title=Parsoid/API&oldid=2496156

It might be worth documenting the API in a more accessible page (not sure where). Part of the restbase endpoint (https://www.mediawiki.org/api/rest_v1/#!/Transforms/post_transform_wikitext_to_lint_title_revision) doesn't seem to be working yet for revisions or page titles, and only works for arbitrary wikitext. 197.218.91.220 (talk) 10:10, 23 June 2017 (UTC)

Thanks for the documentation.

The RESTBase part is https://phabricator.wikimedia.org/T164006 Arlolra (talk) 13:26, 23 June 2017 (UTC)

After a bit of testing the API on random pages, it seems that there is at least one undocumented lint option:

"ignored-table-attr"

It seems to be related to having invalid or wrong table attributes in the syntax. The table syntax was something like (not the "|-|-"):

{|
|-|-
|stuff
|}

Considering that this is obtained directly from the lint API, it might expose more than the linter extension does. Anyway, if this is undesirable it might be better to suppress it, or document it if it is useful.

Thanks for the link to the Restbase part. 197.218.83.93 (talk) 16:27, 29 June 2017 (UTC)

Yes, not all issues that Parsoid detects (or can detect) are exposed via the Linter extension. This one was mostly harmless, so, I think that is the reason we didn't expose it, but we could in the future. SSastry (WMF) (talk) 22:24, 29 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Linter job frequency

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

How often does the linter run? Does it refresh pages as needed? In other words: when I attempt to fix an issue on a template, how can I make sure that the linter is looking at the up-to-date version of the pages that use the template? Bdijkstra (talk) 12:24, 28 June 2017 (UTC)

The linter is run when Parsoid re-renders a page, which happens when a page is edited. If a template is edited, ChangeProp notifies Parsoid, which will eventually update all the pages containing it, but perhaps with some noticeable delay. Arlolra (talk) 14:24, 28 June 2017 (UTC)

OK so how much delay is to be expected? Minutes, hours, days? If it's more than a few minutes, then perhaps it's a good idea to show a timestamp on each error message. Bdijkstra (talk) 14:37, 28 June 2017 (UTC)

It depends on how popular the template is, but, yes, if the template is used on a large number of pages, it can be hours to days before all pages are reprocessed. SSastry (WMF) (talk) 17:24, 28 June 2017 (UTC)

Tracked in Phabricator
Task T161556

It looks like there's a Phab task open about getting up-to-date versions of pages. Whatamidoing (WMF) (talk) 19:57, 4 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Translate

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Is it possible to tag this page and its sub-pages for translation, please? Noé (talk) 11:45, 23 July 2017 (UTC)

Done. (mostly thanks (Thanks!) to @MacFan4000)

There's also separate discussion about possible improvements that could be done to the Special pages themselves, at phab:T162895. Quiddity (WMF) (talk) 00:52, 25 July 2017 (UTC)

Most if not all of the relevant information is provided in the FAQ page, already marked for translation. Let's try to keep the translators' work focused and sustainable. Elitre (WMF) (talk) 04:45, 25 July 2017 (UTC)

Thank you. I confess, I wanted to understand and be able to explain the 30.000+ edits on fr.Wiktionary and I was unable to translate properly 'lint' in French. I hope to get this concept by helping to translate this page (and asking techis to help). Noé (talk) 08:05, 25 July 2017 (UTC)

I'm sure user:NicoV can explain that perfectly! (also, maybe it's not 30k edits? as explained elsewhere, in most cases fixing a few templates is enough, as the errors depend on those.) Elitre (WMF) (talk) 08:22, 25 July 2017 (UTC)

Hi, I'm not sure there's a simple translation for 'lint' in French because it's not a real word...

English wiktionary says "To perform a static check on (source code) to detect stylistic or programmatic errors." and "From the lint Unix utility, written in 1979, which analyses programs written in the C language, itself named after the undesirable bits of fiber and fluff found in sheep's wool (see etymology 1)."

French wiktionary says "(Programmation informatique) Pratiquer une évaluation du code source afin de détecter des erreurs stylistiques ou de programmation." NicoV (talk) 08:56, 25 July 2017 (UTC)

Elitre: 30k edits because some contributors used 'font' in their signature, for a decade or so. So, a lot of talk pages have to be fixed.

NicoV: there is no simple translation for a lot of words, and contributing to Wiktionary is an everyday challenge. Thanks for the French definition, I wrote it two days ago! It is probably not perfect, and your lights are welcome to improve it.

If it is used by people to communicate, it become a word. I don't think it is translatable though. As for a lot of jargon in new techs, people keep the English word, and that's fine. Wiktionary is not an office for language policy, it is just a place where to describe the uses. If the uses are to keep it in English, it's fine. Noé (talk) 09:45, 25 July 2017 (UTC)

Do you have a word for en:Lint (material) in French? :) Elitre (WMF) (talk) 10:12, 25 July 2017 (UTC)

Yes, we may translate lint as 'bourre'. I add the connection through Wikidata and link to fr.Wiktionary in fr.Wikipedia.To remove the lint in French may be the verb 'débourrer', but I don't think it is use in computer context. Noé (talk) 11:49, 25 July 2017 (UTC)

In the computer context, I think software developers understand what "lint" means even in French, because they know about the initial software named "lint". I don't know any French word that is used as a replacement for lint in this context... NicoV (talk) 12:29, 25 July 2017 (UTC)

The Frwiki article is Lint_(logiciel), but I assume you've already seen that! Quiddity (WMF) (talk) 15:12, 25 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

missing-end-tag : span tag around several lines ?

Hi, how do we fix reports of missing end tag for span where the closing span tag is actually here but around several lines.

Main problem is with templates. For example, on frwiki, Linter reports this error for Baud (Morbihan) due to a call to template refnec which puts its first parameter inside a span tag : in this case, the first parameter is a multi lines text.

Similare situation happens for many errors reported. NicoV (talk) 09:52, 3 August 2017 (UTC)

If it's multi-line text (or any form of block content) then you should use a <div>, not a <span>. Block content inside a <span> is invalid HTML. Jdforrester (WMF) (talk) 15:11, 3 August 2017 (UTC)

What James said there. But, yes, this gets trickier where templates and parameters are involved. This will get easier to handle once we start work in earnest with balanced templates. At that time, template authors can provide guidance to editors about contexts in which it can be used which then informs what kind of parameters are valid. Somewhat like a limited set of types (that are pertinent to the HTML context).

But, for the immediate term, don't have a good answer for you -- either let the error be (since the HTML does get "fixed up"), or change the page, or change the template based on how it is being used on pages. It is a low-priority issue for some of these reasons -- because, the wikitext and HTML5 parsers handle them correctly (i.e. as in respecting author's intent) in most (definitely not all) cases. SSastry (WMF) (talk) 15:39, 3 August 2017 (UTC)

The problem is actually caused by the spaces in that particular usage, this seems to be tricky and can only be fixed on a case by case basis, for example this small snippet:

{{refnec|Le nom [[breton]] de la commune est '''''Baod''''' (prononcé [bɔwt]).

''Baod'' serait le nom du fondateur de l'entité primitive. Cette possibilité se trouve étayée par le toponyme de quelques écarts comme ''Lenvaod'' (Lenvaud) ou ''Ker al Baod'' (Keralbaud).
}}

Becomes this:

<div class="mw-parser-output">
    <p>
        <span class="need_ref" style="cursor:help;" title="Ce passage nécessite une référence.">Le nom 
      <a href="/wiki/Breton" title="Breton">breton</a> de la commune est <i><b>Baod</b></i> (prononcé [bɔwt]).
    </p>
    <p>
        <i>Baod</i> serait le nom du fondateur de l'entité primitive. Cette possibilité se trouve étayée par le toponyme de quelques écarts comme <i>Lenvaod</i> (Lenvaud) ou <i>Ker al Baod</i> (Keralbaud).
        </span>
        <sup class="need_ref_tag" style="padding-left:2px;"><a href="/wiki/Aide:R%C3%A9f%C3%A9rence_n%C3%A9cessaire" title="Aide:Référence nécessaire">[réf.&#160;nécessaire]</a></sup>
    </p>
</div>

See Template:Refnec Special:expandtemplates.

This is because an empty line break in wikitext is changed to "<p></p>", and that isn't allowed to be nested inside a span. The same would apply to any block type tag nested inside "phrasing content".

There are many ways to fix this, but this largely depends on what type of output one wants. Either change the template to emit a div or a paragraph, or make sure the template (through lua or something else) changes all empty newlines , e.g. "\n" to "<br>".

Most cases where this happens are caused by tags being misnested and eventually "missing end tags" as a result. In such cases the templates need to be cleaned up to avoid incorrectly nested html.

Using "Show raw HTML" in Special:Expandtemplates is a good way to find these.

Adding this to the linter itself (https://phabricator.wikimedia.org/T163149) should probably help future cases. 197.218.81.104 (talk) 16:10, 3 August 2017 (UTC)

I believe that the Listing templates at the Wikivoyages are having this problem, too. Most listings have only one line, but some have multi-paragraph descriptions. Whatamidoing (WMF) (talk) 17:16, 3 August 2017 (UTC)

Gadget advertising

The gadgets are now listed on the help page

Please see lintHint@PerfektesChaos with functionality:

1. Analyse current page.
2. Analyse arbitrary wikitext sequence or any page.

Greetings PerfektesChaos (talk) 12:07, 10 August 2017 (UTC)

@PerfektesChaos, hi, would you like to add a link about it on the actual page perhaps? It only needs a basic description. Elitre (WMF) (talk) 10:46, 23 August 2017 (UTC)

This advertising is supposed to be added to the connected page.

However. that should be done by a higher polynomial degree, not by myself, and someone might declare it as harmless.

Even more, there is no Tools and Aides section yet on target page.

On doc page enough text material to be copied is available. PerfektesChaos (talk) 12:57, 23 August 2017 (UTC)

By all means, please do feel free to add where you see it fit, the wiki way.

Here's an example of how that's been done in the past. Elitre (WMF) (talk) 14:26, 23 August 2017 (UTC)

That should remain business of someone with “(WMF)” terminated nick. I am not pushing myself to the front.

@Whatamidoing (WMF) sent a THX 11 days ago. PerfektesChaos (talk) 18:10, 23 August 2017 (UTC)

I guarantee this is not the case. Us being around does not mean we own these pages, by any means. Elitre (WMF) (talk) 08:47, 24 August 2017 (UTC)

Do we have a curated list of tools available for semi-automatically fixing all these (linted) errors? Deryck C.^Meta 21:21, 23 August 2017 (UTC)

I don't think so. Would you like to start one? I am not aware of those which have not already been mentioned (Linter, NicoV's one, and the one from this thread). Elitre (WMF) (talk) 08:48, 24 August 2017 (UTC)

When you say Linter do you mean Special:LintErrors or an editing tool? Deryck C.^Meta 12:03, 24 August 2017 (UTC)

That one. Elitre (WMF) (talk) 09:09, 29 August 2017 (UTC)

Apparently not.

I might advertise WikiSyntaxTextMod@PerfektesChaos which happens to fix some automatically while editing for other reasons, and identifies some other problems and warns on manual source editing. Running since 2010, mostly on German WP. PerfektesChaos (talk) 08:40, 24 August 2017 (UTC)

I just want to acknowledge how lintHint gets praised by community members who aren't their creator :p (it's mentioned in this comment at it.wp). I don't mean to say the other tools aren't equally useful, but thought that this endorsement mattered as it comes from another community that also switched early. Elitre (WMF) (talk) 13:59, 2 May 2018 (UTC)

Gracie.

G-Translator told me the it story.

Ah, Italian, since lintHint 3 is on alpha testing and close to be published, I would be happy to get a human translation in Italian for the following text fragments:

• Show LintErrors analysis live.
• Fill balanced wikitext into first input area and press adjacent submit button, or enter page name into second input field (might be followed by revision ID).
• select problem in source text
• Wikitext page not found
• Future problems detected.
• linter error analysis support
• Analyze previous revisions, too.
• Run analysis automatically in namespaces on visit rather than manually triggered by button.
• Convert all source edit links on LintErrors special page into ParserMigration tool edit.
• Suppress small label if no error detected.
• Space separated list of namespace numbers, for automatized analysis or - or *

Italian utenti will benefit from that. PerfektesChaos (talk) 13:34, 6 May 2018 (UTC)

• Mostra analisi degli errori di Lint in diretta.
• Inserisci il wikitesto nella prima area di input e premi il tasto di invio adiacente, oppure scrivi il titolo della pagina nel secondo campo (potrebbe essere seguito dall'ID della revisione).
• Seleziona un problema nel testo sorgente
• Pagina di wikitesto non trovata
• Futuri problemi individuati.
• Supporto per l'analisi degli errori di Lint
• Analizza anche le revisioni precedenti.
• Esegui automaticamente l'analisi nei namespace all'accesso, piuttosto che avviandola manualmente tramite bottone.
• Converti tutti i link di modifica sorgente presenti sulla pagina speciale Errori di Lint nello strumento di modifica ParserMigration.
• Nascondi l'etichetta in assenza di errori rilevati.

About the last one, I'm not sure what it refers to. Sakretsu (talk) 11:07, 7 May 2018 (UTC)

@PerfektesChaos Thanks for the tool :-) About the last one, if I understand correctly, it should be a label for a field containing a list of space separated namespaces where to perform an automated analysis, - for none or * for all. If so, a translation might be "Lista di namespace, in formato numerico separati da spazi, dove effettuare l'analisi. Usare - per la lista vuota e * per indicarli tutti" Daimona Eaytoy (talk) 15:12, 7 May 2018 (UTC)

Gracie, both of you.

I presume next weekend a pre-release of something like a version 2.9 ahead of 3.0 will be online, containing your texts. There you might do a last check. PerfektesChaos (talk) 08:16, 8 May 2018 (UTC)

@Daimona Eaytoy @Sakretsu

If you change temporarily in the JavaScript call from /r.js into /d.js you will find your texts on these pages:

• Special:Blankpage/preferencesGadgetOptions#lintHint
• Special:Blankpage/lintHint

For the benefit of utenti italiano I prepared w:it:Utente:PerfektesChaos/js/lintHint. Currently this is just a redirect. After version 3 has been released and English documentation was updated you might translate some most important sections, linking to English base documentation where less interesting. PerfektesChaos (talk) 17:28, 9 May 2018 (UTC)

Tested it, everything seems fine, well done! And yeah, we'll provide some kind of translation there once ready. Thanks again! Daimona Eaytoy (talk) 18:07, 9 May 2018 (UTC)

Version 3 has been released now.

The German story shows what is basically needed on a translated user guide. However, the JavaScript section is not very important any longer, since the interactive customization has been introduced. The English mother documentation is adding full information for programmers and maintainers which is not needed for using. PerfektesChaos (talk) 11:57, 15 May 2018 (UTC)

What's "Tidy whitespace bug"?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I saw this in new messages in translatewiki.net: "Tidy whitespace bug".

Is it a new bug? If it is, I couldn't find documentation for it. Amir E. Aharoni {{🌎🌍🌏}} 05:08, 13 August 2017 (UTC)

Ah, I thought I would add documentation for it once it got deployed. But, looks like translatewiki gets it sooner? But, https://gerrit.wikimedia.org/r/#/c/371068/3/COMMIT_MSG has some info that will make it to the help pages. SSastry (WMF) (talk) 12:31, 13 August 2017 (UTC)

translatewiki.net gets new messages very soon after they are merged in Gerrit.

Thanks for the link! Amir E. Aharoni {{🌎🌍🌏}} 12:42, 13 August 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

"Through a template" error

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It appears that the template shows up as a redlink in the "through a template" column if the wikitext error occurred in a template that was called via a redirect. Screenshot available on request. Deryck C.^Meta 21:18, 23 August 2017 (UTC)

fixed some bugs over the last couple months. If you see this again, a screenshot would be very welcome. Thanks!e SSastry (WMF) (talk) 15:20, 4 October 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

ElasticSearch?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

As asked in this topic, is there a way to search for Lint errors? e.g. a linterrors:misnested-tag to search pages in Special:LintErrors/misnested-tag? Thanks :) Valerio Bozzolan (talk) 17:48, 18 September 2017 (UTC)

Can you explain the use case a bit more? We currently provide a list of pages filtered by namespace (via the UI and the API). What use case would be enabled by indexing them? SSastry (WMF) (talk) 20:24, 18 September 2017 (UTC)

It helps bots. E.g. looking for pages with a template and that lint error / for something in the source and that lint error, etc. Valerio Bozzolan (talk) 09:21, 19 September 2017 (UTC)

It also helps human beings.

If I am interested in category:XYZ or articles containing the phrase fooBar I can edit and fix them, but i do not like all this other stuff.

Much appreciated feature. PerfektesChaos (talk) 13:36, 19 September 2017 (UTC)

AWB can load search results.

I don't know that it can presently load from the API or the UI. Izno (talk) 15:25, 4 October 2017 (UTC)

Here is an example of the search that should be available. According to https://en.wikipedia.org/w/index.php?title=Barack_Obama&action=info, there is 1 Misnested Tags lint error. (There should be, but is not, a direct way to get more information about this error, with one click on this Information page.) If the user goes to the list all articles with Misnested tags at https://en.wikipedia.org/wiki/Special:LintErrors/misnested-tag?namespace=0, it should be possible to search there for the article Barack Obama, so one can get more information about the misnested tag and fix it. Anomalocaris (talk) 19:05, 4 October 2017 (UTC)

If you want to do it from linter extension, you can use https://www.mediawiki.org/wiki/Manual:Hooks/SearchIndexFields for creating a new index field (you probably want keyword field, a field can have multiple values), https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex for indexing the data and Manual:Hooks/CirrusSearchAddQueryFeatures for defining a new feature like linterrors: Smalyshev (WMF) (talk) 19:34, 4 October 2017 (UTC)

You can look at GeoData extension which does it. Smalyshev (WMF) (talk) 19:34, 4 October 2017 (UTC)

Hmm, does the search API allow the use of generators?

It would be much more future proof to get a generic list of pages and then direct the search engine to look through those and only those. This would be useful almost everywhere,stuff like Special:wantedpages, and maybe pages with a specific Page props.

That would probably greatly reduce the need for hacky insource:// stuff. Anyway, allowing the search engine to access lints seems like a great idea.

Separately though, the lint page could use its own filter on page titles. 197.218.84.238 (talk) 19:51, 4 October 2017 (UTC)

Ah, another note - if you follow the route I outlined above, you'd probably need to run some scripts to update index mappings. Ping people on #wikimedia-discovery about how to do it if you need help. Smalyshev (WMF) (talk) 19:55, 4 October 2017 (UTC)

> direct way to get more information about this error

It wouldn't help much unless the list was ungrouped first. Right now it says stuff like "p-wrap-bug: 6". Clicking that could only take you to a random lint error.

Fortunately, it is already possible (and trivial) to do what you want using the linter API without even visiting the info page. There should be a userscript that does that already. 197.218.84.238 (talk) 19:57, 4 October 2017 (UTC)

Trivial? Please show me how to find the misnested tag in en:Barack Obama. Anomalocaris (talk) 20:05, 4 October 2017 (UTC)

It is coming from :

{{Navboxes
|list1 =
{{US Presidents}}
{{United States presidential election, 2008}}
{{United States presidential election, 2012}}
{{Democratic Party (United States)}}
{{Nobel Peace Prize laureates}}
{{Time Persons of the Year}}
{{United States Senators from Illinois}}
{{Patriot Act}}
{{Grammy Award for Best Spoken Word Album 2000s}}
}}

197.218.84.238 (talk) 20:28, 4 October 2017 (UTC)

Or more specifically :

{{United States presidential election, 2012}}

Oh, and to get the exact spot I wrote a simple userscript. It is not particularly userfriendly, you'd have to paste it on the browser console. 197.218.84.238 (talk) 20:38, 4 October 2017 (UTC)

Thanks, but I didn't ask where the error was. I asked, "Please show me how to find the misnested tag." Anomalocaris (talk) 14:46, 5 October 2017 (UTC)

This is a bit off topic but anyway see the user unfriendly script here :Help talk:Extension:Linter#h-User_unfriendly_script_to_find_errors-2017-10-05T20:16:00.000Z . 197.218.89.23 (talk) 20:18, 5 October 2017 (UTC)

Hello anonymous friend, :-) It might be helpful if you could convert that into a friendly gadget / userscript and share it so it is equally easy for others to use. SSastry (WMF) (talk) 20:59, 4 October 2017 (UTC)

Howdy. It seems like we've gone way off topic... (It is still a good idea to expose lint errors to the search engine).

Anyway, to make it really user friendly one would need a html validator. This is something which probably no wikimedia API currently provides , and which requires one to spend time scratching their head trying to figure out where the error might be. Testing html validity using an external tool is certainly possible but that will be very unreliable.

Also the lint API still doesn't currently support retrieving a revision. So one has to basically send the whole wikitext to the lint API making it somewhat slower. Although quite useful for testing out fixes. Maybe lint errors should be stored in page props or as a javascript variable when the editor loads.

Arguably those improvements should be in the linter tool itself. 197.218.89.23 (talk) 20:33, 5 October 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

multi-colon-escape

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

OK, I see there's a new error: multi-colon-escape

And again it's not documented, so it's quite hard to translate it. Amir E. Aharoni {{🌎🌍🌏}} 12:55, 25 September 2017 (UTC)

Not deployed yet. But, @Arlolra .. FYI. Can you add the appropriate wiki pages? SSastry (WMF) (talk) 14:28, 25 September 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Can link handling be added to description pages?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Example: MediaWiki:Linter-category-self-closed-tag-desc ; the page is not processing wikilinks or html links from this message to the actual page. Xaosflux (talk) 16:20, 4 October 2017 (UTC)

You mean you want wikitext be parsed? That should be doable. Legoktm (talk) 17:32, 4 October 2017 (UTC)

Re: links in the UI string, confirmed - bug filed: phab:T177429

Re: intent - is that basically the change you were trying to add? I'm assuming this is related to phab:T162895. Quiddity (WMF) (talk) 17:46, 4 October 2017 (UTC)

phab:T177429 looks good for future steps. We may want to include localized reference pages (Project:LintCleanup/Tag) etc. Xaosflux (talk) 19:21, 4 October 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

User unfriendly script to find errors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

//Wikilinter
var currError = currError || 0;
var tmpWikitext = tmpWikitext || "";
var lintData = lintData || [];
var textArea = document.getElementById('wpTextbox1');
var selectRange = function(start, end) {
	// https://stackoverflow.com/a/40017290
	var e = document.getElementById( 'wpTextbox1');
	if (!e) return;
	else if (e.setSelectionRange) { e.focus(); e.setSelectionRange(start, end); } /* WebKit */
	else if (e.createTextRange) { var range = e.createTextRange(); range.collapse(true); range.moveEnd('character', end); range.moveStart('character', start); range.select(); } /* IE */
	else if (e.selectionStart) { e.selectionStart = start; e.selectionEnd = end; }
};
function getError(data, currError ){
	if (data && data.length){
		alert("found "+ currError + " /"  + data.length + " errors.  Scroll down to find highlighted text.");
	} else {
		alert("No errors found.");
	}
	lintData = data;
	if (lintData[currError]) {
		var startRange = lintData[currError].dsr[0];
		var endRange = lintData[currError].dsr[1];
		textArea.focus();
		selectRange(startRange, endRange);
	}
}
if (tmpWikitext === $("#wpTextbox1").val() && lintData.length - 1 > 0 ) {
	if ( currError >=  lintData.length) {
		currError = 0;
	} else { currError = currError + 1; }
	getError(lintData, currError );

	console.log("yup");
} else {
	tmpWikitext = $("#wpTextbox1").val();
	$.post(window.location.origin +"/api/rest_v1/transform/wikitext/to/lint", {
		wikitext: $("#wpTextbox1").val()
	}).then(function (data) {
		var textArea = document.getElementById('wpTextbox1');
		getError(data, currError);
	});
}

Instructions:

1. Go to wikipage with errors
2. Click edit / view source
3. Open browser console
4. Paste the snippet above
5. Wait a few seconds and click OK when the alert box shows up
6. Scroll down to find highlighted wikitext
7. Rinse and repeat steps 3 to 6 to find more errors

Unlike the linter, this will cycle through all errors on the page.

Note: This script doesn't filter internal lint errors. So it may highlight errors not show in the linter itself. Feel free to ignore those. It is certainly possible to make it more user friendly like Help talk:Extension:Linter#h-Gadget_advertising-2017-08-10T12:07:00.000Z 197.218.89.23 (talk) 20:16, 5 October 2017 (UTC)

You already mentioned

en:User:PerfektesChaos/js/lintHint.

I am going to integrate your nice selection approach.

The API result is already present and will list details right now, but I hesitated to figure out that dsr[0] dsr[1] business.

I am heading to put an arrow button next to each error row if a source textbox is present, a click should do the selection and hopefully scrolling. PerfektesChaos (talk) 07:27, 6 October 2017 (UTC)

Okay, implementation done and under private testing.

Will be published the next days as 1.4 version.

I am glad that at least FF is autoscrolling the TEXTAREA into selection range. PerfektesChaos (talk) 13:04, 6 October 2017 (UTC)

Yes, it lacks proper documentation. Trial and error helped finding out what those dsr thingies meant. Anyway, scrolling to an area works in chrome with a snippet like this:

                 var scrollTo=  function(textarea, position) {
				if (!textarea) { return; }
				if (position < 0) { return; }
				var body = textarea.value;
				if (body) {
					textarea.value = body.substring(0, position);
					textarea.scrollTop = position;
					textarea.value = body;
				}
			};

It probably works (haven't tested) in firefox too, and other browsers. Using startrange as the position works pretty well with a few tweaks. 197.218.88.102 (talk) 18:46, 6 October 2017 (UTC)

• I have uploaded a BETA (d) pre-release online and make my fellows trying now.
• I don’t struggle with particular browsers, I kindly delegated that stuff to our jquery.textSelection module. PerfektesChaos (talk) 18:14, 7 October 2017 (UTC)

lintHint release 2 online now.

Down arrows in table whereever available.

Provides also sorting for initial order. PerfektesChaos (talk) 08:15, 12 October 2017 (UTC)

Generally looks good.

One issue though is that if the page contains a massive number of errors then it creates a huge table which makes it cumbersome to use. It might be better to add a scrollbox or something else to restrict the size of the table. Also the down arrow doesn't look clickable. 197.218.92.249 (talk) 12:19, 13 October 2017 (UTC)

• On German Wikipedia, there aren’t any pages with massive number of errors.
  • If I limit box size and introduce scroll bars, the next one will argue that survey was lost and demands for larger boxes without scroll bar.
• The arrows are language neutral.
  • They have at least an English tooltip and may be discovered incidently.
  • Once someone figured out the meaning of the arrows they won’t need further decoration.
  • This weekend I plan to update doc pages.
  • I want to keep decoration slim and performant and simple. If I put buttons inside, table rows will become higher, the entire table gets larger and someone will complain that already at an average number of errors the table is too large.

Generally thanks for nudging me to exploit the dsr infos and for your comments. PerfektesChaos (talk) 13:30, 13 October 2017 (UTC)

This page (https://de.wikipedia.org/w/index.php?title=Benutzer:Snorky/Baustelle&oldid=63039709) for example has loads of lint errors in german wikipedia, probably others too. Anyway, it is mostly aesthetics, so it doesn't matter much in the grand scheme of things.

Yes, the problem is that sometimes the dsr thing doesn't really work well and doesn't highlight anything. If the arrow doesn't react to the click so the user may be confused about whether they didn't click it properly or there are no lint errors.

Anyway, these are all small things, the script is much better with this functionality. 197.218.92.127 (talk) 15:13, 15 October 2017 (UTC)

The mentioned page name reads as User construction area, of 2009, provided by a user who did not edit since 2008.

• We won’t do syntax upgrading in “private user area”, nor on talk pages – users are responsible theirselves for their pages, and we are not maintaining discussions or private syntax experiments of a decade ago.
• Content (articles) and active project pages are in rather good shape, and we try to crunch new high priority errors quickly and clean up less important article problems.

Once the meaning of the arrows has been understood, best from doc page, they do not need further decoration.

• Currently less than a dozen registered people appear to use the tool globally, but an anonymous access might use Greasemonkey or browser script. PerfektesChaos (talk) 13:24, 16 October 2017 (UTC)

This is new to me. I read the 7-step instructions above. I use Mozilla Firefox.

1. Go to wikipage with errors: OK
2. Click edit / view source: OK
3. Open browser console: pressed Ctrl+Shift+K and this worked.
4. Paste the snippet above: Not sure where it goes; there's a command line at the bottom that seems to be intended for one line at a time, not entire scripts, but I pasted the whole script in.
5. Wait a few seconds and click OK when the alert box shows up: Nothing happens

So, how do I enter and execute a script? Anomalocaris (talk) 07:32, 18 October 2017 (UTC)

The mentioned page name reads as User construction area, of 2009, provided by a user who did not edit since 2008

That makes sense. It was just a page picked at random.

So, how do I enter and execute a script?

Firefox has a security measure to prevent inexperienced users from causing issues to themselves. So there is a keyword that must be entered on the first use of the browser console. It appears right after you paste a snippet and press enter. It was something like "allow scripts" then enter. Can't quite remember the extract phrase.

Anyway, this was just a demo showing that it can work. It might be better to use PerfektesChaos's script which now also has the ability to jump to error, seems to have been specifically tested in firefox, and is way more user friendly (doesn't require the browser console). The instructions are on this page:

User:PerfektesChaos/js/lintHint 197.218.81.33 (talk) 08:49, 18 October 2017 (UTC)

Correction: "the exact phrase." 197.218.81.33 (talk) 09:04, 18 October 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Do we need one more high priority Linter category?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello. I saw now something bad. The linter categories the page included in talk about other things. These categories did not change after the fix. I am terrified that we'll need one more high priority category. Now after 170 wikis left Tidy. Please tell me I'm stupid and it's nothing. The problem is unclosed italic/bold wiki markup in headers. Thousands of lines become unreadable. See my last edit in w:he:ויקיפדיה:דלפק ייעוץ/ארכיון118. Thank you. IKhitron (talk) 22:57, 4 December 2017 (UTC)

Yes, it is a problem that is not caught by anything right now. I am not convinced this is a very common error. But, since the breakage is so evident, the fix should be easy even after RemexHTML is deployed. In any case, we'll check if we need to introduce a new category.

Thanks for the report! :) SSastry (WMF) (talk) 23:10, 4 December 2017 (UTC)

No!!!!!!!!

Thank you, SSastry (WMF). You are welcome. Could you please cc me on phab, if it will be there? I'd like to know, what's happening with it. IKhitron (talk) 23:24, 4 December 2017 (UTC)

Will do.

We identified the high-priority linter categories by running visual diff tests on a random sample of 50K-70K pages from lots of wikis. We had to introduce the tidy-font-bug category based on enwiki reports. That is most commonly seen on non-article pages (talk pages primarily) and that didn't show up in our visual diff tests since those tests didn't sample from non-article pages. Anyway, that is the reason why I think it is unlikely to be seen on too many pages.

http://mw-expt-tests.wmflabs.org/topfails/2 is the latest set of results. If you click on the remote link there, it will show you screenshots for tidy and for remex to compare. You don't need to do anything with this -- but that is just an FYI. SSastry (WMF) (talk) 23:27, 4 December 2017 (UTC)

I agree the fix is probably easy and the error might not be very frequent. However: Dutch Wiktionary has over 600.000 pages. If there is no Linter category, how are we to find out which pages we need to fix? MarcoSwart (talk) 23:37, 4 December 2017 (UTC)

By the way, could you check, please, if the problem is also in other html tags? For example, div ... '' ... /div, and others? If it looks fine in Tidy, and wrong in HTML5, the definition should be expanded. IKhitron (talk) 23:43, 4 December 2017 (UTC)

Indeed. I am doing all kinds of tests right now to see what kind of weird things Tidy does ... I cannot wait to see Tidy gone. :) SSastry (WMF) (talk) 23:58, 4 December 2017 (UTC)

Indeed you can do, or indeed it happens in more tags? IKhitron (talk) 00:00, 5 December 2017 (UTC)

Indeed, I am checking for other tags .. so far as I can tell this only affects '' and ''' markup .. not HTML tags because of interactions with the parser and tidy/remex and the table of contents. Will continue investigating later. Time for a break. :) SSastry (WMF) (talk) 00:04, 5 December 2017 (UTC)

No, SSastry (WMF), I'm talking about the same markup, but in different tags, for example div instead h2. IKhitron (talk) 00:06, 5 December 2017 (UTC)

I am testing those combinations as well, yes. SSastry (WMF) (talk) 00:10, 5 December 2017 (UTC)

So, based on all my testing, this will only be a problem when there is an unclosed '' or ''' in headings. Since the PHP parser closes the '' and ''' at the end of the line, Tidy will simply fix the misnesting and the effect is limited to the heading. However, in the case of Remex, the unclosed i/b tag leaks over to the TOC and affects the entire page.

For regular tags, Tidy and Remex are similarly affected (with some minor caveats which can be ignored). SSastry (WMF) (talk) 00:29, 5 December 2017 (UTC)

Thank Cat. IKhitron (talk) 00:35, 5 December 2017 (UTC)

https://gerrit.wikimedia.org/r/#/c/395782 .. Separate patches coming for the Linter extension to expose these on Special:LintErrors page SSastry (WMF) (talk) 22:44, 6 December 2017 (UTC)

The Parsoid and Linter patches have been merged and will be deployed next week. So, by Thursday, these pages should be live on wikis. The corresponding help pages are now linked from Help:Extension:Linter. SSastry (WMF) (talk) 16:30, 8 December 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Hewiki switch on January 31

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello. Are you sure that hewiki is ready indeed? We have above 1,500 high categories errors for now. Noticing also Amire80, ערן, יונה בנדלאק. IKhitron (talk) 11:08, 10 January 2018 (UTC)

That is not a hard deadline, FWIW, but more of an invitation to consider it. Maybe it will motivate people to join the efforts and start fixing, so the number will we lower by then. (It is my understanding that in some cases several errors get fixed once a single relevant template is fixed, and that high priority doesn't necessarily mean the pages will look broken after the switch, however I'm not saying it's this wiki's case.) Thanks for your comment! Elitre (WMF) (talk) 11:13, 10 January 2018 (UTC)

I see. I still have many doubts. Let's see what will people say. IKhitron (talk) 11:23, 10 January 2018 (UTC)

Ikhitron: Yes, as Elitre said, this is more of an invitation to consider switching over. Looks like html5-misnesting category has a little under 350 entries in the article namespace. Relative to the size of hewiki, that is a small number overall. SSastry (WMF) (talk) 14:47, 10 January 2018 (UTC)

Are there some number criteria do you have? IKhitron (talk) 14:57, 10 January 2018 (UTC)

Ikhitron: it is upto individual wikis to decide if they are comfortable or not, but when I see an error count in the low 100s for largish wikis, it seems like a good time to consider switching. Or, in some cases, if a wiki is making good progress with their fixes (like ruwiki, for ex), this request is usually motivation to get more done before the proposed switch date. SSastry (WMF) (talk) 15:41, 10 January 2018 (UTC)

Thank you, I understand. IKhitron (talk) 16:08, 10 January 2018 (UTC)

And actually, since all the ambassadors already translated the message (!!!), Subbu is going to post it without waiting for next week. Should the community really feel strongly about that date, as we said, no problems, but this buys communities even more time :) Elitre (WMF) (talk) 20:38, 10 January 2018 (UTC)

@IKhitron I posted here on hewiki. SSastry (WMF) (talk) 21:24, 10 January 2018 (UTC)

Thank you. I fixed a little the russion version. IKhitron (talk) 21:31, 10 January 2018 (UTC)

ok. thanks. SSastry (WMF) (talk) 21:32, 10 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Importance of fixing talk pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When checking the tidy-font-bug at svwikipedia I find a lot of signatures like:

<font color="green">[[User:Example|Example]]</font>

Is it important that we fix these? Skalman (talk) 00:07, 14 January 2018 (UTC)

It depends on how important it is to your wiki that that example continues to show up in green.

Usually, I've noticed that this error is introduced on talk pages because of user signatures. So, if these links lose their custom colour and display in standard blue, then, you can ignore it and fix it with a bot at a later point. I personally think it is not a big deal. But, it depends on your wiki's community obviously. On dewiki, for example, they were / are primarily concerned with fixing lint errors in the Article namespace and aren't worried about archives and user pages and talk pages as much.

Note that even after we replace Tidy, this list of lint errors will continue to show up - so, you can fix some of these lower priority issues like talk pages gradually. SSastry (WMF) (talk) 00:16, 14 January 2018 (UTC)

Alright. In that case I'll focus on non-talk pages. Thanks! Skalman (talk) 00:19, 14 January 2018 (UTC)

dewiki has been described correctly. We focus on articles and first row project pages.

The font issue as described above influences the appearance of a personal signature only, perhaps of a user inactive for a decade now. The link is blue, not green as intended, and it works. This is under personal responsibility of that user; if they wanted long term stable design, they should not use a tag obsoleted in 1998 and put the decoration inside the brackets to be sure that the colour takes precedence over link styles.

multiple-unclosed-formatting-tags is a completely different business. If there is written intent<s>ional<s>ly now all remaining text on page catches strike-through and is not readable any more. Here we fix talk pages as well, but only since that is affecting talk contibutions of innocent users rather than the villain. PerfektesChaos (talk) 10:07, 15 January 2018 (UTC)

@Skalman https://sv.wikipedia.org/wiki/Anv%C3%A4ndardiskussion:Nirmos#Suggestion_for_Linter_fixes has some tips for how some html5 misnesting issues could be fixed. SSastry (WMF) (talk) 04:18, 17 January 2018 (UTC)

@SSastry (WMF), thanks for the suggestion. I'll probably fix a few of the errors, but it feels like a bot would actually be needed... Skalman (talk) 18:18, 17 January 2018 (UTC)

One hacky fix is to update the templates to change the '' to <i> and ''' to <b> tag. That ensures that the quotes in the pages won't conflict with the i/b tags in the templates. That will cause the HTML to be <i><i>..</i></i> ... or <b></b>..</b></b> .. but that won't cause any problems.

I think that is how itwiki folks tackled this kind of issue. SSastry (WMF) (talk) 18:21, 17 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Alternate source of lists? API?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I am trying to pull lists to run in w:Wikipedia:Autowikibrowser and apart from not being able to make a list natively within the app, I cannot see that there is another means to get a list. Copying and pasting the page output is a PITA as it has superfluous columns. Is there other means to generate lists to be run for those of us more simple in our approach? Thanks. — billinghurst sDrewth 12:38, 22 January 2018 (UTC)

I have been pointed to Extension:Linter#API. It may be worth adding some data to the help page. — billinghurst sDrewth 13:14, 22 January 2018 (UTC)

There's the API that you could use to generate a list, or the database tables are also replicated to toolforge so you could make lists that way. Legoktm (talk) 17:15, 22 January 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Change in Special:LintErrors ?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'm working on cleaning up Lint errors on cebwp with my bot. Been making steady progress for some time, but today suddenly the error counts in Special:LintErrors on cebwp jumped back up by the hundreds of thousands. What has changed? Lsj (talk) 20:10, 9 February 2018 (UTC)

Interesting. Yes, this is a fallout of https://phabricator.wikimedia.org/T184280 wherein we changed our error counts from exact numbers to "estimates". And, so, that is probably why you saw this. @Legoktm FYI. The counts went from about 480K to 710K. Is this kind of change expected? SSastry (WMF) (talk) 22:29, 9 February 2018 (UTC)

The same is true of enwiki as well -- the counts have all more or less doubled from what they where. Hmm ... SSastry (WMF) (talk) 22:31, 9 February 2018 (UTC)

The numbers decrease steadily with further bot running - but they decrease by much more than one per bot edit. Fixing 1,000 errors decreases the estimate by several thousands. Lsj (talk) 11:55, 10 February 2018 (UTC)

Correction to previous post. Numbers are jumping up and down without obvious pattern, +/- 10,000-100,000 or so. Lsj (talk) 14:23, 11 February 2018 (UTC)

Apparently the dashboard (https://tools.wmflabs.org/wikitext-deprecation/) simply extracts the data from the wiki / API, so it too is wrong. It seems like might be simpler to extract the whole list and count it clientside using the api directly as it doesn't seem useful for a bot to check the count anyway (Extension:Linter#API).

Unfortunately, that is likely to take an hour or more on a wiki with so many errors. Once it gets to a lower number of errors counting doesn't seem to be a problem anymore. Another benefit of doing it clientside is that ability to get a count of errors of other namespaces.

Long term, it might be useful for the linter to have an export facility like Special:Export that dumps all lint errors. 197.218.89.76 (talk) 15:38, 11 February 2018 (UTC)

But, your comment points to something else ... an alternative to doing live counts (besides fixing the code to run background queries) would be to have the deprecation dashboard run precise counts off database replicas on a labs VM. SSastry (WMF) (talk) 18:21, 11 February 2018 (UTC)

Yes, there is little value in updating the counting regularly for wikis with lots of errors. They'll still have 10 Milllion + errors one hour later or a day later. In fact, in any highly active wiki the count will be wrong more often than not (because of race conditions), e.g. by the time someone looks at the category page, a delayed updated may add 100 more items.

Perhaps it would be wise to add a huge disclaimer that the count is an estimate and add a link to a separate resource if they really want relatively up to date statistics updated hourly or so.

In any case people are used to it (e.g. with maintenance reports). 197.218.89.196 (talk) 19:07, 11 February 2018 (UTC)

The problem right now are that are far too many errors in low priority categories on english and commons wikipedias. So, dumping will take far too long. (70M on commons, and 20-30M on english).

@Legoktm one compromise would be to use precise counts for high and medium priority categories and estimates for lower priority categories. SSastry (WMF) (talk) 18:11, 11 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

List tag

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

After migrating to remex something changed in lists, see https://fi.wikipedia.org/w/index.php?title=Anja_P%C3%A4rson&diff=prev&oldid=15409643#L%C3%A4hteet how it looked when there was an unneeded asterisk.

And see the Commons template here: https://web.archive.org/web/20160828001900/https://fi.wikipedia.org/wiki/Anja_P%C3%A4rson. It looks fine there, but in the current version there is extra asterisk https://fi.wikipedia.org/wiki/Anja_P%C3%A4rson which comes from https://fi.wikipedia.org/wiki/Malline:Commons-rivi. The problem was noticed at https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(tekniikka)#Commonscat-rivi Stryn (talk) 17:39, 13 February 2018 (UTC)

Possibly an issue with the "remove empty elements" feature of remex/tidy? cscott (talk) 20:18, 13 February 2018 (UTC)

In looking at https://fi.wikipedia.org/w/index.php?title=Anja_P%C3%A4rson&oldid=15409643&action=parsermigration-edit, I see an extra asterisk in both cases (Tidy & Remex), except, they are aligned differently. In any case, it looks like you've fixed the problem in Template:Commons-rivi

Are you asking why Linter didn't report this difference? Assuming that is your question, Linter does not look for all possible differences between Tidy and Remex. We are only tracking the most common cases that have been discovered through automated testing, manual inspection, and reports through early deployments such as yours. We are open to introducing new categories in case you discover something that is broken on fiwiki that is found on a lot of pages.

Thanks for the report! SSastry (WMF) (talk) 22:08, 13 February 2018 (UTC)

We have now 5 395 articles with an extra asterisk (only including those using the Commons-rivi template), there were none(?) before the migration. So I think that's a lot of pages. Stryn (talk) 13:23, 14 February 2018 (UTC)

@Stryn Thanks for pointing that out. Is there is something you want us to do here? Or, are you reporting this as one more Tidy vs. Remex issue as an FYI? SSastry (WMF) (talk) 16:21, 14 February 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Spaces in nested lists are interpreted as genuine spaces with the new parser, spoil .hlist behaviour

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

On wikis where @Edokter's .hlist class is in use (enwiki, ruwiki, frwiki etc.), nested lists fail to render correctly when spaces after asterisks/colons are used. In ruwiki, where this is the standard code style, it became a common issue after new parser got deployed, and edits like this have to be made, which spoils the codestyle.

Code

* Item
** Subitem
** Subitem

Expected view
Item (Subitem • Subitem)

Actual view
Item ( Subitem • Subitem)

I guess, spaces after asterisks/colons in the beginning of a line shouldn't be treated as genuine spaces, appearing in the result HTML.

Should I post it to Phabricator instead of here? Jack who built the house (talk) 21:32, 15 February 2018 (UTC)

Hmm .. yes, this is https://phabricator.wikimedia.org/T157418. We'll tackle this soon. SSastry (WMF) (talk) 00:42, 16 February 2018 (UTC)

@Jack who built the house, I've updated the description of T157418 and have scheduled it for an RFC discussion. If you have any thoughts on the specific questions in the description, please weigh in there. SSastry (WMF) (talk) 16:48, 21 February 2018 (UTC)

And @Edokter too. SSastry (WMF) (talk) 16:49, 21 February 2018 (UTC)

@Jack who built the house @Stryn The changes to wikitext parsing to deal with this issue as part of T157418 has now been deployed. Please let me know if hlist issues are resolved on ruwiki (you may need to purge the cached contents of a page to verify). SSastry (WMF) (talk) 00:21, 23 March 2018 (UTC)

@SSastry (WMF): As far as I can see, they are resolved, thanks. Jack who built the house (talk) 11:52, 23 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Pages in Special:LintError categories not updating

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I edited pages in lint errors from wikipedia,simple english wikipedia,and 2 other wikipedias. But the update is not happening in the list. Not even a single edit made by me is getting updated from the linter category. Adithyak1997 (talk) 13:37, 4 March 2018 (UTC)

If the number of corrections is small, this is normal at the moment. It can take several days before the Special page is updated. I remove errors on a daily basis at nl.wiktionary.org and I am experiencing the same. Somewhere I read that updating small changes more often was causing technical problems. MarcoSwart (talk) 15:42, 4 March 2018 (UTC)

Something might be temporarily broken with the update mechanism -- normally, it takes a little while for updates to propagate, but 24 hours is too long. User talk:SSastry (WMF)/Flow export#h-Lint_errors_(tr.wiki)-2018-03-03T19:39:00.000Z has another report from an user on Turkish Wikipedia. We'll investigate this tomorrow. SSastry (WMF) (talk) 18:05, 4 March 2018 (UTC)

For at least weeks now, in English Wikipedia, it has said "Multi colon escape (2 errors)", even though there are no such errors. Anomalocaris (talk) 18:38, 19 April 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Lint error

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Has the problem of non updation of wikipedia pages fixed?I am now able to update many of the pages and the sub list is getting updated but the page Secial:Lint errors is not getting updated. Adithyak1997 (talk) 08:24, 7 March 2018 (UTC)

Those things are unrelated. The counts on the main page do not update immediately, maybe an hour at most. Bdijkstra (talk) 08:30, 7 March 2018 (UTC)

No. It usually gets updated within seconds.Only in one or two cases it updated later. I have checked it for many days. Adithyak1997 (talk) 09:11, 7 March 2018 (UTC)

@Bdijkstra is correct. (a) the counts are cached and so, they won't update immediately (b) if a category has lots of errors (beyond a few thousand, I assume), we report estimated counts and not actual counts. So, for one or both reasons, you may not see the counts updated. SSastry (WMF) (talk) 16:57, 7 March 2018 (UTC)

To me this is not a big issue, but the answer by @SSastry (WMF) is not what I see a the moment. At Dutch Wiktionary we only have small numbers of errors left. On Tuesday March 6 at 00:40 CET I fixed 2 missing end tags, which was reflected immediately on the subpage, but at the moment, 48 hours later, the main page Speciaal:LintErrors is still showing the old number. MarcoSwart (talk) 00:35, 8 March 2018 (UTC)

Looks like https://nl.wiktionary.org/wiki/Speciaal:LintErrors is now showing everything at zero. I suppose it took longer than I would have imagined for the counts to update. But, will keep out an eye for this. SSastry (WMF) (talk) 04:46, 8 March 2018 (UTC)

When I view this page "Afsluitende tag ontbreekt" (=missing end tags) is still showing "10", but when I click that link only 8 pages (the correct number) are shown. Is there a way I can 'purge the cache' of this Special page? MarcoSwart (talk) 06:55, 8 March 2018 (UTC)

The Special page https://nl.wiktionary.org/wiki/Speciaal:LintErrors was updated around this evening, Sunday March 10, around 19:00 CET, after about 138 hours. There was a new, recent error which I corrected and I will let you know when this shows up on the Special page. Again: the subpage is working fine, so in our case it is not really a problem. MarcoSwart (talk) 20:08, 10 March 2018 (UTC)

@MarcoSwart .. this could also be related to the fact that we no longer generate actual counts, but use estimated counts. I assumed that estimated counts will be accurate for small values under 1000 or so, but that may have been an incorrect assumption. SSastry (WMF) (talk) 23:21, 10 March 2018 (UTC)

That is is probably the correct explanation. I vaguely remember an announcement stating something like this before I started seeing a delay in updates. MarcoSwart (talk) 15:02, 11 March 2018 (UTC)

It is probably a good idea to add a basic message similar to the special maintenance reports (e.g. Special:wantedpages saying results are estimates) so people don't keep reporting this. Alternatively considering that the number can be wildly inaccurate it may be best to simply remove it completely and be done with it.

Its probably easier to introduce a basic count of the visible errors within the sub pages, e.g. Special:LintErrors/deletable-table-tag. At least that will always be accurate, as it could only report visible items, even if the pages there are still in cache. 197.218.88.6 (talk) 15:18, 11 March 2018 (UTC)

The main page Special:LintErrors on Dutch Wiktionary has been updated this morning, showing as a new find an old page with both a misnested tag and an obsolete tag, which of course have been corrected by now. What puzzles me is that the counter for "Missing end tag" was and is at 11 pages, with the corresponding subpage only showing the 8 pages that have become our baseline. If it had been 10 I would consider it the result of rounding, but how do we get to 11? MarcoSwart (talk) 11:16, 12 March 2018 (UTC)

There was another update, showing 1 stripped tag en 0 for both the misnested and obsolete tags. Only the Missing end tag remains stubbornly at 11, while the subpage is showing the correct number, 8. MarcoSwart (talk) 16:03, 14 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Search for special page

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Is there an tool in which to enter the name of the page and would show all the errors for it? (not a PerfektesChaos script) For ordinary users. For example on special:LintErrors it would be a search field and would show all categories for one page. So someone could just check out their "interesting" pages without scrolling through the list. Or if the page in remex is now shown as "broken" then it would be possible to quickly find the reason (for example, with unclosed s tag). Sunpriat 12:42, 13 March 2018 (UTC)

You could use Extension:Linter#API perhaps? SSastry (WMF) (talk) 14:18, 13 March 2018 (UTC)

Once https://phabricator.wikimedia.org/T164006 is fixed (soon), you will also get a REST API endpoint which you can issue GET requests to for a specific title (or title & revision). SSastry (WMF) (talk) 20:29, 13 March 2018 (UTC)

I can use it. But I would not want to constantly be a medium between script/api and the user responding to "why half the page is line-through". It would be nice to send users to the tool that they themselves would use. Sunpriat 03:21, 14 March 2018 (UTC)

I see .. you want this integrated into the LintErrors special page. Let us take a look. SSastry (WMF) (talk) 05:34, 14 March 2018 (UTC)

I have made simple user script: ja:User:MawaruNeko/ShowPageLintError.js. I hope it could be helpful. MawaruNeko (talk) 12:06, 14 March 2018 (UTC)

I see the tool is in the relevant section, can this thread be closed? Elitre (WMF) (talk) 13:49, 2 May 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

LintError info not updated for 6 months

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I fixed a self-closing tag error on August 2017, but on Special:LintErrors it still appears as not fixed. Here is the url: https://bg.wikipedia.org/wiki/Special:LintErrors/self-closed-tag.I fixed the same error in the same script, but from the User namespace (a contributor has created a version of it for personal purpose) and all is fine with it. Does anybody have an idea where could be the problem? I suppose that something is not updating properly in the DB. StanProg (talk) 13:24, 30 March 2018 (UTC)

We stopped linting non-wikitext content models. You must have fixed the error after we did that. So, that is very likely the reason this is not updating. SSastry (WMF) (talk) 14:56, 30 March 2018 (UTC)

Shouldn't such non-wikitext content models be cleared from the reported errors? This is some kind of missynchronization. Can this be cleaned? StanProg (talk) 15:24, 30 March 2018 (UTC)

Yes, we'll take a look. SSastry (WMF) (talk) 16:24, 30 March 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Table inside table lint

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I've been trying to fix w:yue:Template:選舉資訊 but found that I couldn't delete the nested table tags without breaking the formatting specifications. Any suggestions on how to fix this template? It has hundreds of transclusions and make up a significant proportion of the errors on yue.wp. Deryck C.^Meta 17:59, 1 May 2018 (UTC)

Try deleting this line:

{| class="infobox_v2 {{#if:{{{選舉日期|}}}|vevent}}" style="width:22em; font-size:90%; width:{{#expr:{{{代表圖片尺寸|45}}}*{{#if:{{{候選人3|}}}{{{政治聯繫3|}}}|4|3}}}}px;"

I don't think that applies to the pages anyway. Or, have you tried it and find that it breaks something? SSastry (WMF) (talk) 20:23, 1 May 2018 (UTC)

I haven't tried deleting the whole line because I was trying to preserve some of the CSS options on that line, not knowing they would've been ignored by MediaWiki anyway! (I didn't create the template.)

I tried your proposed change and checked a few pages. It seems to be okay. If it breaks anything I'll come back to let you know. Deryck C.^Meta 20:54, 1 May 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

attributes with unpaired quotes

Notice about a parsing change that causes this will go out in Tech News when more information will be given.

Consider the following wikicode:
{| style="background-color: #eb6841; style="text-align: center;"

It seems that with Tidy previously, the table would not be colored red, but with RemexHTML now it does. Should this be flagged by the linter? Bdijkstra (talk) 14:50, 16 December 2018 (UTC)

This is more likely to do with,

https://github.com/wikimedia/mediawiki/commit/59bb8864a23f3df120789c7619ef07acefa27b9c Arlolra (talk) 18:34, 16 December 2018 (UTC)

Ah OK. But since this parsing change, a page's layout can break via an unrelated edit, so I would have expected a notice in Tech News to at least prevent confusion. Bdijkstra (talk) 19:33, 16 December 2018 (UTC)

Sorry about that, it's my fault. There was a bit of discussion about the repercussions of the change at the bottom of,

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471363

Do you think it's worth adding to the next edition of Tech News? Arlolra (talk) 21:56, 16 December 2018 (UTC)

A broken page layout is not always noticed, and even then not always reported. So I think it would be good to let technical editors know which patterns are now treated differently. Bdijkstra (talk) 22:11, 16 December 2018 (UTC)

Ok, I added in here, https://meta.wikimedia.org/w/index.php?title=Tech/News/2019/02&type=revision&diff=18722210&oldid=18709064&diffmode=source Arlolra (talk) 19:30, 17 December 2018 (UTC)

Great, thanks. I'm glad that you watch this page! :) Bdijkstra (talk) 19:41, 17 December 2018 (UTC)

Hey, I'm handling Tech News for this week.

How would you summarize that change in one sentence? How will in impact users? Do you have a tracking ticket on Phabricator about that?

Thanks! Trizek_(WMF) (talk) 14:16, 3 January 2019 (UTC)

Since I have no reply but I have to wrap-up and freeze the current issue, I've posted your previous explanation to next week issue.

Please provide there a shorter explanation. :) Trizek_(WMF) (talk) 14:17, 4 January 2019 (UTC)

@Bdijkstra, any updates? Trizek_(WMF) (talk) 14:36, 9 January 2019 (UTC)

Not from me. I assumed you were asking @Arlolra. I don't understand the change well enough to be able to figure out which wikicode patterns are now treated differently. Bdijkstra (talk) 14:50, 9 January 2019 (UTC)

How about ...

Quoted attributes used to require being followed by a space, now they do not. Since this is a change to how a page is parsed it could cause unmodified portions of the page to render differently on edit. Arlolra (talk) 20:56, 9 January 2019 (UTC)

Thanks! I simplified that a fair bit, for the benefit of non-native and/or non-technical readers. You can see the draft at m:Tech/News/2019/03. Johan (WMF) (talk) 07:56, 10 January 2019 (UTC)

No reset of error count

I am used to Special:LintErrors on nl.wiktionary showing estimated numbers. But the line "missing end-tag" for the last weeks has been showing an increasing total, not reflecting that all new errors have been corrected. Has there been a change in the way the total is estimated? At present the page is becoming pretty useless. MarcoSwart (talk) 22:45, 17 February 2019 (UTC)

There has been no change to how it is done. It is based on estimates provided by mysql. SSastry (WMF) (talk) 17:24, 18 February 2019 (UTC)

But how is this estimate computed? I looks like the removal of errors has no or only a very slow effect on the estimate. If it is meant to encourage that errors are removed, this seems counterproductive. And even as a tool is has become useless: I have to look at the subpage to find out whether there are any new errors. MarcoSwart (talk) 17:46, 18 February 2019 (UTC)

The estimation code is pretty wacky, see https://www.percona.com/blog/2011/10/13/when-explain-estimates-can-go-wrong/ and https://stackoverflow.com/questions/1037471/why-the-rows-returns-by-explain-is-not-equal-to-count, https://phabricator.wikimedia.org/rMW6261b4187a91099f4f2fd900562506cf2b3df984 . The hard part is probably fixing the estimate.

The stackoverflow link suggests that using analyse instead of explain will yield better results (at least with mariadb they seem to output different results).

Anyway, the alternative is pretty simple, whenever the number of rows returned by the estimate are less than 5000, simply run the full sql query, or instead of getting the estimate, just re-run the query clientside using javascript api once the special page loads. 197.235.225.166 (talk) 18:55, 18 February 2019 (UTC)

https://nl.wiktionary.org/wiki/Speciaal:LintErrors/missing-end-tag currently estimates 26, and lists 12. I don't know what the numbers were when Marco looked at it yesterday. Whatamidoing (WMF) (talk) 00:22, 19 February 2019 (UTC)

If I remember correctly: estimate 23, listed 10 (8 of which are more or less permanent, the other 2 were resolved. Now we have 4 new errors on new pages, bringing the total back to 12. But the actual number remains most of the time close to 8. There has been a single time a few weeks ago when a single page once contained a larger number of errors, pushing the total over 20 for just one day. Somehow I get the feeling that the estimate keeps using this single instance as a basis. MarcoSwart (talk) 00:45, 19 February 2019 (UTC)

The new errors were corrected this afternoon (local time 13:30), so the actual number became 8 again. At the moment (local time: 19:45) the total is back to 23. MarcoSwart (talk) 18:49, 19 February 2019 (UTC)

All this is just the behavior of the database estimation tool.

As the anon user above indicated, the solution for this is for us to update the code to do an actual count when the # of results is estimated to be under some threshold that has acceptable performance from the DBA point of view. SSastry (WMF) (talk) 20:49, 19 February 2019 (UTC)

Is there anything I can do to help bring this about? MarcoSwart (talk) 22:41, 19 February 2019 (UTC)

It requires development to be done on the Linter codebase. We are currently heads down on the high-priority work of porting Parsoid to PHP and we are unable to pick up linting improvements till we are past that milestone. SSastry (WMF) (talk) 22:51, 19 February 2019 (UTC)

But, if you are a developer or know someone who wants to work on linter improvements before then, I could probably squeeze in time to help with code review and guiding the work. SSastry (WMF) (talk) 22:53, 19 February 2019 (UTC)

Separate the center tag from the obsolete

It will be convenient to separate a category with a center tag from an obsolete category. All tags are relatively easy to update, but the center is widely used in image captions. Because of this (disputes over the design of articles), the center is more difficult to replace. But other tags can be updated much faster. In general, the center tag takes many lines in Linter/obsolete-tag and you have to go to the next page many times to find another tag. Sunpriat 17:26, 18 May 2019 (UTC)

If it's widely used in image captions, perhaps there should be a more structured way to specify that the caption should be centered.

I suggest going even further and separating all the tags, so that it will be possible to get a list of pages that use each tag. Amir E. Aharoni {{🌎🌍🌏}} 18:26, 18 May 2019 (UTC)

I would like to know why wikitext for images does not provide for the alignment of image captions. Perhaps there were reasons for this.

Yes, categories missing-end-tag and obsolete-tag (and stripped-tag; for example, it is convenient to have a separate list for table tags) are huge and split them into smaller ones could be helpful. Small categories are easier to handle (and more enthusiastic) than such large (hundreds of thousands) ones with "infinite scrolling." Sunpriat 13:11, 19 May 2019 (UTC)

I don't think that it was intentionally not allowed. The people who designed the captions years probably just thought that aligning them to the same side where the paragraphs begin is what's needed. I actually haven't seen a lot of images with centered captions, but maybe they are common in the wiki where you write often.

In general, design of pages across different languages should be as similar as possible unless there is a particular reason to do something differently. If there is a reason to make captions centered in the Russian Wikipedia in some cases, then maybe they should also be centered in these cases in all other languages. Or maybe they shouldn't Can you give me some examples of centered captions? Amir E. Aharoni {{🌎🌍🌏}} 06:36, 20 May 2019 (UTC)

You can read a little here [2] [3]. When I just deleted the center then they say "you broke my design", "I see it in that way". This is complicated by the fact that a center class is often adds to the gallery tag, in the infoboxes and panoramas the centered image caption, in books, reports on academic/university works pictures and captions often require to be centered. For examples you can use regexp in search >5k articles with a center tag (apart from what has been done through the template:center). Sunpriat 13:43, 20 May 2019 (UTC)

In Infoboxes and other templates it should be done by the template.

I read the pages and I'm still wondering why would anyone want to make usual image captions in articles centered. Is it systematic, or is it just a choice in certain articles? Amir E. Aharoni {{🌎🌍🌏}} 19:49, 20 May 2019 (UTC)

It is already by the template and it is centered, which differs from the design of simple-wikitext images in the text.

They see it in the sources (e.g. 1 2), and in them it because of the layout requirements ("Справочник издателя и автора А. Мильчин", "Гиленсон Справочник художественного и технического редакторов", "ГОСТ 7.32-2001 6.5.4", I think something in this direction) for the books and the other. Sunpriat 20:26, 20 May 2019 (UTC)

Um... Well, it's up to the Russian Wikipedia to decide. I know Russian, but I don't write in the Russian Wikipedia much. I will add, though, that it really shouldn't be different in different articles, and there should be really good reasons to change the default design anywhere. Amir E. Aharoni {{🌎🌍🌏}} 07:59, 21 May 2019 (UTC)

Sorry folks .. the linter UI needs some serious work at some point.

As for the center tag, we could suppress it, but the question is if this preference for center tag is specific to russian wikipedia or something that is common on multiple wikis. Do either of you know? SSastry (WMF) (talk) 15:42, 21 May 2019 (UTC)

It's a question for @Sunpriat.

I'd say that it shouldn't be suppressed.

My tip to @Sunpriat is to bypass the special page and write a bit of JavaScript that reads the pages data from the API, and then filter out the tags you don't need. It should be easy for anyone who is familiar with using JavaScript on MediaWiki, but I can help if needed. Amir E. Aharoni {{🌎🌍🌏}} 19:00, 21 May 2019 (UTC)

@Amire80 ok, for API, how can I get from https://ru.wikipedia.org/wiki/Special:LintErrors/missing-end-tag separately the data for one type (td) from the second column? Sunpriat 19:22, 21 May 2019 (UTC)

I couldn't find any instances of 'td' in the first 500 results, but here's something for 'center':

api = new mw.Api();
api.post( {
	"action": "query",
	"format": "json",
	"list": "linterrors",
	"lntcategories": "missing-end-tag",
	"lntlimit": "500",
	"lntnamespace": "0"
} ).done ( function ( result ) {
	for ( i = 0; i < result.query.linterrors.length; i++ ) {
		if ( result.query.linterrors[i].params.name === 'center' ) {
			console.log( result.query.linterrors[i].title );
		}
	}
} );

You can run it in the browser JavaScript console while viewing a page in the Russian Wikipedia.

It's super-rudimentary, but works :) Amir E. Aharoni {{🌎🌍🌏}} 19:42, 21 May 2019 (UTC)

As it seems to me, it is the WMF that should consult with the typographers and clarify point around alignment (and center) everywhere for us in the guideline https://design.wikimedia.org/style-guide/visual-style_typography.html . In the infocards, image caption centered even in en-wiki ( https://en.wikipedia.org/wiki/Tibial-fibular_trunk ). Sunpriat 19:02, 21 May 2019 (UTC)

dewiki fixed all old lint errors

I just wanted to inform you that in dewiki all old lint errors in all namespaces got fixed, the last ones today. hgzh 20:07, 21 September 2023 (UTC)

You're welcome to continue on other wikis. Bdijkstra (talk) 20:50, 21 September 2023 (UTC)

Dutch wikibooks was "clean" almost three months ago. Erik Baas (talk) 00:13, 22 September 2023 (UTC)

Barnstar of Diligence

Hurra, und danke an all die wunderbaren Mitwirkenden!

(Sorry, I haven't learned any Dutch.) That's great news for both wikis. Whatamidoing (WMF) (talk) 18:47, 25 September 2023 (UTC)

I want to echo the congrats -- well-deserved barnstar! :-) SSastry (WMF) (talk) 20:14, 25 September 2023 (UTC)

Enabling a new lint category template-arg-in-extension-tag

Hello everyone!

We’d like your feedback on enabling a new lint category: template-arg-in-extension-tag.

This lint helps find cases where template parameters are used inside extension tags written as <tagname>...</tagname> (in tags that allow wikitext inside). It does not apply to the {{#tag:...}} form. Cleaning up these cases will help ensure consistent and reliable page rendering across wikis.

Why this matters

Parsoid, the system that will soon power read views on many Wikipedias, treats these two forms differently:

• <indicator>...</indicator> → template parameters don’t always work correctly, because they’re evaluated later than expected.
• {{#tag:indicator|...|...}} → template parameters work reliably, since they’re evaluated right away.

There are no current plans to change how Parsoid handles template parameters inside <tagname>...</tagname> tags. This is a rare use case, and the reliable {{#tag:...}} form is already available. While support for the old form might be reconsidered someday, it should not be expected. For now, the safe solution is to use {{#tag:...}} when template parameters are involved.

Why this lint is considered a high priority

• The issue already affects Page status indicators and may impact other extensions.
• The fix ({{#tag:...}}) is simple and available today.
• Since Parsoid will soon be the default for read views, preparing content now helps avoid disruption later.

If you have concerns or objections, please let us know here or on task T348722. Otherwise, we’ll move forward with enabling this lint. OSleger-WMF (talk) 15:49, 16 October 2025 (UTC)

Thank you for creating a documentation page before rolling this out. Please go down your checklist for new Linter errors and ensure that the new error is listed on all relevant pages. If you somehow do not have a checklist yet, please make one before rolling out this new error. Jonesey95 (talk) 15:38, 31 October 2025 (UTC)

The checklist is at Parsoid/Adding_a_new_lint_category ABreault (WMF) (talk) 19:32, 31 October 2025 (UTC)