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)

Mobil?

Müsste meine Schaltfläche nicht auch in der mobilen Ansicht funktionieren?

• Ich kann sie zwar anklicken und sie wird auch grau aber mehr passiert nicht. (Gemeint ich hier nur in der Seitenansicht, die Konsole schweigt dazu)
• Beim klicken auf einen dieser Bearbeitungsstifte erscheint die Schaltfläche gar nicht erst.

Ich wollte eigentlich nur mal H:ZQ aktualisieren, daher habbich mobile Ansicht aufgerufen. --Liebe Grüße, Lómelinde Diskussion 10:59, 18. Mai 2018 (CEST)

Du meinst den gelben kleinen Button auf Seitenvorschau etc.?

Schaue ich mir an, eher nach Pfingsten. Keine Ahnung was klemmen könnte. Gibt kaum eine Besonderheit für mobil oder Projekt oder was auch immer; allerdings kann mobil zurzeit keine Tabellensortierung und vielleicht blockiert die dafür eingebaute Ausnahmebehandlung irgendwie.

Danke für den Hinweis --PerfektesChaos 11:14, 18. Mai 2018 (CEST)

Das eilt für mich so gar nicht, ich habe doch gar keinen (eigenen) mobilen Zugang. Ich teste es aber gern, wenn du möchtest. Ich habe neulich, also am letzten Wochenende versucht von einem Tablet aus mich anzumelden, schrunz hoch drei, ich habe dieses Zeichen über dem ó nicht gefunden musste es kopieren, es war sehr umständlich. --Liebe Grüße, Lómelinde Diskussion 11:18, 18. Mai 2018 (CEST)

Ich kann es nicht reproduzieren.

1. Konkrete URL?
2. Wäre ein Fehler zu erwarten gewesen?
3. Echtes Mobilgerät oder Simulation auf PC?

LG --PerfektesChaos 13:21, 18. Mai 2018 (CEST)

Es war vorhin sowohl bei der Spielwiese (diese Version, allerdings geht es dort jetzt) als auch beim Modehaus M. Baltz da streikt es noch ebenso bei Rechtsform vermutlich ANR WP.Fragen zur Wikipedia geht nämlich

Ne, nur die PC-mobile Ansichtsimmulation. Und beim Bearbeiten, kommt wie geschrieben keine Schaltfläche. --Liebe Grüße, Lómelinde Diskussion 13:43, 18. Mai 2018 (CEST)

Ach so, nein die Seite weist keinen LintError auf es war die nächstbeste in meinen Beiträgen, die ich testweise geöffnet hatte. Ich teste mal eine Fehlerversion. Da Politisierungsdilemma ist es genauso, es sollte 2 × Fehlendes End-Tag i in der Tabelle stehen. Bei anderen Namensräumen mit Fehlermeldung bekomme ich eine Tabelle. --Liebe Grüße, Lómelinde Diskussion 13:57, 18. Mai 2018 (CEST)

Ich kann es nicht reproduzieren.

Bei mir unter den angegebenen URL alles erwartungsgemäß, sowohl bei manueller Auslösung wie auch beim automatischen Start.

LG --PerfektesChaos 15:40, 18. Mai 2018 (CEST)

Ooo Kay, ich könnte noch dazuschreiben, dass ich vermute, dass es irgendwie damit zusammenhängt

makeButton@https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/personendaten.js&action=raw&ctype=text/javascript:2211:15
fire@https://de.m.wikipedia.org/w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=12ab2sa:46:599
add@https://de.m.wikipedia.org/w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=12ab2sa:47:143
register@https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/personendaten.js&action=raw&ctype=text/javascript:2132:4
f2@https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/personendaten.js&action=raw&ctype=text/javascript:2110:3
fire@https://de.m.wikipedia.org/w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=12ab2sa:46:599
add@https://de.m.wikipedia.org/w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=12ab2sa:47:143
waitForTE@https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/personendaten.js&action=raw&ctype=text/javascript:2112:2
init/<@https://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/personendaten.js&action=raw&ctype=text/javascript:2265:4
mightThrow@https://de.m.wikipedia.org/w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=12ab2sa:49:590
resolve/</process<@https://de.m.wikipedia.org/w/load.php?debug=false&lang=de&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=12ab2sa:50:269

Es wundert mich nämlich weshalb in einem Nichtpersonenartikel eine personendaten.js erwartet wird. Zudem habe ich eben mal einen Personenartikel getestet und siehe da dort scheint es zu funktionieren. Heute nicht mehr. Ich frage ihn mal nächste Woche, was diese Warnmeldung bedeutet. Ich habe es eben mal ausgestellt und dann funktioniert meine Schaltfläche auch. Sorry wegen der Störung. --Liebe Grüße, Lómelinde Diskussion 16:03, 18. Mai 2018 (CEST)

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)

Option "Analyze previous revisions, too" not working

The option works neither when configured interactively nor by Javascript; the latest revision is always analyzed (except when in edit mode).

It isn't a big problem (for me) though, since an easy workaround is to open the old revision in edit mode (and the alternative of inputting an oldid on Special:BlankPage/lintHint also works fine). --Pipetricker (diskussion) 15:58, 27. Feb. 2019 (CET)

@Pipetricker:

Thank you. Yes, by migration to improved REST API this ID was not communicated any more.

Fix is (by debug version d) online now.

Best --PerfektesChaos 22:07, 3. Mär. 2019 (CET)

Tried it (d.js), works fine; thank you. --Pipetricker (diskussion) 10:12, 4. Mär. 2019 (CET)

Alles im grünen Bereich?

Hast du etwas verändert? Ich wundere mich weshalb mir einerseits die Liste sagt[e], dass dieser Link Enrique Angelelli

