Benutzer Diskussion:PerfektesChaos/js/lintHint

Babel:
de Diese Person spricht Deutsch als Muttersprache.
en-3 This user is able to contribute with an advanced level of English.
fr-1 Cette personne sait contribuer avec un niveau élémentaire de français.
Benutzer nach Sprache

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 5 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

Lint error misdetecting..

Here: https://en.wikisource.org/w/index.php?title=Page:The_four_feathers.djvu/12&action=edit

It's claiming stripped tags, there should not be any as the template calls are matched up.

Please update your code accordingly, to account for header, body, footer template usage. ShakespeareFan00 (Diskussion) 10:17, 12. Mär. 2018 (CET)

Another mis-detection - https://en.wikisource.org/wiki/Page:Niger_Delta_Ecosystems-_the_ERA_Handbook,_1998.djvu/253

ShakespeareFan00 (Diskussion) 10:57, 12. Mär. 2018 (CET)

Odd interaction on Wikisource

Sometimes, if I have the tool in use on English Wikisource, it 'bounces' the main page header template on a page like this s:Broadcasting_Act_1981_(United_Kingdom)/Schedule9 to the end of the page. I can't obviously find an error in the markup from the relevant pages, so I'm open to suggestions as to where the parser/render engine is getting confused.

Perhaps you are able to provide a better explanation? as it's making the tool harder to work with on Wikisource. ShakespeareFan00 (Diskussion) 02:00, 11. Jun. 2018 (CEST)

English Wikisource is running gadgets to create a “dynamicLayout”.

• Something is going wrong, and something is obviously grasping one of the first elements on page content and “bouncing” this element to the end, probably footer section.
• The gadgets I flipped through looked correctly. They should put their hands on the element marked with id="headerContainer" etc., and if they do so they fetch the correct one and perform their job without influence.
• However, I could observe one case, obviously a en:race condition (“sometimes”), that behaved as you describe: The heading block in green was cut off at top and inserted as footer dynamically and in slow motion.
• I do suspect s:en:MediaWiki:PageNumbers.js or s:en:MediaWiki:Gadget-PageNumbers-core.js even when they access the headerContainer correctly, but they might fail on playing with page numbers.
• s:en:MediaWiki:DisplayFooter.js and s:en:MediaWiki:DisplayFooter2.js are inserting new elements as footer and innocent, since they don’t cut off elements from the head region.
• Anyway, some of your gadgets is counting elements from top, and since lintHint will insert two <div> these unexpected elements are disturbing when cutting off the third element and inserting as footer. They must not count the third from top but the second neighbour or child of the one identified as headerContainer.
• All scripts I have seen were rather old in DOM technology for core functionality; perhaps migration to modern jquery and considering more interaction nowadays might make that more robust.

Please discuss with your JavaScript maintainers.

You might turn off s:en:MediaWiki:Gadget-dynamicLayoutOverrides.js preference. No idea how that will influence.

Greetings --PerfektesChaos 17:27, 11. Jun. 2018 (CEST)

Unwanted td tag errors

(moved from en:User talk:PerfektesChaos/js/lintHint --PerfektesChaos 22:30, 12. Feb. 2019 (CET))

In the tool created by you named LintHint, an issue has been detected. Please check the pages:

• en:Template talk:Jctint/core#Newbie question about th tags in miles column
• en:Wikipedia talk:Linter#Unable to consistently reproduce stripped tag errors at Interstate 81 in New York

Adithyak1997 (de) (talk) 14:14, 26 November 2018 (UTC)

Change yellow background

(moved from en:User talk:PerfektesChaos/js/lintHint --PerfektesChaos 22:30, 12. Feb. 2019 (CET))

Hello PerfektesChaos, I've set mine up so that it runs automatically however I wanted to ask is there a way I change the yellow background?,
It's rather hard on the eye when I've just woken up so I wanted to hopefully replace it with either a lighter colour or just white,
Thanks, –Davey2010^Talk (de) 15:31, 6 February 2019 (UTC)

It is made to wake up people editing half asleep.

However, you can provide in any common.css snippets like

#lintHint, #lintHint-collapsed {
   background-color: orange;
}

The orange colour code my be chosen as you like.

Greetings --PerfektesChaos (de) (talk) 10:51, 7 February 2019 (UTC)

Brilliant thank you! :), –Davey2010^Talk (de) 16:31, 10 February 2019 (UTC)

Hi again, Unfortunately this hasn't worked, I've tried various things all of which haven't worked :(, Thanks, –Davey2010^Talk (de) 16:39, 10 February 2019 (UTC)

#lintHint, #lintHint-collapsed {
   background-color: #f9f9f9 !important;
}

You need the !important annotation. --Pipetricker (de) (talk) 17:05, 10 February 2019 (UTC)

You're a legend Pipetricker thanks so much!, Wierdly I had wondered if it was that but then thought it could be anything lol, Anyway many thanks! :), –Davey2010^Talk (de) 17:57, 10 February 2019 (UTC)

@Pipetricker: Eh, yes. Sorry. I forgot. Thx as well.

BTW, this thing is actually a redirect page. I am going to move the entire talk to the central German page since that one is watched continuously.

Best --PerfektesChaos (de) (talk) 19:06, 10 February 2019 (UTC)

You may have to place a notice on  this page  the English redirect page with more emphasis that it isn't intended as a talk page. --Pipetricker (de) (talk) 21:29, 10 February 2019 (UTC)

They simply started to run over the redirect mark. Every time I was waiting that an issue has been resolved and I could move somebody else appended a new section. Now made more clear. Regards --PerfektesChaos (de) (talk) 22:30, 12. Feb. 2019 (CET)

I noticed that with the above css, you lose the green indicating no errors when in edit mode. To get it back, remove the #lintHint-collapsed selector (which also brings back the yellow color of the lintHint button, which I don't mind):

#lintHint { background-color: #f9f9f9 !important }

--Pipetricker (diskussion) 19:16, 21. Feb. 2019 (CET)

Yes, thanks, this will only change the colour of the associated box with error table if any detected.

For changing the characteristic colour assigned to this tool it would be necessary to introduce a further customization issue, and I fail to see a global need for that.

BTW it should not have any influence which word is used for user namespace when attempting to mention.

Thanks for quick support desk --PerfektesChaos 20:46, 21. Feb. 2019 (CET)

Options conflict with Sonderzeichenauswahl (editMenus) gadget

Hi PerfektesChaos,

I installed lintHint in my common.js on de:Wp, but when I went to the options page, either directly to Spezial:Leerseite/preferencesGadgetOptions#lintHint or by clicking the cogwheels button at Spezial:Leerseite/lintHint, I got the wrong options: only options for editMenus, but no options for lintHint.

I fixed it by inactivating the gadget "Sonderzeichenauswahl usw. unter dem Quelltext-Bearbeitungsfeld" in the Preferences Gadgets section. The lintHint options appear for me only when that gadget is turned off. --Pipetricker (diskussion) 11:47, 13. Feb. 2019 (CET)

@Pipetricker: First, thank you for fixing the links after section migration.

Second, I cannot reproduce the situation, but I do believe in your report. Thx again for informing me.

• I checked whether there might be a C&P error anywhere; more than a dozen of gadgets are equipped with such customization support, and the wrong ID might have been left somewhere.
• I guess it is something like a race condition, or event communication.
• There are a lot of tricky things done, a waiting queue for requests before the HTML document (DOM) is available to be equipped, and identifying particular user options for the gadgets, also waiting for that.
• The window.location.hash is evaluated as well under some conditions; I should clear the hash now.
• I will track all events and possible leaks for undesired interaction, but that might need some days (or nights).

After the code has been updated I will inform you and kindly ask for testing, since it is all okay for me.

CU --PerfektesChaos 14:21, 13. Feb. 2019 (CET)

I'm happy to help with testing. And thanks for all your work. --Pipetricker (diskussion) 15:18, 13. Feb. 2019 (CET)

lintHint sees error outside but not inside editor

en:User:Anomalocaris/sandbox/Lint Test has 2 lint errors:

• 1 Misnested tag with different rendering in HTML5 and HTML4
• 1 Stripped tags

lintHint sees these errors when the article is viewed, but not when the article is edited. Why? --Anomalocaris (Diskussion) 16:33, 14. Aug. 2019 (CEST)

Thank you for informing me; I will analyse tonight. Greetings --PerfektesChaos 16:56, 14. Aug. 2019 (CEST)

More lint errors reported on article view but not in editor:

en:File:37th Hong Kong Film Awards.jpg: Stripped tags

