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)

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)

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)

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)

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)

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)

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)

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)

Fehler in Sprachlinks

Mir ist aufgefallen, dass lintHint Linterfehler in Links auf andere Sprachversionen ignoriert, wenn diese nicht mit einem führenden Doppelpunkt verlinkt sind.

[[pl:Wikipedysta:Luca|<font color="blue">Luca]] [[pl:Dyskusja Wikipedysty:Luca|<font color="green"><small><sup><b>[conversacione]</sup></b></small></font>]]

Das zeigt so keinerlei Fehler weder die veralteten Fonttags noch das verschachtelte sup-b. Ich hatte das jetzt mehrfach und habe mich gefragt, ob das generell nicht erkannt wird oder nur vom Tool nicht. Die Seite zeigt aber in den Seiteninformationen tatsächlich 8 Fehler ich finde mit dem Tool nicht einen einzigen. Die Fehlerlisten sagen aber auch da sind Fehler Tilman Berger Kannst du das anpassen oder muss ich weiterhin den Quelltext manuell durchsuchen? Ich meine ich suche eh nach font-Tags irgendwo im Quelltext also mit insource aber … na ja es wäre einfacher keinen Fehler zu übersehen, wenn sie alle erkannt würden. Ich lasse daher mal diese Benutzerseite links liegen. --Liebe Grüße, Lómelinde Diskussion 14:54, 17. Nov. 2021 (CET)

Ich muss das noch etwas präzisieren. In der Leseansicht werden die Fehler noch erkannt nicht, aber beim Bearbeiten, das vergaß ich zu erwähnen. --Liebe Grüße, Lómelinde Diskussion 15:48, 17. Nov. 2021 (CET)

lintHint findet oder erkennt keine Fehler, sondern meldet nur was die Linter-Datenbank davon weiß, oder was die Online-Analyse des Wikitextes findet.

Ein „wenn diese nicht mit einem führenden Doppelpunkt verlinkt“ ist aber keine Verlinkung, sondern ein interlanguage im Sinne von H:INT.

Damit würde die BD mit einem Artikel, einer Projektseite global verknüpft werden, was bei BD ausgeschlossen ist.

Bei einem interlanguage ist es jedoch bedeutungslos, was zwischen Pipe und schließenden eckigen Klammern passiert; das ist wie ein Kommentar und existiert nicht.

Die Linter-Software ist manchmal etwas seltsam drauf; dass sie hier in unterschiedlichen Situationen unterschiedliche Ergebnisse liefert oder auch, dass sie sich über Vorlagensyntax beschwert, die per includeonly gar nicht wirksam ist und erst nach Auflösung der Pfade mit #if: zusammengebaut werden würde.

Was die von dir eingangs genannte Situation angeht: Die Doppelpunkte müssen da sowieso nachgerüstet werden, damit daraus eine sichtbare anklickbare Verlinkung wird und kein unsichtbares interlanguage bleibt.

LG --PerfektesChaos 16:19, 17. Nov. 2021 (CET)

Hmmmmm aber da ist doch ein sichtbarer Link auf der Seite, da wo alles blau Spezial:Diff/41486056/76329118#Dobrzyca wird.

Ein ähnlicher Fehler selber Benutzer Spezial:PermaLink/58037721#NOWE FOTKI der Benutzerlink ist nicht unsichtbar, das ist ja das verwirrende, es hat eine deutliche Auswirkung und wird bei der Bearbeitung nicht erkannt.

Und hinterher so Spezial:Diff/58037721/217356138 und ja ich habe ihm auch die Doppelpunkte mitgegeben. Aber logisch ist das für mich nicht. Gut dann mach ich die andere Seite jetzt auch noch das sieht sonst doooooof aus. --Liebe Grüße, Lómelinde Diskussion 16:35, 17. Nov. 2021 (CET)

Medien und Bildbeschriftung

Magst du das vorsorglich schon mal mit einbinden? Mir graut schon davor, ich kann es aber noch nicht wirklich testen, wie wann wo und weshalb und wie das dann korrigiert werden sollte. --Liebe Grüße, Lómelinde Diskussion 11:18, 17. Dez. 2021 (CET)

Dankeschön, wie ich sehe habe ich eine neue Version. Ich wünsche dir erholsame Feiertage. --Liebe Grüße, Lómelinde Diskussion 09:39, 24. Dez. 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)

Version -5.3

Nur mal so dumm gefragt, ist das nur für euch Männer sichtbar, oder müsste ich auch irgendetwas von der Veränderung bemerken. --Liebe Grüße, Lómelinde Diskussion 17:54, 26. Apr. 2022 (CEST)