{{Webarchiv|url=http://usf.usfca.edu/fac_staff/webberm/plaza.htm|wayback=20120205|text=Searching for Life: The Grandmothers of the Plaza de Mayo and the Disappeared Children of Argentina. Website der [[University of San Francisco]]}}

nicht koscha sei, wenn ich aber nun LintHint frage, sagt es plötzlich: ‚nönö ist alles im grünen Bereich‘. Dabei sehe ich es auch ohne die neue Fehlermeldung deutlich, dass da so ein sichtbarer [[University of San Francisco]] Klammermurks steht. Ich kann zwar jetzt netterweise über die fette Meldung zu der Stelle im Seitentext springen = EN10, aber nun nicht mehr über LintHint zu dem Ort im Quelltext kommen, denn wo grünes Licht ist, muss man nicht stehenbleiben. Das verwirrt mich jetzt doch ein wenig. Absicht? Ich habe den Verdacht du hast das „umgelagert“, damit ich es nicht mehr hier sehen soll. Das heißt, sie lösen sich dort auf, aber die Fehler sind eigentlich noch da, nur werden sie jetzt halt an einem anderen Ort gelistet. --Liebe Grüße, Lómelinde Diskussion 16:29, 18. Mär. 2019 (CET)

Ja, und sie produzieren auch einen sichtbaren roten error an der fraglichen Stelle für das Wartungspersonal, und der Klammermurks wird nunmehr für alle Leser dezent aber explizit sichtbar, während das ja früher automatisch durch die Blauverlinkung bis vor das Wikilink eingeebnet wurde und kaum zu erkennen war.

Die 300 aus der Kat werden durch Bereinigung oder durch Vergessen allmählich von Spezial:LintErrors verschwinden.

Aber keine Sorge, mittelfristig werden uns allen die einfach geklammerten Weblinks in den LintErrors erhalten bleiben; die Webarchiv-Parameter sind ja nur dadurch entstanden, dass der IABot den Linktext in den Parameter verschoben hatte.

Jetzt erstmal besser entlang der neuen Wartungskat arbeiten, oder was ganz anderes machen.

Vorlage:Internetquelle macht dieses Darstellung übrigens schon seit einigen Jahren oder so, jedoch bislang ohne Wartungskat.

LG --PerfektesChaos 16:41, 18. Mär. 2019 (CET)

O.k. ich finde es ja auch so. --Liebe Grüße, Lómelinde Diskussion 16:53, 18. Mär. 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)

Unspported Media Type error..

https://en.wikisource.org/wiki/Main_Page

When I have the script running on a normal page - I see this in red in the output generated from the script.

"error -- Error: Unsupported Media Type"

The script continues to work correctly when in Edit mode. ShakespeareFan00 (Diskussion) 10:55, 30. Nov. 2019 (CET)

Thank you for informing me.

I can reproduce that, and it is the answer the script is receiving from the server now.

Perhaps a temporary problem at server side, perhaps a change in server API programming which was not communicated to me.

I will need a couple of days to get some free hours for investigation. Perhaps during next week.

Please note that there are two different modes: Regarding the request on an entire page, as described by you, only a tiny page identification is sent to server. In case of source page editing the entire current wikitext is sent to server and evaluated.

Greetings --PerfektesChaos 16:19, 30. Nov. 2019 (CET)

It is HTTP status code 415 – Unsupported Media Type.

I did not change anything for half a year, ímplementation of LINT processing itself has not been changed.

Apparently a server problem, a server network connection configuration whatever thing.

For me, it is working now in page name mode for both German Wikipedia and English Wikisource. Probably a temporary issue.

If occurring again, wait a week and see whether problem is solving magically.

Greetings --PerfektesChaos 14:14, 2. Dez. 2019 (CET)

@ShakespeareFan00, Lómelinde: I just found phab:T240057.

• In a nutshell it says that due to server overload LINT has been disabled for queries based upon page name or revision.
• For submitting entire wikitext as issued when editing current modification it is still accepted.
• No precise end of temporary disconnection can be predicted.
• Database entries still remain, but won’t be updated and after recovering a certain gap is to be expected.
• Lómelinde, please drop this into Google Translator.

Greetings --PerfektesChaos 16:36, 10. Dez. 2019 (CET)

??? ich versteh nur Bahnhof. Worum geht es denn genau? Im Augenblick scheint es eh eine Störung zu geben, behobene Fehler verschwinden nicht mehr man muss die Seiten aktiv purgen (oder nach der Bearbeitung explizit noch mal mit dem Tool durchlaufen lassen, was wohl einen ähnlichen Effekt hat) damit sie aus der Liste kommen, ich hatte etliche, die Andim längst behoben hatte, die aber trotzdem in der Liste standen, daher mach ich derzeit auch weniger Literfehleredits (fireflytools scheint auch zu hängen, die Zahlen dort scheinen eingefroren, die Zeitangabe geht aber). Ich hatte diese Meldung nicht. Daher hier auch nur gelesen, aber nicht verstanden was genau los sein soll. Betrifft mich das irgendwie, irgendwo? Und was soll mir ein Phab sagen? Sorry, aber wenn du möchtest, dass ich etwas testen soll, dann musst du mir das genauer mitteilen. Ich hatte keinerlei Probleme, außer, dass alles manchmal recht lange dauert. --Liebe Grüße, Lómelinde Diskussion 16:55, 10. Dez. 2019 (CET)

Also nochmal die Zusammenfassung:

• Vor drei Tagen wurde der Server-Dienst, der jede Bearbeitung beim Speichern auf LINT prüft, wegen allgemeiner Projekt-Überlastung bis auf Weiteres abgeschaltet.
• Die Abfrage während einer Live-Bearbeitung ist einstweilen nicht betroffen.
• Die Datenbank-Einträge bleiben erhalten, ändern sich jedoch nicht mehr.
• Nach Reaktivierung wird mit einer Lücke in der Datenbank-Geschichte zu rechnen sein.
• Ein Zeitpunkt für die Wiederaufnahme ist nicht absehbar.
• Gezielte Linter-Abarbeitung wäre zurzeit nicht sinnvoll.

LG --PerfektesChaos 17:12, 10. Dez. 2019 (CET)

Also ganz lassen, nicht nur einschränken. Dann habe ich es ja quasi instinktiv richtig gemacht. O.k. alles klar. --Liebe Grüße, Lómelinde Diskussion 17:24, 10. Dez. 2019 (CET)

Es scheint wieder zu laufen, oder? --Liebe Grüße, Lómelinde Diskussion 07:28, 13. Dez. 2019 (CET)

Könnte gelöst worden sein; gemächlich Ende nächster Woche ausprobieren.

• Langsam angehen.
• Es gibt den Plan, wegen der entstandenen einwöchigen Lücke in der Datenbank die Datenbanken aller Wikis einmal komplett zu leeren und danach für jede Seite wieder neu zu analysieren und die Datenbank neu aufzubauen.
• Das würde einige nicht verschwindende Karteileichen zu nicht mehr existierenden Konstellationen endlich tilgen.
• Optimisten meinen, sowas würde eine Woche dauern.
• Ich würde dieses Jahr keine systematischen Linter-Analysen des Altbestands mehr einplanen.

@ShakespeareFan00: Might have been solved for now.

• Not very robust yet.
• Do not make big schedules this year.
• It is considered to empty the database and get rid of orphan entries soon. Might take a while to fill again by reparsing all pages on all wikis.
• There would be a gap of one week otherwise in database.

Greetings --PerfektesChaos 13:43, 16. Dez. 2019 (CET)

Letzte Meldung: Bis Jaunar 2020 abwarten, erst dann Datenbank einmal leeren und neu aufbauen, weil jetzt alle Leute in die Weihnachtsferien gehn und wenn dann was schiefgeht ist keiner mehr da und kann reparieren. LG --PerfektesChaos 13:43, 16. Dez. 2019 (CET)

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)