All items at Lint errors: Stripped tags (Files)]: Stripped tags

en:Template:Volleyballbox: Table tag that should be deleted

en:File:Altreva Adaptive Modeler logo.png: Stripped tags: td

en:File:Flipper & Lopaka Title.jpg: Stripped tags: td

en:File:HKFAA BG1.jpg: Stripped tags: td

en:File:National Library IL.png: Stripped tags: td

en:Wikipedia:WikiProject Industrial design/Article alerts: Multiline table in list

en: Wikipedia:WikiProject Java/Article alerts: Multiline table in list

en: Wikipedia:WikiProject Robotics/Article alerts: Multiline table in list

en:Wikipedia:WikiProject Shimer College: Obsolete HTML: font (8), Stripped tags: div

en:Template:Abbr/testcases: Misnested tag with different rendering in HTML5 and HTML4: abbr; Stripped tags: abbr

en:Template:Vandalism information: Obsolete HTML tags: font (3)

--Anomalocaris (Diskussion) 20:16, 14. Aug. 2019 (CEST)

I guess server hiccups.

Currently there is a tremendous lag of database administration business, millions of page jobs in the queues. An exceptional situation, probably some problematic software behaviour anywhere.

A while ago the server might have noticed a lint problem, even false positive by different software problem. Or there might have been really a problem within en:Template:Non-free use rationale 2 or dependencies, which has been remedied.

The page has been added to LINT database.

When you ask on page view lintHint will just query the LINT database whether there is an entry. That is the one which will be reported on page view.

When you analyse in edit mode, the current source code will be analysed by parser and LINT just in time. If the problem has been solved, you will see the green light on source edit. However, the record in LINT database is still active.

I just sent some strong purge requests to the file pages. They bypassed the updating queue with millions of tasks ahead, and should be executed in advance. Usually this works within a few minutes, but is slow this time.

Just wait one week, and see.

Greetings --PerfektesChaos 15:57, 15. Aug. 2019 (CEST)

Check the page history of these articles. They all have an edit by me with edit summary "adjust white space to force recalculation of lint errors". Some of them I edited over two months ago. There's something more fundamental that just waiting. --Anomalocaris (Diskussion) 06:47, 16. Aug. 2019 (CEST)

Man kann die Fehler auch in der Seiteninformation sehen. [1] somit gibt es da wohl durchaus Fehler in der Benutzerseite, was mir auch nachvollziehbar erscheint zumindest in dem Fall, wo kursiv außerhalb der Vorlage steht. Ich könnte es mal testen, müsste dafür aber erst in en:wp eine common.js anlegen.

• @Anomalocaris for example: pageinfo = en:File:37th Hong Kong Film Awards.jpg I do think there it is something wrong in the en:template:Non-free use rationale 2 parameter Minimality there is an other template (“Information” which is tableformatted) in a tablecell. This might be a reason for an linterror. You can see that the table in the Summary (Minimal use) is defected. There you can read html-syntax summary="A standardized table providing complete information about the file, including description of what it shows and how it was made, copyright status and source." class="toccolours mbox-inside" style="width:100%;" cellpadding="2" in the parameter and one shifted parameter “Description” (which is a part of the included en:template:information), can’t you? There is a lot of visible syntax beneeth the box

