Help talk:Extension:Linter

About this board

Separate the center tag from the obsolete

Sunpriat (talkcontribs)

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.

Amire80 (talkcontribs)

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.

Sunpriat (talkcontribs)

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

Amire80 (talkcontribs)

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?

Sunpriat (talkcontribs)

You can read a little here . 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).

Amire80 (talkcontribs)

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?

Sunpriat (talkcontribs)

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.

Amire80 (talkcontribs)

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.

SSastry (WMF) (talkcontribs)

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?

Amire80 (talkcontribs)

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.

Sunpriat (talkcontribs)
Amire80 (talkcontribs)

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

api = new mw.Api(); {
	"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] === '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 :)

Sunpriat (talkcontribs)
Reply to "Separate the center tag from the obsolete"
MarcoSwart (talkcontribs)

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.

SSastry (WMF) (talkcontribs)

There has been no change to how it is done. It is based on estimates provided by mysql.

MarcoSwart (talkcontribs)

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. (talkcontribs)

The estimation code is pretty wacky, see and, . 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.

Whatamidoing (WMF) (talkcontribs)
MarcoSwart (talkcontribs)

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 (talkcontribs)

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.

SSastry (WMF) (talkcontribs)

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.

MarcoSwart (talkcontribs)

Is there anything I can do to help bring this about?

SSastry (WMF) (talkcontribs)

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) (talkcontribs)

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.

Reply to "No reset of error count"

attributes with unpaired quotes

Summary last edited by Trizek (WMF) 14:36, 9 January 2019 3 years ago

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

Bdijkstra (talkcontribs)

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?

Arlolra (talkcontribs)
Bdijkstra (talkcontribs)

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.

Arlolra (talkcontribs)
Bdijkstra (talkcontribs)

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.

Arlolra (talkcontribs)
Bdijkstra (talkcontribs)

Great, thanks. I'm glad that you watch this page! :)

Trizek (WMF) (talkcontribs)

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?


Trizek (WMF) (talkcontribs)

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) (talkcontribs)
Bdijkstra (talkcontribs)

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.

Arlolra (talkcontribs)

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.

Johan (WMF) (talkcontribs)

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.

Reply to "attributes with unpaired quotes"

Gadget advertising

Summary by SSastry (WMF)

The gadgets are now listed on the help page

PerfektesChaos (talkcontribs)

Please see lintHint@PerfektesChaos with functionality:

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


Elitre (WMF) (talkcontribs)

@PerfektesChaos, hi, would you like to add a link about it on the actual page perhaps? It only needs a basic description.

PerfektesChaos (talkcontribs)

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.

Elitre (WMF) (talkcontribs)

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.

PerfektesChaos (talkcontribs)

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.

Elitre (WMF) (talkcontribs)

I guarantee this is not the case. Us being around does not mean we own these pages, by any means.

Deryck Chan (talkcontribs)

Do we have a curated list of tools available for semi-automatically fixing all these (linted) errors?

Elitre (WMF) (talkcontribs)

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

Deryck Chan (talkcontribs)
Elitre (WMF) (talkcontribs)

That one.

PerfektesChaos (talkcontribs)

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.

Elitre (WMF) (talkcontribs)

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.

PerfektesChaos (talkcontribs)


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.

Sakretsu (talkcontribs)
  • 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.

Daimona Eaytoy (talkcontribs)

@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"

PerfektesChaos (talkcontribs)

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 (talkcontribs)

@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:

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.

Daimona Eaytoy (talkcontribs)

Tested it, everything seems fine, well done! And yeah, we'll provide some kind of translation there once ready. Thanks again!

PerfektesChaos (talkcontribs)

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.

Reply to "Gadget advertising"
Sunpriat (talkcontribs)

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

SSastry (WMF) (talkcontribs)
SSastry (WMF) (talkcontribs)
Sunpriat (talkcontribs)

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.

SSastry (WMF) (talkcontribs)

I see .. you want this integrated into the LintErrors special page. Let us take a look.

MawaruNeko (talkcontribs)
Elitre (WMF) (talkcontribs)

I see the tool is in the relevant section, can this thread be closed?

Pages in Special:LintError categories not updating

Summary by SSastry (WMF)
Adithyak1997 (talkcontribs)

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.

MarcoSwart (talkcontribs)

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 and I am experiencing the same. Somewhere I read that updating small changes more often was causing technical problems.

SSastry (WMF) (talkcontribs)

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. Topic:U8oc5a9rj7me4qt0 has another report from an user on Turkish Wikipedia. We'll investigate this tomorrow.

Anomalocaris (talkcontribs)

For at least weeks now, in English Wikipedia, it has said "Multi colon escape (2 errors)", even though there are no such errors.

Deryck Chan (talkcontribs)

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.

SSastry (WMF) (talkcontribs)

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?

Deryck Chan (talkcontribs)

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.

LintError info not updated for 6 months

Summary by SSastry (WMF)
StanProg (talkcontribs)

I fixed a self-closing tag error on August 2017, but on Special:LintErrors it still appears as not fixed. Here is the url: 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.

SSastry (WMF) (talkcontribs)

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.

StanProg (talkcontribs)

Shouldn't such non-wikitext content models be cleared from the reported errors? This is some kind of missynchronization. Can this be cleaned?

SSastry (WMF) (talkcontribs)

Yes, we'll take a look.

User unfriendly script to find errors

Summary by

See User:PerfektesChaos/js/lintHint for a more userfriendly tool (talkcontribs)
var currError = currError || 0;
var tmpWikitext = tmpWikitext || "";
var lintData = lintData || [];
var textArea = document.getElementById('wpTextbox1');
var selectRange = function(start, end) {
	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);; } /* 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];
		selectRange(startRange, endRange);
if (tmpWikitext === $("#wpTextbox1").val() && lintData.length - 1 > 0 ) {
	if ( currError >=  lintData.length) {
		currError = 0;
	} else { currError = currError + 1; }
	getError(lintData, currError );

} 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);


  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 Topic:Tvyz5k6ki39kba6t

PerfektesChaos (talkcontribs)

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 (talkcontribs)

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. (talkcontribs)

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.

PerfektesChaos (talkcontribs)
  • 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 (talkcontribs)

lintHint release 2 online now.

Down arrows in table whereever available.

Provides also sorting for initial order. (talkcontribs)

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.

PerfektesChaos (talkcontribs)
  • 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. (talkcontribs)

This page ( 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.

PerfektesChaos (talkcontribs)

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.
Anomalocaris (talkcontribs)

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? (talkcontribs)
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 (talkcontribs)

Correction: "the exact phrase."

Change in Special:LintErrors ?

Summary by SSastry (WMF)

The linter extension now displays a prominent note that the counts are estimates, not actual numbers.

Lsj (talkcontribs)

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)

SSastry (WMF) (talkcontribs)

Interesting. Yes, this is a fallout of 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) (talkcontribs)

The same is true of enwiki as well -- the counts have all more or less doubled from what they where. Hmm ...

Lsj (talkcontribs)

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 (talkcontribs)

Correction to previous post. Numbers are jumping up and down without obvious pattern, +/- 10,000-100,000 or so. (talkcontribs)

Apparently the dashboard ( 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.

SSastry (WMF) (talkcontribs)

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. (talkcontribs)

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

SSastry (WMF) (talkcontribs)

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.