Pointers are pointing to the wrong place

For several weeks now, lintHint pointers have often been off. For example, editing en:Wikipedia:Biographies of living persons/Noticeboard/Archive109, lintHint detects 47 errors.

• The first error is an obsolete <font> tag, and clicking on the down-arrow highlights text 10 characters after the actual <font> tag.
• The last error is an obsolete <font> tag, and clicking on the down-arrow highlights text about 152 characters after the actual <font> tag.

What is going on? –Anomalocaris (Diskussion) 12:37, 3. Jan. 2020 (CET)

HNY.

Thanks – yes, it has been noticed already that the numbers are not precise any longer.

With beginning of December 2019 the executing parser system has been shifted from Parsoid/JS to Parsoid/PHP.

I guess this is the reason.

Currently the API answers are temporarily or for some wikis completely discarded due to server overload – see section above.

It is hoped that within January 2020 there will be a robust solution regarding servers.

For now partially Parsoid/JS and partially Parsoid/PHP are both producing answers and pointers.

Before the Parsoid migration has not been successfully completed and server load is stable I cannot start investigation, but I will do under stable conditions. LintHint does tell you just the answer received from server.

Greetings --PerfektesChaos 12:53, 3. Jan. 2020 (CET)

This is a Parsoid/PHP bug. We'll investigate this and fix it. SSastry (WMF) (Diskussion) 05:57, 4. Jan. 2020 (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)

lintHint does not appear on the 2017 editor

I wanted to ask if that is a limitation of lintHint or the editor and whether they will work together in the future. --Nickps (Diskussion) 18:28, 17. Sep. 2020 (CEST)

Eh, it is not intended, at least.

There might be some conflict about inserting into document, but lintHint is attempting to appear on top of whatever. Should work. And “2017” does not block the source content elements. Never heard about that.

@Lómelinde: Would you mind to investigate and report, please?

Greetings --PerfektesChaos 18:44, 17. Sep. 2020 (CEST)

Maybe tomorrow. I’m tired today. --Liebe Grüße, Lómelinde Diskussion 18:56, 17. Sep. 2020 (CEST)

I don't know if this is helpful but when I hide the editor with inspect element I can see the lintHint button behind it as you can see here. It still works, but can't be accessed without this "hack". Thank you both for checking this out. --Nickps (Diskussion) 01:13, 18. Sep. 2020 (CEST)

Analyse: Mit der Einstellung „Neuer Wikitext-Modus“ passiert folgendes

• In der Leseansicht steht der Button, wie gewohnt in einem Absatz unter dem Seitentitel
• Wenn man nun auf Bearbeiten (edit) klickt, dann stellt sich die Ansicht in zwei Schritten um
  • der Ladebalken für das Werkzeug erscheint kurz und Linthint ist noch schemenhaft sichtbar
  • die Werkzeugleiste legt sich über die Zeile, in der vorher der Seitentitel stand (id="firstHeading")
  • (firstHeading) steht jetzt ungefähr dort wo zuvor Linthint zu finden war (das Ankertool funktioniert dann auch nicht)
  • id="mw-content-text" ist komplett auf display:none also alles was in diesem div steht:

    <div id="mw-content-text" dir="ltr" class="mw-content-ltr ve-init-mw-desktopArticleTarget-editableContent" lang="de">…</div>
    

  • Da ist dann auch lintHint verborgen und fragmentAnchors wohl auch
  • selbst wenn man eine kleine Änderung machen würde und auf Änderungen veröffentlichen und dann Vorschau klickt, ist die Schaltfläche verborgen, obwohl dann ja eine Leseansicht in der Vorschau angezeigt wird und nicht Quelltext.
  • In der normalen Leseansicht steht lintHhint in diesem div

    <div id="mw-content-text" class="mw-content-ltr" dir="ltr" lang="de">…</div>
    

    und ist sichtbar. Daran schließt sich dann mw-parser-output an. Vermutlich müsstest du den Abschnitt für den Button wohl zwischen id="firstHeading" class="firstHeading .ve-activated .ve-init-mw-desktopArticleTarget-uneditableContent" lang="de" und id="bodyContent" class="mw-body-content" setzen und. Ich habe echt Probleme diesen Inspektor zu interpretieren. --Liebe Grüße, Lómelinde Diskussion 07:27, 18. Sep. 2020 (CEST)

• Thanks, Lómelinde.
• Well, it is not a polite behaviour of “2017” to hide the entire area, including lintHint.
• Unfortunately, mw-content-text is crucial since it is the only one that works in mobile as well as desktop and in every skin.
  • I do need this key element.
  • I might change strategy now. Rather than inserting as first element into mw-content-text I could insert the lintHint business immediately before that one.
• I will think about, change implementation if I find some clear hours, ask for testing and an update will be distributed without further notice somewhen.

Greetings --PerfektesChaos 15:41, 18. Sep. 2020 (CEST)

Version -4.2

Jetzt ist die Schaltfläsche zwar sichtbar, aber sie ist inaktiv, wenn ich es richtig herauslese gibt es da eine Funktion, die sich pointer-events: nennt diese steht auf pointer-events: none schalte ich das Kästchen aus, dann kann ich die Schaltfläche anklicken. Ich muss das mal auf einer Seite mit Fehler testen, ohne wird es jedenfalls grün. Hmm es passiert dann folgendes (wenn ich das aktiviert habe)

LintHint arbeitet als würde es sich in der Leseansicht befinden, es wird eine Tabelle mit den Fehlern ausgegeben, aber es werden keine Sprungziele generiert

Die Schaltfläche für die Optionen ist klickbar das rote X ebenfalls.