|- !style="background: #ccf; text-align: right; padding-right: 0.4em; width: 15em"| Respect for
commercial opportunities (WP:NFCC#2) | n.a. |- !style="background: #ccf; text-align: right; padding-right: 0.4em; width: 15em"| Other information |This File Only Used in 37th Hong Kong Film Awards |- |-

| style="display: none;" colspan="2" | Fair useFair use of copyrighted material in the context of 37th Hong Kong Film Awards//en.wikipedia.org/wiki/File:37th_Hong_Kong_Film_Awards.jpg |}

This is, so I guess, not correkt. The parameter allows no tables in its body. Maybe someone has mixed these templates see the first version which even looks very unusual to me.

(oh ich hoffe das kann man verstehen) Englisch ist nicht so meins. --Liebe Grüße, Lómelinde Diskussion 08:31, 16. Aug. 2019 (CEST)

• en:Template:Volleyballbox hat auch eindeutig einen Linterfehler und zwar im Bereich bestscorer1 dort folgt auf ein |- direkt eine Tabelle daher auch table-tag to be deleted vermute ich mal

|- style="font-size:85%"
{{ #if: {{{bestscorer1|}}} | {{{!}} class="collapsible collapsed" style="width: 100%; background: {{{bg|#eeeeee}}};" cellspacing="0" |}}
{{!}}- style="font-size:85%"
{{!}}style="width:20%;vertical-align:top;text-align:right;"{{!}}{{ #if: {{{bestscorer1|}}} | '''{{{bestscorer1}}}''' | }}
{{!}}style="width:15%;vertical-align:top;text-align:center;"{{!}}{{{progression|}}}
{{!}}style="width:20%;vertical-align:top;text-align:left;"{{!}}{{{goals2|}}}
|} ← gehört zur äußeren Tabelle

Zugegebenermaßen wird tatsächlich der Fehler während der Bearbeitung (über Linthint, wenn ich den Quelltext hierher kopiere) nicht angezeigt, was aber daran liegen mag, dass {{{bestscorer1|}}} leer ist. Das über diesen Parameter includierte Tabellekopffragment ist zudem im Falle eines Wertes {{{bestscorer1|1}}} nicht geschlossen, ihr fehlt dann unten ein {{!}}} allerdings verstehe ich eh nicht was das ganze soll, da die Parameter {{{progression}}}, {{{goals2}}} und {{{bestscorer1}}} in der Dokumentation gar nicht vorkommen. Somit tut sich da auch nichts beim Klick auf show. Ask Ncboss →what he wanted to display with this syntax. --Liebe Grüße, Lómelinde Diskussion 09:45, 16. Aug. 2019 (CEST)

PerfektesChaos: We've heard from Lómelinde; what do you think? --Anomalocaris (Diskussion) 21:08, 21. Aug. 2019 (CEST)

I have told you everything already.

• The tool in question is reporting database entries in view mode.
• There is a known lag of updating database records. Therefore this tool is reporting false positves, but I cannot help that.
• In edit mode the current source code is transferred to server. The tool will report the answer. I cannot do anything else.
• This tool is not causing your problems.

Greetings --PerfektesChaos 22:58, 21. Aug. 2019 (CEST)

Greetings to you as well. I am skeptical of the theory that the problem is simply a lag of updating database records. Consider en:Help talk:Citation Style 1/Archive 2. The Information page reports:

Misnested tag with different rendering in HTML5 and HTML4: 1

Stripped tags: 1

The page history shows that I edited this page 23:48, 19 June 2018‎, and I remember that before I saved it, I got a "green light" from lintHint. But the errors remained on the information page, so I edited it again 9:30, 20 June 2018‎, and again before I saved it, I got a "green light" from lintHint. And 427 days later, it still has a "green light" when editing, and it still has errors on the information page. A delay of 427 days is not a "lag" — it is "never going to happen"! Similarly, some of the items listed above have persisted for more than 2 months with errors outside the editor that lintHint does not see. For example, I edited en:File:37th Hong Kong Film Awards.jpg 71 days ago. Do you really thing this is just a "known lag"? I agree with you that lintHint is doing what it's supposed to do, but something is not doing what it's supposed to do. --Anomalocaris (Diskussion) 08:37, 22. Aug. 2019 (CEST)

You are complaining at the wrong suggestion box.

• The page information view is telling that there is a record in the database and shows the details.
• lintHint is telling that there is a record in the database and shows the details.

Neither is responsible for the database record.

You need to complain at the database feeders and maintainers.

Perhaps it is necessary to clear the entire enWP database and rebuild again from scratch.

Useless to tell those who are building page information collection about false LINT errors.

Good luck --PerfektesChaos 12:36, 22. Aug. 2019 (CEST)

I tested the theory that the problem is a stuck database and did an experiment. I blanked en:File:National Library IL.png and the stripped tag went away; I undid my edit and the stripped tag came back. So the problem isn't a stuck database. So I used the advice from the "Can LintHint highlight inside of a block of templates?" section above where you said

• In this particular case I would open en:Special:ExpandTemplates and copy the code above into the input area. Then run!

With this tool, lintHint shows the stripped </td> tag! But lintHint doesn't find this tag without ExpandTemplates ... even though lintHint is supposed to expand templates internally, without displaying the expanded templates. Can you explain this behavior? --Anomalocaris (Diskussion) 16:47, 22. Aug. 2019 (CEST)

I did the same experiment with en:Template:Vandalism information, where Page Information reports "Obsolete HTML tags: 1". lintHint finds no lint errors here, but with ExpandTemplates, there are 3 visible <font> tags and lintHint finds them all. --Anomalocaris (Diskussion) 17:02, 22. Aug. 2019 (CEST)

You’ll find the errors in →here it’s a little bit tricky, but I do think lintHint works, because the linterror is just incluoded and not inside the templates page. Go first onto the dokumentation page of the template, there you’ll find highlighted an error, follow it through the path and you will end up on the userpage, which includes the obsolete font tags. --Liebe Grüße, Lómelinde Diskussion 18:33, 22. Aug. 2019 (CEST)

Error

In about a week or two the tool stopped working and is generating just the text "error". Here's an example: http://prntscr.com/qh7ez5 Is the tool still being supported? --StanProg (Diskussion) 19:04, 29. Dez. 2019 (CET)

Here's how it's setuped for me: [2]. --StanProg (Diskussion) 19:09, 29. Dez. 2019 (CET)

LintHint error in template

On this page...

en:Template:Blockquote paragraphs

...LintHint gives me this error...

 Missing end tag  blockquote
 Stripped tags    blockquote
 Missing end tag  blockquote
 Stripped tags    blockquote
 Missing end tag  blockquote
 Stripped tags    blockquote

...which is caused by this Wikimarkup...

Blockquote and templates that call it, and are indented with colon (:), bulleted with asterisk (*), or numbered with number (#), will generate errors and incorrectly display anything after a newline character.
<!--Please do not "fix" these deliberate errors. -->
 
{{markup</nowiki>
|<syntaxhighlight lang="html">
:<blockquote>Paragraph 1
Paragraph 2</blockquote>
</syntaxhighlight>
|
:<blockquote>Paragraph 1
Paragraph 2</blockquote>
}}
 
{{markup
|<syntaxhighlight lang="html">
*<blockquote>Paragraph 1
Paragraph 2</blockquote>
</syntaxhighlight>
|
*<blockquote>Paragraph 1
Paragraph 2</blockquote>
}}
 
{{markup
|<syntaxhighlight lang="html">
#<blockquote>Paragraph 1
Paragraph 2</blockquote>
</syntaxhighlight>
|
#<blockquote>Paragraph 1
Paragraph 2</blockquote>
}}

This LintHint error then shows up at en:Template:Quote.

Is there any way to keep the display of the deliberate error without it showing up in LintHint?

If I can't do that, is there a way to stop the error from showing up on other templates? I had to go through a long "Pages transcluded onto the current version of this page" list to find the actual error. --Guy Macon (talk) 15:11, 28. Jun. 2020 (CEST)

Callback function after table is displayed?

Hello. I have started using lintHint.js and I do not wish to see "Obselete HTML tags" warning. Can you please add an option to suppress that? Currently, I am using [...document.getElementsByTagName('td')].filter(el => el.innerText == "Obsolete HTML tags").forEach(el => el.parentElement.remove()).
Acagastya (Diskussion) 21:42, 9. Sep. 2020 (CEST)

This is the first request for such option after three years of lintHint.

I am happy that you found a solution to help yourself for now.

I will change the code and introduce a class derived from category ID for each table row. That would make it easier to suppress something via CSS rule.

Dissemination and testing might take longer ages. I am quite overburdened.

Basically the hints generated by lintHint are not made to be suppressed. And even obsolete tags or “minor priority” categories need to be eliminated in the long run. Only <tt> might become a MediaWiki tag like <pre> one day.

Introduction of a user option is out of scope.

Greetings --PerfektesChaos 15:31, 10. Sep. 2020 (CEST)

Can LintHint be activated automatically in Preview mode?

The setting to activate LintHint upon viewing a page is working well, but when I click Edit and Preview (in wikitext source mode), I have to click LintHint again. Is there a way to force LintHint to run upon page load even in Preview mode? This would save me a lot of time when I open many tabs in Edit mode. Thanks. Jonesey95 (Diskussion) 05:50, 5. Mär. 2021 (CET)

@Jonesey95: Sorry for late reply, but I needed a weekend to dig through my pile of frequently unanswered questions.

Well, intentionally there is no such automatism rather than launch described here.

I do hesitate a bit to make some interface in the way as you describe it, since it might cause server overload when requested after each modification of each page, in each preview and for each diff. The idea is to force the user demanding such analysis manually. Editing a page might occur in many steps, and not every step will need linter.

There is an automatic analysis offered by configuration, but only on page view.

Greetings --PerfektesChaos 16:39, 13. Mär. 2021 (CET)

OK, thank you for the answer. Jonesey95 (Diskussion) 16:51, 13. Mär. 2021 (CET)

Button in indicator bar?

Thanks for this script. Would it be possible to place the yellow button in the .mw-indicators area at the top right? Currently it pushes the whole page down just after page load, which makes it easy to miss a click.

I know it expands when clicked, so I don't mind if it gets moved to the current position once it is explicitly clicked. Inductiveload (Diskussion) 09:51, 25. Mai 2021 (CEST)

@Inductiveload: Funny idea. Actually, a great idea. Should have been mine. I do regret this.

Technically this is no big deal.

• Not all environments are providing an indicators region, at least not yet in mobile.
• However, I can check easily whether an indicators region is present and append lintHint there, otherwise keep contemporary behaviour.
• I have a huge pile of programming and dishes to do, but next time slot after we digested the recent skin changes and challenges lintHint handle will move as suggested.

Best regards --PerfektesChaos 17:37, 25. Mai 2021 (CEST)

Looks like this is now working: thank you very much, it feels much smoother on page load! FYI, I don't think float:right; is needed any more. Removing the float property will make the button line up with other indicators more consistently: phab:F34473283. Inductiveload (Diskussion) 14:36, 28. Mai 2021 (CEST)

Yep, float is a remainder of the previous arrangement, now fallback.

Apparently you are loading the d (debug) version, which is currently improved by 4.x steps.

Finally a stable release will get a 5 release as r.

Greetings --PerfektesChaos 17:21, 28. Mai 2021 (CEST)

ID of button broken

Hi! Tiny buglet (-4.5): the ID of the button is now undefined-collapsed (was lintHint-collapsed).

(BTW, the reason I noticed this is that I have some custom CSS):

#lintHint-collapsed,
#lintHint-null {
    border-radius: 3px !important;
    padding: 3px !important;
    line-height: 1.2 !important;
    font-size: inherit !important;
    float: none !important;
}

#lintHint-null {
    background-color: #90ff90 !important;
}

#lintHint-collapsed {
    background-color: #ffe867 !important;
}

#lintHint {
    background-color: #ffe867 !important;
    border-radius: 3px !important;
}

Kind regards, Inductiveload (Diskussion) 12:34, 3. Jun. 2021 (CEST)

Thank you for the hint wrt lintHint.

• Hopefully fixed now by -4.6.
• I am heading for a major release 5 as soon everybody is happy.

Please note that the selectors are spelled now linthint- rather than lintHint-.

• Also there are classes provided, which I do recommend to use for CSS decoration.
  • A headline might bear such keyword, e.g. in documentation or talk page, and would be decorated then.
  • A class= even with one member only will avoid ambiguity.
• No standard is explicitly declaring whether class= identifiers are case-sensitive or not.
  • Some browsers are treating class names case-insensitive.
  • Some browsers will make a difference and ignore if no exact match.
  • And some will treat camel casing lintHint- like lint-hint-.
• For this reason I am migrating all my codes towards downcased only identifiers.
  • Under certain circumstances this downcasing has been skipped and caused undefined-.

Greetings --PerfektesChaos 01:27, 4. Jun. 2021 (CEST)

Thanks for the reply. I still see undefined-collapsed for the button (both ID and class, with -4.6). linthint-null and the main error table container are OK.

I updated to use classes, which seems to work fine. Inductiveload (Diskussion) 14:33, 4. Jun. 2021 (CEST)

@Inductiveload: undefined should be defined now.

• You won a race condition, and I guess you have a config hook activated.

The entire GUI architecture has been rewritten now, enabling both small buttons for indicator and toolbox, as well as large ones where neither indicator nor toolbox are present, like mobile.

Forget about *-null selectors; this element has gone. It was the twin brother of the button if disabled, but all states are mixed now into the same element. It is no <button> any longer.

With release 5 a documentation of all CSS selectors will be added officially.

Best --PerfektesChaos 01:15, 13. Jun. 2021 (CEST)

Problem with very big tables

