Benutzer Diskussion:TMg/autoFormatter

Babel:
de Dieser Benutzer spricht Deutsch als Muttersprache.
en-3 This user is able to contribute with an advanced level of English.
Benutzer nach Sprache

Zum Archiv

Wie wird ein Archiv angelegt?

Ref-Tags

Hallo, was ist mit Leerzeichen vor <ref>? Gruß, Elvaube ^Disk 18:00, 1. Okt. 2010 (CEST)

Da bin ich mir unsicher, weil ich mir vorstellen könnte, dass das manchmal auch gewollt ist. Gibt es dazu eindeutige Diskussionen? --TMg 18:27, 1. Okt. 2010 (CEST)

Ich setze sie immer direkt hinter den Punkt oder hinter einen Buchstaben. Auch setze ich das Tag immer hinter einen Punkt am Satzende und nicht davor. Gruß, Elvaube ^Disk 20:02, 1. Okt. 2010 (CEST)

Liegt vermutlich daran, was man erreichen möchte. Wenn man das Wort vor dem Satzzeichen belegen möchte, gehört das ref vor den Punkt, für den ganzen Satz nach dem Punkt. Wobei man im ersten Teil auch den Satzbau ändern. Das lässt sich aber durch ein Skript nicht erkennen. Das Leerzeichen kann ich nicht beurteilen. Der Umherirrende 21:15, 1. Okt. 2010 (CEST)

Hilfe:Einzelnachweise deutet an, dass vor <ref> wohl nie ein Leerzeichen stehen sollte. Aber ist das wirklich ausnahmslos so? --TMg 02:05, 5. Okt. 2010 (CEST)

Also ich sehen öfter die Konstellation: Text <ref>…</ref> ., in meinen Augen total falsch. Gruß, Elvaube ^?! ± 18:56, 19. Okt. 2010 (CEST)

Revision: Leerzeichen vor <ref …> entferne ich inzwischen, vorerst aber nur am Satzende. Da erscheint mir das eindeutig, da das Satzzeichen tief und die Fußnote hoch steht (Satz. ^[1] → Satz.^[1]). In anderen Fällen scheue ich mich noch vor einer Automatisierung (WWW ^[1] → WWW^[1]). --TMg 21:41, 10. Dez. 2012 (CET)

Erweiterungsvorschläge

• Genitiv und Auslassung: „Schreibmaschinenapostroph“ (') → typografisch korrekter Apostroph (’)
• Gedankenstrich: Leerzeichen, Bindestrich-Minus, Leerzeichen (… - …) → Leerzeichen, Halbgeviertstrich, Leerzeichen (… – …)
• Zahlenbereich: Bindestrich-Minus (123-456) bzw. Leerzeichen, Bindestrich-Minus, Leerzeichen (123 - 456) → Halbgeviertstrich (123–456)
• d.h. bzw. d. h. → d. h.
• u.a. bzw. u. a. → u. a.
• z.B. bzw. z. B. → z. B.

--Seth Cohen (Diskussion) 16:43, 2. Sep. 2012 (CEST)

1. Dazu bräuchte ich konkretere Beispiele. Einfach nur das Zeichen überall zu ersetzen, wäre sicher nicht korrekt.
2. Das passiert doch schon. Funktioniert es nicht wie du es dir wünschen würdest? Dann bräuchte ich bitte konkrete Beispiele dafür.
3. Das mache ich nur bei Jahreszahlenbereichen, weil in anderen Fällen nicht eindeutig ist, was da gemeint ist. Auch hier gilt wieder: Bitte konkrete Beispiele, wo das erwünscht sein kann.
4. Abkürzungen ersetze ich nicht mehr pauschal. Wer das möchte, kann die oben beschriebenen Benutzerdefinierten Ersetzungen aktivieren.

--TMg 19:03, 2. Sep. 2012 (CEST)

1. Beispiel

• für den Genitiv:
  • Frederick’s of Hollywood
• für eine Auslassung:
  • Britain’s Got Talent

2. Ich werde mal verstärkt darauf achten und gegebenenfalls wieder hier berichten.
3. Beispiel:

• Seitenzahlbereiche

4. Könntest du dir mal kurz meine common.js inklusive Versionsgeschichte ansehen und mir sagen, wie ich beide Varianten (mit und ohne Leerzeichen) abdecken kann? So funktioniert es nämlich nicht, da verschwindet das „Auto-Format“-Symbol aus der Symbolleiste.

--Seth Cohen (Diskussion) 20:08, 3. Sep. 2012 (CEST)

1. Vielen Dank für die Beispiele. Leider ist das sehr schwierig, da es beispielsweise Eigenschreibweisen gibt, in denen das nicht ersetzt werden dürfte. Dieser Auswertung zufolge kommt das Hochkomma über 11.000 mal allein in Lemmata vor. Die können ja unmöglich alle falsch sein. Ich möchte ungern Ersetzungsregeln einführen, bei denen das Risiko so hoch ist, dass richtige durch falsche Zeichen ersetzt werden.
2. Würde mich sehr freuen, danke.
3. Das ist als Beispiel leider noch zu allgemein, da dann auch sehr viele Fälle verändert würden, in denen der normale Bindestrich Absicht ist (etwa in ISBNs). Ich bräuchte ganz konkrete Beispiele wie etwa „Seite 1-2“, am liebsten mit einer konkreten Artikelversion dazu.
4. In der Version, die nicht funktioniert, fehlt ein Komma, aber das nur zur Information. Die Doppelungen sind unnötig. Nimm einfach die Teile [ ] aus der aktuellen Version raus, dann gehts. Und die Doppelung common.js/vector.js ist unnötig. Schieb am besten alles in die common.js und lass die vector.js löschen.

--TMg 20:56, 3. Sep. 2012 (CEST)

1. Vielen Dank für deine schnelle Antwort. Dass eine Ersetzung in den Fällen schwierig sein dürfte, habe ich befürchtet. Von den 11.511 Vorkommen des Zeichens ' in Artikeltiteln entfällt bestimmt ein ganzer Haufen auf Weiterleitungen.
3. Es gibt mehrere Varianten, darunter die von dir genannte. „S. 1-2“ ist auch häufig zu finden.
4. Danke für den Hinweis! Ohne [ ] funktioniert die Ersetzung aber nur bei den Varianten der Abkürzungen ohne Leerzeichen. In meiner common.js und meiner vector.js befinden sich doch unterschiedliche Inhalte.

--Seth Cohen (Diskussion) 21:32, 3. Sep. 2012 (CEST)

2. Wie ich gerade festgestellt habe, funktioniert die Ersetzung nicht, wenn mindestens eines der beiden Wörter vor und nach dem Bindestrich-Minus gesondert formatiert, also als fett oder kursiv ausgezeichnet ist.

--Seth Cohen (Diskussion) 22:58, 3. Sep. 2012 (CEST)

Also bei mir funktioniert es sowohl mit als auch ohne Leerzeichen, wenn ich einfach nur das Folgende verwende.

var autoFormatReplacements = {
  'daß': 'dass',
  'd.h.': 'd. h.',
  'e.V.': 'e. V.',
  'u.a.': 'u. a.',
  'z.B.': 'z. B.'
};

Was ist bei dir anders? Mein zweiter Vorschlag war, den Inhalt aus deiner vector.js in deine common.js zu kopieren und erstere dann löschen zu lassen. Das spart einen Seitenabruf und macht das Laden minimal schneller. Das mit dem Gedankenstrich ist korrekt. Aktuell wird das nur zwischen Buchstaben gemacht, um Fehlersetzungen zu vermeiden, die es beispielsweise zwischen Zahlen gab. Über eine Aufnahme der Hochkommas (fett/kursiv) werde ich nachdenken. --TMg 23:38, 3. Sep. 2012 (CEST)

Das funktioniert tatsächlich, da war ich etwas voreilig und bitte um Nachsicht.

Danke für den Tipp, ich verwende jetzt nur noch die common.js.

Sinnvoll wäre auch, die Ersetzung des Bindestrich-Minus durch einen Halbgeviertstrich zu aktivieren, wenn Klammern (Zeile 18) oder Anführungszeichen im Spiel sind.

Weitere Vorschläge:

• doppelte Leerzeichen
• ... → …
• innerhalb der Vorlage {{Zitat}} verwendete doppelte Anführungszeichen („ “) durch einfache (‚ ‘) ersetzen

Auffälligkeiten:

• Hier stimmt etwas mit der Datumsersetzung nicht (Zeilen 82 und 197).
• [[Madison Square|Madison Square Park]] wird zu [[Madison Square]] Park

(nicht signierter Beitrag von Seth Cohen (Diskussion | Beiträge) 23:32, 4. Sep. 2012 (CEST))

Zuerst einmal vielen Dank für deine Beiträge. Das hilft mir wirklich sehr, auch wenn es sicher frustrierend ist, dass ich vieles abwiegle. ;-)

• Das mit Zitaten und Klammern schau ich mir an.
• Doppelte Leerzeichen entferne ich absichtlich nicht. Das macht nur den Versionsvergleich unübersichtlich, zerstört per Leerzeichen eingerückte vorformatierte Abschnitte, bringt aber keinen Vorteil. Zeilenenden säubere ich, weil diese „unsichtbar“ sind, doppelte Leerzeichen im Text sieht man aber und kann sie entfernen, sollten sie wirklich stören.
• Das … steht schon lange auf meiner Kandidatenliste, ich habe es aber noch nie gewagt, weil es durchaus Beispiele gibt, in denen ... Absicht ist.
• Im kaputten Datum standen Bis-Striche eingetragen, deswegen erkenne ich das als Jahreszahlenbereich.
• Der Artikel heißt so. Warum sollte man das verschleiern und so tun, als würde er anders heißen?

--TMg 23:52, 4. Sep. 2012 (CEST)

• Danke dir für das Skript. :-)
• Spontan fällt mir kein Beispiel ein, wo ... erwünscht ist, könntest du mir eines nennen?
• Oh, ja, stimmt, da gehören ja gar keine Bis-Striche (Halbgeviertstriche) hin.
• Um die im Zusammenhang gemeinte Einheit Madison Square Park nicht auseinanderzureißen.

--Seth Cohen (Diskussion) 00:06, 5. Sep. 2012 (CEST)

• In der Programmierung gibt es das ... oft. Auch, wenn man den Wortlaut von Bildschirmausgaben zeigen möchte. Und noch etwas Naheliegendes: Zitate.
• Dann schreib [[Madison Square Park]] oder [[Madison Square#Lage|Madison Square Park]], wenn nur der Park gemeint ist und nicht der ganze Madison Square. Der Link ist sonst irreführend, wenn er woanders hin führt als seine Beschriftung behauptet. --TMg 00:45, 5. Sep. 2012 (CEST)

• In dem Fall kommt ... aber doch wahrscheinlich innerhalb des <code>-Elements vor, wo die Ersetzung leicht auszuschließen sein dürfte. Innerhalb von Zitaten soll ja gerade … statt ... Verwendung finden.
• Ich hatte nicht geprüft, ob die Weiterleitung existiert. Dass der Link [[Madison Square|Madison Square Park]] in gewisser Weise irreführend ist, da ist natürlich was dran.

--Seth Cohen (Diskussion) 16:23, 5. Sep. 2012 (CEST)

• Und, was meinst du zu den Auslassungspunkten?
• Mir ist gerade aufgefallen, dass in Wikilinks Unterstriche nicht durch Leerzeichen ersetzt werden. Könntest du das noch ergänzen?

--Seth Cohen (Diskussion) 18:21, 6. Sep. 2012 (CEST)

• Wie gesagt, da hab ich Angst. ;-) Der Vorteil, wenn ... durch … ersetzt wird, ist meiner Meinung zu gering für die möglichen Fehlersetzungen. Man sieht (je nach Betriebssystem und Webbrowser) gar keinen oder nur einen mikroskopischen Unterschied. Umbrüche setzen die Browser bei drei Punkten auch korrekt. Und es begegnet mir in unserem Artikelbestand nur ganz selten. Vielleicht nur eine Spezialregel für [...] und (...)?
• Unterstriche entferne ich teilweise, erwische aber nicht alle, da hast du Recht. Ich setze es auf meine Liste.

--TMg 19:20, 6. Sep. 2012 (CEST)

• Dazu ja meine Einlassung bezüglich des <code>-Elements. [...] und (...) zu ersetzen, wäre zumindest ein Anfang. Wobei ich mich frage, ob (...) nicht auch durch […] ersetzt werden sollte. Oder in welchen Fällen sind runde Klammern bei Auslassungen üblich?
• Wo werden Unterstriche denn bereits ersetzt? Danke!

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

• Beides ist üblich und ich würde das niemandem verbieten wollen, auch wenn für uns primär das wissenschaftliche, also eckige gilt. Anekdote: Mir wurde schon mal ein [...] gelöscht, weil jemand dachte, das solle ein Link sein. ;-)
• In Links mit #Ankern sowie in Dateinamen.

--TMg 21:52, 6. Sep. 2012 (CEST)

• Noch mal, in der Programmierung sollte ... doch ausschließlich innerhalb des <code>-Elements vorkommen, oder nicht? Was meintest du mit „Wortlaut von Bildschirmausgaben“? Und in Zitaten sind doch ohnehin die typografischen Auslassungspunkte zu verwenden!?
• Vielen Dank für den Link zu dem guten Artikel. Bezüglich der Anekdote, [...] als Link ist aber nicht gerade zielführend. ;-)
• Ah, ok.

--Seth Cohen (Diskussion) 22:09, 6. Sep. 2012 (CEST)

... gibts wirklich. ;-) Es ist kaum möglich, die Wikipedia nach Beispielen abzusuchen, aber so was hier meine ich:

Bitte warten...
0 Ergebnisse gefunden

Das würde sich beim Ersetzen sichtbar verändern. Im Gegensatz dazu würden sich die erwünschten Fälle gerade nicht sichtbar verändern, es hätte also keinen Vorteil sondern nur mögliche Nachteile. Wie gesagt, den Fall [...] werde ich wohl einbauen. Wenn du mehr solche ganz konkreten Beispiele hast, nur her damit. Noch etwas: Bitte nicht in fremden Beiträgen editieren, auch wenns gut gemeint ist. --TMg 23:30, 6. Sep. 2012 (CEST)

• Ja, [[...]] gibt es als Weiterleitung, [...] aber nicht.
• Für mich ist eine Ersetzung von ... durch … grundsätzlich sichtbar. Fehlersetzungen dürften äußerst selten vorkommen, insofern überwiegt der Nutzen meines Erachtens deutlich.
• Ich habe ja nur an der Syntax gefeilt und keineswegs den Sinn entstellt.

--Seth Cohen (Diskussion) 19:28, 9. Sep. 2012 (CEST)

Meinst du die Ersetzung von ... durch … in Abschnitten mit dicktengleicher Schrift? Genau in diesen Fällen darf es meiner Meinung nach keinesfalls ersetzt werden. Zwischen den normalen ... und … sehe ich keinen Unterschied. Mach mal ein Bildschirmfoto, wenn das bei dir signifikant anders aussieht. --TMg 21:53, 9. Sep. 2012 (CEST)

• Nein, eigentlich meinte ich grundsätzlich, aber da habe ich wohl das Edit-Fenster, in dem ja dicktengleiche Schrift zum Einsatz kommt, mit der Artikelansicht vermischt.
• Was hältst du davon, bei Listen ein Leerzeichen zwischen dem Aufzählungszeichen und dem darauffolgenden Text einzufügen, sofern dort keines steht? Ist das sinnvoll?

--Seth Cohen (Diskussion) 22:20, 9. Sep. 2012 (CEST)

Auch etwas, an das ich mich nie gewagt habe, weil ich zu viele Falscherkennungen befürchte. Obwohl. Ich habe seit kurzem endlich einen Schutz für Quelltextabschnitte drin. Damit hat sich die Fehlerwahrscheinlichkeit drastisch reduziert. Ich nehm es mal in meine Liste auf. --TMg 23:38, 10. Sep. 2012 (CEST)

Danke. --Seth Cohen (Diskussion) 16:05, 11. Sep. 2012 (CEST)

Könntest du ebenfalls die Einfügung eines Leerzeichens hinter </ref> ergänzen, sofern es nicht am Ende eines Absatzes steht, sondern Text folgt, und kein Leerzeichen vorhanden ist? --Seth Cohen (Diskussion) 17:16, 12. Sep. 2012 (CEST)

Die Einfügung einer Leerzeile nach einer Überschrift, sofern nicht vorhanden, wäre auch toll. --Seth Cohen (Diskussion) 23:04, 12. Sep. 2012 (CEST)