Was mich aber echt nervt ist die schlechtere Sichtbarkeit so als wäre da ein opacity über die komplette Seite gelegt und das steht auf 0.5 ich habe nicht mehr so gute Augen dass ich bei 50 % alles gut lesen könnte das meinte ich übrigens oben mit „Linthint ist noch schemenhaft sichtbar“

.ve-loading #content > :not(.ve-init-mw-desktopArticleTarget-loading-overlay), .ve-activated .ve-init-mw-desktopArticleTarget-uneditableContent {
    pointer-events: none;
    -webkit-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    user-select: none;
    opacity: 0.5;
}

Selbst wenn ich nun im Quelltext die Fehler über Suchen anspringe und behebe bemerkt LintHint dies nicht, da es ja meint es wäre in der Leseansicht, und da kann sich ja nichts ändern. --Liebe Grüße, Lómelinde Diskussion 13:24, 20. Sep. 2020 (CEST)

Uih, gut aufgepasst, und so schnell.

Ich hatte noch nie auf dem Schirm, dass lintHint zusammen mit VE benutzt werden könnte.

• Dass der alles deaktiviert und runterdimmt, was außerhalb seiner Spielwiese mw-content-text liegen würde, war mir nicht bewusst.
• Ich kann aber in mittlerer Zukunft für den Button und die Resultate-Box pointer-events sowie opacity explizit setzen; das müsste es hinreichend unwirksam machen.
• Beobachte, und schau was sich -4.3 täte.
• An den aktuellen Quelltext-Inhalt beim VE kommt aber niemand heran, und es existiert während der VE-Bearbeitung auch überhaupt keiner. Der steht als Nicht-Quelltext nur im Hirn von VE und kann weder von lintHint analysiert werden, noch kann in den hineingesprungen werden. Was der gelbe Button also nur machen kann, ist die letzte gespeicherte Version zum Server zu senden. Wäre dann in den Dokus zu ergänzen. Unter VE verbleibt die Seite in der Leseansicht, wie du auch ganz richtig festgestellt hast. Die Bearbeitung passiert nur virtuell, es gibt keinen Quelltext .

LG --PerfektesChaos 18:02, 20. Sep. 2020 (CEST)

Na bei LintHint sehe ich ja die Versionsnummer. Ich werde schauen. --Liebe Grüße, Lómelinde Diskussion 19:03, 20. Sep. 2020 (CEST)

Version -4.3

Schaltfläche ist jetzt aktiv, Opacity aber bleibt über allem, so dass es eher inaktiv wirkt. Verhalten ist ansonsten wie beschrieben. Ich habe jetzt mal einen Edit Spezial:Diff/203868777/203868808 in der Form getätigt, absichtlich an einem eher kleinen Artikel.

• Nach Behebung des Fehlers und Speichern der Seite wird dies nicht sofort erkannt. LintHint steht noch auf dem Stand der Vorherversion, also zeigt es den Fehler in der Leseansicht noch an. Erst nach einem Neuladen der Seite ist es ok und wird grün.
• In der Vorschau ist weiterhin keine Schaltfläche (auch kein Seitenmenü, die Vorschau legt sich über alles), dort wäre es aber eventuell sinnvoll, um zu sehen, ob alle Fehler weg sind. Aber dieses VE-Zeugs ist recht komplex aufgebaut, das ist dann wieder eine andere Oberfläche, die einen neuen imaginären Content abbildet. Zudem fehlen mir dort WSTM und die Zeichenleiste unten, aber immerhin ist Schnarks Syntaxhighlight noch aktiv, ein Trost, TableExpander wäre auch erreichbar, erkennt aber in der Quelltextansicht natürlich einzig die von LintHint erzeugte Tabelle.

So und nun schalte ich 2017 wieder aus. --Liebe Grüße, Lómelinde Diskussion 07:22, 22. Sep. 2020 (CEST)

@Lómelinde: Ah, so schnell trinkt man keinen Korn aus der Flinte. Steht bei dem Dings wo den Grauschleier macht irgendwo mal was von z-index (mit einer Zahl, die bräuchte ich) oder ist der von dir angegebene Quellcode schon alles?

Weil, da lässt sich auch mit Trumpf-Trumpf drübertrumpfen.

LG --PerfektesChaos 17:24, 22. Sep. 2020 (CEST)

Du bist ja lustig wie soll ich das denn finden, da sind etliche div-Konstrukte.

neben diesem div <div id="content" class="mw-body" role="main"> steht in der Box wo man diese Kästchen umschalten kann ein z-index: 0

<div id="bodyContent" class="mw--body-content"> in dem das LintHint-top … drin steht hat

.ve-init-mw-desktopArticleTarget #bodyContent {
    z-index: 1;
}

Da steht aber ein  Info: dran das besagt, dass dieses z-index wirkungslos sei, weil es kein positioniertes Element ist …. Wenn ich jemals begreifen sollte, wie man in der Konsole das kopiert was man kopieren möchte, könnte ich dir den Text hier leichter einfügen, ohne immerzu zwischen den Tabs wechseln zu müssen um es abzuschreiben. Ein durchgestrichenes steht in dieser Regel.

.mw-body-content {
	position: relative;  -- gestrichen
	z-index: 0;  -- gestrichen
}

Und die Regel, von wo ich es kopiert habe lautet wie oben bereits eingefügt komplett so

.ve-loading #content > :not(.ve-init-mw-desktopArticleTarget-loading-overlay), .ve-activated .ve-init-mw-desktopArticleTarget-uneditableContent {
	pointer-events: none;
	-webkit-user-select: none;  -- gestrichen
	-moz-user-select: none;  -- gestrichen
	-ms-user-select: none;  -- gestrichen
	user-select: none;
	opacity: 0.5;
}

Die ist ohne index Und irgendwo gibt es noch eine Regel mit

.oo-ui-defaultOverlay, .skin-vector .oo-ui-windowManager-modal > .oo-ui-dialog, .skin-vector .ve-ui-overlay-global {
	z-index: 101;
}

Mehr finde ich nicht. Der Button hat zwar opacity : 1 aber eben ohne Wirkung, das gilt für die gesamte LintHint-top-Eigenschaft, wenn ich dieses opacity : 0.5 aus der Regel entferne ist es klar und deutlich sichtbar, ebenso verhält sich der Seitentitel, er wird dann auch besser lesbar. Das opacity ist nochmals hier drin <div style="clear: both;" class="ve-init-mw-desktopArticleTarget-uneditableContent"></div> (also in der Nebenbox zum umschalten) es scheint irgendwie eine vererbte Eigenschaft des Titels zu sein denn es steht auch in <h1 id="firstHeading" class="firstHeading ve-init-mw-desktopArticleTarget-uneditableContent" lang="de">Seitentitel</h1> Ich hoffe das hilft irgendwie --Liebe Grüße, Lómelinde Diskussion 07:17, 23. Sep. 2020 (CEST)

