Benutzer Diskussion:TMg/autoFormatter/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Benutzer Diskussion:TMg/autoFormatter/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Benutzer_Diskussion:TMg/autoFormatter/Archiv#Thema_1

regengine.js

Hi TMg, ich habe ein Projekt, das auch versucht, häufige Probleme automatisch beim Edit zu beseitigen, allerdings konzentriere ich mich mehr auf wirklich eindeutige Fälle. Interessiert dich vielleicht ;-) Gruß, Code·is·poetry 15:38, 9. Okt. 2008 (CEST)

ISSN

moin. magst du vielleicht für issn eine ausnahme hinzufügen? könte etwa so aussehen:

 /* Bis-Striche bei Jahreszahlen */
 t = t.replace(/([^0-9-–][0-9]{4}) *[-–]{1,2} *([0-9]{4}[^0-9-–])/g, "$1–$2");
 /* und nicht bei ISSN */
 t = t.replace(/\{\{ISSN\|([0-9]{4})–([0-9]{4})\}\})/g, "{{ISSN|$1-$2}}");

war mir jetzt schon häufiger begegnet. thx und so für das nützliche tool --AwOc 09:22, 10. Jul. 2009 (CEST)

Danke für den Hinweis. Ich habe deinen Vorschlag etwas abgewandelt übernommen. --TMg 18:23, 10. Jul. 2009 (CEST)

gute idee, er ist ja auch falsch ;) --AwOc 18:24, 10. Jul. 2009 (CEST)

Leerzeichen vor Maßeinheiten

Hallo, dein Script vergeht sich leider an Weblinks. Aus

http://www.amazon.de/s/ref=nb_ss_w?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-alias%3Daps&field-keywords=schulbuch+cornelsen&x=0&y=0

wollte es dies machen:

http://www.amazon.de/s/ref=nb_ss_w?__mk_de_DE=%C5 M%C5Z%D5 %D1&url=search-alias%3Daps&field-keywords=schulbuch+cornelsen&x=0&y=0

Also einmal ein 'nbsp' und einmal ein 'space' einfügen. Link ist zu finden im Artikel Schulbuchverlag.--Ben Ben 19:05, 18. Jul. 2009 (CEST)

Danke für die Meldung. Ich habe die beiden dafür verantwortlichen Ersetzungsregeln strenger formuliert. Es kann zwar immer noch vorkommen, dass mein Skript Maßeinheiten erkennt, wo keine sind. Aber das sollte jetzt wesentlich seltener vorkommen. An meinem Grundsatz, dass ohne manuelle Kontrolle per „Änderungen zeigen“ nichts geht, ändert sich nichts. --TMg 12:45, 25. Jul. 2009 (CEST)

Ich bekomm’s nicht hin

wo soll der Button zum Korrigieren sein? Ich habe genau die angegebene Zeile in meine Datei geschrieben. Auch wenn ich es so formuliere wie das andere eingebundene Script, ändert sich nichts. --androl ☖☗ 23:01, 20. Dez. 2009 (CET)

Unter dem Bearbeitungsfenster, rechts neben dem Link zur Bearbeitungshilfe. Die Position dort hat den Vorteil, dass sie vom Skin relativ unabhängig ist. --TMg 18:23, 21. Dez. 2009 (CET)

danke! bei mir durch Zeilenumbruch direkt unter dem Seite-speichern-Button

Bei Günthersdorf passiert ein Fehler, da setzt das Script den Partei-Parameter in die BKL-Vorlage ein. Stattdessen wäre es schön, wenn das Script die störende Leerzeile zwischen den beiden Vorlagen erkennt und löscht, die erzeugt nämlich einen zu großen Abstand zwischen BKH und Artikelinhalt.

statt „zirka“ gefiele mir persönlich „etwa“ besser, ich glaube, das ist immer gleichbedeutend.

noch ein Fehler: „1850–14. Januar 1854“ wird zu „1850–1814. Januar 1854“

--androl ☖☗ 22:05, 21. Dez. 2009 (CET)

Danke für die guten Hinweise. Das mit der Partei ist behoben. Für den merkwürdig formatierten Zeitraum habe ich eine neue Regel erstellt. Leerzeilen zwischen Vorlagen möchte ich nicht pauschal entfernen, da das je nach Vorlage auch erwünscht sein kann. Die Abkürzung „ca.“ pauschal in „etwa“ umzuwandeln, kam mir erst etwas seltsam vor, aber ich denke du hast Recht. Was sagt der Duden dazu? --TMg 22:55, 21. Dez. 2009 (CET)

Duden kann ich mal nachschauen...

bei Eduard Herzog passiert folgendes: da wird in der Folgenleiste in |ZEIT=[[1875]]-[[1924]] das zweite Jahr entlinkt, das erste nicht. Nach welchem Kriterium gehst du da vor?

außerdem sollten in Überschriften grundsätzlich keine  s rein, sonst funktionieren die Abschnittslinks nicht mehr. In den Links schaden sie dagegen nicht, stören aber im Quelltext, siehe Spielwiese

und in Dateinamen bitte keine Bindestriche ersetzen (auch auf Galeriesyntax ohne Linkklammern achten), stattdessen könnten Unterstriche durch Leerzeichen ersetzt werden. --androl ☖☗ 16:15, 22. Dez. 2009 (CET)

Wieder viele gute Hinweise, aber leider schwer umzusetzen. Das sind kontextsensitive Regeln, die allein mit regulären Ausdrücken nicht realisierbar sind. Dazu brauche ich etwas Zeit. Zu den Jahreszahlen: Der Link wird entfernt, wenn er weiter oben im Text schon einmal vorkam. --TMg 20:27, 22. Dez. 2009 (CET)

noch ein Hinweis: wenn da steht align = "center", sollten die Anführungszeichen nicht durch „die“ ersetzt, sondern die Leerzeichen entfernt werden.

Und vielleicht etwas schwerer zu korrigieren: wenn nach einer [[Datei:einbindung.jpg|nach der Beschreibung]]ohne Zeilenumbruch Artikeltext steht, schiebt dein Script das erste Wort vor die Dateiendklammern. --androl ☖☗ 14:38, 13. Jan. 2010 (CET)

Wieder viele interessante Anwendungsfälle. Vielen Dank dafür! Ich habe versucht, für alles eine Lösung zu finden. --TMg 11:43, 14. Jan. 2010 (CET)

Hallo TMg, schau mal, was das Script in dem Artikel Tambora tut. Bei diesen "Jahreszahlen" hilft es vielleicht, den Fall auszuschließen, dass vor oder nach der Zahl ein = oder / steht. --androl ☖☗ 01:38, 1. Mär. 2010 (CET)

In Vorlagen kann |Parameter=1995-96 vorkommen, deshalb möchte ich das Gleichheitszeichen davor nicht ausschließen. Ich habe es aber dahinter ausgeschlossen. Das zweite Problem betrifft Bis-Striche in Dateinamen. Dafür sehe ich aktuell leider keine gute Lösung. --TMg 11:09, 2. Mär. 2010 (CET)

Lemmata mit Klammer

Hallo, gibt es auch die Möglichkeit einen Link auf ein Lemma mit Klammer entsprechend zu kürzen: [[Ort (Stadtteil)|Stadtteil]] → [[Ort (Stadtteil)|]] Gruß, Elvaube 14:05, 18. Jul. 2010 (CEST)

Theoretisch ja, aber würde das nicht den Wortlaut des Textes verfälschen? Nach dem Speichern wird [[Ort (Stadtteil)|Ort]] draus. Hast du ein konkretes Beispiel, wo das sinnvoll wäre? --TMg 12:46, 19. Jul. 2010 (CEST)

Ja, das habe ich. Beispielsweise in der von mir erstellten Tabelle. Gruß, Elvaube 00:49, 21. Jul. 2010 (CEST)

Tut mir leid, aber was soll dort durch was ersetzt werden? Dein obiges Beispiel scheint keinen Sinn zu ergeben. Falls du meinst, dass Oldeborg (Dorf) durch Oldeborg ersetzt werden soll, muss ich dir widersprechen. Das Anzeigen des Klammerzusatzes kann auch gewollt sein, z.B. auf Begriffsklärungsseiten, in Siehe-auch-Abschnitten etc. Das darf nicht automatisiert werden. --TMg 12:14, 21. Jul. 2010 (CEST)

Genau das meinte ich, aber wenn es nicht sinnig ist, dies zu automatisieren, dann sollte es auch nicht weiter beachtet werden. Dank trotzdem :) Gruß, Elvaube 14:52, 21. Jul. 2010 (CEST)

Was noch gut wäre

Hallo, ich habe mir gestern dein Script importiert :)

ich habe da noch ein paar vorschlaege was man noch mit einbauen koennte:

1. v.a. oder v. a. in vor allem umwandeln
2. == Belege ==, == Fußnoten ==, == Einzelbelege == o.ä. in == Einzelnachweise ==
3. Reihenfolge zu == Siehe auch ==, == Literatur ==, == Weblinks ==, == Einzelnachweise == umwandeln
4. ==Ueberschrieft== in == Ueberschrift == umwandeln

Gruss --Lofor 11:03, 20. Aug. 2010 (CEST)

1. Erledigt.
2. Nein, auf keinen Fall, weil darin keine Einigkeit herrscht und das in vielen Fachbereichen ganz bewusst anders gemacht wurde und wird.
3. Wie 2.
4. Die Leerzeichen sollten eigentlich schon eingefügt werden. Hast du ein konkretes Beispiel, wo es nicht funktioniert? --TMg 15:05, 22. Aug. 2010 (CEST)

Super. Danke. Was mir noch aufgefallen ist das Zeichen - sollte bei Dateien nicht in – umgewandelt werden, das gibt Probleme. Das mit den Leerzeichen funktioniert. Gruss --Lofor 18:11, 22. Aug. 2010 (CEST)

Das Problem mit den Gedankenstrichen innerhalb von Dateinamen ärgert mich schon länger. Jetzt hatte ich eine Idee, wie das gelöst werden könnte. Bitte testen. --TMg 19:51, 22. Aug. 2010 (CEST)

Klappt leider noch nicht bei Gera. mfg --Lofor 19:58, 22. Aug. 2010 (CEST)

Hast du alles neu geladen (ggf. Umschalttaste festhalten)? In Gera sehe ich jetzt nur noch ein Problem, nämlich dass in „Grundig Akademie für Wirtschaft und Technik gemeinnützige Stiftung e.V.“ ein Leerzeichen eingesetzt wird. Allerdings sind solche Lemmata den Namenskonventionen zufolge sowieso verkehrt. --TMg 23:11, 22. Aug. 2010 (CEST)

Das kann natuerlich sein, dass ich vergessen hatte den Browser neu zu laden, aber nu scheint es zu funktionieren. Super :) --Lofor 21:42, 23. Aug. 2010 (CEST)

Ideen aus den Skripten von ✓ und PerfektesChaos

Ideen und Gedanken aus den Skripten von Benutzer:✓ (läuft lokal in seinem Webbrowser) und Benutzer:PerfektesChaos/js/WikisyntaxTextMod:

1. Steuerzeichen entfernen, außer Tab und Zeilenumbruch. Kommt in der Praxis allerdings nie vor oder MediaWiki beachtet es schon.
2. Doppelte Leerzeichen in Fließtext könnte man ersetzen. Andererseits, wozu? Bringt keinen Vorteil, nur verwirrende Diffs. Genauso für Tabs. Nur Leerräume am Zeilenende entferne ich, weil diese beim Bearbeiten „unsichtbar“ sind und das Entfernen einen Vorteil bringt (verlässlicheres Navigieren im Bearbeitungsfenster).
3. Manche wünschen sich bei leeren Vorlagenparametern die Beibehaltung des Leerzeichens nach dem Gleichheitszeichen. Sehe ich anders.
4. Nach *, # und : am Zeilenanfang (beliebig viele) immer ein Leerzeichen einfügen. Wichtig: Ausschließlich im Artikelnamensraum. Ausnahmefälle (innerhalb von <nowiki> etc.) sind sehr problematisch.
5. Beim Zeilentrenner |--- in Tabellen mehrfache Striche kürzen (Beispiel). Scheint mir aber streitwürdig.
6. Angeblich ist thumb|right bei Bildern in Tabellen wichtig. Kann ich aber nicht nachvollziehen.
7. Weblinks mit doppelten eckigen Klammern und/oder senkrechtem Strich reparieren ([a], [1], [[2]]).
8. Weblinks auf Wikipedia (und Schwesterprojekte) in Wikilinks umwandeln.
9. |Links mit mehrfachen senkrechten Strichen reparieren. Ist andererseits offensichtlich, dafür braucht man kein Skript.
10. Unterstriche aus Links entfernen und Anker dekodieren (#.C3.A4 → #ä, #.C3.B6 → #ö usw.).
11. Fett dort entfernen, wo es sowieso schon fett ist (Überschriften, Definitionslisten, Tabellenköpfe).
12. Standardvorlagen Commons/Commonscat, Wikisource und Wiktionary normalisieren. Commons + Cat = Commonscat.
13. Vorlage:Siehe auch einsetzen.
14. Mehrfache class- und style-Attribute zusammen fassen.
15. Bei Attributen Anführungzeichen einsetzen, ggf. auch Hochkommas durch Anführungzeichen ersetzen.
16. CSS-Zahlenwerte mit fehlendem px erkennen.
17. Das Ersetzen von HTML-Attributen (bgcolor etc.) durch CSS-Stile wird es bei mir nicht geben, da mir die Vorteile (moderner, einheitlicher) die Nachteile (länger, komplizierter, unübersichtliche Diffs, außerdem Geschmackssache und funktional identisch) nicht aufwiegen.
18. HTML-Entitäten durch Zeichen ersetzen. Sehr aufwendig, je nachdem, wie weit man das treibt. Achtung, es gibt gewollte Ausnahmen wie &tl;, senkrechte Striche, eckige Klammern etc.
19. XML-Tags auf Paarigkeit zu prüfen ist schrecklich aufwendig und fehleranfällig (<nowiki>!). Solche Fehler sieht man meist in der Vorschau.

Sehr viele dieser Ideen haben das <nowiki>-Problem. --TMg 03:06, 11. Sep. 2010 (CEST)

Zu 10.: Anker (fragment identifier) in Wikilinks sollten möglichst nicht kodiert eingegeben werden, weil MediaWiki intern automatisch analog zur Parserfunktion anchorencode kodiert ([[#äöüß]] ergibt <a href="#.C3.A4.C3.B6.C3.BC.C3.9F">#äöüß</a>). Die Anker unkodiert einzugeben, hat den Vorteil, dass sie sich automatisch anpassen, sobald rev:70526 live geht. Die Kodierung von Leerzeichen als Unterstrich ist dagegen unproblematisch, weil Leerzeichen auch in HTML5 nicht zulässig sind und weiter als Unterstriche kodiert werden.

Zu 17.: Ganz so funktional identisch sind die alten HTML-Attribute und das style-Attribut nicht: Die alten Attribute haben die niedrigstmögliche Spezifität (0,0,0,0) und werden von jeder CSS-Regel geschlagen, das style-Attribut hat die höchstmögliche Spezifität (1,0,0,0) und schlägt jede CSS-Regel außer !important. In HTML5, das in Zukunft genutzt werden wird, sind die alten Attribute nicht mehr erlaubt. In Browsern werden sie natürlich weiter funktionieren, aber Validierungsfehler verursachen.

Zu 19.: Fände ich persönlich eher lästig, weil wir kein XML schreiben (wir schreiben Wikitext, der auch HTML- oder XHTML-ähnliche Tags enthält, aber in jedem Fall von MediaWiki verarbeitet wird, und zwar derzeit noch zu unechtem XHTML 1.0, aber demnächst zu HTML5). In HTML 4.01 ist <br /> übrigens unzulässig und funktioniert nur, weil die Browser fehlertolerant sind. In HTML5 wurde der Slash wegen seiner Beliebtheit erlaubt, hat aber auch weiterhin keinerlei Wirkung (das br-Element ist nicht wegen des Slashs geschlossen, sondern weil es einfach kein End-Tag hat); er ist ein sogenannter „Talisman“.

Gruß --Entlinkt 05:07, 28. Sep. 2010 (CEST)

Danke für die Gedanken. Die Punkte 17 und 19 werde ich wie oben schon angedeutet vermutlich nie im Rahmen dieses Skriptes hier umsetzen. Das muss manuell geschehen (z.B. sind align und text-align abgesehen von ihrer Spezifität auch funktional nicht identisch).

Der wichtigste Vorteil der Vereinheitlichung von <br /> ist für mich, dass diese tendenziell unerwünschten Tags dann eher auffallen.

Bei den Ankern hast du mich vielleicht falsch verstanden, dein Hinweis ist so oder so aber sehr nützlich. Den Implementierungsaufwand für die Dekodierung habe ich bisher gescheut, weil mir Ankerlinks in der Praxis nur selten begegnen. Vielleicht lohnt es sich aber doch. --TMg 17:23, 28. Sep. 2010 (CEST)

Zu 10.: Meintest du nur Unterstriche, also den Fall [[#a_b_c]] → [[#a b c]]? Beides tritt nicht übermäßig häufig auf, hat aber dieselbe Ursache (Kopieren aus der Adressleiste des Browsers statt aus der Artikel- bzw. Abschnittsüberschrift).

Zu 17.: Wahrscheinlich lohnt es sich nicht, die Ersetzung zu automatisieren, weil sie stark kontextabhängig ist (Ergänzung deines Beispiels: align="center" wäre je nach Kontext durch style="text-align:center" oder style="margin:auto" zu ersetzen, align="right" aber durch style="float:right") und man auch auf GIGO achten müsste (<div bgcolor="red"> ist bedeutungslos, darf aber nicht blind durch <div style="background-color:red"> ersetzt werden, weil letzteres bedeutungsvoll ist).

Zu 19.: <br>, <br/> und <br /> sind für MediaWiki dasselbe; MediaWiki macht daraus, was die Einstellungen sagen (wenn $wgHtml5 = true und $wgWellFormedXml = false, dann <br>, sonst <br />). Ich persönlich würde, wenn schon vereinheitlicht wird, <br> bevorzugen, damit niemand auf die Idee kommt, man könne mit <div /> ein leeres div-Element erzeugen (funktioniert, aber nur, weil MediaWiki an dieser Stelle meiner Meinung nach zu fehlertolerant ist; ein Browser würde das nicht akzeptieren) und auch, weil es in HTML die kanonische Form ist. Einen Konsens für die eine oder andere Form sehe ich nicht (unter anderem deshalb erlaubt HTML5 beides).

Gruß --Entlinkt 22:32, 28. Sep. 2010 (CEST)

Kopierte Anker sind selten, aber unverhältnismäßig umständlich zu korrigieren. Deshalb und weil es deutlich einfacher zu implementieren war, als gedacht, ist die Dekodierung jetzt drin. (Mit einer bösen Schwachstelle, #5.25 und #5% ergeben nämlich beide die selbe Kodierung, die Sache ist also nicht ein-eindeutig; aber das ignoriere ich vorerst.) Beim <br /> würde ich aus dem genannten Grund (leichteres Erkennen im Quelltext) gern bleiben. --TMg 11:27, 29. Sep. 2010 (CEST)

zu 5) Das ist unnötig lang und ich habe noch keinen Streit um die Langform gesehen. Sollte also problemlos machbar sein

zu 14) Da gibt es viele Varianten: class=Klasse, class="Klasse", class='Klasse', würde aber sinnvoll sein.

zu 18) Benutzer:PDD/convertEntities.js

zu 19) Das erkennen von Tag-Paarigkeit ist nich so schwierig. Das Korrigieren schon eher. Da man sich alle Tags anschaut, kann man auch nowikis entsprechend erkennen.

Der Umherirrende 21:23, 1. Okt. 2010 (CEST)

Auch dir Danke. Ich bin allerdings sehr vorsichtig geworden, Dinge zu korrigieren, die außer etwas hübscheren Quelltext zu erzeugen nicht viel bringen. Ich möchte nicht, dass in Diskussionen um Leerzeichen mehr Zeit verloren geht als die, die durch mein Skript eingespart wurde. Das betrifft vor allem alles rund um (X)HTML- und CSS-Syntax: Wer es nicht lesen kann, dem hilft auch eine hübschere Syntax nicht viel. Was ich aktuell vorhabe, habe ich oben zusammen gefasst. Viele der hier angedeuteten Punkte sind vor allem deshalb nicht dabei, weil sie mir in der Praxis nie begegnet sind. Gegenbeispiele (Permanentlinks) sind deshalb sehr willkommen. --TMg 02:05, 5. Okt. 2010 (CEST)

Revision:

• Steuerzeichen entferne ich inzwischen.
• Weblink-Säuberungen sind inzwischen deutlich umfangreicher geworden.
• Unterstriche in Wikilinks werden aber immer noch nicht ersetzt.
• Überflüssige Fettungen zu entfernen, scheint mir immer noch eine gute Idee, aber auch fehleranfällig und mit entsprechendem Aufwand verbunden.
• Die Säuberung von Standardvorlagen habe ich kontinuierlich ausgebaut.
• Wenn ich mir Vorlage Diskussion:Siehe auch ansehe, lasse ich lieber die Finger davon.
• Die CSS- und HTML-Ideen hier sind zu unkonkret. Siehe dazu auch Wikipedia:WikiProjekt HTML5.

--TMg 16:11, 7. Dez. 2012 (CET)

Ich bekomm’s auch nicht hin

Ich habe die Zeile in monobook.js eingefügt, Browser-Cache geleert und Strg + F5...aber ich kann ebenfalls den Button nicht finden. Gruß --Se90 17:13, 12. Nov. 2010 (CET)

Wenn du das neue Vector-Skin verwendest, muss es die vector.js sein. Die Funktion findest jetzt (neu) in der Symbolleiste über dem Bearbeitungsfenster. --TMg 03:58, 13. Nov. 2010 (CET)

Es funktioniert! Vielen Dank für Deine Hilfe. Tolle Sache, großartig! Aber nicht gerade für diese Seite hier geeignet:-) Gruß--Se90 14:31, 13. Nov. 2010 (CET)

Ein Hinweis noch zu Literaturangaben: Bei Sammelwerken wird bei mehr als zwei Verfassern „(Hrsg.)“ mit „u.a.“ abgekürzt, also „und andere“. Auch das wird geändert in „unter anderem“. (siehe et al.) Gruß--Se90 14:58, 17. Nov. 2010 (CET)

upright

Der Befehl upright für Dateien ist mittlerweile zu hochkant eingedeutscht worden. Vielleicht kann man das analog zu thumb/miniatur mit in die Liste aufnehmen. --Alex 21:53, 29. Nov. 2010 (CET)

Zu viele Änderungen

gudn tach!
das script fuehrt einige aenderungen durch, die gegen die richtlinien verstossen. ich bitte darum, dies abzuaendern. bei bedarf helfe ich dabei.

1. bitte nicht gaengige abkuerzungen wie "u.a.", "ca.", ... ersetzen (siehe WP:RS#Korrektoren, WP:WSIGA#Abkürzungen und Kurzform und zugehoerige diskussionen).
2. zudem bitte nicht ersetzungen s/thumb/miniatur/ durchfuehren (siehe WP:B und Hilfe Diskussion:Bilder/Archiv/2#thumb). zudem ist es nicht konsens, international gueltige keywords durch solche zu ersetzen, die nur in w:de funktionieren.
3. Rechtschreibfehler/-besonderheiten sollten z.b. in zitaten nicht korrigiert werden.

-- seth 19:59, 12. Dez. 2010 (CET)

Zu 2: Dann müssten ja 1. die Doku und 2. tausende von Artikeln entsprechend geändert werden. Gruß, Elvaube · Disk. · Bew. 22:30, 12. Dez. 2010 (CET)

Da der Kommentar auf meiner Diskussionsseite (und damit wohl auch durch meine Bearbeitungen) angeregt worden ist: ich kann aus den verlinkten Wikipedia-Seiten weder herauslesen, dass Abkürzungen generell nicht aufgelöst werden sollen noch das thumb nicht durch miniatur ersetzt werden soll. Als einzige Änderung sicherlich nicht sinnvoll, aber wenn man einen Artikel eh gerade bearbeitet… Wenn doch sollte das auch so eindeutig auf den entsprechenden Seiten stehen beziehungsweise vorher dort diskutiert werden. Ich halte es nicht für besonders sinnvoll hier eine Nebendiskussion aufzutun. Das wörtliche Zitate nicht geändert werden sollen, versteht sich eigentlich von selbst. Dieses Skript soll ja auch nicht blind angewendet werden. Vielleicht kann man noch was programmieren, dass Änderungen nicht in den Vorlagen " und Zitat angewendet werden. Aber wenn das zu viel Arbeit macht, würde ich weiterhin den Benutzern vertrauen. --Alex 22:42, 12. Dez. 2010 (CET)

gudn tach!

@Elvaube:

zu 2.: ich habe auch nicht gesagt, dass es konsens sei, die deutschen begriffe durch die internationalen zu ersetzen. am besten einfach gar nicht, dann nervt's auch keinen.

@Alex:

zu 1.: gemaess WP:RS sollen richtige formulierungen nicht durch nicht-richtigere formulierungen ersetzt werden. in WSIGA steht explizit, dass gaengige abkuerzungen nicht boese sind. deutlicher geht es imho kaum. einige finden abkuerzungen besser, andere deren ausgeschriebene pendants. das ominoese platz-argument hat nie jemand ernsthaft als solches ins spiel gebracht. gegen es zu argumentieren (wie hier ganz oben), ist somit sinnfrei.

zu 2.: eine der thumb-diskussionen habe ich bereits verlinkt. dort kann man u.a. nachlesen, dass "miniatur" von vielen nicht als adaequate abkuerzung akzeptiert wird.

zu 3.: ja, man sollte das mit den vorlagen einbauen.

-- seth 23:04, 12. Dez. 2010 (CET)

Mir ist wichtig, möglichst nur konsensfähige Korrekturen vorzunehmen. Die Diskussion ist deshalb ganz richtig hier. Ich möchte das aber ganz in Ruhe überdenken. Vorab nur so viel: Ich bin selbst sehr skeptisch, was das Übersetzen von Schlüsselwörtern angeht. Ich hasse es beispielsweise in der Adresszeile, da es dadurch unmöglich ist, z.B. in http://de.wikipedia.org/wiki/Spezial:Linkliste/Beispiel mal fix das de durch en auszutauschen. Im Quelltext sehe ich das etwas differenzierter. upright beispielsweise irritiert mich jedesmal. Oben rechts? Hä? --TMg 15:16, 13. Dez. 2010 (CET)

gudn tach!

ja, das s/de/en/-problem stoert mich auch schon laenger, siehe bugzilla:17667 (und offenbar war ich nicht der erste; der bug war nur ein duplicate von bugzilla:9040). bei den keywords ist es aber aehnlich. kopiert man aus dem einen wiki was ins andere, rumms, geht's nicht (ausser z.b. wenn man's vom englischen woanders hin kopiert, immerhin). kopiert man ein script oder bot-bestandteil oder eine regel des abuse filters oder oder oder von sonstwoher zu uns, rumms, geht's nicht. nun ja. die lokalisierung ist wohl leider beschlossene sache. aber die pauschale aenderung bereits funktionierenden und nicht obsoleten codes durch welchen, der nur lokal funktioniert, ist afaik nicht beschlossen. und wie man immer wieder in diskussionen feststellt, gehen die meinungen darueber auseinander. zum upright-beispiel: "thumb" ist evtl. sogar den leuten gelaeufiger als "miniatur". wenn du den diesbzgl. code nicht herausnehmen moechtest, werde ich vermutlich nichts daran aendern koennen bzw. duerfen. insofern ist das nur eine bitte.

bei den abkuerzungen allerdings ist es eine klare sache, die links habe ich genannt. gemaess WP:RS sind aenderungen schluessiger formulierungen in nicht schluessigere formulierungen mist. einige aendern aus geschmacksgruenden pauschal A->B, andere vielleicht B->A, mit ein bissl glueck begegnen sich solche user nicht und halten sich damit gegenseitig am leben; darunter leiden die histories, die leute, welche die artikel auf ihrer watchlist haben und die richtigen autoren, die genervt sind, wenn gefuehlte besserwisser ihren text aendern, ohne dass es eine verbesserung darstellt. ein beispielhafter dauervandale in dieser richtung ist user talk:lustiger_seth/84.167.*.

lange rede, kurzer sinn, die abkuerzungsersetzungen widersprechen den richtlinien. -- seth 23:09, 13. Dez. 2010 (CET)

bitte auch die ersetzungen v.a.->vor allem und ugs->umgangssprachlich entfernen. das sind gaengige abkuerzungen.

die ersetzung von /c(?:irc)?a\./ ist ebenfalls ein verstoss gegen WP:RS. die pov-begruendung („zirka“ ist schlechtes Deutsch) macht das deutlich. -- seth 10:25, 1. Jan. 2011 (CET)

Überleg mal bitte, mit was für Argumenten du hier hantierst. Du musst das Skript ja nicht benutzen, wenn du das anders siehst. --TMg 13:10, 1. Jan. 2011 (CET)

gudn tach!

die begruendung ist dieselbe, mit der dauervandalen wie der bereits genannte user talk:lustiger_seth/84.167.* gesperrt werden. pauschal-edits in dieser richtung sind gemaess WP:RS unerwuenscht. aendere bitte dahingehend das script. -- seth 00:30, 2. Jan. 2011 (CET)

gudn tach!

schau mal auf WP:Administratoren/Notizen/Archiv/2011/01#zugriff auf user-js. dort mache ich einen vorschlag zu einem kompromiss. was haeltst du davon? -- seth 12:25, 15. Jan. 2011 (CET)

danke dafuer. weiss nicht, ob's absicht war, deswegen weise ich mal darauf hin, dass du die ersetzung s/\bdaß\b/dass/gi mitgeloescht hast, vermutlich ein versehen.ok, nachdem ich die history dieser talk page genauer angeschaut habe, war es also anscheinend absicht. sorry fuer meine langsamkeit. -- seth 22:04, 17. Jan. 2011 (CET)

Das selbe Problem. Wer das Skript blind einsetzt, wird „daß“ auch in Lemmata und Zitaten ersetzen. --TMg 10:57, 18. Jan. 2011 (CET)

leerzeilen nach absätzen

==\n\n* => ==\n --Akkakk 00:05, 14. Jan. 2011 (CET)

Nein, auf keinen Fall. Ich zum Beispiel entferne diese Leerzeile nur bei Weblinks und Einzelnachweisen, bei anderen Überschriften füge ich sie im Gegenteil bewusst ein. Allgemein ist das eins von den Details, bei denen man die Arbeit der vorangegangenen Autoren respektieren sollte. --TMg 09:52, 14. Jan. 2011 (CET)

Viertelgeviertstrich nicht in <math> ersetzen

Hallo, kannst bitte bei der Verwendung von <math> die Umstellung von - auf – ausschliessen, sonst funktioniert die Formel nicht mehr. Beispiel: Lichtbogen. Danke --Lofor 13:42, 15. Jan. 2011 (CET)

Bei den Interwikilinks gibt es das gleiche Problem. Gruss --Lofor 18:11, 15. Jan. 2011 (CET)

Das ist schwer (wieder eine kontextabhängige Ausnahme), aber ich versuche es. Danke für die Meldung. --TMg 20:01, 15. Jan. 2011 (CET)

weblinks sind davon auch betroffen --Akkakk 20:50, 15. Jan. 2011 (CET)

gudn tach!

wenn du keinen richtigen parser schreiben moechtest, kannst du dir evtl. mit split (und join) aushelfen; also etwa (grob skizziert)

arr = t.split(/(<math>.+?<\/math>|\[\[.+?\]\])/);

for(i=0;i<arr.length;i+=2) arr[i].replace(...);

t = arr.join("");

aber auch das kann natuerlich in einigen faellen schief gehen. langfristig wird's wohl nicht ohne parser gehen. -- seth 00:10, 16. Jan. 2011 (CET)

Netter Kniff, danke. Mit einem Parser will ich gar nicht erst anfangen, weil das in letzter Konsequenz bedeuten würde, die MediaWiki-Software in JavaScript nachzuprogrammieren. --TMg 12:58, 17. Jan. 2011 (CET)

in interwiki-links ersetzt das script " - " durch " – ". (z.b. in Kosovo) kannst du da was machen? --Akkakk 15:15, 9. Mär. 2011 (CET)

Das ist wirklich schwer. Das erinnert mich an den Fall mit dem „e.V.“ im Lemma. Die Frage ist, sollte man Links wirklich anders behandeln? Oder ist es nicht gerade sinnvoll, solche Fehler auch in Links zu korrigieren? Das „e.V.“ ohne Leerzeichen war falsch (von den Namenskonventionen mal abgesehen). Ein Bindestrich in Knight Rider - K.I.T.T. in Gefahr! ist falsch. Andererseits führen Änderungen an Links meist dazu, dass sie nicht mehr funktionieren. Vielleicht sollte ich nur Interwikilinks aus den Ersetzungen ausklammern? Und natürlich math-Bereiche. --TMg 19:58, 11. Mär. 2011 (CET)

Hallo TMg, Vielleicht wäre es besser, wenn dein Skript in einer <math>-Umgebung keine durch Leerzeichen abgetrennte „-“ durch Viertelgeviertstriche Halbgeviertstriche ersetzt. Dies mag die Wikipedia-Software nämlich gar nicht und spuckt einen Syntax-Fehler aus. Beispielsweise ist dies im Artikel Potential (Physik) so passiert. Dein Skript ersetzt das Minus z. B. bei <math>- 5</math>, aber nicht <math>-5</math>. Viele Grüße, --ThE cRaCkEr 13:04, 23. Jun. 2011 (CEST)

Danke für die Erinnerung. Ich hab das immer vor mir her geschoben, dank dir hatte ich aber eben eine furchtbar simple Idee. Die Striche werden jetzt nicht mehr angetastet, wenn davor oder dahinter Zahlen oder Sonderzeichen stehen. Dein Potential (Physik) bleibt jetzt sauber, aber das oben genannte <math>T - e</math> wird natürlich noch ersetzt. Um die schon diskutierte Ausklammerung von math-Ausdrücken (und anderes, etwa nowiki, source und pre sowie evtl. Zitatvorlagen) werde ich nicht herum kommen. --TMg 19:17, 24. Jun. 2011 (CEST)

Wikipedia:Datumskonventionen#Verlinkungen

verlinkte daten und jahreszahlen kommen oft vor. da lässt sich bestimmt was machen. --Akkakk 17:56, 24. Jan. 2011 (CET)

Was schlägst du vor? --TMg 19:29, 24. Jan. 2011 (CET)

daten (4. März) und jahreszahlen (2004) zu entlinken, es sei denn sie sind vor der ersten überschrift. oder wolltest du reguläre ausdrücke hören? --Akkakk 19:37, 24. Jan. 2011 (CET)

Jahreszahlen werden bereits entlinkt, wenn mehrere identische aufeinander folgen. Dein Vorschlag leuchtet mir ein, aber er erscheint mir auch gefährlich. Was ist, wenn in einem Biografieartikel bewusst weitere Daten verlinkt sind, die bedeutsam für die Person sind? --TMg 19:54, 24. Jan. 2011 (CET)

dann ist das natürlich schlecht und man muss händisch nachhelfen wie bei einigen anderen falschen ersetzungen des scripts. glaub aber nicht, dass das oft vorkommt. --Akkakk 20:07, 24. Jan. 2011 (CET)

/* jahreszahlen & daten entlinken, ausser im nullten abschnitt */
p = t.indexOf("\n=");
if (p > 0)
{
  t1 = t.substr(0, p);
  t = t.substr(p);
  t = t.replace(/\[\[([12][0-9]{3})\]\]/g, "$1");
  t = t.replace(/\[\[([123]?[0-9]\. (Januar|Jänner|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November))\]\]/g, "$1");
  t = t1 + t;
}

zum testen ruhig einfach mal die kopie Benutzer:Akkakk/TMg-autoFormatter.js einbinden--Akkakk 12:36, 1. Feb. 2011 (CET)

Hallo zusammen, falsch formatierte Datumsangaben werden bisweilen manuell umgestellt. Das klappt eigentlich ganz gut, da es immer motivierte Mitarbeiter gibt, die diese Liste abarbeiten. Per Dump wird die Liste einmal wöchentlich aktualisiert. Gruß, Elvaube Disk 13:17, 1. Feb. 2011 (CET)

das sind aber nicht die fälle um die es hier geht --Akkakk 13:27, 1. Feb. 2011 (CET)

@Akkakk: Ich hab den Quelltext mal leicht optimiert. Mein Hauptproblem bleibt leider: Ist es wirklich konsensfähig, in pauschal allen Artikeln pauschal alle Daten und Jahreszahlen (außer in der Einleitung) zu entlinken? @Elvaube: Mein Skript realisiert genau diese Automatik, allerdings nur für die verbreitete Form TT.MM.JJJJ mit 4-stelligem Jahr. Aber danke für den Hinweis, ich werde mir vor allem die Ausnahmen dort in Ruhe ansehen. --TMg 13:56, 1. Feb. 2011 (CET)

Es gibt teil weise auch solche Verlinkungen: JJJJ.MM.TT, die ebenfalls angemeckert werden. Das passiert, wenn man in den Vorlagen cite web oder Literatur die Variablen date oder accessdate zwar vorlagenkonform, dann aber fälschlicherweise ausfüllt. Gruß, Elvaube Disk 21:55, 1. Feb. 2011 (CET)

Und was schlägst du vor? Solche Fehler müssen eigentlich die Vorlagen erkennen und melden. Eine halbautomatische Korrektur durch ein Skript wie dieses hier ergibt meiner Meinung nach nur Sinn, wenn der Fall eindeutig genug ist und häufig genug vorkommt. Bei der ganz unüblichen Schreibweise „2009.12.31“ sehe ich das nicht. --TMg 18:32, 2. Feb. 2011 (CET)

Dann sollte beispielsweise {{cite web|…|date=[[2011-02-02]]|accessdate=[[2011-02-02]] erkannt werden. Das Datum darf an der Stelle nicht verlinkt werden. Gruß, Elvaube Disk 20:23, 2. Feb. 2011 (CET)

Ich habe eingebaut, dass Links auf ISO-Daten (also JJJJ-MM-TT) entlinkt werden, denn solche Artikel gibt es gar nicht. Hilft das? --TMg 17:49, 3. Feb. 2011 (CET)

Falsche Ersetzung in Vorlage:Charts

in der vorlage werden daten der form tt.mm.jjjj verwendet die nicht ersetzt werden sollen. siehe Vorlage:Infobox_Chartplatzierungen#Chartdaten --Akkakk 11:45, 2. Feb. 2011 (CET)

So? --TMg 12:42, 2. Feb. 2011 (CET)

sieht doch gut aus--Akkakk 13:12, 2. Feb. 2011 (CET)

Invalid range in character class

firefox sagt dazu: invalid range in character class. nachvollziehbar. das "-" muss am anfang stehen, hinter dem "^". diff--Akkakk 14:50, 3. Feb. 2011 (CET)

Das war mein Fehler, ich hatte es nicht getestet. Die Folgefehler sollten jetzt alle wieder verschwunden sein. Danke für die zahlreichen Meldungen dazu. Ich habe sie gleich archiviert, weil sie außer mir niemandem nützen. --TMg 17:49, 3. Feb. 2011 (CET)

Wikipedia Diskussion:Umfragen/Syntax-Bot

Neue Ideen, auf die ich per Wikipedia:Umfragen/Syntax-Bot aufmerksam geworden bin.

1. Für die Schreibweise „0197 n. Chr.“ mit führender Null konnte ich keine Richtlinie entdecken.
2. Mehrfache Leerzeichen entferne ich bewusst nicht, da es fast keinen Nutzen bringt, den Versionsvergleich aber unübersichtlich macht.
3. Leerzeichen vor <ref>…</ref> entferne ich noch nicht. Ich bin mir noch immer unsicher, ob es gut ist, das allen aufzuzwingen. Restlos einig ist man sich da nicht.
4. HTML (z. B. <b>) behandle ich nicht, da das viel zu selten vorkommt und zu viel versehentlich kaputt gehen kann (etwa in Artikeln, in denen es um HTML geht).
5. Die Erkennung defekter Anker (passiert häufig, wenn Überschriften geändert werden) ist eine schöne Aufgabe für ein Werkzeug wie Check Wikipedia. Wie könnte mein Skript dabei helfen? Gelöscht werden dürfen die Anker keinesfalls. Warnmeldungen möchte ich nicht anzeigen, das passt nicht in mein Konzept.
6. Über die korrekte Verschachtelung von Überschriften wird diskutiert, seit HTML existiert. So etwas darf kein Bot oder Skript automatisch verschlimmbessern. Check Wikipedia hilft beim Finden, ändern muss es ein Mensch mit Vernunft.
7. Sollte man falsch platzierte Kategorien und Interlanguage-Links nach unten schieben? Oder hat nur jemand einen Doppelpunkt vergessen? Kann ein Bot oder Skript das unterscheiden?
8. „Weblinks“ vor „Einzelnachweise“? Ich fände es gut, wenn man sich da einig wäre, aber das ist leider nicht der Fall.
9. Weblinks auf Schwesterprojekte und Sprachversionen in Wikilinks umwandeln (z. B. [[:en:Link]]). Damit habe ich schon begonnen, muss es nur mal zu Ende programmieren.
10. Man könnte Sortierschlüssel automatisch setzen und korrigieren. Meine Beobachtung ist aber, dass es sehr viele Benutzer gibt, die sich bereits darum kümmern, und die Regeln auch sehr kompliziert sind. Ich befürchte deshalb, dass eine halbherzige Skript-Umsetzung mehr schadet als nützt.
11. Automatische Korrekturen an Listen sind mir zu fehleranfällig. # etwa leitet auch Kommentare innerhalb von <source> ein. Für den geringen Nutzen ist mir die Gefahr zu hoch. Echte Fehler wie durch Leerzeilen zerrissene Listen sind leicht zu sehen und schnell von Hand korrigiert.

--TMg 14:35, 9. Mär. 2011 (CET)

Da ich aus irgendeinem Grund die Seite noch auf meiner Beo habe, weise ich dich für Punkt 10 auf Benutzer:Schnark/js/personendaten.js hin (Suche nach replace_special). Damit wirst du immerhin Sonderzeichen im Sortierschlüssel los, ohne das Rad neu erfinden zu müssen. --Schnark 09:19, 10. Mär. 2011 (CET)

wenn du noch "ñ" und "Ñ" dazunehmen könntest --Akkakk 23:24, 10. Mär. 2011 (CET)

Klar. Ich würde die Liste gern noch viel mehr erweitern, habe aber leider nirgends (außer in Benutzer:Schnark/js/personendaten.js) eine verbindliche Ersetzungstabelle gefunden. --TMg 23:53, 10. Mär. 2011 (CET)

Revision:

• Bei „0197 n. Chr.“ war wohl gemeint, die Nullen zu entfernen. Scheint konsensfähig.

--TMg 16:02, 19. Dez. 2012 (CET)

ISBN

Bist du dir bewusst, dass die korrekte Gliederung einer ISBN wesentlich komplizierter ist als (3)-1-5-3-1? Die Gruppennummer, der du nur eine Ziffer zugestehst, kann bis zu 5 Stellen haben, die Verlagsnummer, die du auf 5 Stellen festlegst, schwankt im deutschsprachigen Raum zwischen 2 und 7 Ziffern. --Schnark 09:24, 12. Mär. 2011 (CET)

es gibt auch http://toolserver.org/gradzeichen/IsbnCheckAndFormat --Akkakk 11:52, 12. Mär. 2011 (CET)

@Akkakk. Danke für den Tipp. @Schnark: Ich verstehe nicht. Was macht mein Skript falsch? --TMg 09:44, 13. Mär. 2011 (CET)

gudn tach!

wenn ich Schnark richtig verstehe, macht dein script keine falschen aenderungen, aber zu wenige. statt

t = t.replace(/\bISBN(-?1[03])?:?\s*(\d{3}-)?(\d)-?(\d{5})-?(\d{3})-?(\d)\b/g, "ISBN $2$3-$4-$5-$6");

sollte es, wenn ich ihn richtig verstehe, besser

t = t.replace(/\bISBN(-?1[03])?:?\s*(\d{3}-)?(\d{1,5})-?(\d{2,7})-?(\d{3})-?(\d)\b/g, "ISBN $2$3-$4-$5-$6");

heissen. -- seth 11:36, 13. Mär. 2011 (CET)

Das würde eine ISBN-10 als 386-6-80-192-9 formatieren. Eben weil das nicht so einfach ist, wollte ich die erste Version meiner Ersetzungsregel erst einmal auf einen gängigen Fall beschränkt. Leider scheint es einen solchen Fall, wie ich ihn mir vorstellte, gar nicht zu geben (978-3-86680-192-9 vs. 978-3-7657-2780-1). --TMg 15:58, 13. Mär. 2011 (CET)

aeh, ja, so geht's natuerlich nicht. war ich zu eilig, sorry. da du die bindestriche ja als optional ansiehst, muesste man was wesentlich umfangreicheres basteln, dass nicht beliebige ziffern, sondern nur die kontextabhaengig erlaubten matcht.

wenn ich ISBN richtig verstehe, sollte es aber dennoch moeglich sein, einige isbns zu parsen, beispielhaft in perl fuer gruppe 3, ohne die sonderfaelle:

s/\bISBN(?:-?1[03])?:?\s*(978|)[- ]?3[- ]?(0[5-9]|1\d)[- ]?(\d{6})[- ]?(\d)\b/ISBN 978-3-$2-$3-$4/g;

s/\bISBN(?:-?1[03])?:?\s*(978|)[- ]?3[- ]?(3[2-9]\d|[4-6]\d\d)[- ]?(\d{5})[- ]?(\d)\b/ISBN 978-3-$2-$3-$4/g;

s/\bISBN(?:-?1[03])?:?\s*(978|)[- ]?3[- ]?(7[3-9]\d\d|8[0-4]\d\d)[- ]?(\d{4})[- ]?(\d)\b/ISBN 978-3-$2-$3-$4/g;

s/\bISBN(?:-?1[03])?:?\s*(978|)[- ]?3[- ]?(8[5-9]\d{3})[- ]?(\d{3})[- ]?(\d)\b/ISBN 978-3-$2-$3-$4/g;

s/\bISBN(?:-?1[03])?:?\s*(978|)[- ]?3[- ]?(9[1-4]\d{4})[- ]?(\d\d)[- ]?(\d)\b/ISBN 978-3-$2-$3-$4/g;

s/\bISBN(?:-?1[03])?:?\s*(978|)[- ]?3[- ]?(9[78]\d{5})[- ]?(\d)[- ]?(\d)\b/ISBN 978-3-$2-$3-$4/g;

fuer die gruppen 0 und 1 gibt's ja auch noch leicht auffindbare regeln. das werden dann allerdings insg. recht viele aufrufe.

es wuerde die ganze sache beschleunigen, wenn man nur einen (und zwar einen simplen) primaeren replace-aufruf fuer den kram verwendet und ihn dann in einer callback-funktion separat betrachtet, also etwa so:

replace(/\bISBN[0-9 -:]{1,25}/g, function isbn_tidy(needle){ /* hier die vielen regexp-ersetzungen einbauen, und ersetzten string zurueckgeben */});

-- seth 17:00, 13. Mär. 2011 (CET)

Damit ich auch noch eine Herausforderung habe ;-) werden jetzt auch falsch gesetzte Striche erkannt und neu gesetzt. Mir war bisher nicht bewusst, dass die Gruppierung tatsächlich vom Land abhängig ist. Mein Skript funktioniert deshalb vorerst nur für deutschsprachige Bücher. Noch eine Einschränkung: Ich akzeptiere vorerst keine Leerzeichen als Trennzeichen, da mir das zu fehleranfällig scheint. Falls dieses Feature gewünscht wird, bitte melden. --TMg 14:34, 14. Mär. 2011 (CET)

irgendwas ist da noch defekt: aus ISBN 3-7709-0558-X wird ISBN 3-7709-0558--X Jürgen Neven-du Mont --Akkakk 17:08, 17. Mär. 2011 (CET)

Vielen Dank für den Hinweis. Ich habe mich immer gefragt, was das X am Ende von ISBNs soll. Als ob jemand zu faul war, die Prüfsumme auszurechnen. ;-) Aber es steht für die Prüfsumme 10. Ich habe die Formatierungsfunktion entsprechend erweitert. --TMg 17:44, 17. Mär. 2011 (CET)

Veränderung der Dateinamen

Wenn man den Formatter verwendet werden auch die Dateinamen geändert. Es werden zum Beispiel die "_" rausgenommen. Kann man da einen BugFix machen?--Pauli94 15:38, 12. Mär. 2011 (CET)

dass die "_" durch leerzeichen ersetzt werden ist kein bug, sondern ein feature. unterstriche sind in lemmata ein platzhalter für leerzeichen. --Akkakk 18:56, 12. Mär. 2011 (CET)

Schon klar. Ich möchte damit nur fragen, ob man die Überprüfung von Dateinamen stoppen kann. Die sollen nicht geändert werden. Sonst wird das Bild ja nimma gefunden ;-) --Pauli94 00:39, 13. Mär. 2011 (CET)

doch, wenn lediglich "_" durch " " ersetzt werden eben schon. funktioniert genau so gut wie --Akkakk 00:54, 13. Mär. 2011 (CET)

@Pauli94: Die Unterstriche sind kein feststehender Bestandteil des Dateinamens sondern ein technisches Hilfsmittel, ähnlich wie die %20 in Webadressen. Wenn dir ein Fall begegnet ist, in dem ein Bild nicht mehr gefunden wird, dann ist das natürlich ein Fehler. Dann brauche ich den Artikelnamen, um das nachvollziehen und reparieren zu können. --TMg 09:42, 13. Mär. 2011 (CET)

Dokumentation zur Maßeinheit %

also ich will ja nichts sagen, aber den quellcode sagt:

	/* Maßeinheiten immer mit Leerzeichen */
	t = t.replace(/\b([0-9]+)( | )?([mck]?m|kg|[KMG]iB|[kMG](B|Hz)|KB)\b/g, "$1 $3");
	/* Prozentwerte erhalten seit Mitte 2007 automatisch ein geschütztes Leerzeichen */
	t = t.replace(/\b([0-9]+)( | )?(%[^a-z0-9"%;])/g, "$1 $3");

also was anderes als die doku--Akkakk 17:39, 17. Mär. 2011 (CET)

Tut mir leid, ich verstehe das Problem nicht. Das Skript sorgt für eine einheitliche Formatierung von Maßeinheiten. Alle werden mit einem Leerraum von ihrer Zahl abgesetzt. Das ist ein Feature, nicht zwei. Der Sonderfall wird erwähnt und in der Referenz erklärt. --TMg 17:53, 17. Mär. 2011 (CET)

ich verstehe Akkakks anliegen hier auch nicht und vermute, dass er die beiden regexp-ersetzungen falsch interpretiert hat.

dennoch koennte man afaiks die ausdruecke noch um redundante ersetzungen kuerzen:

t = t.replace(/\b([0-9]+) ?([mck]?m|kg|[KMG]iB|[kMG](B|Hz)|KB)\b/g, "$1 $2");

t = t.replace(/\b([0-9]+)(?: |)(%[^a-z0-9"%;])/g, "$1 $2");

und falls js auch mit zero-width negative look-ahead assertions umgehen kann, koennte man die zweite substitution auch damit verzieren:

t = t.replace(/\b([0-9]+)(?: |)%(?![a-z0-9"%;])/g, "$1 %");

das verlangt nicht die existenz eines zeichens hinter dem prozent-zeichen. -- seth 22:56, 17. Mär. 2011 (CET)

Danke. Ein Stück vereinfachen lässt sich das offenbar. Die Klammeroptionen (Lookahead etc.) vermeide ich bewusst, da „manche“ Webbrowser das gar nicht oder nicht korrekt verarbeiten. Die Prüfung des Zeichens hinter % ist u. a. für kodierte URIs wichtig (a%20%21b). --TMg 10:38, 18. Mär. 2011 (CET)

Eckige Klammer wird zu Unrecht entfernt

Hallo TMg,

Dein Skript entfernt beim Anwenden auf Bayerische Staatskanzlei einfach eine eckige Klammer bei einem Wiki-Link. Genau:

[[Kategorie:Staatsministerium (Bayern)|Staatskanzlei]]

wird zu

[[Kategorie:Staatsministerium (Bayern)|Staatskanzlei]

Viele Grüße, --ThE cRaCkEr 23:04, 19. Mär. 2011 (CET)

nehme mal an das kam von:

 /* Doppelte eckige Klammern um Weblinks entfernen */
 t = t.replace(/\[+\s*(https?:\/\/[^\]]*?)\s*\]+/gi, "[$1]");

und diesem fehlerchen: diff --Akkakk 12:40, 20. Mär. 2011 (CET)

gudn tach!

um externe links zu matchen, empfehle ich, den wikitext-parser zu imitieren. der nutzt hinter dem protokoll (z.b. "http://") das pattern /[^\][<>"\x00-\x20\x7F]+/ . -- seth 13:27, 20. Mär. 2011 (CET)

Danke euch allen. Genau solche Meldungen brauche ich, um das Skript besser zu machen. Mein Fehler war, dass ich Links auch bearbeitet habe, wenn sie im Quelltext über mehrere Zeilen reichten. Für die MediaWiki-Software sind das aber gar keine Links ([[Test 1]], [http://example.com Test 2]). Solche Fälle bleiben jetzt unangetastet. --TMg 17:51, 20. Mär. 2011 (CET)

Problem mit Infoboxen

Hallo TMg, seit kurzen beobachte ich bei dem Script, dass es bei Infoboxen die erste Zeile mit dem "Namen" entfernt. mfg --Lofor 09:45, 22. Apr. 2011 (CEST)

Das ist Absicht. Das Skript entfernt unnötige Wiederholungen aus denjenigen Infoboxen, die in der Lage sind, das Lemma des Artikels anzuzeigen. Das vermeidet Redundanzen und reduziert damit mögliche Fehlerquellen. --TMg 21:46, 23. Apr. 2011 (CEST)

Alles klar, weiss ich bescheid. mfg --Lofor 18:59, 24. Apr. 2011 (CEST)

Geschützte Leerzeichen bei Rechtsverweisen

Hallo,

Ich habe gerade recht lange gebraucht, um in einem juristischen Artikel in Stellen wie „Gemäß {{§|103|stpo|juris|text=§ 103 Abs. 1 Satz 2}}“ geschütze Leerzeichen einzufügen. Dies soll man auch laut Wikipedia:Belege/Recht#geschützte Leerzeichen. Nun wäre dies doch ein perfekter Job für dein Skript. Die Regex sollte reicht einfach sein: Einfach immer § + Leerzeichen + Zahl durch § + geschütztes Leerzeichen + Zahl ersetzen, genauso bei „Abs.“ und „Satz“. Damit nicht zu viel fälschlicherweise ersetzt wird, kannst du auch schauen, ob du dich zusätzlich in {{§| }} bzw. {{§§| }}- befindest. Mehr Infos dazu auf Wikipedia:Belege/Recht. Viele Grüße, --ThE cRaCkEr 18:13, 22. Jul. 2011 (CEST)

Stimmt, das ist perfekt für eine Automatisierung. Ich habe für die Standardfälle „§ 103 Abs. 1 Satz 2“, „§ 103 Abs. 1“ und natürlich „§ 103“ Regeln eingeführt, sogar unabhängig von den Vorlagen, da ich das Paragraphenzeichen für eindeutig genug halte. --TMg 19:54, 25. Jul. 2011 (CEST)

Danke! Aber ich habe das gerade am Artikel Ruhestörung ausprobiert und dort werden sehr viele übersehen. Kannst du dir das mal ansehen? --ThE cRaCkEr 20:47, 25. Jul. 2011 (CEST)

Es macht eigentlich genau was es soll. Was konkret fehlt dir denn? Was ich bewusst nicht mache ist, ein Leerzeichen einzusetzen, wenn es fehlt, weil ich davon ausgehe, dass so etwas wie „§1“ auch Absicht sein könnte. --TMg 00:08, 26. Jul. 2011 (CEST)

Komisch, ich habe es jetzt noch einmal probiert und tatsächlich, nun macht es genau alles richtig. Als ich es gestern probiert habe, hat es nur ein nbsp eingesetzt und beim Rest normale Leerzeichen gelassen. Warum das auch immer gestern so war, jetzt funktioniert es. Perfekt! --ThE cRaCkEr 11:24, 26. Jul. 2011 (CEST)

Was jedoch nicht funktioniert sind Gesetzesverweise der Form {{§|127|StPO|juris}} Abs. 2 StPO, wie z. B. häufig im Artikel Festnahme vorkommen (bevor ich non-breaking spaces eingefügt habe, natürlich). Lohnt es sich hier, bei "Abs." + Space + Zahl ein nbsp einzufügen? Ich sehe hier gerade keine Fälle, wo dies ungewünscht wäre. Gleiches würde für "Art." und "Nr." (muss noch nicht mal im juristischen Kontext sein) gelten. -- ThE cRaCkEr 15:26, 9. Sep. 2011 (CEST)

Manche Benutzer mögen es nicht, wenn sie im Artikelquelltext hunderte   vorfinden, deswegen bin ich da lieber etwas vorsichtiger. Aber ich habe die benutzerdefinierten Ersetzungen erweitert, so dass du das Folgende in deine common.js übernehmen kannst. Das setzt z.B. in „Abs.1“ ein geschütztes Leerzeichen ein, egal ob da vorher ein Leerzeichen war oder nicht (das gilt für alle benutzerdefinierten Ersetzungen) und egal welche Zahl dahinter steht (das \\d wirkt als Platzhalter). Ich hoffe, ich habe dadurch nichts anderes kaputt gemacht. --TMg 19:03, 9. Sep. 2011 (CEST)

var autoFormatReplacements = {
    'Abs.\\d': 'Abs. \\d',
    'Art.\\d': 'Art. \\d',
    'Nr.\\d': 'Nr. \\d'
}

Hab ich kurz getestet, funktioniert gut. Danke! -- ThE cRaCkEr 10:47, 10. Sep. 2011 (CEST)

„Auch schon seit längerem erledigt, inzwischen sogar mit dem Leerzeichen optional.“ Wie ist das gemeint? --Seth Cohen 23:41, 15. Nov. 2012 (CET)

Du hattest mich später davon überzeugt, auch §1 in § 1 umzuwandeln, nicht nur § 1. --TMg 16:01, 16. Nov. 2012 (CET)

Galeriebilder

Hallo, das Script macht gerade merkwürdige Ersetzungen von Dateinamen, schau mal bei Paderborn und teste mit diesem Code:

[[Datei:blubb.jpg|Text]]

<gallery>
Datei:blubb.jpg|Text
</gallery>

--androl ☖☗ 10:42, 26. Sep. 2011 (CEST)

Autsch. Das Skript sichert alle Dateinamen, setzt statt dessen Zahlen ein und tauscht die Zahlen am Ende wieder gegen die Dateinamen aus. Hier geht aus irgend einem Grund der letzte dieser Schritte schief. Ich schaue es mir an. --TMg 23:42, 26. Sep. 2011 (CEST)

OK, ich denke es ist behoben. --TMg 01:15, 27. Sep. 2011 (CEST)

Decodierung von Abschnittslinks

Hallo TMg, das Script ersetzt in Abschnittslinks ".C2.A0" (&nbsp;) durch Leerzeichen. Leider funktioniert der Link danach nicht mehr. Hier mal ein Test:

• Benutzer Diskussion:TMg/autoFormatter.js#Decodierung.C2.A0von.C2.A0Abschnittslinks → geht
• Benutzer Diskussion:TMg/autoFormatter.js#Decodierung von Abschnittslinks → geht nicht
• Benutzer Diskussion:TMg/autoFormatter.js#Decodierung von Abschnittslinks → geht nicht

--androl ☖☗ 18:36, 5. Okt. 2011 (CEST)

Hast du ein echtes Beispiel in einem Artikel? Zur Erklärung, was das Skript aktuell macht: Geschützte Leerzeichen in Überschriften ergeben sowohl technisch als auch logisch keinen Sinn, deshalb entfernt das Skript diese sowohl aus Überschriften als auch aus Links. Die ersten zwei Links funktionieren nach dieser Reparatur, beim letzten ersetzt das Skript die   aktuell nicht. Dafür werde ich aber keine Ersetzungsregel einführen, da du diesen Link ja nur zur Demonstration erzeugt hast und so etwas in der Praxis wohl nicht vorkommt. --TMg 23:30, 5. Okt. 2011 (CEST)

Jahreszahlen

Moin TMg, wenn ich es richtig sehe wird im Moment 1901–02 zu 1901–1902 geändert. Mir fällt spontan nichts ein, warum dann nicht auch 1901/02 zu 1901/1092 geändert werden sollte. Daher: ist es möglich das auch noch in das Werkzeug einzubauen? Und generell mal herzlichen Dank für den autoFormatter. --Alex (Diskussion) 15:52, 8. Apr. 2012 (CEST)

Verspätete Antwort (irgendwie übersehen): Die Kurzschreibweise „1901/02“ gibt es sehr oft und ich halte sie für legitim. Die Bis-Schreibweise ersetze ich, weil sie missverständlich ist. „1901-02“ könnte auch für „1901–2002“ stehen oder sogar für „Februar 1901“. Die Schreibweise mit dem Schrägstrich ist weniger problematisch, sie steht immer für zwei aufeinanderfolgende Jahre. Wer das im Einzelfall trotzdem ausschreiben möchte, kann das natürlich (begründet) tun, ich denke aber nicht, dass das pauschal von einem Skript gemacht werden sollte. --TMg 14:18, 3. Aug. 2012 (CEST)

ISBN-Nummern falsch formatiert

Hallo TMg, der Autoformatter formatiert manchmal die ISBN-Nummern falsch. --Ninxit (Diskussion) 11:09, 3. Aug. 2012 (CEST)

Danke für den Hinweis. Ich hatte mich auf die Angaben im Artikel ISBN-Verlagsnummer verlassen, die Tabelle dort war aber entweder veraltet oder wurde einfach nur falsch übernommen. Ich habe jetzt sowohl den Artikel als auch mein Skript korrigiert. --TMg 14:04, 3. Aug. 2012 (CEST)

Normdatenvorlage mit ändern?

Die Normdatenvorlage hat sich ja vor einiger Zeit leicht geändert und ist in einigen Artikeln noch falsch eingebunden. Es wäre nützlich, wenn das gleich mit korrigiert würde. Dazu müsste einfach {{Normdaten|PND= durch {{Normdaten|TYP=p|GND= ersetzt werden (Details).--CENNOXX 14:54, 11. Aug. 2012 (CEST)

Entschuldige bitte, dass ich mich nicht gemeldet habe. Ist erledigt. --TMg 21:15, 2. Sep. 2012 (CEST)

Anführungszeichen

Dein Skript ersetzt englische Anführungszeichen (“ ”) durch deutsche („ “) auch im englischsprachigen Kontext. --Seth Cohen (Diskussion) 17:51, 12. Sep. 2012 (CEST)

Was hab ich mir denn dabei gedacht? ;-) Ich habs entfernt. Danke für den Hinweis. --TMg 00:25, 13. Sep. 2012 (CEST)

Na ja, prinzipiell ist die Ersetzung ja durchaus sinnvoll, nur eben nicht im englischsprachigen Kontext. --Seth Cohen (Diskussion) 16:35, 13. Sep. 2012 (CEST)

Interlanguage-Links

Das Skript ersetzt Bindestrich-Minusse in Interlanguage-Links durch Halbgeviertstriche. --Seth Cohen (Diskussion) 20:13, 13. Sep. 2012 (CEST)

Das ist leider nicht so einfach zu beheben, steht aber schon oben auf meiner Wunschliste. Trotzdem natürlich wieder vielen Dank für die Meldung. --TMg 23:02, 13. Sep. 2012 (CEST)

Ganz vergessen: Kannst du mir bitte das konkrete Beispiel nennen, bei dem dir das aufgefallen ist? --TMg 11:01, 18. Sep. 2012 (CEST)

Ersetzung und (Teil-)Revert. --Seth Cohen 17:44, 18. Sep. 2012 (CEST)

Danke. Zur Info: Das ist genau der Fall, für den ich die Interwikilinks ausklammern müsste, so wie ich das schon mit den Dateinamen mache. Auf meiner Merkliste steht das, aber aktuell mit niedriger Priorität. --TMg 22:12, 19. Sep. 2012 (CEST)

Ach so, das ist dann wohl recht aufwendig. --Seth Cohen 19:10, 21. Sep. 2012 (CEST)

Besonders im Filmbereich tritt der Fall häufig auf.--CENNOXX 18:47, 29. Nov. 2012 (CET)

Ich hatte gerade eine sehr, sehr einfache Idee: Ich suche einfach nach dem ersten Sprachlink und zerschneide den Artikel an dieser Stelle. Bestimmte problematische Ersetzungen mache ich nur noch in der oberen Hälfte. Das ist keine sichere Sache, sprich es kann dazu führen, dass ein Link weiter oben fälschlich als Sprachlink erkannt wird und ab da nichts mehr ersetzt wird. Deshalb werde ich das nur für bestimmte Ersetzungen machen, aktuell nur bei Gedankenstrichen. Ein zweiter Kandidat ist das Jahreszahlen-Bis. Kommen sonst noch Fehlersetzungen in Sprachlinks vor? --TMg 20:14, 29. Nov. 2012 (CET)

Wenn vorhanden, kann ja zumindest geprüft werden, ob der erste gefundene Sprachlink unter <references /> steht.--CENNOXX 21:52, 29. Nov. 2012 (CET)

Netter Gedanke, danke. Ganz erledigt ist das noch nicht, weil ich mindestens vom Jahreszahlen-Bis weiß, dass es fälschlich in Sprachlinks eingesetzt wird. Auch bei Anführungszeichen kam das schon vor. --TMg 02:06, 11. Dez. 2012 (CET)

Infobox Stadion

Wieso entfernt dein Skript den Parameter Name samt Wert aus der Infobox Stadion? --Seth Cohen (Diskussion) 16:32, 15. Sep. 2012 (CEST)

Siehe oben unter #Entfernung von Redundanzen aus Infoboxen. --TMg 18:54, 15. Sep. 2012 (CEST)

Danke. --Seth Cohen (Diskussion) 19:16, 15. Sep. 2012 (CEST)

Scheint mir keine gute Idee zu sein, Standardparameter zu löschen. --Seth Cohen (Diskussion) 19:42, 15. Sep. 2012 (CEST)

Inwiefern „Standard“? Der „Standard“ dieser Vorlagen ist, dass sie das Lemma des Artikels anzeigen. Die Argumentation ist relativ schlicht die, dass ein redundant ausgefüllter Vorlagenparameter nichts nützt sondern unnötig, potentiell sogar fehleranfällig ist. --TMg 02:19, 16. Sep. 2012 (CEST)

Standard insofern, als der Parameter Name in der Kopiervorlage der Vorlage Infobox Stadion enthalten ist. Aber was soll’s, ich habe die Funktion einfach abgeschaltet. --Seth Cohen (Diskussion) 16:47, 16. Sep. 2012 (CEST)

Natürlich sind die Parameter in den Kopiervorlagen enthalten, sie werden schließlich gebraucht, wenn das Lemma einen Klammerzusatz hat. Aber eben nur dann. --TMg 01:58, 17. Sep. 2012 (CEST)

In Ordnung. --Seth Cohen 17:23, 18. Sep. 2012 (CEST)

Externe Links

Dein Skript korrumpiert bestimmte externe Links. --Seth Cohen (Diskussion) 19:20, 15. Sep. 2012 (CEST)

Welchen Teil meinst du da? --TMg 02:27, 16. Sep. 2012 (CEST)

Die beiden Teile, die aus dem verlinkten Revert hervorgehen, meine ich. --Seth Cohen (Diskussion) 16:54, 16. Sep. 2012 (CEST)

Bei den beiden Links ist das mit den „2 Metern“ fragwürdig. Ich denke, dass ich das beheben kann. Der andere Link war vorher sowieso defekt. --TMg 02:03, 17. Sep. 2012 (CEST)

Inwiefern fragwürdig? Stimmt, der andere Link war korrupt; und wenn er es nicht gewesen wäre? Offenbar toleriert dein Skript keine Verkettungszeichen in Weblinks. --Seth Cohen 17:19, 18. Sep. 2012 (CEST)

„2m“ ist eine Entfernung, die erhält ein geschütztes Leerzeichen. Für den Fall wie dort habe ich das jetzt ausgeschlossen. Bei dem Strich geht mein Skript von einem versehentlich falsch geschriebenen Wikilink aus und versucht, diesen zu korrigieren, z.B. [https://de.wikipedia.org/wiki/Rick_Danko#Postum_ver.C3.B6ffentlicht|Werke]. Auch diesen Fall konnte ich dank deines Funds ein klein wenig robuster gestalten. --TMg 17:57, 18. Sep. 2012 (CEST)

Prima. Danke! --Seth Cohen 18:08, 18. Sep. 2012 (CEST)

Hexadezimale Farbdefinition

Was hältst du davon, die Kleinbuchstaben hexadezimaler Farbdefinitionen in Großbuchstaben umzuwandeln? --Seth Cohen (Diskussion) 19:25, 15. Sep. 2012 (CEST)

Was soll das bringen? Ich persönlich schreibe das auch gern groß und ändere es auch manchmal, wenn ich ohnehin an einer Vorlage arbeite. Aber zum einen gibt es Benutzer, die das anders sehen, zum anderen spielt es nicht die geringste Rolle. In Artikeln sollten solche Farbangaben sowieso möglichst nie vorkommen. Verzeih mir bitte, wenn ich darauf hinweise, aber bitte lies noch einmal, welche Ziele ich mit diesem Skript verfolge. --TMg 02:32, 16. Sep. 2012 (CEST)

Ich finde, mit Großbuchstaben lassen sich die Farbdefinitionen leichter lesen. Und auch wenn diese Art der Farbdefinitionen in Artikeln möglichst nicht vorkommen sollten, so sind mir doch ein Haufen Artikel untergekommen, wo das der Fall ist. --Seth Cohen (Diskussion) 16:57, 16. Sep. 2012 (CEST)

Das finde ich auch. Trotzdem ist es unsinnig, daran herum zu ändern. Die Nachteile sind wesentlich schwerwiegender: Es hat keinerlei Auswirkung auf die Darstellung und macht nur den Versionsvergleich unübersichtlich. Vor allem zwingt es allen Benutzern einen angeblichen Standard auf, der nirgends so definiert ist. Im Gegenteil: Teilweise ist es in der Webentwicklung üblich, CSS-Farbangaben klein zu schreiben. --TMg 02:16, 17. Sep. 2012 (CEST)

Dass der Versionsvergleich dadurch unübersichtlich wird, finde ich eigentlich nicht. Und von Standard war von meiner Seite nicht die Rede. Wie dem auch sei, meine ursprüngliche Frage hast du zusammenfassend mit „nichts“ beantwortet. ;-) --Seth Cohen 16:32, 17. Sep. 2012 (CEST)

Nein, eigentlich nicht. Wenn ich Vorlagen bearbeite, ändere ich #eeeeee gern in #EEE oder noch lieber in eine Klasse. Das erfordert Sachverstand und eben auch Zurückhaltung. Ein Skript kann das nicht. --TMg 10:28, 18. Sep. 2012 (CEST)

Lokalisierung

Ist geplant, die Lokalisierung noch weiter auszubauen, zum Beispiel die Variablen aufzunehmen, oder auch Schlüsselwörter wie Special:Mypage? --Seth Cohen 19:22, 19. Sep. 2012 (CEST)

Das kommt doch in Artikeln gar nicht vor. Die Software kommt gut mit allen Schreibweisen zurecht, da kann man den Vorlagenautoren bedenkenlos die Wahl überlassen, finde ich. Ich beispielsweise schreibe die Variablen lieber englisch, weil es kürzer und meiner Meinung nach prägnanter ist. Es ist halt Programmierung und Programmiersprachen sind nun mal englisch. Ich lasse mich aber auch gern überzeugen, also wenn du ganz konkrete Einzelfälle hast, nur her damit. --TMg 22:07, 19. Sep. 2012 (CEST)

Stimmt. Ist in Ordnung. --Seth Cohen 19:11, 21. Sep. 2012 (CEST)

includeonly in beta

Hallo TMg, wenn onlyinclude-Bereiche ausgeschlossen werden, so betrifft das auch Begriffsklärungsseiten von Personen (Vorname Nachname), die in Seiten zu Nachnamen eingebunden werden. Dein Skript hat bisher geholfen, die Lebensdaten einheitlich und typographisch korrekt zu formatieren, es wäre schade, darauf verzichten zu müssen. Viele Grüße, --Polarlys (Diskussion) 19:01, 21. Sep. 2012 (CEST)

Interessant. Das schau ich mir gern noch einmal genauer an. Du hast jetzt schon eine Möglichkeit, das zu beheben: Markiere den Text zwischen den beiden onlyinclude, bevor du den Knopf drückst. Wie du markierst, ist fast egal, wichtig ist nur, dass nicht beide onlyinclude in der Markierung enthalten sind. Dann werden sie auch nicht beachtet. --TMg 20:23, 21. Sep. 2012 (CEST)

Ich dachte, ich könnte solche Fälle anhand einer Kategorie erkennen, aber da ist gar keine. Ich habe das onlyinclude für den Moment einfach ganz aus dem Skript geworfen. Das hat lediglich den Nachteil, dass Vorlagen kaputt gehen können, aber im Vorlagennamensraum durfte man das Skript sowieso noch nie blindlings anwenden. --TMg 20:44, 21. Sep. 2012 (CEST)

Danke! --Polarlys (Diskussion) 23:47, 21. Sep. 2012 (CEST)

Galerie

Schau mal, was dein Skript hier ab Zeile 22 angestellt hat. (Ich habe es extra so abgespeichert, um es dir zeigen zu können.) Wozu werden eigentlich zusätzliche Leerzeilen eingefügt? --Seth Cohen 22:44, 22. Sep. 2012 (CEST)

Wieder vielen lieben Dank für die Meldung. Speichern wäre nicht nötig gewesen, ein Link hätte genügt. Schuld war eine Optimierung in der Betaversion. Sollte jetzt behoben sein. --TMg 18:14, 23. Sep. 2012 (CEST)

Danke dir fürs schnelle Beheben. Du hast schon recht, speichern wäre nicht nötig gewesen, das hat den Bug-Report aber erleichtert. Ich hatte ganz vergessen, darauf hinzuweisen, dass ich die Beta-Version nutze. --Seth Cohen 19:03, 23. Sep. 2012 (CEST)

Schaltfläche

Mir ist aufgefallen, dass die „Auto-Format“-Schaltfläche im Firefox nicht angezeigt wird, wenn der entsprechende Tab während des Ladens der Seite nicht fokussiert ist. Im Internet Explorer 9 wird die Schaltfläche gar nicht angezeigt. --Seth Cohen 19:38, 23. Sep. 2012 (CEST)

Ich habe es noch einmal getestet und kann es zumindest in Firefox nicht nachvollziehen. IE9 habe ich nicht. Du benutzt doch auch das Vector-Skin, richtig? Hast du Erfahrung mit Firebug und kannst einmal nachsehen, ob da Fehler auftauchen? Hat es wieder mit einer Einstellung oder einem anderen Helferlein in deiner common.js zu tun? --TMg 20:33, 24. Sep. 2012 (CEST)

Ja, ich benutze das Vector-Skin. Firebug meldet keine Fehler. Dass es an einer Einstellung oder einem anderen Helferlein liegt, glaube ich nicht – ist der Tab beim Laden der Seite fokussiert, wird das Skript samt Schaltfläche ordnungsgemäß geladen –, ausschließen kann ich es aber nicht. --Seth Cohen 15:37, 29. Sep. 2012 (CEST)

Ist dieses Problem nach wie vor reproduzierbar? Es ist aktuell der einzige Grund, aus dem ich die Betaversion zurück halte. --TMg 17:22, 26. Nov. 2012 (CET)

Bei mir derzeit ja. Ist mir auch öfters aufgefallen, dass das Tool manchmal nicht geladen wurde, endlich weiß ich wovon das abhängt.--CENNOXX 20:37, 26. Nov. 2012 (CET)

Verdammter Ressource-Loader. Ich hatte den Fehler gerade ein paar mal, er war aber alles andere als sicher reproduzierbar. Deswegen kann ich nicht sagen, ob meine Fehlerbehebung (nur in der Betaversion) etwas gebracht hat. Bitte berichtet mir, das würde mir sehr helfen. --TMg 21:16, 26. Nov. 2012 (CET)

Hab grad mal den Cache geleert, jetzt kann ich den Fehler nicht mehr reproduzieren.--CENNOXX 22:23, 26. Nov. 2012 (CET)

Weitere Vorschläge

• Slash am Ende von URLs ohne URL-Pfad
• DISPLAYTITLE → SEITENTITEL
• [[w:de:Beispiel]] → [[Beispiel]]
• {{Infobox_Unternehmen …}} → {{Infobox Unternehmen …}}

--Seth Cohen 20:00, 24. Sep. 2012 (CEST)

Unnötige w:de: oder auch nur de: kürze ich bereits. Wenn dir Fälle auffallen, in denen das nicht klappt, nenne mir bitte die Seite. DISPLAYTITLE habe ich eingebaut. Schrägstriche am Ende von URLs sind effektiv wirkungslos. Spätestens der Webbrowser korrigiert das sowieso. Vielleicht im Sonderfall [http://example.com Beispiel], also wenn der eingefügte Schrägstrich das Aussehen des Artikels nicht verändert. Das mit den Unterstrichen ist ein guter Hinweis, das werde ich zusammen mit den verbliebenen Unterstrichen in Links in Angriff nehmen. --TMg 16:46, 2. Okt. 2012 (CEST)

• [[:w:de:Beispiel]] wird nicht gekürzt.
• Danke.
• Dass Schrägstriche am Ende von URLs effektiv wirkungslos sind, ist mir klar. Meinst du, im Sonderfall willst du einen Schrägstrich ergänzen?
• Danke.

--Seth Cohen 18:18, 2. Okt. 2012 (CEST)

• [[:Bild:Beispiel.jpg]] und [[:File:Beispiel.jpg]] etc. → [[:Datei:Beispiel.jpg]]

--Seth Cohen 19:54, 2. Okt. 2012 (CEST)

Schrägstriche: Ja, genau. Als Sonderregel für Artikel mit der Gemeinde-Infobox hab ich das ja sogar schon drin, das müsste ich nur mal verallgemeinern. Wichtig ist mir, dass in solchen Fällen, in denen es Auswirkung auf das Aussehen des Artikels hat, kein „Schrägstrich-Krieg“ entsteht. Doppelpunkte: Es ist unglaublich, was du alles entdeckst. Wieder vielen, vielen Dank für deinen Einsatz. Aktuell werte ich den Doppelpunkt als Schutz, aber ich werde mir überlegen, diese Fälle aufzunehmen. --TMg 22:52, 4. Okt. 2012 (CEST)

Wie meinst du das, du wertest den Doppelpunkt als Schutz? --Seth Cohen 19:35, 17. Okt. 2012 (CEST)

Genauso, wie [[:en:Beispiel]] und [[:Datei:Beispiel.jpg]] bedeuten, dass die Software mit diesen Links nichts weiter tun soll, sondern sie so anzeigen, wie sie eingegeben wurden, genauso könnte man argumentieren, dass solche Links vor Skiptänderungen „geschützt“ sein sollen. Das ist aber Quatsch, wenn es eindeutig ist und sich das Linkziel nicht verändert. Alle hier gezeigten Fälle werden ja inzwischen ersetzt. --TMg 11:45, 30. Nov. 2012 (CET)

Dateinamen in Infoboxen (Beta)

Fehler und Revert. --Seth Cohen 15:40, 29. Sep. 2012 (CEST)

Interessant, an diesen Fall hatte ich noch nie gedacht. Lösbar wäre das (im Grunde läuft es darauf hinaus, Fragmente zu schützen, die dem Muster |…=….jpg entsprechen). Aber dazu brauche ich Zeit. Dringend erscheint mir das nicht. Dich möchte ich an dieser Stelle noch einmal dazu ermahnen, die Änderungen des Skriptes immer im Detail zu prüfen, idealerweise einmal per „Änderungen zeigen“ und abschließend noch einmal per Vorschau. --TMg 00:30, 1. Okt. 2012 (CEST)

Doch, dringend. ;-)

Das mache ich, keine Sorge. Ist es nicht der praktischste Weg, dich auf Fehler hinzuweisen? --Seth Cohen 19:11, 1. Okt. 2012 (CEST)

Innerhalb von Vorlagen werden Bindestriche in Dateinamen ebenfalls durch Halbgeviertstriche ersetzt, zum Beispiel in {{Panorama|Wiesbaden - Panorama.jpg|1500|Panoramaaufnahme von Wiesbaden vom Kriegerdenkmal am Neroberg aus gesehen}}. --Seth Cohen 20:01, 17. Okt. 2012 (CEST)

Ich habe das jetzt wie schon angedeutet gelöst: Ich nutze die Dateiendung zur Erkennung, ob das Fragment zu schützen ist. --TMg 17:20, 26. Nov. 2012 (CET)

autoFormatReplacements

var autoFormatReplacements = { '\\dHz': '\\d Hz', '§\\d': '§ \\d' };

Das funktioniert so nicht. Wo liegt der Fehler? --Seth Cohen 15:44, 29. Sep. 2012 (CEST)

Das mit dem Platzhalter geht aktuell nur nach Punkten, also z. B. in „Nr.5“. Ich werde nochmal schauen, ob etwas dagegen spricht, das flexibler zu gestalten. Die Hz hatte ich in meiner Maßeinheitensammlung irgendwie übersehen, das werde ich beheben. Den Paragraph behandle ich nur, wenn da zuvor schon ein Leerzeichen stand, da ich Schreibweisen ohne Leerzeichen nicht zerstören will. --TMg 00:24, 1. Okt. 2012 (CEST)

Ach so.

Die Schreibweise (Paragrafenzeichen ohne Leerzeichen) ist aber typografisch falsch. --Seth Cohen 19:15, 1. Okt. 2012 (CEST)

OK, überzeugt. Ich habe alles umgesetzt (Maßeinheit Hz wird beachtet, § ohne Leerzeichen wird beachtet, \\d kann frei verwendet werden). Vorerst aber nur in der Betaversion. --TMg 16:46, 2. Okt. 2012 (CEST)

Danke sehr. --Seth Cohen 17:09, 2. Okt. 2012 (CEST)

var autoFormatReplacements = { '\\df.': '\\d f.', '\\dff.': '\\d ff.' };

Das funktioniert so nicht. Wo liegt der Fehler? --Seth Cohen 21:17, 12. Okt. 2012 (CEST)

Die Automatik mit den Leerzeichen ist an den Punkt gekoppelt. In dem Fall hier musst du die Schreibweisen mit Leerzeichen als zusätzliche Regeln aufnehmen, damit alle Fälle erkannt werden. --TMg 22:24, 12. Okt. 2012 (CEST)

Danke sehr. Könntest du das ändern oder würde das Probleme machen? --Seth Cohen 23:10, 12. Okt. 2012 (CEST)

Dann wäre es nicht mehr möglich, Regeln zu konstruieren, die zwischen „5a“ und „5 a“ unterscheiden können. Es würde immer gleich behandelt werden. --TMg 00:37, 13. Okt. 2012 (CEST)

Ach so. Demnach lassen sich aktuell keine Regeln konstruieren, die zwischen „5.a“ und „5. a“ unterscheiden? --Seth Cohen 19:33, 17. Okt. 2012 (CEST)

Korrekt, präziser hätte ich es nicht formulieren können. Die Funktion ist ja hauptsächlich für Abkürzungen entstanden, da erspart diese kleine Automatik das sonst nötige Doppeln. --TMg 22:47, 17. Okt. 2012 (CEST)

Prozentangaben

Ist es gewollt, dass dein Skript bei Prozentangaben, die das Layout betreffen eingreift? Zum Beispiel wird bei einer Tabelle aus |width=40% valign=top| (ohne Leerzeichen) |width=40 % valign=top| (mit Leerzeichen). --Seth Cohen 13:59, 3. Okt. 2012 (CEST)

Nein, das ist natürlich ein falscher Fehler. Ich hab die Regel mal etwas verfeinert, mit dem Nachteil, dass so etwas wie |Wahlbeteiligung=41% in Infoboxen nicht mehr erkannt wird. Aber das dürfte in der Summe seltener vorkommen als der Problemfall, den du gefunden hast. --TMg 15:20, 3. Okt. 2012 (CEST)

Falscher Fehler? :-D

Kannst du die Regel nicht so formulieren, dass das Skript nur bei Angaben wie width=, height= etc. keine Änderungen durchführt? --Seth Cohen 16:10, 3. Okt. 2012 (CEST)

Negativ-Regeln, die über den Ausschluss einzelner Zeichen hinaus gehen, machen die Sache schnell irrsinnig komplizierter, langsam und fehleranfällig. Da mag ich ein simples „hinter Gleichheitszeichen nie“ lieber. Der erwähnte Fall sollte kaum vorkommen. In Infoboxen wird das meist mit Leerzeichen geschrieben oder gar nur als Zahl und die Vorlage kümmert sich um das Prozentzeichen. Sprich, wenn so was mal ein Problem sein sollte (in der Vorlage:Infobox Wahlkreis habe ich es beispielsweise gerade entdeckt), würde ich eher darüber nachdenken, die Vorlage zu ändern. --TMg 23:06, 4. Okt. 2012 (CEST)

Okay. --Seth Cohen 20:47, 7. Okt. 2012 (CEST)

1-Buchstaben-Maßeinheiten

Die Einheit g wird nicht berücksichtigt. --Seth Cohen 18:51, 10. Okt. 2012 (CEST)

Stimmt, aber angesichts des Ärgers, den schon das m macht, scheue ich mich etwas davor, weitere 1-Buchstaben-Einheiten einzubauen. l, s, t u. a. fehlen deshalb auch. Wo genau und wie häufig kommt das g denn vor? --TMg 23:14, 10. Okt. 2012 (CEST)

Welchen Ärger macht das m denn? Wo das g überall vorkommt und wie häufig, kann ich dir nicht sagen. --Seth Cohen 17:58, 12. Okt. 2012 (CEST)

Mir reicht für den Anfang schon der Name des Artikels, in dem dir das aufgefallen ist. Ärger mit dem Meter hattest du selbst schon und mir ist das auch schon untergekommen. Bei Einheiten mit 2 Buchstaben ist das Risiko einer solchen Fehlerkennung einfach wesentlich geringer. Vielleicht muss ich die Regel für die danach erlaubten Zeichen umdrehen, so wie ich das schon beim Gedankenstrich gemacht hatte. Statt „alle Zeichen außer“ dürfte nach „2 m“ dann nur noch Leerraum oder !'),./:;?| folgen. Deckt das alles ab? So was wie [[2m]] oder {{Vorlage|2m}} würde dann bewusst rausfallen. --TMg 01:03, 13. Okt. 2012 (CEST)

Revision: Geschützte Leerzeichen werden ab sofort nur noch eingesetzt, wenn auf die Maßeinheit ein Leerraum, !'),./:;? oder das typografische “ folgt. (Wichtig für mich: Für Letzteres muss die Regel nach der Anführungszeichen-Ersetzung folgen.) Der senkrechte Strich entfällt vorerst, weil Ersetzungen innerhalb von Tabellen und Vorlagen oft einfach unnötig sind. Das Gramm habe ich ergänzt. --TMg 18:44, 7. Nov. 2012 (CET)

Symbol

Statt des „Auto-Format“-Symbols wird plötzlich nur noch der Text „Auto-Format“ in der Bearbeiten-Werkzeugleiste angezeigt. --Seth Cohen 18:09, 16. Okt. 2012 (CEST)

Ich hasse Commons. Dieser hochnotpeinliche Fehler existiert seit weit über einem Jahr aber niemand ist in der Lage, ihn zu lokalisieren geschweige denn zu beheben. Was macht die Foundation mit dem Geld? --TMg 19:52, 16. Okt. 2012 (CEST)

Und nun? --Seth Cohen 21:47, 16. Okt. 2012 (CEST)

Den Entwicklern auf die Füße treten. --TMg 23:02, 16. Okt. 2012 (CEST)

Lässt sich das denn jetzt erst mal durch einen Purge oder dergleichen beheben? --Seth Cohen 19:31, 17. Okt. 2012 (CEST)

Nö. Nervt mich tierisch. Aber ich weigere mich jetzt auch, hier rumzufummeln (ich könnte die Bildgröße um ein Pixel verändern, dann würde es erst mal wieder gehen). Den Bug hab ich jetzt rotzfrech auf die höchste Priorität gesetzt. --TMg 21:55, 17. Okt. 2012 (CEST)

„They can’t use the tool because of this bug.“

Das stimmt zwar nicht ganz, aber es ist dennoch ein Unding.--Seth Cohen 01:07, 18. Okt. 2012 (CEST)

„Nicht benutzbar“ ist sicher etwas übertrieben, aber wenn man nicht mehr sieht, wo man klickt, ist das schon signifikant. Inzwischen wurde das kaputte Thumbnail manuell neu erzeugt. Behoben ist der Fehler längst nicht (erst heute war z. B. das {{Commons}}-Symbol kaputt). --TMg 22:19, 26. Okt. 2012 (CEST)

Ach so, schade. --Seth Cohen 22:33, 26. Okt. 2012 (CEST)

Cursor

Die Anwendung des Skripts führt jetzt dazu, dass der Cursor ans Ende des Artikels springt und entsprechend heruntergescrollt wird. --Seth Cohen 18:18, 16. Okt. 2012 (CEST)

Bei mir nicht. Firefox? Was hat sich geändert, seit das passiert? --TMg 19:56, 16. Okt. 2012 (CEST)

Hm, war wohl nur ein vorübergehender Fehler, es lässt sich jedenfalls nicht mehr reproduzieren. --Seth Cohen 21:48, 16. Okt. 2012 (CEST)

Großschreibung von Vorlagen

Könntest du eine Regel ergänzen, die die Schreibung von Vorlagen gegebenenfalls von klein auf groß ändert, zum Beispiel {{dieser Artikel|…}} → {{Dieser Artikel|…}}? --Seth Cohen 19:51, 17. Okt. 2012 (CEST)

Das hab ich mir auch schon überlegt, aber pauschalisieren kann ich das keinesfalls. Auf Anhieb fallen mir die Sprach-Vorlagen ein, die bewusst klein geschrieben werden. Wenn du mir Vorlagen nennst, bei denen die Großschreibung Konsens ist und die dir in Artikeln in Kleinschreibung begegnen (Beispielartikel zur Anschauung finde ich immer sehr hilfreich), nehme ich diese gern auf. „Dieser Artikel“ ist schon mal ein guter Kandidat dafür. --TMg 21:40, 17. Okt. 2012 (CEST)

Welche Sprachvorlagen werden denn kleingeschrieben? Meinst du die ersten zwölf, die mit einem " beginnen? --Seth Cohen 01:11, 18. Okt. 2012 (CEST)

{{enS|…}} etc. Das Großschreiben würde ich wie gesagt gern per Positivliste machen. Bei {{Commons}} mach ich es schon. Wo noch? --TMg 22:14, 26. Okt. 2012 (CEST)

Na ja, eigentlich wird die Vorlage EnS ja gar nicht kleingeschrieben.

Alle Vorlagen aufzuzählen, die mitunter kleingeschrieben sind, würde wohl den Rahmen sprengen. Ein Beispiel: Vorlage Belege. --Seth Cohen 22:39, 26. Okt. 2012 (CEST)

Was meinst du mit „wird nicht kleingeschrieben“? So steht es in der Dokumentation und so ist es in Artikeln üblich. Ich überlege sogar, das hier aufzunehmen, also dass es immer in Kleinschreibung gewandelt wird. Nennen sollst du mir wenn möglich Vorlagen, die dir gehäuft in Kleinschreibung begegnen. --TMg 23:26, 26. Okt. 2012 (CEST)

MediaWiki lässt ja gar keine kleingeschriebenen Vorlagen zu, {{enS|…}} wird zu {{EnS|…}}. --Seth Cohen 01:39, 27. Okt. 2012 (CEST)

Irgendwas bringst du hier durcheinander. Aus technischer Sicht unterscheidet die Software einfach nicht zwischen Groß- und Kleinschreibung. Beide Schreibweisen bewirken genau das Selbe, und das heißt auch, dass keine Schreibweise richtiger als die andere ist. Was wir in welchem Fall bevorzugen, ist eine rein stilistische Frage. Ein kleines „enS“ im Artikel bleibt auch nach dem Abspeichern klein. --TMg 02:37, 27. Okt. 2012 (CEST)

Ich habe mich unglücklich ausgedrückt. Gemeint war, dass {{enS|…}} ohnehin auf EnS verweist. Aber gut, wenn die Vorlage in Artikeln kleingeschrieben werden soll, was ja offensichtlich der Fall ist, dann nimm die Umwandlung doch ruhig auf. Wobei ich mich nicht erinnern kann, dass sie mir in Artikeln mal großgeschrieben begegnet ist. --Seth Cohen 17:08, 27. Okt. 2012 (CEST)

Ich habs mal in einer Liste zusammen gefasst. Bitte ergänzen, wenn dir bei deiner Artikelarbeit mehr klein Geschriebenes auffällt. Die meistbenutzten Vorlagen laut Vorlagenauswertung sind vielleicht ganz interessant, da ist sogar die Groß/Kleinschreibung erkennbar. Allgemein: Wartungsbausteine stehen per Definition nur begrenzte Zeit im Artikel. Korrekturen daran möchte ich nur in Ausnahmefällen durchführen. Weiterleitungen möchte ich gern auflösen, kann das aber natürlich nur machen, wenn dazu ein erkennbarer Konsens besteht. --TMg 00:10, 3. Nov. 2012 (CET)

Erst mal vielen Dank!

Inwiefern sich die nur temporäre Verwendung der Wartungsbausteine und eine Korrektur derselben widersprechen, erschließt sich mir nicht.

Was die Weiterleitungen angeht, in den meisten Fällen wird doch sicherlich der offizielle Vorlagennamen präferiert. Dass du die Weiterleitungen der Vorlagen {{Belege}}, {{Quelle}}, {{Quellen}} und {{Quellen fehlen}} mangels Konsens nicht auflösen möchtest, leuchtet mir ein; aber etwaige Kleinschreibung kann doch ruhig in Großschreibung geändert werden. --Seth Cohen 17:41, 4. Nov. 2012 (CET)

In beiden Fällen würde eine automatische Korrektur suggerieren, dass es sich um eine Änderung hin zu einem erwünschten, präferierten Zustand handeln würde. Bausteine werden aber sowieso wieder entfernt, auf lange Sicht spielt ihre Schreibweise keine Rolle. Das macht nur die Versionsvergleiche unübersichtlich und verführt unbedarfte Benutzer zu Unsinns-Bearbeitungen, die nur daraus bestehen, „quelle“ groß zu schreiben. --TMg 18:30, 4. Nov. 2012 (CET)

In meinen Augen ist zum Beispiel {{Quelle}} auch durchaus {{quelle}} vorzuziehen. Dass unbedarfte Benutzer derartige Bearbeitungen durchführen würden, halte ich für ziemlich unwahrscheinlich.

„Nichts gegen die Korrektur offensichtlicher Tippfehler, aber das geht mir deutlich zu weit.“ SCNR. Du hast meine Listen ja auch umgepflügt. ;-) --Seth Cohen 18:28, 7. Nov. 2012 (CET)

Ich weiß natürlich, dass du es gut meinst, aber wenn ich Kommentare etwas flapsiger formuliere, ist das kein Versehen. Ich meine auch, dass „habs“ und „klein Geschriebenes“ nicht falsch sind. Die Templatetiger-Liste bin ich mal durchgegangen und habe mir die folgenden Kandidaten heraus gegriffen. So was wie „DEU“ kann nicht falsch geschrieben werden, denn dann funktioniert es nicht mehr. Bei offensichtlichen Substantiven wie „Normdaten“ sind Falschschreibungen unwahrscheinlich. Datenbanklink-Vorlagen sind mir zu wenig allgemein, die möchte ich nicht in ein so allgemeines Skript aufnehmen. --TMg 15:24, 9. Nov. 2012 (CET)

Erledigtes:

• {{Belege fehlen}}: Erledigt incl. Weiterleitungs-Auflösung (jetzt doch, weil WikiSyntaxTextMod das auch macht).
• {{Dieser Artikel}}: Erledigt.
• {{Dts}}, {{Dtsx}}, {{Nts}}: Erledigt.
• {{EnS}} usw.: Erledigt.
• {{Hauptartikel}}: Erledigt incl. Weiterleitungs-Auflösung.
• {{Internetquelle}}: Erledigt incl. Weiterleitungs-Auflösung.
• {{Lang}}: Erledigt.
• {{Link GA}}, {{Link FA}}: Erledigt.
• {{Rotten Tomatoes}}: Erledigt incl. Weiterleitungs-Auflösung.
• {{Siehe auch}}: Erledigt incl. Weiterleitungs-Auflösung.
• {{SortKey}}, Vorlage|SortKeyName, {{SortDate}}: Erledigt.
• {{Wikinews}}, {{Wikiquote}} usw.: Erledigt.

Offenes:

• {{Coordinate}}, Koordinate: Bin mir unsicher. Weiterleitungs-Auflösung wahrscheinlich kein Konsens.
• {{Fishbase}}: Scheint mir zu wenig allgemein.
• {{Zh}}: Wie enS behandeln.

Geschützte Leerzeichen bei Währungsangaben

Was hältst du von geschützten Leerzeichen bei Währungsangaben (zum Beispiel €, EUR und $)? --Seth Cohen 19:54, 17. Okt. 2012 (CEST)

Wo kommt das vor, außer als Umsatz in Unternehmens-Infoboxen? An allen anderen Stellen scheinen Geldbeträge als rotes Tuch wahrgenommen zu werden. Zumindest wurde ich schon einmal angefeindet, weil ich mich erdreistete, über die Erwähnung von Einführungspreisen in Produktartikeln nachzudenken. Deshalb habe ich Respekt davor, an so etwas herum zu fummeln, da das nur die Aufmerksamkeit darauf lenkt. Ein zweites Problem habe ich mit der „korrekten“ Schreibung. Wo kommt bei „100 Mio. Euro“ ein geschütztes Leerzeichen hin? Zwei? Fände ich nicht gut. Wo bei der (falschen) Schreibweise „US$100“? Oder reicht es schon, die simplen Fälle wie „1 €“ abzudecken? --TMg 21:50, 17. Okt. 2012 (CEST)

Beispiele: 1, 2, 3, 4, 5, 6.

Bei „100 Mio. Euro“ wären wohl tatsächlich zwei geschützte Leerzeichen angebracht. --Seth Cohen 01:27, 18. Okt. 2012 (CEST)

Super, danke. Das iPod-Beispiel find ich lustig. Die paar verlorenen Preise da hat offenbar nur noch niemand gelöscht. Dabei wären die Apple-Produkte mit ihrer relativ starren Preisstruktur ideal, um das auch im Artikel zu erwähnen. Aber nein, da steht nichts. Ist das eine Art Zensur? Zurück zum Thema: Schreibt man in Österreich wirklich „EUR 1“? Das liest sich ja schrecklich. Ich denke, ich werde nur ein paar simple Schreibweisen wie „1 €“, „1 Euro“, „1 US$“ und natürlich die offiziellen Kürzel EUR, USD usw. aufnehmen. Nur $ absichtlich nicht, weil das oft mehrdeutig ist und sonst den falschen Eindruck erweckt, der Benutzer, der ein geschütztes Leerzeichen einsetzt, hätte sich damit beschäftigt und es für richtig befunden. --TMg 22:34, 26. Okt. 2012 (CEST)

Zu der Sache mit den Preisangaben kann ich nichts sagen, ich weiß nicht, was das soll.

Ob man in Österreich „EUR 1“ schreibt, weiß ich auch nicht, im Fließtext ist das jedenfalls unschön. In Tabellen zum Beispiel würde ich zumindest „EUR 1,00“ oder „EUR 1,–“ bzw. „EUR 1,—“ (siehe hier) schreiben, einfach nur „EUR 1“ sieht komisch aus.

Klingt gut. Inwiefern meinst du, sei das Dollarzeichen mehrdeutig? --Seth Cohen 22:47, 26. Okt. 2012 (CEST)

Liste von Dollarwährungen. ;-) --TMg 23:31, 26. Okt. 2012 (CEST)

Ach so, die verschiedenen Währungen meintest du. --Seth Cohen 01:16, 27. Okt. 2012 (CEST)

Konkreter Vorschlag: EUR, Euro, €, CHF, USD, US$, JPY, ¥. Aber wie gesagt nur hinter Zahlen. Leerzeichen würde ich wie bei allen andern Maßeinheiten auch erzwingen, aus 1€ wird also 1 €. --TMg 17:01, 28. Okt. 2012 (CET)

Gut. Kann ja später noch erweitert werden. Baust du auch eine Korrektur bei umgedrehter Reihenfolge (Beispiel: EUR 1,00) ein? Und werden führende Nullen (Beispiel: 01,00 EUR) getilgt? --Seth Cohen 18:26, 30. Okt. 2012 (CET)

Die genannten Währungseinheiten sind drin. Bezüglich der weiteren Vorschläge bin ich – wie immer ;-) – skeptisch. Den Text ungefragt verändern möchte ich ungern, da so etwas wie „04,00“ etwa in Tabellen auch Absicht sein kann. Ebenso bei „EUR 4“. Außer natürlich, es gibt dazu einen klar belegbaren Konsens, auf den ich mich berufen kann. Am ehesten überlege ich noch, die beiden häufigen Schreibweisen „4 Mio. EUR“ und „4 Mrd. EUR“ aufzunehmen, eventuell sogar mit gleichzeitiger Ergänzung eventuell fehlender Punkte. Wobei ich das zu 4 Mio. EUR machen würde, da ich kein Freund von zwei oder mehr   hintereinander bin. Das führt schnell zu übermäßigem Flattersatz, vor allem wenn (etwa in Infoboxen) wenig Platz zur Verfügung steht. --TMg 19:02, 7. Nov. 2012 (CET)

Danke sehr. Dass du hinsichtlich meiner Vorschläge skeptisch bist, ist gut und richtig, das gewährleistet schließlich die hohe Qualität deines Skripts. In diesem Fall waren meine beiden Fragen eher spontane Ideen, weniger konkrete Vorschläge. --Seth Cohen 18:52, 15. Nov. 2012 (CET)

Vorlage Charts

Könntest du die Datumsformatierung (17.10.2012 → 17. Oktober 2012) innerhalb der Vorlage Charts abstellen? --Seth Cohen 19:57, 17. Okt. 2012 (CEST)

Hier ein Beispiel. Die Infobox Chartplatzierungen wird durch die Datumsformatierung unschön gestreckt. --Seth Cohen 18:54, 26. Okt. 2012 (CEST)

Vielen Dank für das Beispiel. Ich bin da sehr unschlüssig. Die einfachste Lösung wäre, die Datumsersetzung auszulassen, wenn vor/hinter dem Datum ein | steht. Aber das würde auch erwünschte Fälle ausklammern, etwa Daten in Tabellen. Ich denke, das muss zusammen mit Vorlage:Zitat, Vorlage:Internetquelle und einigen anderen in die „Liste der zu schützenden Vorlagen“, für die ich mir noch eine Lösung ausdenken muss. Bis dahin empfehle ich, mit der Möglichkeit zu arbeiten, nur einen markierten Textteil zu formatieren. --TMg 22:08, 26. Okt. 2012 (CEST)

Die Datumsformatierung innerhalb von Vorlagen komplett zu deaktivieren, ist keine Option? Tabellen wären davon ja nicht betroffen. --Seth Cohen 22:50, 26. Okt. 2012 (CEST)

Genau das meine ich, ich habe aktuell nur noch keine Technik für den Schutz von Vorlagen im Skript. --TMg 23:27, 26. Okt. 2012 (CEST)

Prima. „Liste der zu schützenden Vorlagen“ klang für mich nach einer Positivliste, nicht nach einem generellen Ausschluss von Vorlagen. --Seth Cohen 01:18, 27. Okt. 2012 (CEST)

Ich hatte dich doch falsch verstanden. Nein, kein genereller Ausschluss, bestimmte Ersetzungen sollen beispielsweise in Infoboxvorlagen ja weiterhin durchgeführt werden. --TMg 02:41, 27. Okt. 2012 (CEST)

Da hast du recht. --Seth Cohen 17:12, 27. Okt. 2012 (CEST)

Grad gemerkt: Das selbe Problem hatte ich schon mal behoben. Ist in der Betaversion irgendwie verloren gegangen. --TMg 01:17, 28. Okt. 2012 (CEST)

Huch, das hatte ich nicht gesehen. --Seth Cohen 16:15, 28. Okt. 2012 (CET)

Geschweifte Klammern

Schau mal, was dein Skript hier mit den beiden geschweiften Klammern macht. --Seth Cohen 17:31, 26. Okt. 2012 (CEST)

Lustig. Ich staune immer wieder, was du so alles findest. Das Skript denkt, das ab dem #time wäre ein Anker und de- bzw. kodiert ihn. Ich habs behoben. Eigentlich soll das Skript auf solche vorlagenlastigen Seiten aber gar nicht angewendet werden. Da wird zwangsläufig immer irgendwas kaputt ersetzt. --TMg 22:01, 26. Okt. 2012 (CEST)

Bei Anwendung des Skripts auf solch vorlagenlastigen Seiten schaue ich mir die Änderungen vor dem Speichern auch sehr genau an.

Sieh mal, was hier mit den ä passiert.

Und hier werden zwei div-Container zerschossen. Wäre es nicht sinnvoll, innerhalb spitzer Klammern keine Ersetzung von Anführungszeichen durchzuführen? --Seth Cohen 22:59, 26. Okt. 2012 (CEST)

Das ist etwas verwirrend, weil es sich um eine alte Version handelt und bei „Änderungen zeigen“ ein Vergleich mit der aktuellen Version vorgenommen wird. Vorher sahen die beiden div-Container so aus. --Seth Cohen 23:06, 26. Okt. 2012 (CEST)

Die ä waren vorher schon kodiert. So was dekodiere ich aktuell nur in #Ankern. Wir hatten schon mal darüber geredet, dass ich das auf den ganzen Link ausdehnen müsste. Mal sehen. Auf jeden Fall wieder ein gutes Beispiel. Die DIVs waren vorher schon völliger Murks, da richtet die Ersetzung nicht wirklich Schaden an. Sie richtet im Gegenteil die Aufmerksamkeit darauf. It’s not a bug, it’s a feature. ;-) Kontextsensitivität ist halt so ein Problem. Reguläre Ausdrücke sind kontextfrei. Ich nehm als Fazit mal mit, dass ich auch bei den Anführungszeichen von Negativ- auf Positivlisten wechseln sollte (nur noch ersetzen, wenn davor und dahinter bestimmte erlaubte Zeichen stehen). --TMg 03:00, 27. Okt. 2012 (CEST)

Das mit der Aufmerksamkeit bei den div-Containern habe ich mir auch gedacht. :-) --Seth Cohen 17:16, 27. Okt. 2012 (CEST)

Ich denke mal laut und bitte um Kommentierung. Liste von Zeichen, die ich vor Anführungszeichen erlauben würde: Leerraum, !#'(*+/:;>[|. Zeichen, die ich nach Anführungszeichen erlauben würde: Leerraum, !'),./:;<?]}. Innerhalb der Anführungszeichen ist alles erlaubt, außer dem Zeilenumbruch und "“”„. Außerdem darf das erste und letzte Zeichen kein Leerraum sein. --TMg 16:43, 28. Okt. 2012 (CET)

Sieht gut aus.

Hier werden auch zwei geschweifte Klammern kodiert. --Seth Cohen 17:46, 30. Okt. 2012 (CET)

Die Anführungszeichen-Regel ist umgestellt. Das mit den Umlauten fehlt noch, aber das steht unten nochmal. Den letzten Fall ([[#{{suburl|Überschrift}}]]) halte ich für Unfug. Ich war ganz unabhängig von dir über diese Vorlage gestolpert und habe schon begonnen, sie zu substituieren. Meine Ersetzungsregel deshalb zu entschärfen, würde ihre Nützlichkeit einschränken. Aktuell ist es nämlich möglich, eine Überschrift zu kopieren, in einen Link einzusetzen ([[#{{Vorlage}} spinnt]]) und per Knopfdruck funktional zu machen ([[#%7B%7BVorlage%7D%7D spinnt]]). Das würde verloren gehen. --TMg 16:35, 4. Dez. 2012 (CET)

Jahreszahlenbereich

Hier („2001-2005“) funktioniert die Ersetzung des Bindestrichs durch einen Bis-Strich nicht. --Seth Cohen 20:38, 27. Okt. 2012 (CEST)

Das ist Absicht aufgrund der eckigen Klammer dahinter. Ich finde die Meldung nicht mehr, aber es ging um Interwikilinks nach dem Schema [[:fr:Lemma 1936-1937]], in die kein Halbgeviertstrich hinein darf. --TMg 01:28, 28. Okt. 2012 (CEST)

Eine Fallunterscheidung, ob eine oder zwei schließende eckige Klammern folgen, müsste das doch lösen. --Seth Cohen 16:13, 28. Okt. 2012 (CET)

Mit der Technik, die ich jetzt verwende, geht das nicht so einfach. Oder anders gesagt ist es mir den Aufwand nicht wert. Ich würde das gern so lassen. --TMg 16:46, 28. Okt. 2012 (CET)

Schade. --Seth Cohen 19:05, 30. Okt. 2012 (CET)

Parameter Datei

Werte des Parameters Datei beziehungsweise datei in Vorlagen wie {{Gesprochene Version}} werden nicht „geglättet“. Hier ein Beispiel. --Seth Cohen 23:47, 1. Nov. 2012 (CET)

Dazu müsste ich dem Skript eine Liste aller Vorlagen mitgeben, wie der oder die Bildparameter dort heißen und was für Werte diese akzeptieren. Es gibt sogar welche, die sowohl Datei = Name.jpg als auch Datei = [[Datei:…]] erlauben (intern nutzen sie ifexist zur Unterscheidung). Sowohl der einmalige Implementierungsaufwand wäre relativ hoch als auch die dauernde Anpassung der Liste an den jeweils aktuellen Stand der unterstützten Vorlagen. Für den Nutzen ist mir da der Aufwand deutlich zu hoch, tut mir leid. --TMg 23:41, 2. Nov. 2012 (CET)

Kein Problem. --Seth Cohen 17:26, 4. Nov. 2012 (CET)

„Aus Versehen“ mit erledigt, zumindest teilweise. Unterstriche werden ersetzt. --TMg 17:17, 26. Nov. 2012 (CET)

Wikilinks

[[Deutschland ]], [[ Deutschland]], [[Deutschland|]] → [[Deutschland]] (Beispiel) --Seth Cohen 00:02, 2. Nov. 2012 (CET)

Sieht nach einer guten Idee aus, danke für den Hinweis. Die ersten beiden Beisiele erfordern besondere Sorgfalt (Test: „Prefix ation“, „Prefixation“). Das mit dem Strich scheint eindeutig zu sein (Test: „Prefixation“ → „Prefixation“). --TMg 15:29, 5. Nov. 2012 (CET)

Danke dir für deine Mühe! --Seth Cohen 18:35, 7. Nov. 2012 (CET)

Ist mir auch prompt in der Praxis begegnet. Dein drittes Beispiel wird übrigens schon vom MediaWiki gesäubert. --TMg 14:53, 9. Nov. 2012 (CET)

Meinst du [[Datei:Neunburg vorm Wald Rathaus 40583.jpg|miniatur| Wappen am Rathaus]] und [[Bayernwerk |Bayernwerk AG]]? Ja, korrekt dargestellt wird [[Deutschland|]], das stimmt. Entfernen würde ich den überflüssigen senkrechten Strich dennoch. Übrigens, selbst im Versionsvergleich wird [[Deutschland|]] paradoxerweise als [[Deutschland|Deutschland]] angezeigt. --Seth Cohen 18:45, 15. Nov. 2012 (CET)

Das letzte Beispiel wird beim Speichern automatisch zu [[Deutschland|Deutschland]] und das säubere ich schon. Als [[Deutschland|]] kann das höchstens vorkommen, wenn man es gerade eben selbst eingefügt hat. Genau dann kann es aber Absicht sein, bspw. [[Test (Klammer)|]]. Um das nicht kaputt zu machen, müsste ich die Logik der MediaWiki-Software 1:1 nachbauen. Das scheint mir den Nutzen nicht zu rechtfertigen. Das mit den Leerzeichen halte ich aber für lohnenswert. --TMg 21:39, 15. Nov. 2012 (CET)

Sogar schon vor dem Speichern bei „Änderungen zeigen“. Ja, da hast du recht, das wäre wohl etwas viel des Guten. --Seth Cohen 21:45, 15. Nov. 2012 (CET)

Zeile 401. --Seth Cohen 21:49, 16. Nov. 2012 (CET)

Reguläre Ausdrücke in benutzerdefinierten Ersetzungen

Könntest du zusätzlich zur Zeichenauswahl und dem Platzhalter für Zahlen auch den Platzhalter für Buchstaben, Zahlen und Unterstriche \\w in den benutzerdefinierten Ersetzungen (autoFormatReplacements) zulassen? Dann könnte ich mir zum Beispiel Apostroph-Regeln basteln. --Seth Cohen 00:17, 2. Nov. 2012 (CET)

Mein \\d-Platzhalter hat nicht die selbe Bedeutung wie in regulären Ausdrücken. Bei mir steht er für „eine oder mehr Ziffern“ (entspricht also \d+). Das \\w müsste ich genauso behandeln, um die Einheitlichkeit zu wahren (ich würde sogar etwas im Sinne von [A-Za-z\xB5\xC0-\xD6\xD8-\xF6\xF8-\u02AF]+ daraus machen, also Umlaute mit einbeziehen). Würde das auf deinen Fall passen? Ich nehme an, du willst "\\w's": "\\w’s" schreiben? --TMg 17:16, 2. Nov. 2012 (CET)

Aus dem Kommentar „und evtl. weitere Buchstaben, z. B. Umlaute“ in der Tabelle der Vordefinierten Zeichenklassen bin ich nicht ganz schlau geworden. Mir fällt zwar spontan kein Beispiel ein, in dem auf einen Umlaut ’s folgen könnte, aber schaden kann es sicherlich nicht, die Umlaute mit aufzunehmen. Genau, du liegst vollkommen richtig mit deiner Annahme. :-) --Seth Cohen 17:34, 2. Nov. 2012 (CET)

Ob das Regex-\w Umlaute einbezieht, hängt von der Konfiguration der Regex-Engine ab. Diese Möglichkeit gibt es beispielsweise in Perl, in JavaScript wurde sie bewusst weggelassen. Meine jetzige Umsetzung des \\w weicht davon ab: Es findet einen oder mehrere Buchstaben, wobei alle für unsere Zwecke relevanten Umlaute dazu zählen, Zahlen und der Unterstrich aber nicht. --TMg 15:19, 5. Nov. 2012 (CET)

1. Danke für die interessanten Infos.
2. Herzlichen Dank für die Umsetzung!
3. Den Unterstrich braucht’s wirklich nicht, aber Zahlen wären schon gut. Beispiel: “The 1970’s”

--Seth Cohen 18:38, 7. Nov. 2012 (CET)

Ich wollte da bewusst keine Überschneidung. Mach zwei Regeln: "\\d's": "\\d’s", "\\w's": "\\w’s". --TMg 13:42, 8. Nov. 2012 (CET)

Hast vollkommen recht, das dachte ich mir später auch. Nochmals vielen Dank! --Seth Cohen 19:59, 8. Nov. 2012 (CET)

„Mir fällt zwar spontan kein Beispiel ein, in dem auf einen Umlaut ’s folgen könnte, aber schaden kann es sicherlich nicht, die Umlaute mit aufzunehmen.“

Was habe ich mir denn dabei gedacht? Es ist ja völlig unerheblich, ob der Umlaut am Ende des Wortes oder irgendwo anders vorkommt. Und ob dann ’s oder etwas anderes folgt, steht noch mal auf einem anderen Blatt. --Seth Cohen 18:58, 15. Nov. 2012 (CET)

Kodierung und Dekodierung

[[Regul%C3%A4rer Ausdruck#Vordefinierte Zeichenklassen]] wird nicht zu [[Regulärer Ausdruck#Vordefinierte Zeichenklassen]]. --Seth Cohen 00:24, 2. Nov. 2012 (CET)

Das hast du in verschiedenen Variationen inzwischen mindestens dreimal genannt. Ich werde es wohl endlich mal machen müssen. ;-) --TMg 19:39, 2. Nov. 2012 (CET)

Ehrlich? Auch mit dieser Art Kodierung? --Seth Cohen 19:56, 2. Nov. 2012 (CET)

Jein. Das mit den Unterstrichen zählt zur selben Kodierung. Ein gutes Beispiel für alles zusammen wäre etwa: [[Regul%C3%A4rer_Ausdruck|Regex]]. --TMg 15:21, 5. Nov. 2012 (CET)

Wie auch immer, doppelt (und dreifach) hält besser. ;-) --Seth Cohen 18:40, 7. Nov. 2012 (CET)

Anführungszeichen innerhalb der Vorlagen Zitat und "

Wäre toll, wenn du das noch einbauen könntest. --Seth Cohen 14:39, 2. Nov. 2012 (CET)

Schrägstriche

Guten Abend, ich bin gerade auf diesen Fehler (?) aufmerksam gemacht worden. Die Einstellungen in meiner vector.js hatte ich ja nach dem Problemchen in der letzten Woche geändert, denke also derzeit auch die korrekte Version des autoFormatters zu nutzen. Also bitte einmal die Anomalie erkunden. Danke und Gruß, Elvaube?! 19:41, 2. Nov. 2012 (CET) Nutze wohl die Beta! Elvaube?! 19:45, 2. Nov. 2012 (CET)

Meines Erachtens hat das nichts mit autoFormatter.js zu tun. --Seth Cohen 20:15, 2. Nov. 2012 (CET)

Fürs Archiv: Es ist ein Bug in WikiSyntaxTextMod, siehe dort. --TMg 23:20, 2. Nov. 2012 (CET)

Tausendertrennzeichen

Wieso funktioniert denn var autoFormatReplacements = { '\\d\'\\d': '\\d.\\d' } nicht, um die Tausendertrennzeichen zu ersetzen? Beispiel. --Seth Cohen 19:03, 15. Nov. 2012 (CET)

So was. Da hab ich extra Zeit investiert, damit genau das geht, und genau das dabei kaputt gemacht. Jetzt funktioniert es. --TMg 21:06, 15. Nov. 2012 (CET)

Bestens. Vielen Dank! --Seth Cohen 21:36, 15. Nov. 2012 (CET)

Verlinkung

Was hältst du hiervon? --Seth Cohen 19:37, 15. Nov. 2012 (CET) Ist hierdurch (Zeile 339) entstanden. --Seth Cohen 19:42, 15. Nov. 2012 (CET)

So ein Quatsch. ;-) Von „Airbus A319-100“ zu „Airbus A319-100“ zu „Airbus A319-100“. Keiner dieser Links ist besser als der andere. Das sind alles nur Weiterleitungen auf den immer selben Übersichtsartikel. Die Weiterleitung Airbus A319-100 halte ich für akzeptabel, aber es ist nicht in Ordnung, dass die Bearbeitung des unangemeldeten Benutzers nur aus dem Verschieben der eckigen Klammern bestand. Das hat den Artikel in keinster Weise besser gemacht. Andere akzeptable Möglichkeiten, die das Skript auch nicht antastet, wären „Airbus A319-100“ oder gleich „Airbus A319-100“ gewesen.

Aus der Perspektive „was könnte das Skript tun“ und „was kann ich daraus lernen“ betrachtet: Es wäre schick, wenn das Skript bei Links wie [[Airbus A319|Airbus A319-100]] prüfen würde, ob der hintere Teil „Airbus A319-100“ als Lemma existiert. Die Frage ist nur, was dann passieren soll? Das wäre das erste Mal, dass das Skript ein Linkziel verändert. Und in was? Angenommen, Airbus A319 ist ein Artikel aber Airbus A319-100 nur eine Weiterleitung, wäre es dann besser, den Artikel- in einen Weiterleitungslink zu ändern? Oder das Weiterleitungsziel auslesen und einsetzen? Ich bin mir sicher, dass das nicht konsensfähig ist, eben weil Weiterleitungen auch Absicht sein können. Kurz: Ich denke nicht, dass es gut wäre, wenn mein Skript Linkziele verändert. --TMg 21:30, 15. Nov. 2012 (CET)

Danke für die ausführliche Antwort. Dass dein Skript Linkziele verändert, darauf wollte ich auch nicht hinaus. Ich war mir nur unsicher, wie der Link nun am besten auszusehen hat. --Seth Cohen 21:41, 15. Nov. 2012 (CET)

Leerzeichen bei HTML-Kommentaren einfügen

autoFormatReplacements = { '<!--\\w-->': '<!-- \\w -->' }

Wo liegt der Fehler? ;-) --Seth Cohen 21:55, 16. Nov. 2012 (CET)

Ups, heute ist wohl nicht mein Tag. So was wie [A-Za-z0-9\s]* (zzgl. weiterer Zeichen) ist ja nicht möglich. Also muss ich mehrere Regeln erstellen?

autoFormatReplacements = { '<!--\\w': '<!-- \\w', '<!--\\d': '<!-- \\d', '\\w-->': '\\w -->', '\\d-->': '\\d -->', '.-->': '. -->', '!-->': '! -->', '?-->': '? -->' } etc.

--Seth Cohen 22:30, 16. Nov. 2012 (CET)

Wenn es sein muss dann so, ja. Das ist eine ganz gute Idee. Aber ob das überhaupt sinnvoll ist? Sollte man sich nicht eher bemühen, den Grund herauszufinden, warum solche Kommentare in einem Artikel gelandet sind und die Ursache beheben, anstatt an solchen temporären Syntaxelementen herum zu doktern? Auf der anderen Seite erscheint mir das so eindeutig, dass ich überlege, das sinngemäß zu übernehmen. Hm, … --TMg 16:34, 19. Nov. 2012 (CET)

Doch, sollte man, da hast du schon recht. Aber nicht immer ist das so leicht. Ja, bitte übernehmen, das wäre toll. :-) --Seth Cohen 22:55, 19. Nov. 2012 (CET)

Frage dazu: Sind dir bei deiner Arbeit Artikel begegnet, in denen deutlich mehr als nur ein oder zwei HTML-Kommentare standen? Dutzende? Hunderte? --TMg 11:38, 30. Nov. 2012 (CET)

Nein, ich würde sagen, nicht mehr als ein Dutzend. --Seth Cohen 13:28, 30. Nov. 2012 (CET)

Tut mir leid, aber ich habe mich (auch nach Durchsicht einiger älterer Ideensammlungen) gegen reine Leerzeichenänderungen wie diese entschieden. Mir sind gut lesbare Versionsvergleiche sehr wichtig. Die werden zwangsläufig verwässert. Dazu muss der Vorteil größer sein, als einfach nur den Quelltext etwas hübscher zu machen. Wer mag, kann das benutzerdefiniert machen. Die Dokumentation dazu muss ich für das neue \\w ohnehin erweitern.

Wie sollte die benutzerdefinierte Regel am besten aussehen? --Seth Cohen 16:12, 13. Dez. 2012 (CET)

In der einfachen Syntax genau so, wie oben. Daran ist nichts zu verbessern. Für die erweiterte Syntax habe ich ein Beispiel in die Doku eingefügt. --TMg 21:09, 13. Dez. 2012 (CET)

Danke sehr! --Seth Cohen 01:13, 16. Dez. 2012 (CET)

Mehrere Ersetzungen innerhalb eines Wortes

Beispiel: Damit „La'i'os“ zu „La’i’os“ wird, muss das Skript zweimal ausgeführt werden. --Seth Cohen 23:40, 20. Nov. 2012 (CET)

Ja, das ist ein ganz normales Verhalten der Regex-Engine. Auch in meinen Standardregeln gibt es einige mit dieser Einschränkung (hier zum Ausprobieren: "a" "b"). Es gibt Möglichkeiten, dieses Verhalten zu vermeiden, idealerweise durch Look-aheads, notfalls durch Schleifen. Ersteres werde ich mal probieren. --TMg 15:21, 21. Nov. 2012 (CET)

Und erledigt. Auch das mit den Anführungszeichen klappt jetzt. Den Code kapiert jetzt zwar keiner mehr, aber ich find’s cool. ;-) Vielen Dank für die Anregung. --TMg 16:03, 21. Nov. 2012 (CET)

Und ich erst. Herzlichen Dank! :-) --Seth Cohen 17:18, 21. Nov. 2012 (CET)

Milchstraße

Vorhin wollte das Skript im Artikel Milchstraße aus

{{Panorama|ESO - Milky Way.jpg|800|Fotomosaik des gesamten Milchstraßenbandes}}

ein

{{Panorama|ESO – Milky Way.jpg|800|Fotomosaik des gesamten Milchstraßenbandes}}

machen. Dadurch findet die Vorlage Panorama aber das Bild nicht mehr und zeigt nichts an. --jed (Diskussion) 08:24, 23. Nov. 2012 (CET)

Vielen Dank für die Meldung. Ich habe eine Idee im Kopf, wie das gelöst werden könnte, ohne die ansonsten ja nützliche Gedankenstrich-Regel ganz zu deaktivieren (grob: /\|\s*([^<>[\]{|}]*\.(?:gif|jpe?g|png|svg)\b)/i). Aber der Aufwand erschien mir bisher nicht gerechtfertigt. Im Moment bitte ich darum, per „Änderungen zeigen“ auf solche Fälle Acht zu geben und sie ggf. rückgängig zu machen, bevor man speichert. --TMg 12:02, 23. Nov. 2012 (CET)

OK. --jed (Diskussion) 15:00, 23. Nov. 2012 (CET)

Die Änderung ist relativ komplex und deshalb vorerst nur in der Betaversion drin. --TMg 17:08, 26. Nov. 2012 (CET)

Infobox Bild Bug

Hallo, seit neustem wird in der Infobox Film der Parameter Bild mit „FILE0“ ersetzt. liegt wahrscheinlich an dem neuen Milchstraßendings. --CENNOXX 02:34, 27. Nov. 2012 (CET)

Ich kann es nicht nachvollziehen. Hast du ein konkretes Beispiel? --TMg 11:40, 27. Nov. 2012 (CET)

Zum Beispiel bei Arthur (Film) wird | Bild = Arthur-Logo.svg zu | Bild = FILE0. Wenn ich nur bis zum Ende der Bildparameter-Zeile markiere, wird das ganze nicht verändert, erst wenn ich den nächsten „|“-Strich markiert habe.--CENNOXX 20:16, 27. Nov. 2012 (CET)

Ah, hab mal meine eigenen autoFormatReplacements rausgenommen. Es lag an '  ': ' ' (um doppelte Leerzeichen zu entfernen). Ich wende autoFormatter auf Infoboxen eh nicht an, deshalb wohl erstmal nicht so wichtig. --CENNOXX 20:17, 27. Nov. 2012 (CET)

Danke. Mir war bewusst, dass solche Fälle auftreten können, aber dass das praktisch augenblicklich passiert, ist bemerkenswert. ;-) Eine einfache Lösung wäre, die benutzerdefinierten Ersetzungen erst auszuführen, wenn die Dateinamen schon wieder restauriert sind. Aber das könnte wieder Dateinamen kaputt machen, was ja gerade verhindert werden soll. Interessant ist, dass deine beiden problematischsten Regeln welche sind, über die ich mir schon sehr oft Gedanken gemacht habe und die ich bis jetzt immer ganz bewusst nicht eingebaut habe:

1. Leerzeichen nach Aufzählungszeichen (*, # und evtl. weitere). Deine vereinfachte Regel hat das Problem, dass sie bei *** etwas Ungewolltes bewirkt.
2. Mehrfache Leerzeichen im Text. Die sind vor allem in Infoboxvorlagen und Tabellen Absicht. Das zerstörst du, wenn du nicht aufpasst.

In beiden Fällen vertrete ich den Standpunkt, dass es a) keinen klaren Konsens gibt, wann das erwünscht ist und wann nicht, und es b) den Artikel nicht besser macht. Die Nachteile (unübersichtliche Diff-Ansicht, möglicherweise unsinnige Edits die nur daraus bestehen) überwiegen meiner Meinung nach den einen kleinen Vorteil, dass der Quelltext etwas hübscher aussieht. Die vielleicht beste Lösung, die ich dir anbieten kann, schwebt mir sowieso schon länger vor: Ich will in den benutzerdefinierten Ersetzungen optional auch echte reguläre Ausdrücke erlauben. --TMg 15:07, 28. Nov. 2012 (CET)

@CennoxX: Hier mein Vorschlag für ein paar deiner wie gesagt etwas problematischen Ersetzungsregeln. Ich habe versucht, es einfach zu halten und bewusst keine Look-aheads ((?=…)) benutzt, obwohl das besser wäre.

var autoFormatReplacements = [
    ['TV-Serie', 'Fernsehserie'],
    [/ +<ref\b/g, '<ref'],              //keine Leerzeichen vor Einzelnachweisen
    [/^([*#]+) *([^*#:;])/gm, '$1 $2'], //Leerzeichen hinter Aufzählungszeichen am Zeilenanfang
    [/([^\s=|] ) +([^\s=|])/g, '$1$2'], //mehrfache Leerzeichen kürzen, außer in Vorlagen und Tabellen
    ['...', '…']
];

Den Rest sinngemäß. Deine Commons-Regeln ließen sich auch zusammen fassen, aber die komplizierter wirkenden habe ich ehrlich gesagt nicht verstanden. Was bewirkt das Substen da? --TMg 16:38, 28. Nov. 2012 (CET)

Müssten die Ersetzungsregeln insgesamt nicht von geschweiften anstatt von eckigen Klammern umgeben sein? Und wofür sind die eckigen Klammern um die einzelnen Ersetzungsregeln selbst eigentlich gut? --Seth Cohen 17:19, 28. Nov. 2012 (CET)

Das ist eine neue Schreibweise, die ich noch nicht dokumentiert habe. Die alte geht weiterhin und ich werde sie auch behalten, weil sie einfacher ist. Es war aber nicht möglich, reguläre Ausdrücke zu verwenden. Vor den Doppelpunkten dürfen nur Strings stehen. Bei der neuen Schreibweise gibt es diese Einschränkung nicht, da kann man beides mischen. --TMg 11:11, 29. Nov. 2012 (CET)

Ach so, alles klar, vielen Dank! --Seth Cohen 15:12, 29. Nov. 2012 (CET)

Danke für die angepassten Ersetzungsregeln. Zu den Commonsregeln: Damit leg ich wie in Wikipedia:Textbausteine/Schwesterprojekte empfohlen {{subst:PAGENAME}} als Linkziel fest. Ich weiß aber nicht, wie ich in die vector.js ohne <nowiki> ein {{subst:PAGENAME}} reinkriege deshalb hab ich mir mit der doppelten Ersetzung geholfen.--CENNOXX 18:08, 29. Nov. 2012 (CET)

Ach so, stimmt ja. Dann so: '{{Commonscat|{' + '{subst:PAGENAME}}|S}}'. Ich finde es aber nicht so gut, das automatisiert überall zu ersetzen. Der Seitenname ist sowieso Standard, warum sollte man den nochmal hinschreiben? Die einzige Wirkung, die das hat, ist dass der Link nach einer Verschiebung des Artikels immer noch auf die alte Kategorie zeigt. Darin sehe ich allerdings sogar einen Nachteil. Und warum S? Prüfst du vorher, ob in der Kategorie wirklich keine Videos und Audiodateien sind? Ich würde immer die lange Beschriftung stehen lassen, dann ist die Zeile nicht nur etwas länger und wird besser gesehen, sie ist vor allem einheitlich und schneller wiederzuerkennen und muss nicht geändert werden, falls doch mal jemand ein Video in die Kategorie einfügt. --TMg 20:29, 29. Nov. 2012 (CET)

Naja, wenn der deutsche Artikel verschoben wird, heißt das ja nicht, dass die Commonskategorie auch verschoben wird. Meist ist es eher so, dass ein deutscher Artikel auf ein Klammerlemma verschoben wird. Wenn eine Commonskategorie verschoben wird, muss man diese im Artikel so oder so anpassen. Also für mich ist das plus-minus-0. Könnte man aber vielleicht mal bei Wikipedia:Textbausteine/Schwesterprojekte diskutieren. Zum "S": Ja, ich kontrolliere die Kategorie immer, ob wirklich nur Bilder drinnen sind. Hängt aber auch mit meinem Arbeitsbereich zusammen, ich schreib weniger zu allgemeinen Themen, wo schonmal ein Film o.Ä. dazukommt, sondern zu Film, Fernsehen und Schauspielern, wo es eine echte Ausnahme ist, wenn da mal ein Film/Audio dazukommt.--CENNOXX 21:47, 29. Nov. 2012 (CET)

Man kann da sicher so und so argumentieren. Es ist jedenfalls gängig, in den Artikeln nur kurz {{Commonscat}} zu notieren. Eine Wiederholung des Lemmas halte ich wie gesagt eher für eine Fehlerquelle als für hilfreich. Der Auslöser dieser Meldung hier, das „FILE0“, sollte inzwischen durch mehrere Umstellungen nicht mehr vorkommen. Die erweiterten Ersetzungen sind dokumentiert. --TMg 00:52, 18. Dez. 2012 (CET)

Kleinschreibung von FQDNs

Wie findest du die Idee, bei FQDNs Kleinschreibung zu erzwingen? Beispiel (Zeile 154). --Seth Cohen 17:28, 27. Nov. 2012 (CET)

Ja, definitiv. Ich wusste gar nicht, dass es Benutzer gibt, die das anders schreiben. --TMg 17:52, 27. Nov. 2012 (CET)

Das heißt, du baust es ein? --Seth Cohen 23:19, 27. Nov. 2012 (CET)

Ja, klar. Auf jeden Fall, wenn es das Aussehen des Artikels nicht verändert. Vielleicht sogar bei unbeschrifteten Weblinks. Da bin ich mir nicht ganz sicher, denke aber, dass das in Ordnung geht. Außerdem ist das eine gute Idee für meinen neuen Weblink-Checker. --TMg 14:16, 28. Nov. 2012 (CET)

Super! Ich glaube auch, dass es selbst bei unbeschrifteten Weblinks in Ordnung geht. Deinen neuen Weblink-Checker werde ich sofort einbauen. :-) --Seth Cohen 15:21, 28. Nov. 2012 (CET)

Skript streikt

Das Skript funktioniert auf einmal nicht mehr. Es passiert nichts, wenn ich auf das Icon klicke. --Seth Cohen 19:29, 28. Nov. 2012 (CET)

Nicht genug getestet. Jetzt geht es wieder. --TMg 11:20, 29. Nov. 2012 (CET)

Prima, danke! --Seth Cohen 15:13, 29. Nov. 2012 (CET)

Leerzeichen vor Prozentzeichen in Style-Angaben

Schau mal, was dein Skript hier macht. --Seth Cohen 15:20, 29. Nov. 2012 (CET)

Wer fügt denn so was (<span style=font-size:90%>) in Artikel ein? Das hat da gleich aus aus einer ganzen Menge Gründe nichts zu suchen. Meine %-Regel habe ich unabhängig davon entschärft. Auch da gilt wieder, dass ich sie von „überall ersetzen, außer vor bestimmten Zeichen“ auf „nur vor bestimmten Zeichen ersetzen“ umbauen sollte. Mal überlegen, was kann nach einem „100 %“ folgen? Leerraum, !'),./:;?]|}“. Was ich aktuell ausschließe: "%;>}. Also bleibt sogar nur Leerraum und !'),./:?]|“ übrig. Hinweis für mich: Die Regel sollte nach der Anführungszeichenersetzung folgen. --TMg 19:45, 29. Nov. 2012 (CET)

Leif Czerny (Versionsunterschied). --Seth Cohen 22:18, 29. Nov. 2012 (CET)

Das war als rhetorische Frage gemeint. ;-) So lange unsere MediaWiki-Software das im Artikelnamensraum nicht verbietet, wird es immer Benutzer geben, die so etwas einfügen. Leider versagt bei der Säuberung solcher unschönen Code-Konstrukte jedes Skript. --TMg 11:34, 30. Nov. 2012 (CET)

Und mein Beitrag als rhetorische Antwort. ;-) --Seth Cohen 13:20, 30. Nov. 2012 (CET)

Viertelgeviertstrich → Halbgeviertstrich

Hallo TMg, im Artikel Ludwig Demling werden entsprechende Änderungen im letzten Abschnitt zu den Schriften nicht vorgenommen. Warum? Grüße, --Polarlys (Diskussion) 21:46, 6. Dez. 2012 (CET)

Bitte etwas genauer. Ich vermute, du meinst die Seitenzahlen, die dort übrigens uneinheitlich mal mit „S.“ und mal ohne geschrieben sind. Das unterstütze ich aktuell noch nicht (schon diskutiert, siehe oben). Ich unterstütze aktuell nur Gedankenstriche (mit Leerzeichen davor und dahinter) sowie Jahreszahlenbereiche, überlege aber, das auszuweiten (siehe auch obige Ideensammlung). Das möchte ich nur sehr vorsichtig tun, da es viele Fälle gibt, in denen Bindestriche zwischen Zahlen nicht angetastet werden dürfen. ISBN sind ein naheliegendes Beispiel dafür, es gibt aber noch mehr. Also konkret: Ja, „S. 94-105“ (mit verschiedenen Schreibweisen für die „Seite“) werde ich einbauen, aber keine generelle Ersetzung von Bindestrichen. --TMg 14:56, 7. Dez. 2012 (CET)

Fehlende Ersetzungen

Schau mal hier. Das Wort framed wird nicht ersetzt und [[Sepia_(Farbstoff) | Sepia]] wird nicht zu [[Sepia (Farbstoff)|Sepia]]. --Seth Cohen 19:18, 16. Dez. 2012 (CET)

Das ist kein Einzelfall, der Unterstrich wird in Wiki-Links generell nicht mehr ersetzt.--CENNOXX 19:34, 16. Dez. 2012 (CET)

Es geht ja nicht nur um den Unterstrich. Aber wieso das denn? --Seth Cohen 19:37, 16. Dez. 2012 (CET)

Gibt es eigentlich eine Alternative zu <div style="clear:left"/> --Seth Cohen 19:37, 16. Dez. 2012 (CET)

Ein gutes Beispiel, danke. framed hatte ich nie aufgenommen, werde das aber nachholen. Das mit den Unterstrichen fehlt auch noch und wird ebenfalls kommen. Das mit dem clear ist korrekt so. Es gibt noch andere Schreibweisen, etwa <br style="clear:both;" />, aber von denen ist abzuraten. Siehe Vorlage:Absatz-L. --TMg 19:53, 16. Dez. 2012 (CET)

Unterstriche wurden doch sonst aber ersetzt!? Danke sehr. --Seth Cohen 20:34, 16. Dez. 2012 (CET)

Nein, bisher nur in #Ankerlinks. --TMg 21:16, 16. Dez. 2012 (CET)

Ernsthaft? Hatte auch gedacht, dass das mal ging.--CENNOXX

Ihr werdet das nicht mehr überprüfen können, weil Unterstriche und %-Kodierungen seit heute endlich überall ersetzt werden. ;-) Bei den Leerzeichen habe ich noch das Problem, dass sie durchaus eine Bedeutung haben können (Beispiel: A[[ B ]]C) und ich sie deshalb nicht pauschal entfernen kann. --TMg 01:01, 18. Dez. 2012 (CET)

Klasse, vielen Dank! --Seth Cohen 20:04, 18. Dez. 2012 (CET)

Indexierung dieser Seite

Magst du diese Seite nicht von Suchmaschinen indizieren lassen? --Seth Cohen 19:19, 16. Dez. 2012 (CET)

Ich versuche es, aber es scheint fast so, als würde Google pauschal alles ignorieren, was auf „.js“ endet. --TMg 19:45, 16. Dez. 2012 (CET)

Ach so. --Seth Cohen 19:51, 16. Dez. 2012 (CET)

Ich habe Dokumentation und Diskussion mal verschoben. --TMg 21:10, 16. Dez. 2012 (CET)

Prima, jetzt klappt die Indexierung. --Seth Cohen 20:06, 18. Dez. 2012 (CET)

Beta

„Die Entwicklungsversion mit den jeweils neusten Änderungen ist auf der Unterseite /Beta.js zu finden. Zu dieser Version gibt es auch einen Softwaretest.“

Hier ist nicht ganz eindeutig, ob mit „dieser Version“ die Beta-Version gemeint ist oder die Version der aktuellen Seite. --Seth Cohen 19:21, 16. Dez. 2012 (CET)

Ist doch eigentlich auch egal, oder? Der Test umfasst auch die aktuelle Version. --TMg 19:47, 16. Dez. 2012 (CET)

Dann schon. --Seth Cohen 19:48, 16. Dez. 2012 (CET)

Leerzeilen in Infoboxen

Wäre die Entfernung von Leerzeilen in Infoboxen nichts für dein Skript? Hier ein Beispiel. --Seth Cohen 19:48, 16. Dez. 2012 (CET)

Grundgütiger, was ist das für eine Vorlage? Zum Glück nicht oft verwendet. Ich arbeite zur Zeit an einem Modul zur Säuberung von Infobox-Vorlagen. Wenn man das verwendet, fliegen Leerzeilen automatisch raus. Allerdings nicht pauschal aus allen Vorlagen sondern nur aus denen, für die man eine benutzerdefinierte Formatierungsregel hinterlegt hat. Pauschal ist mir das einerseits den Aufwand nicht wert, andererseits zu gefährlich. --TMg 20:03, 16. Dez. 2012 (CET)

Zu gefährlich? Sind doch nur Leerzeilen. --Seth Cohen 20:39, 16. Dez. 2012 (CET)

Das Stichwort lautet wieder Kontextsensitivität. Um solche Leerzeilen zu finden, muss das Skript nicht nur Vorlagen allgemein erkennen sondern auch verschachtelte Vorlagen und solche verrückten Konstruktionen wie in deiner Fundstelle beachten. Das ist mit sehr viel Aufwand verbunden, der mir nicht gerechtfertigt erscheint, und eine Garantie, dass es nicht zu Fehlersetzungen kommen wird, gibt es dann trotzdem nicht. Ich lass die Meldung aber mal offen und versuche, wenigstens eindeutige Fälle aufzunehmen. --TMg 21:15, 16. Dez. 2012 (CET)

Danke für die Erklärung und die Aufnahme eindeutiger Fälle. --Seth Cohen 20:01, 18. Dez. 2012 (CET)

Zur Dokumentation: Entfernt werden nur Leerzeilen am Ende von Parametern und auch nur in der Infoboxsyntax mit den senkrechten Strichen am Zeilenanfang. Sobald irgend eine Untervorlage oder ein Element mit spitzen Klammern auftaucht, bricht die Säuberung an der Stelle aus Sicherheits- und Performancegründen ab. Einzige erlaubte Ausnahme ist aktuell das <br />. --TMg 16:00, 20. Dez. 2012 (CET)

Interlanguage-Link

Schau mal hier. --Seth Cohen 22:40, 19. Dez. 2012 (CET)

Ein unsichtbares Leerzeichen (U+200B). Die entferne ich seit einer Weile pauschal. Sollte das in dieser Sprache tatsächlich Absicht sein? Denkbar wäre es. Wie kriegt man das raus? Dann müsste ich es durch ​ oder %E2%80%8B ersetzen (und das aus der Dekodierung ausnehmen). --TMg 23:59, 19. Dez. 2012 (CET)

Sind das wieder rhetorische Fragen? Ich weiß es jedenfalls nicht. ;-) --Seth Cohen 15:19, 20. Dez. 2012 (CET)

Sag bloß du kannst kein Tibetisch ;) CENNOXX 15:30, 20. Dez. 2012 (CET)

Schon ernst gemeinte, aber eher allgemein an die Runde gerichtete Fragen. ;-) Die Antwort ist auch gar nicht wichtig, weil dieses eine Beispiel schon ausreicht, um zu sehen, dass so etwas tatsächlich vorkommt. Nebenan ist das schon bekannt, daran sollte ich mich wohl orientieren, auch wenn mir das mit der %-Maskierung besser gefallen würde. --TMg 16:12, 20. Dez. 2012 (CET)

Du hast es ja schon behoben. Danke sehr! --Seth Cohen 21:44, 21. Dez. 2012 (CET)

Ich habe die Regel erst einmal nur rausgeworfen, damit sie keine weiteren Fehler verursacht. --TMg 00:44, 22. Dez. 2012 (CET)

Ach so. --Seth Cohen 21:09, 23. Dez. 2012 (CET)

Ich habe eine neue Regel eingeführt, die das unsichtbare Leerzeichen entfernt, wenn danach ein Zeichen aus einem lateinischen Unicode-Block folgt (U+0000 bis U+024F). Ich gehe davon aus, dass ein unsichtbarer Worttrenner, der (anders als das weiche Trennzeichen) keinen Trennstrich erzeugt, in diesen Schriftsystemen niemals Sinn ergibt. --TMg 01:14, 3. Jan. 2013 (CET)

Danke sehr. --Seth Cohen 00:37, 4. Jan. 2013 (CET)

Kategorien

Was ist denn hiervon ([[Kategorie:Google|SketchUp]]) zu halten? --Seth Cohen 22:37, 1. Jan. 2013 (CET)

Das ist ein Sortierschlüssel für die Kategorie, aber der ist vollständig wirkungslos, weil er nur das Lemma wiederholt. Der Klammerzusatz hat in dem Fall keine Wirkung, weil in dieser Kategorie weder mit noch ohne Klammerzusatz etwas mehrdeutig ist. So gesehen bin ich mir recht sicher, dass das Unfug ist und weg kann. Automatisieren? Hm. Ist das nur ein Zufallsfund oder hast du genau das schon mehrfach gesehen? --TMg 00:32, 2. Jan. 2013 (CET)

Danke für deine Antwort. Ohne dir auf Anhieb konkrete Beispiele nennen zu können, meine ich, dass mir so etwas schon öfter untergekommen ist. Übrigens, ich wünsche dir ein frohes neues Jahr! --Seth Cohen 18:54, 2. Jan. 2013 (CET)

Ich habe eine Regel eingeführt, die Sortierschlüssel entfernt, wenn sie identisch mit dem Lemma sind (ohne Berücksichtigung von Groß-/Kleinschreibung, da diese seit einigen Monaten irrelevant ist). Die Sache mit dem Klammerzusatz ist aber sogar in Hilfe:Kategorien beschrieben, das darf ich also nicht entfernen. --TMg 01:12, 4. Jan. 2013 (CET)

Vielen Dank! Was genau meinst du bezüglich des Klammerzusatzes? --Seth Cohen 20:39, 5. Jan. 2013 (CET)

Siehe Hilfe:Kategorien#10. Regel: Klammer-Lemmata. Ich halte das wie oben argumentiert für Unfug, aber dort steht es genau so, wie du es im Artikel SketchUp (Software) vorgefunden hast. --TMg 15:18, 6. Jan. 2013 (CET)

Die Klammerregel wurde schon häufiger diskutiert. Theoretisch müsste man alles, was man irgendwie "hintendranhängen" möchte. Also Artikel, Vornamen (hier wird bisher das Komma verwendet) und Klammerzusätze hinter einem Sonderzeichen anfügen, dass die Software (Ascii-Code? bin Laie) vor allen anderen Buchstaben und Zahlen sortiert. Der Klammerzusatz ist eigentlich nur dann von Belang, wenn sowieso ein Sortierschlüssel nötig ist und wenn mehrere gleiche Lemmata (ohne Klammerzusatz) in einer Kategorie vorkommen. Bisher wird hier uneinheitlich gehandelt. Ein Beispiel: Die Filmkats sind sehr voll, zudem kommen häufig gleiche Lemmata vor. Les Misérables als Beispiel. Meiner Meinung nach sollte der Sortierschlüssel hier Sortierung:Miserables #Les #1998 (bzw. 1995/2012). Der Artikel wird sowieso schon abgetrennt, mit einem Klammerzusatz sollte man dies auch machen, sofern ein Sortierschlüssel nötig ist. Im oben genannten Beispiel steht z.B. 1998 vor 1995, was an der nicht einheitlichen Sortierung liegt. Die Klammerregel Nr. 10 ist auch deshalb kursiv gesetzt, weil sie "nicht ausgereift" war/ist und einigen Benutzern auch als unnötig betrachtet wurde, da solche Fehlsortierungen wie im oben genannten Beispiel nur sehr selten vorkommen und sich (angeblich) kaum jemand daran stören würde wenn 1998 vor 1995 steht. Ich persönlich sehe sowas nicht gern und ändere dann hin und wieder den Sortierschlüssel, woraufhin man gern mal Kritik erntet, weil man angeblich nur unwichtige Nulledits tätigt. Daher wünsche ich mir schon lange, dass man die Sortierschlüssel gemäß allen Regeln der Hilfeseite vollautomatisch von einem Bot eintragen lässt. Dann bräuchte man sich nur noch um die Extra-Sortierungen in einzelnen Kats kümmern. Wäre doch sicher möglich. Naja, lange Rede, kurzer Sinn: Klammerzusätze sollten meiner Meinung nach mit in den Sortierschlüssel hinein, sofern sowieso - also im Nichtklammerlemmateil (schönes Wort) - ein Sortierschlüssel nötig ist. Am besten abgetrennt durch eine Raute, so wie es schon bei den Artikeln (der, die, das, ein, the, les usw.) gehandhabt wird. --BlueCücü (Diskussion) 15:41, 6. Jan. 2013 (CET)

Das Artikel einer Sonderregel und einem Sonderzeichen bedürfen, ist klar, weil „Titel Der“ sonst unlogisch einsortiert würde. Deshalb muss irgendein Sonderzeichen dazwischen (wobei das meiner Meinung nach auch „Titel, Der“ sein könnte, aber das ist nicht wichtig). Darum ging es hier aber gar nicht. Schau dir das Beispiel „Moby Dick (19…)“ an. Die Klammer stellt die korrekte Sortierung bereits sicher. „Moby Dick #19…“ wäre sinnfrei, weil das nichts an der Sortierung ändert. Die Klammer wegzulassen, so wie es jetzt in Regel 10 steht, wäre sogar destruktiv, weil es die Sortierung zerstört. Dein Beispiel sollte meiner Meinung nach schlicht „Miserables (19…) #Les“ lauten, das heißt der Klammerzusatz bleibt vollständig unangetastet. --TMg 16:24, 6. Jan. 2013 (CET)

1.) Bei dem Moby-Dick-Beispiel bin ich deiner Meinung. Hier ist kein Sortierschlüssel nötig.

2.) Bei "Titel, Der" bin anderer Meinung, da Leerzeichen vor Komma sortiert werden. Beispiel: "Sortierung:Akte Odessa, Die" käme vor "Sortierung:Akte, Die" was falsch wäre. Mit Raute kommt "Sortierung:Akte #Die" vor "Sortierung:Akte Odessa #Die", da die Raute vor dem O sortiert wird. (Einige Sonderzeichen werden immer vor Buchstaben sortiert wie z.B. die Raute, andere hinter den Buchstaben. Hat glaub ich was mit der ASCII-Zeichen-Rangfolge zu tun, aber ich weiß es nicht genau.)

3.a) Zu „Miserables (1992) #Les“: So einfach ist es leider nicht. Was wenn ein Artikel zum Film "The Miserables" aus dem Jahr 1970 angelegt wird (fiktives Beispiel)? Dann würde "Sortierung:Miserables (1970) #The" vor "Sortierung (1992) #Les" einsortiert werden, da 70 vor 92 kommt. Allerdings sollte hier erst nach dem Artikel sortiert werden.

3.b) Oder was wäre wenn ein Artikel "Les Miserables de Paris" angelegt wird. Wird dann die Klammer auf vor oder nach d einsortiert? Falls letzteres dann käme "Sortierung:Miserables de Paris #Les" vor "Sortierung:Miserables (1992) #Les". Hier handelt es sich um 3 Sortiereinheiten, die unabhängig voneinander sortiert werden müssen --> "Sortierung:Lemma #Artikel #Klammerzusatz". --BlueCücü (Diskussion) 16:53, 6. Jan. 2013 (CET)

2.) Es war naheliegend, dass das mit der Raute einen Grund hat. Akzeptiert.

3.a) Na und? Dann werden die Filme eben nach dem Jahr sortiert. Das ist doch gut nachvollziehbar.

3.b) Die Klammer spielt in der selben Liga wie die Raute, beide werden vor die Buchstaben sortiert. Mein Hauptargument ist, dass der Verzicht auf eine extra „Klammerregel“ die Richtlinien eindeutiger, leichter verständlich, leichter benutzbar und damit letztlich weniger fehleranfällig macht. „Falsch“ ist die Sortierung nicht, nur minimal „anders“. Wichtig ist, dass es einheitlich und für jedermann leicht nachvollziehbar ist. Das wäre meiner Meinung nach gegeben. --TMg 17:26, 6. Jan. 2013 (CET)

3.a/b) Okay, überzeugt.

Wäre es denn theoretisch möglich den Sortierschlüssel mit dem AutoFormatter prüfen und ggf. korrigieren zu lassen? Habe keinen nennenswerten Programmierkenntnisse, daher kann ichs nicht abschätzen.

Personen: Für Personenartikel könnte man ja definieren, dass er den Sortierschlüssel einfach aus den Personendaten übernimmt (Zeichenfolge hinter NAME=) und dann noch die Sonderzeichen korrigiert (ä zu a usw.) bzw. entfernt (Bindestriche). (, ) könnte durch ( #) ersetzt werden, auch bei Personen. Müsste aber vorher diskutiert werden.

Artikel: Für die Artikel müsste man programmieren: Prüfe erstes Wort im Lemma. Falls erstes Wort = Artikel (der, die, das, the, les, la, l', une, a, ein, eine, des usw.) dann setze dies Wort nach hinten hinter eine Raute. Es sei denn der Artikel gehört zur Kategorie:Begriffsklärung.

Zahlen: Beginnt ein Artikel mit Ziffern, so füge #::: hinzu wo bei die Anzahl der : gleich der Anzahl der Ziffern ist. Hier gibts kleine Hürden, z.B. "10.000 Meilen unter dem Meer": Liest das Programm da 10 oder 10000? oder "007": Lässt das Programm führende Nullen weg oder nicht?

Alles in allem wäre so etwas eine enorme Hilfe, denn in manchen Kategorien siehts immer noch aus wie Kraut und Rüben. Die Sortier-Regeln der Hilfeseite hatte ich vor einigen Jahrn übrigens mal überarbeitet und auch die Beispiel-Tabelle eingefügt. Mein Beweggrund war, dass es in den Filmkategorien recht bunt zuging. Mittlerweile siehts schon etwas besser aus. Aber bevor Sortierschlüssel nicht vollautomatisch per Bot oder halbautomatisch per z.B. AutoFormatter geprüft werden, wirds wohl immer etwas unordentlich bleiben. Dann bräuchte man sich nur noch um Ausnahmen zu kümmern. Diese Ausnahmesortierschlüssel könnte man dann ja für den Bot/das Script markieren, z.B. <botstop>{{SORTIERUNG:XYZ}} <!--Hinweis:Dieser Sortierschlüssel entspricht wissentlich nicht den automatischen Sortierregeln von [[Hilfe:Kategorien]], Änderungen bitte vorher im Portal:XYZ diskutieren---></botstop> oder ähnlich. Dann müsste man sich wirklich nur noch um absolute Ausnahmen kümmern, die einfach nicht programmierbar sind. Also falls das irgendwann in naher oder mittlerer Zukunft möglich sein sollte, lass es mich wissen. --BlueCücü (Diskussion) 18:01, 6. Jan. 2013 (CET)

Zu deinem Bearbeitungskommentar: "Regel wieder raus, weil das Absicht sein kann, wenn es eine vom Lemma abweichende Standard-SORTIERUNG gibt". Woher hast du das? Die Standard-Sortierung darf sich eigentlich ausschließlich nach dem Lemma richten. Für alles andere sind die extra-Sortierungen (also Kategorie:Lemma|XYZ) da. Wenn die Standard-Sortierung also exakt gleich ist, dann ist sie nicht nötig und könnte raus. --BlueCücü (Diskussion) 10:23, 7. Jan. 2013 (CET)

Beispiel: Ein Artikel heißt „Stausee Musterstadt“. Dieser soll in allen Kategorien per „Musterstadt“ einsortiert werden, deshalb wird ein Standardsortierschlüssel gesetzt. Das vereinfacht den Quelltext, da man diesen vom Lemma abweichenden Sortierschlüssel dann nicht mehrfach wiederholen muss. Nur für die „Kategorie:Musterstadt“ soll ausnahmsweise doch das ursprüngliche Lemma zur Sortierung genutzt werden, deshalb wird es dort wiederholt. Anders formuliert: Die Regel müsste einen evtl. vorhandenen Standardsortierschlüssel berücksichtigen. --TMg 15:01, 7. Jan. 2013 (CET)

Wenn dein Beispielartikel „Stausee Musterstadt“ 4 Kategorien hätte. In 3 soll nach M wie Musterstadt und in einem nach S wie Stausee sortiert werden. Dann wäre der Standard-Sortierschlüssel trotzdem Sortierung:Stausee Musterstadt oder in diesem Beispiel eben kein Standard-Sortierschlüssel nötig, weil mit dem Lemma identisch. Für die 3 anderen Kategorien müsste dann der Extrasortierschlüssel Kategorie:XYZ|Musterstadt verwendet werden. Hier gehts meines Wissens nicht nach Häufigkeit, denn diese kann sich mit neu hinzukommenden Kats ja jederzeit wieder ändern. Hin und wieder gibts auch einen Standard-Sortierschlüssel, da Sonderzeichen vorhanden und trotzdem für jede Kat einen Extra-Sortierschlüssel, weil dort anders sortiert wird. Hier ist der Standardsortierschlüssel dann nur für eventuell noch hinzukommende Kats wichtig. So kenn ich es zumindest. --BlueCücü (Diskussion) 21:23, 7. Jan. 2013 (CET)

Ja, so würde ich das auch bevorzugen und empfehlen. Aber manchmal ist es einfach schon so, wie ich es beschrieben habe. Das darf mein Skript nicht kaputt machen. Allgemein möchte ich an solchen Sortierspezialitäten nur ungern automatisiert Änderungen vornehmen, weil das schlimmstenfalls etwas kaputt macht und bestenfalls nichts bewirkt. Ich erweitere das Skript gern, wenn die Ersetzung eine Wirkung hat, sie idealerweise nicht durch die seit langem geplante Umstellung des Sortieralgorithmus hinfällig wird und wenn ein eindeutiger Konsens dazu besteht, beispielsweise für die Korrektur von {{SORTIERUNG:Film, Der}} zu {{SORTIERUNG:Film #Der}}. --TMg 21:28, 22. Jan. 2013 (CET)

Werde demnächst mal die Regeln unter Hilfe:Kategorien auf Aktualität prüfen und ggf. Uneinigkeiten auf der Disk. ansprechen. Danach kann man dann schauen, welche häufig vorkommenden Fehler in Sortierschlüsseln per Script korrigiert werden könnten. --BlueCücü (Diskussion) 21:45, 22. Jan. 2013 (CET)

Geschützte Leerzeichen zwischen Tag und Monat beim Datum?

Hallo TMg, zunächst einmal ein großes Lob an Dich für dieses Skript! Eine Frage hätte ich aber noch: Ist es irgendwie machbar, dass der autoFormatter geschützte Leerzeichen auch zwischen Tag und Monat beim Datum setzt; also etwa 6. Januar in 6. Januar korrigiert? Gruß --Cherryx ^sprich! 16:48, 6. Jan. 2013 (CET)

Es scheint sich von selbst zu klären; Benutzerdefinierte Ersetzungen. Ich schaue mal, ob ich es damit hinbekomme. :-) Gruß --Cherryx ^sprich! 16:54, 6. Jan. 2013 (CET)

Machbar ist alles, aber speziell das möchte ich ungern allen Benutzern aufzwingen. Der Artikelquelltext wird durch die vielen   (zu den Daten kommen noch Gedankenstriche, die bekannten Abkürzungen, Maßeinheiten und vieles mehr) sehr schnell schrecklich unleserlich. Manche Benutzer stören sich sehr daran und ich muss mich bemühen, einen ausgewogenen Mittelweg zu finden. Und da vertrete ich die Meinung, dass ein umgebrochener „6.
Januar“ viel weniger tragisch ist als ein zerrissenes „z.
B.“ oder zerrissene „1000
m“ (anders gesagt sind es die kurzen Wörter am Zeilenanfang, die ich als störend empfinde). Außerdem gibt es schon seit längerem Bemühungen, solche Stellen automatisch zu schützen, so wie das aktuell schon bei „100 %“ passiert. Als benutzerdefinierte Regel (sprich, wenn du es vertreten kannst, das bei allen deinen Edits immer mit zu ändern) ist das aber gar kein Problem: '\\d. Januar': '\\d. Januar' (und entsprechend für alle Monate). --TMg 17:12, 6. Jan. 2013 (CET)

Danke Dir – ich habe aber doch noch eine Frage. Ist es auch möglich, gleichzeitig zu definieren, dass das Datum nicht geändert werden soll, wenn vor dem Tag ein Gleichheitszeichen (=) steht (etwa bei PND)? Gruß --Cherryx ^sprich! 23:51, 6. Jan. 2013 (CET)

Das geht nur mit der erweiterten Syntax. Auch würde ich empfehlen, statt mit verbotenen mit erlaubten Zeichen zu arbeiten. Viele meiner Regeln habe ich inzwischen so umgestellt, weil das wesentlich weniger fehleranfällig ist. Im folgenden Beispiel stehen die erlaubten Zeichen vorn in der eckigen Klammer: Vor dem Tag (\d+) muss entweder ein Leerzeichen (\s) oder eine Klammer auf stehen. Weitere Zeichen würde ich da gar nicht ergänzen, da jedes einen Fall andeutet, in dem das geschützte Leerzeichen wahrscheinlich unnötig oder sogar störend wäre. --TMg 06:44, 7. Jan. 2013 (CET)

[/([\s(]\d+\.) (Januar|Februar|März|April|Mai|Ju[nl]i|August|September|Oktober|November|Dezember)\b/g, '$1 $2'],

Leerzeichen nach *

Ist es möglich ins Script aufzunehmen, dass stets nach einem * (wenn es als Aufzählungszeichen am Zeilenanfang verwendet wird) ein Leerzeichen folgt. Dies hat keine tatsächliche Änderung am Artikel zur Folge, allerdings wäre der Quelltext dann übersichtlicher. * plus Leerzeichen und dann Text wird häufiger verwendet als * ohne Leerzeichen mit direkt folgendem Text. Manchmal wird auch beides in Artikeln vermischt und sieht dann unschön aus. --BlueCücü (Diskussion) 21:10, 6. Jan. 2013 (CET)

Möglich ist natürlich alles, aber ich hatte mich in diesem Fall dagegen entschieden (siehe Archiv). Solche Änderungen haben das Potential, die Diff-Ansicht sehr unübersichtlich zu machen. Das minimal hübschere Aussehen des Quelltextes ist mir die Nachteile nicht wert. Aber ich habe in der Dokumentation schon eine benutzerdefinierte Ersetzung für genau diesen Fall, die du benutzen kannst. --TMg 06:51, 7. Jan. 2013 (CET)

Danke für den Hinweis. Habs jetzt bei mir übernommen. Aber hin und wieder funktioniert es nicht. Zum Beispiel hier. Liegt es an den ''-Zeichen? --BlueCücü (Diskussion) 23:22, 7. Jan. 2013 (CET)

So geht das nicht. Der zweite Regelsatz hebelt den ersten wieder aus. Du musst beides in das erweiterte Format mit den verschachtelten eckigen Klammern bringen. Sinngemäß wie folgt. --TMg 23:43, 7. Jan. 2013 (CET)

var autoFormatReplacements = [
  [/^([*#]+) *([^*#:;])/gm, "$1 $2"],
  [", Der}", " #Der}"],
  [", Die}", " #Die}"]
];

Danke. Nach ein wenig Hin- und Hergeschiebe gehts nun. --BlueCücü (Diskussion) 00:14, 8. Jan. 2013 (CET)

Leerzeichen statt Tabulatoren

Wäre das was? --Seth Cohen 23:30, 6. Jan. 2013 (CET)

Die noch nicht dokumentierte Vorlagen-Formatierung säubert solche Tabs automatisch mit (Beispiele für die Verwendung sind in meiner common.js zu sehen). Darüber hinaus möchte ich mit Tabs aus dem selben Grund nichts machen, aus dem ich auch doppelte Leerzeichen unangetastet lasse. Es bringt effektiv nichts, macht nicht einmal den Quelltext besser lesbar, dafür die Diff-Ansicht verwirrend. --TMg 07:16, 7. Jan. 2013 (CET)

Die Vorlagen-Formatierung ist aber noch nicht aktiv, oder? --Seth Cohen 20:23, 7. Jan. 2013 (CET)

Doch. Sie formatiert aber nur Vorlagen, für die man individuell ein Format festgelegt hat. Mein Plan ist, nur in absolut eindeutigen Fällen Vorgaben zu machen (Vorlage:Personendaten, evtl. Vorlage:Normdaten). Gedacht ist die Funktion vor allem für Benutzer in Fachportalen, die „ihre“ Lieblingsinfobox gern überall einheitlich einrücken, umbenannte Vorlagenparameter ersetzen und veraltete entfernen möchten. --TMg 21:03, 7. Jan. 2013 (CET)

Generelle Frage

Ich benutze das Script probehalber seit gestern und habe daher zur Benutzung ein paar Fragen:

• Gibt es eine Möglichkeit die Änderungen zu überprüfen, bevor man sie gespeichert hat. Denn hin und wieder schlich sich doch die ein oder andere Änderung ein, die ich dann wieder repariert habe. (Zum Beispiel wurden die falschen Anführungszeichen auch in Interwikis geändert oder "15. Juli 2012 - 10:00" wurde zu "15. Juli 2012–2010:00".) Sowas führt natürlich immer zu zwei Edits. Mit der einfachen Vorschaufunktion kann ich ja leider nicht die 2 Versionen nebeneinander vergleichen. Oder geht das irgendwie doch?
• Desweiteren ist mir aufgefallen, dass Benutzer CherryX in kürzester Zeit viel Kritik auf seiner/ihrer Disk. geerntet hat, weil er/sie eben nur diese formalen Änderungen macht und dabei Fehler nicht korrigiert und so für einige Verschlimmbesserungen gesorgt hat. Der Ärger der anderen Benutzer ist natürlich zu verstehen. Vielleicht sollte man noch irgendwo gut sichtbar hervorheben, dass das Script nur benutzt werden sollte, wenn man sowieso Änderungen an einem Artikel vornimmt und wenn man es benutzt hat, danach auch immer kritisch den Diff-Link kontrolliert.

Grüße, --BlueCücü (Diskussion) 10:34, 7. Jan. 2013 (CET)

Die Kritik ergibt sich größtenteils jedoch nicht daraus, dass die Änderungen falsch, sondern unerwünscht sind; etwa ein geschütztes Leerzeichen irgendwo am Zeilenanfang, in den PND oder ähnlichem. Das lag vielleicht aber auch an meiner en­thu­si­as­tischen Verwendung des Skriptes. Der erste Punkt würde mich aber auch interessieren; dass man quasi eine Art Diff-Link bekommt, ohne dass ein richtiger erzeugt wurde. --Cherryx ^sprich! 10:40, 7. Jan. 2013 (CET)

• Punkt 1 verstehe ich leider nicht. Du klickst einfach auf „Änderungen zeigen“ und siehst in der dann erscheinenden Diff-Ansicht, was das Skript gemacht hat. Beim Bearbeiten kompletter Artikel gehe ich meist so vor, dass ich zuerst einmal auf das Auto-Format-Symbol und sofort auf „Änderungen zeige“ klicke. Ist da alles in Ordnung, mache ich mit dem weiter, was ich eigentlich am Artikel machen wollte. Sollten sich während meiner Arbeit am Artikel weitere Formatierungswünsche ergeben (meist kopierte Weblinks, die ich einkürzen will), markiere ich nur grob den Absatz, damit der Auto-Formater nur noch dort Änderungen vornimmt.
• So etwas wie das mit der Uhrzeit bitte unbedingt melden, auch wenn es dir nebensächlich vorkommt. Ich bin immer bemüht, die Fehlerquote zu reduzieren und brauche dazu genau solche Fundstellen.
• Zum letzten Punkt: Ja, ich denke, das kann ruhig noch deutlicher aus der Dokumentation hervor gehen. WikiSyntaxTextMod liefert da eine ganz gute Vorlage.

--TMg 15:18, 7. Jan. 2013 (CET)

TMg, du wirst es nicht glauben, aber bevor du die Schaltfläche „Änderungen zeigen“ erwähntest, war sie mir gänzlich unbekannt! Ich wusste gar nicht, dass es sie gibt, aber das scheint genau das zu sein, wonach gesucht wurde. :-) (Verschwörungstheoriemodus an) Vermutlich gab es diese Schaltfläche bis vorhin gar nicht und du hast sie irgendwie durch ein Skript eingefügt. (Verschwörungstheoriemodus aus) Gruß --Cherryx ^sprich! 17:27, 7. Jan. 2013 (CET)

Wer behauptet, dass ihm so was noch nie passiert ist, der lügt. ;-) --TMg 20:32, 7. Jan. 2013 (CET)

Mir gings genauso wie CherryX. Wobei ich mich vielleicht herausreden kann, da ich das Script erst seit einem Tag teste ;) Auch mir war der "Änderungen zeigen" Button bisher nicht aufgefallen. Gelesen hatte ich von dem "Änderungen zeigen" auf der umseitigen Beschreibungen, hatte aber angenommen, es wäre die Vergleichsansicht in der Versionshistorie gemeint. Man gut ich habe nachgefragt. Das macht die ganze Sache doch um einiges leichter. Wahrscheinlich war eine gewisse "Betriebsblindheit" schuld. --BlueCücü (Diskussion) 21:30, 7. Jan. 2013 (CET)

P.S.: Wie schauts denn mit der fälschlichen Korrektur der Anführungszeichen in Interwiki-Links aus (siehe hier). Kann man die verhindern? --BlueCücü (Diskussion) 21:33, 7. Jan. 2013 (CET)

Das mit der Uhrzeit habe ich behoben. Fälschliche Ersetzungen in Interwiki-Links ärgern mich schon länger und erst neulich hatte ich eine gute Idee dazu, muss sie nur einmal konsequent umsetzen. Danke für das Beispiel. --TMg 21:51, 7. Jan. 2013 (CET)

Noch ein Beispiel: Bei diesem en-wpLink wurde aus 2009-10 2009-2010 gemacht. --BlueCücü (Diskussion) 22:22, 7. Jan. 2013 (CET)

Was es nicht alles gibt. Danke. Ich bin wie gesagt für jedes noch so kleine Beispiel dankbar. Zu deinem anderen Punkt: Schaut mal bitte, ob die Einleitung verständlich ist, oder ob sie jetzt zu sehr abschreckt. --TMg 22:25, 7. Jan. 2013 (CET)

Gesichtet und für gut befunden. So findet auch jeder Dussel wie ich gleich die Schaltfläche „Änderungen anzeigen“ ;) --BlueCücü (Diskussion) 00:14, 8. Jan. 2013 (CET)

Alle Wörter groß im Sortierschlüssel

Nach wie vor ersetzt das Script kleingeschriebene Anfangsbuchstaben jedes Wortes durch das großgeschriebene Pendant. Diese Regel kann ja nun deaktiviert werden. (Auf die Gefahr hin, dass diese Info redundant ist.) --BlueCücü (Diskussion) 22:58, 7. Jan. 2013 (CET)

Ich weiß, aber es stört ja auch nicht und sorgt für Einheitlichkeit. Das erinnert mich daran, dass ich jetzt SORTIERUNG- alias DEFAULTSORT-Zeile wegwerfen kann, wenn sie abgesehen von der Groß-/Kleinschreibung identisch zum Lemma ist. Das wäre sowieso Voraussetzung, um das oben Diskutierte nochmal in Angriff zu nehmen. --TMg 00:01, 8. Jan. 2013 (CET)

Aber was nützt die Einheitlichkeit, wenn kein erkennbarer Sinn dahintersteckt. Vor einiger Zeit machte die Großschreibung jedes Wortes noch Sinn, weil nur so sichergestellt war, dass in den Kats richtig sortiert wird. Dies nun beizubehalten nur der Einheitlichkeit wegen macht keinen Sinn. Im Gegenteil: Dann lieber Einheitlichkeit mit dem Lemma in punkto Groß/Kleinschreibung. Das führt zu weniger Konfusion bei (neuen) Benutzern, die mit dem Sortierschlüssel nicht viel anfangen können. Auch andersherum können Großbuchstaben im Wortinner ruhig beibehalten werden, wenns dem Lemma entspricht (Beispiel, momentan würd das Script daraus ein kleines t machen, wichtig ist mittlerweile aber nur noch dass der Bindestrich "verschwindet"). Vielleicht sollte man das generell erstmal unter Hilfe:Kategorien diskutieren. Werd dort vielleicht demnächst mal eine Diskussion anstoßen. --BlueCücü (Diskussion) 00:13, 8. Jan. 2013 (CET)

Ich vertrat damals die Ansicht, dass es besser ist, die alten Regeln so lange beizubehalten, bis der Umbau der Software abgeschlossen ist. Das ist jetzt fast zwei Jahre her. Du bist der Erste, der sich seit dem deswegen meldet. Die Entwickler interessiert es vermutlich nicht, weil die alle Englisch sprechen. Daran, dass die Groß-/Kleinschreibung ignoriert wird, wird sich aber sehr wahrscheinlich nichts mehr ändern. Deshalb nehme ich das jetzt als gegeben hin und habe die Regel entfernt. Konsequenterweise gibt es eine neue Regel, die SORTIERUNG alias DEFAULTSORT entfernt, wenn es abgesehen von der Groß-/Kleinschreibung identisch zum Lemma ist. --TMg 18:59, 10. Jan. 2013 (CET)

Du schreibst, du hättest die Regel entfernt. Es wird allerdings nach wie vor das erste kleingeschriebene Wort im Sorterischlüssel (nur das erste, nicht alle) von klein in groß geändert. Auch werden großgeschriebene Buchstaben im Wortinnern weiterhin in kleine umgewandelt. Oder braucht die Änderung bis zum nächsten Update o.ä. bis sie aktiv wird? --BlueCücü (Diskussion) 14:27, 18. Jan. 2013 (CET)

Ja, genau. Ich habe die Änderung heute in die stabile Version übernommen. Du musst vielleicht noch das mit dem Cache machen. --TMg 22:04, 19. Jan. 2013 (CET)

Vorschlag: Leerzeilen zwischen Sortierung und Kats streichen

Leerzeilen zwischen Sortierung:XYZ und Kategorie:XYZ könnten meiner Meinung nach automatisch gestrichen werden, da es a) in den meisten Fällen eh so gehandhabt wird und b) so ersichtlicher ist, dass sich die Vorlage auf die Kategorien bezieht. --BlueCücü (Diskussion) 00:40, 8. Jan. 2013 (CET)

Leerzeichen in Vorlagen (Tabellen, Infoboxen)

War sicher schonmal Thema aber ich konnte auf die Schnelle nichts dazu finden: Aufgrund dieser Anfrage auf meiner Disk, würd mich interessieren, ob es machbar wäre, dass man Leerzeichen in Vorlagen die nach einem Gleichheitszeichen (=) kommen von der Regel „Entferne überflüssige Leerzeichen am Zeilenende“ ausnehmen könnte. So würden weiterhin Leerzeichen am Zeilenende einer ausgefüllten Tabellen-/Infobox-Zeile entfernt werden, jedoch Leerzeichen in nicht ausgefüllten (also nach dem =) Zeilen bestehen bleiben. Wäre so etwas möglich? (Quasi: Entferne Leerzeichen am Zeilenende nicht, wenn sie nach dem Zeichen = in Textpassagen zwischen {{ und }} stehen.) Liebe Grüße, --BlueCücü (Diskussion) 14:40, 18. Jan. 2013 (CET)

Ich meinte, das schon einmal beantwortet zu haben, aber ich finde es nicht mehr. Ich vertrete die Ansicht, dass Leerzeichen in halb ausgefüllten Infoboxvorlagen mehr Verwirrung stiften als nützen. Sie machen nichts „besser lesbar“, denn dahinter steht ja gar nichts. Man braucht sie nicht, um zu erkennen, wie die Infoboxvorlage formatiert werden soll – das ist viel besser an den bereits ausgefüllten Vorlagenzeilen zu sehen. Daran orientiert man sich. Tut man das nicht, helfen auch die Leerzeichen nicht viel. Sie sind am Zeilenende völlig unsichtbar. Nichts deutet auf ihre Existenz hin, außer man navigiert bewusst mit dem Textcursor dort hin. Ich habe schon oft gesehen, dass auf das vermeintliche Zeilenende geklickt und dort ein Leerzeichen und der Parameterwert eingegeben wurde. Mit dem Ergebnis, dass das eigentlich schon vorhandene Leerzeichen hinter den Parameterwert wandert. Der mehr oder weniger einzige Nutzen der Leerzeichen ist, erfahreneren Autoren ein klein wenig Tipparbeit zu ersparen. Gerade von diesen wird man aber wohl erwarten dürfen, dass sie mal fix auf ihre Leertaste drücken. Deshalb wird es eine solche Ausnahme in meinem Skript nicht geben. Davon ausgenommen sind nur Kopiervorlagen. --TMg 18:00, 21. Jan. 2013 (CET)

In diesem speziellen Fall handelte es sich um eine Vorlage für ein Turnier. Da der Artikel schon fertiggestellt, aber das Turnier noch nicht weit fortgeschritten war, waren eben noch sehr viele Zeilen nicht ausgefüllt (-323 Byte, Diff). Bei weiteren Bearbeitungen hat der Benutzer, der mich ansprach, nun auf das Leerzeichen verzichtet. Solche Fälle - also "frische" Artikel mit weitestgehend unausgefüllten Tabellen - werd ich einfach zukünftig mit mehr Fingerspitzengefühl bearbeiten oder die Autoformat-Funktion einfach (vorerst) nicht benutzen. --BlueCücü (Diskussion) 21:56, 22. Jan. 2013 (CET)

Du kannst den Artikel markieren (Textcursor hinter der Infobox platzieren, Umschalt+Strg+Ende drücken, Auto-Format-Knopf anklicken). Das Skript behandelt dann nur den markierten Teil. Außerdem habe ich das zum Anlass genommen, die (optionale) Vorlagenformatierung um eine trim-Eigenschaft zu erweitern. --TMg 22:25, 22. Jan. 2013 (CET)

Bug entdeckt

Siehe diesen Diff und dann die darauffolgende Änderung, in der ein en-wp-Link repariert wird. Es grüßt, --BlueCücü (Diskussion) 19:30, 24. Jan. 2013 (CET)

Sweet. Vielen lieben Dank für die Meldung. --TMg 21:44, 24. Jan. 2013 (CET)

Simulation von Anführungszeichen durch Kommas

Kann ich ,,solche Sünden" (Diff, Permalink) automatisiert reparieren, ohne dass es zu Fehlersetzungen kommt? --TMg 15:40, 27. Jan. 2013 (CET)

Das wäre super. Kommt auch einzeln vor, ,so‘ zum Beispiel. --Seth Cohen 19:53, 28. Jan. 2013 (CET)

Ist schon erledigt, also für zwei Kommas. Einzeln ist es wesentlich gefährlicher, weil das ja auch einfach nur ein verrutschtes Komma sein kann. --TMg 20:19, 28. Jan. 2013 (CET)

Leerzeichen am Artikelanfang

Beispiel. --Seth Cohen 19:54, 28. Jan. 2013 (CET)

Und wenn man einen neuen Diskussionsabschnitt beginnt, der mit einem einfach eingerückten Quelltext beginnt? Ich denke, am Artikelanfang sieht man so etwas selbst sehr gut, da braucht man keine Skripthilfe. --TMg 20:22, 28. Jan. 2013 (CET)

Vielleicht auf den Artikelnamensraum beschränken? --Seth Cohen 22:09, 30. Jan. 2013 (CET)

Auch da kann das ja vorkommen. Das führt nur zu Fehlersetzungen, spart aber nahezu keine Arbeit ein. --TMg 17:23, 31. Jan. 2013 (CET)

Ein Artikel, der mit einem einfach eingerückten Quelltext beginnt? --Seth Cohen 23:02, 1. Feb. 2013 (CET)

Vielleicht hast du ja Recht, keine Ahnung. Der Punkt ist, dass das nichts ist, was ich als Aufgabe meines Skriptes betrachte. Es soll zeitraubende Routinearbeiten übernehmen. Das ist nicht gegeben, da das so gut wie nie vorkommt, höchstens mal auf einer Diskussionsseite. Es soll komplizierte Korrekturen durchführen, die von Hand kaum möglich sind, wie z. B. die einfachen Anführungszeichen in Zitaten (das war ein super Vorschlag, gern mehr in dieser Art). Auch das ist nicht gegeben, da man Leerraum am Anfang des Bearbeitungsfensters augenblicklich sieht und selbst entfernen kann, wenn er stört. Und wenn er nicht stört, ist die Entfernung sinnlos. --TMg 11:23, 2. Feb. 2013 (CET)

In Ordnung, danke. --Seth Cohen 20:39, 3. Feb. 2013 (CET)

Cite book <-> Literatur

Hallo TMg!

Wäre es möglich die Vorlage cite book automatisch in die deutsche Literatur-Vorlage zu ändern? Im wesentlichen müssen nur einige Parameter übersetzt werden. Leider hat die cite-book-Vorlage einige Parameter (die aber quasi nie benutzt werden) die in der Literatur-Vorlage nicht existieren: origdate, origyear, origmonth, format, chapterurl, quote, authorlink, last, first, coauthors, others ,accessyear, accessmonth, date

Es muss also folgendes

{{Cite book | author= |editor= |title= |url= |accessdate= |edition= |volume=|year= |month= |publisher= |location= |language= |id= |isbn= |doi= |pages= |chapter= }}

nach

{{Literatur | Autor= | Herausgeber= | Titel= | Online= |Zugriff= | Auflage= | Band= | Jahr= | Monat=| Verlag= | Ort= | Originalsprache=| ISSN=| ISBN= | DOI= | Seiten= | Kapitel=}}

übersetzt/ersetzt werden werden.

Da z.B. ein Großteil aller cite-book Vorlagen in de.WP durch dieses Tool erzeugt werden, reicht es wohl sich einzig auf die 1:1 umbiegbaren Parameter zu konzentrieren. Die Parameter die nicht in Literatur existieren können ja einfach stehen bleiben, so dass man händisch sich überlegen kann was man damit tut. Außerdem wäre es vllt. gut dann auch innerhalb dieser Vorlage das englische Datum ins deutsch Datum zu übersetzen. Also „January 13 2013“ nach „13. Januar 2013“ usw. Aber das ist am Anfang nicht so wichtig, da händische Änderung des Datums nicht so aufwändig ist wie „Umbiegen“ der gesamten Vorlage--Svebert (Diskussion) 11:33, 9. Feb. 2013 (CET)

Ich nehme gern auch Regeln in mein Skript auf, die Vorlagen beeinflussen, knüpfe daran aber ganz bestimmte Bedingungen, die ich hier nicht erfüllt sehe. Vor allem werde ich keinesfalls nur „halbe“ Ersetzungen vornehmen, die händisch vervollständigt werden müssen. Wenn du mir eine ganz konkrete Art der Nutzung der Cite-Vorlage nennst (bitte mit einem oder besser mehreren Beispielen und Vorher-/Nachher-Vergleich), die sich eindeutig in die andere umwandeln lässt, schaue ich mir das gern an. Andernfalls denke ich, dass du mit WSTM besser bedient bist. --TMg 22:14, 14. Feb. 2013 (CET)

Vorschlag: Entfernen von Parametern aus den Vorlagen "IMDb Titel" und "IMDb Name"

Wie zum Beispiel hier von mir händisch entfernt können die Filmtitel und Schauspielernamen aus der Vorlage entfernt werden, wenn sie mit dem Lemma identisch sind. Sie hinter der Zahl nach | einzufügen macht eigentlich nur bei Klammerlemmata einen Sinn. Trotzdem werden sie häufig aus Unwissenheit dennoch eingesetzt. --BlueCücü (Diskussion) 00:15, 16. Feb. 2013 (CET)

Das mache ich gern. Aber das betrifft extrem viele Vorlagen, nicht nur Vorlage:IMDb Name (incl. Weiterleitung Vorlage:IMDb name), Vorlage:IMDb Rolle, Vorlage:IMDb Titel und Vorlage:IMDb Unternehmen. Mal schauen, wie ich das löse. Eine äquivalente Säuberung habe ich schon für diverse Infobox-Vorlagen. Ich denke, die sollte ich erweitert, so dass sie mit unbenannten Vorlagenparametern klar kommt. --TMg 22:29, 17. Feb. 2013 (CET)

Funktioniert aber noch nicht. Oder kommt das erst mit dem nächsten Update? --BlueCücü (Diskussion) 19:15, 25. Feb. 2013 (CET)

Wie immer erstmal zum Test in der Betaversion. --TMg 21:19, 25. Feb. 2013 (CET)

Frage: common-Änderungen auf Vorlage Sortierung begrenzen

Ich nochmal, dann nerv ich auch nicht weiter ;) Kann man mit ein paar einfachen Befehlen die Komma-zu-Raute-Änderungen auf meiner common-Seite auf die Sortierungs- bzw. Defaultsort-Vorlage beschränken? Die Frage rührt daher, da die Komma-zu-Raute-Änderungen in Musik-Artikeln auch manchmal in der Discogs-Vorlage gemacht werden, wo sie allerdings nicht sinnvoll sind, da dann das Linkziel verändert wird. --BlueCücü (Diskussion) 00:33, 16. Feb. 2013 (CET)

Im Grunde musst du nur komplette reguläre Ausdrücke aus deinen Regeln machen, also bspw. [/(\{SORTIERUNG:[^{}]+), Der\}/g, "$1 #Der}"],. --TMg 22:35, 17. Feb. 2013 (CET)

Vielen Dank. Werds demnächst mal ausprobieren und mich wieder melden, sollte es noch irgendwo haken. --BlueCücü (Diskussion) 22:41, 17. Feb. 2013 (CET)

Vorschlag: Entfernen von Leerzeile zwischen Einzelnachweise-Überschrift und references

Die überflüssige Leerzeile zwischen der Einzelnachweise-Überschrift und den refrences könnte man doch sicher automatisch entfernen. Beispiel:

== Einzelnachweise ==

<references />

wird dann zu

== Einzelnachweise ==
<references />

Es grüßt mal wieder, --BlueCücü (Diskussion) 01:13, 16. Feb. 2013 (CET)

Leerzeilen nach Überschriften fasse ich ungern an, weil da keine Einigkeit besteht. Den Spezialfall „Überschrift, Leerzeile, <references />, Leerzeile“ halte ich ausnahmsweise mal für unstrittig. --TMg 18:03, 25. Feb. 2013 (CET)

HTML-Entität

Moin TMg, im Artikel Hermann Bolt hat mir der Auto-Formatter gerade mitten in die Kategorien eine HTML-Entität eingebaut. Ich habe es mir dummerweise nicht genau gemerkt und bekomme es gerade auch nicht reproduziert, aber meine es wäre HTML ‎ gewesen. Ich dachte, ich sage einfach mal Bescheid, vielleicht hilft es weiter. --Alex (Diskussion) 15:52, 17. Feb. 2013 (CET)

Danke. Solche Meldungen sind mir immer sehr wichtig. Mein Tool hat das unsichtbare Leserichtungs-Zeichen (‎), das da vorher schon stand, lediglich sichtbar gemacht. In diesem Fall ergab es überhaupt keinen Sinn und kann einfach entfernt werden. Also alles richtig abgelaufen. --TMg 21:54, 17. Feb. 2013 (CET)

Hinweis: – zu bis

Hier wurde in der Tabelle beim drittletzten Herren (Nebojša Radmanović) der Bis-Strich nicht in "bis" umgewandelt. Liegts an den '', die dort folgen? --BlueCücü (Diskussion) 23:18, 17. Feb. 2013 (CET)

Interessanter Sonderfall, aber eindeutig genug, damit ich ihn aufnehmen kann. --TMg 17:58, 25. Feb. 2013 (CET)

Kombination benutzerdefinierter und erweiterter benutzerdefinierter Ersetzungen

Wie ist denn da die korrekte Syntax für? Würdest du mal einen Blick in meine common.js werfen? So funktioniert es nicht. --Seth Cohen 22:59, 24. Feb. 2013 (CET)

Reicht das Beispiel auf der Vorderseite nicht aus? Bitte wandle alle Zeilen, die noch einen Doppelpunkt haben, in die Form ['…', '…'], um. --TMg 17:54, 25. Feb. 2013 (CET)

Beide Schreibweisen lassen sich demnach nicht kombinieren? --Seth Cohen 20:41, 25. Feb. 2013 (CET)

Um die einfachen Regeln in der zweiten Syntaxvariante mit den eckigen Klammern verwenden zu können, musst du sie wie gezeigt umschreiben. --TMg 21:18, 25. Feb. 2013 (CET)

Alles klar, danke. --Seth Cohen 23:47, 25. Feb. 2013 (CET)

Erweiterte benutzerdefinierte Ersetzung

Aus <!-----Kommentar-----> wird <!-- Kommentar--- --> statt <!-- Kommentar -->. --Seth Cohen 21:22, 25. Feb. 2013 (CET)

Danke für den Hinweis. Ich habe die Regel angepasst, siehe Vorderseite. --TMg 18:10, 26. Feb. 2013 (CET)

Danke sehr. --Seth Cohen 00:08, 27. Feb. 2013 (CET)

Erweiterte benutzerdefinierte Ersetzung II

[/^([*#]+) *([^*#:;])/gm, "$1 $2"],

Fügt immer ein Leerzeichen hinter die Aufzählungszeichen * und # am Zeilenanfang ein.

Aus #WEITERLEITUNG bzw. #REDIRECT wird # WEITERLEITUNG bzw. # REDIRECT. Könntest du den Fall ausklammern? --Seth Cohen 23:19, 27. Feb. 2013 (CET)

Das war vergleichsweise einfach zu beheben, siehe Vorderseite. --TMg 23:01, 28. Feb. 2013 (CET)

Danke sehr. --Seth Cohen 23:11, 28. Feb. 2013 (CET)

Vorschlag references

Das doch noch hin und wieder anzutreffende <references></references> könnte automatisch zu <references /> geändert werden. --BlueCücü (Diskussion) 00:08, 2. Mär. 2013 (CET)

Sehr gute Idee, danke. --TMg 12:33, 2. Mär. 2013 (CET)

Vorlage Cite web, url, underline

Beta-Version: Underline im url-Parameter wird hier durch ein Blank ersetzt. --Thoken (Diskussion) 15:29, 7. Mär. 2013 (CET)

Bemerkenswert, vielen Dank. Das Skript hat die URIs mit Commons-Bildern verwechselt. --TMg 16:16, 7. Mär. 2013 (CET)

Weblinks mit senkrechtem Strich

Habe eine kleine Fehlkorrektur gefunden: Siehe hier und die anschließende Korrekturbearbeitung. Grüße, --BlueCücü (Diskussion) 11:33, 17. Mär. 2013 (CET)

Einen ziemlich ähnlichen Fall hatte ich hier. --BlueCücü (Diskussion) 11:58, 17. Mär. 2013 (CET)

Weblinks mit senkrechtem Strich, wer kommt denn auf so was. Leider musste ich dazu meine Regel, die [http://url.de/pfad|Solche Falschschreibungen] korrigieren sollte, entschärfen, denn ich habe keine Möglichkeit, das von erwünschten Fällen wie [http://url.de/pfad|id Solchen] zu unterscheiden. --TMg 15:12, 17. Mär. 2013 (CET)

Hinweis: Daten werden nur teilweise umgewandelt

Im Trainerabschnitt wurden hier nur die Daten nach, aber nicht vor dem Bis-Strich konvertiert. Grüße, --BlueCücü (Diskussion) 11:40, 17. Mär. 2013 (CET)

Lustig, die entsprechende Datumsregel habe ich erst vor kurzem in der Betaversion komplett überarbeitet. Ich habe diesen Teil mal live geschaltet. --TMg 14:14, 17. Mär. 2013 (CET)

Vorschlag: redundante Jahreszahlen erst wenn nach erster Infobox doppelt entlinken

Redundant verlinkte Jahreszahlen werden ja entlinkt. Oft geschieht dies bei Filmartikeln dann gleich in der Einleitung, weil die Jahreszahl im Quelltext zuvor schon in der Infobox verlinkt war. Mein Vorschlag wäre, dass verlinkte Jahreszahlen in Infoboxen zu Beginn eines Artikel ignoriert werden, so dass nur redundante Jahreszahlverlinkungen ab der Einleitung entlinkt werden. --BlueCücü (Diskussion) 12:14, 17. Mär. 2013 (CET)

Gute Idee und eine schöne Herausforderung. Danke. --TMg 15:36, 17. Mär. 2013 (CET)

Zahlwörter

Aus (beispielsweise) „2-fach“ wird „2fach“. Laut Duden sind beide Schreibweisen zulässig. Ich persönlich bevorzuge die Bindestrich-Variante. Gibt es dazu einen Konsens innerhalb der Wikipedia? --Seth Cohen 00:48, 22. Mär. 2013 (CET)

Tut mir leid, ist das ein Fehler, ein Vorschlag oder nur eine Frage? Entfernt mein Skript den Bindestrich? Einen Konsens gibt es bei so extrem ins Detail gehenden Fragen mit ziemlicher Sicherheit nicht. Wenn ausdrücklich beides erlaubt ist, dann gilt für die Wikipedia-Arbeit meist, dass vorhandene Schreibweisen nicht geändert werden sollten. Zitat: Nicht großflächlich eine zulässige in eine andere zulässige Schreibweise ändern. --TMg 11:24, 22. Mär. 2013 (CET)

Es handelt sich um Feststellungen, gefolgt von einer Frage. Ja, dein Skript entfernt den Bindestrich. --Seth Cohen 00:25, 11. Apr. 2013 (CEST)

Ich kann das auch mit deinen benutzerdefinierten Ersetzungen nicht nachvollziehen. Ich wüsset wie angedeutet nicht einmal, welcher Schreibweise der Vorzug zu geben wäre, geschweige denn, wo eine Ersetzungsregel dafür herkommt? Also sehr verwirrend. Ohne weitere Informationen kann ich dir da nicht weiter helfen. --TMg 16:14, 11. Apr. 2013 (CEST)

Sorry! Da war ich wohl betrunken. ;-) --Seth Cohen 18:16, 12. Apr. 2013 (CEST)

Bis-Striche nicht umgewandelt

In diesem Abschnitt wurden vom Script die Bis-Striche nicht umgewandelt. Just4info. Vielleicht magst du bei Gelegenheit mal drüberschauen woran es lag. Es grüßt, --BlueCücü (Diskussion) 12:27, 24. Mär. 2013 (CET)

Die Regeln für Jahreszahlenbereiche berücksichtigen keine eckigen Klammern. Ich kann mir das mal anschauen, aber eigentlich ist das ein Paradebeispiel für gänzlich nutzlose Jahreszahlenlinks. Die sollten alle entfernt werden. Ich überlege sogar, ob ich solche Fälle vollautomatisch entlinken kann. Ob das konsensfähig wäre? --TMg 17:52, 24. Mär. 2013 (CET)

Mir fällt spontan keine Tabelle ein in der „nackte“ Jahreszahlen momentan willentlich und sinnvoll verlinkt werden. Mir fallen im Sportbereich nur verlinkte Jahreszahlen ein, die dann auf den versteckten Link eines Turniers im betreffenden Jahr verlinken, also z.B. [[Deutsche Hallenhalma-Meisterschaft 2012|2012]]. Da machts Sinn. Auch in der Infobox eines Filmartikels macht die Zeile „Erscheinungsjahr: [[Filmjahr 2007|2007]]“ durchaus Sinn. Aber ob es konsensfähig wäre genrell alle reinen „normalen“ Jahreszahlverlinkungen ([[2007]], etc.) in Infoboxen und Tabellen zu entlinken, vermag ich nicht zu beurteilen. --BlueCücü (Diskussion) 20:08, 24. Mär. 2013 (CET)

Ich meinte speziell Jahreszahlenbereiche. Es ergibt meiner Meinung nach niemals Sinn, diese zu verlinken. --TMg 20:57, 24. Mär. 2013 (CET)

Achso. Ja, bei Jahreszahlenbereichen bin ich auch der Meinung das diese komplett entlinkt werden könnten. P.S.: Momentan ist meine Bearbeitungsleiste über dem Bearbeitungsfenster verschwunden. Also die mit dem Sigantur- und auch Autoformatter-Button. Hat Letzterer damit etwas zu tun, oder liegt der Fehler woanders? --BlueCücü (Diskussion) 19:58, 25. Mär. 2013 (CET) P.P.S.: Geht wieder alles. --BlueCücü (Diskussion) 20:25, 25. Mär. 2013 (CET)

Hier nochmal ein weiteres Beispiel. Diesmal allerdings mit ausgeschriebenem „Bis“. Bzw. beide Varianten (Bis ausgeschriebe und Bis-Strich) vermischt. Vielleicht hilfts ja beim Erstellen einer eventuellen Regel fürs Script. --BlueCücü (Diskussion) 11:46, 26. Mär. 2013 (CET)

Jahreszahlenbereiche mit einem oder zwei Links werden jetzt entlinkt und nach der selben Regel wie sonst mit dem Bis-Strich versehen. Bei der Schreibweise mit „bis“ bin ich mir nicht so sicher, ob das pauschal verändert werden dürfte und wie. Das würde ich eher dem Benutzer überlassen. Schnellste Methode: Doppelklick auf das „bis“, - und nochmal den Besen drücken. --TMg 01:05, 13. Jun. 2013 (CEST)

Leerzeichen vor Prozentzeichen nicht gesetzt

Hier wurden im Abschnitt „Sortiment“ viele Leerzeichen nicht gesetzt. Nur ein Mal. Später wurds dann händisch korrigiert. Liegts u.U. an den durch einen Punkt abgetrennten Dezimalstellen? --BlueCücü (Diskussion) 13:11, 24. Mär. 2013 (CET)

Genau. „4.9%“ gibt es im Deutschen nicht und es wird nicht richtiger, wenn mein Skript „4.9 %“ daraus macht. Da gilt wieder mein Argument, dass ich solche falschen Stellen nicht „veredeln“ möchte, weil das den Eindruck erweckt, die Schreibweise wäre erwünscht. Ich kann auch nicht automatisch Punkte in Kommas umwandeln, weil das zu fehleranfällig wäre. Ich würde mir aber eine Sache ansehen: Die Regel abhängig von der Textsprache lokalisieren. --TMg 17:42, 24. Mär. 2013 (CET)

Vorschlag: Leerzeile vor SORTIERUNG bzw. erster Kategorie

Manchmal „kleben“ die Kategorien oder die Sortierungs-Vorlage direkt unter den references oder einer Koordinaten-Vorlage. Damit der Kategorien-Block mitsamt der Sortierung für sich allein als Einheit sichtbar ist, wäre es schön wenn der autoFormatter eine Leerzeile vor SORTIERUNG bzw. - falls nicht vorhanden – vor der ersten Kategorie einfügen würde. --BlueCücü (Diskussion) 20:28, 25. Mär. 2013 (CET)

Werde ich einbauen, dauert aber etwas, weil das nicht ganz trivial ist und ich Fehlersetzungen (bspw. im Vorlagennamensraum) vermeiden will. --TMg 13:53, 26. Mär. 2013 (CET)

Eine Leerzeile wird jetzt eingefügt, wenn vor dem Kategorien-Block entweder ein Einzelnachweis-Abschnitt oder eine Navigationsleiste steht. Das mit der Koordinaten-Vorlage erscheint mir zu unsicher, das beachte ich noch nicht. Ich nehme gern weitere Vorschläge auf (bitte ganz konkret die beiden Elemente nennen, zwischen die eine Leerzeile soll). --TMg 15:06, 27. Apr. 2013 (CEST)

weiteres (hoffentlich) konkretes Beispiel: Zwischen Weblink und Kategorienblock (also Sortierung bzw. erste Kategorie)

* [www.blabla... Beschreibung]
{{SORTIERUNG:...
[[Kategorie:...

--BlueCücü (Diskussion) 16:12, 17. Mai 2013 (CEST)

Hattes es grad, dass zwischen <references /> und [[Kategorie:... keine Leerzeile eingefügt wurde. --BlueCücü (Diskussion) 17:22, 18. Mai 2013 (CEST)

Geht bei mir. Bitte den Artikel nennen. Das Beispiel mit dem Weblink eins weiter oben ist klar, darum kümmere ich mich. --TMg 17:43, 18. Mai 2013 (CEST)

Hab grad kein konkretes Beispiel. Aber wenn ich eins konstruiere. Also <references /> und eine Kategorie oder den Sortierschlüssel direkt untereinander schreibe ohne Leerzeile, dann bewirkt der „Klick auf den Besen“ keine Leerzeilen-Setzung. Am Cache kanns auch nicht liegen. Bin momentan etwas ratlos. Falls mir mal beim Abarbeiten der Wartunslisten wieder ein konkretes Beispiel über den Weg läuft, dann meld ich mich nochmal. --BlueCücü (Diskussion) 20:14, 18. Mai 2013 (CEST)

Liegt nicht zufällig daran, dass es bisher erst in der Betaversion drin ist und noch nicht „scharfgeschaltet“? --BlueCücü (Diskussion) 15:35, 24. Mai 2013 (CEST)

Ja, wie immer. Bitte entschuldige. Ich habe jetzt der Einfachheit alles freigeschaltet. --TMg 16:29, 24. Mai 2013 (CEST)

Halb so wild. Da hätte ich auch früher drauf kommen können :) --BlueCücü (Diskussion) 16:38, 24. Mai 2013 (CEST)

Zwischen „Normdaten“ und „Sortierung/Kategorie“ wäre noch ein konkretes Beispiel. --BlueCücü (Diskussion) 19:04, 24. Mai 2013 (CEST)

Ebenso zwischen {{Coordinate..... und SORTIERUNG. --BlueCücü (Diskussion) 15:59, 30. Okt. 2013 (CET)

Ich weiß gerade selbst nicht mehr, warum ich das mit der Coordinate-Vorlage weiter oben als unsicher bezeichnete. Ich werde es wohl einbauen. --TMg 16:28, 30. Okt. 2013 (CET)

Vorschlag: Leerzeilen am Artikelanfang entfernen

Einen kleinen hab ich noch, dann ist auch erstmal wieder Schluss für heute: Werden QS- oder Löschbausteine gelöscht, so verbleiben hin und wieder Leerzeilen am Artikelanfang. Diese können doch sicher auch automatisch wegautoformatiert werden, oder? Es grüßt, --BlueCücü (Diskussion) 20:47, 25. Mär. 2013 (CET)

Siehe oben. Aber wenn du auch dafür bist, werde ich nochmal darüber nachdenken. --TMg 13:47, 26. Mär. 2013 (CET)

Wobei ich Leerzeilen nicht -zeichen meinte. --BlueCücü (Diskussion) 23:07, 26. Mär. 2013 (CET)

colspan-Wert in Anführungszeichen

Spalte 1	Spalte 2
colspan="2"
colspan "2"	Tja …

Es wird in Tabellen manchmal z.B. colspan "2" zu colspan „2“ geändert. Dies ist sicher nicht gewollt oder bleibt dies ohne Folgen? (Beispiel) Ostergrüße von --BlueCücü (Diskussion) 14:04, 30. Mär. 2013 (CET)

Ja, das bleibt ohne Folgen, weil die Schreibweise vorher schon falsch war und sowieso nichts bewirkt. Sieh es als Achtungssignal, dort bitte das fehlende Gleichheitszeichen zu ergänzen. --TMg 15:56, 30. Mär. 2013 (CET)

Noch ein kleiner Oster-Bug

Aus „[…] während des Krieges konnte der Bau erst am 30. Oktober 1955 – 23 Jahre nach Baubeginn – vom Tschenstochauer Bischof […]“ wurde „[…] während des Krieges konnte der Bau erst am 30. Oktober 1955–1923 Jahre nach Baubeginn – vom Tschenstochauer Bischof […]“. Habs nun in Klammern („[…] während des Krieges konnte der Bau erst am 30. Oktober 1955 (23 Jahre nach Baubeginn) vom Tschenstochauer Bischof […]“) gesetzt, damit es zukünftig nicht fehlkorrigiert wird. --BlueCücü (Diskussion) 14:10, 30. Mär. 2013 (CET)

Mit einem „Trick“ erledigt: „1955 – 23 Jahre danach“ ist jetzt geschützt, weil die Zahlen nicht aufsteigend sind, aber aus „1922 – 23 Jahre danach“ wird immer noch „1922–1923 Jahre danach“. --TMg 19:28, 8. Jun. 2013 (CEST)

<ref name="XYZ"></ref>

Hallo! Während <references></references> in <references /> umgewandelt wird, bleiben Konstruktionen wie <ref name="XYZ"></ref> unberührt. Ist es möglich, hier auch automatisch auf <ref name="XYZ" /> zu korrigieren? Grüße, --Polarlys (Diskussion) 12:20, 7. Apr. 2013 (CEST)

Klar, an diesem Fall hatte ich bisher nur noch nicht gedacht. --TMg 16:17, 7. Apr. 2013 (CEST)

Danke. --Polarlys (Diskussion) 17:02, 7. Apr. 2013 (CEST)

Zum 1. Fall: Wikipedia:Tipp des Tages#Einzelnachweise für Fortgeschrittene wird aber nicht vom Skript angetastet, oder?--Svebert (Diskussion) 17:15, 7. Apr. 2013 (CEST)

Ich bin mir nicht ganz sicher, was du meinst. Es geht nur um leere Elemente. --TMg 12:13, 8. Apr. 2013 (CEST)

Zeilenumbrüche in Einzelnachweis-Blöcken nicht entfernen

Wo wir gerade dabei sind. Ich formatiere die Einzelnachweise gerne nach dem Muster:

<references>
 <ref name="Bezeichnung">
  {{Literatur
   | Autor  = Max Mustermann
   | Title  = Tolles Buch
   | Verlag = Großer Verlag
   | Ort    = Musterstadt
   | Jahr   = 2013
  }}
 </ref>
</references>

Ich bin mir nicht sicher, ob das so „korrekt“ ist und streng genommen müssen die ganzen Leerzeichen natürlich nicht sein, aber mir persönlich helfen die Einrückungen dabei, einen Überblick zu behalten, was wozu gehört und wo eventuell noch Angaben fehlen. Nach einem Klick auf Auto-Format, sieht das dann so aus: [Zeilenumbrüche werden entfernt.] Nicht dramatisch, nur ein wenig nervig. Meinetwegen muss da auch gar nicht global dran rumgespielt werden, aber habe ich persönlich eine Möglichkeit das abzustellen? Danke schon mal. --Alex (Diskussion) 23:41, 7. Apr. 2013 (CEST)

Siehe Benutzerin Diskussion:Ra'ike#Granatgruppe. Zufall? Kurz: Ja, ich werde das abstellen. Zu den Leerzeichen: Zumindest das allererste Leerzeichen in jeder Zeile erscheint mir überflüssig. Das würde ich weg lassen. Ansonsten spricht da nichts dagegen. --TMg 12:13, 8. Apr. 2013 (CEST)

Oha, wirklich Zufall. (Zumal ich die Vorlage:Literatur in den Einzelnachweisen immer in der langen Version verwende, siehe oben.) Vielen Dank. --Alex (Diskussion) 18:47, 8. Apr. 2013 (CEST)

Auslassungspunkte

Kann es sein, dass nur alleinstehende ... in … geändert werden und solche in Zitaten in eckigen Klammern. Direkt am Text, also „Text...“ wird nämlich nicht zu „Text…“. Ist das so gewollt, weil eine automatische Änderung zu fehleranfällig wäre? --BlueCücü (Diskussion) 07:59, 11. Apr. 2013 (CEST)

Exakt. Ich wandle die drei Punkte nur um, wenn sie an einer Stelle stehen, die typografisch sehr wahrscheinlich richtig ist. Da es sich bei „Text...“ um eine ganz typische Fehlverwendung handelt, ersetze ich das nicht. Da muss ein Leerzeichen hin, wenn es sich nicht um ein abgekürztes Wort handelt. --TMg 16:09, 11. Apr. 2013 (CEST)

Ich nehme gern weitere Fälle auf, in denen die Ellipse eingesetzt werden soll. Aber den Fall „Buchstabe Punkt Punkt Punkt“ ohne Leerzeichen werde ich wie erklärt nicht aufnehmen. --TMg 15:28, 27. Apr. 2013 (CEST)

123m hochgestellt

Hallo TMg! Ich war vorhin unachtsam und habe beim Formatieren die Angabe ^99m[[Technetium|Tc]]-markierten [[Bisphosphonat]]e in ^99 m[[Technetium|Tc]]-markierten [[Bisphosphonat]]e umgewandelt. Sind die entsprechenden Chemie/Nuklearmedizin-Artikel Grund genug für eine Anpassung des Skriptes an dieses Szenario oder würdest du davon eher Abstand nehmen? Gruß, --Polarlys (Diskussion) 20:15, 16. Apr. 2013 (CEST)

Hast du ein paar konkrete Artikel, in denen das vorkommt? Ich denke, ich werde Maßeinheiten neben spitzen Klammern ganz ausschließen. Dann wird zwar auch <ref>99m</ref> nicht mehr ersetzt, aber das kommt normalerweise nicht vor. --TMg 12:32, 18. Apr. 2013 (CEST)

Nuklearmedizin, Radionuklidangiografie, Schilddrüsenszintigraphie, Technetium. Viele Grüße, --Polarlys (Diskussion) 18:25, 18. Apr. 2013 (CEST)

Dankeschön. Ich sehe jetzt in keinem Fall mehr eine Fehlersetzung. Gelöst habe ich das durch Verbot der spitzen Klammer vor der Zahl. Das heißt, 99m<ref>…</ref> ist noch im Spiel. Das ist die einzige Kombination mit spitzen Klammern, die mir praxisrelevant erscheint. --TMg 22:32, 18. Apr. 2013 (CEST)

Script ändert nur die ersten "Doppel-Anführungszeichen" in 'Einzel-Anführungszeichen' in einem Zitat

Hier das Beispiel dazu. Es grüßt, --BlueCücü (Diskussion) 09:45, 17. Apr. 2013 (CEST)

Aktuell ist das so, weil ich das so programmiert habe. Danke für das Beispiel, ich nehme das auf und werde mir eine Lösung überlegen. Lösung bis dahin: Den Knopf mehrmals drücken. --TMg 12:25, 18. Apr. 2013 (CEST)

Änderungen im/am Sortierschlüssel

Derzeit wird der Sortierschlüssel entfernt, sofern er mit dem Lemma 100 % identisch ist. Wenn er nicht 100 % identisch ist, werden äöü zu aou und ß zu ss umgewandelt. Kannst du das Script so hindrehen, dass es erst die Umlaute etc. umwandelt und erst im zweiten Schritt prüft, ob das Lemma 100 % identisch ist. Denn hin und wieder hat ein Benutzer wohlweißlich einen Sortierschlüssel gesetzt, aber nicht die Sonderzeichen ersetzt. In diesem Fall entfernt das Script den Sortierschlüssel einfach komplett, obwohl eigentlich nur noch die Sonderzeichen korrigiert werden müssten. Es grüßt, --BlueCücü (Diskussion) 20:04, 21. Apr. 2013 (CEST)

Sehr gut beobachtet, danke. --TMg 01:10, 23. Apr. 2013 (CEST)

Die Änderungen äöüßé etc. könnten eigentlich auch in der Extrasortierung ([[Kategorie:XY|äöüßé]] --> [[Kategorie:XY|aousse]]) vorgenommen werden. Vielleicht beim nächsten Update :) Grüße, --BlueCücü (Diskussion) 14:30, 24. Apr. 2013 (CEST)

Fehler in gallery-tags

Zwischen gallery-tags werden anscheinend auch Bindestriche zu Halbgeviertstrichen in Dateinamen geändert, sofern kein „Datei“ oder „File“ oder „Bild“ oderoder am Anfang der Zeile steht (Beispiel und nachfolgender Korrektur). Es grüßt, --BlueCücü (Diskussion) 12:09, 29. Apr. 2013 (CEST)

Ja, leider. Ich hatte mit viel Aufwand einen Schutz für die Dateinamen entwickelt und plötzlich darf man den Namensraum in Galerien weglassen. Ich bin da zwiegespalten, ob das eine gute Idee ist und wie ich sowohl bei meinen Bearbeitungen als auch in Bezug auf das Skript damit umgehen soll. Der meiner Meinung nach große Vorteil der Schreibweise mit „Datei:“ ist, dass das identisch zu allen anderen Stellen ist, an denen man Dateinamen sieht: Auf den Dateibeschreibungsseiten steht es immer dabei und auch in der normalen Bildeinbindung ist es Pflicht. Nur in Galerien nicht. Das ist doch verwirrend. Beheben muss ich das trotzdem, ich suche aber noch nach einer eleganten Lösung. Ich will Galerien nicht komplett ausklammern. --TMg 15:19, 29. Apr. 2013 (CEST)

Einerseits ists ja nachvollziehbar, da in einer „gallery“ nur aus einem bestimmten Namensraum „Daten gezogen“ werden. Andererseits verschleiert es doch ein wenig die Herkunft. Kann mir da noch nicht so recht eine Meinung zu bilden. Werde bis zum eventuellen Update also erstmal Änderungen innerhalb gallerytags etwas genauer beäugen. --BlueCücü (Diskussion) 09:09, 30. Apr. 2013 (CEST)

Änderung gemäß Datumskonvention nach | funktioniert nicht

Das Ändern von z.B. 12.07.13 in 12. Juli 2013 funktioniert in Tabellen anscheinend nur, wenn nach dem | ein Leerzeichen steht, nicht aber wenn das Datum direkt nach dem | kommt (Beispiel: vergleiche Abschnitt Viertel- und Halbfinale). --BlueCücü (Diskussion) 09:12, 30. Apr. 2013 (CEST)

Absicht, damit teils notwendige Kurzformen in Tabellen und Vorlagen nicht kaputt gemacht werden. Eigentlich müsste ich auch den Fall mit senkrechtem Strich und Leerzeichen verbieten, dafür bestand bisher aber noch keine Notwendigkeit. --TMg 09:27, 30. Apr. 2013 (CEST)

Gut. Werde Datumsänderungen in Tabellen also fortan nicht übernehmen. Solange bis das Script es nach dem nächsten Update sowieso nicht mehr ändert. ;) --BlueCücü (Diskussion) 09:41, 30. Apr. 2013 (CEST)

Der Schutz bezieht sich vor allem auf Vorlagen wie {{Vorlage|12.07.13}}. In solchen normal breiten Tabellen kannst du ruhig Leerzeichen vor die Daten setzen und sie ausschreiben. --TMg 11:57, 6. Mai 2013 (CEST)

Ist gedanklich notiert. --BlueCücü (Diskussion) 12:43, 6. Mai 2013 (CEST)

!width = "20%" wird zu !width = „20 %“

Hier wurden einige Zeilen nach dem Muster !width = "20%" wird zu !width = „20 %“ geändert. Da es keine Auswirkungen auf die Tabelle in der Vorschau hatte, habe ich es erstmal übernommen. Aber irgendwo ist da glaub ich noch der Wurm drin, oder? --BlueCücü (Diskussion) 09:39, 30. Apr. 2013 (CEST)

Was für ein wunderbar schräges Beispiel (eine ganze Tabelle nur aus Kopfzellen), wieder vielen Dank dafür. Eigentlich habe ich eine Säuberung für Fälle wie attribut = "wert", aber die beachtete bisher noch keine Kopfzellen. --TMg 11:32, 6. Mai 2013 (CEST)

Immer wieder gern ;) --BlueCücü (Diskussion) 11:38, 6. Mai 2013 (CEST)

Vorschlag: Leerzeile über jede Überschrift

Wäre es möglich eine Leerzeile über jede Überschrift einzufügen, sofern nicht vorhanden. Dies würde manchen Quelltext etwas entstauchen. --BlueCücü (Diskussion) 20:41, 4. Mai 2013 (CEST)

Ungern. Ich hatte das kurzzeitig drin, aber es nervte, beispielsweise bei auskommentierten Überschriften. Auch Bildeinbindungen und Dinge wie Vorlage:Anker können absichtlich vor Überschriften stehen. Das sind mir zu viele (seltene) Sonderfälle, denen nur eine kleine Arbeitserleichterung gegenüber steht. --TMg 10:30, 6. Mai 2013 (CEST)

Überzeugt. --BlueCücü (Diskussion) 11:16, 6. Mai 2013 (CEST)

Minus- zu Bis-Strich in pdf-Links

Hallo. Hatte es heute zweimal, dass das Script in einem pdf-Link einen Minusstrich in einen Bis-Strich umwandeln wollte (z.B. hier). Habs dann wieder händisch geändert vor dem Speichern. Weiß nicht genau, ob das ein Fehler ist der sich auf pdf-Links beschränkt oder generell für Weblinks gilt. Beste Grüße, --BlueCücü (Diskussion) 11:34, 13. Mai 2013 (CEST)

Ja, das gilt generell für Weblinks, weil ich für diese keinen besonderen Schutz habe. Ich habe es zum Teil behoben, weil ich so etwas wie „1973-84/85“ gern weiter unterstützen möchte. --TMg 00:37, 14. Mai 2013 (CEST)

Dauerschleife bei ISBN

In diesem Artikel wird bei mehrmaliger Betätigung des „Besen-Buttons“ endlos ein Bindestrich an die eine ISBN angefügt. Tippe darauf, dass die ISBN falsch ist und dadurch ne Dauerschleife entsteht. Bin mir aber nicht sicher. Beste Grüße, --BlueCücü (Diskussion) 07:37, 23. Mai 2013 (CEST)

Mit <small> unlesbar gemachte Einzelnachweise

Unfug: <small><ref … /></small>. Fundort: David Guetta/Diskografie. --TMg 15:23, 5. Jun. 2013 (CEST)

Inwiefern unlesbar? --Seth Cohen 20:36, 7. Jun. 2013 (CEST)

Ohne Lupe nicht mehr lesbar, aber das kommt auf den Webbrowser und die Schriftdarstellung im Betriebssystem an. Unfug ist es in jedem Fall. --TMg 17:33, 8. Jun. 2013 (CEST)

Geschützte Leerzeichen vor Einheiten

Zu ergänzen? ml, dl, dm, dm², dm³, etc. --Seth Cohen 20:28, 7. Jun. 2013 (CEST)

Ja, vielleicht. Ich wollte die Liste absichtlich kurz halten, unter anderem da sie mit jeder Ergänzung ineffizienter wird. Anders gesagt: Ich nehme gern weitere Maßeinheiten auf, wenn sie praktisch in mehr als einem Artikel vorkommen. „ml“ kann ich mir gut vorstellen. Aber der Rest? Beispiele? --TMg 17:36, 8. Jun. 2013 (CEST)

Reihenfolge Bildformatierung

Vereinheitlichen? mini|hochkant, hochkant|mini. --Seth Cohen 20:30, 7. Jun. 2013 (CEST)

Ungern, da das praktisch gar nichts bringt und nur die Versionsvergleiche unübersichtlich macht. Und wenn, was wäre zu bevorzugen? --TMg 17:39, 8. Jun. 2013 (CEST)

Nun gut, mini|hochkant ist eindeutig zu bevorzugen und auch so dokumentiert. Ich werde eine Regel einbauen, die das sortiert, wenn sowieso eine Änderung in der Zeile ansteht. --TMg 13:46, 28. Jun. 2013 (CEST)

Nachfrage zu archiviertem Vorschlag

Wurde dieser Vorschlag umgesetzt oder als nicht machbar verworfen? Frag nur weil er archiviert wurde, es aber noch nicht funktioniert. Häufig fällt es bei Sportlern (oder generell Personen-Artikeln) auf, bei denen das Geburtsjahr sowohl in der ersten Infobox als auch im Einleitungssatz verlinkt ist. Falls es als nicht machbar archiviert wurde, kann dieser Abschnitt auch gern direkt nacharchiviert werden :) Gruß, --BlueCücü (Diskussion) 22:12, 11. Jun. 2013 (CEST)

Der Vorschlag ist umgesetzt, jedoch in einer einfachen Form, die verschachtelte Vorlagen nicht beachtet. Ich vermute, dass in den Sportler-Infoboxen so etwas wie {{DEU}} vorkommt. Kann das sein? Wie immer wäre ein Beispiel schön. --TMg 23:27, 11. Jun. 2013 (CEST)

Nehmen wir mal den hier als prominentes Beispiel. --BlueCücü (Diskussion) 23:40, 11. Jun. 2013 (CEST)

HTML-Entitäten

Hielt ich nie für nötig, aber eben bin ich über einen Berg – gestolpert. Ich hab mir mal ein paar Kandidaten ausgewählt. Noch ein praxisrelevantes Zeichen? Gibt es Fälle, in denen etwas nicht ersetzt werden darf? (Außer in <code> etc., versteht sich.) --TMg 19:52, 12. Jun. 2013 (CEST)

«	U+00AB	/&#*(?:laquo|x0*AB|0*171) *;/gi
·	U+00B7	/&#*(?:middot|centerdot|x0*B7|0*183) *;/gi
»	U+00BB	/&#*(?:raquo|x0*BB|0*187) *;/gi
×	U+00D7	/&#*(?:times|x0*D7|0*215) *;/gi
–	U+2013	/&#*(?:ndash|x0*2013|0*8211) *;/gi
—	U+2014	/&#*(?:mdash|x0*2014|0*8212) *;/gi
‘	U+2018	/&#*(?:lsquo|x0*2018|0*8216) *;/gi
’	U+2019	/&#*(?:rsquor?|x0*2019|0*8217) *;/gi
‚	U+201A	/&#*(?:lsquor|sbquo|x0*201A|0*8218) *;/gi
“	U+201C	/&#*(?:ldquo|x0*201C|0*8220) *;/gi
”	U+201D	/&#*(?:rdquor?|x0*201D|0*8221) *;/gi
„	U+201E	/&#*(?:ldquor|bdquo|x0*201E|0*8222) *;/gi
†	U+2020	/&#*(?:dagger|x0*2020|0*8224) *;/gi
‡	U+2021	/&#*(?:Dagger|ddagger|x0*2021|0*8225) *;/g (Reihenfolge beachten)
•	U+2022	/&#*(?:bull|bullet|x0*2022|0*8226) *;/gi
…	U+2026	/&#*(?:hellip|mldr|x0*2026|0*8230) *;/gi
‹	U+2039	/&#*(?:lsaquo|x0*2039|0*8249) *;/gi
›	U+203A	/&#*(?:rsaquo|x0*203A|0*8250) *;/gi

Keine Ahnung, wie ich auf  *; mit den optionalen Leerzeichen gekommen bin. Statt dessen habe ich lieber ;? verwendet. Das kommt in der Praxis vor. --TMg 01:42, 21. Jun. 2013 (CEST)

Naviblöcke erstellen/auflösen

Ist es machbar, dass das Script

• aus mehreren untereinanderstehenden Navigationsleisten einen Naviblock erstellt
• aus einem Naviblock mit nur einer einzigen Navigationsleiste die Blockvorlage entfernt

Grüße, --BlueCücü (Diskussion) 07:53, 13. Jun. 2013 (CEST)

Lustige Koinzidenz. Ich überlege auch, die alte Schreibweise der Vorlage:NaviBlock aufzulösen, obwohl die wahrscheinlich nirgends mehr vorkommt (jedenfalls findet die Volltextsuche nichts). Irgendwo automatisiert einsetzen möchte ich die Vorlage nicht. Ihr Nutzen tendiert gegen Null. Man kann sogar argumentieren, dass sich die Navigationsleisten ohne die Blockvorlage besser voneinander abheben und damit besser nutzbar sind. Die Vorlage verkompliziert nur den Quelltext. Außerdem ist ihr Name schrecklich (passt überhaupt nicht zu den so schön standardisierten Namen der Navigationsleisten). Bemerkenswerterweise hat die sonst so verspielte englischsprachige Wikipedia so eine Vorlage überhaupt nicht. Also viele Argumente dagegen und nur 1 Pixelstreifen dafür. --TMg 02:10, 14. Jun. 2013 (CEST)

Wenigstens säubern sollte ich so was aber, wenn es schon mal da ist. --TMg 21:47, 9. Jul. 2013 (CEST)

{{NaviBlock
|Navigationsleiste Städte und Gemeinden im Rhein-Sieg-Kreis
|Navigationsleiste Ortsteile von Ruppichteroth}}

Sortierschlüssel-Ersetzungen

Meinst du, man könnte noch die kyrillischen Zeichen in die automatische Sortierschlüsselersetzung aufnehmen? Hier das manuell korrigierte Beispiel. Nen sonnigen Sonntag wünscht, --BlueCücü (Diskussion) 14:02, 16. Jun. 2013 (CEST)

Und woher weiß ich, was durch was ersetzt werden soll? Das da ist wenig hilfreich. --TMg 16:07, 17. Jun. 2013 (CEST)

Ist das hier auslesbar? Ansonsten vielleicht den Unicode-Block kopieren, hier einsetzen und dann auf den Button unter „Translit“ klicken, Ergebnis copy-pasten und dem Unicode-Block gegenüberstellen. Fragt sich nur wie viele kyrillische Lemmata wir haben. Vielleicht ist der Aufwand auch etwas zu groß. --BlueCücü (Diskussion) 20:00, 17. Jun. 2013 (CEST)

Das Tool ist merkwürdig. Es verwendet wie es scheint die englische statt die deutsche Transliteration (V statt W für das russische В). --TMg 21:06, 17. Jun. 2013 (CEST)

Den Artikel auszuwerten, ist ebenfalls anstrengend. Selbst unter Missachtung der meisten Sonderfälle (einiges ist nach Vokalen oder am Wortanfang oder -ende anders zu schreiben) bleibt viel Unklares übrig. Was ist da „richtig“? --TMg 21:41, 18. Jun. 2013 (CEST)

Unicode-Nr.	Zeichen	Transkription
U+0413	Г	G oder H? Laut Artikel Г „in der Regel mit g umschriftet“.
U+0415	Е	E oder Je? Eigentlich eindeutig. Є wird zu Je aber Е bleibt E. Ausnahmen bestätigen die Regel.
U+0416	Ж	Sch oder Dsch? Laut Ж „meistens als sch umschrieben“.
U+0418	И	I oder Y? Scheint mir den Artikeln zufolge im Deutschen ziemlich eindeutig.
U+0419	Й	I oder J? Sehr widersprüchliche Informationen. Ich nehme jetzt das, was mir logischer scheint und was die große Tabelle in Kyrillisches Alphabet bestätigt.
U+0429	Щ	Schtsch oder Scht? Laut Щ „in der deutschen Transkription also schtsch“.

Gute Frage, nächste Frage ;) Vielleicht könnte man damit leben, dass man einfach eine Ersetzungsvariante dem Script vorgibt, dann ist der Artikel in den Kats zumindest schonmal richtiger einsortiert als vorher, nämlich nicht mehr am Ende nach Z. Sollte es dann noch Ungereimtheiten geben kann ein Benutzer mit ausreichenden kyrillisch-Kenntnissen ja die manuelle Anpassung vornehmen. Gibts eigentlich viele kyrillische Lemmata in de-wp? Oder war das Beispiel eh nur eine sehr seltene Ausnahme. Den meistens wird ja eh das transkribierte Lemma genommen. --BlueCücü (Diskussion) 15:44, 21. Jun. 2013 (CEST)

Leere Vorlage:Literatur

Das geht? Fundstelle. --TMg 11:34, 20. Jun. 2013 (CEST)

Wenn leer, dann löschen. Wird denk ich niemand als "Knoten im Taschentuch" vorläufig eingebaut haben. --BlueCücü (Diskussion) 23:17, 22. Jun. 2013 (CEST)

Geschützte Leerzeichen entfernen

Neue Idee: 1. Januar 2001 → 1. Januar 2001. Referenz. Beispiel. Auch aus Sterbedaten entferne ich es schon (Referenz). Weitere Ideen? --TMg 18:06, 21. Jun. 2013 (CEST)

Da eindeutige Referenz vorhanden --> geschützte Leerzeichen zwischen Monat und Jahr entfernen. --BlueCücü (Diskussion) 23:21, 22. Jun. 2013 (CEST)

Könnte/Darf man...

... als einigermaßen erfahrener Benutzer des Scripts eigentlich auch die Beta-Version statt der „Alpha-Version“ in seine common.js einbinden? Oder ist das eher unerwünscht? --BlueCücü (Diskussion) 23:14, 22. Jun. 2013 (CEST)

Die stabile Version ist für Leute, die es nerven würde, wenn sich dauernd was ändert und auch mal was kaputt geht. Wer wie du hier aktiv mitdiskutiert, sollte auf jeden Fall die Beta nehmen. :-) --TMg 16:34, 23. Jun. 2013 (CEST)

Porting English version

I would suggest that you take a look at w:Wikipedia:AutoEd, which is fairly comprehensive tool that follows the MOS at en:WP; you could also refer to my formatting script, which has evolved independently of it but seems to have some of the same functions. --Ohconfucius (Diskussion) 11:57, 24. Jun. 2013 (CEST)

Thanks a lot for the links. I know AutoEd but I don't think anybody should use it as an example. It contains highly questionably and some very bad regular expressions. Most modules are abandoned and never updated since 2009. I'm sure AutoEd does what it's supposed to do but from my perspective (the perspective of a coder) it's ugly. I will definitely look at your code (and do a code review while I'm at it, if you want). Maybe let me try to explain my goal to make things clear: My script is and always should be focused on the German Wikipedia. That's my unique selling point. But since many rules apply everywhere it should be possible to use my script everywhere without breaking things. --TMg 13:45, 24. Jun. 2013 (CEST)

Any feedback would be appreciated. --Ohconfucius (Diskussion) 06:10, 25. Jun. 2013 (CEST)

Done. What I learned:

• No typographic quotes and apostrophes in the English Wikipedia!
• No space in "1%" in the English Wikipedia!
• He removes all spaces in front of every <ref>. Should I do the same?
• He has a "1 x 2" rule (with non-optional spaces).

--TMg 00:45, 28. Jun. 2013 (CEST)

• Most grateful to you. Regards, --Ohconfucius (Diskussion) 05:30, 28. Jun. 2013 (CEST)

Getting rid of <font>

Thanks to Bgwhite for sharing. Here is my point of view:

1. <font color="…"> is easy to understand.
   • Can be easily replaced with <span style="color:…;"> without any drawback I'm aware of. I think I should do this. erledigtErledigt
   • Ouch: <font color="red">rot</font color>. erledigtErledigt
   • Would be good to have a rule to merge <span style="…"><span style="…"> to <span style="…;…">. erledigtErledigt
2. <font face="…"> contains a comma separated list of font names. I don't like this at all. This should be burnt with fire and not replaced.
   • Silently remove the nonsensical default values sans-serif, Arial, Helvetica and Helvetica Neue. erledigtErledigt
   • Take care of stuff like face="Arial,sans-serif" (drop) and face="Arial,Xyz" (don't touch). erledigtErledigt
   • Maybe replace Courier and such with <code>? Maybe <code>? But <code> is also deprecated, right?
3. <font size="…"> can be 1 to 7 or something like -1 or +1. 2 seems to be the default in the Vector skin. I want to replace this with smaller <small> and <span style="font-size:larger;"> in as much cases as possible. I don't care about a perfect replacement. It doesn't really matter. Here is what Bgwhite uses: 1/-2 = 87%, 2/-1 = 100%, 3/+0 = 125%, 4/+1 = 140%, 5/+2 = 190%, 6/+3 = 250%, 7/+4 = 375%, 8/+5 and up = 390%. Also see WP:WikiProjekt HTML5 and the talk page there.
   • This should become smaller <small> (Test: Aa): <font size="-2">-2 (Test: Aa),</font> <font size="0">0 (Test: Aa)</font> <font size="1">and 1 (Test: Aa).</font> erledigtErledigt
   • This should be removed (Test: Aa): <font size="-1">-1 (Test: Aa)</font> <font size="2">and 2 (Test: Aa).</font> erledigtErledigt
   • Same for 100%, 1em, 1.0em and such. erledigtErledigt
   • This should become larger (Test: Aa): <font size="-0">-0 (Test: Aa),</font> <font size="+0">+0 (Test: Aa)</font> <font size="3">and 3 (Test: Aa).</font> erledigtErledigt

How to deal with combined attributes: Remove nonsensical attributes (including empty and otherwise broken attributes) but keep the <font> tag. Remove empty <font> tags in a loop. Replace simple cases. Merge. --TMg 18:42, 25. Jun. 2013 (CEST)

• There are other cases of crap put into </font> I used </font\s*([a-zA-Z0-9#-]*)> to get rid of everything.
• On enwiki, per en:WP:FONTFACE, changing font is not allowed, but there are exceptions.
• <code> is also deprecated. It is recommended to replace tt with code.
• On enwiki, font size shouldn't be smaller than 90% for accessibility reasons. The <small> tag used 87%, so that is what I went with. No text could go larger than 390% as the wikimedia software would not display larger than 390%.
• There are also alot of stray </font> tags that pop up. Bgwhite (Diskussion) 19:12, 28. Jun. 2013 (CEST)

• I'm using </font[^<>]*> now. What could go wrong? ;-)
• Not sure what you mean with "changing font". en:WP:FONTFAMILY doesn't tell what's allowed.
• Or <kbd> or <samp>. They are closer because they come with no background color. But they depend on the content so I can't add them automatically.
• I totally forgot about <small>. Thanks, I'm using it now for size 1, 0, -2 and everything below.
• Thanks for the hint. But looking for balanced brackets and tags is outside the scope of my script. I leave that for AWB and other tools. :-)

--TMg 00:18, 12. Jul. 2013 (CEST)

• Can't do <span style="font-family:Times New Roman";>. Examples of what are allowed that I have found... Letter articles A, B show different fonts of what the letters can look like. There are a few Native American language articles that show what they look like.
• I didn't know about <samp>.

I will be bugging you later about some regexes. I'm porting over Checkwiki from toolserver to labs and cleaning some code. Sure is nice when you can replace 50 lines of code with one regex. There are going to be a few that are going to be way above my small brain. Bgwhite (Diskussion) 09:31, 12. Jul. 2013 (CEST)

I see. You are right, both <font face="…"> and <span style="font-style:…;"> should only be used in very, very few cases. Therefor it doesn't help much to add rules for these cases. Don't hesitate to ask your questions. I love to help with creating regexes. --TMg 19:46, 3. Aug. 2013 (CEST)

Eingedeutschtes CSS

Ich habe – neben den Namen der Spezialseiten – noch eine weitere Zwangseindeutschung gefunden, die sogar mir zu weit geht.

• baseline, grundlinie
• bottom, unten
• middle, mitte
• sub, tiefgestellt, tief
• super, hochgestellt, hoch, sup
• text-bottom, text-unten
• text-top, text-oben
• top, oben

Das sind Werte der CSS-Eigenschaft vertical-align, die in jeder CSS-Dokumentation stehen. Wer kommt auf die Idee, für etwas seit 1996 Bestehendes, das von Außerhalb der Wikisoftware kommt, neue Wörter zu erfinden? Weiteres:

• hochkant kann man auch mit Leerzeichen verwenden. Decke ich das ab? erledigtErledigt
• verweis finde nicht nur ich hässlich und unnötig; link ist genauso ein deutsches Wort.
• alternativtext finde ich in Ordnung, würde es aber nie einsetzen, weil das bekannte HTML-Attribut auch nur kurz alt lautet.

--TMg 02:05, 3. Jul. 2013 (CEST)

Passt hier zwar nur bedingt zum Thema, aber kann mittlerweile nicht auch standardmäßig miniatur in mini geändert werden? Momentan wirds glaub ich nur geändert, wenn sowieso eine weitere Änderung an den Datei-Parametern erfolgt, oder? Hab zwar keine Zahlen parat, aber mini scheint mir doch weitaus häufiger als miniatur (als thumb-Übersetzung) benutzt zu werden. --BlueCücü (Diskussion) 20:58, 3. Jul. 2013 (CEST)

Der Trend geht definitiv zu mini, ja, und ich bevorzuge es auch, wo immer es geht. Aber ich will keine plumpe Ersetzung, die keinerlei Wirkung hat, außer die Versionsvergleiche unübersichtlich zu machen. Warten wir mal noch ein paar Monate, dann baue ich vielleicht eine Regel ein, die einen Artikel bei gemischter Verwendung von miniatur und mini vereinheitlicht. --TMg 01:19, 4. Jul. 2013 (CEST)

Script stellt Quelltext um

Hallo, im Artikel über die Insel Norderney gibt es eine Miniaturansicht mit eingebauter Farblegende. Wird das Script ausgeführt, so stellt dieses die Formatierung um, so dass die Tabelle nicht mehr richtig angezeigt wird.

Übersichtskarte der Schutzzonen des Nationalparks Niedersächsisches Wattenmeer auf und um Norderney

---

Stadtfläche Hellerfläche

Dünen Strand

Das Script baut die ersten drei Zeilen zu einer zusammen:

[[Datei:Karte Insel Norderney Nationalparkzonierung.png|mini|links|Übersichtskarte der Schutzzonen des Nationalparks Niedersächsisches Wattenmeer auf und um Norderney
----
{|style="background:none;"|-|style="vertical-align:top; width:50%;"{{Farblegende|#BFA9B6|Stadtfläche}}
{{Farblegende|#CBE3C1|Hellerfläche}}
|style="vertical-align:top; width:5px;"|
|style="vertical-align:top; width:50%;"|
{{Farblegende|#ECE6BE|Dünen}}
{{Farblegende|#FFF9C4|Strand}}
|}]]

Die angezeigte Fehlermeldung lautet: Bildparameter nicht erkennbar Übersichtskarte der Schutzzonen des Nationalparks Niedersächsisches Wattenmeer auf und um Norderney ---- { (Datei:Karte Insel Norderney Nationalparkzonierung.png).

Vielleicht kann einmal danach geschaut werden? Danke und Gruß, Elvaube ?! 16:13, 4. Jul. 2013 (CEST)

Ich bin komplett ratlos. Ich kann es nicht nachvollziehen, nicht mit deiner common.js, nicht mit WSTM (das du parallel nutzt), nicht mit alten Versionen meines Skripts. Ich habe auch keine Idee, welche Regel für das Entfernen von Zeilenumbrüchen verantwortlich sein könnte. Passierte das nur mit einer bestimmten Version des Artikels Norderney oder mit der jetzt aktuellen immer noch? Bist du sicher, dass es beim Drücken des gelben Besens passiert? Passiert das auch mit dem Beispiel, das du hierher kopiert hast? Kannst du mal das Neuladen aller Skripte erzwingen? PS: Ich habe den Kollegen informiert. --TMg 19:30, 4. Jul. 2013 (CEST)

Das ist mit Sicherheit WSTM (leider für mich reproduzierbar).

• WSTM sucht die schließenden eckigen Klammern der Bildeinbindung. Wobei die Pipes ja immer Parameter der Bildeinbindung voneinander trennen würden. Und hier sind sehr viele Pipes in der Tabelle.
• WSTM kommt mit Kommentaren und Vorlagen und nowiki und Bildeinbindungen innerhalb der Bildlegende zurecht. WSTM erkennt auch, dass es eine Tabelle gibt, weil ein scheinbarer Bldparameter lautet oder endet auf: Zeilenumbruch+{ und sucht dann das Ende dieser Tabelle. Aber das hier ist die komplizierteste Bildlegende, die WSTM und ich bisher gesehen haben, und wir werden uns daran weiter verbessern. Sie enthält dann auch noch ein paar Vorlageneinbindungen zum Überspringen.
• Nebenbei: Unter der Fehlermeldung steht als letzte Zeile -- WikiSyntaxTextMod (PerfektesChaos).

Ich werde mich also um Abhilfe bemühen, empfehle für die Bearbeitung dieses Artikels (oder nur Abschnitts) WSTM vorübergehend auszukommentieren und das zu tun, was beabsichtigt war.

(Mal interessehalber gefragt: Was stellt eigentlich VisualEditor an, wenn dieses Bild bearbeitet wird?)

Erstmal sorry für die Umstände --PerfektesChaos 23:11, 4. Jul. 2013 (CEST)

Ich muss ja zugeben, das es sich bei meinem Konstrukt um einen sehr experimentellen Einzelfall (?) handelt, der sicherlich kein Standard ist. Von daher kann ich nachvollziehen, wenn es zu Problemen kommt. Ich habe dies schon seit längerem und dachte mir, ich informiere euch mal. Vielleicht macht es in Zukunft mehr Sinn, die Farblegende in der Bildbeschreibung unter commons anzeigen zu lassen. Gruß, Elvaube ?! 17:14, 5. Jul. 2013 (CEST)

Der Visual Editor zeigt die Miniatur des Bildes an mit einer geschlossenen, geschweiften Klammer (}) darunter. Gruß, Elvaube ?! 17:25, 5. Jul. 2013 (CEST)

Grundsätzlich muss WSTM mit diesem Konstrukt von alleine klarkommen; den Bug habe ich inzwischen gefixt und bin in der Erprobung. Ende kommender Woche sollte es live sein.

Was dieses spezielle Minibild angeht: Nun, ich sehe, dass da links eine Stadt ist, und dann so grün-gelb. Aber was nun Düne ist und was Strand, das offenbart sich erst bei Klicken auf eine höhere Auflösung, und das bräuchte schon eine Seite auf Commons; gewissermaßen vielleicht eine Galerie mit nur einem Bild. Insofern kann in der Tat bei der mini-Vorschau die Legende entfallen.

VE: Und? wenn du es abspeicherst, versaut er die Tabelle dann auch so schön wie WSTM es bislang tat?

Sonniges Wochenende und frischen Seewind --PerfektesChaos 12:33, 6. Jul. 2013 (CEST)

Hallo zusammen, bevor ich das hier vergesse: Es funktioniert mittlerweile. Gruß und Danke für die schnelle Reaktion, Elvaube ?! 16:24, 29. Jul. 2013 (CEST)

autoFormatter und nbsp

Hi TMg, kannst du mir erklären, warum der autoFormatter etwa z. B. als z.B. liest? Auf meiner common.js habe ich definiert, dass z.B. zu z. B. formatiert werden soll – es handelt sich dabei um formatierte geschützte Leerzeichen – jedoch macht er das jetzt auch mit z. B.. Wenn man beispielsweise z. B. in z. B. formatiert, sieht man einen Unterschied im Quelltext und kann sich dabei vielleicht etwas denken, wenn ein   durch ein scheinbar gewöhnliches Leerzeichen ersetzt wird, werden jedoch viele Menschen irritiert. Sollte es nicht anders lösbar sein, werde ich wieder mit   arbeiten, jedoch das formatierte nbsp etwa bei Angaben wie i. V. m. w. N. (i. V. m. w. N.) oder §&nbsp;226 Abs.&nbsp;1 Nr.&nbsp;2 Alt.&nbsp;2 (§ 226 Abs. 1 Nr. 2 Alt. 2) weiterhin verwenden. Den Großteil der nbsp im Zusammenhang mit Gesetzesangaben stammt ohnehin von mir… hätte ich dieses andere nbsp doch nur vorher gekannt. Gruß – CherryX ^sprich! 19:21, 13. Jul. 2013 (CEST)

Ich würde mal behaupten, dass von 1000 Wikipedianern vielleicht ein oder zwei verstehen, wovon du redest. Du weist das Skript an, die in deiner common.js aufgezählten Abkürzungen auf eine Schreibweise mit Leerzeichen zu vereinheitlichen, und das macht das Skript auch. Nachvollziehen geschweige denn verstehen kann das, was du da gemacht hast, anschließend kaum einer mehr. Ich kann dir auf Anhieb nicht sagen, wo die Richtlinie steht, aber es ist projektweit Konsens, das geschützte Leerzeichen aus diesem einfachen Grund niemals als Unicodezeichen zu schreiben sondern immer als  . Es wäre lieb, wenn du das ebenfalls durchgängig so machen könntest, sonst entsteht nur unnötiges Hin- und Hergeändere von der einen Form in die andere und zurück. --TMg 15:11, 14. Jul. 2013 (CEST)

Ich hoffe, meine recht barsch klingende Antwort ist nicht falsch angekommen. Ich will das Zeichen nicht pauschal verbieten. Zukünftig kann es durchaus gewollt sein, Stichwort Visual Editor. Es pauschal zu entfernen, wäre noch störender, als das Zeichen einfach stehen zu lassen. Aus dem selben Grund möchte ich das benutzerdefinierte Ersetzen von   durch das Zeichen auch nicht verbieten. Oder doch? Außerdem in dem Zusammenhang aufgefallen:

• In benutzerdefinierten Suchmustern muss „z.\xA0B.“ berücksichtigt werden. erledigtErledigt
• In Dateinamen \xA0 und %C2%A0 sowie %5F säubern. erledigtErledigt
• Ich darf 1\n\nJuli 2001 nicht kaputt machen. erledigtErledigt
• \xA0 in alle Regeln einbauen, die mit Vorlagen zu tun haben; sowohl bei Parametern (Beispiel) als auch Werten (dort natürlich nur vom Anfang/Ende trimmen). erledigtErledigt
• \xA0 pauschal vom Zeilenende trimmen? Ergibt doch niemals Sinn, wenn dahinter sowieso ein Umbruch folgt, oder? erledigtErledigt
• Auch U+2000 bis U+200D und U+202F vom Zeilenende trimmen? erledigtErledigt

--TMg 10:24, 15. Jul. 2013 (CEST)

1. Der Benutzer ist (wohl aus anderen Gründen) seit einigen Tagen infinit inaktiv.
2. Unsichtbare Zeichen sind mit extrem seltenen Ausnahmen in definitiv nichtlateinischen Schriftsequenzen für alle Benutzer sichtbar zu machen; heißt Entity. Es kommt sonst durch C&P zur Verschleppung quer durch den Quelltext und zu unerklärlichen Effekten an anderen Stellen. Nur aus den letzten Wochen:
   • Kryptische Leerzeichen in Einzelnachweisen
   • WP:Technik/Werkstatt #Die Tücken der bedingten Trennstriche
   • WP:WikiProjekt Vorlagen/Werkstatt/Archiv 2013/2 #Das hier …

VG --PerfektesChaos 10:53, 15. Jul. 2013 (CEST)

Danke fürs Drüberschauen. Den „schüchternen“ Trennstrich (U+00AD) mache ich bereits ausnahmslos sichtbar. Über das unsichtbare Leerzeichen (U+200B) und das Links-nach-rechts-Zeichen (U+200E) hatten wir uns schon unterhalten und ich denke, wir sind uns da einig, auch wenn unsere Herangehensweisen verschieden sind (und ich immer noch meine, dass du mich irgendwie falsch verstanden haben musst). Weitere Zeichen möchte ich ungern pauschal durch named entities ersetzen. Ein z. B. im Quelltext ist zwar nicht erwünscht, aber auch nicht falsch. Dass man das durch Kopieren woanders hin schleppt, wo es falsch wäre, scheint mir unwahrscheinlich. Unübersichtliche Versionsvergleiche fände ich schlimmer. Ein paar möglicherweise eindeutige Fälle, über die ich nachdenken werde, habe ich oben ergänzt. --TMg 14:15, 15. Jul. 2013 (CEST)

Wenn autoFormatter innerhalb von z. und B. usw. das Ding duldet und es in allen sonstigen Zusammenhängen (zwischen Wörtern, an allen Klammern, am Zeilenende oder Leerzeichen benachbart) sichtbar macht, kann ich damit leben. Ich habe sowieso keinen Einfluss darauf.

• WSTM macht es außerhalb nichtlateinischer Umgebungen immer sichtbar, und Krdbot macht auch vieles sichtbar.
• Der nächste ungeskriptete Autor kann die Leerzeichen ohnehin nicht unterscheiden, sieht die Lücke zwischen z. und B. und setzt das Entity dazwischen; egal was da war.
• Das ist bekanntlich eh’ alles für die Katz: Wikipedia:Typografie/Automatische Leerzeichen
• OT: Falls du jemandem die Extension:Labeled Section Transclusion erklären möchtest, rate ich zu H:section.

Gute Nacht --PerfektesChaos 00:37, 17. Jul. 2013 (CEST)

• Wenn ein Autor ein   einsetzt, wo es erwünscht ist, ist das immer in Ordnung, unabhängig davon, ob das mit Skripthilfe geschah und unabhängig davon, welches Zeichen zuvor dort stand. Das taugt deshalb nicht so recht als Argument.
• Zum automatischen Umbruchschutz hatte ich mich ja schon dort geäußert. Ich meine, dass das niemals alle Fälle abdecken kann. Wir werden immer mit   hantieren müssen, wenn auch weniger.
• Ich kann nicht sagen, wie das passiert ist, aber das pauschale Ersetzen geschützter durch normale Leerzeichen fände ich nicht in Ordnung.

--TMg 15:02, 17. Jul. 2013 (CEST)

@wie das passiert ist: Ich setze auf Diskussionsseiten von meiner Seite keinerlei Skripte ein und weiß es auch nicht. Allerdings gibt es Browser-Versionen (war FF22) wie früher der IE, die das \xA0 durch Leerzeichen ersetzen. Vielleicht macht WikEd das von sich aus? Ich habe keine Test-Seiten. Unabhängig davon zeigt es, wie wacklig es ist, sich auf die Unterschiedlichkeit von \xA0 und \x20 zu verlassen; insbesondere wie eingangs propagiert die &nbsp; durch \xA0 zu ersetzen.

VG --PerfektesChaos 11:24, 18. Jul. 2013 (CEST)

Hi, die letzten Wochen war ich inaktiv und lese deine Antwort jetzt erst – danke dir; ich arbeite dann nach wie vor mit dem sichtbaren nbsp. Gruß – CherryX ^sprich! 08:33, 28. Jul. 2013 (CEST)

Freut mich, dass wir uns auf eine gemeinsame Linie einigen konnten. Bleiben noch die unten aufgezeigten Fälle. --TMg 12:22, 1. Aug. 2013 (CEST)

Vorschlag: Leerzeile zwischen Normdaten und Sortierung

Da der Sortierschlüssel + Kategorien (meiner Meinung nach) als Einheit für sich stehen sollte, wäre generell ein Leerzeile vor "SORTIERUNG" sinnvoll. Falls nur explizite Fälle möglich sind, dann wäre das automatische Einfügen einer Leerzeile zwischen den Vorlagen {{Normdaten|......}} und {{SORTIERUNG:........}} ganz nett, da dieser Fall verhältnismäßig häufig vorkommt. (nicht signierter Beitrag von BlueCücü (Diskussion | Beiträge) 22:00, 12. Jul. 2013‎)

Mach ich. Mit Regeln in der Form „immer ersetzen, außer in folgenden Fällen“ gibt es grundsätzlich zu viele Fehlersetzungen, deshalb habe ich inzwischen fast alles auf „nur in folgenden Fällen ersetzen“ umgestellt. Das halte ich erst recht bei solchen Regeln für wichtig. --TMg 15:11, 14. Jul. 2013 (CEST)

Okay. Falls mir noch weitere häufig auftretende Fälle ein-/auffallen, dann meld ich mich. --BlueCücü (Diskussion) 08:52, 15. Jul. 2013 (CEST)

Geschütztes Leerzeichen nicht im Sortierschlüssel einfügen

Hier wird ein geschütztes Leerzeichen im Sortierschlüssel eingefügt. (Im zweiten Schritt wird „&“ dann zu „und“.) Kann man das Einsetzen der gesch. Leerzeichen vielleicht für die Sortierschlüsselzeile verbieten. --BlueCücü (Diskussion) 09:26, 15. Jul. 2013 (CEST)

Nicht perfekt gelöst, weil „2m“ in Sortierschlüsseln noch zu „2 m“ werden kann, für diesen Fall reicht es aber. --TMg 22:11, 15. Jul. 2013 (CEST)

Gilgi – eine von uns

Hallo, den gelben Kehrbesen wende ich ja oft und gern an. Aber bei o.g. Artikel kommen 2 failures:

• Die Kategorien sind weg
• <references/> muß weiter oben im Artikel steht, sonst plauzt es.

Die Erklärung der Phänomene interessiert mich. Gruß --Hedwig Storch (Diskussion) 20:22, 15. Jul. 2013 (CEST)

Faszinierend. Vielen lieben Dank für die Meldung, das ist sehr nützlich. Das Geheimnis ist die ISBN, die auf --> endet. Das macht mein Skript aus Versehen kaputt. Ich kümmere mich darum. Bis dahin hilft es, zwischen ISBN und --> ein Leerzeichen einzufügen. --TMg 21:26, 15. Jul. 2013 (CEST)

Vielen Dank für die umgehende Hilfe. Nachdem ich die überflüssige Lit.stelle entfernt hatte, kehrte der Besen wie gewohnt (gestern hatte ich ziemlichen trouble, als die Kategorien weg waren. Nun ist alles wieder in Butter).Gruß --Hedwig Storch (Diskussion) 09:25, 16. Jul. 2013 (CEST)

Hesperus oder 45 Hundposttage

Hallo, gerade mal jetzt habe ich Deinen gelben Besen auf o.g. Artikel angesetzt. Warum werden in „...ist Viktor Sebastian – wie die beiden Vornamen sagen – Sieger und Märtyrer zugleich.“ die beiden „-“ nicht mehr, wie bisher, in hübsche „breite -“ (ich meine –) gewandelt? Gruß --Hedwig Storch (Diskussion) 10:20, 18. Jul. 2013 (CEST)

Hm, bei mir gibt es da kein Problem. Vielleicht hattest du noch etwas markiert? Dann formatiert der Besen nur die Markierung. --TMg 10:31, 18. Jul. 2013 (CEST)

Ich habs jetzt wiederholt, garantiert ohne Markierung. Es ging wieder nicht. --Hedwig Storch (Diskussion) 12:38, 18. Jul. 2013 (CEST)

Jetzt probiere ichs mal hier: * Nach Schulz<ref>Schulz, S. 340</ref> ist Viktor Sebastian – wie die beiden Vornamen sagen – Sieger und Märtyrer zugleich. Wow, hier funktionierts. --Hedwig Storch (Diskussion) 12:40, 18. Jul. 2013 (CEST)

Wenn ich den Artikel bearbeite – egal ob den ganzen oder nur den Abschnitt – und dann den Besen drücke, funktionierts. Hast du mal den Cache geleert? Welchen Webbrowser verwendest du? Klappt es, wenn du im Artikel nur den fraglichen Abschnitt markierst und dann den Besen drückst? --TMg 15:04, 18. Jul. 2013 (CEST)

Den Firefox Cache habe ich geleert und den Besen nur auf den Abschnitt angewendet. Das klappt. Für größere Abschnitte wirkt der Besen nicht. --Hedwig Storch (Diskussion) 11:46, 19. Jul. 2013 (CEST)

Ehrlich, ich habe alles durchprobiert, was mir einfiel, auch nochmal mit Firefox, aber bei mir klappt es immer. Ist es bei dir nur dieser eine Artikel oder tritt das auch anderswo auf? Kannst du bitte folgendes probieren:

1. Klicke bitte hier.
2. Aktiviere in deinem Firefox im Menü unter „Web-Entwickler“ die „Web-Konsole“.
3. Drücke in der Web-Konsole auf den Knopf „Leeren“.
4. Dann den Besen drücken. Wird der Besen grün oder grau? Erscheint in der Web-Konsole etwas? Werden im Quelltext im Literaturabschnitt die ISBNs formatiert? (Gleich die erste müsste von „ISBN 3596109736“ zu „ISBN 3-596-10973-6“ werden.)

--TMg 14:26, 19. Jul. 2013 (CEST)

Hallo, wie ich schon sagte, der Effekt tritt in dem Gilgi-Artikel auf. Sonst bin ich mit Deinem Tool zufrieden und verwende es auch fast täglich weiter. Nach Durchlaufen obiger Vorschrift bleibt der Besen gelb und der Bildschirm mit den Ausschriften in der Web-Konsole sieht so aus:

Hesperus. Die erste ISBN wird nicht berichtigt. Grüße --Hedwig Storch (Diskussion) 20:19, 21. Jul. 2013 (CEST)

Grundgütiger, das ist vielleicht nervig. :-( Ich kann es immer noch nicht genau so wie bei dir nachvollziehen, aber ich habe eine Idee. Das Bild war sehr hilfreich, danke. Prüfe bitte, ob du die seit ein paar Tagen neuen „Eingabewerkzeuge“ aktiviert hast und wie die bei dir eingestellt sind. Leider sind die in den „Einstellungen“ nicht zu finden. Beim Bearbeiten taucht in der Ecke des Bearbeitungsfensters kurz ein Tastatursymbol auf. Du musst schnell genug sein, das zu treffen. Oder du nimmst das Zahnradsymbol links in der Seitenleiste bei den „Sprachen“. Am besten deaktivierst du die „Eingabewerkzeuge“ komplett, wenn du sie nicht brauchst. Danach bitte nochmal obige Schritte durchprobieren. --TMg 15:17, 22. Jul. 2013 (CEST)

Der Tip war gut. Unter Spracheinstellungen (links) habe ich die Eingabewerkzeuge deaktiviert. Jetzt funktioniert es wieder (ISBN Korr. und breites -). Gruß --Hedwig Storch (Diskussion) 17:32, 22. Jul. 2013 (CEST)

Umformatierung von Einzelnachweisen

Hallo, TMg. Läßt sich das Programm so (vor)einstellen, dass es Sachen zwischen zwei Ref-Tags ignoriert und so belässt wie sie sind? -- Serienfan2010 (Diskussion) 16:28, 22. Jul. 2013 (CEST)

Bitte zeige mir am besten das ganz konkrete Beispiel und die ganz konkrete Umformatierung, die das Skript deiner Meinung nach lieber nicht machen sollte. Ich schau mir das sehr gern an, denn eins meiner Ziele ist ja auch, dass das Skript niemandem auf die Nerven geht. --TMg 16:58, 22. Jul. 2013 (CEST)

Also auf die Nerven geht es mir nicht, allerdings sollten Quellen so viel ich weiß ja so belassen werden wie sie eben formatiert sind. Hier ein Beispiel. Es wird von "" auf „“ und der Strich (–) auf bis geändert. -- Serienfan2010 (Diskussion) 17:06, 22. Jul. 2013 (CEST)

Zum Teil ändert das Skript da wirklich etwas viel, zum Teil ist das aber in Ordnung. Falsche Bis-, Gedankenstriche und Anführungszeichen dürfen auch in Zitaten, Buchtitel etc. korrigiert werden. Das ist keine Verfälschung. Unter Wikipedia Diskussion:Zitate gab es kürzlich eine längere Diskussion dazu. Mit dem Ausschreiben des Datums verhält es sich etwas anders. Das Datumsformat sollte vor allem in Buchtiteln unverändert bleiben. Im gezeigten Beispiel handelt es sich aber nur um eine Webseite, bei der ich das nicht so kritisch sehen würde. Einzelnachweise ganz auszuklammern, wäre keine gute Idee, da dann auch erwünschte Datumsformatierungen nicht mehr stattfinden. Ganz unabhängig davon: Ich finde, Formulierungen mit „soll“ sind sehr ungeschickt. Das Problem ist, dass diese Formulierung am Stichtag veraltet sein wird und für den Leser lächerlich klingt. Ein „wurde angekündigt“ kann dagegen notfalls auch mal ein paar Tage stehen bleiben und klingt nicht lächerlich veraltet, weil etwas im Sinne von „wurde für gestern angekündigt“ ja nicht falsch wird. Die Ankündigung lautete so, egal wann man das liest. --TMg 17:53, 22. Jul. 2013 (CEST)

Ok, danke für deine ausführliche Antwort. Wenn das so kein Problem darstellt, dann lass es einfach so. Ich hatte zwar nicht um Hilfe bei Formulierungen gebetten, aber trotzdem auch hier ein danke. Ich werde in Zukunft mal auf meine Formulierungen achten. Allerdings ist das Problem mit der Unaktualität im Fernsehbereich, zumindestens bei von mir beobachteten Seiten, sehr gering bis gar nicht vorhanden. Es finden sich fast immer welche die das meistens direkt während oder nach der Ausstrahlung korrigieren. Das aber nur als Hinweis. -- Serienfan2010 (Diskussion) 18:07, 22. Jul. 2013 (CEST)

mini statt miniatur

Hallo, wieso ersetzt das Script bei Bildern „miniatur“ mit „mini“? Die Standardeinstellung (etwa bei der Bearbeitungsleiste) ist ja eigentlich miniatur.--CENNOXX 23:53, 23. Jul. 2013 (CEST)

Das mit der Werkzeugleiste wusste ich gar nicht. Seltsam. Da wurde wohl eine Anpassung vergessen. Mini wurde als Konsens eingeführt, um die ewigen Diskussionen um miniatur vs. thumb aufzulösen, und so weit mir bekannt auch sehr schnell breit akzeptiert. Siehe etwa Hilfe:Bilder. Diskussionen dazu waren zahlreich, deshalb wundere ich mich etwas, dass das an dir vorbei gegangen sein sollte. Trotzdem ersetzte ich nicht pauschal miniatur durch mini, da das ja gar nichts bringt und nur die Versionsvergleiche unübersichtlich macht. Das wäre ein Fehler, wenn du das beobachtet hast. Ich bevorzuge aber mini, wenn sowieso andere Änderungen an einer Bildeinbindung anstehen. --TMg 00:10, 24. Jul. 2013 (CEST)

Ich hab nochmal recherchiert. Der Knopf in der Werkzeugleiste ruft zur Ermittlung des Schlüsselworts einfach mw.config.get('wgWikiEditorMagicWords').img_thumbnail auf (Quelle). Das gibt den ersten Wert zurück, der in den Spracheinstellungen hinterlegt ist. Im Deutschen sind das „miniatur“, „mini“, „thumbnail“ und „thumb“ (Quelle), im Englischen nur „thumbnail“ und „thumb“ (Quelle). Das heißt, dass selbst die englischsprachige Wikipedia witzigerweise das Problem hat, dass die Werkzeugleiste das falsche Schlüsselwort einfügt, obwohl in sämtlichen Anleitungen (en:WP:Manual of Style/Images, en:WP:Picture tutorial etc.) ausschließlich von „thumb“ die Rede ist. Oder anders gesagt, die Werkzeugleiste ist nicht ausschlaggebend. --TMg 18:41, 24. Jul. 2013 (CEST)

Bei Hilfe:Bilder wurde miniatur ohne eine vorherige Diskussion (jedenfalls nicht auf der Diskussionsseite) durch mini ersetzt. Woran siehst du, dass das mittlerweile Konsens sein soll? Wo gabs dazu Diskussionen? FzW? Eine breite Akzeptanz von mini sehe ich nicht.--CENNOXX 13:46, 27. Jul. 2013 (CEST)

Ach komm schon. Wir sollten vereint gegen die wenigen Verfechter englischer Schreibweisen im Artikelnamensraum auftreten und uns wegen so etwas nicht das Leben gegenseitig schwer machen. Die Diskussion dazu fand dort statt. In vielen auch früheren Diskussionen wie den im Kurier zahlreich und lautstark geführten oder dieser dort wurde immer wieder von beiden Seiten betont, dass „mini“ der perfekte Kompromiss wäre. WikiSyntaxTextMod macht es wie ich. Auch dass die Änderung der Hilfeseite ein Jahr lang unangefochten blieb, deute ich als weiteren Beweis dafür, dass es ein sehr guter Konsens ist und ich finde es nicht gut, dass du das jetzt zurück geändert hast. Ich würde mich wirklich freuen, wenn wir uns da auf eine gemeinsame Linie einigen könnten. --TMg 11:13, 6. Aug. 2013 (CEST)

Ich hab meine Änderung auf Hilfe:Bilder wegen der Diskussion auf WP:Verbesserungsvorschläge wieder rückgängig gemacht. Eindeutig scheint mir da die Diskussion da aber nicht wirklich gewesen zu sein. In der von dir aufgeführten Diskussion wird auch nicht „von beiden Seiten betont“, dass „mini“ der „perfekte Kompromiss“ wäre. Ich les da zu „mini“ lediglich ein „hätte“/„würde“. Auch dass die Änderung auf der Hilfeseite unangefochten blieb, halte ich nicht für aussagekräftig. Meine vorherige Änderung hat auch niemand mitbekommen.

Auf Hilfe:Bilder habe ich nichts „jetzt“ auf miniatur zurückgeändert sondern vor 2 Monaten, also noch vor dieser Diskussion. Ich hätte das nicht mitten in einer Diskussion geändert. Sowas gehört sich (meiner Meinung) nicht.

Ich werd ab jetzt „mini“ nicht mehr in „miniatur“ ändern. Allerdings werde ich auch weiterhin kein „miniatur“ in „mini“ ändern. Ich halte das für kein Problem. Formatierungen von Belegtiteln übernahm ich noch nie. Nicht bei jeder Sache muss man sich auf eine gemeinsame Linie einigen, ich fasse die Änderungen deines Scriptes als Vorschläge auf. Ich bin dankbar dafür, übernehme aber nicht alle. Das werde ich so beibehalten.--CENNOXX 19:15, 7. Aug. 2013 (CEST)

Das sollte kein Vorwurf sein. Bitte entschuldige, wenn das so ankam. Du hast schon Recht. Dennoch ist mir wichtig, einen guten Konsens abzubilden, den jeder gern übernimmt, ohne dauernd etwas rückgängig oder gar das Gegenteil zu machen (wie leider bei dir, da deine Ersetzungsregeln aktuell alle „mini“ in „miniatur“ ändern). Das macht ja auf Dauer keinen Spaß. Wenn mir verstreut etwas zur „thumb“-Frage begegnete, hatte ich immer das Gefühl, dass „mini“ von beiden Seiten als gleichermaßen akzeptabler Kompromiss anerkannt wurde. Deshalb hatte ich mich angeschlossen und aufgehört, „miniatur“ einzusetzen. Der Prozentsatz geht stetig nach oben, und das kann nicht an mir liegen, weil mein Skript gar nicht so oft eingesetzt wird, dass es ausschlaggebend wäre. „miniatur“ ändere ich nicht in „mini“, außer es gibt sowieso eine Änderung an den Bildparametern. Siehe dazu auch BD:TMg/autoFormatter/Archiv#Eingedeutschtes CSS. Wenn dich etwas bestimmtes an meinem Skript stört, was du oft von Hand wieder zurück änderst, sag es bitte. Ich schaue gern, ob ich die entsprechende Regel entschärfen kann oder ob sich evtl. ein Konfigurationsschalter dafür lohnt. --TMg 20:25, 7. Aug. 2013 (CEST)

Sorry, wenn die Antwort vorhin etwas ruppig rüber kam. Keine Angst, ich tausch mini nicht mehr in miniatur. Was in meinen Ersetzungsregeln steht ist unerheblich. Von Bedeutung ist, welche Ersetzungen ich vornehme. Wenn eine Änderung zu umfangreich ist, markiere ich und setze das Script nur zum Teil ein. Ich übernehme die Änderungen wie gesagt nicht blind. Ich möchte aber auch weiterhin thumb nicht in mini, sondern miniatur ändern, daher meine Ersetzungsregel.--CENNOXX 22:02, 7. Aug. 2013 (CEST)

Ungewünschte Linkverkürzung

Mit dem Tool werden Links in der Art [[Wikipedia|Wikipedias]] ja umformuliert zu [[Wikipedia]]s, was natürlich sinnvoll ist. Anders sieht das Ganze allerdings aus, wenn ein Leerzeichen im Linktext steht, in diesem Fall ist eine Kürzung meist (oder sogar immer?) unerwünscht Bsp: [[Emmy|Emmy Awards]] wird nach Scriptausführung zu [[Emmy]] Awards. Kannst du Änderungen wie diese ausschließen?--CENNOXX 16:01, 27. Jul. 2013 (CEST)

Wenn wie hier ([[A|B]]) B eine Weiterleitung auf A ist, dann sollte vielleicht eher zu [[B]] geautoformatiert werden. Aber dies geht glaub ich über die Möglichkeiten des Scriptes hinaus, oder? --BlueCücü (Diskussion) 10:36, 28. Jul. 2013 (CEST)

• An sich stellt es technisch kein Problem dar, [[A|B]] zu prüfen und die API zu fragen, ob B als Weiterleitung nach A existiert. Das würde jedoch einigen Prinzipien meines Skripts widersprechen, zusätzliche Abhängigkeiten erzeugen und es komplizierter und spürbar langsamer machen. Ich kann mir vorstellen, die Arbeit mit Weiterleitungen und möglicherweise auch Begriffsklärungen als eine Art Add-on anzubieten. Aber wäre der Aufwand dafür gerechtfertigt? Dürfte dieses Add-on überhaupt automatisiert Linkziele verändern? Muss das nicht in jedem Fall einzeln geprüft werden?
• Mir ist bewusst, dass die Linkverkürzung zu den wenigen Details gehört, auf die ich immer mal wieder angesprochen werde. Auch wenn ich zugeben muss, dass du ein beachtenswertes Beispiel gefunden hast, möchte ich dennoch bei meiner allgemeinen Argumentation bleiben: Links wie [[Berlin|Berliner Mauer]] sind irreführend. Der Link erweckt den falschen Eindruck, dass er zu einem speziellen Artikel führen würde; statt dessen landet man bei der Einleitung eines viel allgemeineren Artikels. Es gibt drei bessere Arten der Verlinkung, die mein Skript selbstverständlich alle unangetastet lässt: Idealerweise existiert [[Berliner Mauer]] als Artikel. Dann ist der Eingriff des Skripts als Aufruf zu verstehen, den falsch zielenden Link zu korrigieren. Die nächstbessere Lösung ist, den Leser per [[Berlin#Berliner Mauer|Berliner Mauer]] direkt zu einem Abschnitt zu führen. Alternativ kann man per [[Berliner Mauer]] auf eine Weiterleitung verweisen, die ihrerseits wiederum nach [[Berlin#Berliner Mauer]] führt. Letzteres hat den Vorteil, dass jederzeit jemand einen Artikel aus der Weiterleitung machen kann, und dieser neue Artikel dann gleich überall richtig verlinkt ist.

Trifft das auf das Beispiel ebenso zu? Schließlich ist das kein über- oder untergeordnetes Thema sondern nur ein anderer Name für das selbe Ding. Ich sage: „Emmy-Awards“ ist dem Leser gegenüber fairer. Der Artikel heißt so. --TMg 14:49, 29. Jul. 2013 (CEST)

Hm, ich hatte mehrere Fälle, bei denen mir der unangetaste Link sinnvoller erschien. In dem Fall ist es für mich aber auch nicht möglich das als "benutzerdefinierte Ersetzung" wieder rückgängig zu machen, ohne gleich das ganze Script zu kopieren oder?--CENNOXX 16:05, 29. Jul. 2013 (CEST)

Ich argumentiere wie erklärt für „Emmy-Awards“, „Siemens AG“ usw. Die Artikel heißen so. Die Verlinkung ist simpel und ehrlich. Ich verstehe durchaus, dass „Emmy-Awards“, „Siemens AG“ usw. Vorteile haben (die Klickfläche wird vergrößert, der Zusammenhang als ein Begriff wird betont), aber das hebt die Nachteile (Irreführung, unnötig komplizierter Quelltext) nicht auf. Wenn du weitere gute Beispiele hast, würde ich sie gern sehen. Aber wie schon angedeutet ist mir in all der Zeit noch keins begegnet, das man nicht anders lösen könnte, wenn es darauf ankommt (z. B. [[Siemens#Geschichte|Siemens AG]] oder ''[[Siemens]] AG'' kursiv). Benutzerdefinierte Regeln für solche Fälle sind realisierbar. --TMg 16:34, 29. Jul. 2013 (CEST)

Okay. Ich halte Links wie [[Emmy|Emmy-Awards]] oder [[Siemens|Siemens AG]] für besser (natürlich nur, sofern kein sinnvoller Anker zur Verfügung steht). Ist wohl Meinungssache.--CENNOXX 23:16, 5. Aug. 2013 (CEST)

Ich möchte nur nicht, dass du deswegen einen Fork des Skripts aufmachst, das fände ich schlimm. Wie gesagt, ich mache die Verkürzung vor allem deswegen, weil ich schlimme Irreführungen wie [[Berlin|Berliner Fernsehturm]] auflösen will. Das Skript kann nicht unterscheiden, ob so ein Link im Einzelfall vielleicht doch nicht schlimm ist. Deswegen wird alles aufgelöst. Der Schaden ist minimal. Kein Link geht verloren. Kein Linkziel wird verändert. Ausnahmen kannst du dir einrichten. --TMg 10:47, 6. Aug. 2013 (CEST)

var autoFormatReplacements = [
	[/\[\[Emmy\]\]\W*Award/ig, '[[Emmy Award]]']
];

Auch ich habe mir das Tool angesehen, aufgrund der ungewünschten Linkverkürzungen werde ich es aber nicht oft einsetzten. Die Fehlverlinkungen sind zu häufig. In einem wahllos heraus gegriffenen Artikel Acetylsalicylsäure aus Thromboxan A₂ Thromboxan A₂ und in Wuppertal aus E/D/E Einkaufsbüro Deutscher Eisenhändler GmbH ein E/D/E Einkaufsbüro Deutscher Eisenhändler GmbH oder aus FOM Hochschule für Oekonomie & Management ein FOM Hochschule für Oekonomie & Management wird. Es ist einfach sehr häufig, dass eine eine Kurzform und eine Langform des Namens gibt. Wenn der Autor die Langform verlinken will - das muss man das respektieren (weil es meistens für das Verständnis des Textes hilft. Gibt es irgendwoe eine Option mit der ich das ungewünschte Verhalten abschalten kann? --Atamari (Diskussion) 17:35, 24. Dez. 2013 (CET)

Das Script kann nicht entscheiden ob Kurz- und Langform synonym sind. Angenommen es entsteht wirklich mal ein Artikel zum Thromboxan A2 (falls es mehrere Thromboxane gibt), dann wird im ASS-Artikel trotzdem weiterhin aufs Thromboxan verlinkt werden. Daher sollten Nichtsynonyme nicht versteckt werden. Ist Kurz- und Langform wirklich synonym und das eine keine Untereinheit vom anderen, dann sollte besser eine Weiterleitung von der Langform auf die Kurzform angelegt werden, so dass diese dann verlinkt werden kann, wenn gewünscht. --BlueCücü (Diskussion) 17:51, 24. Dez. 2013 (CET)

@Atamari: Wie ich etwas weiter unten schon schrieb, denke ich, dass diese Ersetzungsregel eine meiner nützlichsten ist. Sie macht das wahre Linkziel sichtbar. Die Vorteile, die das meist hat, erscheinen mir gewichtiger als die Unannehmlichkeit, die deine Beispiele zeigen. Allgemein solltest du dir bewusst machen, dass mein Skript grundsätzlich nur Vorschläge unterbreitet. Deshalb ist es ein Knopf der Werkzeugleiste und kein Bot. Es ist eine ganz entscheidende Funktion des Skripts, dass die Änderungen von einem Benutzer geprüft und ggf. auch mal verworfen werden. Ich bemühe mich zwar stets, Fehlersetzungen zu minimieren – schließlich will auch ich nicht dauernd Änderungsvorschläge des Skripts umständlich rückgängig machen –, aber ganz ausschließen kann und will ich das nicht. Dann würde das Skript keinen Sinn mehr ergeben bzw. ich könnte wie gesagt gleich einen Bot daraus machen. Die Änderung ist ein Vorschlag und ein Aufruf an den Bearbeiter, nach einer besseren Alternative für den verschleierten Link zu suchen. Will man eine lange Linkbeschriftung behalten, hat man mehrere Möglichkeiten:

• Verschiebe den Artikel, wenn die Langform der wahre Name ist.
• Benutze die Weiterleitung [[FOM Hochschule für Oekonomie & Management]] oder erstelle sie, wenn es sie noch nicht gibt. Das ist völlig legitim und oft sogar gewollt, um bspw. die Möglichkeit offen zu halten, aus der Weiterleitung einen eigenen Artikel zum Vorgänger machen zu können.
• Nutze einen Anker, um genauer zu zielen: [[FOM Hochschule#Geschichte|FOM Hochschule für Oekonomie & Management]]. Das lässt das Skript selbstverständlich unangetastet.
• Hebe den vollen Namen anders hervor: ''[[FOM Hochschule]] für Oekonomie & Management''.

Tipp: Wenn man einen Abschnitt markiert, bevor man den Knopf mit dem Besen drückt, wird nur der markierte Teil des Textes gesäubert. So kann man z. B. eigene Diskussionsbeiträge säubern sowie möglicherweise unübersichtliche Massenänderungen vermeiden, wenn man eigentlich nur einen Abschnitt bearbeiten wollte.

Ich verstehe allerdings auch sehr gut, dass bestimmte Änderungsvorschläge nerven können, wenn man sie zu oft rückgängig machen muss und eigentlich ganz andere Prioritäten hat. Ich habe deshalb eine Möglichkeit zum Deaktivieren dieser Regel eingebaut. Kopiere dazu die Zeile var autoFormatMaskedLinks = false; in deine common.js. @CennoxX: Für dich ist das vielleicht auch interessant. --TMg 15:57, 7. Jan. 2014 (CET)

Bis-Strich bei Seitenzahlen

Hier (Zeile 83) hat die automatische Ersetzung nicht funktioniert. --Seth Cohen 00:46, 13. Aug. 2013 (CEST)

Wieso sind die Seitenzahlen kursiv? So was „veredle“ ich aktuell nicht. Ich akzeptiere Punkt und Komma nach den Seitenzahlen, aber kein Hochkomma. --TMg 01:41, 13. Aug. 2013 (CEST)

Weiß ich nicht. Also bleibt’s dabei? --Seth Cohen 15:45, 13. Aug. 2013 (CEST)

Der Eintrag da widerspricht komplett unseren Richtlinien, siehe WP:LIT. Ich habe auch bei anderen Details schon so argumentiert, dass die automatisierte „Veredlung“ solcher Formatierungen den Eindruck erwecken könnte, das wäre erwünscht. Einfach die falschen Formatierungen korrigieren (Kommas und Punkte statt Gedankenstriche, nur den Titel kursiv) und nochmal den Besen drücken. Ich bitte zwar immer um Beispiele – auch hier wieder vielen Dank dafür –, aber eine Sonderregel, um die Kursivschreibung um ''Seite 86-101'' automatisiert zu entfernen, erscheint mir übertrieben. --TMg 16:19, 13. Aug. 2013 (CEST)

In Ordnung. Danke sehr. --Seth Cohen 17:52, 13. Aug. 2013 (CEST)

Hochgestellte Zahlen

<sup>2</sup> etc. durch die Zeichen ² und ³ ersetzen? Wenn ja, wie radikal? Generell, oder nur nach Maßeinheiten, also nach „m“, „mm“ usw.? --TMg 19:42, 13. Aug. 2013 (CEST)

Senf. --PerfektesChaos 22:53, 13. Aug. 2013 (CEST)

Danke. Im Augenblick gehe ich pauschal vor, weil ich das mit der „musikalischen Notation“ mangels Beispielen schwer nachvollziehen kann. Trifft das nur auf ³/₄-Takt etc. zu? Dann könnte ich eine einfache Ausschlussregel „nicht vor Schrägstrich“ ergänzen. Oder gibt es andere Fälle? --TMg 13:20, 5. Okt. 2013 (CEST)

Ja, Orgeln. Die haben gleichzeitig <sup>7</sup> und <sup>2</sup> – konsultiere mal die nächste Dorfkirche deiner Umgebung.

Ich fordere deshalb in WSTM Positivliste statt Ausschlussregel, und m² reichen eigentlich für den Hausgebrauch.

Selbst Maßeinheiten wie m² haben aber ihre Tücken:

• 1 Ws = 1 kg·m<sup>2</sup>·s<sup>−2</sup>

VG --PerfektesChaos 20:50, 5. Okt. 2013 (CEST)

Ich wurde auf ein Beispiel hingewiesen, aber eine Seite im Wikipedia-Namensraum habe ich dazu vergeblich gesucht. Gibt es keine? Bzgl. Positivlisten hast du natürlich Recht. Die Erfahrung habe ich schließlich selbst gemacht – die entsprechende Umstellung meines Skripts ist seit einer Weile abgeschlossen. Also doch nur in den gängigen Flächenmaßen? --TMg 15:58, 7. Okt. 2013 (CEST)

Alles, was über die haushaltsüblichen m² und m³ hinausgeht, steht im Verdacht, atomphysikalische, musikalische oder sonstwelche Notationen und Formeln zu sein. Und das kann man nur manuell und mit Hintergrundwissen auf Sicht ändern.

Bei autoFormatter hätte ich die Sorge, dass jemand den gesamten Artikel markiert und das auf alles anwendet, außer Tiernahrung. Und wer sich nicht wirklich damit auskennt, sollte die Atomphysik so lassen wie vorgefunden, es entsteht ja kein Schaden.

• 5 – Register (Orgel)#Repetition
• 3+33+0+1 – Nikolaikirche (Berlin)#Orgel
• 0+1+2 – Stadtkirche St. Jakobi (Chemnitz)#Glocken
• 0+1+2+3 – Herz-Jesu-Kirche (Dresden)#Geläut
• 1+3+Brüche – Schloßkirche (Chemnitz)#Orgel

VG --PerfektesChaos 21:58, 7. Okt. 2013 (CEST)

Ach herje, das auch noch. --TMg 23:49, 8. Okt. 2013 (CEST)

score tag

You need to add the <score> tag to the list of "Protect sections" (aka, code, pre, nowiki) to autoFormatter. Bgwhite (Diskussion) 11:07, 28. Aug. 2013 (CEST)

Seems I missed that in April. Thanks. --TMg

Entfernen von Leerzeichen am Anfang/Ende von Links

Überflüssige Leerzeichen am Anfang und Ende von Wikilinks könnten entfernt werden: [[ Link]], [[Link ]], [[ Link ]] und natürlich auch mehrfache Leerzeichen --> [[Link]]. Ein schönes Restwochenende wünscht, --BlueCücü (Diskussion) 20:13, 31. Aug. 2013 (CEST)

Wurde schon einige male angesprochen, siehe u. a. #Wikilinks oben. Ist leider nicht so einfach. Steht aber weiterhin auf meiner Merkliste. --TMg 22:06, 1. Sep. 2013 (CEST)

Datumsformat, fehlendes Leerzeichen zwischen Tag und Monat wird nicht eingefügt

Hier, im Artikel Vahrenwalder Kirche hat der autoFormatter versäumt im ersten Absatz bei […] Am 19.Mai 2013 […] einzufügen. Ich musste es manuell einfügen. --Betateschter (Diskussion) 21:54, 6. Okt. 2013 (CEST)

Interessant. Um diesen Fall kümmere ich mich bisher noch gar nicht, aber du hast Recht, das scheint sich sehr gut für eine Automatisierung zu eignen. Ich werde das bei Gelegenheit mal umsetzen. Danke für das Beispiel. --TMg 15:13, 7. Okt. 2013 (CEST)

en:Template:Dead link

Hi, just wanted to say thanks for this script. However, on the English Wikipedia, it changes the phrase 'dead link' to 'Toter link' which is not appropriate for the English Wikipedia. Can this be fixed? Thank you! Jmeeter (Diskussion) 04:14, 11. Nov. 2013 (CET)

Thank you very much for the hint. I missed this somehow. It's fixed now. --TMg 13:47, 11. Nov. 2013 (CET)

nbsp nicht in Weblinks

Hier möchte der autoFormatter ein geschütztes Leerzeichen in einen Link einfügen, der danach nicht mehr funktionieren würde. Ich hoffe hiermit weitergeholfen zu haben und verbleibe mit freundlichen Grüßen ;) --BlueCücü (Diskussion) 19:04, 11. Nov. 2013 (CET)

Beispiele brauche ich immer, danke. Eine Lösung wird schwierig, weil das Skript so etwas wie „13 ft/5 m“ auch am Satzende finden soll. Ich müsste entweder Satzenden oder Schrägstriche aus der Erkennung nehmen. --TMg 19:56, 11. Nov. 2013 (CET)

Ich habe das nun doch gelöst, indem ich keine Schreibweisen mit Schrägstrich mehr akzeptiere, da das in der Praxis sowieso kaum vorkommt. --TMg 00:59, 2. Dez. 2013 (CET)

Don't remove blank line

At en.wikipedia.org there should be two lines between categories and stub-templates. All stub templates at enwp ends with '-stub'. (Please add a talkback template att my talk page at enwp.) -Josve05a (Diskussion) 20:52, 4. Dez. 2013 (CET)

Thanks for the hint, I did not know that. I will fix it soon. Do you think it's a good idea to actually add these two lines if they are missing? --TMg 01:07, 5. Dez. 2013 (CET)

Yes it is a good idéa, sinc I know AWB does it. -Josve05a (Diskussion) 01:17, 5. Dez. 2013 (CET)

Still not done! See en:Dovşanlı and en:My Latest Novel. -Josve05a (Diskussion) 14:00, 9. Dez. 2013 (CET)

I'm trying to speed things up but some things need to be tested first. This fix is in the Beta branch. I will try to deploy it to the stable branch next weekend. --TMg 15:15, 9. Dez. 2013 (CET)

Don't change to 'to'

Please don't change John Doe (1 January 2000 - 1 March 2012) to John Doe (1 January 2000 to 1 March 2012) on en.wikipedia.org.

//Josve05a (Diskussion) 17:13, 5. Dez. 2013 (CET)

Date ranges with dashes are considered bad style in German. It seems it's valid in English. Again, thank you very much for the hint. I's fixed. --TMg 19:00, 5. Dez. 2013 (CET)

Year ranges

One more thing. According to this, it should not change 2002-03 to 2000-2003 either. (I.e. the 1939–45 war). -Josve05a (Diskussion) 22:21, 5. Dez. 2013 (CET)

I'm not sure about this one, sorry. I don't think it's forbidden to touch a probably misleading 1912–13 (could be 1912–1913 or 1912–2013). Does this replacement rule do any harm? I'm not aware of any. The MOS is not very clear, unfortunately. According to this section year ranges shouldn't be abbreviated. --TMg 17:28, 7. Dez. 2013 (CET)

I know. But since 1912-13 can mean both 1912-1913 and 1912-2013, then autoFormatter should not do this edit, since it is not clear. And one more thing. Some articles are named e.g. 'England in football 1912-13'. That autoFormatter shold not change the text in the article, wich would make the article look wierd, haveing one tile and another title inside bold in the text. England in football 1912-1913. So to be on the safe side autoFormatter should not make this edit automatically. -Josve05a (Diskussion) 21:23, 7. Dez. 2013 (CET)

It tried to change [[Category:Moldovan MPs 1917–18]] to [[Category:Moldovan MPs 1917–1918]]. -Josve05a (Diskussion) 10:43, 9. Dez. 2013 (CET)

I will look into some of these cases, especially the broken category. Again, thank you very much. Please keep reporting. However, even if "to be on the safe side" is a good advice, it can't be top priority. I would need to remove every second rule "to be on the safe side". This wouldn't make much sense. Please keep in mind: you are responsible for your edits, not the script. :-) What the script does are suggestions. If it suggests to change "1912–13 in English football" to "1912–1913 in English football" you should consider moving the article. You are right, it's not clear, but "1912–13" means "1912–1913" in almost all cases. Very few people live longer than 100 years. ;-) I'm not touching "2000–07" for an other reason: it could mean "July 2000". --TMg 15:08, 9. Dez. 2013 (CET)

Thanks for that long answer. :-) It also changed tried to (I did not save) [[Indian cricket team in Pakistan in 1989–90]] to [[Indian cricket team in Pakistan in 1989–1990]]. -Josve05a (Diskussion) 15:14, 9. Dez. 2013 (CET)

Yes, it's probably a bad suggestion to change a link target. I will try to balance this rule somehow without removing it completely. Thanks for the example. --TMg 15:19, 9. Dez. 2013 (CET)

I did not changed everything but what I consider most important. Your "bold title" example is not a problem, if you ask me. In such rare cases you can move the article or undo the scripts suggestion. --TMg 23:52, 9. Dez. 2013 (CET)

(I know that I am a pain in the a**, but...) It tried to change 20 January 1909 – 23 July 1996 to 20 January 1909–1923 July 1996. -Josve05a (Diskussion) 15:20, 10. Dez. 2013 (CET)

Wow, that's an other error. Not sure how to fix this. You see, that's why using the dash between a year and a day is forbidden here in the German Wikipedia. Wouldn't be a problem with "to". --TMg 17:50, 10. Dez. 2013 (CET)

I found a surprisingly simple solution to solve this problem. --TMg 15:34, 15. Dez. 2013 (CET)

Image namespace alias

Don't change Image:Filename.jpg to File:Filename.jpg Using Image is ok at enwp. -Josve05a (Diskussion) 18:51, 6. Dez. 2013 (CET)

Sure, it's not forbidden to use Image. Same here in the German Wikipedia. But it's not forbidden to change the old, probably misleading alias Image to the true name of the namespace either. If you want you can add the line var autoFormatLocalisation = false; to your local common.js to turn off the feature. --TMg 17:28, 7. Dez. 2013 (CET)

Shortening link titles

Don't change e.g. [[New Laws|New Laws of Indies]] to [[New Laws]] of Indies-Josve05a (Diskussion) 18:51, 6. Dez. 2013 (CET)

I'm aware this feature is disputable. We are discussing this every now and then (e.g. 2007 and most recently). I would like to stick with my reasoning: I consider the benefits of this replacement rule much more important than the oddities. The name of the article is "New Laws". What's the benefit of changing the title to something else? Most users expect a link to open an article with that name. If a user copies the title "New Laws of Indies" and uses it as a link in an other article he will get a broken link for no obvious reason. You have many possibilities to make such misleading links better:

• Move the article: [[New Laws of Indies]]
• Create a redirect: [[New Laws of Indies]]
• Use an anchor. The script will not touch this: [[New Laws#Legacy|New Laws of Indies]]
• Highlight the full name: ''[[New Laws]] of Indies''

I could add a per-user setting to disable this rule. But I think this would be a shame because I consider this one of my most valuable replacements. --TMg 17:28, 7. Dez. 2013 (CET)

You can add the line var autoFormatMaskedLinks = false; to your local common.js to disable this feature. --TMg 14:31, 7. Jan. 2014 (CET)

IMDb Title

Do not change {{IMDb title}} to {{IMDb Title}}, since it is a redirect to {{IMDb title}}. -Josve05a (Diskussion) 21:28, 7. Dez. 2013 (CET)

On enwp. -Josve05a (Diskussion) 21:32, 7. Dez. 2013 (CET)

Thats a mistake. Thanks. It's fixed now. --TMg 01:47, 9. Dez. 2013 (CET)

br-tag

Please do not change <br> to <br /> since <br> is the standard in the new release of XHTML-coding. Please read en:Wikipedia talk:WPCleaner/Archive 2013#<br> tag. -Josve05a (Diskussion) 21:31, 7. Dez. 2013 (CET)

I'm not sure what you mean with "the new release of XHTML-coding". I know the talk page. I wrote some of the longer comments there. ;-) They still apply. I'm aware there are one or two reasons to leave <br> untouched. But I consider all other reasons more important. I may change my mind but currently I don't want to add an exception for this. --TMg 14:29, 9. Dez. 2013 (CET)

ref name on enwp

Please do not change <ref name="isbn0-19-517234-5"> to <ref name="ISBN 0-19-517234-5">. This is a chosen ref name. Even if the isbn is "wrong, but the program should not change the name of a ref name. -Josve05a (Diskussion) 22:13, 7. Dez. 2013 (CET)

Good catch, thanks. This shouldn't happen, no matter in which language the script is used. I will fix it. --TMg 14:08, 9. Dez. 2013 (CET)

DEFAULTSORT on enwp

Please don't remove - from any DEFAULTSORT. This character is allowed on enwp. -Josve05a (Diskussion) 10:40, 9. Dez. 2013 (CET)

All my rules to create clean sort keys are still work in progress. Luckily the English rules are much better than the German. I will fix it. --TMg 13:59, 9. Dez. 2013 (CET)

The same goes with . -Josve05a (Diskussion) 15:28, 9. Dez. 2013 (CET)

Im deutschen darf das - aber gern entfernt werden. War mal so, ist jetzt aber nicht mehr der Fall. (Nutze die Beta-Version.) --BlueCücü (Diskussion) 19:57, 10. Dez. 2013 (CET)

English: The three characters '-. aren't touched any more. Deutsch: Den Bindestrich entferne ich wieder. Beim Hochkomma überlege ich noch, es wie den typografisch korrekten Apostroph (’) zu behandeln und ebenfalls wieder zu entfernen. Den Punkt werde ich außen vor lassen. Da er meist kein verbindendes sondern ein trennendes Zeichen ist, müsste ich ihn durch ein Leerzeichen ersetzen, und das würde meist sowieso nichts an der Sortierung ändern. --TMg 23:21, 11. Dez. 2013 (CET)

Entlinkungen von Jahreszahlen

Kann die Entlinkung doppelter/mehrfacher Jahreszahlen für Artikel der „Kategorie:Tag“ ausgenommen werden? Denn dort ist es wohl so gewollt, dass mehrfach die Jahres-Artikel verlinkt werden. --BlueCücü (Diskussion) 14:36, 9. Dez. 2013 (CET)

Klingt logisch, mach ich. --TMg 15:10, 9. Dez. 2013 (CET)

http to File

It tried to change

<!-- FAIR USE of http://en.wikipedia.org/wiki/Image:Image-NorwichSchool_Crest.gif: see image description page at http://en.wikipedia.org/wiki/Image:Image-Norwich school crest.jpg for rationale -->

to

<!-- FAIR USE of [[:Image:Image-NorwichSchool Crest.gif]]: see image description page at [[:Image:Image-Norwich]] school crest.jpg for rationale -->.

Notice the last file. From:

http://en.wikipedia.org/wiki/Image:Image-Norwich school crest.jpg

to

[[:Image:Image-Norwich]] school crest.jpg.

-Josve05a (Diskussion) 16:50, 10. Dez. 2013 (CET)

That's exactly what the script is supposed to do. :-) External links to the English Wikipedia don't make much sense in the English Wikipedia. The internal link syntax does exactly the same and provides many additional benefits like being protocol relative and been shown in "what links here". Sure, this is in a comment, but the reasoning is the same. The problem with the second link is that it uses spaces where it should use underscores. That's a mistake by the user or bot that put the link there. --TMg 18:21, 10. Dez. 2013 (CET)

Doppelte Jahreszahlen entlinken / erste Infobox bzw. Vorlage ignorieren

Ich weiß, ist ein alter Hut. Aber aus gegebenen Anlass wollt ich nochmal nachfragen, ob Infoboxen vor der eigentlichen „Prosa“-Einleitung eines Artikels ignoriert werden (können). Dachte das wäre umgesetzt, aber scheint beim o.g. Beispiel nicht zu funktionieren. Liegts daran dass der Infobox noch ein Bild vorausgeht? Oder war das noch ne offene Baustelle bzw. leider nicht umsetzbar? --BlueCücü (Diskussion) 10:43, 13. Dez. 2013 (CET)

Nachtrag: Hätte mal erst im Archiv schauen sollen, sorry. Hat demzufolge derzeit den Status „schöne Herausforderung“ ;-) --BlueCücü (Diskussion) 10:46, 13. Dez. 2013 (CET)

Nachnachtrag: Und hier die Folgediskussion. Ich werd entweder alt oder hab zu lange pausiert. Liegt also an verschachtelten Vorlagen. Diese kann ich aber im aktuellen Beispiel nicht erkennen. --BlueCücü (Diskussion) 10:55, 13. Dez. 2013 (CET)

Dein erster Gedanke war doch schon der richtige. ;-) Es lag am Bild. Verschachtelte Vorlagen wurden schon beachtet (sonst hätte ich das nicht archiviert) und jetzt auch Bilder. --TMg 11:48, 15. Dez. 2013 (CET)

ISBN in URL

It tried to change: [http://www.hup.harvard.edu/catalog.php?isbn=9780674372993 ISBN 0-674-37299-9] to [http://www.hup.harvard.edu/catalog.php?isbn=978-0-674-37299-3 ISBN 0-674-37299-9] and it also tried to change: [http://www.hup.harvard.edu/catalog.php?isbn=9780674011632 ISBN 0-674-01163-5] to [http://www.hup.harvard.edu/catalog.php?isbn=978-0-674-01163-2 ISBN 0-674-01163-5] on this page on enwp. -Josve05a (Diskussion) 20:36, 14. Dez. 2013 (CET)

Cool, this got "magically" fixed along with this change. I moved the fix to the stable branch now. Please reload. Thanks for the additional examples. It's good to have them in my tests suite. --TMg 11:32, 15. Dez. 2013 (CET)

ref wird komplett gelöscht

Hier möchte das Script die Zeichenfolge <ref name="w/d"></ref> komplett rauslöschen. Dass das schließende </ref> nicht Not tut ist mir klar. Aber hier wird ganz rasiert. Liegts an dem /-Zeichen im ref-Namen? --BlueCücü (Diskussion) 08:23, 16. Dez. 2013 (CET)

Und ich dachte beim Programmieren noch, „hoffentlich kommt niemand auf die verrückte Idee, Schrägstriche in Identifikatoren zu verwenden“. ;-) Test Nummer 600 deckt jetzt auch das ab. Live ist die Korrektur auch schon. Danke dir. --TMg 18:08, 16. Dez. 2013 (CET)

Keine Ahnung wer auf solch merkwürdige Ideen mit „Schrägstrichen in Identifikatoren“ kommt. Da steckt man nicht drin. --BlueCücü (Diskussion) 23:49, 17. Dez. 2013 (CET)

Das war wirklich nur ein Spaß. ;-) Ich hab nicht in die Versionsgeschichte geguckt. Die unglückliche Kombination der zwei daran beteiligten Regeln zu verfeinern hat Spaß gemacht. Ein Hoch auf test first. --TMg 11:13, 18. Dez. 2013 (CET)

Die Empörung war ja nur gespielt ;) Gelobe im Sinne von Punkt 6 und 8 immer wachsam zu bleiben und nie eingeschnappt/empört zu sein, wenn mal ne Anregung nicht aufgenommen oder umgesetzt wird. Vorweihnachtliche Grüße, --BlueCücü (Diskussion) 13:00, 18. Dez. 2013 (CET)

Projektorganisation

Offen ist ja noch genug. Sag mal ehrlich, was aus deiner Sicht am wichtigsten wäre? --TMg 16:45, 18. Dez. 2013 (CET)

Gute Frage: Bin ja so vergesslich. Führst du eigentlich eine Liste der offenen Punkte – eine Art To-do-Liste. Oder sind das quasi die nicht archivierten Diskussionsbeiträge? Vielleicht ist ja eine Extraunterseite übersichtlicher. Dort könntest du ja alles kurz und knackig formulieren und nach derzeitiger Priorität ordnen und jederzeit umordnen. Was ich gefühlt am häufigsten wieder „zurücksetze“ sind glaube ich Änderungen in externen Links (Beispiel). Vielleicht wäre ne Regel möglich dass innerhalb der Zeichenketten ab „http“ bis zum nächsten Leerzeichen nichts geändert werden darf? --BlueCücü (Diskussion) 23:05, 19. Dez. 2013 (CET)

Ich bin mit meinem manuellen Archivierungssystem hier momentan ganz zufrieden. Archiviert wird nur, was aus meiner Sicht erledigt ist. Beim Rest ist zumindest teilweise noch etwas offen, aber meist nichts dramatisch Dringendes mehr. Weit vorausplanen möchte ich nicht. Das halte ich sowieso nicht ein. Ich richte mich nach meinen grundsätzlichen Prioritäten und natürlich danach, wie dringlich eine Sorge vorgetragen wird. ;-) Das Problem in deinem Beispiel hab ich gleich behoben. So was solltest du wirklich immer melden, egal wie unwichtig es dir erscheint. --TMg 01:52, 20. Dez. 2013 (CET)

LRM

Gibt es Fälle wo das Leerzeichen (‎), welches das Script in &lrm; wandelt, bewusst gesetzt wird oder handelt es sich stets um unbewusste copy-paste-Mitnahmen? Bisher habe ich im nachhinein immer alle LRMs gelöscht, sobald sie auftauchten. Hatte keinen Fall wo dort ein Leerzeichen stehenbleiben musste (a), sondern ausschließlich Fälle in denen das Zeichen komplett gelöscht werden konnte (b). Wenn Fall (a) also niemals vorkommt (?), dann könnte das Script dieses Leerzeichen doch gleich löschen, oder? --BlueCücü (Diskussion) 09:50, 20. Dez. 2013 (CET)

Seit wir dank Wikidata keine Interlanguage-Links mehr pflegen, sind bidirektionale Steuerzeichen zumindest hier bei uns zu 99 % unnötig und können entfernt werden. Das Problem ist, das eine Prozent zu erkennen, wo es wichtig ist. Wer sich unsicher ist, sollte die Zeichen immer stehen lassen. Sie richten keinen Schaden an. Automatisch entferne ich sie nur, wo ihre Wirkungslosigkeit algorithmisch feststeht. Meine Faustregel für den verbleibenden Rest: Wenn in der Umgebung des &lrm; nur „normale“ lateinische Buchstaben zu sehen sind, und weit und breit kein arabisches oder anderes Zeichen eines von rechts nach links zu lesenden Schriftsystems auftaucht, kann es ziemlich sicher entfernt werden. --TMg 15:39, 20. Dez. 2013 (CET)

Versuch ich mir zu merken. --BlueCücü (Diskussion) 11:00, 21. Dez. 2013 (CET)

Externe Wikilinks in Vorlage:Internetquelle nicht ändern

Externe Wiki-Links werden in der Vorlage:Internetquelle so geändert, dass sie im Anschluss nicht mehr funktionieren (Beispiel). Es grüßt, --BlueCücü (Diskussion) 11:00, 21. Dez. 2013 (CET)

Ich habe die Regel für diesen Fall entschärft. Streng genommen ist es aber verboten, Wikipedia als Quelle anzugeben. --TMg 00:18, 29. Dez. 2013 (CET)

Suggestion for enwp

Just a suggestion, change the following: {{Main|*****}} {{Main|#####}} to {{Main|*****|#####}} --Josve05a (Diskussion) 16:16, 21. Dez. 2013 (CET)

You can add this as a custom rule, if you want, but I do not want to enforce such replacements on all users. --TMg 00:07, 16. Mai 2017 (CEST)

Apostrophe

Gibt es eine Möglichkeit sowas aufzunehmen. Ist sicherlich verzwickt, da man nicht einfach jedes ' in ’ umwandeln kann. Oder kann man da irgendwie zwischen ' als Wikicode-Zeichen und ' als Apostroph in Fließtext und Links unterscheiden. In externen Links und Vorlagen, die zu Links werden, sollten die Zeichen natürlich nie geändert werden. Für häufig vorkommende Namen im Billardbereich, wo ich hin und wieder aktiv bin, habe ich mir eine einfache Suchen-Ersetzen-Funktion schon in die common.js aufgenommen (z.B. O’Sullivan --> O’Sullivan), aber wenn das generell „autoformatierbar“ wäre, dann wärs z.B. im Filmbereich eine enorme Hilfe. Es werden zwar immer Weiterleitungen vom '-Lemma auf's ’-Lemma angelegt, aber generell sind ja Direktverlinkungen lieber gesehen. Nebeneffekt wäre, dass das MissingTopicsTool nicht andauernd die '-Lemmata „findet“, obwohl sie ja eigentlich vorhanden sind. Obwohl das wohl eher eine MTT-Bug-Geschichte ist. Guten Rutsch wünscht, --BlueCücü (Diskussion) 16:33, 27. Dez. 2013 (CET)

Schwierig. Wir hatten das ja schon diskutiert (1, 2). Ich möchte das nicht als pauschale Ersetzung für alle Benutzer anbieten, weil die wenigsten den Unterschied zwischen den Zeichen verstehen. Auch wenn die Änderung in den meisten Fällen korrekt wäre, würde sie Verwirrung stiften. Ich möchte deshalb gern dabei bleiben, das nur als benutzerdefinierte Regel anzubieten. Die habe ich jetzt noch etwas weiter gefasst, siehe Vorderseite. --TMg 00:16, 29. Dez. 2013 (CET)

Habe es mal testweise übernommen. Funktioniert fein. Nur meine anderen Auto-Ersetzungen wollen nicht mehr so recht. Kannst du vielleicht mal einen Blick auf meine common werfen, ob da irgend wo das berühmte Komma oder Semikolon fehlt. Oder kann man nicht gleichzeitig Varautoreplacements mit geschweiften und eckigen Klammern haben? --BlueCücü (Diskussion) 14:55, 30. Dez. 2013 (CET)

Der zweite Regelsatz hebelt den ersten komplett aus. Du musst es in der Schreibweise ['\\w\'\\w', '\\w’\\w'], einbauen. --TMg 16:11, 1. Jan. 2014 (CET)

Vielen Dank. Habs geändert. --BlueCücü (Diskussion) 06:30, 2. Jan. 2014 (CET)

It is me and my years again

Hello. if you can remember, we had a little discussion about if years should be writter 1958-59 or 1958-1959. I have had a discussion with Howicus on the Teahoes IRC chat (#wikipedia-en-help) and according to en:Wikipedia:YR#years it says that both cases can be used for diffrent articles. Therefore I'm once again reqesting that this can be removed from enwp. -Josve05a (Diskussion) 22:06, 29. Dez. 2013 (CET)

Yes, both can be used and as I said it's not forbidden to change it. Same here in the German Wikipedia. It's not forbidden to write "1958–59". We (the users of my script) are changing it anyway. What the script does is a suggestion. If it's good we keep it. If it's questionable we revert it. Don't get me wrong. I'm really thinking about this. If you are constantly reverting some of the scripts suggestions it's a bad suggestion and I should do something about it. I think I will add an per-user switch to turn some features off including this one. See #Merkliste 2014. --TMg 00:10, 30. Dez. 2013 (CET)

That makes sense! (I just want to point out the second point on that page: "[…] sports seasons spanning two calendar years should be uniformly written as 2005–06 season.") Josve05a (Diskussion) 01:37, 30. Dez. 2013 (CET)

Oh, that's important. I didn't saw that before. Thanks. I disabled the rule by default in the English Wikipedia. It can be re-enabled with an additional line of code. --TMg 00:00, 2. Jan. 2014 (CET)

Tabellen

Idee von mir: Tabellen bereinigen (für die bessere Lesbarkeit), also nach einem Trennstrich ("|") kommt ein Leerzeichen. --Atamari (Diskussion) 00:06, 30. Dez. 2013 (CET)

Danke, ich verstehe die Idee, muss sie u. a. mit Blick auf meine Prinzipien aber leider ablehnen. Auf die Artikel hätte eine solche Änderung keine Auswirkung. Die Diff-Ansicht würde extrem unübersichtlich werden. Manchmal wäre es ungewünscht, wenn ein Autor absichtlich eine sehr kompakte Schreibweise gewählt hat. Vor allem aber ist die Tabellensyntax so schwammig, dass ich sie technisch nicht sicher genug erkennen kann. Die entstehenden Fehler und die Zeit, die ich und die Benutzer des Skripts dafür investieren müssten, würde durch den Vorteil der etwas leichter lesbaren Tabellensyntax nicht aufgewogen. --TMg 00:24, 30. Dez. 2013 (CET)

DEFAULTSORT

The program is still changing - to a space. To duplicate run the script on en:Maria Theresa of Austria (1801–1855). -Josve05a (Diskussion) 12:19, 31. Dez. 2013 (CET)

Isn't that an en-dash (U+2013)? I'm not aware of an exception for that character in sort keys. It doesn't matter anyway. The sorting order does not change at all no matter if this is space, a hyphen-minus (U+002D) or an en-dash. --TMg 15:56, 1. Jan. 2014 (CET)

It should still be sorted under, even if there is no change in category-sorting.. Josve05a (Diskussion) 19:00, 11. Feb. 2014 (CET)

It took me a while but I finally had a surprisingly simple idea how to fix this. --TMg 23:03, 27. Feb. 2014 (CET)

Other places than mainspace

On Wikipedia:WikiGnome on enwp, the script removes |WikiGnome from [[Category:Wikipedia fauna|WikiGnome]]. Making the page getting sorted under Wikipedia:WikiGnome. Wich is not intended. -Josve05a (Diskussion) 16:32, 31. Dez. 2013 (CET)

The namespace is ignored. This sort key does not do anything and can be safely removed. Example: See en:Category:Wikipedia fauna. The page "User:Aditya Kabir/Wikifauna" isn't sorted under "U" but "A" without having a sort key. --TMg 16:05, 1. Jan. 2014 (CET)

Odd suggestion

It tried to change the following to en:Jonny Polonsky within {{Infobox musical artist}}:
| instrument = [[vocal]]s, [[guitar]], [[bass]], [[drum]]s, [[piano]], [[organ]], [[synthesizer]], [[pump organ]], [[clavinet]], [[mellotron]], [[harmonium]], [[melodica]], [[ukelele]], [[lap steel]], [[dobro]], [[mandolin]], [[mandocello]], [[banjo]], [[harmonica]], [[marimba]], [[vibraphone]], [[xylophone]], [[flute]], [[bajo sexto]], toy [[piano]]
to
| instrument = [[vocals, guitar, bass, drums, piano, organ, synthesizer, pump organ, clavinet, mellotron, harmonium, melodica, ukelele, lap steel, dobro, mandolin, mandocello, banjo, harmonica, marimba, vibraphone, xylophone, flute, bajo sexto, toy piano]]
Josve05a (Diskussion) 04:10, 7. Jan. 2014 (CET)

That would be extremely odd. Unfortunately I don't know what causes this issue. I don't think it's my script. I can't reproduce it no matter what I try. I also tried your vector.js and common.js. Seems to be fine. Could this be a browser issue? Which one are you using? And browser plug-ins? --TMg 09:28, 7. Jan. 2014 (CET)

I'm using Google Chrome. I can't reprduce it either. I'm also using the plug-ins AdBlock 2.6.16, Does Amazon Ship to ...? 3.0.6, Google Dokument 0.5, Panic Button Plus 1.1.5, Panic Button Plus 1.0.0, Wolfram|Alpha (Official) 1.2.2. -Josve05a (Diskussion) 13:37, 7. Jan. 2014 (CET)

Odd. You did not used the Visual Editor? I will close this report for now. Please reopen if it happens again. --TMg 14:22, 7. Jan. 2014 (CET)

Checkwiki Fehler 16

Moin TMg! Lang nicht gesprochen. Vielleicht wir sehen uns in Hackathon dieses Jahr? Waere es moeglich dass du in deine Auto-Formatter Liste von Unicode charactern (CHECKWIKI Fehler) #16 \u202A|\u202C addierst bitte? D.h. AutoFormatter zu korrigieren alle 6 invisible Unicode character. (Du kannst mein Deutsch korrigieren!) -- Magioladitis (Diskussion) 13:46, 17. Jan. 2014 (CET)

Magioladitis, thank you very much for the hint. Currently these two characters aren't in the code on GitHub. Is this still to come? Here is an overview according to my script and my opinion:

• U+200B (ZERO WIDTH SPACE): It's a valid character in some languages to mark a possible break in article titles that are composites of connected words. Similar to ­ but without becoming a dash. I do remove it when I'm sure it's misplaced: from line endings and if it's between two Latin characters (range U+0000–U+024F). This is my own conclusion. I can't prove this is fail-proof.
• U+200E (LRM): I remove it if I'm sure it's misplaced: if it's in front of a closing ] or next to a left-to-right character (see my code for the range). All remaining are made visible as ‎.
• U+2028 (LINE SEPARATOR): I have the feeling it can be removed. It's most probably a mistake and completely useless in wikitext. It doesn't do anything in Firefox and IE. Opera turns it into a space.
• U+202A (LRE) and U+202C (PDF): Not sure. Replace it as recommended?
• U+FEFF (BOM): I remove it with no exceptions.

--TMg 19:59, 17. Jan. 2014 (CET)

Satzbau war richtig :) -- Magioladitis (Diskussion) 14:50, 18. Jan. 2014 (CET)

Nicht ganz. ;-) Aber problemlos zu verstehen. Ich freue mich auf ein Wiedersehen beim Hackathon. --TMg 15:12, 18. Jan. 2014 (CET)

Ich hoffe wir treffen uns beim Hachathon dieses Jahr auch! -- Magioladitis (Diskussion) 00:32, 3. Jan. 2015 (CET)

Fehlermeldung (Maya Jobarteh)

Bei dem Artikel Maya Jobarteh wird bei der Vorlage IMDb Name wird eine Klammer („}“) zu viel entfernt. --Atamari (Diskussion) 02:04, 4. Feb. 2014 (CET)

Ein schönes Fundstück, danke. Schon behoben. --TMg 22:48, 4. Feb. 2014 (CET)

URL mit &20052

Hier ersetzt die Beta-Version "&20052" innerhalb URL durch vermutlich chinesisches Schriftzeichen. --Thoken (Diskussion) 20:57, 1. Mär. 2014 (CET)

Ein sehr schönes Fundstück, vielen lieben Dank. Sogleich behoben. --TMg 14:07, 2. Mär. 2014 (CET)

Bindestrich in Linktext

Ist das so (aus [[Assistenzstelle|Assistenz-]] wird [[Assistenzstelle|Assistenz]]-) gewollt? --Seth Cohen 22:47, 18. Mär. 2014 (CET)

Genau das wollte ich gerade auch anmerken. Da der ganze Begriff inklusive dem ausgelassenen Teilwort verlinkt gehört, muss der Auslassungsstrich klar in der Klammer bleiben. --androl ☖☗ 17:40, 24. Mär. 2014 (CET)

Tut mir leid, aber den Strich in den Link hinein zu ziehen, ist typografisch nicht korrekt. Der Grund wird am ehesten klar, wenn man die Link-Unterstreichungen aktiviert hat. Beispiel: Assistenz-Stelle. --TMg 22:32, 27. Mär. 2014 (CET)

Ah, ich verstehe, wir reden über verschiedene Dinge. In Assistenz-Stelle muss der Bindestrich natürlich draußen bleiben, in Assistenz- und Oberärzte muss er dagegen in die Verlinkung. --androl ☖☗ 16:14, 28. Mär. 2014 (CET)

Es gibt eigentlich keinen Grund, die beiden Fällen unterschiedlich zu handhaben. Assistenz- und Oberärzte ist typografisch ebenso inkorrekt. Satzzeichen unterstreicht man nicht mit. --TMg 00:01, 29. Mär. 2014 (CET)

Den typografischen Aspekt hatte ich außer Acht gelassen. --Seth Cohen 15:58, 3. Apr. 2014 (CEST)

Gibt es denn die Möglichkeit die korrekte Verlinkung dem typografischen Aspekt vorzuziehen, also diese Funktion zu deaktivieren? --Hadibe (Diskussion) 18:03, 22. Aug. 2015 (CEST)

Was meinst du denn mit „korrekt“? Wie schon gesagt, Satzzeichen in Formatierungen hinein zu ziehen ist in den seltensten Fällen korrekt; bei Unterstreichungen in jedem Fall falsch. Ich biete gern Optionen an, wenn das dabei hilft, die Akzeptanz dieses Skripts und seiner Ersetzungsregeln zu erhöhen. Das scheint mir in diesem Fall jedoch nicht gerechtfertigt. Warum eine Regel abschaltbar machen, wenn es vom nächsten Benutzer dann doch korrigiert wird? --TMg 12:16, 22. Sep. 2015 (CEST)

Ok, ich habe die Regel ein wenig entschärft. Bindestriche am Ende von Links bleiben jetzt unangetastet, wenn dahinter eine Leerstelle folgt. Links wie [[Berlin|Berlin-]] werden trotzdem noch korrigiert, weil das tatsächliche Linkziel ja nicht „Berlin-Irgendwas“ lautet sondern nur „Berlin“ und das auch so erkennbar sein sollte. --TMg 10:25, 24. Sep. 2015 (CEST)

Vielen Dank! @Seth Cohen, Androl, Hadibe: Die beiden Suchen nach insource:/\|[a-z\- ]+\]\]\-\, /i bzw. insource:/\|[a-z\- ]+\]\]\- und /i liefern leider zu viele Treffer, als dass man diese händisch nach Fällen wie im Beispiel ganz oben durchgehen könnte. Vielleicht könnte man die Treffer noch etwas weiter eingrenzen. Nur weiss ich gerade nicht wie. --Leyo 17:30, 29. Nov. 2015 (CET)

Geschützte Leerzeichen

Ist eine Veränderung von "5000 Euro" zu "5000&nbsp;Euro" (Beispielartikel) im Konsens der Gemeinschaft? Falls gewünscht, müsste man dann nicht auch "25.000 Schweizer Franken" zusammenkleben? Was ist mit Jahrestagen, da wird "24.&nbsp;März&nbsp;2014" zu "24.&nbsp;März 2014", wäre es da auch okay, auch das zweite &nbsp; zu entfernen? --androl ☖☗ 17:40, 24. Mär. 2014 (CET)

Beim verbliebenen geschützte Leerzeichen in „24.&nbsp;März 2014“ bin ich unsicher. Wir sprechen seit einer Weile darüber, das zu automatisieren. Solange das noch nicht Realität ist, können die Leerzeichen sinnvoll sein – sofern man es nicht übertreibt. Du kannst sie entfernen, solltest aber Rücksicht auf eventuelle Hauptautoren und Konsistenz innerhalb des Artikels nehmen. Beim „Euro“ als ausgeschriebenes Wort wundere ich mich gerade selbst, warum ich das aufgenommen habe. Die Regel sollte eigentlich nur (kurze) Maßeinheiten umfassen, die abgerissen auf der nächsten Zeile sinnentstellend wirken. Das trifft auf „EUR“ zu, auf „Euro“ aber wohl eher nicht. Ich werde es raus nehmen. --TMg 22:44, 27. Mär. 2014 (CET)

SORTIERUNG

Bei İzmit wird der Sortierschlüssel entfernt, wahrscheinlich weil lowercase("İzmit") = lowercase("Izmit") = "izmit". Bei Yılankale kein Problem. Vielleicht hilft es, sowohl lowercase als auch uppercase zu überprüfen. --androl ☖☗ 16:32, 28. Mär. 2014 (CET)

Bei mir wird in keinem Fall etwas entfernt. Vielleicht ein Problem mit einer ganz bestimmten Browserversion? Oder ist dir in deiner Beschreibung etwas durcheinander geraten? --TMg 00:10, 29. Mär. 2014 (CET)

tatsächlich, je nach Browser verhält es sich unterschiedlich. Der, den ich hier gerade habe, ist ziemlich alt (IE8), und da wird der Sortierschlüssel bei İzmit entfernt. --androl ☖☗ 16:01, 8. Apr. 2014 (CEST)

Ich habe mir das jetzt mehrmals genau angesehen und muss den Versuch, das zu beheben, vernünftigerweise aufgeben. IE8 verhält sich einfach falsch, wenn man ihn darum bittet, Groß/Kleinschreibung zu ignorieren. Ich habe den interessanten Fall aber in meine Testliste aufgenommen, um sicherzustellen, dass das die einzige betroffene Browserversion ist. --TMg 02:46, 12. Apr. 2014 (CEST)

Leerzeichen zu Beginn des Alternativtextes von Wikilinks

Klick. [[Thomas_Hillenkamp| Thomas Hillenkamp]] wird nicht zu [[Thomas Hillenkamp]]. --Seth Cohen 16:03, 3. Apr. 2014 (CEST)

Als Wunsch verstehe ich das und werde versuchen, das aufzunehmen. Im Moment ist das Absicht, weil sonst Konstellationen in diesem Beispiel zuBeispiel werden würden. --TMg 02:50, 12. Apr. 2014 (CEST)

Doppelte Verlinkungen in Jahresartikeln

Hallo TMg,
zunächst herzlichen Dank für dieses schöne Tool. Es ermöglicht mir, viele mir wichtige Kleinigkeiten en passant zu erledigen.
Ich habe sehr viele Jahre (z. B. 1996 1997 ...) auf meiner Beobachtungsliste. Auf vielen dieser Seiten hätte der autoFormatter einiges zu tun. Allerdings ist es dort üblich zu jeder Person jeweils das Geburts- bzw. Sterbejahr zu verlinkten – auch andere Doppelverlinkungen sind üblich. Damit kann ich das Tool dort nicht einsetzen. Gerade auf älteren Jahresseiten stehen jedoch häufig (ich habe gerade kein krasses Beispiel zur Hand) veraltete Formatierungen – bzw. werden immer wieder aus anderen WPs so übersetzt übertragen.
Wäre es möglich, entweder eine Sonderbehandlung der Jahre, oder eine Konfigurierbarkeit der Doppelverlinkungsbehandlung zu bekommen?
Gruß --Baumfreund-FFM (Diskussion) 06:25, 14. Apr. 2014 (CEST)

Das kommt mir so bekannt vor. Also zusätzlich zur Tages- auch die Jahreslategorien ausklammern? Sollte kein Problem sein. --TMg 21:38, 20. Apr. 2014 (CEST)

So gleichen sich die Wünsche :-) – danke. --Baumfreund-FFM (Diskussion) 21:42, 20. Apr. 2014 (CEST)

Kodiertes %20 wird als Datum erkannt

Siehe hier: [3] --Atamari (Diskussion) 21:06, 1. Mai 2014 (CEST)

Die Veränderung innerhalb der URL wir immer noch vorgenommen? --Atamari (Diskussion) 14:05, 9. Mai 2014 (CEST)

Danke fürs Nachhaken. Die Lösung war so einfach, dass es mich fast ärgert, mich nicht sofort darum gekümmert zu haben. Tut mir Leid. --TMg 17:14, 9. Mai 2014 (CEST)

Schönheitsfehler?

Hallo TMg!
Der autoFormatter ist ein schönes Skript mit vielen nützlichen Funktionen. Ich möchte es für eigene Zwecke kopieren und anpassen (→ Testwiki). In JavaScript bin ich Anfänger, aber zuversichtlich.
Es gibt anscheinend einen kleinen Schönheitsfehler: Wenn ich den "Besen" anklicke, läuft das Skript, anschließend ist das Icon hellgrün hinterlegt. Wenn ich nochmal klicke, grau. Das Skript läuft jedesmal korrekt ab, obwohl das graue Icon den Eindruck erweckt, als wäre die Funktion nicht aktiv. Könnte das ein MediaWiki-Fehler sein? Wir haben in unserem Wiki 1.19, die Wikipedia hat bereits 1.24, daher habe ich hier kurzerhand ein eigenes Benutzerkonto angelegt - und siehe da: Derselbe Fehler, selbst wenn ich das Skript direkt importiere!
Am Browser scheint es nicht zu liegen. Firefox 30.0 und IE 11 reagieren identisch.
Was meinst Du könnte die Ursache sein? --Klenzy (Diskussion) 12:09, 4. Jul. 2014 (CEST)

Beim zweiten Aufruf war ja schon alles erledigt, also nichts mehr zu tun.

Gruß --Baumfreund-FFM (Diskussion) 07:21, 5. Jul. 2014 (CEST)

@Baumfreund-FFM. Danke, aber ich habe nicht dich gefragt, sondern TMg.

@TMg, das geschilderte Problem tritt selbstverständlich unabhängig davon auf, ob ich zwischen den mehrmaligen Aufrufen des Skripts den Artikel nochmals geändert habe oder nicht. Die Toolbar bzw. der Button können ja schlechterdings vorher wissen, ob es etwas zu tun gibt oder nicht. Grüße --Klenzy (Diskussion) 11:53, 5. Jul. 2014 (CEST)

@TMg, bin mutiger geworen und habe es gefunden. Das Skript macht das selbst. Der Grund dafür erschließt sich mir nicht, denn wie erwähnt kann der Benutzer weitere Änderungen machen und dann nochmal ein AutoFormat wollen; das geänderte Icon irritiert da nur. Jedenfalls kann ich den Schönheitsfehler nun nach meinen eigenen Vorstellungen beheben: Insofern danke! Grüße --Klenzy (Diskussion) 16:32, 5. Jul. 2014 (CEST)

Wenn eins meiner Skripte Anlass und Motivation bietet, in die Programmierung einzusteigen, freut mich das immer sehr. Das Skript steht wie alles hier unter CC-BY-SA – wenn du den Link zum Original beibehältst, kannst du es gern an deine Bedürfnisse anpassen. Die Frage hat Baumfreund beantwortet (Danke fürs Aushelfen). Das Icon wird grün, wenn es Änderungen vorgenommen hat, und grau, wenn es nichts zu tun gab. Falls du da eine bessere Idee hast, nur zu. --TMg 09:30, 11. Jul. 2014 (CEST)

Ah, danke! Deine Erklärung für das Verhalten des Icons war jetzt leichter verständlich als die Antwort von Baumfreund (die vielleicht nur zu knapp formuliert, daher missverständlich war). Ich werde das wahrscheinlich mit einer Statusmeldung per alert lösen, wo ich dann auch noch den wichtigen Hinweis "Kontrolle per Vorschau/Änderungsvergleich wird dringend angeraten" unterbringen möchte. Aber ich bin mir bewusst, dass es sich dabei nicht um eine allgemeintaugliche Lösung handelt.

Der Link auf das Original ist selbstverständlich drin und bleibt drin.

Nochmals vielen Dank! --37.4.50.84 13:47, 11. Jul. 2014 (CEST) (--Klenzy on the road ohne Kennwort)

Doubt about space in sub section

Hello TMg, I've one doubt about your tool. This tool changes ==sub section== into == sub section ==. Is this change is necessary? Please can you explain me.--Shrikarsan (Diskussion) 09:44, 18. Jul. 2014 (CEST)

Straightforward answer is no, this change is not necessary. It doesn't change anything in the resulting article. But it makes the wiki source much more readable and easier to maintain for following editors. It's just good practice to add these spaces. You are free to revert parts of the scripts suggestions if you don't like one of them. Another way to avoid doing to many unwanted changes is to select the text you want to clean before clicking the Auto-Format button. --TMg 11:22, 22. Jul. 2014 (CEST)

Thanks --Shrikarsan (Diskussion) 14:25, 24. Jul. 2014 (CEST)

Verlinkungen

Der autoFormatter korrigiert Verlinkungen u.a. Minus-strich auf den Bis-strich. So entstehen hinterher rote Links. Also innerhalt von den eckigen kammern sollte der autoFormatter eigentlich nichts korrigieren, oder? Beispiel: duch ein Script wurde eine Liste generiert, mit dem autoFormatter formartiert und gespeichert. Dadurch gab es den Paul Franken (Politiker, 1894–1944) als Rotlink, weil die Person nur mit Minus-Strich gab. Mittlerweile wurde die Person verschoben aber es ist möglich, das es Lemmata gibt, die ein Minus-Strich o.ä. verwenden. Also innerhalb der eckigen Klammern ist alles tabu. --Atamari (Diskussion) 21:04, 20. Jul. 2014 (CEST)

Ich muss ganz grundsätzlich davon abraten, das Skript pauschal auf so riesige Artikel anzuwenden. Bearbeite lieber nur einen Abschnitt oder markiere vor dem Drücken des Auto-Format-Knopfes so viel Text, wie du gerade noch überblicken kannst. Wenn Fehlersetzungen passieren, dann bin ich zwar immer sehr dankbar dafür, hier darauf hingewiesen zu werden, denn nur so kann ich das Skript kontinuierlich verbessern und an geänderte Gegebenheiten anpassen. Aber letztendlich bist du für deine Bearbeitungen verantwortlich. Und dazu gehört auch, noch einmal kurz über die Vorschau zu fliegen und nach roten Links Ausschau zu halten. Was den konkreten Fall betrifft: Das Lemma war eindeutig falsch, oder nicht? Die Skriptänderung hat darauf aufmerksam gemacht. Mit Erfolg, wie man sieht. Da ich Links unter anderem deshalb nicht pauschal ausschließe, können Fehlersetzungen natürlich passieren. Ich bemühe mich immer, die zu reduzieren, wenn ich darauf hingewiesen werde. Wenn dir da noch mehr auffallen sollte, zögere bitte nicht und wirf mir einfach einen Link hier hin. --TMg 11:45, 22. Jul. 2014 (CEST)

How to not fix URLs into interwiki links?

For links to Wikipedia articles on a non-Wikimedia wiki. It is nice to use the full URL to Wikipedia. This shows that it's off-site. I've tried "var interWikiReplace = false;" but this doesn't work. How to turn off fixing links into interwiki links please? --Rob Kam (Diskussion) 16:57, 1. Nov. 2014 (CET)

@Rob Kam: I'm not sure what the problem is. What wiki are you talking about? Does the script destroy links? Do they turn red or don't link to the correct page any more? --TMg 19:00, 2. Nov. 2014 (CET)

The SDIY wiki. For example the page there Synthesizerstudio Bonn has the link [http://en.wikipedia.org/wiki/Kraftwerk Kraftwerk] which autoFormatter fixes to [[:en:Kraftwerk|Kraftwerk]]. Yes this destroys the link, it becomes a red link. I'd like the option to disable it from making external links into interwiki links. --Rob Kam (Diskussion) 19:20, 2. Nov. 2014 (CET)

Interwiki links mislead the user to think they're staying on the same site while they're being taken to a different one. Interwiki links like [[:en:Interwiki links|Interwiki links]] work fine on en.wikipedia, de.wikipedia, mediawiki.org, etc. but on the SDIY wiki they're red links. Rob Kam (Diskussion) 10:28, 7. Nov. 2014 (CET)

@Rob Kam: So you are really using it on a non-Wikimedia wiki. You are actually the first user that tells me that. Good to know. I added the setting var autoFormatWikimediaLinks = false;. Please note that it's absolutely possible to use the short syntax and still style such links as external (with the icon and color). All you need is a bit of CSS to do that. --TMg 16:55, 12. Nov. 2014 (CET)

@TMg Thank you that works just right, and thanks for the script - it's very helpful with keeping things tidy. Rob Kam (Diskussion) 17:29, 12. Nov. 2014 (CET)

Großschreibung von Vorlagen

Im Jahr 2012 wurde die Schreibweise von {{Dtsx}} mit in die Fehlerkorrektur aufgenommen. Wie kann es dann sein, dass die Vorlage von der richtigen Großschreibung ins Kleine geändert wird? --Hadibe (Diskussion) 05:41, 2. Dez. 2014 (CET)

Die Dokumentationsseite der Vorlage ist leider unpräzise und ich habe versäumt, mich darum zu kümmern. Für diese Vorlage ergibt nur Kleinschreibung Sinn, weil Vorlage:dts auch schon immer klein war und es sogar Vorlage:edts gibt, die mit großem D gar nicht funktioniert. Die Einheitlichkeit innerhalb dieser Vorlagenfamilie habe ich höher gewertet als die individuellen Dokuseiten. --TMg 14:52, 31. Dez. 2014 (CET)

Also? Kann die Kopiervorlage von Vorlage:Dtsx in dtsx geändert werden? An der Funktionalität sollte sich ja nichts ändern. --Hadibe (Diskussion) 18:08, 31. Dez. 2014 (CET)

Was ist der tiefere Sinn und Nutzen, funktionierende Großschreibungen in Kleinschreibungen zu ändern? Sogar Vorlage:dts heißt im Grunde Vorlage:Dts; dass oben auf der Dokuseite Vorlage:dts steht, ist im Grunde Trickserei. Imho nicht mehr als Geschmackssache. --AMGA (d) 08:45, 13. Jan. 2015 (CET)

Mein Skript erhöht die Einheitlichkeit und Lesbarkeit der Wiki-Quelltexte. Abgesehen davon ist die Schreibweise von Vorlagen komplett bedeutungslos. So sehr, dass man nicht einmal sagen kann, eine Schreibweise wäre „richtiger“ oder „wahrer“ als die andere. Sie sind gleich. Die Englische Wikipedia bspw. schreibt Vorlagen praktisch immer klein, bei uns ist es umgekehrt. Ich nehme nur eindeutige Fälle auf, die Sinn ergeben und bei denen sich die Communities seit langem einig sind. Außerdem lege ich Wert darauf, dass Bearbeitung niemals nur aus solchen wirkungslosen Syntaxkorrekturen bestehen. Wenn ein Benutzer meines Skripts sich nicht daran hält, bitte ich, ihn freundlich darauf hinzuweisen. --TMg 15:42, 14. Jan. 2015 (CET)

Kategoriebezeichnung – Fehler

Wie bei der Änderung der Liste der Kulturdenkmale in Berlin-Dahlem werden aus der Kategoriebezeichnung Umlaute und Bindestriche entfernt. Das führt aber dazu, dass die Wikipedia:Liste#K ebendiese Kategoriebezeichnungen nicht mehr alphabetisch aufführt, sondern am Ende der Auflistung. Momentan betrifft das die Berliner Ortsteile Charlottenburg, Dahlem, Friedrichshain, Grünau und Köpenick. --Hadibe (Diskussion) 00:57, 22. Dez. 2014 (CET)

Ich hab mich da in jeder Hinsicht an den unter WP:Kategorien dokumentierten Konsens gehalten. Soweit sich da nichts ändert, muss ich davon ausgehen, dass die Bindestriche der Fehler sind, und nicht meine Leerzeichen. --TMg 15:08, 31. Dez. 2014 (CET)

Alles klar, dann werde ich in Zukunft auch die anderen Kategoriebezeichnungen umarbeiten. --Hadibe (Diskussion) 18:13, 31. Dez. 2014 (CET)

File name protection

File names are not always properly protected from changes. It appears if the protection only works for files that start with '[[File:' or '[[Datei:'. However, in Afrikaans, for example, files starting with '[[Beeld:' and '[[Lêer:' are not protected. Can this somehow be accommodated? Best regards. Naudefj (Diskussion) 20:31, 2. Jan. 2015 (CET)

You are right, only English and German namespace names are recognized. I will expand this code as soon as I can. --TMg 15:27, 14. Jan. 2015 (CET)

Aaand done. :-) --TMg 16:50, 14. Jan. 2015 (CET)

Danke! :-) Naudefj (Diskussion) 17:56, 18. Jan. 2015 (CET)

<strike>

Momentan werden ja die <strike>-Tags durch <s> ersetzt. Ist es möglich, eine Kontrolle des abschließenden </s> einzubauen, wenn der Schrägstrich schon vorher vergessen wurde? --Hadibe (Diskussion) 20:55, 7. Jan. 2015 (CET)

In solchen Fällen ist eine Autokorrektur fast nie möglich, nur eine Warnung, und Warnungen gibt es bei mir nicht. Dafür sind andere Werkzeuge besser geeignet, siehe WP:WPSK. --TMg 15:24, 14. Jan. 2015 (CET)

Dates

Script makes change in 0123—0123 years "[[КХЛ в сезоне 2012—2013|2012-13]]"->"[[КХЛ в сезоне 2012–2013|2012–13]]" (try on this [4]). Сharacter "—" should not be replaced. Can you fix this? Or how can I change my .js to disable it is this change? --Сунприат (Diskussion) 11:48, 29. Jan. 2015 (CET)

The reason for this behavior is that I build the script with the German and English style guides in mind. I didn't know the Russian one is different. Thanks a lot for letting me know. I will fix this. --TMg 18:15, 4. Feb. 2015 (CET)

Checkwiki changes

New:

• Error 102. Checks for correct syntax of PMID

Changes:

• Error 69: Now finds cases of ISBN in a wikilink ( [[ISBN]] 978-12345-6789-0) and # symbol (ISBN #978-12345-6789-0)
• Error 2: Checks for <center/>, <small/> and <br clear
• Error 85: Checks for <center></center> and <gallery></gallery>
• Error 34: Catches more cases. See Instances of 'subst:' in articles

Bgwhite (Diskussion) 22:32, 2. Feb. 2015 (CET)

Cool. Thanks for letting me know! --TMg 18:31, 4. Feb. 2015 (CET)

Hinweis

Nach dem Bearbeiten mit dem autoFormatter auf den Artikel Horst Szymaniak hat sich Benutzer:Wahrerwattwurm bei mir gemeldet (siehe hier). Ich kann kein Problem bzw. Unterschied sehen. --Atamari (Diskussion) 10:17, 4. Feb. 2015 (CET)

Dort (BD) kommentiert. LG --PerfektesChaos 11:23, 4. Feb. 2015 (CET)

Das Verhalten meines Skriptes ist genau so erwünscht, PerfektesChaos hat das perfekt erklärt. Danke dafür! Was mich am Artikel Horst Szymaniak generell wundert, ist nicht nur das veraltete HTML, sondern überhaupt, dass die Aufstellungsgrafik „zu Fuß“ mit dafür gar nicht vorgesehenen Vorlagen „gebastelt“ wird. Hat das Fußballportal keine Vorlage dafür? Bemerkenswerterweise nicht. Die benutzen SVG dafür. So sollte es meiner Ansicht nach auch sein. --TMg 18:31, 4. Feb. 2015 (CET)

Weitere Optionen

Hallo TMg. Ich verwende den autoFormatter, nachdem ich andere, ähnliche Skripts ausprobiert und für mässig tauglich befunden habe, schon lange, und zwar bei fast jedem ANR-Edit. Also erstmal vielen Dank für das tolle Tool! Zwei Ersetzungen stören mich allerdings regelmässig. Ich persönlich mag keine nbsps, weil ich ihren praktischen Nutzen nicht sehe und sie den Quelltext unleserlich machen - und häufig auch die Diffs, weil das Skript in manchen Artikeln in fast jeder Zeile ein solches geschütztes Leerzeichen einfügen will, so dass die eigentlichen Änderungen untergehen. Und Ersetzungen von Links nach dem Schema [[XYZ|XYZ 123]] -> [[XYZ]] 123 sind mir in aller Regel zu heikel, um sie mal eben nebenbei durchzuführen. Letzteres liesse sich wohl durch die Option autoFormatMaskedLinks = false vermeiden, dann würde ich aber auch alle (meiner Ansicht nach sinnvollen) Korrekturen nach dem Muster [[XYZ|XYZs]] -> [[XYZ]]s verlieren, und die überwiegen klar. Für die geschützten Leerzeichen gibt es gar keine Option. Ich fände es also schön, wenn diese beiden Änderungen ein Opt-out anbieten würden. Verstümmeln brauchst du dein Skript dafür natürlich nicht, aber wenn es machbar wäre, wäre ich froh. --YMS (Diskussion) 09:50, 5. Feb. 2015 (CET)

• autoFormatMaskedLinks tut, was du möchtest. Ich hab es auf der Vorderseite genauer beschrieben.
• Bei geschützten Leerzeichen meine ich, sehr zurückhaltend zu sein, weil ich die Lesbarkeit des Quelltextes ebenfalls als sehr wichtig einschätze. Ich entferne sie in vielen Fällen sogar, u. a. in Überschriften und teils in Lebensdaten und zwischen Monaten und Jahren. Ich setze sie nur ein, wo mir der Nutzen signifikant erscheint, weil die an den Zeilenenden auseinander gerissenen Fragmente sonst keinen Sinn mehr ergeben: Bei „§ 1“ und bei „1 m“. Das war es eigentlich. Ich vermute, die spielst auf die Maßeinheiten an? Ich könnte mir vorstellen, diese Regel zu verfeinern und z. B. bestimmte längere Einheiten raus zu nehmen oder die Länge der Zahl davor zu berücksichtigen. Hast du Vorschläge oder ein Beispiel, das dich besonders nervte?

--TMg 15:54, 5. Feb. 2015 (CET)

Danke für die autoFormatMaskedLinks-Info/Doku-Klarstellung. Ich hatte (vermutlich schon öfter) sogar im Code nachgeschaut, aber offensichtlich zu flüchtig und dann übersehen, dass im else-Fall ja trotzdem noch was gemacht wird.

Und für die geschützten Leerzeichen kann ich dir leider kein besonderes Beispiel präsentieren. Wäre aber möglich, dass mich das eine oder andere Mal auch die Entfernung derselben gestört hat. Während die bei Prozentzeichen und in Überschriften wohl auch für mich immer okay ist, würde ich vermutlich auch eine Änderung wie "14.&nbsp;Dezember&nbsp;1911 -> 14.&nbsp;Dezember 1911" nicht abspeichern wollen (weil sie mir erstens unvollständig erscheint und ich zweitens nicht demjenigen ins Handwerk pfuschen will, der diese Leerzeichen da für angebracht hält).

Aber vielleicht bin ich mit der deaktivierten autoFormatMaskedLinks-Optionen ja bereits glücklich. --YMS (Diskussion) 16:12, 5. Feb. 2015 (CET)

Ich bin sehr an jeder Anregung interessiert, die die Zufriedenheit der Benutzer mit meinem Skript und dem, was es tut, steigert. Regeln, die mit geschützten Leerzeichen hantieren, hab ich aber mehrere, und ich möchte keinen Schalter einbauen, der alle einfach abschaltet. Achte mal darauf, welche Art von Ersetzung die für dich nervigste ist und zeig mir ein oder zwei Beispiele dafür (idealerweise mit Permanentlinks), dann überleg ich mir was. --TMg 16:55, 5. Feb. 2015 (CET)

Ich hab' meine Edits nun mal einige Zeit beobachtet, und bin zu dem Ergebnis gekommen, dass mich alle nbsp-Einfügungen stören. Musst du aber nichts gegen tun, zumal ich ohnehin plane, in Zukunft verstärkt den Visual Editor einzusetzen. --YMS (Diskussion) 16:37, 5. Mai 2015 (CEST)

Danke. Dennoch: Ich nehme das durchaus ernst und werde mir was überlegen. Schritt 1: Alle nbsp-Regeln kritisch prüfen.

• In § 1 A. 1 S. 1 werden schlimmstenfalls 3 nbsp eingefügt. Das ist vielleicht unnötig viel und könnte z. B. die Länge der Zahlen berücksichtigen (z. B. nur bei 1 und 2-stelligen Zahlen).
• Bei Dateigrößen erachte ich die nbsp als wichtig, unabhängig von der Länge der Zahl.
• Auch von den Entfernungen bin ich überzeugt, sonst hätte ich es nie gewagt, sie aufzunehmen.
• Bei den Maßeinheiten könnte ich weitere raus werfen (ich denke da in erster Linie an die 3-buchstabigen Währungskürzel EUR usw.) sowie die Länge der Zahl berücksichtigen (z. B. nur bei max. 3-stelligen Zahlen, „1000 m“ bliebe also unangetastet).

Schritt 2: Einen Schalter zum Abschalten aller nbsp-Regeln einbauen. --TMg 16:34, 6. Mai 2015 (CEST)

Links einkürzen

Das Einkürzen der Wikilinks funktioniert im Skript nicht, wenn sich die Links durch Groß- und Kleinschreibung unterscheiden. Beispiel: [[Alkoholische Gärung|alkoholische Gärung]] in Alkoholersterwerbsalter. --Hadibe (Diskussion) 04:11, 6. Apr. 2015 (CEST)

Ebenso bei führendem oder angehängtem Whitespace, Beispiel [[Begabung| Begabungen]]. --YMS (Diskussion) 18:21, 7. Apr. 2015 (CEST)

Danke, solche Beispiele sind ungemein hilfreich. Der Fall mit dem kleinen Anfangsbuchstaben ist interessant, aber leider nicht generalisierbar, da es Wikis gibt, in denen die Großschreibung signifikant ist. Ich denke, ich werde das nicht aufnehmen können, wenn mein Skript in solchen Wikis nutzbar bleiben soll. Der Fall mit den Leerzeichen steht bereits auf meiner Agenda. --TMg 16:14, 6. Mai 2015 (CEST)

Can you not add a configuration variable to enable this kind of change if a user wants it? It would be very helpful on the majority of Wikipedias. - dcljr (Diskussion) 11:39, 5. Aug. 2016 (CEST)

Could you please see en:Wikipedia talk:User scripts#Regex or user script for simplifying piped links of mixed case and comment there? I would appreciate your "expert opinion" on the matter… - dcljr (Diskussion) 06:20, 26. Aug. 2016 (CEST)

Subtraktion mit #expr:

Anscheinend wird eine Subtraktion nicht als Berechnung erkannt und deshalb mit einem Viertelgeviertstrich Halbgeviertstrich versehen:{{#expr: 740 - 585}} = 155
Beispiel: Ascher (Pass) --Hadibe (Diskussion) 00:14, 17. Apr. 2015 (CEST)

Die Antwort darauf ist schlicht, dass Vorlagenprogrammierung nichts im Artikelnamensraum zu suchen hat. Innerhalb von Vorlagen sind solche Konstrukte üblicherweise durch <includeonly> oder ähnlich umspannt, das berücksichtigt mein Skript bereits. Allein stehende Parserfunktionen werde ich jedoch nicht gesondert behandeln. Das würde die Komplexität und Fehleranfälligkeit des Skripts stark erhöhen, der Nutzen wäre jedoch nur gering. Du kannst solche Fehlersetzungen als Aufforderung verstehen, den Wikitext an dieser Stelle in Ordnung zu bringen. Außerdem hast du die Möglichkeit, vor dem Drücken des Auto-Format-Besens nur den Teil des Textes zu markieren, in dem aufgeräumt werden soll. --TMg 16:09, 6. Mai 2015 (CEST)

Unerwünschtes Leerzeichen vor Prozentzeichen in Style-Attribut

Siehe <div style="padding:5% 0 10% 0;">. --Seth Cohen 23:19, 4. Mai 2015 (CEST)

Faszinierend. Danke. Dass derartiges HTML nichts in Artikeln verloren hat, darin sind wir uns denke ich einig. Unabhängig davon ein sehr hilfreiches Beispiel zur Verbesserung meines Skripts. Ich schau mal, ob mir was dazu einfällt. --TMg 16:17, 6. Mai 2015 (CEST)

IMDb

Hallo,

die Vorlagen {{IMDb Titel}} und {{IMDb Name}} werden zurzeit durch {{IMDb}} ersetzt. Die neue Vorlage ignoriert mit getArticleBase Klammererweiterungen. D.h. z.B. im Artikel „Titanic (1997)“ kann bei „{{IMDb|tt0120338|Titanic}}“ der letzte Parameter gekürzt werden.--CENNOXX 16:36, 20. Mai 2015 (CEST)

Ich verstehe nicht ganz. Was heißt „werden“? Ist das ein Projekt? Wo ist das dokumentiert? Ich glaube, du schlägst vor, diese neue Vorlage in meinen redundantTemplateParameters-Regelsatz aufzunehmen und den zweiten Parameter zu kürzen, wenn er mit dem Artikelnamen identisch ist? --TMg 18:35, 20. Mai 2015 (CEST)

Mein Kommentar ist in der Tat etwas undurchsichtig. Derzeit gibt es einen Botlauf, bei dem die Ersetzung durchgeführt wird (vgl). Mir gings eher darum, dass die Vorlagen IMDb Titel & Co. demnächst (also in einer Woche oder so) aus dem Quelltext raus können und um die Kürzung des zweiten Parameters.--CENNOXX 00:34, 21. Mai 2015 (CEST)

Ok, danke. Ich habe die neue Vorlage in alle Regelsätze (Schreibweise säubern, Leerzeichen entfernen, redundante Titel entfernen) aufgenommen. Die alten Vorlagen sind noch in vielen Sprachversionen in Benutzung. So lange keine Fehlersetzungen auftauchen, behalte ich die bei. --TMg 15:27, 21. Mai 2015 (CEST)

Schaltfläche

Seit dem letzten Update wird in Artikeln mit Leerzeichen am Ende von Infoboxparametern die „autoFormatter“-Schaltfläche in der Werkzeugleiste nach dem Anklicken auch dann grün, wenn das Skript keine Änderungen vorgenommen hat. Finde ich etwas verwirrend. Gruß, --K. Kokolores 15:41, 3. Jun. 2015 (CEST)

Danke für den Hinweis. Das hatte ich beim Freischalten der Änderung übersehen. Sollte jetzt wieder wie gewohnt funktionieren. --TMg 12:29, 4. Jun. 2015 (CEST)

In Mikojan-Gurewitsch MiG-105 gibts ein Problem mit dem Tool

Hallo TMg,
wenn man hier den autoFormatter aufruft, werden Gedankenstriche als bis interpretiert.
Wie immer herzlichen Dank für das tolle Tool.
Gruß --Baumfreund-FFM (Diskussion) 08:47, 5. Jul. 2015 (CEST)

Interessant, danke. Ich habe die Regel ein wenig strenger gemacht, so dass dieser Fall jetzt ausgeschlossen ist, Schreibweisen wie „von Mitte 1901 – 2. Januar 1902“ aber noch eingeschlossen sind. --TMg 12:59, 22. Sep. 2015 (CEST)

Viele Bilder nacheinander bringen das Script ins Straucheln

...oder eher gleich zum Stolpern. Der Artikel Große Berliner Kunstausstellung beginnt mit über 20 Bildern. Wenn ich das Script dort benutzen will, meldet der Firefox hier auf meiner Workstation nach einiger Zeit lediglich, dass das Script ungewöhnlich braucht. Das kann ich problemlos fünf Mal wiederholen, bis es mir zu blöd wird. Wenn ich das Script nur auf die Hälfte der Bilder anwende, läuft's gewohnt schnell durch, bei allen auf einmal (auch ohne den Rest des Artikeltextes) kommt's nie zu einem Ergebnis. --YMS (Diskussion) 13:20, 8. Jul. 2015 (CEST)

Das ist leider ein Fehler in der Regex-Engine von Firefox, der mich an anderer Stelle bereits gezwungen hat, eine Funktion komplett abzuschalten. Ich werde das untersuchen, vielleicht findet sich ein Workaround. Ich empfehle, vor allem bei sehr großen Artikeln nur den relevanten Teil des Wikitextes zu markieren (z. B. den Abschnitt, den du gerade bearbeitet hast) und erst dann auf den Besen zu klicken. Das vermeidet solche Probleme meist. --TMg 13:05, 22. Sep. 2015 (CEST)

Ich habe den Fehler eingegrenzt und den Performanzeinbruch ganz deutlich abgeschwächt. --TMg 10:13, 27. Nov. 2015 (CET)

Hochgestellte Ziffern

Hallo TMg,
hier wird das Verhalten bei hochgestellten Ziffern kritisiert. Kannst Du mal schauen, ob Du das berücksichtigen kannst?
Gruß --Baumfreund-FFM (Diskussion) 20:12, 17. Aug. 2015 (CEST)

Das Problem tauchte bereits einige Male auf und inzwischen berücksichtigt das Skript alles, was zu berücksichtigen ist, und lässt hoch- und tiefgestellte Ziffern in chemischen Formeln unangetastet. Maßeinheiten wie km² und m³ schreibt man aber nun mal so. Dafür sind die Unicodezeichen da. Unschönheiten in der Darstellung von Unicodezeichen sind generell ein Problem der Schriftart auf dem jeweiligen Endgerät. Mit einer anderen Schriftart oder schlimmstenfalls einem Update des Betriebssystems wird dieses Problem verschwinden. Umgekehrt bedeutet die Verwendung von m<sup>2</sup>, dass der Wikitext für alle Benutzer unleserlicher und vor allem ganz extrem fehleranfälliger wird, und dass die Darstellung dafür auf anderen Endgeräten unschön aussieht. Man versucht sozusagen, den Teufel mit dem Beelzebub auszutreiben. Das funktioniert nicht, das könnt ihr jemandem, der 20 Jahre HTML- und 10 Jahre Wikitext-Erfahrung hat, glauben. Die ² und die ³ sind auf den meisten Tastaturen erreichbar und sie werden hier in diversen Formatierungs- und Sonderzeichen-Leisten genau so angeboten, nicht via <sup>. --TMg 13:20, 22. Sep. 2015 (CEST)

Danke für die Erläuterung. --Baumfreund-FFM (Diskussion) 12:10, 24. Sep. 2015 (CEST)

Wikipedia:Schreibweise von Zahlen#Exponentialdarstellung gilt auch für dich. Falls du damit nicht einverstanden bist, so sprich dies bitte auf der dortigen Disk. an. --Leyo 12:23, 24. Sep. 2015 (CEST)

Siehe die etwas differenziertere Bemerkung bei Hilfe:Sonderzeichen #Mathematische Zeichen.

• Steht dort inhaltlich/sinngemäß unverändert und unangefochten seit inzwischen mehr als zehn Jahren.

Wird in Hunderttausenden von Artikeln auch so praktiziert; vielleicht in einer Million Artikel – Cirrus streikt schon.

Es wäre also eher WP:SVZ zu konkretisieren.

• Nebenbei ist es Unsinn, den middot noch von zwei nbsp zu umschließen. Der schafft sich seinen notwendigen Raum in 5·10¹²³ schon selbst.

LG --PerfektesChaos 12:54, 24. Sep. 2015 (CEST)

Bitte nicht in diesem Ton, Leyo. Das Skript rührt Exponentialdarstellungen und Potenzen nicht an. Es bringt ausschließlich die Maßeinheiten mm², cm², m², km² sowie mm³, cm³, m³ und km³ in die einheitliche, wie von PerfektesChaos dargelegt seit mehr als 10 Jahren hier und überall sonst im Web so übliche Form. Ich bin gern bereit, über die Auswahl dieser Maßeinheiten zu diskutieren und einzelne zu entfernen, die im Hausgebrauch weniger üblich sind und für die das Argument „offenkundig und vertraut“ nicht gilt. --TMg 16:48, 24. Sep. 2015 (CEST)

Den Ton halte ich nicht für zu scharf, solange dein Script gegen Wikipedia:Schreibweise von Zahlen#Exponentialdarstellung verstösst (genanntes Beispiel). --Leyo 12:34, 27. Nov. 2015 (CET)

Da verstößt nichts. Lies die Regelseite bitte selbst noch einmal und zeige die Stelle auf, an der dort vom Maßeinheiten die Rede ist. --TMg 16:01, 27. Nov. 2015 (CET)

Markup in Links

Hallo TMg.

Der Visual Editor setzt, wenn man einen kompletten bestehenden Link z.B. kursiv setzen will, das Markup dafür in den Link ([[Foo|''Foo'']], Beispiel-Diff). Das ist unschön, weil der Linktext dabei unnötig dupliziert wird. Es wäre schön, wenn der Autoformatter da aufräumen könnte (noch schöner wäre es natürlich, wenn der VE sowas gar nicht erst machen würde - aber dieselbe Formatierumgseigenart könnten auch menschliche Benutzer oder andere Tools produzieren). --YMS (Diskussion) 21:53, 11. Sep. 2015 (CEST)

Eine sehr sinnvolle Ergänzung, unabhängig vom Fehler im Visual Editor. Danke für die Idee. Ist jetzt zum Test in der Betaversion. --TMg 12:57, 22. Sep. 2015 (CEST)

Vorlage:BAnz

Hallo TMg,
der autoFormatter formatiert auch in der Vorlage das Datum um und erzeugt damit einen Vorlagenfehler (Beispiel).
Kannst Du da was machen?
Gruß --Baumfreund-FFM (Diskussion) 19:12, 28. Okt. 2015 (CET)

Leider nein, da der Inhalt dieser Vorlage wie ganz normaler Fließtext aussieht. Einen Schutz, der bestimmte Vorlagen ganz ausnimmt, habe ich bisher nicht. --TMg 09:39, 27. Nov. 2015 (CET)

Danke fürs nachschauen.

Schade, dann muss ich mal schauen, wie ich damit klar komme.

Gruß --Baumfreund-FFM (Diskussion) 06:16, 30. Nov. 2015 (CET)

Turning {{Cite}} to {{cite}}

Is there a reason why the tool turns capitalized citation templates to lowercase ones? I've ignored it as I felt that it was benign, but others take issue with it. If there is a not policy recommending these changes, I would like a setting to disable them so as not to be considered disruptive. Thanks. Ost316 (Diskussion) 23:10, 13. Jan. 2016 (CET)—

Such capitalization changes are critical for many German templates, but almost completely irrelevant in English. I removed this specific rule now. --TMg 15:51, 15. Jan. 2016 (CET)

Besen färbt sich nicht mehr

Hallo TMg,
obwohl das Skript offensichtlich arbeitet, färbt sich der Besen seit einigen Tagen anschließend nicht mehr. (Zwei verschiedene Win7-Rechner, aktueller Firefox, ein Win7-Rechner IE, Chrome).
Bitte schau mal nach.
Gruß --Baumfreund-FFM (Diskussion) 07:47, 16. Jan. 2016 (CET)

Na super. gerrit:186639. Danke für die Meldung, ich habs behoben. CC Fomafix. --TMg 17:32, 18. Jan. 2016 (CET)

Danke. --Fomafix (Diskussion) 17:36, 18. Jan. 2016 (CET)

Das erleichtert mir die Arbeit sehr - danke. --Baumfreund-FFM (Diskussion) 06:58, 19. Jan. 2016 (CET)

Lokalisierungen schweizbezogen und österreichbezogen

Siehe WP:Schweizbezogen und WP:Österreichbezogen. Das Helferlein Wikipedia:Helferlein/Rechtschreibprüfung beachtet «schweizbezogen», und „österreichbezogen“ (Prüfung auf einfaches Vorkommen des Strings, daher funktioniert das sowohl bei Vorlagen als auch html-Kommentar. AutoFormatter ist bei «schweizbezogen» vor allem bei den Anführungszeichen betroffen, bei österreichbezogen beim expandieren von Kurzdatum in Langform beim Monat Jänner. (Die Verwendung von Hochkomma als Tausendertrennzeichen bei schweizbezogen müsste man vor der Umsetzung überprüfen, ob das anderwertige Probleme zur Folge hätte (z.B. Nicht-Erkennung von Zahlen innerhalb von Vorlagen))  Frohes Schaffen — Boshomi ☕⌨☺   23:08, 26. Feb. 2016 (CET)

Danke für den Hinweis, damit hatte ich mich bisher noch nie beschäftigt. Ich habe Testfälle und den Jänner hinzugefügt. Weitere Fehler konnte ich nicht finden. Mit Tausendertrennzeichen mache ich nichts. Ob ich in schweizbezogenen Artikeln ungefragt die "geraden Anführungszeichen von der Tastatur" durch «spitze» ersetzen sollte, da bin ich mir noch unsicher. --TMg 13:50, 29. Feb. 2016 (CET)

Bei den Guillemets könnte man prüfen, ob so ein Klammernpaar schon vorkommt, und das nur solchen Artikeln ersetzen, wo das der Fall ist. Damit wird zumindest der Artikel einheitlich. Frohes Schaffen — Boshomi ☕⌨☺   11:58, 2. Mär. 2016 (CET)

Danke, die Idee gefällt mir wirklich gut. --TMg 12:46, 3. Mär. 2016 (CET)

Bitte bei österreichbezogen und schweizbezogen nur auf den string /österreichbezogen/i und /schweizbezogen/i prüfen, die Klammern, html-kommentarzeichen,... einfach ignorieren, denn so funktioniert auch Appers Rechtscheibhelferlein (weshalb die Umstellung von österreichbezogen auf die Vorlage technisch kein Problem war). Frohes Schaffen — Boshomi ☕⌨☺   16:31, 3. Mär. 2016 (CET)

nochmal nachgedacht: besser wäre es vielleich die Zeichen zu prüfen „“ ’ ‚‘ “” ‘’ und wenn diese vorhanden sind, werden diese auch bei Schweizbezogen weiterverwendent, kommen sie noch nicht vor werden «» als Standard für Schweizbezogen genommen. Frohes Schaffen — Boshomi ☕⌨☺   12:09, 14. Mär. 2016 (CET)

Ich habe inzwischen genug Testfälle gesammelt, die zeigen, dass es tatsächlich sinnvoll ist, nur auf die Wörter zu prüfen. Zur Prüfung verwende ich nur die öffnenden „ und « und halte das für ausreichend. Schließlich macht mein Skript ja nichts mit englischen (die bleiben gerade) oder einfachen Anführungszeichen. Ich baue das aber gern weiter aus, wenn konkrete Fälle auftauchen, in denen meine aktuelle Logik nicht ausreichend ist. --TMg 10:17, 17. Mär. 2016 (CET)

Wikisource-Links

Hallo. Wikisource-Links sollten lieber nicht angetastet werden. Hier ein Beispiel. Ist wahrscheinlich ähnlich wie weiter oben schonmal bei den CommonsLinks angemerkt. Oder ließe sich da was machen? Grüße, --BlueCücü (Diskussion) 18:27, 3. Mär. 2016 (CET)

Ich versteh leider nicht, was du meinst. In dem Artikel finden nach deinem Edit gar keine Ersetzungen mehr statt, und auch in deinem Edit sehe ich nichts, was falsch wäre. „Wikisource“ wird als Eigenname groß geschrieben. Meinst du das? --TMg 17:46, 4. Mär. 2016 (CET)

Das Apostroph im WikisourceLink wird geändert. Dell'arte --> Dell’arte. (War lange nicht aktiv. Vielleicht liegts auch an meinen privaten Einstellungen, die ich dann mal überdenken sollte.) --BlueCücü (Diskussion) 22:14, 4. Mär. 2016 (CET)

Ja, das kommt aus deiner common.js. --TMg 14:56, 6. Mär. 2016 (CET)

Danke fürs Nachschauen. --BlueCücü (Diskussion) 08:28, 19. Mär. 2016 (CET)

Commons-Kategorienamen vor Änderungen schützen

(BK) Hallo TMg, danke auch für die Nachricht. Bei deinem Skript (egal ob ich es anwende oder andere), stolpere ich immer wieder über die folgenden Probleme:

• In Parametern, die links auf Commons darstellen, werden regelmäßig der Bindestrich ersetzt und typographische Hochkommata eingefügt. Das erzeugt dann einen dangling iw-Link. Gibt es dafür eine Konfiguration oder ließe sich eine schaffen, die bestimmte Vorlagenparameter wörtlich nimmt und nicht modifiziert? Per Vorlagenparameter und Infobox? Analog zu autoFormatTemplates. Irgendwo würde es dann vielleicht noch eine zentrale Stelle brauchen, die für alle VerwenderInnen deines Skripts gilt (ist ja nicht anwendungs-, sondern infoboxspezifisch).
• In der {{Denkmalliste Österreich Tabellenzeile}} wird der Parameter Name 1:1 aus unserer Quelle entnommen und jährlich beim Update auf neue Daten 1:1 textuell verglichen. Alle Veränderungen an Name sind daher kontraproduktiv. Natürlich könnte Krd den Vergleich smarter machen, … Aber man könnte das auch mit dem obigen Mechanismus erschlagen. Was meinst du? Name in {{Denkmalliste Österreich Tabellenzeile}} ist jetzt nur ein Beispiel, es könnten auch andere Stellen/UserInnen Stringvergleiche machen, die nach solchen Ersetzungen schief gehen. Dazu kenne ich die individuelle Arbeitsweise bei vielen Updates nicht (WLPA, WLE, …)
• Unnötig finde ich, dass bei wertlosen Voragenparametern alle spaces hinter dem = entfernt werden, auch wenn die Formatierung |_ = _\n ist. Füllt man den Parameter aus, muss der Zwischenraum wieder ergänzt werden. Diese Ersetzung müllt nebstbei bei großen, vorlagenbasierten Listen die diff ziemlich zu. Mit trim:false ist das ziemlich smart. RTFM. Das Problem was bleibt: unbedarfte Anwender konfigurieren dein Skript nicht richtig.
• (Spaces zur Deutlichkeit als _ dargestellt) Aufgefallen ist mir, dass dein Skript zwar ' _' durch ' ' ersetzt, nicht aber das entsprechende '_ ' mit dem Space vorne.

mit autoFormatTemplates brauche ich den m=multiline parameter gar nicht. (danke, wieder was neues gelernt: RTFM, RTFM, always RTFM.)

lg --Herzi Pinki (Diskussion) 12:15, 14. Mär. 2016 (CET)

Den Vorschlag von Boshomi oben, bei den benutzerdefinierten Änderungen für jedes Suchen-Ersetzen-Paar auch einen Editkommentar angeben kann halte ich für eine Verbesserung im Sinne der Akzeptanz der durch das Skript durchgeführten Änderungen. lg --Herzi Pinki (Diskussion) 12:15, 14. Mär. 2016 (CET)

Hallo ihr beiden. Das Mockup ist großartig und die damit verbundenen Ideen ebenso, vielen lieben Dank dafür. Leider habe ich vieles von dem, was ihr schreibt, noch nicht verstanden.

1. Was meinst du mit „Parametern, die links auf Commons darstellen“? So etwas wie |Commons = Kategoriename in Denkmallisten?
2. Gedankenstriche sind meines Wissens auch in den englischen Kategorienamen auf Commons zu verwenden. Eine Lösung könnte also darin bestehen, diese Kategorien zu verschieben.
3. Mit typographischen Hochkommas mache ich gar nichts. Das dürfte eine benutzerdefinierte Ersetzung sein. Kannst du mir ein konkretes Beispiel zeigen?
4. Das mit dem Namensparameter ist sehr interessant. Es wäre sehr hilfreich, eine ganz konkret Liste von Änderungen zu haben, die dort vorkommen.
5. Die Ersetzung von  \s+ ist benutzerdefiniert. Die kannst du bei dir erweitern, wenn sie mehr tun soll.

--TMg 11:14, 17. Mär. 2016 (CET)

Nur zum Mockup und common.js: Der Hintergrund ist, dass ich viel mit unterschiedlichen Browsern und Geräten arbeite, und gerne auch lange Listen einstelle. Die Daten so eines Formulars werden meines Wissens nach aber nur im LocalStorage abgelegt, und sind damit spezifisch für nur einen Computer und einen Browser. Mit Hilfe der Variable in common.js kann man seine festen Einstellungen überall verwenden.

Die Schaltfläche im Mockup "auf Standard zurücksetzen" würde bedeuten, dass man default-Einstellungen von Autoformatter übernimmt. "common.js einlesen" würde dann bedeuten, dass zusätzlich die in common.js gespeicherten Objekte einliest.

Alternativ wäre nur eine Schaltfläche "auf Standard zurücksetzten" und dafür eine zusätzliche eine Schaltfläche "alle/keine auswählen" für benutzerdefinierte Ersetzungen, In diesem Fall würde "auf Standard zurücksetzen" bedeute, dass auch common.js eingelesen wird.  Frohes Schaffen — Boshomi ☕⌨☺   13:32, 17. Mär. 2016 (CET)

Hallo TMg,

1. ja, |Commons = Kategorie/Seitenname bzw. |Commonscat = Kategoriename, natürlich verstehe ich deine Lösung mit dem Umbenennen auf Commons, aber habe das noch nie bei den vielen Anwendern deines Skripts beobachtet, dass die auch auf Commons umbenennen. Bei Filenamen machst du diese Ersetzung doch auch nicht (aber die kannst du wahrscheinlich leichter am Suffix erkennen).
2. commons:Commons:Language policy gibt übrigens die notwendige Verwendung von Gedankenstrichen nicht vor. mE.
3. {{xxxxx |Commonscat= Mit falschen "Hochkommata" und - (Bindestrich) }} In meinen Einstellungen finde ich das nicht.
4. ad Name: ich sammel das nach Ostern zusammen. Es geht aber nicht um die Änderungen, die vorkommen (das hat unser Datenprovider komplett in der Hand, und zwar ohne Rechtschreibprüfung, 4-Augenkontrolle, QS oder Ähnlichem.), sondern um Änderungen unsererseits die beim Vergleich gerade noch als gleich akzeptiert werden. Bsp. werden die Schreibweisen hl. und Hl. als gleichwertig betrachtet und damit nicht als Unterschied ausgewiesen. Wir machen da quasi einen halbautomatischen Dreiwegmerge. Ein Bsp. für die letztes Jahr ausgewiesenen Unterschiede findest du hier. Korrekturen werden über den Parameter Anzeige-Name eingebracht.
5. 20% selber schuld ist zwar auch nicht super, aber besser als 100%. Sorry. Kommt wohl so öfter vor.

lg --Herzi Pinki (Diskussion) 02:07, 20. Mär. 2016 (CET)

@TMg: folgende Ersetzungen werden beidseitig vor dem Vergleich beim Update der Denkmallisten AT gemacht:

   s/\behem(?:\.|alige[srn]?) /ehem. /g;
   s/\bkath(?:\.|olisch(?:e[rn]?)?) /kath. /g;
   s/\bheilig(?:e[rn]?)? /hl. /g;
   y/„“/""/;
   s/"//g;
   s/\bund\b/u./g;
   s/\s*,\s+/ /;
   s# ?/ ?#/#g;
   s/\s+/ /g;

hilft das? Commonscat muss allerdings gegen Commons passen, nicht gegen die BDA-Daten. lg --Herzi Pinki (Diskussion) 11:48, 30. Mär. 2016 (CEST)

Hallo @TMg:, das Problem mit Commonscat mag ich nicht so im Sande verlaufen lassen. Gerade wieder nachgebessert. lg --Herzi Pinki (Diskussion) 00:45, 13. Mai 2016 (CEST)

Das verläuft nicht im Sande, so lange es unerledigt hier auf dieser Diskussionsseite steht. Es ist nur leider so, dass eine technische Lösung für dieses Problem unverhältnismäßig aufwendig ist. Sage Boshomi bitte, dass er den Auto-Formatter nicht auf komplette Denkmallisten anwenden soll. Die Ersetzungsregeln sind für Artikel gemacht. Sie richten in langen Listenartikeln grundsätzlich mehr Schaden an, als sie nützen. Was gut geht ist, vorher genau den Textabschnitt zu markieren, den man säubern möchte. Aber bitte nicht komplette Listen. --TMg 09:20, 18. Mai 2016 (CEST)

Ich wollte eben eine Blockade einbauen, so dass das Skript gar nichts mehr tut, wenn es merkt, dass man es blind auf eine Denkmalliste anwenden will. Dabei fiel mir ein Lösungsweg ein, der doch etwas leichter umzusetzen war, als ich dachte. Die Parameter |Commons= und |Commonscat= werden jetzt wie Dateinamen vor typografischen Änderungen geschützt. Vorerst nur in der Betaversion. Bitte testen. --TMg 10:42, 18. Mai 2016 (CEST)

Ich hatte beim oben zitierten Edit eher unabsichtlich auf den Autoformatter geklickt, und dabei den Commonscat-Fehler übersehen. Beim Fork, der nur Benutzerdefinierten Ersetzungen sowie die Backup- und Restore-Funktionen enthält, die für sich alleine schon genial sind, tritt das Commonscat-Problem nicht auf. Haupt-use-case für den Fork sind Massenersetzungen wie diese hier: https://meta.wikimedia.org/w/index.php?title=User:Boshomi/global.js&diff=15600429&oldid=15581222 wobei hier absichtlich wegen Fällen wie diese, kein Regexp verwendet wurde, da ich zuvor sowieso jede einzelne URL manuell auf Funktionsfähigkeit überprüfen musste.

Extem nützlich wäre übrigen, wenn sofort nach dem Click und dem durchgeführten Regexp das wikEd-Diff oder das Schnark-Diff geöffnet angezeigt würde. Beim WikEd-Diff hatte ich es schon so weit, dass es in der Konsole vollständig durchgelaufen ist, aber leider scheitete ich beim Sichtbarmachen. Frohes Schaffen — Boshomi ⌨   22:10, 18. Mai 2016 (CEST)

@Herzi Pinki: Die beiden kritischen Änderungen, über die wir gesprochen hatten (Commons-Kategorienamen schützen und Leerzeichen am Ende nicht ausgefüllter Vorlagenparameter behalten), sind live. --TMg 13:15, 23. Jun. 2016 (CEST)

Softhyphen nach Wikilink statt nowiki oder wbr-Tags

In einigen Fällen wird innerhalb von Worten mit nowiki-Tags verhindert, dass das ganze Wort blau unterlegt wird.

Das ist eine [[Wortverkünpfung]]strennung, das kommt so vor oder so [[Wort]]verküpfung oder so [[Wort]]<nowiki/>verküpfung

Der selbe Zweck aber mit bessere Umsetzung wird mit einem Softhyphen (&shy;) erreicht, da dieses ein Trennzeichen liefert, falls das Wort umgebrochen werden sollte. Ebenfalls falsch an solchen Stellen ist das wbr-Tag, das den selben Effekt hat wie die nowiki-Konstruktion. Frohes Schaffen — Boshomi ⌨   19:07, 4. Jun. 2016 (CEST)

Anmerkung insource:/[A-ZÄ-Ü]\]\][A-ZÄ-Ü]?\<nowiki ]*\/\>[A-ZÄ-Ü]/iu liefert derzeit 2800 Seiten, mit über 5000 Treffern. Frohes Schaffen — Boshomi ⌨   19:31, 4. Jun. 2016 (CEST)

Anmerkung zur Anmerkung: <span /> wird zum selben Zweck genutzt und müsste daher noch addiert werden. --Hadibe (Diskussion) 05:50, 9. Jun. 2016 (CEST)

Nur mal einiges zur Klarstellung, obwohl TMg vermutlich geläufig:

1. Das wbr-Tag erzeugt selbstverständlich nicht „dasselbe“, auch wenn Boshomi sowas Ähnliches vor wenigen Tagen bei mir aufgeschnappt, aber nur halb oder überhaupt nicht verstanden hatte.
   • Mit wbr kommte es ohne Trennstrich mitten im Wort zu einer neuen Zeile.
   • Mit nowiki wird das Wort in derselben Zeile fortgesetzt.
2. nowiki ist seit 15 Jahren der Projektstandard, shy eine umstrittene und erst vor wenigen Jahren versucht einzuführende Änderung.
3. nowiki hat etwa 11.000 Vorkommen nach Wikilink.
4. <span/> und <b/> würden demnächst zur Auslösung einer Wartungskat führen und werden dann rechtzeitig vorher per Bot ersetzt.
5. Grammatikalisch ist der Ersatz mittels shy nicht in allen Fällen richtig, beabsichtigt und erwünscht.

VG --PerfektesChaos 22:09, 9. Jun. 2016 (CEST)

Danke für die sehr hilfreiche Ergänzung. So kann ich es kurz machen: Eine pauschale Ersetzung des gängigen [[Linkmuster]]<nowiki />s durch ­ ist in vielen Fällen sachlich falsch und darf es in einem (halb-) automatisierten Skript nicht geben. --TMg 15:07, 20. Jun. 2016 (CEST)

nowiki im Code

Wenn du das nowiki-Tag, das du ganz oben im Code öffnest, am Ende auch wieder schließt, kannst du wie bisher auf die Backslashes in Vorlagensyntax verzichten. Geändert hat sich ja nur die Tatsache, dass ungepaarte Tags wirkungslos bleiben. --Schnark 11:38, 1. Jul. 2016 (CEST)

Wikitext muss also neuerdings balanciert sein? Darauf wäre ich nie gekommen. Vielen lieben Dank für den Hinweis. --TMg 16:26, 4. Jul. 2016 (CEST)

@Schnark, ich suche gerade erfolglos nach dem Announcement davon. Wann wurde das geändert? --TMg 16:35, 4. Jul. 2016 (CEST)

Laut Wikipedia:Technik/Werkstatt#Veraendertes nowiki - tag Verherhalten ?? seit mindestens einem Monat. --Schnark 09:15, 5. Jul. 2016 (CEST)

Defaultsort transliteration

When using autoFormatter on the page ady:Абдзаххэр, it changed:

{{DEFAULTSORT:Абдзэх}}

to:

{{DEFAULTSORT:Abdsech}}

This seems very wrong. (Nevermind that the tag probably is not necessary in the first place.)

I thought maybe it indicated a wiki configuration error, but {{CONTENTLANGUAGE}} on that wiki does return (correctly) "ady". I tried to disable the change using "var autoFormatLocalisation = false;" in my global.js (on Meta), but it didn't work. How do I turn off just that one "fix"? - dcljr (Diskussion) 11:28, 5. Aug. 2016 (CEST)

The default order in categories is the Latin A, B and so on and then the Cyrillic А, Б and so on. This is considered wrong on most wikis and the reason why my script cleans this up. The Latin B and the Cyrillic Б, for example, should be together, not in two groups. The underlying reason and solution for this problem is currently discussed in phabricator:T47443. But this discussion is new and unfinished. As long as this is the case, the solution most wikis agree on is to use individual DEFAULTSORT keys, as you have seen them produced by my script. However, I guess these character replacements do not make much sense on Cyrillic wikis. I will disable it there. --TMg 15:59, 12. Aug. 2016 (CEST)

Position of the button

One more thing, Can we add tab of autoFormatter option on wiki article in p-cactions or p-tools etc? :) Muhammad Shuaib (Diskussion) 03:18, 16. Aug. 2016 (CEST)

How would that work? My script is an editing tool, supposed to be used while editing articles. Your question sounds more like you are looking for a bot or fully automated script. Do you know AutoWikiBrowser? --TMg 17:38, 16. Aug. 2016 (CEST)

Yes, it would be fully automated script. It will add a button in p-views or p-cactions, when we click user defined autoReplacement function will initialize like this one. Muhammad Shuaib (Diskussion) 11:10, 17. Aug. 2016 (CEST)

What do you mean with "initialize"? What's the actual problem you want to solve? What replacements do you want to do? What do you want to achieve? I believe the "extra editbuttons" script does the same as I do: it adds buttons to the wikitext editors toolbar. It's not a bot. --TMg 11:17, 18. Aug. 2016 (CEST)

Yes it adds buttons to editor but it adds an option to p-views as well, as any user intending autoFormat the article achieves his intention while clicking the option "ابرابزار" which at the top of every article without going to the editor. Similarly I want that those user-defined replacements will be changed when I click the button. You should test extra-edit buttons gadget on fa.wiki, then you will realize which feature I request. :) Muhammad Shuaib (Diskussion) 14:27, 18. Aug. 2016 (CEST)

The communities I know dislike it when their watch lists contain to many semi-automatic edits that do nothing but making the wikitext source code look nicer without making the article better. I'm aware that my script is often misused for such semi-automated edits. I kindly ask everybody to not do this. If your community is fine with this then please, go ahead. But I'm sorry to tell you that I will not help making such a usage easier. --TMg 18:25, 18. Aug. 2016 (CEST)

Yes, Our community is ok with these replacements. BTW many thanks to you. :) Muhammad Shuaib (Diskussion) 23:49, 18. Aug. 2016 (CEST)

Ellipses (Auslassungspunkte)

Hallo TMg, alles klar? AF will change three non-spaced periods "..." to elipsis (Auslassungspunkte) "…". On English Wikipedia however, the recommended style is three non-spaced periods, cf. en:MOS:ELLIPSIS. Could you make an exception for enwiki, please? Or even better: on enwiki have "…" turned into "...". Danke, Sam Sailor (Diskussion) 10:17, 24. Aug. 2016 (CEST) Bitte echo an Antwort.

@Sam Sailor: I find the reasons people give for all the typographic sins in the English Wikipedia shameful. When you know a little bit about Unicode you look at an English article and wonder about all the 1960s placeholder characters. But it's not my job to prove the English community to be wrong (or lead by the wrong people). Since the MOS says so, I will disable this rule in the English Wikipedia. --TMg 18:06, 24. Aug. 2016 (CEST)

​You may have a good point there, but as you say yourself, the rules are the rules … until they change. :) Vielen Dank für deine Hilfe. Sam Sailor (Diskussion) 18:15, 24. Aug. 2016 (CEST)

Datumsformat

Hallo TMg, könntest du die Parameter der Vorlage:BAnz von der Formatänderung ausnehmen, bitte, oder sollte man die für schlechte Programmierung schimpfen?

Noch öfter (über 1300 mal) wird das Datum 01.01.1948 aus einem Buchtitel verwendet. Kannst du da was machen, dass das nicht verbogen wird? --androl ☖☗ 18:27, 22. Sep. 2016 (CEST)

Ich würde gern, nur ist das vor allem für Buchtitel fast gar nicht vollautomatisiert machbar. Ich will ja, dass zum Beispiel "zuletzt abgerufen am 1.12.2015" in einem Einzelnachweis korrigiert wird. Wie kann die Software wissen, wo ein Buchtitel beginnt und endet, wenn er nicht z.B. in einem Vorlagenparameter steckt? Ich bleibe da dran, kann aber nichts versprechen. In jedem Fall danke für die wirklich hilfreichen Beispiele! --TMg 15:05, 7. Okt. 2016 (CEST)

Hat etwas gedauert, aber für Vorlage:BAnz ist mir jetzt ein eleganter Kniff eingefallen. Für Buchtitel leider noch nicht. Das steht aber ohnehin auf meiner „ewigen“ Merkliste, deshalb schließe ich diese Diskussion vorerst. --TMg 23:33, 6. Mai 2017 (CEST)

Spaces in header syntax

It seems to me that the usual practice on English Wikipedia (see, for instance, en:MOS:HEAD) is not to add spaces between the text of the header and the equals signs: for instance, ==Header==, not == Header ==. Is there a way to turn off this feature of autoFormatter? Erutuon (Diskussion) 20:32, 8. Okt. 2016 (CEST)

Thanks for asking. My main argument for this replacement is that the wikitext looks much more natural with these spaces. According to the same MOS bullet points should have spaces. The same is true for the heading syntax in common lightweight markup languages. I do not plan to change this. --TMg 10:55, 17. Okt. 2016 (CEST)

"Übereifrigkeiten" bei der Ersetzung

Folgende "Übereifrigkeiten" sind mir aufgefallen:

1. Leerzeichen in XML: <ref name="aaa" > wird zu <ref name="aaa"> beides ist aber valides HTML/XML, das Leerzeichen ist irrelevant.
2. Hochkomma in XML: <ref name=aaa> wird zu <ref name="aaa"> beide Formen werden aber vom Mediawiki Parser ohne Probleme verarbeitet.
3. Kommentare werden nicht übersprungen: Bsp Bindestrich zu Halbgeviertstrich Ersetzung bei <!-- - -->
   Sollten Kommentare nicht grundsätzlich unverändert bleiben ?

Gruß H.-Dirk Schmitt 17:55, 3. Nov. 2016 (CET)

1. Kannst du bitte ausführen, was du mir mit diesen Hinweisen sagen willst? Du scheinst ganz bestimmte Vorstellungen davon zu haben, was ein Skript, das Wikisyntax lesbarer macht, für dich tun soll. Deine Wünsche scheinen jedoch von dem abzuweichen, was ich auf der Vorderseite dokumentiert habe. Insofern brauche ich deine Hilfe, um den Unterschied zu verstehen.
2. Punkt zwei stimmt so nicht. Anführungszeichen werden nicht immer eingesetzt sondern nur, wenn sie die Lesbarkeit erhöhen. Wenn mein Skript noch zurückhaltender vorgehen soll, benötige ich konkrete Beispiele. „aaa“ ist keines, das bleibt bereits unangetastet.
3. Warum sollten Typografiefehler in Bearbeitungskommentaren nicht korrigiert werden? Hilft dir evtl. <nowiki> weiter?

--TMg 22:31, 5. Nov. 2016 (CET)

Zum Hintergrund – ich benutze Dein Skript nicht, aber andere erzeugen damit viele Diffs bei meiner Art zu schreiben. Darum wollte ich Dir Feedback geben

So ist z.B. ein Wort wie falcsh berichtigt worden aber die Änderungen erstrecken sich über den ganzen Artikel.

1. Hier stört mich das viele Differenzen erzeugt werden, die IMHO nicht sinnvoll sind.
2. Sorry - mein Fehler.
3. wie 1., aber zudem sollte das Innere von Quelltextkommentare nie angefasst, weil diese immer einen Inhalt für Tools,… tragen können. Triviales Beispiel eine URL, außerhalb von Wikipedia sind Halbgeviertstrich in URLs selten ;-)

H.-Dirk Schmitt 23:14, 5. Nov. 2016 (CET)

Danke für die schnelle Antwort. Leider ist das für mich nach wie vor viel zu allgemein, als dass ich daraus konkrete Verbesserungsvorschläge für mein Script ableiten könnte. Kannst du mir bitte Links zu Diffs mit ganz konkreten Beispielen zeigen, in denen du dir wünschen würdest, dass es zurückhaltender vorgehen würde? Ich entwickle dieses Script seit inzwischen über 10 Jahren aktiv weiter. Minimale Diffs, wie du sie dir wünschst, sind eine Top-Priorität. Insofern bin ich sehr an deinem Feedback interessiert. Ich brauche jedoch unbedingt echte Diffs, die ich mir selbst ansehen kann. So gut gemeint alle deine Hinweise sind, sie nützen mir nichts, weil du sie bereits so stark verallgemeinert hast, dass ich nicht mehr nachvollziehen kann, welche der über 200 Säuberungen und über 700 Tests ich weiter verfeinern müsste. --TMg 16:08, 6. Nov. 2016 (CET)

Siehe Spezial:Diff/159281633

Blöcke ab Zeile 22 und 70

cu, H.-Dirk Schmitt 16:43, 6. Nov. 2016 (CET)

Danke für den Diff. Allerdings ist da alles genau so, wie es sein soll. Der Trennstrich in Zeile 70 ist ein Typografiefehler. Die zu korrigieren, ist eine der Hauptaufgaben meines Scripts. Und Leerzeichen in allein stehenden XML-Tags wie <br /> werden der Einheitlichkeit und Lesbarkeit zuliebe durchgängig gesetzt. Das ist auch konsistent mit allen gängigen Hilfe- und Richtlinien-Seiten. --TMg 18:36, 6. Nov. 2016 (CET)

Ich habe zusätzliche Testfälle aufgenommen, um sicher zu gehen, dass ich keine Anführungszeichen in <ref name=Beispiel> setze, wo sie nicht nötig sind und es auch sonst nichts an der Schreibweise zu bemängeln gibt. Ich konnte keinen Fehler finden. Hier noch einmal, was das Script tut:

1. Leerzeichen wie in <ref name=Beispiel > sind irreführend und werden zugunsten der Einheitlichkeit und Eindeutigkeit entfernt.
2. Fehlende Leerzeichen wie in <ref name=Beispiel/> werden immer eingesetzt.
3. Sobald eine dieser Änderungen passiert, werden zugunsten der Einheitlichkeit und Lesbarkeit auch immer die Anführungszeichen gesetzt.

--TMg 19:13, 14. Nov. 2016 (CET)

Bibcodes

Moin, könntest du mal einen Blick hier drauf werfen? Ich wüsste nicht wo und wie ich das aktiviert habe. Gruß -- Quotengrote (D|B) 07:15, 7. Nov. 2016 (CET)

Ich habe dort geantwortet. Ursache war eine problematische benutzerdefinierte Ersetzung von Seth Cohen, die dieser schon seit 2012 aktiviert hat. --TMg 09:56, 7. Nov. 2016 (CET)

Spaces in header/headline

Why is this necessary and can the code be tweaked so it doesn't do this? I'm talking about the spacing between equal signs and the header text. From MOS:HEAD: "Spaces around the Title (e.g. == Title ==) are optional and ignored." --Jennica (Diskussion) 02:35, 16. Mär. 2017 (CET)

Please see #Spaces in header syntax above. --TMg 13:59, 16. Mär. 2017 (CET)

Autoformatter

Hallo TMg/autoFormatter, gibt es eine Möglichkeit, dein Skript in einem anderen Javascript (z. B. Bandersnatch von Schnark) zu laden, so dass es die Änderungen dort durchführt, bevor man andere Ersetzungen mit einem weiteren Skript durchführt? Viele Grüße --Crown-job (Diskussion) 16:41, 5. Apr. 2017 (CEST)

Benutzer:Schnark/js/bandersnatch? Ich muss mich deutlich dagegen aussprechen, die Ersetzungen, die mein Auto-Formatter vorschlägt, in irgend einer Weise zu automatisieren. Wenn der Regelsatz so stabil und allgemein akzeptiert wäre, dass man ihn auch automatisieren könnte, dann hätte ich einen Bot oder gleich eine Quelltext-Änderung an der MediaWiki-Software daraus gemacht, und kein interaktives Benutzerskript. --TMg 15:51, 3. Mai 2017 (CEST)

kl. Fehlermeldung

Aus https://de.wikipedia.org/wiki/Spezial:Linkliste/Frederik_Jensen_(Politiker) wird [[Spezial:Linkliste/Frederik Jensen (Politiker]]). Die schließende Runde Klammer wird falsch gesetzt. --Atamari (Diskussion) 16:11, 6. Mai 2017 (CEST)

Danke für die Meldung! Ist angepasst. --TMg 23:23, 6. Mai 2017 (CEST)

Geschütztes Leerzeichen zwischen Dagger und Datum

Warum entfernt dein Skript ein geschütztes Leerzeichen zwischen Dagger (†) und Datum? --Seth Cohen 23:02, 28. Jun. 2017 (CEST)

Weil das in Biografien so gängig und in Wikipedia:Formatvorlage Biografie auch so dokumentiert ist. Obwohl mein Skript bestimmte geschützte Leerzeichen setzt, entfernt es sie in anderen Fällen wieder, weil sie in den leider weitaus meisten Fällen eher schädlich als nützlich sind. Sie vermüllen den Quelltext, machen nachfolgenden Autoren das Leben schwer, und erschweren die Lesbarkeit auf schmalen Bildschirmen (Smartphones). --TMg 12:42, 29. Jun. 2017 (CEST)

Fehler bei Tabellenformatierung mit nbsp

Hallo TMg,

|Viehbesitzer ||130||57||53|| 
|---- style="background:#FFFFFF"

führt zu

|Viehbesitzer ||130||57||53|| |---- style="background:#FFFFFF"

und zerschossener Tabellensyntax. Passiert nur wenn die letzte Zelle der Zeile &nbsp; enthält, was ja sein darf. lg --Herzi Pinki (Diskussion) 23:48, 21. Jul. 2017 (CEST)

Du hast zwei brachiale Regeln in deiner eigenen common.js, die das machen: [/ \s+/g, ' '] und [/\s+ /g, ' '] entfernen jeglichen Leerraum (einschließlich Zeilenumbrüche) vor und nach  . --TMg 22:50, 24. Jul. 2017 (CEST)

Frage zur Vereinfachung von wiki-links

Hallo TMg, dein AutoFormatter macht aus Menschen islamischen Glaubens Menschen islamischen Glaubens. Aus Kunibert der Schreckliche einen Kunibert der Schreckliche. Ich weiß nicht ob das so gut ist, aber vielleicht ist das schon mehrfach durchgekaut worden. Ich würde es besser finden, wenn bei Links mit mehreren Wörtern dein Script die Finger von lassen würde. islamischer Glauben zu islamischer Glauben ist natürlich weiterhin ok. (bitte Source ansehen) lg --Herzi Pinki (Diskussion) 00:16, 22. Jul. 2017 (CEST)

Der Islam ist ein interessanter Fall, in dem der „verdeckte“ Link tatsächlich in Ordnung gewesen wäre. Leider ist das die Ausnahme. In den weitaus meisten Fällen sind verdeckte Links irreführend, z. B. zeigt [[Bayern|Bayerns Innenminister]] nicht auf einen Artikel über den Minister, und [[Kunibert|Kunibert der Schreckliche]] nicht auf einen Artikel über „den Schrecklichen“. Du kannst die Funktion jedoch leicht abschalten, wenn sie dich stört. --TMg 10:05, 7. Aug. 2017 (CEST)

Datumsentlinkung

Hallo TMG,
heute habe ich beobachtet, dass der autoFormatter auf 2. August bei Benutzung jedes weitere Autreten von Jahreszahlen entlinkt. Es mag ja sein, dass dies Standard ist; aber dort ist es nicht üblich und ich finde es auch unschön. Kann ich dieses Feature bei mir abschalten?
Gruß --Baumfreund-FFM (Diskussion) 18:10, 31. Jul. 2017 (CEST)

Tages-Artikel nehme ich seit 2013 aus dieser Entlinkungsregel aus. Das Skript kann das allerdings nur erkennen, wenn der gesamte Artikel inklusive der Tages-Kategorie bearbeitet wird. Wenn Abschnitte bearbeitet werden, würde ich empfehlen, den Säuberungs-Besen nur auf zuvor markierte Textabschnitte anzuwenden. --TMg 00:23, 1. Aug. 2017 (CEST)

Baumfreund-FFM, ich habe eine zusätzliche Ausnahme eingebaut, die Tages-Artikel auch ausschließt, wenn man nur einen Abschnitt bearbeitet. --TMg 09:53, 7. Aug. 2017 (CEST)

Klasse – dankeschön.

Gruß --Baumfreund-FFM (Diskussion) 12:10, 7. Aug. 2017 (CEST)

Hilfe bei einer Ersetzung

Moin TMg, ich habe eine kurze Frage: Ich möchte immer den Text [[Captain (association football)|captain]] mit {{Kapitän}} ersetzen. Leider schaffe ich es nicht eine Anweisung zu schreiben, da ich mit den Sonderzeichen Probleme habe. Könntest du helfen? Danke vorab! --Abu-Dun Diskussion 12:30, 15. Aug. 2017 (CEST)

@Abu-Dun: [ '\[\[Captain \(association football\)\|captain]]', '{{Kapitän}}' ], --TMg 17:53, 4. Sep. 2017 (CEST)

Funktioniert leider nicht. Aus

{{fs player|no=1 |nat=DEN |pos=GK |name=[[Jonas Lössl]]|other=ausgeliehen von [[1. FSV Mainz 05|Mainz 05]]}}
{{fs player|no=2 |nat=ENG |pos=DF |name=[[Tommy Smith (Fußballspieler, 1992)|Tommy Smith]]|other=[[captain (association football)|captain]]}}

wird

{{fs player|no=1 |nat=DEN |pos=GK |name=[[Jonas Löss{{Kapitän}}]|other=ausgeliehen von [[1. FSV Mainz 05|Mainz 05]]}}
{{fs player|no=2 |nat=ENG |pos=DF |name=[[Tommy Smith (Fußballspieler, 1992)|Tommy Smith]]|other=[[captain (association football)|captai{{Kapitän}}]}}

Meine global.js ist hier. --Abu-Dun Diskussion 22:33, 4. Sep. 2017 (CEST)

Ah, bitte entschuldige. Richtig ist [ '\\[\\[Captain \\(association football\\)\\|captain]]', '{{Kapitän}}' ], --TMg 16:42, 5. Sep. 2017 (CEST)

Dann wird leider nur folgendes daraus:

{{fs player|no=2 |nat=ENG |pos=DF |name=[[Tommy Smith (Fußballspieler, 1992)|Tommy Smith]]|other=[[captain (association football)|{{Kapitän}}}} --Abu-Dun Diskussion 08:14, 6. Sep. 2017 (CEST)

Ich habe leider keine Zeit, es selbst zu probieren. Probier mal bitte [ /\[\[Captain \(association football\)\|captain]]/gi, '{{Kapitän}}' ], --TMg 12:00, 6. Sep. 2017 (CEST)

Die Version funktioniert fehlerfrei! Schönen Dank für die Mühe und noch eine entspannte Restwoche. --Abu-Dun Diskussion 12:05, 6. Sep. 2017 (CEST)

Exponentialdarstellung

Hallo TMg,
Gemäß Wikipedia:Schreibweise von Zahlen#Exponentialdarstellung soll die Exponentialdarstellung in html stattfinden; Du wandelst in Unicode um.
Ich bitte Dich zu erläutern warum.
Falls Du dies aufrecht erhalten willst, kann ich dies für mich ausschalten?
Gruß --Baumfreund-FFM (Diskussion) 21:40, 17. Sep. 2017 (CEST)

Exponentialdarstellungen mit „Kombination mit anderen hochgestellten Zahlen oder Minuszeichen“ rühre ich nicht an. Ich setze lediglich allein stehende ² und ³ ein, typischerweise in den Maßeinheiten m² sowie mm³. Diese beiden Zeichen sind im Gegensatz zu den Zahlen ab 4 spätestens seit den 1980er-Jahren in jedem Zeichensatz vorhandenen. Siehe auch /Archiv#Hochgestellte Zahlen. Bitte nenne mir ein oder zwei konkrete Artikel, in denen du deiner Meinung nach problematische Ersetzungen beobachtet hast. Dann schaue ich mir das gern noch einmal an. --TMg 19:02, 21. Sep. 2017 (CEST)

Es führt nicht zu konkreten Problemen, sondern diese Änderungen werden (teil-)revertiert (mit der Begründung der Regelwidrigkeit). Daher möchte ich sie nicht durchführen. Kann ich diese Teilfunktion abschalten?

Gruß --Baumfreund-FFM (Diskussion) 06:30, 26. Sep. 2017 (CEST)

Wie gesagt, zeige am besten ein paar konkrete Beispiele. Verallgemeinert lässt sich dazu nichts weiter sagen. --TMg 18:50, 28. Sep. 2017 (CEST)

Spezial:Diff/167323578 → Bitte Artikel als Ganzes betrachten. --Leyo 19:57, 28. Sep. 2017 (CEST)

Wunderbar, vielen lieben Dank. Das leuchtet ein, dass nicht mitten in einer Formel mit mehreren <sup> ein anders formatiertes Zeichen auftauchen soll. Das ließ sich gut reparieren. Solche Formeln werden jetzt nicht mehr angetastet. --TMg 22:55, 29. Sep. 2017 (CEST)

Hallo TMg,
mein Problem wird dadurch leider nicht gelöst. Ich finde trotz längeren Suchens zwar keines der Beispiele, aber es ist mir extrem unangenehm als Admin wegen einer entgegen den geschriebenen Regeln durchgeführten Änderung revertiert zu werden.
Kann man dieses feature als Benutzer doch irgendwie abschalten?
Gruß --Baumfreund-FFM (Diskussion) 07:24, 30. Sep. 2017 (CEST)

1. Was mein Skript tut, sollte man immer als Vorschlag betrachten. Wenn man sich nicht sicher ist, ob alle Ersetzungen in Ordnung sind, sollte man es entweder gar nicht oder nur auf einen zuvor markierten Abschnitt anwenden. Das Skript ist nicht dafür gedacht, es blind auf jeden Edit anzuwenden, den man irgendwo macht. Wenn das möglich wäre, hätte ich einen Bot daraus gemacht, und kein Benutzerskript.
2. Ersetzungsregeln für Benutzer individuell abschaltbar zu machen, ist selten sinnvoll. Es wäre nur eine Frage der Zeit, bis ein anderer Benutzer kommt, der die Ersetzung trotzdem durchführt.
3. Offenbar gibt es vereinzelt Benutzer, die die für Formeln gedachte Formatierungsregel als pauschales Verbot auslegen, die Zeichen ² und ³ überhaupt zu verwenden. Das halte ich so für untragbar.
4. Ich habe großes Interesse daran, die Fehlerrate so klein wie möglich zu halten. Das geht aber nur mit konkreten Beispielen, wie Leyo sie oben lieferte. Anhand dieses einen Beispiels habe ich die Regel bereits massiv eingeschränkt.

--TMg 16:50, 16. Okt. 2017 (CEST)

Ich suche den Artikel wo ich revertiert wurde und melde mich dann wieder.

Bis dahin bitte ich Dich den Thread offen zu lassen.

Gruß --Baumfreund-FFM (Diskussion) 17:58, 22. Okt. 2017 (CEST)

Ich habe inzwischen den Revert gefunden. Allerdings ist mir jetzt aufgefallen, dass der Begründungslink von der Exponentialdarstellung mit Zehnerpotenzen handelt und somit als Begründung nicht zutreffend ist.

Aus meiner Sicht kann somit dieser Diskussionssthread geschlossen werden.

Danke für die Geduld.

Gruß --Baumfreund-FFM (Diskussion) 06:45, 14. Nov. 2017 (CET)

Danke fürs Raussuchen, das ist sehr hilfreich. Leider meint da wirklich jemand, Quadratmeter und Kubikzentimeter dürften nicht mit den klassischen Zeichen geschrieben werden, und dafür ist die Regel definitiv nicht gedacht. Hin und her revertieren würde ich deswegen nicht, aber ggf. ist ein Hinweis angebracht. --TMg 20:14, 15. Nov. 2017 (CET)

Das habe ich vor, sobald ich wieder die Zeit sehe, eine eventuelle Diskussion verlässlich bedienen zu können.

Mir war zunächst wichtig, dass Du so wenig wie möglich offene Threads hast.

Gruß --Baumfreund-FFM (Diskussion) 05:58, 16. Nov. 2017 (CET)

Edit creating math format error

In this edit en:Special:Diff/808570265 tagged with autoFormatter it mangled a mathematical equation causing a render error. In maths mode spaces are escaped using \ (backslash space) and its legal for one to occur at the end of a line. It looks like autoFormatter removed the trailing space leaving just a trailing \ (backslash) which caused the render error. --Salix alba (Diskussion) 21:14, 3. Nov. 2017 (CET)

Uh, that's super rare. Thanks for the helpful report. I fixed it already. --TMg 12:20, 4. Nov. 2017 (CET)

Empfehlung BR

Hallo TMg, alles Gute im Neuen Jahr 2018, könntest du bitte die Ersetzung des <br> zum <br /> (vermeintlich XHTML) streichen oder sogar die Regel genau umkehren, vgl. WP:HTML5 #br. Danke und freundliche Grüße -- User: Perhelion 19:26, 22. Jan. 2018 (CET)

Anders als vielfach behauptet handelt es sich bei <br /> nicht um ungültige oder veraltete Syntax in HTML 5.

• Siehe HTML 5, W3C Recommendation, 14 December 2017, Abschnitt 8.1.2.1. Start tags – then there may be a single U+002F SOLIDUS character (/) betreffend void-Elemente.

Die Autorenschaft der deWP ist seit anderthalb Jahrzehnten an diese Syntax gewohnt und vergeigt sonst die <references />. Zur Beunruhigung durch sinnlosen Umstellungseifer besteht keinerlei Anlass.

Mit oder ohne Schrägstrich ist jeweils eine von zwei in HTML gleichberechtigten gültigen Schreibweisen. Nirgendwo ist in HTML vorgeschrieben, dass nunmehr der Schrägstrich nicht mehr erlaubt, veraltet, inkompatibel oder sonstwas wäre.

VG --PerfektesChaos 19:52, 22. Jan. 2018 (CET)

Das glaube ich ehrlich gesagt nicht, die Leute haben sich daran gewöhnt weil jahrelang das durch Scripte ersetzt wurde. Es gibt keinen Grund mehr die von Wikimedia bevorzugte Schreibweise bevormundend zu ersetzen. Ich glaube nicht, dass du/wir hier langfristig eine Alleinfahrt machen können. Ich würde mich nicht daran so festbeißen. Ansonsten können wir ja deinem Argument mit einer Umfrage Nachdruck verleihen!? (PS: Hier der neuerliche Anstoß) VG -- User: Perhelion 15:22, 23. Jan. 2018 (CET)

Was der Wiki-Server an den Browser des Lesers schickt, bekommt in 99,999999 % der Fälle niemals ein menschliches Auge zu Gesicht.

• Die dürfen gern diese ein oder zwei Byte einsparen; das interessiert niemanden. Die dürfen außerdem (bis auf pre-Sequenzen) das gesamte HTML-Dokument in eine einzige Zeile schreiben; auch das spart ein paar Bytes und interessiert auch niemanden.

Für unseren Wikitext und unsere Autoren ist das absolut nicht maßgeblich.

Wir haben mühsam gelernt: Wenn da <ref name="x" /> steht, dann bleibt es allein und es kommt nichts mehr. Wenn es <ref name="x"> heißt, dann muss da unbedingt ein </ref> hinterherkommen.

Irgendwelche Änderungen einer anderthalb Jahrzehnte gelebten und vertrauten Praxis müssen einen triftigen Grund haben. Eine zulässige vertraute und übliche Notation mit Gewalt in eine andere zulässige aber bei uns ungebräuchliche Notation umzuändern (wobei der Wikitext ohnehin zunächst durch den Parser geht) würde man dir bei deiner Umfrage eher als Projektstörung und sinnlose Belästigung auslegen.

Wie sich Vorlagenprogrammierer auf Commons kabbeln, interessiert unsere Autoren nicht.

Weil wir gerade bei korrekter HTML-Syntax sind: Seit einem Vierteljahrhundert bezeichnet <kbd> semantisch eine Tastatureingabe und ist nicht als Missbrauch zum Erzeugen von Schreibmaschinenschrift per Nebeneffekt zu verwenden.

VG --PerfektesChaos 16:58, 23. Jan. 2018 (CET)

Hm* also in gleicher Weise wie samp. Du hattest mal gesagt, wir bräuchten auch das tt nicht ersetzen. Dann benutze ich wieder tt, aber wieso darf man eine Signatur "auf keinen Fall" als Tastatureingabe kennzeichnen?

@WSTM: Wenn du (in deinem Tool) so einen Button wie dieses Tool hier hätte, dann bräuchten wir die vollkommen redundante und primitivere Version (für den kleinen Mann?) von TMg doch gar nicht. -- User: Perhelion 19:16, 24. Jan. 2018 (CET)

Als „primitiv“ und „vollkommen redundant“ bezeichnet zu werden ist neu für mich. Meine Regelsammlung hier ist, wenn ich das richtig sehe, 3 Jahre älter als WSTM. Konkurrenzdruck empfinde ich nicht, und wie ich PerfektesChaos' liebenswertem Einspringen hier entnehmen kann, er ebenso wenig. Unsere Werkzeuge folgen anderen Philosophien, und machen teilweise deutlich andere Ersetzungen. Meine wichtigste Philosophie für den hier besprochenen Fall lautet „Einfachheit durch Einheitlichkeit“. Seit einer Weile sind ungeschlossene Tags nicht mehr nur Geschmackssache, sondern werden als Fehler gemeldet und abgearbeitet. Nach einem Jahrzehnt plötzlich damit anzufangen, bei einem einzelnen Ausnahme-Tag das Gegenteil zu machen, empfände ich als unglaublich verwirrend. --TMg 19:18, 3. Feb. 2018 (CET)

Ja ab und zu gibt es etwas Neues... Ich bin lange genug hier um dein Tool einschätzen zu können (wahrscheinlich haben wir gleichzeitig BLueFiSH.as' Tool benutzt). Eigtl. spricht diese Diskussionsseite für sich (vor allem im Vergleich zum WSTM). MfG -- User: Perhelion 22:38, 14. Jun. 2018 (CEST)

Protect ref sections for user-defined replacements?

Hi, TMg. I defined some replacements but afraid to mis-replace references. Is there any configuration about this?

And I perfer adding a space after leading syntax marks:

From:                     To:
*Item 1                   * Item 1
*Item 2                   * Item 2

but my defined replacement don't works.

var autoFormatReplacements = [
	[ /^([*#:;]+)\s*/g, '$1 ' ]
];

I'm unfamiliar with how regex works in JavaScript, how to coding this one? Thanks.--Muhebbet (Diskussion) 19:40, 25. Jan. 2018 (CET)

I would not recommend to automatically add spaces to the list syntax. It creates a lot of noise in diffs, tends to misbehave, and is controversial in many communities. For example, it is very uncommon to add a space after ;. If you want, try the second example. Excluding references is currently not possible. --TMg 18:35, 3. Feb. 2018 (CET)

Probleme bei der Formatierung von Infoboxen

Hallo TMg,

bei mir funktioniert die Formatierung von Infoboxen leider nicht mehr (meine global.js, ich nutze die aktuelle stabile Version von Google Chrome). Dort steht beispielsweise

{ name: 'Infobox Fußballnationalmannschaft', format: '| ________________ = _\n' }

Leider werden die Parameter der Infobox nicht mehr korrekt eingerückt, siehe z. B. hier. Könntest du dir das bitte einmal ansehen? --Abu-Dun Diskussion 10:08, 11. Mai 2018 (CEST)

Du meinst vermutlich „Leerzeichen nach Pipe“? Habe ich dementsprechend verfeinert; zunächst mal ging es jedoch darum, dass nicht die gesamte Infobox in einer einzigen Quelltextzeile zurückgeschrieben wird. Inwieweit das TMg-Feature wirken kann, weiß ich grad nicht, aber die Definition gehört für alle Benutzer einheitlich in die Vorlagendoku und nicht bei jedem eine andere in seinem persönlichem JS. LG --PerfektesChaos 11:20, 11. Mai 2018 (CEST)

Genau das meine ich. In der Vorlagendoku steht es in der Regel richtig mit den Leerzeichen, nur bei der Anwendung in den jeweiligen Artikel leider teilweise nicht. Dafür hat bis vor kurzem TMgs Tool ganz gut geholfen. Mit einem Knopfdruck war alles korrekt formatiert (zumindest in den Infoboxen, die ich in meiner persönlichen global.js (siehe oben) definiert habe. Aber genau dieses funktioniert wie erwähnt nicht mehr (siehe Beispiel oben). --Abu-Dun Diskussion 14:09, 11. Mai 2018 (CEST)

Hm. Ich habe deine global.js auf verschiedene Arten getestet, und bei mir funktioniert sie einwandfrei. Was genau passiert denn statt dessen, bzw. was passiert nicht? Siehst du Fehlerausgaben in der JavaScript-Konsole? Mir fällt lediglich auf, dass du den Auto-Formatter zweimal eingebunden hast. Diese Seite kannst du löschen lassen. --TMg 18:08, 12. Mai 2018 (CEST)

Den zweiten Eintrag habe ich gelöscht, danke. Wenn ich hier auf Auto-Format im Quelltexteditor klicke passiert leider gar nichts. Das Icon verblasst (opacity: 0.4) und weiter passiert nichts . Eingerückt wird nichts (in dem Beispiel alles zwischen pattern_la1 und socks2). Getestet unter Google Chrome (Stable, Windows), Google Chrome (Beta, macOS), Safari (11.1, macOS), Firefox (60.0, macOS). Ich hab dir mal den Log hier hochgeladen. Und hier ohne die Verwendung von WikEd. Funktioniert leider auch nicht. --Abu-Dun Diskussion 22:30, 12. Mai 2018 (CEST)

Ich bin da leider wirklich ratlos. Kann es sein, dass du versehentlich etwas im Text markiert hast, wenn du auf den Auto-Format-Besen klickst? --TMg 15:38, 13. Mai 2018 (CEST)

Nein, markiert habe ich da nichts. Bei anderen Artikeln funktioniert das Tool, nur eben nicht bei der Einrückung in Infoboxen, so wie es mir im Moment vorkommt. --Abu-Dun Diskussion 19:15, 13. Mai 2018 (CEST)

Es funktioniert! Ich habe die Beta.js bei Wikimedia eingebunden und die Anweisungen für de.wiki ausschließlich in die common.js in der de.wiki hinterlegt und bei wikimedia entfernt. Jetzt klappt’s auch wieder mit der Einrückung. --Abu-Dun Diskussion 16:31, 15. Mai 2018 (CEST)

Nonfunctional in CodeMirror and Visual Editor wikitext mode

On about 14 June 2018, English Wikipedia enabled the CodeMirror Syntax highlighting feature by default (See also w:en:Wikipedia:Village pump (technical)#Syntax highlighting will no longer turn off / Forced into 2017 Editor). Auto-Formatter doesn't work for me when syntax highlighting is enabled. While this feature can still be manually deactivated with a simple button click, it would be nice to have both syntax highlighting and Auto-Formatter's features. I noticed this conflict before when CodeMirror was still opt-in, but figured it was probably a higher priority now that CodeMirror is opt-out.

As a related note, the button is not shown in the new wikitext mode of the Visual Editor. The editor itself seems unchanged in this mode, so I think it's probably just a matter of adding the button. Daask (Diskussion) 20:38, 14. Jun. 2018 (CEST)

Those who will edit this script could use my experience with ruwiki's Wikificator gadget. This edit fixed the behaviour with CodeMirror, while the code on the bottom enables the gadget in the new wikitext mode. Jack who built the house (Diskussion) 21:59, 16. Jun. 2018 (CEST)

TMg you solved this with an „Quick and dirty“ hack. This is indeed not optimal (davon abgesehen sollte ein ID-Selector effizienter sein $( '#mw-editbutton-codemirror a[aria-checked="true"]' ) 5 mal schneller, obwohl jQuery eh nicht viel mit Performance zu tun hat. Und das Element könntest du gleich in die var speichern anstatt zweimal ins DOM zu greifen). You simple need to change e.value = …; → $(e).val ( … ); Because jQuery seems to trigger an other event which CodeMirror recognize. -- User: Perhelion 18:11, 8. Aug. 2018 (CEST)

My .click() hack stopped working. I replaced it with the $( e ).val() suggestion. Thanks a lot! --TMg 15:41, 3. Sep. 2018 (CEST)

Localized date format

I was testing AutoFormatter in finnish wiki and here is few questions. Is there a way to not edit dates inside <ref> tags? In our wiki we keep those in short format in reference section. Then the finnish date format, month is in the partitive case, should be marked by -ta at the end so instead of current 23.7.2015 -> 23. heinäkuu 2015 it should be 25. heinäkuuta 2015 (same goes for every month). I have no clue where localized dates are coming so wondering is that something that can be fixed? --OneMember (Diskussion) 22:28, 20. Sep. 2018 (CEST)

I disabled the date expansion for Finnish wikis. Thanks for letting me know. --TMg 07:52, 26. Sep. 2018 (CEST)

json in WP-pages

Hallo TMg, ich vermute mal dein autoFormatter macht bei der Ersetzung typografischer Hochkommatas nicht Halt vor json-Daten. Siehe etwa St. Gotthard im Mühlkreis und das <graph>-tag. json sollte er aber in Ruhe lassen. lg --Herzi Pinki (Diskussion) 15:44, 15. Nov. 2018 (CET)

Das war schnell lösbar, vielen Dank für den freundlichen Hinweis! Der Auto-Formatter wusste nur noch nichts von diesem Tag. --TMg 18:48, 2. Dez. 2018 (CET)

autoFormatter beeinflußt das Ergebnis innerhalb span style

Siehe Diff. --Atamari (Diskussion) 11:20, 2. Mai 2019 (CEST)

Vielen Dank für die Meldung. Ich denke ich habe es hinbekommen, solche Fälle jetzt auszuschließen. Obwohl so komplexer CSS-Code eigentlich nicht in den Artikelnamensraum gehört, sondern in Vorlagen versteckt werden sollte. --TMg 19:15, 17. Mai 2019 (CEST)