Du kannst einen HTML-Inspektor für ein Abwärtspfeil-Feld starten; dann siehst du zumindest die drei Informationen. LG --PerfektesChaos 17:57, 26. Apr. 2022 (CEST)

Ok, ich wollte nur wissen, ob das auf mich einen Einfluss hat. --Liebe Grüße, Lómelinde Diskussion 17:59, 26. Apr. 2022 (CEST)

Und ich frage extra noch, ob das eine Wirkung auf mich hat. OK, kann sein, das war schon länger dort, aber vorhin ist es mir erst aufgefallen, weil ich ne echt merkwürdige Seite hatte, die geisterhaft gesperrt war, ohne dass man das im Logbuch sehen konnte, aber in den Seiteninformationen stand diese Info und natürlich in dem Button, (nur Quelltext ansehen, nix mit bearbeiten) und da sah ich dann auch diesen Link zu der Tabelle. Vorgegaukelt, das ist recht hilfreich. Irgendeine Frage hatte ich noch, etwas mit Pseudotags, ich weiß echt nicht was ich mit denen machen soll, aber ich denke immer, die fallen uns auch irgendwann auf die Füße also lieber nowiki drum. Schlimm sind da auch immer diese Softwareupdateankündigungen weil da steht dann neu ist <math> und na toll das hat natürlich dann kein Ende </math> Du bist echt süß „mein Schatz“ sehr nett von dir. Ich habe aber die Funktion Revertpingen deaktiviert, ich würde sonst irre werden. --Liebe Grüße, Lómelinde Diskussion 17:28, 27. Apr. 2022 (CEST)

5.1 2022-02-07 phab:T301374

<grins> ist per Definition normaler Text, solange das nicht als HTML/MediaWiki eingeführt wird, wie auch verbotenes HTML <a>, aber ich maskiere die trotzdem mit Entities, damit Bots und Skripte nicht durcheinanderkommen.

• isnich://www.example.org ist auch kein Magisches Wort.

LG --PerfektesChaos 17:59, 27. Apr. 2022 (CEST)

Es ist, wie gesagt, sehr hilfreich, nur schaue ich zu selten in die Seiteninformationen. Danke für die Info. Einen sonnigen Abend noch. --Liebe Grüße, Lómelinde Diskussion 18:13, 27. Apr. 2022 (CEST)

Bezüglich des Links (vorgegaukelt)

Das funktioniert leider nicht mehr. Beispiel: ein Fehler Falsch verschachtelte Tags und der Link führt (wohl durch die letzten Veränderungen) nach hier anstatt nach dort. Es wäre schön wenn du etwas Zeit finden und das anpassen könntest. --Liebe Grüße, Lómelinde Diskussion 10:35, 28. Jun. 2022 (CEST)

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

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)

Kritische Zeichen

Seit dem Update vor ein paar Tagen scheinen bestimmte Zeichen Mitauslöser der Verschiebungen zu sein, dazu zählen aus meinem Text unter anderem †. Hinzu kommen scheinbar auch noch Zeichen aus der Sonderzeichenleiste, wie àéïôǖþǣəП௫ឃᛦᛏ, die alles verschieben, also als doppeltes Zeichen gezählt werden. Vielleicht haben sie irgendwo an den Zeichensätzen etwas geändert. --Liebe Grüße, Lómelinde Diskussion 11:12, 30. Okt. 2023 (CET)

Danke für die Analyse, das geht in die hier schon vermutete Richtung.

Das wäre dann der Effekt „Zeichen ≠ Bytes“:

• Maßgeblich ist die Kodierung per UTF-8.
• Zeichen aus ASCII haben genau ein Byte.
• Alle anderen benötigen zwei oder mehr.
• Siehst du auch in einer URL, bei L%C3%B3melinde – das „ó“ wird in zwei Zeichen C3+B3 kodiert; das wären die beiden Bytes ó (manchmal als Mojibake zu sehen).

Für eine Analyse, was passiert ist, wann warum die Browser genau was machen, was ich vor fünf Jahren programmiert hatte, wie das jetzt im Moment bei denen richtig funktioniert und was ich tun kann damit es wieder passt kann ich erst nach hinreichender Zeit und Ruhe ermitteln. Das Wochenende war nix, und es kam wieder ein halbes Dutzend vorrangig abzuarbeitender überflüssiger Nonsens-Aktionen dazwischen.

LG --PerfektesChaos 11:40, 30. Okt. 2023 (CET)

Es eilt bei uns hier nicht so sehr, unsere Fehlerlisten sind ja derzeit recht überschaubar. Und ein fehlendes Tabellenende ist nicht so schwer zu finden. --Liebe Grüße, Lómelinde Diskussion 11:52, 30. Okt. 2023 (CET)

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)