Naja, das ist doch schon mal ganz niedlich.

Nun gehe zu den beiden gelben Elementen, die unter dem Grauschleier liegen, und sage ihnen:

• z-index: 2
• Falls das nicht wirkt: 102
• Wenn immer noch nicht: 99999

Mit diesen Index-Nummern sollte sparsam umgegangen werden; jeder setzt die gern um noch 100 und noch 1000 höher, und irgendwann stapeln sich die Ebenen bis zum Mond.

LG --PerfektesChaos 12:44, 23. Sep. 2020 (CEST)

Wie bitte, wie soll ich denen denn etwas sagen? Und welche gelben Elemente? Ich bin keine Programmiererin ich habe Probleme mit diesem Konsolenwerkzeug. --Liebe Grüße, Lómelinde Diskussion 13:01, 23. Sep. 2020 (CEST)

Ne echt nicht, ich kann da hinschreiben was immer ich möchte solange das opacity : 0.5 aus dem Header aktiv ist geht da nichts drüber. --Liebe Grüße, Lómelinde Diskussion 13:20, 23. Sep. 2020 (CEST)

„steht in der Box wo man diese Kästchen umschalten kann“

Da kannst du nicht nur Häkchen machen und wegnehmen, du kannst auch die Werte ändern und die Namen von Eigenschaften.

Und du kannst komplett neue Eigenschaften zu einem Element hinzufügen; hier halt: z-index

LG --PerfektesChaos 14:02, 23. Sep. 2020 (CEST)

Es hat aber keinerlei Wirkung. Nur das entfernen des Kästchens opacity: 0.5 löst irgendetwas aus. Ich kann da z-index 10000 schreiben es tut sich nichts. Weil dieser Schleier nun mal ganz außen drüber liegt. --Liebe Grüße, Lómelinde Diskussion 14:07, 23. Sep. 2020 (CEST)

Mhm. Okay. Mhm. Grauer Nebel liegt zu hoch. Muss ich noch denken.

Theoretisch möglich, aber nicht sehr sauber und nicht sehr robust.

Das wird dann wahrscheinlich nicht ohne riesigen Extra-Aufwand machbar sein, weil es dann eine blinde Attrappe unter dem Grauschleier und eine aktive Dublette obendrüber geben muss. Und wenn sich an der Bildschirmgröße was ändert müsste neu justiert werden.

Der Nebel liegt so hoch, dass ich oberhalb der gesamten Seite schweben müsste. Von da aus können die gelben Elemente aber nicht mehr sehen, was unter ihnen liegt, was sie verdecken würden, und können nicht den Veränderungen des Fenster-Layouts folgen. Es müsste zu beiden ein Dummy gleicher Größe und deshalb gleichen Inhalts angelegt werden, diese Dummies werden in das Layout eingefügt, also unter dem Grauschleier, danach oberhalb des Grauschleiers genau drüber die gelben echten, und wenn sich die Position der unteren irgendwie ändert müssten sie die oberen benachrichtigen dass sie sich jetzt verschoben hätten und die oben müssten dem folgen.

Und wenn du, falls du es öfter brauchst, im Einzelfall oder generell diesen Grauschleier wegmachen würdest oder nur ein wenig grau aber nicht so dolle? Der müsste dann wohl eine opacity:0.3 bekommen; dann erinnert er immer noch an den VE-Modus ist jedoch transparenter.

LG --PerfektesChaos 17:48, 24. Sep. 2020 (CEST)

Ich versteh jetzt gar nichts mehr. Der Nebel liegt nicht hoch, er ist vererbt aus der Überschrift id="firstHeading" da ist das Dingen verbaut. Da wird opa in die City geschickt und ehrlich opacity 0.3 dann sehe ich ja gar nichts mehr.

Element mit opacity 0.3 Element mit opacity 0.5 Element opacity ausgeschaltet

Ich benötige das gar nicht ich arbeite nicht mit dem Editor 2017. Das ist mir nur so aufgefallen. --Liebe Grüße, Lómelinde Diskussion 19:09, 24. Sep. 2020 (CEST)

Ja, aber an die Überschrift komme ich nicht robust ran, weil die ist Skin-abhängig, mobil ggf. anders und kann sich dieses Jahr auch mal bei Vector ändern.

• Ich muss mich an mw-content-text dranhängen.
• Ich bin schon von „drin“ nach „davor“ gegangen, mehr ist nicht.

Da muss beim VE irgendwas laufen wie folgt:

• Gelb unten drunter als Normalseite__Grau:0.3__
• Gelb unten drunter als Normalseite__Grau:0.7__
• Was zum Spielen Gelb unten drunter als Normalseite
• Und an die opacity:0.5 von dem dritten Beispiel müsstest du irgendwie rankommen.
• Wenn da ein Grauschleier über Elementen liegt.

Oder da ist kein Grauschleier über Elementen, sondern nur die Schriftfarbe abgedimmt und die Dimmerei kann dann auch auf NullSieben manipuliert werden.

Es übt und lernt.

LG --PerfektesChaos 21:24, 24. Sep. 2020 (CEST)

Also meiner Meinung nach ist da nur ein Dimmer. Es liegt keinerlei Farbe drüber. Ich kann auch das opacity von 0.5 auf 1 setzen dann ist auch alles gut, aber ich kann nichts über einen z-index regeln. Egal wo ich das opacity ändere, es taucht ja mehrmals in den divs auf, es ändert die Eigenschaft der Überschrift mit. Einfacher wäre es doch, wenn du dir das selbst anschauen würdest. Ich bin nicht so gut im erklären der Konsoleneigenschaften.

Es wird nur und ausschließlich dieser Bereich beeinflusst, ich male es jetzt für dich auf.

Simulation

html
body

#mw-page-base
#mw-head-base
#content
.ve-init-target-source
.ve-ui-positionedTargetToolbar
.ve-init-mw-desktopArticleTarget-originalContent
#top

das folgende hat jeweils die Eigenschaft opacity: 0.5