en:List of Warped Tour lineups by year has a fostered content lint error, according to both its "Page information" page and the Fostered content lint errors page. When I try to run lintHint on this article, every time I do, I get a red "error -- Error: Request Entity Too Large" error. If I break the very large table into two and test each half separately, lintHint doesn't find an error. Also, the linter page edit link highlights a section that starts 18 characters before the top of the table and ends 736 characters before the end of the table. The total size of the table is 150,290 bytes, a bit more than 2¹⁷ or 131,072. LintHint was able to get to "green" when the table was the first 119,292 bytes or the last 125,364 bytes of the original table, but it wouldn't get to green when the table size was 127,212 bytes. (It may be that the real problem is that my Internet connection is too slow and something times out.) I suspect that the linter has problems with very large tables, and when a table is too big, the linter gives up and somehow finds fostered content, even though it's not there. Please click the edit link, notice the misalignment of the highlighting, use lintHint, and tell me what you think. –Anomalocaris (Diskussion) 01:52, 12. Jun. 2021 (CEST)

Ich habe es mal hier in der Spielwiese versucht, gleiches Ergebnis „entity to large“ und das obwohl hier etliche Vorlagen nicht vorhanden, also weniger Inhalte umzusetzen würden.

There ist an other error in this table look at this edit added band to table. There is a missing of |- above the Bandname |Last Minet and other missing Pipes to complete the tablecells in this two rows. It is misplaced but not the linterror itself, as I think. I can not see any fostered content. But it may be this |- id="0.E2.80.939" 0.E2.80.939 I do think this means id="0–9" for the toc and for me it looks very strange. This anchor is out of funktion compare with any other anchor jump to E is ok. But however the massage “Error: Request Entity Too Large” will not vanish. --Liebe Grüße, Lómelinde Diskussion 07:33, 12. Jun. 2021 (CEST)

Lómelinde Danke schön for your assistance. I agree that the edit inserting Last Minet is messed up, and I agree it's not the cause of the Fostered content error. I reverted that edit and the page is still listed with 1 Fostered content error. –Anomalocaris (Diskussion) 06:09, 14. Jun. 2021 (CEST)

@Anomalocaris Have you also repalced the wrong id? --Liebe Grüße, Lómelinde Diskussion 06:13, 14. Jun. 2021 (CEST)

Lómelinde: erledigtErledigt Still fostered. –Anomalocaris (Diskussion) 09:06, 14. Jun. 2021 (CEST)

I try to find it. It might be something like |- content | or any incorrect closed template. It is not above D I’m still searching. --Liebe Grüße, Lómelinde Diskussion 09:18, 14. Jun. 2021 (CEST)

OK it might be really the number of table-rows that make an overflow. I have not found any fosterd content, but as long as the errormassage resumes (Entity Too Large) the linterrors will be shown on pageinformation and in linterrorlists. The same happenes when pagecontent is larger then 1 MB there might be errors in pages but no entry in linterlists and pageinfo if the pagesize was > 1MB before the start of linteranalysis in 2017 or they do not vanish when fixed. You can try to save one version of the table with half the content to bring the pageinfo to zero and reset to version with full table. It might help for this time, but not for new versions with new errors. I think the only way is to split the article in two or more parts and a maximum of 800 rows, not 1300 like now. Maybe there is a limt defined (1000 rows per page) like 1 MB for maximum artikelcontent. --Liebe Grüße, Lómelinde Diskussion 10:38, 14. Jun. 2021 (CEST)

Error in customization

Hello. When I try to customize LintHint to run in all namespaces by specifying the * value, it gives the following error message: <span>preferencesGadgetOptions<br />API error badvalue: Unrecognized value for parameter "action": tokens. * Login session might have been expired.</span>. I tried logging out and log back in but is still showing the error. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (Diskussion) 09:12, 8. Okt. 2021 (CEST)

Thank you for notification.

I will need this weekend for investigation.

The code which failed is of 2013, and there might have been a recent change at MediaWiki which I did not considered for updating.

Sorry for inconvnenience --PerfektesChaos 16:52, 8. Okt. 2021 (CEST)

Yeah, I missed mw:MediaWiki 1.37/Deprecation of legacy API token parameters.

Or, more precise: I caught the announcement but I was not aware that my code is affected.

I modified the code, but general test procedures will take some days until public release gets online.

Greetings --PerfektesChaos 17:17, 8. Okt. 2021 (CEST)

Thanks for your work! This happened in sqwiki, which I have since found has LintHint as a gadget selectable from preferences. Using it as a gadget enables it in all namespaces, so there is a workaround in that specific wiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (Diskussion) 19:05, 8. Okt. 2021 (CEST)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: After three years I put a major release online now.

• Please check whether it is working now again as described.
• The implementation has been made in 2013, but in 2014 it has been announced that a big simplification of user authentification is in progress.
  • Unfortunately I forgot that I used the older approach for user options.
  • My code became significantly better, faster, shorter with the update. The MediaWiki software can be simplified after completing the migration process, and will be more robust and easier to maintain and a bit faster.

Greetings --PerfektesChaos 13:29, 10. Okt. 2021 (CEST)

Yes, it is working now. Thank you. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (Diskussion) 13:35, 10. Okt. 2021 (CEST)

SqWiki

moved from user talk:PerfektesChaos

---

Hey there! :)

I'm a crat from SqWiki. Our community uses your tool as a gadget to fix our linter problems and we are very grateful for it. However lately I got told that apparently it doesn't work on mobile. I came at your EnWiki page to search for the code and do any needed updates, hoping that would fix the problem but I saw 2 pages in JS and now I'm confused. Maybe this is the reason it doesn't work on mobile?

Can you take a look at our gadget here and let me know if you can help? It is a copy-paste of this page. Should I also use this page somehow?

As a provided facility, this is our Gadget-definition page. --Klein Muçi (Diskussion) 01:07, 5. Nov. 2021 (CET)

@Klein Muçi:

• I will move this section to user talk:PerfektesChaos/js/lintHint as soon you have noticed.
  • I prefer to keep all issues about this tool together.
• “apparently it doesn't work on mobile”
  • Gadget-definition will need to specify:
    |targets=desktop,mobile
  • You may find that already for the last three entries at dark-mode etc.
  • By default the definition runs on desktop only.
• “2 pages in JS and now I'm confused”
  • Quite simple, it is the same thing, more or less.
  • r.js is a robust, stable, and compressed version (“release”).
  • d.js is human readable, and beta testing might be run there (“development” or “debug”). After it turns out that this works correctly a r.js will be made from that.
  • When a gadget is offered, r.js is recommended since that one is a bit faster.
• You should transclude the code at enWP as described in enWP via mw.loader.load() and execute always the most recent stable version.

Greetings --PerfektesChaos 08:15, 5. Nov. 2021 (CET)

Oh... So it is the same, I had only missed the targets at the definitions' page. Thank you for your concise answer! :) --Klein Muçi (Diskussion) 11:09, 5. Nov. 2021 (CET)

Context hint would help