Leerzeile nach Überschriften: Auf keinen Fall, tut mir leid. Ich hatte das sogar mal drin und habe es entfernt, weil es genervt hat. Es gibt keinen Konsens in dieser Frage. Der eine mag es so, der andere so, teils sogar durcheinander in einem Artikel (ich setze unter „Weblinks“, „Einzelnachweise“ u. ä. bswp. nie Leerzeilen, unter die Überschriften oben im Text dagegen schon). Das mit dem Leerzeichen nach ref klingt etwas gefährlich. Zwei ref hintereinander dürfen z. B. keins haben. Genauso gibt es ref in Zitat-Vorlagen u. ä., wo Leerzeichen gar nicht nötig sind. --TMg 00:32, 13. Sep. 2012 (CEST)

• Es wäre nur konsequent, nach jeder Überschrift eine Leerzeile zu haben, denn durch „Abschnitt hinzufügen“, wo für die Überschrift ein eigenes Edit-Feld reserviert ist, wird ja auch eine Leerzeile erzeugt. Vielleicht bist du so nett, und verrätst mir, wie ich das selbst für mich realisieren kann.
• Dann bau doch bezüglich des Leerzeichens hinter </ref> entsprechende Ausnahmen ein.

--Seth Cohen (Diskussion) 16:33, 13. Sep. 2012 (CEST)

Ich rate dringend davon ab, anderen Artikelautoren Leerzeilen aufzuzwingen, wo sie bewusst keine gesetzt hatten. Wenn du beim Überarbeiten eines Abschnitts einen Zeilenumbruch einfügst, ist das natürlich in Ordnung. Aber bitte nicht automatisiert. --TMg 18:56, 15. Sep. 2012 (CEST)

Revision:

• Ersetzungen mit dem Apostroph sind mir zu gefährlich, u. a. weil das Zeichen Teil der Wikisyntax ist.
• Ich werde Bis-Striche nicht ohne Beachtung des Kontext (aktuell Seiten und Jahre) zwischen Zahlen setzen.
• Die Ellipsen-Regel greift jetzt in wesentlich mehr Fällen, vor allem innerhalb von Zitaten, nicht jedoch am Wortende, wo sie meist falsch ist.
• Gedankenstriche neben Anführungszeichen funktionieren noch nicht.
• Leerzeichen ergänzen, wenn ein <ref /> zwischen Text gequetscht ist.

--TMg 17:49, 31. Jan. 2013 (CET)

Fork

Hallo TMg,

Ich möchte dir ein fettes Lob für dein schönes Skript aussprechen :-). Seit gestern nutze ich es, aber in abgewandelter Form da ich bei einigen Dingen einen anderen Standpunkt als du habe (z. B. Lokalisierung von Schlüsselwörtern, automatische Formatierung von Einzelnachweisen usw.). Ich hoffe es ist ok für dich, dass ich dein Skript „dreist kopiert“ habe (siehe Benutzer:Svebert/autoFormatter.js).

Noch eine technische Frage: Ist es möglich mittels JS ein zusätzliches Textfeld unter der Zusammenfassungszeile zu platzieren? Bin leider kein JS Experte, aber du hast es ja auch geschafft einen neuen Button zu integrieren. Ich würde nämlich gerne so ein Textfeld in das Skript integrieren wollen, so dass das Skript Warungs- und Info-Ausgaben in dieses Feld schreiben kann. Z. B. könnte ich mir eine Funktion vorstellen die alle internen Links aus einem Artikel gräbt und überprüft ob welche doppelt vorkommen und dem Benutzer dann in dieses Textfeld schreibt, dass er mal die Dopplung von Link x und Link y überprüfen solle.

Auch andere „Integritätstests“ wären dann denkbar. Z. B. sogar die Überprüfung der Erreichbarkeit von externen Links, Vorschlag von bestimmten Vorlagen für Einzelnachweise (Cite-Book /Cite Journal usw.)--svebert (Diskussion) 17:34, 8. Sep. 2012 (CEST)

Hallo svebert! In Hinblick auf Hilfe Diskussion:Einzelnachweise ist die Formatierung von Einzelnachweisen vermintes Gelände. Ich kann dir davon nur abraten, auch wenn ich diese ganzen Kodierungsvorstellungen über die Platzierung von Einzelnachweisen nicht teile. Du handelst dir damit nur Ärger ein. Wenn du einen besonderen Standpunkt zur Lokalisierung hast, so finde ich es inkonsequent, dass das Skript eben doch an der Lokalisierung dreht. Beispiel: Vorher 2 mal „File“ und „thumb“, 9 mal „Datei“ und „miniatur“ – nach deinem Skript: 11 mal „File“ und „thumb“. Szenario: Ein Nutzer schreibt einen Artikel mit deutscher Lokalisierung (weil er sich der Vorstellung hingibt, dass eine einheitliche und deutsche Bezeichnung im Interesse von neuen Autoren ist). Dann kommt der englischsprachige Benutzer:Materialscientist und ergänzt eine Datei von Commons. Das macht er häufig und es ist ok. Er nutzt englische Syntax. Dann kommst du und reparierst irgendwas. Danach ist der Artikel englisch „lokalisiert“. Das ist doch sinnlos. Viele Grüße, --Polarlys (Diskussion) 18:16, 8. Sep. 2012 (CEST)

@Svebert: Mein Skript steht wie alles hier unter CC und darf in diesem Rahmen selbstverständlich abgewandelt werden. Du hättest mich nicht einmal darauf hinweisen müssen, insofern freue ich mich sehr über deine Meldung. Danke. Zu einigen der angesprochenen Punkte:

• Wenn du bei deinen Bearbeitungen keine Schlüsselwörter eindeutschen willst, kann ich diesen Teil sehr gern abschaltbar machen.
• Es wäre definitiv nicht in Ordnung, wenn ein Skript „miniatur“ zurück in „thumb“ ändern würde, da die Skripte dann gewissermaßen gegeneinander „kämpfen“ würden. Deine Vorgehensweise ist sehr interessant, da sie dieses Problem vermeidet. Ich vertrete dennoch den Standpunkt, dass man in der deutschsprachigen Wikipedia niemals „Datei“ in „File“ ändern darf.
• Deine Änderungen in Einzelnachweisen kommen mir aus meiner Erfahrung heraus alle recht fragwürdig vor. Es kann durchaus beabsichtigt sein, wenn ein ref vor dem Punkt steht. Genauso wie nicht anklickbare Weblinks und „fehlende“ Punkte. Du solltest dir bewusst sein, dass diese Ersetzungsregeln viele false positives erzeugen werden und auch jeden, der dein Skript mitnutzen möchte, darauf aufmerksam machen.
• Deine automatisch gesetzte Zusammenfassungszeile finde ich nicht in Ordnung. Mein Skript ist kein Bot-Ersatz. Ich will nicht, dass damit Bearbeitungen getätigt werden, die aus nichts weiter als dem Drücken des Knopfes bestehen. Wenn das der Sinn gewesen wäre, hätte ich einen Bot daraus gemacht und keinen Knopf in der Werkzeugleiste. In die Zusammenfassungszeile gehört, was genau du an einem Artikel verändert hast und nicht, wie das Werkzeug hieß, dass du dazu zur Hilfe genommen hast.
• Die Idee mit der Ausgabe von Hinweisen hatte ich auch, habe mich bisher aber immer dagegen entschieden. Ich möchte absichtlich nur Änderungen vornehmen, für die es einen Konsens gibt. Alles, was Meldungen und zusätzliche Entscheidungen des Benutzers erfordert, birgt die Gefahr, mehr Fehlmeldungen, Aufwand und Streitereien zu provozieren als möglichen Nutzen. Außerdem gibt es schon genug andere Projekte, die so etwas machen, siehe WikiProjekt Syntaxkorrektur. Ich möchte absichtlich etwas anbieten, das zwischen diesen Projekten und reinen Bot-Korrekturen liegt.
• Ich habe gesehen, dass du offenbar das Skript mit dem Skript formatiert und dabei einiges kaputt gemacht hast.

--TMg 20:16, 8. Sep. 2012 (CEST)

Hi!

Ich kann eure Kritiken alle nachvollziehen. Aber überzeugen tun sie mich nicht.

1. Diese Skripte hier sind keine Bot-Ersätze oder gar automatische Skripte. Jede einzelne Änderung die das Skript macht muss man sich definitiv händisch anschauen und auf Sinnhaftigkeit überprüfen. Die Skripte machen einem nur das Leben leichter, so dass man nicht mit tausenden Klicks in einem Artikel <ref>...</ref>. nach .</ref> vertauschen muss.
2. Einzelnachweise. Mag sein, dass das vermintes Gelände ist, aber ich bekomme definitiv Augenkrebs wenn ich <ref>...</ref>, anstatt ,<ref>...</ref> sehe und ändere dies normalerweise auch händisch wenn mir sowas über den Weg läuft. Auch weiß ich, dass manchmal diese Umstellungen keinen Sinn machen, aber genau deshalb ist das Skript ja auch nur halb-automatisch.
3. Internationalisierung/Lokalisierung. Strittig ich weiß. Ich werde versuchen es so umzuprogrammieren, dass auf die „demokratisch“ konsistente Schreibweise umgebogen wird, also wenn 10x Datei und 4x File dann nach Datei.
4. Ich weiß um false positives, aber wie gesagt, dass Skript ist nur halbautomatisch. Und die false positives sind doch so selten, dass sich die jetzige Implementierung m.E. arbeitszeittechnisch lohnt.
5. Generell stehe ich wohl nicht auf dem Standpunkt, dass das Skript nur Änderungen durchführen soll die zu 99,999% richtig sind, mir reichen 95%.
6. Zusammenfassungszeile soll immer befüllt werden und diese Funktion habe ich nun so programmiert, dass hinten „auto-fmt“ angehängt wird falls man das Skript nutzt. Idealerweise soll's so laufen: Man bearbeitet einen Artikel inhaltlich. Füllt die Zusammenfassungszeile aus und drückt dann zum Abschluss den „Besen“. Dann auf „Änderung zeigen“ und prüft das Diff. Dann „Seite speichern“. Bei diesem Arbeitsablauf finde ich das automatische hinzufügen der Zusammenfassungszeile sinnvoll. (ja, heute habe ich für Probeläufe nicht vorher inhaltlich bearbeitet (shame on me), sondern bin bei „Letzte Änderungen“ auf ungesichtete Artikel gegangen und habe diese gesichtet und dann das Skript laufen lassen. Das wird aber definitiv nicht der Normalfall in Zukunft (bei mir) sein.)
7. Zum letzten Punkt ;-) genau das ist mir passiert :D. Aber eigentlich hatte ich das wieder gefixt.--svebert (Diskussion) 21:58, 8. Sep. 2012 (CEST)

1. Genau das ist aber unsere Kritik, dass man das weder „vertauschen muss“ noch soll.
4. Dein Skript löscht bei )<ref/>. den Punkt. Es verschiebt bei <ref/> A: das „A“ vor das ref. Es fügt Punkte in refs ein, wo keine hingehören. Dass du Links rein auf die Domain kürzt, finde ich auch nicht gut. Und warum du Punkte in die Links setzt, verstehe ich gar nicht.
5. Mein Ziel sind auch keine 99,999 %. Dann dürfte ich das Skript gar nicht betreiben. Deine Ausführungen zeigen mir im Gegenteil, dass wir beide genau das selbe wollen. Meinst du nicht, dass wir da lieber zusammen arbeiten und versuchen sollten, einen Konsens zu finden, der allen zugute kommt?
6. Ich finde den Hinweis trotzdem unpassend. Das könnte den Eindruck erwecken, als würdest du das vorsorglich als Erklärung setzen, falls dir Fehler durchrutschen. Damit du dann sagen kannst, das war nicht ich, das war das Skript.
7. Ich hatte noch ein paar */ gesehen, bei denen der Stern verloren gegangen ist. --TMg 00:17, 9. Sep. 2012 (CEST)

1. Die allermeisten <ref>...</ref>. Referenzen müssen nach .<ref>...</ref> geändert werden, da die Referenz sich nicht auf das eine Wort, sondern meistens auf den Satz beziehen (Inhaltliche Begründung). Selbst wenn das nicht der Fall ist (hier kann man jetzt diskutieren) finde ich es ästhetisch immer sinnvoller die Fußnote nach dem Satzzeichen zu setzen. Da es dazu m.W. keinen Konsens gibt, ändere ich dies (natürlich nicht systematisch, sondern nur wo es mir über den Weg läuft und auch nicht als einzige Änderung eines „Edits“) so wie ich es mag.
2. Da ich die regexp erst heute implementiert habe sind sie natürlich fehleranfälliger als sie in naher Zukunft sein werden. Wobei ich de regexp gerade nochmal überarbeitet habe. Problematisch ist sowas: <ref>test</ref>\n:eingerückte Zeile, da hier der Doppelpunkt ein aktives Zeichen ist, dass aber von der regexp nicht erkannt wird. Da muss ich nochmal was mit negative lookaheads oder so machen.
3. Aller aller größtenteils gehört an das Ende einer ref immer ein Punkt. Siehe hier [1]. Selbst wenn da nur steht S. 52, dann muss da ans Ende ein Punkt.
   1. Ich kürze ja nicht wirklich die Links, sondern nur ihre Anzeige. m.E. ist diese verkürzte Anzeige in den allermeisten Fällen sinnvoll, denn /index.php?id=43 und ähnliches ist ohne Informationsgehalt. Es reicht www.tagesschau.de anstatt www.tagesschau.de/index.php?id?=43 (als Anzeige, wohlgemerkt).
   2. Ich verschiebe bei externen Links als letzes Element in der ref die Punkte in die Links, da sonst das „externe-Link-Zeichen“ den Punkt unnötig nach rechts verschiebt. Bsp.: doof www.google.de. schön www.google.de.