#firstHeading
<h1 id="firstHeading" class="firstHeading ve-init-mw-desktopArticleTarget-uneditableContent" lang="de">Gottfried Leygebe</h1>
#contentSub
#contentSub2
#jump-to-nav
a.mw-jump-link:nth-child(5)
a.mw-jump-link:nth-child(6)
#lintHint-top
<div class="noprint ve-init-mw-desktopArticleTarget-uneditableContent" id="lintHint-top" style="clear: both; width: 100%;"><button id="lintHint-collapsed" style="display: block; float: right; margin-bottom: 3px; padding: 2px; pointer-events: all; background-color: rgb(255, 255, 0); color: rgb(0, 0, 0); opacity: 1;" title="-4.3" class="noprint">lintHint</button></div>
div.ve-init-mw-desktopArticleTarget-uneditableContent:nth-child(8)

div.oo-ui-widget:nth-child(10)
<div class="oo-ui-widget ve-ui-surface ve-ui-surface-source ve-ui-mwSurface ve-ui-mwWikitextSurface ve-init-mw-target-surface ve-ui-surface-dir-ltr">
/* Der editierbare Seiteninhalt wird nicht gedimmt */
</div>
#mw-data-after-content
…

Und es ist völlig egal wohin ich das lintHint schiebe, es behält immer diese Eigenschaft des opacity gekoppelt mit der Überschrift. Ich kann dir das nicht auflösen. --Liebe Grüße, Lómelinde Diskussion 07:35, 25. Sep. 2020 (CEST)

Ich habe weder Kräfte noch Nerven noch Zeit fremde Software-Pakete auszuprobieren, die sich dann auch noch alle Nase ändern können.

Ich brauche schon exakte Anweisungen was ich für einen style setzen soll.

Letzter Versuch: Gib den gelben lintHint mal style="opacity: 1 ! important" mit. Dann weiß ich auch nicht mehr.

LG --PerfektesChaos 00:44, 27. Sep. 2020 (CEST)

Ich weiß nicht, ob ich mich wirklich so unklar ausdrücke, aber das ist irgendwo mit dem anderen direkt verbunden, da lässt sich nichts einzeln einstellen, ändere ich dort den Wert, ändert sich das automatisch für alles was ich oben gedimmt habe, da lässt sich auch nichts mit important regeln. Ich habe zu wenig Ahnung davon, um festzustellen woher das genau kommt, wer das vorgibt und weshalb es eine gemeinsame Eigenschaft ist, die alles beeinflusst. Es ist sinnlos einem gedimmten Button eine noch so hohe Priorität oder Ebene zu verpassen, wenn der Dimmer danach von Außen drüber gelegt wird. Ich meine es taucht erstmals in einem <a id="top" class="ve-init-mw-desktopArticleTarget-uneditableContent"></a> Element auf, was auch immer das ist. Dann setzt es sich fort bis der Bereich zu einem div mit der id div.ve-init-mw-desktopArticleTarget-uneditableContent:nth-child(8) Das hat folgenden Inhalt:

html.client-js.ve-not-available.ve-activated.ve-active body.mediawiki.ltr.sitedir-ltr.capitalize-all-nouns.mw-hide-empty-elt.ns-0.ns-subject.mw-editable.page-Eduard_Hübner.rootpage-Eduard_Hübner.skin-vector.action-view.skin-vector-legacy div#content.mw-body div.ve-init-target-source.ve-init-target.ve-init-mw-target.ve-init-mw-articleTarget.ve-init-mw-desktopArticleTarget div.ve-init-mw-desktopArticleTarget-originalContent div#bodyContent.mw-body-content div.ve-init-mw-desktopArticleTarget-uneditableContent

Anschließend folgt der eigentliche Seitenquelltext und der ist, wie geschrieben ungedimmt und beginnt ab div.oo-ui-widget:nth-child(10) danacht ist kein opacity mehr vorhanden. Ich vermute es hat irgendetwas mit der Eigenschaft .ve-activated .ve-init-mw-desktopArticleTarget-uneditableContent zu tun, denn die steht in dem CSS-Selektor des lintHint mit drin. Ich kann das nicht lösen, es klebt zusammen wie Pech und Schwefel. Ich benötige das nicht, ich verwende den normalen Editor. Ich kann gut damit leben, solange man mich nicht zwingt den Editor zu wechseln. --Liebe Grüße, Lómelinde Diskussion 07:24, 27. Sep. 2020 (CEST)

Why doesn't it detect this missing table close?

Hi. First, thanks for this great tool!

I noticed today that it finds no error in en:Special:PermaLink/980597500, yet the article is missing a table-closing at the end of the table in the Confederations section. Thanks! —[AlanM1(talk)]— 22:51, 27. Sep. 2020 (CEST)

I do think the missing of a table close |} is not in every case an lintError for the software. So the tool can’t find it. This is something I often aked me why the software can find missing tag like div, small, span, italic or bold, but not a missing end of a table. In your example the following content is interpreted as content of the table itself. The missing of the table ending should be found by the software, than lintHint will find it too. --Liebe Grüße, Lómelinde Diskussion 06:41, 28. Sep. 2020 (CEST)

I'm afraid what you're saying appears to be contradictory. Yes, lintHint routinely finds tables that are opened but not closed, as it does with div, italic, etc. markup. This is fairly straightforward to do, which is why I wonder why it fails in this case (and no others that I've seen). —[AlanM1(talk)]— 13:08, 28. Sep. 2020 (CEST)

Yes in many cases it will find the error, but this case is spacial, I know many pages with frames build up with tablesymtax on talkpages left open I’ll seach for an example.

see wikitext in Benutzer:Warhog/Vorlage:Diskussionsseite the table is open at the end an the pageinformation does not mark any LintError →info. I have often seen such pages. I hope you’ll understand I am not an English speaker. --Liebe Grüße, Lómelinde Diskussion 13:39, 28. Sep. 2020 (CEST)

Please note: This tool lintHint is just broadcasting reports of the Parsoid syntax processing.

• This tool does not analyse any code.
• It does nothing more than making analysis results visible.
• It has no knowledge about meaning and circumstances of the messages forwarded to the reader.

Please address any content issues to mw:Help:Extension:Linter etc. THX --PerfektesChaos 15:15, 28. 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)

List of all error codes?

Is there a list of all of the errors that can be reported, with some description of what the error means?GhostInTheMachine (Diskussion) 10:08, 5. Mai 2021 (CEST)

In this wikiproject we have H:Wikisyntax/Validierung#Problemtypen with some descriptiopns of possible errors. But it is not a list of all errors that can occure. --Liebe Grüße, Lómelinde Diskussion 14:16, 5. Mai 2021 (CEST)

