Wikiup Diskussion:Lua/Modul/WLink

Vorlagenprogrammierung	Diskussionen	Lua			Test	Unterseiten
		Modul	Deutsch	English		Modul:	Dokumentation

Wikipedia:Lua/Modul/WLink/Test

Bei dem link auf die Testseite bekomme ich die allgemeine Fehlerseite von WP (PHP fatal error in /usr/local/apache/common-local/php-1.24wmf3/includes/parser/Preprocessor_DOM.php line 1692: Call to a member function item() on a non-object )? lg --Herzi Pinki (Diskussion) 01:20, 13. Mai 2014 (CEST)

Gut bobachtet; wusste gar nicht, dass sich schon jemand für diese Seite interessiert.

Mehr dazu: BD:Umherirrender #I shot the sheriff, I crashed the server

Donnerstag nächster Woche könnte er wieder weg sein. Auf beta wurde er bereits behoben.

Nimm den solang.

LG --PerfektesChaos 09:10, 13. Mai 2014 (CEST)

Frage

Hallo, verwende die Funktion WLink::getPlain() inzwischen häufig an der Schnittstelle zum Geohack. Sehr nützlich. Bei Rheinufertunnel (Düsseldorf) bin ich über ein Problem gestolpert, wo ich gerne die Meinung des Kontraktes von getPlain() hätte. Dort wird aus Rheinufertunnel mittels {{#invoke: WLink | getPlain |1=xxx {{RSIGN|DE|B|1}} Rheinufertunnel}} schlussendlich xxx Rheinufertunnel oder ähnliches. Komischerweise zeigt es google nach Übergabe der Parameter anders an.

Meine Frage: Soll WLink::getPlain() eingebettete Grafiken nicht komplett wegfressen (erzeugt plain text), oder wie sieht das die Funktion vor? lg --Herzi Pinki (Diskussion) 09:28, 31. Okt. 2014 (CET)

siehe bitte auch Vorlage_Diskussion:Coordinate#Problem_bei_Name_im_Geohack_und_genereller_Lösungsvorschlag. --Herzi Pinki (Diskussion) 10:45, 31. Okt. 2014 (CET)

Hm, Bibliotheksfunktion, Fragestellung und Situation sind neu.

• Ursprünglich konzipiert ist es für kleine Vorlageneinbindungen, bei denen höchstens eine Datei-Verlinkung (also mit führendem Doppelpunkt) vorkäme.
• Hier ist es eine Datei-Einbindung. Für diese wie auch an Kategorien oder Interlanguage war es bislang nicht gedacht gewesen. Fieserweise auch noch in einer Vorlage versteckt.
• Ich kann natürlich ohne Performance-Probleme schauen, ob {{ drin vorkommt, und in diesem Fall das erstmal expandieren, falls nicht sowieso schon passiert (müsste aber eigentlich). Mit etwas Glück sehe ich dann wieder normalen Wikitext.
• Ich kann zusätzlich jedes Linkziel untersuchen, ob ein Doppelpunkt darin vorkäme, und falls ja, ob dieser an erster Stelle stünde oder nicht. Wenn es nur mindestens einen Doppelpunkt im Inneren gibt, kann ich relativ einfach interpretieren, ob es sich um den NR Datei, File, Bild, Image, Kategorie, Category handeln würde und dann die Sonderfälle berücksichtigen; also Nulltext.
• Die Bildlegende kann ich nicht zwischen den zunächst englischsprachigen, obendrein deutsch und sonstwie übersetzten Medienparametern herausfischen. Insofern geht die Bildunterschrift genauso wie ein alternativer Tooltip auf Null.
• Sorgen macht mir an der Bildlegende, dass sie beliebig kompliziert sein kann, insbesondere Tabellen und Links und vor allem weitere Dateieinbindungen enthalten kann; so oft bei der Legende von Flaggen zu sehen. Außerdem gäbe es noch nowiki, das bislang auch nicht berücksichtigt ist; oder syntaxhighlight und pre – was das Auffinden des schließenden Klammerpaares weiter erschwert, aber vermutlich teilweise auch nur Cache-Identifizierer ohne Klammern liefern würde. Oder Konstrukte, bei denen Klammern durch includeonly zunächst unwirksam gemacht sind.
• Die Funktion kann keinen kompletten Wikiparser leisten.
• Ich kann sie nach und nach im Sinne der von dir gegebenen Anregung ausbauen, aber es wird sich immer ein komplexer Fall finden, bei dem sie versagt.
• In den nächsten Tagen schaun wir mal.

LG --PerfektesChaos 12:17, 2. Nov. 2014 (CET)

danke mal für deine komplexe Analyse :-( Und danke fürs Schauen. Das Versagen in Einzelfällen ist akzeptabel, da nicht dramatisch: Für meinen Use Case (geohack) ist es nicht so schlimm, wenn da gelegentlich doch noch Schmierzeichen durchkommen. Die Koordinaten stimmen ja.

Da fällt mir ein, was machst du mit <ref>s? Gehörten auch weg.

Ich habe immer noch die Möglichkeit, Bapperl in Boxtiteln zu verbieten. Schlimmstenfalls über einen zusätzlichen Infobox Parameter. lg --Herzi Pinki (Diskussion) 13:03, 2. Nov. 2014 (CET)

Naja, ich kann relativ simpel das mutmaßliche Vorkommen von Tags anhand der Existenz eines < herausfinden, und dann im Prinzip in eine verschärfte Analyse schalten.

Aber da muss ich dann auch an die Performance denken, erlaubte <br /> drinlassen und böse Sachen rausnehmen.

Wer sagt mir eigentlich, dass das <ref immer und überall unerwünscht wäre?

Und was mache ich, wenn ich das schließende Tag nicht finde, oder die falsch verschachtelt sind, oder HTML-Kommentare, oder damit auskommentierte End-Tags?

Ich müsste erstmal philosophieren.

Die Situationen, die ich beim Entlinken eines Vorlagenparameters vor Augen hatte, waren sehr viel trivialer gewesen.

LG --PerfektesChaos 13:36, 2. Nov. 2014 (CET)

Vorlage:Smiley/Wartung/traurig  es ist halt nur ein Vorlagenparameter. --Herzi Pinki (Diskussion) 14:57, 2. Nov. 2014 (CET)

getArticleBase

Die Funktion wird in Vorlagen, z.B. Vorlage:IMDb benutzt, um den Linktext zu erzeugen. Wäre es möglich, dass man auch eine durch {{SEITENTITEL}} erzeugte Kleinschreibung berücksichtigt? --Färber (Diskussion) 12:09, 9. Jul. 2015 (CEST)

Nein, denn das Dingens weiß auch nicht mehr als die Seitenvariablen.

Es nimmt die Zeichenkette, die sich analog zu {{PAGENAME}} aus den Bibliotheksfunktionen ergibt, und solange die keine Angaben von {{SEITENTITEL:}} widerspiegeln, können die umseitigen Funktionen das auch nicht darstellen.

Nächste Tücke ist, dass {{SEITENTITEL:}} nicht nur den ersten Buchstaben kleinschreiben darf, sondern auch Syntax wie Kursivschreibung oder <sup></sup> einbauen kann; was soll dann damit geschehen?

VG --PerfektesChaos 12:52, 9. Jul. 2015 (CEST)

Eckige Klammern in Linktext

Hallo, wann ist es nötig, eckige Klammern in Linktexten schon im Vorlagenparameter zu escapen? Hier gibt es mehrere Funktionen, die das überprüfen: wenn ich es richtig verstehe, sollte {{#invoke:WLink|isBracketedLink|Foo [sic!] Bar}} true (oder einen nicht leeren String) liefern und {{#invoke:WLink|isValidLinktext|Foo [sic!] Bar}} false (oder leeren String). Leider gibt aber beides, mit #if: abgefragt, einen leeren String - und mit subst:#if gibt beides einen nicht-leeren String:

• {{#if:{{#invoke:WLink|isBracketedLink|Foo [sic!] Bar}}|true|false}}: false
• {{#if:{{#invoke:WLink|isValidLinktext|Foo [sic!] Bar}}|true|false}}: false
• {{subst:#if:{{#invoke:WLink|isBracketedLink|Foo [sic!] Bar}}|true|false}}: true
• {{subst:#if:{{#invoke:WLink|isValidLinktext|Foo [sic!] Bar}}|true|false}}: true

Die Vorlage:Webarchiv benutzt isBracketedLink, dadurch werden die Klammern (text=''Die Judo-Sportzentrum ist ferrtiggestellt [sic!] ...) im Artikel Speyer nicht erkannt (Wartungskategorie). Die Vorlage:Internetquelle benutzt isValidLinktext, dadurch werden die Klammern (titel=[WN+] ...) im Artikel Andreas Kalbitz erkannt. In beiden Fällen stören die Klammern eigentlich nicht, da die Vorlagen ja auch invoke:WLink|getEscapedTitle benutzen. Keine Überprüfung hat die Vorlage:cite web, da könnte man getEscapedTitle einsetzen, wenn es gewünscht ist. --androl ☖☗ 01:33, 19. Mai 2020 (CEST)

• Erstmal ist diese Moduldiskussion der völlig falsche Ort, um die Anwendungen in einzelnen Vorlagen und gar die Formatierung in Artikeln zu diskutieren.
• Dann ist es grundsätzlich keine gute Idee, eckige Klammern in Werktitel-Linktexten zu verwenden. Sie sehen doof aus bei der Schrägstellung.
• Weiterhin ist es das Ziel, die Vorlageneinbindung wieder weglassen zu können und zum normalen Quelltext zurückkehren zu können. Dann müssen die eckigen Klammern jedoch, wo wirklich nötig, escaped sein.
• Vorlage:Internetquelle wird sehr oft durch VisualEditor-Benutzer mit zwei Klicks ohne genauer hinzugucken benutzt, und da schreibt dann der VisualEditor-Citoid den ganzen Reklame-Müll aus dem Titel der Website mit rein, und das müsste dann sowieso von richtigen Autoren nachbearbeitet werden.
• Vorlage:Webarchiv wird fast nur automatisiert von einem Bot geschrieben, und wenn da vorher schon Klammer-Schrott in einem Weblink stand, dann soll das jetzt durch einen Menschen aufgearbeitet werden.
• Wenn ein [sic!] nicht Bestandteil der in der Zeitung abgedruckten Überschrift des Artikels war, dann hat es in der Linkbeschriftung nichts verloren, gehört in einen Kommentar und es wird völlig zu Recht eine Wartungskat ausgelöst.
• Zu Vorlage:cite web wäre mir nicht bekannt, dass sie jemand pflegt.
• Wenn du subst: machst, musst du das auch auf jeden inneren Aufruf anwenden, also auf #invoke: ebenso.

VG --PerfektesChaos 12:09, 19. Mai 2020 (CEST)