4. ich meine schon das wir zusammenarbeiten können. Vllt. kann man das Skript ja modularisieren und dann benutzerspezifische Erweiterungen einfügen (so ähnlich wie du es für die Rechtschreibfehlerbeseitigung gemacht hast.
5. ja, so ist's aber nicht gemeint gewesen. Ich werde das nochmal überdenken.
6. ok, muss ich nochmal gucken ob ich noch welche übersehen habe.

• Die Punkte-vor-ref-Tag-Sache ist im Übrigen der Hauptgrund, warum ich das Skript überhaupt verwenden möchte (neben den Anführungszeichen).
• die Schlüsselwörter-Sache habe ich jetzt so umgesetzt, dass dasjenige Schlüsselwort verwendet wird, das am häufigsten im Artikel vorkommt. DEFAULTSORT wird immer nach SORTIERUNG umgeändert, irgendwie konnte ich die betreffenden Zeilen nicht so umprogrammieren, dass dasjenige Schlüsselwort bleibt, welches schon drinsteht.--svebert (Diskussion) 02:07, 9. Sep. 2012 (CEST)

• Ich weiß, dass nur die Anzeige gekürzt wird. Genau das kritisiere ich als irreführend, weil nicht mehr erkennbar ist, wohin der Link führt. Man meint, einen Link zur Hauptseite anzuklicken und landet plötzlich auf einer Unterseite. Oder schlimmer noch: Jemand könnte sich wundern, was ein Link zur Hauptseite in einem Einzelnachweis zu suchen hat und ihn löschen. Deshalb meine ich, dass solche Links entweder mit einem ordentlichen Text zu beschriftet sind (egal ob mit oder ohne Vorlage) oder komplett lesbar stehen bleiben müssen.
• Tut mir leid, aber www.wikipedia.de. ist Unfug. Die Domain endet nicht mit einem Punkt.
• „\s*“ ist gefährlich, das solltest du an vielen Stellen in „ *“ ändern. Dann erledigt sich auch das Doppelpunktproblem.
• Wenn du möchtest, dass DEFAULTSORT in deinen Bearbeitungen stehen bleibt, kannst du die Zeile einfach auskommentieren. Das kann ich dir wie gesagt gern als Option anbieten.
• Ich muss dir sogar zustimmen, denn wenn mir bspw. ein „<ref/>,“ auffällt, verschiebe ich das meist ebenfalls hinter das Satzzeichen. Ich scheue mich aber davor, das als Standardregel für alle Benutzer meines Skripts anzubieten. Vorschlag: Ich baue das als Option ein, die man gezielt aktivieren muss, wenn man das möchte, ähnlich wie bei den Abkürzungen.
• Nochmal ganz allgemein, nicht dass du das falsch verstehst. So lange du die Verantwortung für deine Bearbeitungen übernimmst, was du ja tust, und so lange sich niemand darauf beruft, nur „den Willen deines Skriptes“ umzusetzen, hast du selbstverständlich alle Freiheiten. Mir ist das aber leider schon passiert, dass ich für die Fehler anderer Benutzer verantwortlich gemacht wurde. Ich muss mir deshalb sehr genau überlegen, was ich hier neu einbaue. Und ich will ja auch, dass es breit verwendet wird, deshalb mache ich mir diese Gedanken gern. --TMg 14:46, 9. Sep. 2012 (CEST)

hi TMg!

Das mit dem Punkt in den Link verschieben habe ich abgeändert, da es wirklich unsinnig war. Auch habe ich die regexps bzgl. der ref-Tags verändert und nun arbeiten sie recht verlässlich. Bei DEFAULTSORT reicht es aber doch nicht die betreffende Zeile auszukommentieren, oder? Denn dann funzen die Ersetzungen Ä -> A usw. nicht mehr. (Die Lokalisierung DEFAULTSORT nach SORTIERUNG ist im übrigen die Einzige die ich sinnvoll finde, da ich DEFAULTSORT unsinnig finde.)

Momentan bin ich mit dem Skript das ich verwende relativ zufrieden. Ich kann natürlich verstehen dass es Unsinn ist zwei sehr ähnliche Skripte nebeneinander zu haben. Wie oben geschrieben sind die Funktionen Satzzeichen-vor-<ref>-Verschiebung, Punkt-an-Ende-von-Referenz und die Nicht-Lokalisierung-von-Schlüsselwörtern-aber-Angleichung-innerhalb-eines-Artikels essentiell für mich. Wenn du diese Sachen optional in dein Skript einbauen würdest (ich habe gestern dein beta-Skript gesehen, wo du angefangen hast zu modularisieren), dann würde ich dein Skript verwenden.--svebert (Diskussion) 15:19, 9. Sep. 2012 (CEST)

Revision:

1. Die Idee, die Lokalisierung von Schlüsselwörtern davon abhängig zu machen, was im Artikel häufiger vorkommt, ist interessant, überzeugt mich aber nicht. Was, wenn ein Artikel so chaotisch zusammenkopiert ist, dass [[Image:…|miniatur|upright|links|…]] als Gewinner übrig bleiben? Was soll die Mischung? Warum sollte ein schon vorhandenes Datei durch Image ersetzt werden? Ich sage: Entweder einheitlich oder gar nicht.
2. Doppelte Satzzeichen um <ref> entferne ich, aber nur, wenn es zweimal das gleiche ist. Leerraum könnte ich da gleich mit entfernen.
3. Punkte am Ende von <ref> könnte ich unter bestimmten Umständen (ISBN/Jahres/Seitenzahl, siehe unten) einsetzen.
4. Semikolon in Lebensdaten (Referenz).

--TMg 18:10, 22. Nov. 2012 (CET)

Ideen aus der WikiSyntaxTextMod-Konfiguration von RonMeier

1. Er verschiebt <ref> ebenfalls grundsätzlich hinter die Satzzeichen. Ich könnte das wenigstens per Opt-in anbieten.
2. [[commons:File: durch [[:Datei: ersetzen? Eher nicht, denn es erzeugt einen anderen Link.
3. <br /> entfernen, wenn danach sowieso ein Umbruch folgt ((?=\n[\n#*:;])). erledigtErledigt
4. Leerraum zwischen zwei <ref> entfernen. erledigtErledigt
5. Leerraum zwischen Satzende und <ref> entfernen. erledigtErledigt, allerdings wirklich nur am Satzende.
6. Seitenangaben immer einheitlich als S.
7. Bis-Striche bei Seitenangaben.
8. ISBN und Seitenangabe immer in die selbe Reihenfolge bringen.
9. Zwischen ISBN und Seitenangabe immer ein Komma.
10. Vor ISBN ein Komma bevorzugen.
11. Punkt am Ende von <ref>, wenn es mit einer ISBN oder Jahres/Seitenzahl endet.
12. Doppelpunkt am Ende von Überschriften entfernen? erledigtErledigt

--TMg 17:44, 22. Nov. 2012 (CET)

Ersetzung der Anführungszeichen in Belegen

Ist es beabsichtigt, dass die Anführungszeichen von Internetquelle, citeweb & Co. ersetzt werden? hatte bisher immer angenommen, dass da die Titel eins zu eins übernommen werden, aber bei Vorlage:Internetquelle#Archivierte Internetquellen wird als Beispiel Erklärung zur Initiative „Netz gegen Kinderporno“. angegeben obwohl auf der Website Erklärung zur Initiative "Netz gegen Kinderporno" steht. Ist das auf der Dokuseite einfach ein Fehler, oder sollen Anführungszeichen immer ersetzt werden? --CENNOXX 18:01, 1. Dez. 2012 (CET)

Puh, schwierig. Nein, das ist kein Fehler. Hier kommen mehrere Dinge zusammen. Zuerst einmal ist es eine technische Einschränkung meines Skriptes. Es kann nicht wissen, woher das Ersatzzeichen »"« kommt und wie es zu werten ist. Wenn es zwei findet, die wie Anführungszeichen verwendet werden, dann macht das Skript typografisch korrekte Anführungszeichen daraus.

Nun könnte man argumentieren, dass Zitate, Buchtitel und ähnliches unverändert übernommen werden sollten, inklusive eventueller Typografiefehler. Aber warum? Inwiefern verändert sich ein Zitat, wenn wir die korrekten Unicodezeichen einsetzen? Gerade bei Übernahmen von Webseiten unterstelle ich, dass es niemals Absicht war, das Ersatzzeichen »"« zu verwenden. Webseiten werden nicht mit der Schreibmaschine geschrieben, wo es die Zeichen möglicherweise nicht gibt. Auf Webseiten geschieht das aus Unwissenheit oder Faulheit. Die Ersatzzeichen durch die eigentlich gemeinten auszutauschen, macht ein Zitat nicht weniger präzise, meiner Ansicht nach ist sogar das Gegenteil der Fall.

Das kann man anders sehen, aber die Dokumentation der Vorlage:Internetquelle scheint mir Recht zu geben. --TMg 19:06, 1. Dez. 2012 (CET)

+1 --Seth Cohen 20:08, 18. Dez. 2012 (CET)

Vorschlag: Absetzen von Vorlagen nach Weblinks o.ä.

Kannst du die Funktion hinzufügen, dass Vorlagen wie {{Navigationsleiste XYZ}} "für sich" stehen. Häufig werden sie einfach an Weblinks drangehängt, z.B.:

== Weblinks ==
* www.fdgsgdg.de
* www.fgfg.com
{{Navigationsleiste XYZ}}

Für die Lesbarkeit schöner wäre:

== Weblinks ==
* www.fdgsgdg.de
* www.fgfg.com

{{Navigationsleiste XYZ}}

Ist natürlich nicht nur hinter den Weblinks der Fall, sondern nach dem jeweiligen letzten Abschnitt, z.B. auch manchmal direkt unter <references />. Liebe Grüße, --BlueCücü (Diskussion) 19:00, 15. Feb. 2013 (CET)

Der Fall Einzelnachweise–Navigationsleiste ist jetzt drin. Den Weblink-Abschnitt zu erkennen, ist ziemlich haarig, weil da drin auch Vorlagen und vieles andere vorkommen können. Aber ich lass das noch offen, vielleicht fällt mir was ein. --TMg 15:34, 27. Apr. 2013 (CEST)

Punkte und Kommata vor und hinter </ref>

Hallo, es fällt sehr häufig auf, dass Benutzer die Referenzen falsch setzen oder drumherum zu viele Satzzeichen setzen. Oftmals steht vor dem <ref> kein Punkt, sondern dahinter, oftmals wird ein Leerschritt vorher eingefügt usw. Bei </ref> werden auch oftmals Punkte oder Kommata dahinter angegeben. Kann man da etwas machen? Ein Beispiel. Gruß, Elvaube?! 14:46, 8. Apr. 2013 (CEST)

Solcherlei Korrekturen werden bereits durch das Script abgedeckt. Zumindest Punkte nach dem schließenden ref und Leerzeichen vor und nach dem ref werden entfernt. --BlueCücü (Diskussion) 16:53, 8. Apr. 2013 (CEST)

Wie BlueCücü sagt, mache ich bereits einige Korrekturen:

• Steht vor und hinter ref zweimal das selbe Satzzeichen, wird das hintere entfernt.
• Steht vor dem ref ein Satzzeichen und ein Leerzeichen, wird das Leerzeichen entfernt.

Wenn du mehr so eindeutige Beispiele hast, nur her damit. Leider gehört der von dir erwähnte Fall „Satzzeichen von hinter dem ref davor verschieben“ nicht zu den eindeutigen Fällen. Meines Wissens besteht in dieser Frage nach wie vor kein Konsens und ich scheue mich davor, mein Skript angreifbar zu machen, indem ich so etwas hinzufüge. Wenn du mir dabei helfen kannst, mich auf einen belastbaren Konsens zu berufen (eine eindeutig verlaufene Diskussion oder ähnliches), wäre ich dafür sehr dankbar. --TMg 18:44, 8. Apr. 2013 (CEST)

Beispiel. Gruß, Elvaube?! 21:45, 13. Apr. 2013 (CEST)

Dort stehen zwei ref vor dem Punkt und zwei nach dem Punkt. Unentschieden. ;-) Die meines Wissens halbwegs anerkannte Richtlinie lautet, wenn der Einzelnachweis das letzte Wort oder den letzten Teil des Satzes belegt, darf er vor dem Punkt stehen. Belegt er den ganzen Absatz, steht er nach dem Punkt. Das kann ein Skript nicht unterscheiden. --TMg 14:38, 14. Apr. 2013 (CEST)

Automatisches Einsetzen eines allg. Sortierschlüssels

Etwas weiter oben sagtest du zum Thema Sortierschlüssel mal: „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.“

Habe mir zum Thema „Allgemeiner Sortierschlüssel“ (SORTIERUNG/DEFAULTSORT) jetzt mal überlegt, inwieweit das automatische Setzen mit deinem Script möglich wäre. Meine Programmierkenntnisse hören irgendwann beim C64 auf, daher hab ichs einfach mal in (möglichst) logischer Sprache formuliert. Vielleicht kannst du dies ja fürs Script gebrauchen.

Ein paar Dinge vorweg:

• Mit „allgemeiner Sortierschlüssel“ meine ich die SORTIERUNG- bzw. DEFAULTSORT-Angaben über den Kategorien.
• Mit Extra-Sortierschlüssel meine ich die Sortierangaben nach dem Schema [[Kategorie:XYZ|Teil vom Lemma]].
• Ein generelles Prüfen schon vorhandener allgemeiner Sortierschlüssel halte ich (vorerst) für nicht machbar, da es zu viele Sonderfälle gibt.
• Denkbar wäre aber ein Hinzufügen des allgemeinen Sortierschlüssel, wenn:
  • a) im Lemma andere Zeichen als „a–zA–Z()“ vorhanden sind und
  • b) bisher noch kein allgemeiner Sortierschlüssel im Quelltext vorhanden ist.

Treffen a) und b) zu könnte das Script folgendermaßen vorgehen:

Vor-Prüfung

1. Prüfe, ob der Artikel Personendaten enthält
   • falls ja, dann setze als allg. Sortierschlüssel = die Zeichenfolge, die hinter „{{Personendaten|NAME=“ steht
   • falls nein, dann gehe zu 2.)
2. Der Artikel gehört zur Kategorie:Begriffsklärung
   • falls ja, dann springe zu 4.)
   • falls nein, dann gehe zu 3.)
3. Prüfe, ob Lemma mit Artikel beginnt; Artikel = folgende Zeichenketten (D/der, D/die, D/das, T/the, L/les, L/la, L/ l', U/une, A/a, E/ein, E/eine, D/des usw.)
   • falls ja, dann streiche diese Zeichenkette am Anfang und setze sie ans Ende des Lemmas hinter einer Raute (#)
   • falls nein, dann gehe zu 4.)
4. Prüfe, ob Lemma mit Ziffern beginnt
   • falls ja, dann füge #::: hinzu, wobei die Anzahl der : gleich der Anzahl der Ziffern bis zum ersten Nicht-Ziffernzeichen 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?)
   • falls nein, dann gehe zu 5.)
5. Prüfe, ob Lemma in einer der Unterkategorien der Kategorie:Liste steht UND mit einer der Zeichenketten (Liste/List aller/Liste bedeutender/Liste bekannter/Liste der/Liste des/Liste von) beginnt
   • falls ja, dann streiche diese Zeichenkette und gehe zu 6.)
   • falls nein, dann gehe zu 6.)

Haupt-Prüfung

6. - (Bindestrich) → streichen (im Englischen erlaubt) erledigtErledigt
7. – (Gedanken-/Bis-Strich) → Leerzeichen erledigtErledigt
8. / → Leerzeichen erledigtErledigt
9. , → Leerzeichen (außer in Personenartikeln, dort stehenlassen)
10. . → Leerzeichen (im Englischen erlaubt)
11. „“ ‚‘ “” " (Anführungszeichen aller Art) → streichen erledigtErledigt
12. ' ’ ʿ (Apostrophe aller Art) → streichen (gerade Hochkommas sind im Englischen erlaubt) erledigtErledigt
13. ! ? → streichen
14. Klammerinhalt (nur, wenn Klammer am Lemmaende) → streichen
15. () (Klammern aller Art) → streichen
16. äèéêöüāčłńňōőšūž → aeeeouaclnnoosuz, ß → ss, ²³ → 23 (sowie alle Änderungen, die das Script bisher auch schon tätigt) erledigtErledigt
17. (α, β, γ, δ → alpha, beta, gamma, delta) erledigtErledigt
18. & → und erledigtErledigt (eigentlich je nach Zusammenhang auch „and“, „et“ usw., aber das geht wohl nicht)
19. + → und erledigtErledigt
20. … weitere Spezialfälle folgen nach und nach, sobald sie mir (oder anderen) auffallen.

Nach-Prüfungen

1. Leerzeichen zwischen Ziffern und Buchstaben einfügen
2. Doppelte/mehrfache Leerzeichen auf ein Leerzeichen kürzen erledigtErledigt
3. Leerzeichen am Ende löschen erledigtErledigt
4. Leerzeichen vor # einfügen (nur, falls nicht schon vorhanden und nur am Ende, nicht bei Artikeln, die mit Ziffer(n) beginnen)
5. Lösche allg. Sortierschlüssel, wenn er nach all diesen Schritten doch noch mit Lemma identisch ist (kann eigentlich nur bei Lemmata mit Ziffern, die nicht am Anfang stehen, der Fall sein, z. B. „All 4 One“, da zu Beginn die Ziffer 4 als „Nicht-a–zA–Z()-Zeichen“ erkannt wurde). erledigtErledigt
6. Extra-Sortierschlüssel entfernen wenn a) = identisch mit Lemma oder b) identisch mit allg. Sortierschlüssel erledigtErledigt

Und nun kommst du :) Wäre so etwas programmierbar oder würde dies das Script zum Glühen bringen? --BlueCücü (Diskussion) 23:05, 14. Mai 2013 (CEST)

Wenn du mir das so grandios aufbereitest, kann ich ja nicht anders. :-) Ich werde mich langsam Stück für Stück vorarbeiten (nicht heute, aber im Laufe der kommenden Wochen) und hier ggf. Rückfragen stellen. --TMg 13:37, 16. Mai 2013 (CEST)

Super. Ich würde mich auch als beta-Tester anbieten :) Werde dann hier allabendlich mal vorbeischauen, ob Fragen aufgetaucht sind. --BlueCücü (Diskussion) 20:09, 16. Mai 2013 (CEST)

Linkänderung in Vorlage:Übersetzung

Die Vorlage:Übersetzung sollte von der automatischen Änderung von IL-Wikilinks ausgenommen werden (Beispiel). Beste Grüße, --BlueCücü (Diskussion) 09:54, 25. Mai 2013 (CEST)

Dein Beispiel ist gelöscht. Hast du es noch im Kopf und kannst es hier zeigen? --TMg 11:06, 27. Mai 2013 (CEST)

Ich nehme an, dass diese Vorlage falsch benutzt wurde. Schließlich wird dort ja kein kompletter Interwiki-Link eingefügt, sodenn man sie richtig benutzt. Jedenfalls wurde dort eine Änderung/Verkürzung des Interwiki-Links durch den AutoFormatter erwirkt, sodass die Vorlage nicht mehr funktionierte. Aber wie gesagt, wenn ich mir die Vorlage so anschauen, nehme ich an, dass sie falsch benutzt wurde. Denn man trägt dort ja garkeine kompletten Links ein, sondern nur das Lemma, das dann per Vorlage in den Link verwandelt wird. War denke ich ein Einzelfall. Sollte ich nochmal woanders drüberstolpern, meld ich mich wieder. --BlueCücü (Diskussion) 23:05, 6. Jun. 2013 (CEST)