Please see mw:Help:Lint errors.

This tool here is stupid.

It is just forwarding and formatting small pieces of information gathered from Lint service.

This tool here has no knowledge what it is presenting.

Greetings --PerfektesChaos 01:29, 6. Mai 2021 (CEST)

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)

Button / Knopf und Anzeigebereich

Entweder träume ich oder du hast ein Radiergummi verwendet, um den Rahmen der Schaltfläche zu eliminieren. Ich gewöhne mich an vieles, auch an das nun springende Knöpfchen. Aber wenn du auf der Vorderseite nun explizit so etwas schreibst:

…Knopf lintHint in der rechten oberen Ecke angeboten … dann erwarte ich nicht, dass es stattdessen so lintHint

aussieht

Der gelbe Kasten enthält üblicherweise eine Tabelle mit Fehlerhinweisen. → und hatte, wenn ich mich nicht irre, zuvor auch einen Rahmen (da ist ein 2 Pixel dicker transparenter Rahmen, was habe ich davon?), oder auch nicht, jedenfalls ist irgendetwas anders. Unschön finde ich die Anzeige der grauen (ich bin gerade aktiv beschäftigt, bitte warte bis ich fertig bin) Schaltfläche oberhalb der Tabellenbox.

lintHint

Seitentitel

---

Fehlertabellenkasten

Sie hat den merkwürdigen Effekt, dass man das gelbe Anzeigefeld nun quasi mit einem Klick ausblenden und die Analyse nochmals starten kann (obwohl grau eigentlich inaktiv oder bin gerade beschäftigt bedeuten sollte). Ich finde das eher verwirrend.

… erscheint ein kleines grünes Feld lintHint …

Da hat sich nicht viel verändert, denn es hatte auch zuvor schon „keinen“ Rahmen und sah so aus wie jetzt auch lintHint.

Die Schaltfläche ist mal hier mal da mal doppelt oder dann doch zumindest redundant zum roten X und einem Neustart über gelb. Ich bin mir nicht sicher, ob mir diese Neuerung jetzt irgendwelche Vorteile gebracht hat. Und ja, ich habe den Abschnitt eins drüber durchaus registriert. --Liebe Grüße, Lómelinde Diskussion 14:10, 27. Mai 2021 (CEST)

Rufe doch mal einen lesenswerten oder exzellenten Artikel auf. Dann siehst du den Grund.

Und in der Mobildarstellung gibt es den Rahmen weiterhin. Weil keine Seitenindikatoren.

Ein Problem ist, dass die ganze Seitendarstellung nachträglich nach unten geschoben werden muss, was leicht passieren kann, wenn jemand ein langsames JS hat. Das ist die Schilderung von eins drüber.

Ein anderes Problem ist, dass der reservierte Bereich eine fingerdicke Lücke zwischen Seitenkopf und Textanfang blockiert, weil das Layout der Seite mit Infoboxen usw. erst unterhalb dieser lintHint-Lücke beginnen kann.

Das andere noch offene Problem von weiter oben werde ich im Zuge dieser Änderung auch versuchen zu lösen.

 Der kleine Anker von fragmentAnchors wird übrigens auch irgendwann nach da oben wandern. In der Werkzeugbox wirkt seine ganze Zeile doch arg verloren, und mobil gibt es die gleich gar nicht.

LG --PerfektesChaos 16:25, 27. Mai 2021 (CEST)

Nö ich mag diese Bapperl nicht. Ich wollte es auch nur erwähnen, ich kann damit leben. --Liebe Grüße, Lómelinde Diskussion 16:45, 27. Mai 2021 (CEST)

Mobil, also wenn ich in der mobilen Ansicht versuche etwas zu bearbeiten dann ist der Button weg. Anders ist es, wenn ich während der Bearbeitung nach dorthin umschalten würde. Vielleicht bin ich zu dusselig dafür. Wenn ich versuche einzelne Abschnitte zu bearbeiten ist da kein lintHint sichtbar, es steckt irgendwo oben hinter irgendetwas.

Und generell hat grün trotzdem keinen Rahmen. --Liebe Grüße, Lómelinde Diskussion 18:08, 27. Mai 2021 (CEST)

Ich habe es mir überlegt, so unpraktisch ist der graue Button gar nicht. Vielleicht kann man ihm einfach einen Titel „aktualisieren“ anfügen. --Liebe Grüße, Lómelinde Diskussion 11:12, 28. Mai 2021 (CEST)

@Lómelinde: Sodele, inzwischen besser?

• Und an #lintHint does not appear on the 2017 editor war ich auch dran; zumindest erstmal: „Was mich aber echt nervt ist die schlechtere Sichtbarkeit so als wäre da ein opacity über die komplette Seite gelegt“.
• Jetzt zumindest Teilerfolg?

LG --PerfektesChaos 01:32, 4. Jun. 2021 (CEST)

zu 1. Ich sehe keinerlei Unterschied. (außer dass da im Tooltip der grauen Fläche jetzt ein ! steht, wo zuvor ein … zu sehen war, grün hat ein + das war aber zuvor auch da, Version sagt -4.6 Verhalten ist wie zuvor, man kann damit bequem eine Analyse neu starten ohne zuvor das rote Kreuz klicken zu müssen, was aber auch normal funktioniert)

die Konsole sagt mir

• Fehler beim Verarbeiten des Wertes für 'opacity'. Deklaration ignoriert.
• https://de.wikipedia.org/api/rest_v1/transform/wikitext/to/lint

also Fehler sehe ich keine

zu 2. Da ist keine Schaltfläche mehr, Opacity liegt aber weiterhin über der kompletten Seite. Ebenso wie ich mobil keinerlei Schaltfläche sehe sobald man auf Bearbeiten geht. Beispielsweise wenn man in der mobilen Ansicht aus der Linterfehlertabelle einem Bearbeiten-Link folgt. Erst ist es ebenso verschwommen noch sichtbar (solange der Ladevorgang läuft) aber sobald die Bearbeitungswerkzeugleiste erscheint (egal ob Quelltext oder visuelle Bearbeitung) ändert sich die Ansicht und die Schaltfläche ist weg, unerreichbar irgendwo verborgen, sie wird aber durchaus aufgelistet, als