Hi, and thanks for the script. Would it be possible to add a few words of context near the start tag of a missing end tag case, or other similar issue? For example, at en:Clerical celibacy, lintHint reports a missing i end tag; as there is no specific <i> tag present in the wikicode, I assume this is about mismatching wikimarkup for ''. Unfortunately, there are 139 occurrences of it, and after scrolling through the first couple dozen, I gave up (also, it's easy to miss a true positive when scanning that many). For example (fake example):

lint	+	context
Missing end tag	i	A ''locus classicus...

This would help narrow down the search for the offending markup. Would something like that be possible? As things stand now, there's a linter problem somewhere in en:Clerical celibacy, but I can't find it. Adding Benutzer:Jonesey95. Mfg (de/en), Mathglot (Diskussion) 22:56, 22. Dez. 2021 (CET)

P.S. It occurred to me your script is used for Wikipedias in various languages, and instead of having to translate 'context' (although it's recognizable by cognate in Romance/Germanic/Slavic languages) you could use something like { Lorem ipsum... } which I think would be recognizable everywhere. Mathglot (Diskussion) 23:02, 22. Dez. 2021 (CET)

@Mathglot:, do you see the little down-arrow next to the error? Clicking on that will jump you down to the site of the error. It's not always perfect, because sometimes LintHint can't look deep inside a template or table to find the specific location, but everything that is not highlighted is usually OK to ignore for that specific error. (Disclaimer: sometimes the actual error exists somewhere within the paragraph prior to the highlighted string.) Jonesey95 (Diskussion) 23:38, 22. Dez. 2021 (CET)

@Jonesey95:, No, I don't; the only down arrows I see, are part of the column-sort icon in the table header. Do you see one in the lintHint output at en:Clerical celibacy? If so, what OS/browser are you on?

P.S. didn't get your ping, because template {{U}} doesn't do anything in de-wiki. Here, you can use {{Ping}} or {{Reply}} (but not {{Re}}). Template {{User}} exists, but has tons of links; e.g. {{User|Mathglot}} = Mathglot (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren). Also, you can use [[User:Some userid]] because English namespace and special prefixes work on every language and Wikimedia project, so here at de-wiki, [[User:Jonesey95]] = [[Benutzer:Jonesey95]], [[User talk:Mathglot]] = [[Benutzer Diskussion:Mathglot]], [[Template:User]] = [[Vorlage:User]], and so on; ditto WP, Diff, Permalink, Special, and so on. If you occasionally visit other Wikipedias, this template might help.

Thanks, Mathglot (Diskussion) 02:07, 23. Dez. 2021 (CET)

Yes, I see the down arrow on that article, to the right of the "i" box in LintHint, but only in Edit mode. It jumps me down to "Aduersus Jovinianum I, 7. 26 (PL 23, 230C; 256C).", which has opening italics but no closing italics. Jonesey95 (Diskussion) 06:28, 23. Dez. 2021 (CET)

see en:User:PerfektesChaos/js/lintHint#Error table = “The ⇓ column appears only if there is any source text area in page. Each ↓ links to a selected region where this error occurred.”

The click on the downarrow ↓ links to some text in a ref-tag, where a cursive-tag '' is not closed. --Liebe Grüße, Lómelinde Diskussion 06:46, 23. Dez. 2021 (CET)

Thank you @Lómelinde:, and I do have the ⇓ character in the column header in the lintHint table in Edit preview mode, and I do have the down arrow ↓ in the cell. Both characters have a tooltip 'select problem in source text' but neither character is hyperlinked to anything and clicking them does nothing. Tested on Win10 with Vivaldi, Opera, Chrome, and Firefox, and all display the same behavior.

@Jonesey95:, thanks for pointing out the problem near Aduersus Jovinianum...; now that you've shown me where it is, I can see it; I'm going to leave it unfixed so I can use it as a test bed for trying to figure out why the arrow links for you, but not for me. Given that situation, maybe my original thought of extracting a few nearby words into the lintHint table as a context indicator would still be useful for users like me who get down arrows that are unlinked. Mathglot (Diskussion) 12:24, 23. Dez. 2021 (CET)

I have no idea why it might be not be linked for you, it works well for me on WIN10 and Firefox, jumps to a line about 98 + and highlights this text ''Aduersus Jovinianum I, 7. 26 ([[Patrologia Latina|PL]] 23, 230C; 256C). There you see the missing tag I think it should be fixed like this ''Aduersus Jovinianum'' I, 7. 26 (PL 23, 230C; 256C). which skin or editor do you use? I can not reproduce it on vector an normal wikitexteditor. Can you see a massage in the browserconsole. --Liebe Grüße, Lómelinde Diskussion 14:49, 23. Dez. 2021 (CET)

• Thanks, Jonesey95, for quick responding. Ló as well.
• @Mathglot:
  • lintHint won’t tell more than already listed in table. lintHint won’t read the page content or something somewhere in uncertainly rendered pages.
  • Regarding non-clickable arrow: Are you using some kind of wikisyntax highlighting? There are at least three methods, and some might hide the original plain text source text edit area and cover it by something where no details can be accessed. VisualEditor is tried to be detected, but has no source text edit area at all. I guess your arrows are internal links within the page, but they do not find a target.
• There is no Template:U here but I think Template:ping is rather global. U is not intuitive in most non-English languages and not self-explaining. Reply is specific and some non-English projects like us provide a redirect as courtesy for visitors. The word user is not indicating a conversation and might have many meanings in context of users. We create a kind of user profile.

Merry Xmas --PerfektesChaos 08:22, 24. Dez. 2021 (CET)

 Info: Da mir gerade der Firefox abgeschmiert ist und ich auf GoogleChrome umstellen musste ist mir folgendes aufgefallen:

Der lintHint-Pfeil, der den Sprung zum markierten Fehler machen soll, funktioniert tatsächlich nicht. Es ist so, dass der Fehler durchaus blau markiert wird, aber der Sprung innerhalb des Quelltextes erfolgt nicht. Man kann manuell durchschollen und findet den markierten Bereich. Eine wirkliche Fehlermeldung sehe ich allerdings nicht, aber mit der Chromekonsole bin ich auch nicht wirklich vertraut. Ich kann nur erkennen, das das Anklicken die jeweilige Markierung in Quelltext umschaltet. --Liebe Grüße, Lómelinde Diskussion 09:46, 13. Jan. 2022 (CET)

@ ALL: New release online since January 1st, HNY.

• Seems to be robust. All recent complaints fixed.
• Switching back to r.js might accelerate a bit, and runs a stable version.

@GoogleChrome: I try to focus on selection within the TEXTAREA. If that is not supported by current GoogleChrome I can’t help.

Greetings --PerfektesChaos 17:15, 13. Jan. 2022 (CET)

Bisher keine Veränderung. Im Chrome klappt der Sprung zu den Zielen noch immer nicht. Neu starten (was Crazy auf meiner Disk neulich erwähnte) ist kein Problem. --Liebe Grüße, Lómelinde Diskussion 09:27, 12. Feb. 2022 (CET)

Not working on ExpandTemplates

@PerfektesChaos: The recent update seems to have made the script not work on Special:ExpandTemplates at all. It adds lintHint, or

<div class="linthint-collapsed noprint linthint-fine" id="linthint-collapsed" role="button" style="padding: 1px; pointer-events: all; display: inline-block; line-height: 1.2em; margin-left: 3px; margin-right: 3px; color: rgb(160, 160, 160); cursor: default; background-color: rgb(173, 255, 47);" aria-disabled="true" title="+">lintHint</div>

next to the Help button but it does nothing when clicked (no event handlers are attached to the element), even if the output on the page contains lint errors. Can you please look into it? Thanks! Nardog (Diskussion) 07:59, 26. Dez. 2021 (CET)

I found this → see above Not working with ExpandTemplates it seems not to be a new Problem at all. I never use this, but can confirm there is only the green button. --Liebe Grüße, Lómelinde Diskussion 08:39, 26. Dez. 2021 (CET)

Sure, I will dig into that.

I forgot to investigate section „Not working with ExpandTemplates“ from June, and now the BETA version became productive.

Unfortunately I have no idea what is expected to happen on Special:ExpandTemplates. Many years ago I developed lintHint, and I forgot everything and I cannot remember what I did in spring. I never use it for Special:ExpandTemplates, so it is out of my experience and testing scope.

I guess a while ago the (new) Special:ExpandTemplates has been changed to use a OOUI widget rather than a HTML element, therefore this text input is not visible to current lintHint heuristics.

• If there is no reasonable task, lintHint will show the green field with version number only, but does not execute anything. Actually it should not be title="+" but revision ID.

--PerfektesChaos 09:43, 26. Dez. 2021 (CET)

A BETA test version has been uploaded. Hopefully this works now.

@Lómelinde: d-4.9 2021-12-27 ist dir gewidmet.

• Ein unter diesen Umständen etwas ungewöhnliches Ansinnen, aber wenn du es bitte bis 3Könige in allen möglichen Zusammenhängen, mobil, VE, Special:ExpandTemplates, Syntaxhighlight usw. testen würdest?

Bis 3Könige kommen, Syntaxhighlight meint CodeMirror (beißt sich mit meinem Schnark), mobil bin ich noch immer nicht, VE kann gehen, ExpandTemplates, da war mir so ganz dunkel, dass ich es vor Jahren mal ausprobiert hatte, erinnerte mich aber nicht mehr, genau was dort passierte. Bericht folgt. --Liebe Grüße, Lómelinde Diskussion 06:49, 27. Dez. 2021 (CET)

On Special:ExpandTemplates expanded output is analyzed rather than input source.

Greetings --PerfektesChaos 01:09, 27. Dez. 2021 (CET)

I switched to d.js and now it works properly in ExpandTemplates. Thanks! Anomalocaris (Diskussion) 03:01, 27. Dez. 2021 (CET)

• ExpandTemplates  Ok invaliden Text oder Vorlage {{}} in das Feld einfügen, einmal Expandieren, lintHint starten und im Ergebnisfeld werden die Fehler angesprungen.
• VE N ich habe keine Idee wie das gehen soll.
  • In der Leseansicht ist die gelbe Schaltfläche aktiv (man kann den Fehler analysieren lassen ehe man auf bearbeiten klickt).
  • Danach aber wird die eben geöffnete Fehlerbox mit Nebelbelag weiterhin angezeigt (ohne Pfeile natürlich) man könnte nun nur noch die Optionen (ich schreibe hier mal was da bei mir aktiv ist Namensraum-Nummern * und das Feld „Analysiere auch frühere Seitenversionen.“), die neu verlinkten Linterfehlerlisten oder den Schließer anklicken. Muss ich mal testen, was passiert, wenn ich auf automatische Analyse umschalte.
  • Test Automatikstart: Die Analyse startet zwar, aber sie analysiert es so, als wäre man in der Leseansicht = das Feld liegt jetzt zwar nicht mehr im Nebel aber die Spalte mit den Sprungmarken fehlt. Schließen der Box lässt die Schaltfläche verschwinden, Neuladen führt zum vorherigen Zustand. Das VE-Problem ist und bleibt ungelöst.
• VE + Wikitextmodus (2017 Wikitexteditor) N das vernebelt alles wieder
  • Automatischer Anlauf (Leseansicht)
  • Bearbeiten oder Quelltext bearbeiten (Box im Nebel) + Seite neu laden = Boxinhalt wie in der Leseansicht (ohne Nebel) = keine Pfeile
• Nur Wikitextmodus (2017 Wikitexteditor) N
  • Verhalten wie soeben beschrieben
• mobil N weiß ich auch nicht, hat nie wirklich funktioniert, meine ich.
  • Analyse läuft in der Leseansicht (Automatik oder Schaltfläche)
  • Bearbeiten: Button/Box verschwindet irgendwo hinter der Toolleiste (rutscht nach oben, wäre aber wohl auch mobilVE nur Leseansichtanalyse) ist futsch weg verschwunden unerreichbar

Aber wie gesagt, mobil bin ich nicht unterwegs. Dann mögen die Könige kommen. --Liebe Grüße, Lómelinde Diskussion 07:46, 27. Dez. 2021 (CET)

Tried en:User:PerfektesChaos/js/lintHint/d.js and it's working on ExpandTemplates like it used to, thanks! Nardog (Diskussion) 14:13, 27. Dez. 2021 (CET)

Possible bug (difference between rendered page and preview)

When I look at this page in rendered view (normal reading view), the yellow LintHint button stays yellow and shows:

• Misnested tag with different rendering in HTML5 and HTML4: span
• Stripped tags: span

When I look at the same revision in Preview mode and click the yellow LintHint button, the button turns green (indicating zero errors). The rendered view is correct and matches the Page information list of Linter errors. The Preview behavior of the LintHint button appears to be incorrect. Jonesey95 (Diskussion) 18:47, 13. Jul. 2022 (CEST)

This seems to be like it works with other includet errors. The problem is, that the span tags are not really in the source of your page. The code of the includes template shows:

<span class="example" style="font-family: Georgia, 'DejaVu Serif', serif; color: #006400;" {{#if:{{{title|}}}|title="{{{title}}}"}}>{{{1|Example text}}}</span>

span iy a tag for inline use not fpor textblocka, but you have put some lists (linebreaks) into the parameter 1 = example text, this does not work. Try the expanded text and you will see that there is an error inside, but not in the wikitext. LintHint can’t see the span tags at all. Expand the template:

<span class="example" style="font-family: Georgia, 'DejaVu Serif', serif; color: #006400;">Using the subject as a self-published source: Living persons may publish material about themselves, such as through press releases or personal websites. Such material may be used as a source only if:
:::*it is not unduly self-serving;
:::*it does not involve claims about third parties;
:::*it does not involve claims about events not directly related to the subject;
:::*there is no reasonable doubt as to its authenticity;
:::*the article is not based primarily on such sources.</span>

and the tool will find both the “misnested tag with different rendering in HTML5 and HTML4” span and the “stripped tags” span.

I do think, this is not an error in the tool, because it can not jump to any spantag, that is not in the source of a page.

I have many such (false)errors while editing a page, for example: when a project page uses a template like pagename/heder (or in this manner {{../Oben}} example: Spezial:Diff/224463480 but no footer. LintHint will now show “all ok” in reading view (and there is all correctly), but when you go to editview lintHint will say, stripped tags div because it only can find the closing div but not the opening one, which is included by the template {{../Oben}}. --Liebe Grüße, Lómelinde Diskussion 06:49, 14. Jul. 2022 (CEST)

lintHint is only forwarding warnings issued by MediaWiki software.

lintHint does not analyze anything and has no knowledge about content or syntax.

Things as described may occur, but responsibility is at MediaWiki. They have problems with template syntax since on programming they do not analyze branches, e.g. of {{#if: and take the source code as-is, therefore with duplicated branchses while only one comes into effect.

Thanks to Lómelinde for first response.

Greetings --PerfektesChaos 16:12, 15. Jul. 2022 (CEST)

Compatibility with Vector 2022 and future skin changes

The latest iteration of the Vector 2022 skin is not compatible with this script and I'd like to work out how we could restore it. The issue is the positioning of the #linthint-top element.

Could this script use mw.util.addSubtitle to add #linthint-top element or alternatively $('#linthint-top').prependTo('#vector-page-tools') ?

cc User:Jonesey95 who reported this issue. --Jdlrobson (Diskussion) 23:39, 23. Jan. 2023 (CET)

See the screen shot at https://phabricator.wikimedia.org/T327715. Jonesey95 (Diskussion) 23:47, 23. Jan. 2023 (CET)

I answered in the phab:T327715 task.

• Yes, of course, as soon the tower is telling me new coordinates and a new approach I will use that landing place immediately.

Greetings --PerfektesChaos 17:24, 24. Jan. 2023 (CET)

Incorrect "Big Tables that are hard to view on mobile" reports

LintHint is flagging various pages as having "Big Tables that are hard to view on mobile", but there are no large tables on the pages, just rather small infoboxes. Not sure what is causing this. Some examples are w:en:Edward Balliol and w:en:John Balliol. SMcCandlish (Diskussion) 22:36, 12. Mai 2023 (CEST)

@SMcCandlish see en:Wikipedia talk:Linter#New linter error: large-tables and mw:Help:Extension:Linter/large-tables the problem is that all tables with more than 5 columns where triggered. Not the maximum width of the table, but just the number of columns or if there are tables in tables. --Liebe Grüße, Lómelinde Diskussion 07:19, 13. Mai 2023 (CEST)

Yes, agreed, and this nonerror is starting to be rather annoying. Since these nonerrors are being marked with such overwhelming frequency, and have no issues in themselves for delinting editors to fix, I am wondering if this specific item could be ignored by LintHint? If not by default, by way of adding/changing the code on our common.js pages so we don't see it appear when editing with LintHint?
Another thing I'm wondering about is, when editing on a page, the LintHint checking banner states "Big Tables that are hard to view on mobile" on the editing page which is clearly stated, but on https://en.wikipedia.org/wiki/Special:BlankPage/lintHint it only states "Future problems detected." which is not very helpful. Wondered if that could be adjusted as well? Anyway, thank you for considering these requests, and thank you for this very helpful tool. Very pleased with it. Zinnober9 (Diskussion) 01:33, 14. Mai 2023 (CEST)

Some answers:

• lintHint is self-learning.
  • If unkown identifiers arrive suddenly (since I am not notified some weeks in advance) lintHint is displaying as “unknown future” when first encountered.
  • As an aftermath lintHint is querying the localized meaning, if retrievable.
  • Then lintHint is attempting to add this to the list of all localized descriptions in browser memory.
  • The first time lintHint is always labeling as “unknown”, but on second visit it might be known.
  • This mechanism is not in effect on special (blank) page generation.

I started to ponder on keywords for opt-in.

• I won’t implement this for one particular case right now, but scalable for an unlimited number of similar cases.
• I am entirely overburdened, and things where I need to use fresh brain and should not be erroneous have an input queue of several weeks or months.
• I cannot make any promise.

You will see what happened first.

• The experiment is discontinued, lessons learnt, statistics complete, no remedy, no syntax problem.
• lintHint will suppress undesired messages by default.

BTW the assumption of five columns is quite stupid, but no better means are available.

• There are old style “layout tables” with two columns and both are very wide, and which should be responsive elements. This is not trivial; in easy cases this is a common list which can make use of a standard solution. Otherwise it needs a lot of individual formatting, introduction of explaing headlines etc.
• There are tables with six year numbers and adjoined small numbers. They fit well, and look fine as landscape but ridiculous as portrait to satisfy an MW Linter rule.
• The minimum width of a table is not a fixed value, since the browser will try to stay within the current visible width and extend vertical space to reduce horizontal column width.
• Since minimum width of each column depends on user specific width of images etc. wrt font size it is impossible to derive column or table width from wikisyntax only. The goal is bad, the intention has been nice.

Thx @Ló for quick response.

Greetings --PerfektesChaos 09:30, 14. Mai 2023 (CEST)

Possible new bug information

Hi. I was recently doing my usual cleanup of links within links when I noticed there seems to be a major change in the media software that now seems to allow links within links to become visible, and usable, but linthint is still detecting them as lint errors. Actually, I don't think the problem is so much linthint as it is the media software itself since I was getting a list of lint errors from special pages, and it was telling me there were over 7,000 pages of links within links errors, but when I clicked on many of the pages, I found that the links were actually working. Likewise, linthint would highlight errors of links that were actually displaying as two different links even though the code showed them as being one link inside another. Maybe I should write a note about it a VP technical? --Huggums537 (Diskussion) 04:35, 11. Jun. 2023 (CEST)

• Some examples are:

https://en.wikipedia.org/w/index.php?title=L. Forbes Winslow&diff=prev&oldid=1159553284

https://en.wikipedia.org/w/index.php?title=Videos and audio recordings of Osama bin Laden&diff=prev&oldid=1159553152

https://en.wikipedia.org/w/index.php?title=Maurice Strong&diff=prev&oldid=1159552663

https://en.wikipedia.org/w/index.php?title=Sevier County, Utah&diff=prev&oldid=1159551969 Huggums537 (Diskussion) 04:40, 11. Jun. 2023 (CEST)

• I added a topic at: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problem_with_links_within_links_lint_errors Huggums537 (Diskussion) 05:17, 11. Jun. 2023 (CEST)

This is not a bug, example

*[http://www.henryirving.co.uk/correspondence.php?search=ewart Letter of Forbes Winslow to actor [[Henry Irving]] (1879)]

you can see the problem, when looking on the linktext. The wikilink is working, but the weblink is broken, that is what the lintercategory is triggering.

the linktext should look like this.

• Letter of Forbes Winslow to actor Henry Irving (1879)

it is expected that all text is linked, even the year at the end infront of the closing bracket ], but with a wikilink in the weblink it looks as following

• Letter of Forbes Winslow to actor Henry Irving (1879)

you see what pappened and it is an real linterror. You have to delink the actors name or change to

• Letter of Forbes Winslow to actor Henry Irving [1879] (henryirving.co.uk)

by the way, in german project we do not want any wikilink in the titles of books or wablinks. And all your examples shows the same, broken weblinks look links only all ist linked to the webside take a lokk on this page Hilfe:Wikisyntax/Validierung#Links in Links. The problem is not that the wikilink will not work, but that the weblinktext breaks in extremly examples there remains no text in a weblink. try this

* [http://www.henryirving.co.uk/correspondence.php?search=ewart [[Letter]] of Forbes Winslow to actor Henry Irving (1879)]

it would look like this

•  Letter of Forbes Winslow to actor Henry Irving (1879)

Please do not put any bracket, even not [] into an other link. --Liebe Grüße, Lómelinde Diskussion 07:49, 11. Jun. 2023 (CEST)

Got it. Thank you for your help. --Huggums537 (Diskussion) 01:18, 12. Jun. 2023 (CEST)

lintHint not always highlighting text correctly

Gemeldet in Phabricator
Task T365284

When the lintHint error table has two or more errors, clicking the 2nd or subsequent down arrows highlights text that is often far from where the lint error actually is. The 1st down arrow normally highlights the text in error correctly. This started happening on enwiki yesterday. I don't know if it is also happening on the other projects.

This is an example where this problem is occurring:

Open this version of this article. In edit mode, lintHint reports two Missing end tags. Clicking on the 2nd down arrow highlights this text:

led with [[ground meat]] and flavor.<ref>{{cite web|url=http://www.qur

which is four lines down from where the missing end tag actually is:

*'''[[School|School for Muslim girls]]. [[Zeynalabdin Taghiyev]] (1904)

--Bruce1ee (Diskussion) 16:53, 20. Okt. 2023 (CEST)

Yes I do think there is something wrong with the focussing.

Das ist mir seit vorgestern, oder so, auch aufgefallen. muss ich präzisieren. Beispiel:

Bei Benutzer:Drekamu/Grabhügel Thüringen gibt es einen Fehler wo ein Kursivtag fehlt. Springe ich die Seite direkt aus der Liste an, dann lande ich korrekt in der Zeile, in der das Tag fehlt ''Becks Grab, Berka (Werra)] lasse ich hingegen jetzt lintHint laufen und springe über den Pfeil zum Fehler, dann lande ich 5 Zeilen tiefer beim Text bei gel ''[[Hünengrab]]'' bei [.

In dem Beispiel von Bruce1ee sind aber zwei Fehler, merkwürdigerweise wird da tatsächlich der obere Fehler korrekt angesprungen, der zweite dann um vier Zeilen versetzt angezeigt.

Weiteres Beispiel: Vorlage:Tischtennis Nationale Rangliste zwei Fehler fett: Aus der Tabelle 1. Fehler markiert das öffnende fett, lintHint markiert drei Zeichen '''{{Tis, die weiter hinten stehen. Fehler 2 aus der Tabelle markiert alle Zeichen nach dem öffneden fett bis zur Zeile über dem noinclude, lintHint markiert hier mit Versatz ab '''{{Tischtennis … </noinclude>. Ok die Seite ist aber auch etwas kompliziert mit verschachtelten noincludes. --Liebe Grüße, Lómelinde Diskussion 07:20, 21. Okt. 2023 (CEST)

Thanks for the confirmation. --Bruce1ee (Diskussion) 08:36, 21. Okt. 2023 (CEST)

PerfektesChaos, I've created a minimal reproducible example in my sandbox, see en:Special:Permalink/1181833694. It seems to be caused by non-ascii characters. It looks like the edit link from Special:LintErrors does go to the correct place, so I guess this is an actual bug in LintHint? --Rchard2scout (Diskussion) 16:18, 25. Okt. 2023 (CEST)

This problem is still happening. If there is any way that we can help you fix the problem, please tell us. Thanks. Jonesey95 (Diskussion) 01:15, 2. Dez. 2023 (CET)

@PerfektesChaos I've managed to account for this problem using input_string.encode('utf-8')[start_offset:end_offset].decode('utf-8')
i.e. encoding into bytes, slicing the byte object at the offsets, and then decoding that back. You may wish to apply this to your script. Qwerfjkl (Diskussion) 17:06, 17. Mai 2024 (CEST)

@Qwerfjkl: Thank you. Pinging Jonesey95 – FYI. --Bruce1ee (Diskussion) 19:19, 17. Mai 2024 (CEST)

I filed this bug as T365284. Jonesey95 (Diskussion) 20:23, 17. Mai 2024 (CEST)

Thanks for flagging the regression. The issue should be resolved now. --ABreault (WMF) (Diskussion) 01:52, 14. Jun. 2024 (CEST)

@ABreault (WMF): Thank you. It appears to be working correctly again. --Bruce1ee (Diskussion) 02:59, 14. Jun. 2024 (CEST)

Wikipedia Mobile App: Image Recommendations and New Lint Error

Hello,

This is Amal Ramadan, the Sr. Community Relations Specialist supporting the Wikipedia mobile apps team.

Our Android team is working on Image Recommendations that will enhance accessibility and user engagement within the Wikimedia mobile apps; our engineers are adding a new lint error type, which is planned to match images without alt text and are expected to trigger on a large number of pages.

It is planned to use this lint category to feed both existing linter-based correction workflows and a "microtask" workflow in the Wikipedia mobile app, where small work tasks can be presented to users in a relevant context.

We want to make sure this won’t be disruptive to existing linter system users and that updates to support the new lint type can be coordinated.

Our current technical evaluation doesn't expect performance problems from this, but if it's overloading people's workflows, we want to be sure to accommodate those needs.

Thank you for your understanding and cooperation as we work towards enhancing the Wikipedia mobile app experience.

ARamadan-WMF (Diskussion) 09:14, 27. Feb. 2024 (CET)

See also phab T344378. Jonesey95 (Diskussion) 15:39, 7. Mär. 2024 (CET)

Hi everyone, sorry for the confusion. The project page for this effort is actually here. By the way my name is Jaz, I am the Lead Product Manager for the apps. If you're interested in discussing the project overall I've created this thread. Also, I want to clarify this isn't intended as a feature for new editors or the Growth experiments. --JTanner (WMF) (Diskussion) 02:19, 8. Mär. 2024 (CET)

Ungesichtete Seiten

Die Anzeige der Schaltfläche ist bei komplett ungesichteten Seiten nicht vorhanden. Bei Seiten mit ungesichteten Versionen ist sie hingegen sichtbar (direkt hinter dem indikator-review-status) Ich weiß jetzt nicht, wie das vor der letzten Änderung der Software war, weil ich zu selten ungesichtete Seiten bearbeite. Sollte die Schaltfläche da sein oder wird sie bewusst oder versehentlich nicht angezeigt? Ich kann sie jedenfalls auch im Inspektor nicht finden.

Spezial:Ungesichtete Seiten

<div class="mw-indicators">
	<div id="mw-indicator-indicator-fr-review-status" class="mw-indicator"><indicator name="fr-review-status" class="mw-fr-review-status-indicator" id="mw-fr-revision-toggle"><span class="cdx-fr-css-icon-review--status--unchecked"></span><b><a href="/wiki/Hilfe:Gesichtete_Versionen" title="Hilfe:Gesichtete Versionen">Nicht gesichtet</a></b></indicator></div>
	</div>

Spezial:Seiten mit ungesichteten Versionen

<div class="mw-indicators">
	<div id="mw-indicator-indicator-fr-review-status" class="mw-indicator"><indicator name="fr-review-status" class="mw-fr-review-status-indicator" id="mw-fr-revision-toggle"><span class="cdx-fr-css-icon-review--status--pending"></span><b>Ausstehend</b></indicator></div>
	<div class="linthint-collapsed noprint" id="linthint-collapsed" role="button" style="padding: 1px; pointer-events: all; display: inline-block; line-height: 1.2em; margin-left: 3px; margin-right: 3px; color: rgb(0, 0, 0); cursor: pointer; background-color: rgb(255, 255, 0);" aria-disabled="false" title="-5.8">lintHint</div></div>

Auch mehrmals neu laden hat nichts gebracht. --Liebe Grüße, Lómelinde Diskussion 10:13, 4. Sep. 2024 (CEST)

Das Kästchen zur Erstsichtung stand am Fuß jeder der betroffenen Seiten, damit die komplette Seite zuerst durchgescrollt werden musste.

Das ist dann offenbar seit letztem Donnerstag verschwunden. Allerhöchstwahrscheinlich irrtümlich durch einen Programmierfehler.

Wird dann wohl kommenden Donnerstag wieder auftauchen.

Für Nachforschungen ist es mir viel zu heiß; ich gehe auf dem Zahnfleisch und mache nur dringliche oder triviale Aktionen.

LG --PerfektesChaos 12:15, 4. Sep. 2024 (CEST)

Na ja nicht ganz, das hat mit dem Kästchen zur Sichtung nur indirekt zu tun. Vorher war da ja schon immer so ein zuletzt ovaler Kasten zum Ausklappen. Der Sichtungsbutton sollte sicherlich wieder unten stehen, es hat wenig Sinn den oben in einer Box zu verstecken. Wie gesagt ich weiß leider nicht, ob da jemals ein lintHint stand. Das sollte auch nur eine Info sein. Im Betawiki gibt es unten den Sichrungsbutton, aber auch dort kein lintHint. Es ist nicht so wesentlich, weil man sich ja über bearbeiten helfen kann. --Liebe Grüße, Lómelinde Diskussion 12:47, 4. Sep. 2024 (CEST)

Ah, bei lintHint bist du, ja, ist ja auch dessen Tool-Seite. Bei 30° schalte ich ab.

Das lintHint-Feld ist an die <indicator>-Technik gebunden.

• Über die werden Auszeichnungen und Klimbim angezeigt.
• lintHint fügt dem <div class="mw-indicators"> ein weiteres Element hinzu, oder stellt voran.
• Bei den noch nie gesichteten Artikeln ist das vorhanden, lintHint dürfte damit also kein Problem haben.
• Möglicherweise löscht da irgendwer irgendwas, weil keine Auszeichnungen erlaubt sein sollen, oder aber das <div class="mw-indicators"> ist zu Beginn nicht vorhanden.

Keine unmittelbare Ursache für mich erkennbar.

Kann dauern, bis ich das temperaturmäßig analysiert, geschweige denn behoben bekomme.

LG --PerfektesChaos 13:06, 4. Sep. 2024 (CEST)

Es ist nicht wichtig, es sollte nur eine Info sein. Falls man aus der Fehlertabelle dorthin käme, würde man das ja gar nicht bemerken, weil man direkt in der Bearbeitung landet, vermutlich ist es mir deshalb auch noch nie aufgefallen. --Liebe Grüße, Lómelinde Diskussion 13:17, 4. Sep. 2024 (CEST)

LintHint script error

Hi PerfektesChaos, I hope you're well, So for the past week or so I've had this error box show and I'm unable to use LintHint, I updated/removed various stuff on my common.js page (here) but that didn't do anything, I didn't know if there was something wrong your end or my end?,

Also the yellow background is my formatting and has nothing to do with the error, Many thanks, Warm Regards, --Davey2010 (Diskussion) 23:00, 10. Sep. 2024 (CEST)

@Davey2010 see #Merkwürdige Fehlermeldung it has come with the last softwareupdate on 5. september. But there should not be errormessages in all pages. I analysed, that the {{DEFAULTSORT:}} is one case. Pages without sorting should work well. I have also testet the tool on en:wp there is a template {{short description|Building comprising a single dwelling}} that makes this error. For some help, edit the pagees just header by header and it works, if there ist no {{DEFAULTSORT:}} or this kind of template. en:Template:Short description shows the same error. See for example en:User talk:Prioryman/Archive 2 there the tool is working (for me) and shows 8 errors. --Liebe Grüße, Lómelinde Diskussion 06:27, 11. Sep. 2024 (CEST)

“I hope you're well”

• This week I might start to recover from an overheated summer. I am boiled. No brain cells left.

The issue you are reporting is caused by WMF.

• The lintHint tool is entirely unchanged for many, many months.

Greetings --PerfektesChaos 08:15, 11. Sep. 2024 (CEST)

Hi @Lómelinde, Oh, of course it had to be WMF related, wouldn't be a normal day if it wasn't :P, Many thanks for your helpful message I'll try to remember that going forward, Thanks, Warm Regards,

Hi @PerfektesChaos, Haha heatwaves/overheated summers aren't fun I know that feeling, Hope you cool down soon :D, I see, that's a shame - hoping WMF fix whatever they've messed up pronto, Anyway have a great day, Take care, Many thanks, Warm Regards, --Davey2010 (Diskussion) 16:18, 11. Sep. 2024 (CEST)

"Duplicate ID" error shows in Edit mode, but not on saved page

See this version of my sandbox page. It has no Linter errors listed on "Page information", and LintHint shows a green color (no errors). When you click Edit (source edit mode in Vector 2022), the LintHint script shows a "Duplicate ID" error.

Expanding the code, {{tq|A}} Foo {{tq|B}}, in Special:ExpandTemplates shows no id= present in the expanded wikitext. --Jonesey95 (Diskussion) 17:00, 30. Sep. 2024 (CEST)

@Jonesey95: It is not only in vector 2022, subst shows that lintHint marks two of these templates

{{FormattingError|Template:Tq is only for quoting in talk and project pages. Do not use it in actual articles.}}
{{FormattingError|Template:Tq is only for quoting in talk and project pages. Do not use it in actual articles.}}

and in there is a code <span id="FormattingError" ></span> which is doubled. --Liebe Grüße, Lómelinde Diskussion 17:40, 30. Sep. 2024 (CEST)

Thank you. Those templates are not used outside of article namespace (NS=0), so LintHint should not detect them when it is analyzing a page in Talk/Diskussion space. Jonesey95 (Diskussion) 20:19, 30. Sep. 2024 (CEST)

Thanks to Lómelinde for first responding.

lintHint is just reporting what the Wiki server tells about a page – lintHint does not analyze or detect anything, nor does it invent any message.

Obviously, en:Template:tq is implemented in a way that the error messages found by Lómelinde are produced, at least in edit mode. Apparently in edit mode only, which can be detected. Both error messages do contain the identical id="FormattingError" which is not permitted within one page. The implementation of this template (and probably many other) using an id= needs to be changed. id= must not be used to identify elements if not used to jump to this point. Use class= for CSS decoration or element identification by gadgets.

Greetings --PerfektesChaos 21:42, 30. Sep. 2024 (CEST)