Ich hab die Vorlage heute geändert. ;-) Den Fehler kann ich inzwischen nachvollziehen und werde mich darum kümmern. Zur Not halt, indem alle Vorlageneinbindungen umgestellt werden. --TMg 23:56, 6. Jun. 2013 (CEST)

Hatte mich auch schon gewundert warum jemand einen kompletten Link in diese vorbildlich gestaltete, selbsterklärende Vorlage einsetzt. Dass sie es erst seit heute ist, wusste ich nicht ;) --BlueCücü (Diskussion) 00:35, 7. Jun. 2013 (CEST)

What I learned from AWB

• The German Commonscat template is called en:Template:Commons category in the English Wikipedia. erledigtErledigt
• Empty bold sections can be removed, but '''\s*''' should not strip newlines.
• Same for <b></b> and such. erledigtErledigt
• Duplicate punctuation before and after a reference should match [,.:;]. erledigtErledigt
• I think I should check for [,.:;]<ref />. and remove all these. But keep the ; and : wiki syntax intact.
• Merging duplicate references (with or without names) is a very nice idea. But how to create a propper name="…"?
• Note to self: Replace [[1970]]–[[1975]] with 1970–1975. erledigtErledigt
• Note to self: Remove the small tag from <small><ref /></small> and such. erledigtErledigt
• Fix <ref name="…""> with duplicate or wrong (typographic) quotes.
• Fix <ref name "…">.
• Drop <ref name="">, <ref name=> and such.
• Note to self: Fix my [[:en:interwiki]] shortener at Meta and other non-Wikipedia wikis. erledigtErledigt
• Replace [[this ]]with [[this]] and[[ this]] with [[this]]. Take care of the spaces.
• Try to fix broken external links like http//this or http:/this or http:///this. Take care of “HTTP/1.0”. erledigtErledigt
• Remove tags like <font>…</font> if they don't do anything. erledigtErledigt
• Try to fix <br //> and <br \>. erledigtErledigt
• Remove empty <gallery></gallery> and other completely empty tags. erledigtErledigt
• Try to fix <small/>, <i/>, <i\> and such before working with these, should be </small> and </i> in almost all cases.
• Note to self: Extend the [[2001-01-01]] rule. Take care of [[11-11-11]]. erledigtErledigt

--TMg 20:39, 11. Jun. 2013 (CEST)

Some questions on autoFormatter were brought up at en:User_talk:GoingBatty/Archive4#format script. Bgwhite (Diskussion) 22:38, 23. Jun. 2013 (CEST)

• Note to self: Check en:WP:MOS.
• Use mw.config.get('wgMonthNames'). erledigtErledigt
• Use wgFileExtensions.
• Use wgPageContentLanguage, not wgContentLanguage. No. For now I stick with "one wiki, one set of rules".
• Simply use this.locale === 'en' && mw.config.get('wgDBname') === 'enwiki' in the interlanguage links rules to distinguish the English Wikipedia from Commons, Meta etc. erledigtErledigt

--TMg 12:31, 24. Jun. 2013 (CEST)

According to the en.WP Manual of Style, [[1970]]–[[1975]] should be replaced with 1970–75 (separated by unspaced &ndash;). The only case where they should go to "full years" is the turn of a century (1999–2003). We don't use ordinal date formats in en.wp, and the German full stop to so denote is not familiar to us, so 1. Januar 2000 would need to be 1 January 2000. Regards, --Ohconfucius (Diskussion) 05:47, 28. Jun. 2013 (CEST)

Thanks. Please note that I never added a dot to a date. I tried to make all my date rules aware of the language now. From what I see in the MOS it's not forbidden do expand year ranges to 1970–1975 in the English Wikipedia. It's recommended in the German Wikipedia. --TMg 20:07, 17. Jul. 2013 (CEST)

Siehe auch