<div class="noprint linthint-top" id="linthint-top" style="clear: both; width: 100%;"><div class="linthint-collapsed noprint" id="linthint-collapsed" role="button" style="cursor: pointer; padding-left: 2px; padding-right: 2px; padding-top: 2px; pointer-events: all; float: right; border-color: rgb(224, 224, 224) rgb(224, 224, 224) rgb(112, 112, 112) rgb(112, 112, 112); border-style: solid; border-width: 2px; margin-bottom: 3px; background-color: rgb(255, 255, 0); color: rgb(0, 0, 0);" title="-4.6">lintHint</div></div>

Es ist als würde sie verborgen, weggeklappt, unsichtbar gemacht, oder was weiß ich. Wenn ich es richtig herauslese, dann liegt die Schaltfläche im Inhaltsbereich oben rechts zumeist hinter einem Bild oder einer Infobox. Bearbeitet man nur die Einleitung hier dann wandert das unsichtbare linthint weiter nach unten (eigentlich anders es bleibt an der Position wo es zuvor auch war, der Text wandert eher nach oben), bearbeitet man einen Abschnitt wie „Leben“, dann ist die Schaltfläche oben ungefähr im Bereich der Abschnittsüberschrift. Nimmt man nun einen Abschnitt „Ausstellungen“ dann ist die Schaltfläche quasi aus dem Anzeigebereich verschwunden ich kann sie optisch (graue Vorschau wo das Dingen sein sollte) nicht erreichen, sie muss weit weit oberhalb sein. Ein ein- oder ausgeklapptes Inhaltsverzeichnis hat ebenfalls einen Einfluss auf diese Position. Es schiebt die Schaltfläche nach oben, selbst wenn das Inhaltsverzeichnis ja bei der Abschnittsbearbeitung gar nicht zu sehen ist. Auch ein Einklappen der einzelnen Abschnitte beeinflusst scheinbar die Position, sie ist nicht an einer irgendwie nachvollziehbaren Stelle festgemacht. Und in allen Fällen, wo man Bearbeiten sagt, eben komplett unsichtbar. Weil etliche Folien sich wohl darüber legen, aber irgendwo mitten im Bearbeitungstext wäre ja auch nicht praktikabel.

So für dich habe ich es jetzt noch in Minerva probiert, dort ist alles sichtbar, dort hat sogar der grüne Button einen Rand. Da liegt die Schaltfläche auch tatsächlich außerhalb des Bearbeitungsbereichs, also rechts oben daneben. Ich weiß nicht wie ich dir da helfen könnte. --Liebe Grüße, Lómelinde Diskussion 07:59, 4. Jun. 2021 (CEST)

Nun komplett neu.

In diesem dussligen 2017-Modus liegt in der Tat eine Schutzdecke über dem Überschriftbereich nebst Indikatoren.

Deshalb ist es kaum möglich, den gelben Button rechts oben zu packen.

Er liegt dann jetzt halt links in der Toolbox, beim Anker.

Die Fehlermeldungstabelle liegt fortan immer oberhalb des Seiten-Inhalts-Beginns (=Seiten-Überschrift).

Das Bearbeitungsfeld ist überhaupt keins, tut nur so. Ist pro Zeile ein HTML-div, und da kann ich nicht trivial draufpositionieren.

LG --PerfektesChaos 01:26, 13. Jun. 2021 (CEST)

Leider ebenso ohne jegliche Auswirkung, hier folgt der Code aus dem Inspektor:

Du meintest doch im Abschnitt Werkzeuge dort wo der Anker und der Expander stehen, da ist nichts. Und dieses gruselige Opacity über dem Bearbeitungsbereich finde ich auch nicht sonderlich barrierefrei. Aber da können wir ja nichts machen. Zudem ist jener Code oben, grau, also inaktiv? Ich finde dort ganze 3 linthint-Einträge

1 steht in etwas, das mit script-Tags eingeschlossen ist, es ist das zweite dieser Skripte und enthält wohl die normalerweise hier angezeigten Menüpunkte zum Benutzer oberhalb der Seite, obwohl ich nicht genau sehe wo. Der Bereich lässt sich nicht kopieren.

2 und 3 in dem Bereich den ich oben kopiert habe mit dem grauen div

Mehr sehe ich nicht.

bezüglich „Die Fehlermeldungstabelle liegt fortan immer oberhalb des Seiten-Inhalts-Beginns (=Seiten-Überschrift).“

Das sieht dann jetzt so aus (also bei Bearbeitungen ohne 2017-Editor)

Fehlertabellenkasten

lintHint

Seitentitel

---

Die graue Schaltfläche bleibt sichtbar, ist aber nicht mehr aktiv, kein Restart. --Liebe Grüße, Lómelinde Diskussion 07:23, 13. Jun. 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)

Not working with ExpandTemplates

lintHint has always worked with in English Wikipedia with ExpandTemplates, until now. Now, it doesn't work. I go to en:Special:ExpandTemplates, and in the "Input wikitext:" box I type <strike>, and click on the green lintHint, and nothing happens. –Anomalocaris (Diskussion) 21:24, 14. Jun. 2021 (CEST)

@Anomalocaris: Eh, sorry for inconvenience.

Recently there has been a major change in the debugging version (-4.7), but the release is 4.1 from April 2019.

Therefore, first question: Which code do you load, d.js for development or r.js which is stable?

If you are using d then you might shift to r for a while.

As soon I get time I will look at this issue, and another one, but probably on weekend. I am quite overburdened.

Thanks anyway for reporting --PerfektesChaos 21:46, 14. Jun. 2021 (CEST)

OK, I switched to r.js, and now lintHint works fine with ExpandTemplates. Danke! –Anomalocaris (Diskussion) 21:58, 14. Jun. 2021 (CEST)

Nur zur Info

LintHint kollidiert derzeit mit dieser Vorlage Benutzer:J-PG/Beitragszähler. Soll heißen es liegt unten drunter und kann nicht angeklickt werden. Neulich hatte ich noch eine andere lustige Kombination mit der Tourbushaltestelle. Benutzer:Moschitz/Babel Beispiel: Benutzer:Moschitz/Babeltour, da ist es allerdings klickbar, nur sieht man gelb auf gelb (lintHint steht dann direkt hinter Haltestelle) fast nicht.

Und ab und zu erscheint die Schaltfläche nicht (Zeitproblem) und ich muss mir behelfen, indem ich eine Seite neu lade oder auf Änderungen zeigen klicke, obwohl ich noch nichts verändert habe, dann ist sie da. Das ist aber nicht wirklich schlimm. --Liebe Grüße, Lómelinde Diskussion 11:12, 28. 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)