Ob es klug wäre, eine Regel für die Entfernung des Pfeils vor → {{Siehe auch|…, → ''Siehe auch: [[… u. ä. einzuführen? Referenzen: Vorlage:Siehe auch, Wikipedia:Assoziative Verweise. --TMg 21:35, 14. Jun. 2013 (CEST)

Kann man denk ich machen. Kommts denn häufig vor? Fehlkorrekturen sind in diesem Falle wohl nicht zu erwarten. --BlueCücü (Diskussion) 14:00, 16. Jun. 2013 (CEST)

Merkliste 2013

Verstreute Fundstücke und unsortierte Ideen:

• Viel hilft viel: <div clear="all" style="clear:both;"></div><br />.
• Vorlage:FormatDate und evtl. weitere auflösen, wenn sie im Artikelnamensraum auftauchen?
• <br> hinter Tabellen entfernen (Beispiel).

Erledigt:

• [[A|B-]] erkennen (dass das hässlich ist, sieht man vor allem dann, wenn man die Unterstreichung der Links aktiviert hat) und zu [[A|B]]- machen.
• .tiff/.tif dazu, evtl. auch .ogv/.oga/.ogx, vgl. commons:Commons:MIME type statistics.
• Anführungszeichen am Anfang/Ende des Textes/der Markierung. Relevant beim Schreiben von Diskussionsbeiträgen.
• Typografie (Anführungszeichen etc.) in der Zusammenfassungszeile.
• Leerzeichen nicht vom Selektionsende trimmen.
• „ISBN 10: …“ mit Doppelpunkt.
• isbn2= usw.
• In ISBN U+2010, U+2011, U+2212 wie „-“ behandeln. N-Dash lieber nicht.
• Komplett leere Sortiervorlagen (Vorlage:Nts usw.) wegwerfen.
• Evtl. wirkungslose Sortiervorlagen identifizieren (z. B. {{nts|123}}) und entfernen. Ist nicht wirkungslos; Ausgabe kann sich ändern.
• Leere Schutzbereiche verwerfen bzw. gar nicht erst schützen.
• Leere Parameter 1 aus Vorlagen mit benannten Parametern entfernen (Beispiel).
• &auml; etc. aufnehmen.
• Weißraum am Beitragsende interessiert MediaWiki sowieso nicht, das Trimmen erschwert das Markieren mit der Maus.
• (1,2 kB; PDF-Datei) automatisch drehen.
• Komma in (PDF, 1,2 kB) in Semikolon wandeln (nur im Deutschen).
• Kommastellen in (PDF; 432,1 kB) auf zwei signifikante Stellen kürzen, dabei englische 1,234 kB nicht kaputt machen.
• Einzelnachweise immer auf Punkt enden lassen, wenn das letzte Zeichen eine Ziffer ist. Das greift bei ISBNs, Jahres- und Seitenzahlen, z. B. <ref>…, S. 1.</ref> Zu fehleranfällig, und greift zu sehr in die Gestaltungsfreiheit des Artikelautors ein.

--TMg 00:10, 16. Mai 2017 (CEST)

Kommentar zur Änderungen für Sortierung und Extrasortierung + Anregung

Hallo. Habe eben die Neuerung des automatischen Einfügens des Sortierschlüssels entdeckt. Im Kommentar zur Änderung schreibst du, dass dies wohl umstritten ist. Also ich werds mal ne Weile testen, aber ich wüsste nicht, wo diese automatische Änderung zu Nachteilen oder gar Fehlern führen sollte. Die Liste „SORTIERUNG fehlt und Lemma mit Sonderzeichen“ bei CheckWikipedia ist momentan > 14.500 Artikel. Allein das zeigt doch schon, dass eine (Halb)Automatisierung hier sehr hilfreich sein kann. Sollte das automatische Einfügen des Sortierschlüssels in bestimmten Fachportalen nicht erwünscht sein (manche haben ja ihr eigenes mitunter wie ich finde komplizierteres System, z.B. Bahnstrecken, Flüsse, Kirchengebäude), so kann man ja vielleicht Artikel gewisser Kats ausschließen. Falls mir da was auffallen sollte, melde ich mich.

Eine Anregung habe ich noch zum Extrasortierschlüssel. Dieser wird ja nun entfernt, sofern er mit a) dem Lemma oder b) dem allgemeinen Sortierschlüssel übereinstimmt. Hab ich das richtig verstanden? So weit so gut. Könnte aber vor dieser Prüfung noch die selbe „Säuberung“ aller Umlaute/Sonderzeichen im Extrasortierschlüssel stattfinden, wie sie ja auch im allgemeinen Sortierschlüssel gemacht wird? Denn im Extrasortierschlüssel kommen auch häufiger die Buchstaben äöüß etc. vor. Beste Grüße und Doppeldaumenhoch für die Neuerung. --BlueCücü (Diskussion) 11:10, 11. Dez. 2013 (CET)

Nachtrag: Oben habe ich mitbekommen, dass du die Zeichen - und . wieder aus der Sortierschlüssel-Säuberung entfernt hast. Kannst du diese Änderung auf en-wp begrenzen oder wäre dass zu aufwändig? In de-wp wüsste ich jedenfalls nicht, dass diese Zeichen beibehalten werden sollen. Außer den Zeichen # (am Anfang von Artikeln, die mit Ziffern beginnen oder zur Abtrennung von Artikeln) : (am Anfang von Artikeln, die mit Ziffern beginnen) , (in Personenartikeln zum Trennen von Nach- und Vorname) ! (nur im Extrasortierschlüssel, um Artikel in einer Kategorie von allen andern abzugrenzen) fallen mir keine weiteren Sonderzeichen ein, die im allgemeinen Sortierschlüssel in de-wp benutzt werden. Beispiel: Im Artikel 1. Königlich Bayerische Reserve-Division wurde als automatischer Sortierschlüssel

{{SORTIERUNG:1. Koniglich Bayerische Reserve-Division}}

generiert, den ich dann händisch zu

{{SORTIERUNG:#:1 Koniglich Bayerische ReserveDivision}}

geändert habe.

Wo wir auch gleich beim zweiten Nachtrag wären: Ziffern am Artikelanfang im Sortierschlüssel automatisch mit der Raute und der jeweiligen Anzahl an Doppelpunkten auszustatten ist wahrscheinlich nicht mit vertretbarem Aufwand möglich, oder doch? Hoffe das waren jetzt nicht zu viele Fragen auf einmal ;) Es grüßt, --BlueCücü (Diskussion) 11:38, 11. Dez. 2013 (CET)

Die Checkwiki-Liste war der Anlass, mich mal wieder an die Sache zu wagen. Ich bin mir immer noch unsicher. Die neue Regel könnte zu viele Änderungen auslösen, die verwirrend oder praktisch irrelevant sind.

1. Hat ein Artikel nur eine Kategorie, an die schon ein korrekter Sortierschlüssel angehängt ist, wird dieser entfernt und statt dessen SORTIERUNG eingesetzt. Das hat überhaupt keine Auswirkung und könnte deshalb als unnötige Quelltextschubserei empfunden werden.
2. Vor allem in Artikeln aus Regionen, in denen ich die Zeichen nur teilweise abdecke, lässt das Skript einen nur halbfertigen Zustand zurück. Konstruiertes Beispiel: Angenommen, im Artikel ʻAbd-al-Laṭīf steht schon die Zeile [[Kategorie:X|Abdallatif]]. Dann fügt das Skript trotzdem {{SORTIERUNG:ʻAbd-al-Laṭif}} hinzu. Aber das ist größtenteils lösbar, ich muss einfach nur mal diese Liste abarbeiten.
3. Das mit dem Strich werde ich so machen.
4. Das mit den Zahlen ist technisch nicht schwer, ich finde das aber merkwürdig. Bist du sicher, dass es keine Ausnahmen gibt, in denen die Zahl vorn stehen bleiben darf? Im Englischen werden einfach führende Nullen ergänzt.

--TMg 21:33, 11. Dez. 2013 (CET)

1. Es hat den Vorteil, dass beim Hinzufügen weiterer Kategorien, in diesen gleich richtig sortiert wird.
2. Solange die Liste nicht abgearbeitet ist, wird man trotzdem darauf aufmerksam, dass der allgemeine Sortierschlüssel fehlt und kann diesen händisch korrigieren. (Solange würde ich die Änderung, dann nur in der Betaversion lassen.)
3. Find ich gut.
4. In de-wp wurde die nennen wir sie mal #:-Regel mal eingeführt, weil so immer automatisch richtig sortiert wird, egal wieviele Ziffern die Zahl hat. So müssten z.B. nicht unzählige Sortierschlüssel in Artikeln um führende Nullen ergänzt werden, wenn jemand auf die Idee käme ein (relevantes) Buch mit dem Titel „250000000000 Sterne unter dem Himmelszelt“ zu schreiben oder einen Film namens „26867805000000000000 – Das Jahr in dem Loschmidt konstanten Kontakt aufnahm“ dreht. Die Regel ist zwar für Sortier-Zwecke praktischer, allerdings leider nicht sehr intuitiv. Oftmals weggelassen werden die #:-Zeichen eigentlich meines Wissens nur in kleinen Kategorien, in denen es auch unter Nichtberücksichtigung der #:-Regel zu keinen Fehlsortierungen kommt. Auch in Extrasortierschlüsseln wird oft „falsch“ sortiert, z.B. [[Kategorie:Badminton-Weltmeisterschaft|#2006]] (also ohne ::::). Dies hat derzeit natürlich keine sichtbaren Auswirkungen, aber spätestens im Jahre 10000 wirds kritisch ;) Hoffen wir, dass es bis dahin eine Wikisoftware gibt, die Zahlen selbstständig am Artikelanfang nicht Ziffern für Ziffer, sondern als ganze Zahl sortiert. --BlueCücü (Diskussion) 08:57, 12. Dez. 2013 (CET)

Mein Problem mit den Zahlen ist, dass das Chaos nur noch größer wird, wenn ein paar Artikel die #:-Zeichen enthalten und ein paar nicht. Oder? Ich verstehe das bis jetzt so, dass z. B. „#::::2001“, „2002“ und „#::::2003“ falsch sortiert werden, also sehr wohl ein Problem entstehen kann, das es vor dem Eingriff meines Skriptes nicht gab. --TMg 01:36, 13. Dez. 2013 (CET)

Problem würd ichs nicht nennen. Es zeigt dann ja, dass in der jeweiligen Kategorie generell mal aufgeräumt werden müsste. Verstehe aber wenn das nicht automatisiert werden und daher lieber im Einzelfall händisch geändert werden sollte. Falls du es doch mit vertretbarem Aufwand programmieren könntest, würde ich so eine Funktion in meine common-Unterseite aufnehmen und testen. Würd dann bei entsprechender Änderung vorher in die Kategorien schauen und weitere Artikel anpassen bzw. ggf. von der Änderung absehen. --BlueCücü (Diskussion) 10:37, 13. Dez. 2013 (CET)

Die Unicodeblock-Liste habe ich abgearbeitet und denke, dass jetzt 99,9 % aller Zeichen transformiert werden sollten. Die schon seit längerem gewünschte Säuberung von Extrasortierschlüsseln ist auch endlich drin. Das Hinzufügen allgemeiner Sortierschlüssel bleibt vorerst eine Betafunktion. Ich denke, ich werde es sogar zu einer Opt-in-Funktion machen müssen, weil es den Blick von jemandem braucht, der sich mit Kategorien auskennt. Im Englischen beispielsweise muss man führende Nullen hinzufügen und dazu einen Blick auf die anderen Artikel in der Kategorie werfen. Das ist unmöglich automatisierbar. Auch die #:-Regel kann ich nicht für alle Benutzer automatisieren, weil es Ausnahmen gibt. Ich habe aber eine benutzerdefinierte Regel vorbereitet, die du testen kannst. Frage dazu: Die Regel versucht, auch schon vorhandene #:-Präfixe zu korrigieren. Ich überlege, das raus zu nehmen, wenn es mehr Schaden als Nutzen bringt. --TMg 14:10, 15. Dez. 2013 (CET)

Danke. Ich werds mal eine Weile testen und dann Rückmeldung geben, wie die Schaden-Nutzen-Bilanz ausschaut. --BlueCücü (Diskussion) 05:17, 16. Dez. 2013 (CET)

P.S.: Kann der Punkt . noch automatisch aus dem Sortierschlüssel entfernt werden oder spricht etwas dagegen? Kann meines Wissens nach ignoriert werden. --BlueCücü (Diskussion) 08:26, 16. Dez. 2013 (CET)

Weiter oben schreibst du: „Da er (der Punkt) 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.“ Meist ist er ein trennendes Zeichen, das stimmt. Allerdings folgt auch in den meisten Fällen dann sowieso ein Leerzeichen. Oder der Punkt ist weder trennend noch bindend, sondern Bestandteil einer Zahl (100.000) oder gehört zu einer Ordinalzahl (1., 2., 3.) im Lemma. Daher würd ich nicht durch ein Leerzeichen ersetzen, sondern komplett streichen vorschlagen. --BlueCücü (Diskussion) 08:34, 16. Dez. 2013 (CET)

Im Englischen darf ich Punkte nicht entfernen. Auch im Deutschen scheint mir das keine sichere Sache zu sein, siehe {{SORTIERUNG:Smith, Robert L.}}. Hast du weitere konkrete Beispiele (außer „20.000 Meilen unter dem Meer“, da ist es klar), in denen der Punkt zur korrekten Sortierung unbedingt entfernt werden muss? --TMg 16:42, 16. Dez. 2013 (CET)

Zitat von weiter oben: "Die Regel versucht, auch schon vorhandene #:-Präfixe zu korrigieren. Ich überlege, das raus zu nehmen, wenn es mehr Schaden als Nutzen bringt." Ja, würde ich rausnehmen. Verwirrt glaube ich eher. Wäre zwar formal richtiger, aber wenns in einem Artikel von vielleicht 20 ähnlichen einer Kategorie geändert wird, dann stimmt die Reihenfolge dort erstmal nicht. Es sei denn man ändert gleich alle anderen 19 mit. Aber daran denkt sicher nicht jeder. Zu weiteren Beispielen. Also bei Personennamen ist meine ich sogar die weitaus gängigere Praxis den Punkt - wie auch Bindestriche oder Apostrophe - zu entfernen. Desweiteren kommen Punkte hin und wieder in Werkstiteln vor. Insgesamt waren es 2011 ca. 7800. --BlueCücü (Diskussion) 15:17, 30. Dez. 2013 (CET)

Jahreszahlenbereichskorrektur in Literaturangaben

Häufig möchte das Script Jahreszahlen vom Schema 1944–45 in 1944–1945 korrigieren. In Literaturangaben setze ich das meist wieder zurück. Manchmal rutscht es mir aber auch durch. Dadurch kam z.B. diese Diskussion zustande. Gibt es eine Möglichkeit, diese Änderung im Titel von Einzelnachweisen und in Abschnitten die „Literatur“ in ihrer Überschrift haben, nicht automatsch vornehmen zu lassen? Aber erstmal ein frohes Fest und nen guten Rutsch, --BlueCücü (Diskussion) 16:33, 24. Dez. 2013 (CET)

Änderung in Vorlage commonscat

Der Name in der Vorlage Commonscat sollte besser unangetastet bleiben (Beispiel). Oder wäre das ein Hinweis die Kategorie auf Commons zu verschieben? --BlueCücü (Diskussion) 16:57, 24. Dez. 2013 (CET)

Im Englischen – also auch bei Commons – sollen die (eigentlich falschen) geraden Anführungszeichen verwendet werden. Die Änderung des Skripts darf also nicht übernommen werden. Das zu vermeiden, ist in diesem Fall leider schwierig. Vielleicht kann ich die Zeichen innerhalb der Commons-Vorlagen einfach pauschal zurück wandeln. Dazu muss ich mich aber mal durch die Commons-Kategorien wühlen. --TMg 00:32, 30. Dez. 2013 (CET)

Merkliste 2014

Höchste Priorität:

1. Jahreszahlenbereiche in Buchtiteln nie ausschreiben.
2. Weblinks vor typographischen Änderungen schützen.

Verstreute Fundstücke und unsortierte Ideen:

• „etwa/ca./um [[1810]]“ u. ä. entlinken.
• Leerzeichen mindestens vor <br /> entfernen.
• Zitate und bestimmte andere Vorlagen stärker vor Änderungen schützen.
• Sind weitere Säuberungen rund um <ref> konsensfähig? Sind Fälle wie ,<ref />. praxisrelevant? Ist das Verschieben hinter das Satzzeichen per Opt-in denkbar?
• Redundante Fettschreibung aus Tabellenköpfen werfen (nicht aus Definitionslisten, um deren Missbrauch nicht zu legitimieren).
• Weblinks auf häufige Schwesterprojekte (commons:, s:, wikt:) in Wikilinks umwandeln.
• Diff-Links lassen sich per [{{fullurl::|…}} …] kürzen. Konsensfähig? Wurde zerstört.
• <div style="clear:both;"></div> und <br style="clear:both;" /> immer in genau diese Form bringen.
• Zeichen, die Schnark ersetzt, ich aber noch nicht:
  ȦȺȧⱥƁƂɃƀƃƇȻƈȼƉƊƋƌȡȸ DŽ Dž DZ Dz dž dz ƎƏƐȨɆȩɇəƑƒƓƔǴǵȞⱧⱵȟⱨⱶǶ ƕ ƖƗǰɈȷɉƘⱩƙⱪȽⱠⱢƚƛȴⱡLJ Lj lj ƝȠƞȵNJ Nj nj ƆƟƠȪȬȮȰơȫȭȯȱƢ ƣ ƤⱣƥɊɋȹ ɌⱤɍƩȿƬƮȾƫƭȶⱦƯɄưƲⱴǷƿƳȲɎƴȳɏƵȤⱫƶȥɀⱬ.…
  AAaaBBBbbCCccDDDdddbDZDzDZDzdzdzEEEEEeeeFfGGGgHHHhhhHVhvIIJJjjKKkkLLLllllLJLjlgNNnnNJNjnjOOOOOOOoooooOIoiPPpQqqpRRrSsTTTttttUUuVvWwYYYyyyZZZzzzz
• „1850-er Jahre“ zu „1850er Jahre“ (Quelle).
• [http://doppelt.de http://doppelt.de] kürzen (Beispiel).
• <ref Name="…"> klein schreiben.
• Evtl. auch hex-kodierte &#91; und &#93; vereinheitlichen? Macht den Quelltext nicht wirklich lesbarer; keine eindeutige Präferenz für eine Schreibweise.
• 5%; sollte genauso wie 5%, erkannt werden. Lieber nicht, wegen CSS.

Erledigt:

• Interlanguage-Links stärker vor ungewollten Änderungen schützen.
• [[1810]]–[[1811]] entlinken.
• Bis-Strich in 1901-? (Diskussion dazu).
• Aufdecken verschleierter Linkziele umschaltbar machen (nur noch Endungen wie in [[Berlin|Berliner]], nicht mehr ganze Wörter wie in [[Berlin|Berliner Mauer]]).
• Ausschreiben von Jahreszahlenbereichen abschaltbar machen; nur im Deutschen standardmäßig aktiviert.
• Vorlagenformatierung kommt mit {{Personendaten<!-- Metadata: see [[Wikipedia:Persondata]]. --> nicht klar.
• Dec/hex-kodierte &amp; immer in diese Form bringen.
• 1 % in allen Sprachen säubern, aber 1% unangetastet lassen. Im Englischen das Leerzeichen ggf. ganz entfernen (Referenz).
• Warum wird https://de.wikipedia.org/wiki/A:B am Text/Markierungsende zu [[A]]:B?
• Huch, ich hab ha vergessen.
• Kein geschütztes Leerzeichen in |Parameter = 2 m² und |Parameter = 1,2 m² Ohne ² klappt es schon.
• Ligaturen klein schreiben (z. B. Œ → Oe, Referenz).
• Vorlagennamen /Absatz|Clear(?:[ |]*(?:all|both))?/gi in de zu „Absatz“, sonst „Clear“.
• Vorlagennamen /-|Br|Breakafterimages|Clr/gi in de zu „Absatz“, sonst lassen (eigentlich {{-}}, aber das wäre schlimmer).
• <small><ref name="Unsinn" /></small>

--TMg 15:12, 18. Feb. 2016 (CET)

Doppelgemoppel der Kat auf BKL-Seiten

Die Kategorie:Begriffsklärung wird ja auf den BKL-Seiten automatisch durch die Vorlage:Begriffsklärung eingebunden. Hin und wieder ist die Kategorie trotzdem nochmals in der Form [[Kategorie:Begriffsklärung]] im Quelltext vorhanden und könnte denke ich automatisch entfernt werden. Auch alles in der Form [[Kategorie:Begriffsklärung|Lemma]] kann gelöscht werden. Dies würde eh über das automatische Einfügen des Sortierschlüssels bei im Lemma vorhandenen Sonderzeichen ersetzt werden. --BlueCücü (Diskussion) 22:38, 14. Jan. 2014 (CET)

Diff automatisch aufrufen

Hallo TMg,
Du empfiehlst ja auf jeden Fall das diff zu kontrollieren, was ich auch tue. Wäre es dann nicht möglich das diff automatisch nach Deinem Tool aufzurufen (sofern etwas geändert wurde) und am Kopf der Seite zu positionieren? Das würde viel Zeit sparen.
Gruß --Baumfreund-FFM (Diskussion) 18:54, 14. Apr. 2014 (CEST)

ich klick immer auf vorschau, aber dass diff kann ich mir erst anschauen, wenn ich gespeichert habe oder? --Wetterwolke (Diskussion) 01:20, 15. Apr. 2014 (CEST)

Das diff entspricht Änderungen zeigen und geht schon vor dem Speichern. --Baumfreund-FFM (Diskussion) 06:26, 15. Apr. 2014 (CEST)

seid 7 jahren angemeldet, 2000 bearbeitungen und erst jetzt wo du es sagst nehm ich es war :D danke --Wetterwolke (Diskussion) 19:24, 15. Apr. 2014 (CEST)

Gern geschehen, manchmal sieht man den Wald vor lauter Bäumen nicht. --Baumfreund-FFM (Diskussion) 20:59, 15. Apr. 2014 (CEST)

Technisch ist der Wunsch kein Problem. Ich hatte das einst sogar experimentell drin. Aber es schränkt die Nutzbarkeit stark ein, wenn man automatisch in die Diff-Ansicht gezwungen wird. Als Benutzereinstellung oder zweiten Knopf könnte ich mir das vorstellen. Mal sehen. --TMg 21:46, 20. Apr. 2014 (CEST)

Meinst Du, dass Du hier noch etwas machst? --Baumfreund-FFM (Diskussion) 07:04, 27. Mai 2014 (CEST)

Wie wäre es, wenn Umschalt+Klick auf den Besen die Diff-Ansicht aufrufen würde? --TMg 09:33, 11. Jul. 2014 (CEST)

Überflüssige Leerstelle nicht beseitigt

Hallo TMg,
ist das Absicht?: Bei dieser Bearbeitung wurde die Leerstelle vor dem miniatur in der ersten Zeile nicht beseitigt. Auch ein erneuter Aufruf des Tools ändert dies nicht.
Nochmals danke für dieses schöne Werkzeug, ich setze es inzwischen ständig ein.
Gruß --Baumfreund-FFM (Diskussion) 07:14, 12. Mai 2014 (CEST)

Interessante Kombination, die berücksichtige ich so noch nicht. Ich säubere vorn den Dateinamen und hinten das hochkant, die miniatur lasse ich aber unangetastet. Deshalb bleibt das Leerzeichen übrig. Ich werde das aufnehmen. --TMg 14:42, 14. Mai 2014 (CEST)

Allerdings interessant. So hat sich die regelmäßige Kontrolle der Ersetzungen gelohnt. --Baumfreund-FFM (Diskussion) 18:42, 14. Mai 2014 (CEST)

Commonscat

in wikilinks und bildereinbindungen werden unterstriche entfernt, dass könnte man auch für die bsp {{Commonscat|Arena_das_Dunas}} machen. gruß --Wetterwolke (Diskussion) 02:28, 28. Mai 2014 (CEST)

Vielleicht beachtenswert

Hallo TMg,
bei dieser Bearbeitung musste ich die erste Zeile manuell bearbeiten, da der autoFormatter sie nicht beachtete (Sie war ja auch inkonsistent). Vielleicht könnte er ja bei Zeilen, die er nicht versteht eine Warnung äußern. Wenn es nicht in der ersten Zeile gewesen wäre, hätte ich sie wahrscheinlich nicht gesehen.
Gruß --Baumfreund-FFM (Diskussion) 07:20, 18. Jul. 2014 (CEST)

Ich bin in jedem Fall dankbar für die Meldung, auch wenn ich mir nicht ganz sicher bin, was du da erwartet hättest. Ich könnte framed durch gerahmt ersetzen, tue das bisher aber nur, wenn dahinter noch eine Beschreibung folgt. mini und gerahmt zusammen ergeben wenig Sinn. Das automatisiert auf gerahmt zu kürzen, wäre gefährlich. Das darf nur bei kleinen Bildern gemacht werden, die nicht skaliert werden müssen. Aber das kann das Skript nicht wissen. Also auf mini reduzieren? --TMg 11:15, 22. Jul. 2014 (CEST)

Wie schon geschrieben, hatte ich keine konkrete Erwartungshaltung, sondern wollte nur die Auffälligkeit berichten. Vielleicht wäre es möglich bei unklaren Sonderfällen ein Popup zu bringen. Wenn diese nicht zufällig im Sichtfeld sind, bemerkt man sie wohl sonst nicht. --Baumfreund-FFM (Diskussion) 18:58, 22. Jul. 2014 (CEST)

Korrekturen

2 3 4 Anmerkungen habe ich:

1. Warum wird das eine right entfernt, das andere aber nicht automatisch, sondern nur übersetzt?
2. Vorlage:GiS (Gleise in Serviceeinrichtungen) ist keine der Sprachvorlagen und sollte daher das große G behalten.
3. Könnte man beim Einfügen der geschützten Leerzeichen vor Maßeinheiten die Überschriften auslassen, da sonst die Links zu diesen Abschnitten nicht mehr funktionieren? --Hadibe (Diskussion) 22:30, 1. Feb. 2015 (CET)
4. z.B. und z. B. wird momentan nicht korrigiert. Das ist zwar kein Checkwiki-Eintrag, ist aber vielleicht trotzdem leicht einzubauen. --Hadibe (Diskussion) 06:08, 16. Feb. 2015 (CET)

ad 2) wüsste ich einen anderen Weg: Vorlage Diskussion:GiS #Umbenennung dieser Vorlage

LG --PerfektesChaos 22:47, 1. Feb. 2015 (CET)

1. Die redundante mini|rechts-Kombination wird im Augenblick nur dann automatisch erkannt, wenn die beiden Wörter direkt hintereinander stehen. Ich kann versuchen, das zu erweitern und danke für das schöne Beispiel. Aber ich bin mir nicht sicher, ob sich der Aufwand dafür lohnt.
2. Dafür werde ich keine Ausnahme einbauen, tut mir Leid. Bitte umbenennen. „gi“ ist zwar kein Sprach- sondern der Ländercode für Gibraltar, unnötig verwirrend ist das trotzdem.
3. Faszinierend. Dieser Fall fehlt in meiner Testumgebung. Wird behoben. --TMg 18:41, 4. Feb. 2015 (CET)
4. Seit es Vandalismusvorwürfe gab, ist die Entscheidung, ob und welche Abkürzung wie ersetzt werden soll, eine Entscheidung der Benutzer meines Skripts.

--TMg 12:09, 16. Feb. 2015 (CET)

Alles klar, danke. Diese Funktion kannte ich noch nicht. --Hadibe (Diskussion) 15:09, 16. Feb. 2015 (CET)

replacing – with - inside wikilinks

For slovenian Wikipedians: Is there any way to stop replacing – with - inside wikilinks [[wiki link with - inside|label]] or just [[wiki link with - inside]]. Wikilink should not be changed, because now changes cause red links. I`am using local autoFormatter.js with local autoFormatterSettings.js. --Pinky sl (Diskussion) 14:28, 27. Feb. 2015 (CET)

Category

Firstly, I would like to thank you for this tool, which does simple but necessary tasks. Could you set the command to stop on "Category" changes, especially between dash (-) and hyphen (–)? Eg: When autoFormatter applies on Articles created or expanded during Women's History Month (India) - 2015, it changes dash (-) to hyphen (–) --AntanO (Diskussion) 08:50, 22. Mär. 2015 (CET)

Thanks. I will try to improve but it's not easy in this case. Also I wonder. I know the English Wikipedia agrees on using the longer en-dash. Shouldn't the category name be fixed instead? --TMg 21:43, 26. Mär. 2015 (CET)

Yes, category name shouldn't fix. Usual fix is not an issue. No problem if it is too much of complicate. --AntanO (Diskussion) 10:25, 9. Apr. 2015 (CEST)

Merkliste 2015–2019

• Bis-Strich in |Seiten=49-50.
• <small> auch um mehrere <ref> entfernen.
• <ref name "rhythm" /> und <ref name 'rhythm' /> (Beispiel)
• Triviale <imagemap>-Syntax durch [[File:…|link=…]] ersetzen.
• Monitor Special:LintErrors.

--TMg 11:03, 19. Apr. 2017 (CEST)

Erledigt:

• Der Umherirrende schlägt vor, den Vorteil minimaler Diffs als gewichtiger zu betrachten als den geringen Nutzen, den das Entfernen von Leerzeichen am Ende leerer Infoboxzeilen bringt.
• [[Datei:….png|verweis=https://de.wikipedia.org/wiki/Spezial:…]] geht kaputt (Beispiel).
• Alternativtext entfernen, wenn er mit der Bildbeschriftung identisch ist (Beispiel).
• LRM am Textende entfernen.
• Vorlage:Imagemap substituieren.
• Strip empty || from image syntax.
• Strip duplicate |thumb|…|thumb| and such from image syntax.

--TMg 21:42, 17. Mai 2019 (CEST)

ISBN 9789024732241

Hallo, warum zerpflückt der gelbe Kehrbesen (Auto-Format) - wie sonst bei gültigen Nummern üblich - obige nicht? Gruß --Hedwig Storch (Diskussion) 15:10, 12. Mär. 2016 (CET)

Das ist ein niederländisches Buch (ISBN-Gruppennummer 90). Die Regeln sind für jedes Land anders, und bisher unterstütze ich nur deutsche und englische Bücher. --TMg 09:38, 14. Mär. 2016 (CET)

Info: Benutzer:PerfektesChaos/js/isbnLib‎

• Die momentan sehr umständliche Installationsprozedur soll in den nächsten Wochen (Ostertage) umgeschrieben werden von .using() auf mw.hook().
  • Dann ist nur noch das Laden der Bibliothek erforderlich, und sie meldet sich, wenn alle internen Komponenten auch einsatzbereit sind.
  • In den letzten Monaten habe ich alle WSTM-Komponenten auf mw.hook() umgestellt; es ist dann jetzt innere Angelegenheit von isbnLib‎, sich zusammenzusuchen, was gebraucht wird. Der Anwender soll sich um das WSTM-Zeug nicht mehr kümmern müssen.
• In Ermangelung externer Fremdnutzer hatte ich hier bislang wenig ausgebaut.

VG --PerfektesChaos 11:31, 14. Mär. 2016 (CET)

Danke für den Hinweis. Nur, hm, … bitte versteh mich nicht falsch, aber ich möchte dir gern einmal sagen, dass mich deine Skripte häufig äußerst ratlos zurück lassen. Ich meine, du gibst dir so viel lobenswerte Mühe, dass deine Projekte auch von anderen weiter nutzbar sind, seien es Anwender oder andere Entwickler. Du schreibst mehrsprachige, hervorragend formatierte Dokumentationen. Aber wenn es dann ans Eingemachte geht, ich ernsthaft in eines deiner Skripte eintauchen und den Quelltext verstehen möchte, … äh, was? Und damit meine ich noch nicht einmal deine durchaus krude Quelltextformatierung. Dazu habe ich genug Erfahrung, um darüber stehen und Quelltext trotzdem lesen zu können. Aber wenn Dateinamen und Variablen nur einen Buchstaben lang sind, wenn sich eine Abkürzung nach der anderen die Klinke in die Hand geben, wenn Funktions- und Parameternamen aus vermutlich ästhetischen Gründen alle mit den selben Anfangsbuchstaben beginnen, egal ob das inhaltlich Sinn ergibt oder nicht, … es tut mir sehr Leid, aber dann gebe ich auf.

Konkreter: en:User:PerfektesChaos/js/isbnLib/d.js ist nur ein Wrapper. Wo ist der Quelltext? In deiner Dokumentation wird auf en:user:PerfektesChaos/WikiSyntaxTextMod/S und en:user:PerfektesChaos/WikiSyntaxTextMod/U verwiesen, aber diese Seiten gibt es gar nicht. Durch schrittweises Nachvollziehen dessen, was dein Lade-Code tut, habe ich verstanden, dass das keine Seitennamen sondern Modulnamen sind, und die aufgelöste Seite en:User:PerfektesChaos/js/WikiSyntaxTextMod/dU.js ist, wobei „d“ für „Debug-Version“ und „U“ für „Utilities“ steht. Lesbar sind solche Dateinamen genauso wenig wie zum Beispiel if ( !impact ) if ( ask ) if ( naked !== ask ) impact = 6;. Gut, dieses Fragment habe ich aus dem ISBN-Parser entnommen, und Parser-Code ist immer schwer lesbar. Aber warum diese Variablennamen? Was für ein „Impact“? Wie kann etwas, das eben noch keinen Impact hatte, plötzlich den Impact 6 haben? Was heißt das? Was bedeutet eine Prüfung auf „Ask“? Dass Fragen gestellt werden dürfen? Was für Fragen, von wem, an wen? Was ist „naked“? Und wie kann „nackt sein“ ungleich „stelle Fragen“ sein? Das ergibt alles keinen Sinn. Es macht es mir nicht nur unmöglich, den Code zu verstehen, ich kann ihn nicht einmal benutzen, wenn das öffentliche Interface, das du anbietest, kryptisch mw.libs.isbnLib.focus( about ) heißt, statt offensichtlich mw.libs.isbnLib.guessLanguageCodes( isbn ). Und ich frage mich auch, warum du dir das selbst antust? Stört es dich nicht selbst, dass du immer und immer wieder hinschreiben musst, wofür die Buchstaben, Abkürzungen und Kunstbegriffe stehen? --TMg 10:53, 17. Mär. 2016 (CET)

Ich programmiere seit über 35 Jahren, und ich verfahre dabei immer gleich.

• Innere Angelegenheiten meiner Benutzerskripte muss erstmal nur ich verstehen; Schnittstellen nach jeweils außen dokumentiere ich ausgiebig. Wie ich nach innen vorgehe, handhabe ich so, dass ich es leicht nachvollziehen und pflegen kann. Was in der nur wenige Jahre dauernden Wiki-Benutzersoftware-Welt irgendwer später damit anstellen will, ist mir egal.
• Bei ungetypten Sprachen arbeite ich immer mit meiner Version der Ungarischen Notation.
• Ich hasse ungetypte Sprachen.
• Wenn du mal geduldig auf alle mit .js guckst, wird sich dir der Sinn von d und r erschließen. Bedenke, dass meine Vorkoster diverser Skripte mit der d-Version arbeiten, die teilweise mehrere Wochen im Voraus erscheint, während die analoge r-Version erst nach Testerei auf den Markt kommt. Die D und R hatte ich wohl bereits Anfang der 1990er im Microsoft Studio gesehen und waren damals schon in IDE allgemein üblich.
• Warum ein Buchstabe zur Kennzeichnung der internen WSTM-Module ausreichen muss, kannst du dir anhand der öffentlichen WSTM.main.subs = "MWCEIHTXOLUS"; (es gibt zurzeit noch drei private dazu) vielleicht ausmalen. Da ich der einzige Bearbeiter bin und ich das auswendig weiß, wird es reichen. Die gesamte Buchstabenkette muss für den Vollstart von WSTM geladen und verwaltet werden, und alles über diese Kennbuchstaben hinaus würde dabei nur stören, zumal sie auch in die volle Versionsbezeichnung der momentan ablaufenden Konfiguration einfließen.
• Wer die Bedeutung dieser Kennbuchstaben gleichwohl erläutert bekommen möchte, gehe auf User:PerfektesChaos/js/WikiSyntaxTextMod/tech (verlinkt auch auf en:User:PerfektesChaos/js/WikiSyntaxTextMod/tech)
• WSTM-Code darf sich gern jeder Internetbenutzer auf dem Planeten angucken. Er ist aber für mich von mir geschrieben und nicht für Außenstehende.

Wie ich bereits angekündigt hatte, habe ich die Bereitstellung von der 2013 für eine bestimmte Situation entstandenen komplizierten Methodik zu einer deutlich einfacheren Weiterverwendung fortgeschrieben.

Ich dokumentiere Argumente an der Schnittstelle und die genaue Bedeutung lokaler Variablen sowie die genauere Wirkungsweise von Funktionen.

• Wenn ich kurz i schreibe und das dutzendfach in Schleifen und Zugriffen auf Teilzeichenketten vorkommt, dann ist der Code übersichtlicher als wenn ich statt dessen einen selbsterklärenden Namen mit 10–20 Buchstaben verwenden würde. Wenn es Tricks und Besonderheiten gibt, dann dokumentiere = kommentiere ich einmalig i und die Feinheiten, was alles nicht in einen Namen hineinpassen würde.
• Ich werte seit Jahrzehnten meine standardisierten Funktionsdokus aus und generiere daraus HTML-Seiten mit ausklappbaren Details zu den Argumenten. Ich navigiere erstmal in diesen und nicht im Code direkt. Für Universal-Bibliotheken, von denen die Nachwelt etwas haben mag (stringLib), verwende ich Javadoc.

Wenn irgendwo unter „ResourceLoader – Dependencies“ Bezeichner genannt werden, handelt es sich immer um Modulnamen.

isbnLib‎ 2.0 ist jetzt hoffentlich benutzerfreundlicher.

VG --PerfektesChaos 11:50, 18. Mär. 2016 (CET)

Zeilenweise Ersetzungen bei Regexp-Objekten

Ich war so frei, und habe mal wieder ein Skript von dir geforkt: Benutzer:Boshomi/ARreplace.js

In diesem Fall nutze ich nur die benutzerdefinierte Ersetzen-Funktion. Aufgrund eines Hinweises auf meiner Disk habe ich die Ersatzfunktion abgeändert, sodass auch Zeilenweise Ersetzungen möglich werden: Spezial:diff/152465403 Frohes Schaffen — Boshomi ☕⌨☺   16:36, 13. Mär. 2016 (CET)

Danke für die Nachricht. Ich bin dennoch ziemlich verwundert, denn ich kann in deinem Fork letztlich nichts erkennen, was das Original nicht auch kann. Wer braucht denn die Funktion und wozu? Bei dir kommt gar kein ^ vor. Herzi Pinki kann in seiner common.js einfach den /m-Modifikator verwenden, dann finden /^…/gm und /…$/gm nicht mehr nur den Textanfang/ende, sondern Zeilenanfänge/enden. Das ist ein ganz reguläres Regex-Feature, da greife ich mit meinem Skript auch gar nicht ein. --TMg 10:06, 14. Mär. 2016 (CET)

Danke für die Antwort. Dass man mit dem m-Flag dieses Verhalten auch erreichbar ist wusste ich nicht. Der Hintergrund für den Fork war, dass ich so nur die benutzerdefinierten Anweisungen ausführen kann, und alles andere liegen lassen kann. Das ist dort sinnvoll wo man ein spezifische kleine Änderung für sehr viele Artikel umsetzen will. In diesem Fall ist Autoformater zu aktiv, wodurch bei großen Arikeln und dementsprechenden aufwendigen Diffs es an machen Stellen schwierig ist, eventuelle Fehler zu erkennen. Ich habe das vor gut 2 Wochen im großen Umfang eingesetzt, und dabei dann aber zu viele Kleinigkeiten übersehen.

Wenn ich einen Wunsch für den Autoformater äußern darf, (und wenn es mir möglich wird, hätte ich das für den Fork geplant):

• eine zweite Schaltfläche mit der man zu "Einstellungen" kommt und die ein Formular öffnet. (so ähnlich wie derzeit bei WeblinkChecker)

  

  Mockup

• Im Formular kann man auswählen, welche Funktionen aktiviert sein sollten.
• eine Eingabe für benutzerdefinierte Regexp/String-Ersetzungen.
• bei den benutzerdefinierten Änderungen für jedes Suchen-Ersetzen-Paar auch einen Editkommentar angeben kann.
• jede einzelne Zeile der benutzerdefinierten Änderungen aktivier/deaktivierbar ist.
• eine für alle PC fixierte Standardliste über common.js sollte weiterhin unterstützt werden. (Im Sinne einer ini-Datei)

Wenn ich das selbst umsetzen will, weiß ich bei meinen recht bescheidenen ja-Kenntnissen noch nicht wie lange ich dazu brauche. Der Autoformater hat aber für mich progrmmiertechnisch den Vorteil, dass ich das etwas leichter nachvollziehen kann, wie bei dem doch sehr anspruchsvollen weblinkChecker. Frohes Schaffen — Boshomi ☕⌨☺   11:56, 14. Mär. 2016 (CET)

Nachtrag: Vielen Dank, dass es den Autoformater überhaupt gibt. Es ist wirklich toll was man mit diesem Werkzeug erreichen kann. Frohes Schaffen — Boshomi ☕⌨☺   12:01, 14. Mär. 2016 (CET)

Leerzeichen vor Satzzeichen

Beispiel. --Seth Cohen 15:02, 24. Mär. 2016 (CET)

Hm. Ich verstehe die Idee, befürchte aber Fehlersetzungen. Relevanz hätte sie wohl. --TMg 21:12, 24. Mär. 2016 (CET)

Ein Problem dabei ist auch dass einige Fremdsprachen die Plenks standardmäßig verwenden, und diese bei Originalzitaten, etwa bei Linktexten, erhalten werden sollten. Frohes Schaffen — Boshomi ⌨   21:46, 18. Mai 2016 (CEST)

Space after </ref>

If the sentence has ended with a </ref> and there is no space after </ref> before the start of a new sentence, so my request is that Autoformatter automatically add this space after </ref> Thank you. Managerarc (Diskussion) 12:26, 4. Jun. 2016 (CEST)

Thanks for the suggestion. However, I'm not sure if this can be done in all cases. For example, two <ref> next to each other should not have a space between them. I can also think of other reasons to not have a space after a <ref>, for example when a template follows. So when I add such a replacement it must be limited to <ref> followed by a letter. Needs more investigation. A simple search for insource:/\<\/ref>[A-Z]/ shows only about 20 results, which is not really worth it. --TMg 14:58, 20. Jun. 2016 (CEST)

Anpassungen

• in Autofromatter kann die Zeile t = t.replace( /\{\{\s*WBA\s*\|\s*/gi, '{\{Waybackarchiv|' ); und die folgenden raus. Die Vorlagen wurden vor 2 Jahren gelöscht.
• In ARreplace (Diff) habe ich ein Bild eines Button gefixt, und die Funktion der Zusammenfassungszeile verbessert. Bitte dies in Benutzer:TMg/autoFormatter/AReplace.js übernehmen. Deine Seite habe ich in der Beschreibungsseite Benutzer:Boshomi/ARreplace für die Installationsanleitung herangezogen. (Vier-Augen-Prinzip schadet bei meinen Skriptanpassungen sowieso nicht)
• In meinem WeblinkChecker-Fork habe ich das AutoDiff eingefügt. Spezial:Diff/155688965. Das funktioniert ganz gut. Frohes Schaffen — Boshomi ⌨   14:05, 1. Jul. 2016 (CEST)

@Schnark: Das Skript //de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter/autoDiff.js ruft Autoformatter (und hoffentlich bald auch weblinkChecker) das Schnark/Diff.js auf. Wäre schön, wenn das an passender Stelle mit Fliegelflagel aktivierbar wäre. Frohes Schaffen — Boshomi ⌨   14:43, 1. Jul. 2016 (CEST)

No user-defined replacements in links

Hi, This script does not run on ur.wikipedia. Plz figure it out, Thanks. Muhammad Shuaib (Diskussion) 16:15, 6. Aug. 2016 (CEST)

Sorry, Now it works. I think any script imported in my common.js prevents autoFormat. :) Muhammad Shuaib (Diskussion) 16:56, 6. Aug. 2016 (CEST)

Is there any way to prevent auto formatting in square brackets e.g. [[ ]], it contains here links to another article or page. So we dont like to auto-format these links. --Muhammad Shuaib (Diskussion) 21:32, 7. Aug. 2016 (CEST)

Muhammad Shuaib: Can you please copy and paste a specific example or link to a specific article where such an unwanted auto-formatting happens? I'm afraid I do not know what you mean when you are talking about square brackets otherwise. My script does several different cleanups to wiki links and I'm currently not aware of any language specific problems. --TMg 15:41, 12. Aug. 2016 (CEST)

I want that autoformatter will not change or at lease will not replace (e.g. replacements used in autoReplacement function) any link, i.e. any text which exists in square brackets such as [[Germany]]. So in case any user will write wrong name like [[Gremany]], autoReplacement function will not replace but leave it as it is. Muhammad Shuaib (Diskussion) 03:10, 16. Aug. 2016 (CEST)

I'm very sorry, but I can't help you when you don't tell me which settings and user-defined replacements you are using. Both your global.js and your local common.js do not contain a autoFormatReplacements setting, but from what you are describing it seems you are talking about user-defined replacements. When a user-defined replacement asks my script to replace a word, it will do exactly that. It's up to you how you set your replacements up. You can use regular expressions. It's possible but not easy to make a regular expression not replace stuff in a certain context. --TMg 17:38, 16. Aug. 2016 (CEST)

Right, I am talking about user defined replacements which You can see here. Previously I imported from de:User:TMg/autoFormatter but it does not allow to localize button label in toolbar, so I had to copy the whole script here. Muhammad Shuaib (Diskussion) 11:02, 17. Aug. 2016 (CEST)

1. I added an autoFormatterButtonLabel setting. With this you can edit ur:MediaWiki:Gadget-ImlaCorrectionInEditTools.js and replace the line
   mw.loader.load( '//ur.wikipedia.org/w/index.php?title=User:محمد شعیب/autoFormatter.js&action=raw&ctype=text/javascript' );
   with
   mw.loader.load( '//de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript' );
var autoFormatterButtonLabel = 'خودکار درستی املا';
   You can delete your copy ur:User:محمد شعیب/autoFormatter.js then.
2. It appears you are using a script that is designed to clean up wikitext syntax to fix grammar and spelling mistakes. Even if you can do this, I do not encourage you to do this and can not help you with problems that are not in my script but in the set of user-defined replacements you are using.
3. While reading all the regular expressions in ur:MediaWiki:Gadget-ImlaCorrectionInEditTools.js I notice quite a lot of error-prone and most probably unintended details in there. Some are actual errors that make me wonder how these specific regular expressions could ever work and what their original intention was. Do you want an actual review of all these replacements? And if I would do that for you, how would you address these issues?
4. A specific example is the fragment (?:|\\s) at the start of most expressions. I assume it was intended to either match the beginning of a sentence or a space in the middle of a sentence, to avoid replacements in the middle of a word. The problem is: this fragment does nothing it is intended to do. What it does instead is searching for a backslash followed by a lower case "s" or nothing, which is always true. I believe you should either remove all these fragments or replace them with (?:^|\s).

--TMg 12:37, 18. Aug. 2016 (CEST)

1. Thanks for fixing this label issue, I replaced the script source but it does not work, and button label still appears in English. :(
2. Yes, We are using your script for fixing typos and cleaning wikitext syntax as well.
3. Of course, we would be grateful if you review these replacements and fix their errors. :)
4. As you say that you noticed (?:|\\s), and suggested to replace it with (?:^|\s). I tried this regex but it does not work, as it replaces only fist occurrence of typo at the start of sentence and then deletes the space. You could check there in sandbox. Many Thanks for your valuable help. :) Muhammad Shuaib (Diskussion) 14:17, 18. Aug. 2016 (CEST)

• I had a typo in autoFormatterButtonLabel. Please add a "t".
• You are right, my suggestion removes spaces. In this case you should simply remove all these fragment since they do not do anything anyway.

--TMg 18:06, 18. Aug. 2016 (CEST)

Englische Monatsnamen

Moin, siehst du eine Möglichkeit die automatische Anpassung vom Englischen ins deutsche Datumsformat bzw. Namen zu integrieren. Bei RegEx bin ich leider komplett überfordert. Gruß -- Quotengrote (D|B) 14:19, 7. Sep. 2016 (CEST)

Quotengrote: Gern, wenn du mir hilfst zu verstehen, was genau du meinst. Kategorien? Links? Infoboxen? Imports? Übersetzungen? Oder gar Datumsangaben in Benutzersignaturen? Woher kommt der englische Text und welche Formate kommen darin vor? --TMg 11:40, 9. Sep. 2016 (CEST)

@TMg: Haupsächlich bei Vorlage:Cite journal/Doku wenn aus dem englischen direkt übernommen wird. -- Quotengrote (D|B) 15:44, 14. Sep. 2016 (CEST)

Quotengrote: en:Template:Cite journal#Date sagt leider nichts darüber aus, was für Formate da in der Praxis vorkommen. Das müsstest du mir anhand von Beispielen zeigen. --TMg 16:16, 14. Sep. 2016 (CEST)

Ok, ich suche mal die häufigsten Varianten zusammen, weiß aber nicht ob ich das noch die Woche schaffe. Danke schonmal. ;-) -- Quotengrote (D|B) 17:46, 14. Sep. 2016 (CEST)

Feature Request: Special:Diff

I wish autoFormatter automatically converted links such as https://en.wikipedia.org/w/index.php?title=Trump&diff=prev&oldid=761435379 or https://en.wikipedia.org/w/index.php?diff=761435379 into Special:Diff/761435379. Thanks. Sondra.kinsey (Diskussion) 01:02, 24. Jan. 2017 (CET)

You might be interested in en:User:PerfektesChaos/js/pageLinkHelper by PerfektesChaos then. --Leyo 01:17, 24. Jan. 2017 (CET)

Thanks for the suggestion. I'm considering this since this special page was introduced. But I'm afraid I will not implement this, at least not as a default feature for all users. My main argument is that the name of the article is lost. I will try to come up with a custom rule you can use if you want. --TMg 08:38, 26. Jan. 2017 (CET)

– line in it.wikipedia

Hi, in it.wikipedia this line – will be used only for years and not for wikilinks. For wikilinks we use this line: -. Please, can you fix this bug? Your gadget is very great, there is only this little thing who causes mistakes and red links.--Ferdi2005 (Diskussion) 14:52, 21. Aug. 2017 (CEST)

@Ferdi2005: I'm afraid I need a much more specific example to fully understand what you are talking about. What I find most helpful is a link to an actual article where I can try to reproduce the problem myself, along with an explanation of the relevant part of your local manual of style (MOS). --TMg 17:58, 4. Sep. 2017 (CEST)

M. E. unerwünschte Formatierung

Hallo Tmg,
wenn ich hier den autoFormatter nutze, wird in einem nicht sichtbaren Link eine geschützte Leerstelle eingefügt. Kannst Du das vermeiden?
Gruß --Baumfreund-FFM (Diskussion) 07:58, 11. Nov. 2017 (CET)

Ja, diese Ersetzung wirkt unnötig. Vermeiden kann ich das aber leider nicht so einfach. Gut ist, dass der Link dadurch nicht kaputt geht. --TMg 19:18, 11. Nov. 2017 (CET)

Linkformatierung

Hallo TMg, Benutzer:Jonaes02 hat den Artikel Königsgräber der Joseon-Dynastie überarbeitet und dabei Benutzer:TMg/autoFormatter verwendet. Das hat wohl beispielsweise [[Guri|Guri-si]] durch [[Guri]]-si ersetzt. Das ist wohl normalerweise sinnvoll, in diesem Fall hatte ich aber absichtlich die erste Form gewählt. Vom Link her ist es zwar dasselbe, aber bei Suffixen mit "-" wird, anders als beispielsweise bei [[korea]]nisch, der Rest des Wortes nicht als Link formatiert (vgl. Guri-si mit Guri-si), was in der Tabelle m.E. seltsam aussieht. Insofern ändert diese Änderung nicht nur die Wiki-Syntax, sondern auch das tatsächliche Aussehen des Textes. Ich würde das daher lieber wieder auf die vorige Schreibweise zurückstellen. Das macht aber wenig Sinn, wenn bei der nächsten Bearbeitung mit deinem Skript das wieder zurückgesetzt wird. Könntest du nicht dein Skript bitte so anpassen, dass bei solchen Syntaxformaten, bei denen hinter dem eigentlichen Link nicht nur Kleinbuchstaben folgen (Großbuchstaben und Ziffern haben anscheinend auch den Effekt des Linkabbruchs), keine automatische Ersetzung durchgeführt wird? Grüße --bjs 13:05, 12. Jun. 2018 (CEST)

Siehe hierzu meine Anmerkung zur Verlinkung und der Erkennbarkeit der tatsächlichen Linkziele.

VG --PerfektesChaos 14:16, 12. Jun. 2018 (CEST)

@TMg: Die Linkformatierung entfernt in vielen Fällen eine sinnvolle einheitliche Formatierung zusammenhängender Begriffe. Das ist für mich eine klare Verschlechterung. Beispieledit bei Eurofighter Typhoon. Statt "Eurofighter Jagdflugzeug GmbH" heißte es nun "Eurofighter Jagdflugzeug GmbH", als würde das "GmbH" nicht zum Namen gehören. Diese Linkmaskierung hatte jemand absichtlich so gesetzt um das sinnentnehmende Lesen zu erleichtern. Eurofighter Jagdflugzeug GmbH gibt es sogar als erwünschte Weiterleitung. Warum soll man das also nicht auch so verlinken. Im gleichen Artikel wurde "Litening III" in "Litening III" geändert. Das Linkziel ist ein Übersichtsartikel und die Linkbezeichnung ein Spezialfall innerhalb dessen. Durch die Maskierung wird es keineswegs zu undeutlich, auf welchen Artikel der Link zielt. Hier z. B. "Aero L-39 Albatros" vs. "Aero L-39 Albatros" und viele andere Beispiele des gleichen Benutzers. Das ist als Name zusammen zu lesen und folglich auch gemeinsam zu formatieren und zu maskieren. In zusammenhängenden Bezeichnungen sollte die Formatierung im Normalfall nicht wechseln. Bei vielen Namen gibt es unterschiedliche gebräuchliche Varianten, die alle legitim sind. Ein Zwang, nur noch die im Lemma benutzte Form als Link zu zeigen und damit aus der jeweiligen Gesamtbezeichnung herauszulösen, würde unsere internen Namenskonventionen höher hängen als es sich gehört. Die dienen nur dazu, unter den möglichen Lemmavarianten diejenige auszuwählen, unter der der Artikel erstellt wird. Sie beabsichtigen jedoch keine projektweite Sprachbereinigung, denn das ginge in Richtung unerwünschter Beeinflussung des allgemeinen Sprachgebrauchs und damit Theoriefindung. --Sitacuisses (Diskussion) 23:44, 30. Aug. 2018 (CEST)

Litening III ist leicht lösbar. Darüber hinaus kann ich den Beitrag so nicht ernst nehmen. Es gibt keinen „Zwang“, mein Tool zu verwenden. Die Funktion lässt sich abschalten. Den Nutzern meines Tools „Sprachbereinigung“ vorzuwerfen ist angesichts der Tatsache, dass der Text überhaupt nicht verändert wird, einfach nicht hinnehmbar. --TMg 15:39, 3. Sep. 2018 (CEST)

@TMg: Deine Reaktion ist bedauerlich. Es dir gelungen, den Kern meines Einwandes zu ignorieren, nämlich die einheitliche Formatierung zusammenhängender Begriffe. Stattdessen hast du überflüssigerweise gezeigt, dass Godwin’s law auch ohne lange Diskussionsvorlauf greifen kann. Ich erfinde nicht irgendwelche Dinge, die du nicht ernst nehmen müsstest, sondern schreibe über die praktischen Erfahrung mit einem Benutzer, der annahm, dass die Änderungen so richtig sein müssen, weil das Tool sie anbietet. Siehe dazu die vorausgehende Benutzerdiskussion. Um einen Grund zu haben die Funktion abzuschalten, muss man zunächst über ihre Fallstricke informiert sein. Opt-in wäre sinnvoller als Opt-out. --Sitacuisses (Diskussion) 07:53, 10. Sep. 2018 (CEST)

@TMg: Die Litening-Lösung geht aber weder bei Aero L-39 Albatros oder Eurofighter Jagdflugzeug GmbH noch bei dem mir eingangs genannten Guri-si, weil das Linkziel des gesamte Artikel und nicht ein bestimmter Abschnitt ist. Sitacuisses hat auch nicht von einem Zwang gesprochen, dein Tool zu verwenden, aber wenn dein Tool eine bestimmte Formatierung vorgibt und automatisch bei jedem kleinsten Edit umstzt, den irgendjemand, der es aktiviert hat, in dem Artikel vornimmt, ist es für einen Autor schon eine Art Kampf gegen Windmühlen, die ihm als geeignet scheinende Formatierung gegen blinden Automatismus zu verteidigen. Im Fall folgender Kleinbuchstaben ist diese automatische Linkersetzung ja immer sinnvoll (z.B. [[König|Königs]] zu [[König]]s), aber bei Trenn- oder Leerzeichen kann das Tool einfach nicht automatisch beurteilen, was besser ist. Grüße --bjs 18:54, 26. Sep. 2018 (CEST)

Hast du den Auto-Formatter je ausprobiert, oder wenigstens die Beschreibung gelesen? Er arbeitet nicht automatisch, nicht einmal halbautomatisch – genau aus den genannten Gründen. Wenn ein Benutzer das Tool blindlings auf komplette Artikel anwendet, ohne wenigstens den Diff zu kontrollieren, dann verwendet er es falsch und sollte darauf hingewiesen werden. --TMg 22:55, 27. Sep. 2018 (CEST)

About the changes that this script makes

Why does it replace <br/> with <br>, ref name=X/> with ref name=X />, etc., and put spaces in headings? Those are not really formatting errors but rather stylization choices.

Also, it replaces  -  (hyphen) with  –  (en dash) in citations; citations should match the original titles. Interqwark ^{talk contribs} 09:23, 14. Jun. 2018 (CEST)

I'm not really sure what the question here is. Wikitext is designed in a way so it always renders, which means there are not really "errors". Everything this script does can be classified as "stylization". Which is the reason why this is not part of the MediaWiki software or a bot, but a user script, and I ask every user to take full responsibility and carefully review and possibly revert every change this script makes. --TMg 15:52, 3. Sep. 2018 (CEST)

Italian Wikipedia

Hi, your tool is nice, but on Italian Wikipedia we don't use –, we use -, so replacing - with – causes problem (also with links) and it's not standard. Can you make a switch for that? Regards.--Ferdi2005 (Diskussion) 21:05, 22. Aug. 2019 (CEST)

@User:Ferdi2005: According to it:WP:MDS#Lineetta e trattino the Italian Wikipedia does use the long – dash. Can you please post a link to an example article where this script causes unwanted replacements? --TMg 12:40, 18. Feb. 2020 (CET)

IN EVERY CASE! It’s used only in particular cases, never in titles or in every other thing, I’ve never seen it in my wikipedian life. Do you understand what is in that page you linked? @TMg: —-Ferdi2005 (Diskussion) 18:34, 20. Feb. 2020 (CET)

I don't speak Italian, but the Goodle translation is good enough so I can understand it. The page specifically says that the long dash "can be used to separate two elements in titles, captions, or words", and even mentions an example for a title with a long dash: "Facoltà di ingegneria – Dipartimento di elettronica". There are at least 200,000 pages in the Italian Wikipedia that use the long dash as a separator. The page it:Lineetta even uses the very long dash, but my script doesn't touch this. I am going to repeat my question for the third time now: Please post a link to an example article where the script causes unwanted replacements. --TMg 17:57, 23. Feb. 2020 (CET)

Hi, sorry if I answer so lately. An example is easily found in Wikilinks, we don’t use long dashes in them: it: Inti-Illimani 4 - Hacia la libertad would be changed in it: Inti-Illimani 4 – Hacia la libertad and it would not work! I’m sorry if in my precedent messages I was a little bit rude, but I’m not really good at writing these type of messages in English :D This is not a big problem, though. Thanks again for your fantastic work with the autoFormatter.--Ferdi2005 (Diskussion) 14:32, 8. Dez. 2020 (CET)

Found! In Wikilinks: in this edit the tool would have changed Mostri contro alieni - Zucche mutanti venute dallo spazio in Mostri contro alieni – Zucche mutanti venute dallo spazio causing a red link if I had not manually fixed it, because in Italian Wikipedia we never use "–" in titles.--Ferdi2005 (Diskussion) 18:10, 15. Feb. 2021 (CET)

There is not much I can do about this, other than disabling this replacement on itwiki. Which is what I now did. Thanks for your patience! --TMg 18:00, 24. Sep. 2021 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 18:00, 24. Sep. 2021 (CEST)

MagicWords

Einige MagicWords enthalten einen Unterstrich, also beispielsweise {{LOKALES_JAHR}} . Der autoFormatter ersetzt dises "_" durch ein Blank - wodurch die MagicWords aber nicht mehr funktionieren. --Atamari (Diskussion) 20:19, 31. Jan. 2020 (CET)

Der Auto-Formatter sollte keinesfalls im Vorlagen-Namensraum verwendet werden, deshalb überrascht mich diese Anfrage etwas. In Artikeln sollten Magic-Words gar nicht vorkommen. Ich habe die Ersetzungsregel dennoch entschärft, um solchen Fehlersetzungen vorzubeugen. Danke für den Hinweis! --TMg 12:36, 18. Feb. 2020 (CET)

Dieser Abschnitt kann archiviert werden. TMg 12:36, 18. Feb. 2020 (CET)

autoFormatter not working on fennec aka firefox for android 68.6.0

@TMg: hello, i have copied and pasted code given at User:TMg/autoFormatter on meta:User:Leela52452/global.js.

unfortunately autoFormatter is not working. Leela52452 (Diskussion) 06:07, 30. Mär. 2020 (CEST)

What you did here looks correct. I don't know what went wrong. Was there a specific result you expected, but didn't got? --TMg 16:27, 6. Apr. 2020 (CEST)

honestly, i did not remember and most importantly i did not provided issue details, please close this issue. please excuse 14:06, 14. Apr. 2020 (CEST) any OTHER suggestion or critique is preferred here

converting Kategori: to Category: on trwiki ( Türkçe ), dawiki ( dansk )

hello @TMg: when i tap autoformatter icon it is converting Kategori: to Category: on Türkçe wiki. see this diff Leela52452 (Diskussion) 10:06, 18. Apr. 2020 (CEST) any OTHER suggestion or critique is preferred here

hello @TMg: the issue is also dansk wiki. see this edit diff Leela52452 (Diskussion) 08:38, 20. Apr. 2020 (CEST) any OTHER suggestion or critique is preferred here

Thanks a lot for the report. This was indeed a mistake. It's fixed now. --TMg 16:17, 5. Mai 2020 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 16:17, 5. Mai 2020 (CEST)

Lint errors

Hi @TMg:, Could you please configure mentioned lint errors for common.js

• Center <div style="text-align: center;">$1</div>
• Strike <del>$1</del>
• tt <code>$1</code>
• wikilink-in-extlink
• multi-colon-escape

ZI Jony ^(SWMT) 16:22, 27. Apr. 2020 (CEST)

Sorry, but no:

• <div style="text-align: center;"> is ugly and not better than <center>. In almost all cases it should either be removed, replaced with a template, or the text-align needs to be placed in a more appropriate position, e.g. as part of the table syntax. Neither of this should be done by a bot or fully automated script. Doing so makes the wikitext worse.
• Blindly replacing <strike> with <del> is almost certainly wrong. In some cases it might need to be <s>, sometimes CSS.
• There is half a dozen replacements for <tt>. Blindly replacing it with <code> is most certainly wrong.
• wikilink-in-extlink: I can think of at least two ways to fix this: either by removing the wikilink, or by ending the external link earlier. Which one is more appropriate must be decided by a human.
• multi-colon-escape: That's one I can add to my script.

--TMg 10:40, 4. Mai 2020 (CEST)

autoformatter: converting link between square brackets to bare hyperlink

@TMg: hello, it is converting link in square brackets of https://www.wattersgallery.com to bare hyperlink. please find diff. -28au21 (Diskussion) 06:19, 2. Sep. 2021 (CEST)

I'm afraid I don't understand. What's wrong? --TMg 16:03, 24. Sep. 2021 (CEST)

Not working

Hello. I've been using the script for a few months up until a few days ago where it stopped working, possibly due to the last edit you've made to the .js. Can you kindly fix it? --Minorax (Diskussion) 14:45, 25. Sep. 2021 (CEST)

Beta version works. Use it on your own risk. Please check always the changes. --Elutz (Diskussion) 16:53, 25. Sep. 2021 (CEST)

Same problem here, have been using it for years without problem. But now, it stopped working. When debugging it under Chrome, there is a JavaScript error in the function

cleanTypography: function( t ) {}

in the line

if ( !context.isIt ) {

• Uncaught ReferenceError: context is not defined.

Stacktrace

 index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:814 Uncaught ReferenceError: context is not defined
    at Object.cleanTypography (index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:814)
    at Object.cleanText (index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:218)
    at Object.cleanAll (index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:127)
    at Object.cleanElement (index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:103)
    at Object.click (index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:46)
    at Object.execute (index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript:1522)
    at Object.doAction (load.php?lang=de&modules=ext.wikiEditor&skin=vector&version=jb298:18)
    at HTMLAnchorElement.<anonymous> (load.php?lang=de&modules=ext.wikiEditor&skin=vector&version=jb298:20)
    at HTMLAnchorElement.dispatch (load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=1f752:formatted:2892)
    at HTMLAnchorElement.elemData.handle (load.php?lang=de&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=1f752:formatted:2779)

--S.K. (Diskussion) 17:50, 27. Sep. 2021 (CEST)

@TMg: After looking some more at it, I'd assume replacing the above line with

if ( this.lang != "it" ) {

should fix the problem.

--S.K. (Diskussion) 18:15, 27. Sep. 2021 (CEST)

BTW: Replacing the current import of autoFormatter with a link to the old version before the change solves the problem temporarily: mw.loader.load( '//de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js&oldid=203880929&action=raw&ctype=text/javascript' );

--S.K. (Diskussion) 18:39, 27. Sep. 2021 (CEST)

Whoops. Fixed. --TMg 13:29, 2. Okt. 2021 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 13:29, 2. Okt. 2021 (CEST)

ISSN in Vorlage

{{Cite journal |issn = 1046-2899}} an en.wikipedia.org wird: {{Cite journal |issn = 1046–2899}} AManWithNoPlan (Diskussion) 21:26, 21. Jan. 2022 (CET)

I will try to improve this. Thanks for the report! One ad-hoc solution is to write it as =1046-2899 without the space. This makes it more obvious that it's not regular text. --TMg 19:23, 7. Apr. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 20:35, 8. Apr. 2022 (CEST)

Typographieänderungen in Linktiteln (und Datumsformat in Tabellen)

Hallo TMg, in Titeln von Weblinks und von Werken sollten doch "falsche" Datumsformate und ähnliches nicht korrigiert werden. Wäre es möglich, dass du die Formatierung innerhalb eines Vorlagenparameters "titel=" aussetzt (Beispiel Ahmed Kamel)? Auch an manchen anderen Stellen, z.B. der Vorlage:Infobox Tennisturnierjahrgang (hier: Parameter Datum), ist ein "falsches" Datumsformat per Portalwunsch vorgesehen und eine "Korrektur" führt zu Gegenwehr. Für Tabellen ist es in Wikipedia:Datumskonventionen#Datumsangaben_in_Tabellen sogar explizit erlaubt, leider ersetzt dein Script da auch oft alles einfach. --androl ☖☗ 19:50, 6. Jun. 2022 (CEST)

Danke für die Meldung. Ich habe versucht, alle erwähnten Situationen zu entschärfen. Für weitere Beispiele bin ich sehr dankbar, sollten noch welche auftauchen. --TMg 18:20, 8. Sep. 2022 (CEST)

replacing: 233&659 with 233ʓ inside ref tag

it is replacing pp.232-233&659 with pp.232-233ʓ, please see diff Jindam vani (Diskussion) 18:25, 13. Aug. 2022 (CEST)

Oh, that shouldn't happen. Thanks a lot for the report. --TMg 18:18, 8. Sep. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 18:18, 8. Sep. 2022 (CEST)

Aktuelle Version funktioniert nicht, alte schon

Die aktuelle Version funktioniert nicht (Icon wird nicht angezeigt). Wenn ich mit mw.loader.load( '//de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js&oldid=221898737&action=raw&ctype=text/javascript' ); die vorige Version lade, klappt es. --S.K. (Diskussion) 22:17, 11. Sep. 2022 (CEST)

Hi bei mir funktioniert es. eingebunden als

mw.loader.load("//de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript");

gruss, --Wetterwolke (Diskussion) 16:27, 12. Sep. 2022 (CEST)

Okay. :-( Bei mir mit importScript('Benutzer:TMg/autoFormatter.js'); nicht. Das ging vorher ohne Probleme. --S.K. (Diskussion) 18:07, 12. Sep. 2022 (CEST)

importSript ist wohl veraltet auch wenn es noch funktiniert hat. vielleicht hilft dir auch Wikipedia:Technik/Skin/JS#Laden anderer Skripte. Gruss, --Wetterwolke (Diskussion) 16:39, 14. Sep. 2022 (CEST)

Das war es nicht. Egal ob importScript oder mw.loader.load beides funktioniert nicht. Mit der Vorversion geht es problemlos. --S.K. (Diskussion) 21:11, 14. Sep. 2022 (CEST)

@S.K.: Ich kann den Fehler in den aktuellen Chrome und Firefox leider nicht nachvollziehen. Aber der Beitrag von Jindam vani unten gibt einen Hinweis. Ich hab mal was versucht. Geht es jetzt wieder?

Tipp: Es ist möglich, durch Anhängen von mw.loader.load( '//de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js&action=raw&ctype=text/javascript&oldid=221898737' ); vorübergehend zu einer älteren Version zurück zu wechseln. --TMg 06:28, 15. Sep. 2022 (CEST)

Mit der aktuellen Version funktioniert es wieder mit Safari als Browser. Danke! --S.K. (Diskussion) 18:41, 15. Sep. 2022 (CEST)

not working on palemoon 31.2.0.1 (armhf)

it was working fine few days back. it is not working on palemoon browser (architecture:armhf). please look into it. Jindam vani (Diskussion) 03:57, 15. Sep. 2022 (CEST)

hello Benutzer:TMg visited http://maettig.com/wikipedia/autoFormatter-test.html debug info Jindam vani (Diskussion) 04:15, 15. Sep. 2022 (CEST)

Error: SyntaxError: invalid regexp group
Source File: https://de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js/Beta.js&action=raw&ctype=text/javascript
Line: 314, Column: 4
Source Code: /&#*(x([\dA-F]{2,})|((?<=#)\d{3,})|[a-z]{2,9}\d{0,2}\b)(?![\
Error: TypeError: mediaWiki.libs is undefined
Source File: http://maettig.com/wikipedia/autoFormatter-test-runner.js
Line: 1

hello Benutzer:TMg just few hours back everything is back 2 normal. its working now. -Jindam vani (Diskussion) 08:11, 16. Sep. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 12:23, 4. Okt. 2022 (CEST)

Can you make an automated edit summary?

@TMg, can you make an automated edit summary when your autoFormatter is used on English wikipedia somewhere on the lines of: "Cleaned up using autoFormatter."? Cheers, Qwerty284651 (Diskussion) 02:22, 4. Okt. 2022 (CEST)

We discussed this a long time ago, see #Fork above. My argument still holds: This is not a bot and shouldn't be used as such. My script is meant to be used along regular, meaningful edits. The summary line should reflect that edit. --TMg 12:17, 4. Okt. 2022 (CEST)

So, is the summary line: "Cleaned up using autoFormatter" adequate, or not? Qwerty284651 (Diskussion) 14:43, 4. Okt. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 12:17, 4. Okt. 2022 (CEST)

image disappeared

it is rendering code only, instead of image. please see commit which image lost the code is bad, if possible please look into it. Jindam vani (Diskussion) 16:18, 15. Okt. 2022 (CEST)

@Benutzer:TMg i copy pasted above image code from en:Greenhouse gas emissions Jindam vani (Diskussion) 06:37, 16. Okt. 2022 (CEST)

Fixed. Thanks, and sorry for the delay! --TMg 13:38, 5. Jun. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 13:38, 5. Jun. 2023 (CEST)

Clarify spaces in Section Headings

Hi, love the script but just wanted to check on adding spaces to section headings since as far as I can see, in the English Method of Style the headings all have no spaces between the text and "=" --Mesidast (Diskussion) 12:13, 17. Okt. 2022 (CEST)

I know English Wikipedia users often remove these spaces. But it looks like the English MOS doesn't say anything about them. Most wikis agree on having them. They makes the wikitext quite a bit more readable. --TMg 13:48, 5. Jun. 2023 (CEST)

not deleting period after category Orthodox Judaism

diff is not deleting period or full stop after Orthodox Judaism. it is bringing it to bottom. <_> Jindam vani (Diskussion) 15:57, 17. Okt. 2022 (CEST)

The dot is misplaced there, but the script can't know why. I think this must be fixed by a user. --TMg 13:50, 5. Jun. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 13:50, 5. Jun. 2023 (CEST)

removing or editing incorrectly? in en:Template:Infobox settlement

@TMg: diff please notice that shortening of wp link (probably ok), however it also removed ref tags in comments. code copy pasted from en:Botushë. can you please look into it? <_> Jindam vani (Diskussion) 10:20, 27. Dez. 2022 (CET)

As this tag is empty it won't do anything and is removed because of this. I suggest to make it say <ref>…</ref> in the relevant templates. --TMg 14:13, 5. Jun. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. TMg 14:13, 5. Jun. 2023 (CEST)

option to install as tampermonkey script

@TMg Hi, can you please convert this to tampermonkey or greasemonkey. --2401:4900:62E9:ACB2:FFAD:E019:F68E:CAD9 10:59, 16. Mai 2023 (CEST)

I don't really have the capacity to maintain another version of my script, sorry. --TMg 17:15, 17. Jan. 2024 (CET)

Dieser Abschnitt kann archiviert werden. TMg 17:15, 17. Jan. 2024 (CET)

added ‎, date changed incorrectly

added ‎, changed date: Date: 11.10.2016 to Date: 11. అక్టోబరు 2016. diff --హరుడు (Diskussion) 15:52, 9. Jun. 2023 (CEST)

hello Benutzer:TMg again, i am bit wrong about date format ( perhaps? ). i tracked down guidelines aka mos for dates, te wiki follows YMD, see: mos [ date ]. confirmed with my mentor: clarification. the situation seems to be tricky. if we change to YMD, it will be violation of mos. if only month name is replaced, it raises several doubts or looks wrong. as of now, please consider to format by removing periods from 11.10.2016 to 11 అక్టోబరు 2016. thank you. --హరుడు (Diskussion) 11:08, 24. Jun. 2023 (CEST)

Thanks for the patience. I see it's indeed complicated. I removed the dot in your language. I hope this helps. The invisible left-to-right mark was already there. My script just made it visible. --TMg 17:12, 17. Jan. 2024 (CET)

Commonscat-Verweise und Ähnliches ausschließen?

Hallo TMg, vielen Dank für das tolle Werkzeug! Gibt es eine Möglichkeit, den Inhalt von Commonscat-Vorlagen u. Ä. von der Auto-Formaterung auszuschließen? Der AutoFormatter hat bei mir schon ein paar mal die Inhalte von Vorlage:Commonscat, Vorlage:Wikisource, Vorlage:Wikibooks u. Ä. "zerschossen", indem Minusse in Halbgeviertstriche, typographisch falsche in typographisch richtige Anführungszeichen umgewandelt werden, obwohl die Commons-Kategorie bzw. die Wikisource-Seite das typographisch falsche Lemma haben. Natürlich kontrolliere ich die Änderungen des AutoFormatters vor dem Abspeichern nochmal, aber manchmal rutscht es eben durch. Könnte man Änderungen innerhalb dieser Vorlagen grundsätzlich unterbinden? Viele Grüße, DerMaxdorfer (Diskussion) 10:57, 3. Jul. 2023 (CEST)

Unknown parameters

Hi, I saw that the gadget can replace or delete parameters from templates. I was wondering, would it be possible instead to set a list of parameters and have it remove those that are not in the list? Basically to clean up the template of any unknown parameters. --GryffindorD (Diskussion) 16:14, 9. Aug. 2023 (CEST)

There are currently no plans to add such a feature, sorry. It would be very prone to errors, I'm afraid. For example, some templates have parameters that are intentionally not documented via TemplateData. How should my script know such things? --TMg 16:40, 17. Jan. 2024 (CET)

Dieser Abschnitt kann archiviert werden. TMg 16:40, 17. Jan. 2024 (CET)

Decoding ndash and mdash

Depending on the font (and depending on one's visual acuity), it can be difficult to tell the difference between -, –, and —. Unless you can cite a guideline that discourages the use of mdash and ndash for coding clarity, please do not "decode" them in this script. "Manually" re-coding them is significantly more difficult than running this script. Scripts should not make unhelpful practices easier.

The same argument could be made for other character entity references, but I'm not concerned with that at this time; any improvement is an improvement. Thank you. Mandruss (Diskussion) 17:39, 30. Apr. 2024 (CEST)