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.&nbsp;h.
• u.a. bzw. u. a. → u.&nbsp;a.
• z.B. bzw. z. B. → z.&nbsp;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)

Geschützte Leerzeichen bei Währungsangaben

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wikilinks

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

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

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

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

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

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

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

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

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 />.
• 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>
• 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.

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

Entfernen von Leerzeichen am Anfang/Ende von Links

Überflüssige Leerzeichen am Anfang und Ende von Wikilinks könnten entfernt werden: [[ Link]], [[Link ]], [[ Link ]] und natürlich auch mehrfache Leerzeichen --> [[Link]]. Ein schönes Restwochenende wünscht, --BlueCücü (Diskussion) 20:13, 31. Aug. 2013 (CEST)

Wurde schon einige male angesprochen, siehe u. a. #Wikilinks oben. Ist leider nicht so einfach. Steht aber weiterhin auf meiner Merkliste. --TMg 22:06, 1. Sep. 2013 (CEST)

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)

Suggestion for enwp

Just a suggestion, change the following: {{Main|*****}} {{Main|#####}} to {{Main|*****|#####}} --Josve05a (Diskussion) 16:16, 21. 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)

Checkwiki Fehler 16

Moin TMg! Lang nicht gesprochen. Vielleicht wir sehen uns in Hackathon dieses Jahr? Waere es moeglich dass du in deine Auto-Formatter Liste von Unicode charactern (CHECKWIKI Fehler) #16 \u202A|\u202C addierst bitte? D.h. AutoFormatter zu korrigieren alle 6 invisible Unicode character. (Du kannst mein Deutsch korrigieren!) -- Magioladitis (Diskussion) 13:46, 17. Jan. 2014 (CET)

Magioladitis, thank you very much for the hint. Currently these two characters aren't in the code on GitHub. Is this still to come? Here is an overview according to my script and my opinion:

• U+200B (ZERO WIDTH SPACE): It's a valid character in some languages to mark a possible break in article titles that are composites of connected words. Similar to ­ but without becoming a dash. I do remove it when I'm sure it's misplaced: from line endings and if it's between two Latin characters (range U+0000–U+024F). This is my own conclusion. I can't prove this is fail-proof.
• U+200E (LRM): I remove it if I'm sure it's misplaced: if it's in front of a closing ] or next to a left-to-right character (see my code for the range). All remaining are made visible as ‎.
• U+2028 (LINE SEPARATOR): I have the feeling it can be removed. It's most probably a mistake and completely useless in wikitext. It doesn't do anything in Firefox and IE. Opera turns it into a space.
• U+202A (LRE) and U+202C (PDF): Not sure. Replace it as recommended?
• U+FEFF (BOM): I remove it with no exceptions.

--TMg 19:59, 17. Jan. 2014 (CET)

Satzbau war richtig :) -- Magioladitis (Diskussion) 14:50, 18. Jan. 2014 (CET)

Nicht ganz. ;-) Aber problemlos zu verstehen. Ich freue mich auf ein Wiedersehen beim Hackathon. --TMg 15:12, 18. Jan. 2014 (CET)

Ich hoffe wir treffen uns beim Hachathon dieses Jahr auch! -- Magioladitis (Diskussion) 00:32, 3. Jan. 2015 (CET)

Bindestrich in Linktext

Ist das so (aus [[Assistenzstelle|Assistenz-]] wird [[Assistenzstelle|Assistenz]]-) gewollt? --Seth Cohen 22:47, 18. Mär. 2014 (CET)

Genau das wollte ich gerade auch anmerken. Da der ganze Begriff inklusive dem ausgelassenen Teilwort verlinkt gehört, muss der Auslassungsstrich klar in der Klammer bleiben. --androl ☖☗ 17:40, 24. Mär. 2014 (CET)

Tut mir leid, aber den Strich in den Link hinein zu ziehen, ist typografisch nicht korrekt. Der Grund wird am ehesten klar, wenn man die Link-Unterstreichungen aktiviert hat. Beispiel: Assistenz-Stelle. --TMg 22:32, 27. Mär. 2014 (CET)

Ah, ich verstehe, wir reden über verschiedene Dinge. In Assistenz-Stelle muss der Bindestrich natürlich draußen bleiben, in Assistenz- und Oberärzte muss er dagegen in die Verlinkung. --androl ☖☗ 16:14, 28. Mär. 2014 (CET)

Es gibt eigentlich keinen Grund, die beiden Fällen unterschiedlich zu handhaben. Assistenz- und Oberärzte ist typografisch ebenso inkorrekt. Satzzeichen unterstreicht man nicht mit. --TMg 00:01, 29. Mär. 2014 (CET)

Den typografischen Aspekt hatte ich außer Acht gelassen. --Seth Cohen 15:58, 3. Apr. 2014 (CEST)

Gibt es denn die Möglichkeit die korrekte Verlinkung dem typografischen Aspekt vorzuziehen, also diese Funktion zu deaktivieren? --Hadibe (Diskussion) 18:03, 22. Aug. 2015 (CEST)

Was meinst du denn mit „korrekt“? Wie schon gesagt, Satzzeichen in Formatierungen hinein zu ziehen ist in den seltensten Fällen korrekt; bei Unterstreichungen in jedem Fall falsch. Ich biete gern Optionen an, wenn das dabei hilft, die Akzeptanz dieses Skripts und seiner Ersetzungsregeln zu erhöhen. Das scheint mir in diesem Fall jedoch nicht gerechtfertigt. Warum eine Regel abschaltbar machen, wenn es vom nächsten Benutzer dann doch korrigiert wird? --TMg 12:16, 22. Sep. 2015 (CEST)

Ok, ich habe die Regel ein wenig entschärft. Bindestriche am Ende von Links bleiben jetzt unangetastet, wenn dahinter eine Leerstelle folgt. Links wie [[Berlin|Berlin-]] werden trotzdem noch korrigiert, weil das tatsächliche Linkziel ja nicht „Berlin-Irgendwas“ lautet sondern nur „Berlin“ und das auch so erkennbar sein sollte. --TMg 10:25, 24. Sep. 2015 (CEST)

Vielen Dank! @Seth Cohen, Androl, Hadibe: Die beiden Suchen nach insource:/\|[a-z\- ]+\]\]\-\, /i bzw. insource:/\|[a-z\- ]+\]\]\- und /i liefern leider zu viele Treffer, als dass man diese händisch nach Fällen wie im Beispiel ganz oben durchgehen könnte. Vielleicht könnte man die Treffer noch etwas weiter eingrenzen. Nur weiss ich gerade nicht wie. --Leyo 17:30, 29. Nov. 2015 (CET)

Leerzeichen zu Beginn des Alternativtextes von Wikilinks

Klick. [[Thomas_Hillenkamp| Thomas Hillenkamp]] wird nicht zu [[Thomas Hillenkamp]]. --Seth Cohen 16:03, 3. Apr. 2014 (CEST)

Als Wunsch verstehe ich das und werde versuchen, das aufzunehmen. Im Moment ist das Absicht, weil sonst Konstellationen in diesem Beispiel zuBeispiel werden würden. --TMg 02:50, 12. Apr. 2014 (CEST)

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)

Dates

Script makes change in 0123—0123 years "[[КХЛ в сезоне 2012—2013|2012-13]]"->"[[КХЛ в сезоне 2012–2013|2012–13]]" (try on this [2]). Сharacter "—" should not be replaced. Can you fix this? Or how can I change my .js to disable it is this change? --Сунприат (Diskussion) 11:48, 29. Jan. 2015 (CET)

The reason for this behavior is that I build the script with the German and English style guides in mind. I didn't know the Russian one is different. Thanks a lot for letting me know. I will fix this. --TMg 18:15, 4. Feb. 2015 (CET)

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)

Checkwiki changes

New:

• Error 102. Checks for correct syntax of PMID

Changes:

• Error 69: Now finds cases of ISBN in a wikilink ( [[ISBN]] 978-12345-6789-0) and # symbol (ISBN #978-12345-6789-0)
• Error 2: Checks for <center/>, <small/> and <br clear
• Error 85: Checks for <center></center> and <gallery></gallery>
• Error 34: Catches more cases. See Instances of 'subst:' in articles

Bgwhite (Diskussion) 22:32, 2. Feb. 2015 (CET)

Cool. Thanks for letting me know! --TMg 18:31, 4. Feb. 2015 (CET)

Weitere Optionen

Hallo TMg. Ich verwende den autoFormatter, nachdem ich andere, ähnliche Skripts ausprobiert und für mässig tauglich befunden habe, schon lange, und zwar bei fast jedem ANR-Edit. Also erstmal vielen Dank für das tolle Tool! Zwei Ersetzungen stören mich allerdings regelmässig. Ich persönlich mag keine nbsps, weil ich ihren praktischen Nutzen nicht sehe und sie den Quelltext unleserlich machen - und häufig auch die Diffs, weil das Skript in manchen Artikeln in fast jeder Zeile ein solches geschütztes Leerzeichen einfügen will, so dass die eigentlichen Änderungen untergehen. Und Ersetzungen von Links nach dem Schema [[XYZ|XYZ 123]] -> [[XYZ]] 123 sind mir in aller Regel zu heikel, um sie mal eben nebenbei durchzuführen. Letzteres liesse sich wohl durch die Option autoFormatMaskedLinks = false vermeiden, dann würde ich aber auch alle (meiner Ansicht nach sinnvollen) Korrekturen nach dem Muster [[XYZ|XYZs]] -> [[XYZ]]s verlieren, und die überwiegen klar. Für die geschützten Leerzeichen gibt es gar keine Option. Ich fände es also schön, wenn diese beiden Änderungen ein Opt-out anbieten würden. Verstümmeln brauchst du dein Skript dafür natürlich nicht, aber wenn es machbar wäre, wäre ich froh. --YMS (Diskussion) 09:50, 5. Feb. 2015 (CET)

• autoFormatMaskedLinks tut, was du möchtest. Ich hab es auf der Vorderseite genauer beschrieben.
• Bei geschützten Leerzeichen meine ich, sehr zurückhaltend zu sein, weil ich die Lesbarkeit des Quelltextes ebenfalls als sehr wichtig einschätze. Ich entferne sie in vielen Fällen sogar, u. a. in Überschriften und teils in Lebensdaten und zwischen Monaten und Jahren. Ich setze sie nur ein, wo mir der Nutzen signifikant erscheint, weil die an den Zeilenenden auseinander gerissenen Fragmente sonst keinen Sinn mehr ergeben: Bei „§ 1“ und bei „1 m“. Das war es eigentlich. Ich vermute, die spielst auf die Maßeinheiten an? Ich könnte mir vorstellen, diese Regel zu verfeinern und z. B. bestimmte längere Einheiten raus zu nehmen oder die Länge der Zahl davor zu berücksichtigen. Hast du Vorschläge oder ein Beispiel, das dich besonders nervte?

--TMg 15:54, 5. Feb. 2015 (CET)

Danke für die autoFormatMaskedLinks-Info/Doku-Klarstellung. Ich hatte (vermutlich schon öfter) sogar im Code nachgeschaut, aber offensichtlich zu flüchtig und dann übersehen, dass im else-Fall ja trotzdem noch was gemacht wird.

Und für die geschützten Leerzeichen kann ich dir leider kein besonderes Beispiel präsentieren. Wäre aber möglich, dass mich das eine oder andere Mal auch die Entfernung derselben gestört hat. Während die bei Prozentzeichen und in Überschriften wohl auch für mich immer okay ist, würde ich vermutlich auch eine Änderung wie "14.&nbsp;Dezember&nbsp;1911 -> 14.&nbsp;Dezember 1911" nicht abspeichern wollen (weil sie mir erstens unvollständig erscheint und ich zweitens nicht demjenigen ins Handwerk pfuschen will, der diese Leerzeichen da für angebracht hält).

Aber vielleicht bin ich mit der deaktivierten autoFormatMaskedLinks-Optionen ja bereits glücklich. --YMS (Diskussion) 16:12, 5. Feb. 2015 (CET)

Ich bin sehr an jeder Anregung interessiert, die die Zufriedenheit der Benutzer mit meinem Skript und dem, was es tut, steigert. Regeln, die mit geschützten Leerzeichen hantieren, hab ich aber mehrere, und ich möchte keinen Schalter einbauen, der alle einfach abschaltet. Achte mal darauf, welche Art von Ersetzung die für dich nervigste ist und zeig mir ein oder zwei Beispiele dafür (idealerweise mit Permanentlinks), dann überleg ich mir was. --TMg 16:55, 5. Feb. 2015 (CET)

Ich hab' meine Edits nun mal einige Zeit beobachtet, und bin zu dem Ergebnis gekommen, dass mich alle nbsp-Einfügungen stören. Musst du aber nichts gegen tun, zumal ich ohnehin plane, in Zukunft verstärkt den Visual Editor einzusetzen. --YMS (Diskussion) 16:37, 5. Mai 2015 (CEST)

Danke. Dennoch: Ich nehme das durchaus ernst und werde mir was überlegen. Schritt 1: Alle nbsp-Regeln kritisch prüfen.

• In § 1 A. 1 S. 1 werden schlimmstenfalls 3 nbsp eingefügt. Das ist vielleicht unnötig viel und könnte z. B. die Länge der Zahlen berücksichtigen (z. B. nur bei 1 und 2-stelligen Zahlen).
• Bei Dateigrößen erachte ich die nbsp als wichtig, unabhängig von der Länge der Zahl.
• Auch von den Entfernungen bin ich überzeugt, sonst hätte ich es nie gewagt, sie aufzunehmen.
• Bei den Maßeinheiten könnte ich weitere raus werfen (ich denke da in erster Linie an die 3-buchstabigen Währungskürzel EUR usw.) sowie die Länge der Zahl berücksichtigen (z. B. nur bei max. 3-stelligen Zahlen, „1000 m“ bliebe also unangetastet).

Schritt 2: Einen Schalter zum Abschalten aller nbsp-Regeln einbauen. --TMg 16:34, 6. Mai 2015 (CEST)

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)

Links einkürzen

Das Einkürzen der Wikilinks funktioniert im Skript nicht, wenn sich die Links durch Groß- und Kleinschreibung unterscheiden. Beispiel: [[Alkoholische Gärung|alkoholische Gärung]] in Alkoholersterwerbsalter. --Hadibe (Diskussion) 04:11, 6. Apr. 2015 (CEST)

Ebenso bei führendem oder angehängtem Whitespace, Beispiel [[Begabung| Begabungen]]. --YMS (Diskussion) 18:21, 7. Apr. 2015 (CEST)

Danke, solche Beispiele sind ungemein hilfreich. Der Fall mit dem kleinen Anfangsbuchstaben ist interessant, aber leider nicht generalisierbar, da es Wikis gibt, in denen die Großschreibung signifikant ist. Ich denke, ich werde das nicht aufnehmen können, wenn mein Skript in solchen Wikis nutzbar bleiben soll. Der Fall mit den Leerzeichen steht bereits auf meiner Agenda. --TMg 16:14, 6. Mai 2015 (CEST)

Unerwünschtes Leerzeichen vor Prozentzeichen in Style-Attribut

Siehe <div style="padding:5% 0 10% 0;">. --Seth Cohen 23:19, 4. Mai 2015 (CEST)

Faszinierend. Danke. Dass derartiges HTML nichts in Artikeln verloren hat, darin sind wir uns denke ich einig. Unabhängig davon ein sehr hilfreiches Beispiel zur Verbesserung meines Skripts. Ich schau mal, ob mir was dazu einfällt. --TMg 16:17, 6. Mai 2015 (CEST)

Merkliste 2015

• Bis-Strich in |Seiten=49-50.
• Alternativtext entfernen, wenn er mit der Bildbeschriftung identisch ist (Beispiel).
• <small> auch um mehrere <ref> entfernen.

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.

--TMg 14:12, 22. Mai 2015 (CEST)

Hochgestellte Ziffern

Hallo TMg,
hier wird das Verhalten bei hochgestellten Ziffern kritisiert. Kannst Du mal schauen, ob Du das berücksichtigen kannst?
Gruß --Baumfreund-FFM (Diskussion) 20:12, 17. Aug. 2015 (CEST)

Das Problem tauchte bereits einige Male auf und inzwischen berücksichtigt das Skript alles, was zu berücksichtigen ist, und lässt hoch- und tiefgestellte Ziffern in chemischen Formeln unangetastet. Maßeinheiten wie km² und m³ schreibt man aber nun mal so. Dafür sind die Unicodezeichen da. Unschönheiten in der Darstellung von Unicodezeichen sind generell ein Problem der Schriftart auf dem jeweiligen Endgerät. Mit einer anderen Schriftart oder schlimmstenfalls einem Update des Betriebssystems wird dieses Problem verschwinden. Umgekehrt bedeutet die Verwendung von m<sup>2</sup>, dass der Wikitext für alle Benutzer unleserlicher und vor allem ganz extrem fehleranfälliger wird, und dass die Darstellung dafür auf anderen Endgeräten unschön aussieht. Man versucht sozusagen, den Teufel mit dem Beelzebub auszutreiben. Das funktioniert nicht, das könnt ihr jemandem, der 20 Jahre HTML- und 10 Jahre Wikitext-Erfahrung hat, glauben. Die ² und die ³ sind auf den meisten Tastaturen erreichbar und sie werden hier in diversen Formatierungs- und Sonderzeichen-Leisten genau so angeboten, nicht via <sup>. --TMg 13:20, 22. Sep. 2015 (CEST)

Danke für die Erläuterung. --Baumfreund-FFM (Diskussion) 12:10, 24. Sep. 2015 (CEST)

Wikipedia:Schreibweise von Zahlen#Exponentialdarstellung gilt auch für dich. Falls du damit nicht einverstanden bist, so sprich dies bitte auf der dortigen Disk. an. --Leyo 12:23, 24. Sep. 2015 (CEST)

Siehe die etwas differenziertere Bemerkung bei Hilfe:Sonderzeichen #Mathematische Zeichen.

• Steht dort inhaltlich/sinngemäß unverändert und unangefochten seit inzwischen mehr als zehn Jahren.

Wird in Hunderttausenden von Artikeln auch so praktiziert; vielleicht in einer Million Artikel – Cirrus streikt schon.

Es wäre also eher WP:SVZ zu konkretisieren.

• Nebenbei ist es Unsinn, den middot noch von zwei nbsp zu umschließen. Der schafft sich seinen notwendigen Raum in 5·10¹²³ schon selbst.

LG --PerfektesChaos 12:54, 24. Sep. 2015 (CEST)

Bitte nicht in diesem Ton, Leyo. Das Skript rührt Exponentialdarstellungen und Potenzen nicht an. Es bringt ausschließlich die Maßeinheiten mm², cm², m², km² sowie mm³, cm³, m³ und km³ in die einheitliche, wie von PerfektesChaos dargelegt seit mehr als 10 Jahren hier und überall sonst im Web so übliche Form. Ich bin gern bereit, über die Auswahl dieser Maßeinheiten zu diskutieren und einzelne zu entfernen, die im Hausgebrauch weniger üblich sind und für die das Argument „offenkundig und vertraut“ nicht gilt. --TMg 16:48, 24. Sep. 2015 (CEST)

Den Ton halte ich nicht für zu scharf, solange dein Script gegen Wikipedia:Schreibweise von Zahlen#Exponentialdarstellung verstösst (genanntes Beispiel). --Leyo 12:34, 27. Nov. 2015 (CET)

Da verstößt nichts. Lies die Regelseite bitte selbst noch einmal und zeige die Stelle auf, an der dort vom Maßeinheiten die Rede ist. --TMg 16:01, 27. Nov. 2015 (CET)

Dieser Abschnitt kann archiviert werden. TMg 16:01, 27. Nov. 2015 (CET)

Vorlage:BAnz

Hallo TMg,
der autoFormatter formatiert auch in der Vorlage das Datum um und erzeugt damit einen Vorlagenfehler (Beispiel).
Kannst Du da was machen?
Gruß --Baumfreund-FFM (Diskussion) 19:12, 28. Okt. 2015 (CET)

Leider nein, da der Inhalt dieser Vorlage wie ganz normaler Fließtext aussieht. Einen Schutz, der bestimmte Vorlagen ganz ausnimmt, habe ich bisher nicht. --TMg 09:39, 27. Nov. 2015 (CET)

Danke fürs nachschauen.

Schade, dann muss ich mal schauen, wie ich damit klar komme.

Gruß --Baumfreund-FFM (Diskussion) 06:16, 30. Nov. 2015 (CET)

Merkliste 2016

• LRM am Textende entfernen.

--TMg 17:34, 4. Feb. 2016 (CET)

Lokalisierungen schweizbezogen und österreichbezogen

Siehe WP:Schweizbezogen und WP:Österreichbezogen. Das Helferlein Wikipedia:Helferlein/Rechtschreibprüfung beachtet «schweizbezogen», und „österreichbezogen“ (Prüfung auf einfaches Vorkommen des Strings, daher funktioniert das sowohl bei Vorlagen als auch html-Kommentar. AutoFormatter ist bei «schweizbezogen» vor allem bei den Anführungszeichen betroffen, bei österreichbezogen beim expandieren von Kurzdatum in Langform beim Monat Jänner. (Die Verwendung von Hochkomma als Tausendertrennzeichen bei schweizbezogen müsste man vor der Umsetzung überprüfen, ob das anderwertige Probleme zur Folge hätte (z.B. Nicht-Erkennung von Zahlen innerhalb von Vorlagen))  Frohes Schaffen — Boshomi ☕⌨☺   23:08, 26. Feb. 2016 (CET)

Danke für den Hinweis, damit hatte ich mich bisher noch nie beschäftigt. Ich habe Testfälle und den Jänner hinzugefügt. Weitere Fehler konnte ich nicht finden. Mit Tausendertrennzeichen mache ich nichts. Ob ich in schweizbezogenen Artikeln ungefragt die "geraden Anführungszeichen von der Tastatur" durch «spitze» ersetzen sollte, da bin ich mir noch unsicher. --TMg 13:50, 29. Feb. 2016 (CET)

Bei den Guillemets könnte man prüfen, ob so ein Klammernpaar schon vorkommt, und das nur solchen Artikeln ersetzen, wo das der Fall ist. Damit wird zumindest der Artikel einheitlich. Frohes Schaffen — Boshomi ☕⌨☺   11:58, 2. Mär. 2016 (CET)

Danke, die Idee gefällt mir wirklich gut. --TMg 12:46, 3. Mär. 2016 (CET)

Bitte bei österreichbezogen und schweizbezogen nur auf den string /österreichbezogen/i und /schweizbezogen/i prüfen, die Klammern, html-kommentarzeichen,... einfach ignorieren, denn so funktioniert auch Appers Rechtscheibhelferlein (weshalb die Umstellung von österreichbezogen auf die Vorlage technisch kein Problem war). Frohes Schaffen — Boshomi ☕⌨☺   16:31, 3. Mär. 2016 (CET)

nochmal nachgedacht: besser wäre es vielleich die Zeichen zu prüfen „“ ’ ‚‘ “” ‘’ und wenn diese vorhanden sind, werden diese auch bei Schweizbezogen weiterverwendent, kommen sie noch nicht vor werden «» als Standard für Schweizbezogen genommen. Frohes Schaffen — Boshomi ☕⌨☺   12:09, 14. Mär. 2016 (CET)

Ich habe inzwischen genug Testfälle gesammelt, die zeigen, dass es tatsächlich sinnvoll ist, nur auf die Wörter zu prüfen. Zur Prüfung verwende ich nur die öffnenden „ und « und halte das für ausreichend. Schließlich macht mein Skript ja nichts mit englischen (die bleiben gerade) oder einfachen Anführungszeichen. Ich baue das aber gern weiter aus, wenn konkrete Fälle auftauchen, in denen meine aktuelle Logik nicht ausreichend ist. --TMg 10:17, 17. Mär. 2016 (CET)

Dieser Abschnitt kann archiviert werden. TMg 10:17, 17. Mär. 2016 (CET)

Wikisource-Links

Hallo. Wikisource-Links sollten lieber nicht angetastet werden. Hier ein Beispiel. Ist wahrscheinlich ähnlich wie weiter oben schonmal bei den CommonsLinks angemerkt. Oder ließe sich da was machen? Grüße, --BlueCücü (Diskussion) 18:27, 3. Mär. 2016 (CET)

Ich versteh leider nicht, was du meinst. In dem Artikel finden nach deinem Edit gar keine Ersetzungen mehr statt, und auch in deinem Edit sehe ich nichts, was falsch wäre. „Wikisource“ wird als Eigenname groß geschrieben. Meinst du das? --TMg 17:46, 4. Mär. 2016 (CET)

Das Apostroph im WikisourceLink wird geändert. Dell'arte --> Dell’arte. (War lange nicht aktiv. Vielleicht liegts auch an meinen privaten Einstellungen, die ich dann mal überdenken sollte.) --BlueCücü (Diskussion) 22:14, 4. Mär. 2016 (CET)

Ja, das kommt aus deiner common.js. --TMg 14:56, 6. Mär. 2016 (CET)

Danke fürs Nachschauen. --BlueCücü (Diskussion) 08:28, 19. Mär. 2016 (CET)

Dieser Abschnitt kann archiviert werden. TMg 14:56, 6. Mär. 2016 (CET)

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)

(BK) Hallo TMg, danke auch für die Nachricht. Bei deinem Skript (egal ob ich es anwende oder andere), stolpere ich immer wieder über die folgenden Probleme:

• In Parametern, die links auf Commons darstellen, werden regelmäßig der Bindestrich ersetzt und typographische Hochkommata eingefügt. Das erzeugt dann einen dangling iw-Link. Gibt es dafür eine Konfiguration oder ließe sich eine schaffen, die bestimmte Vorlagenparameter wörtlich nimmt und nicht modifiziert? Per Vorlagenparameter und Infobox? Analog zu autoFormatTemplates. Irgendwo würde es dann vielleicht noch eine zentrale Stelle brauchen, die für alle VerwenderInnen deines Skripts gilt (ist ja nicht anwendungs-, sondern infoboxspezifisch).
• In der {{Denkmalliste Österreich Tabellenzeile}} wird der Parameter Name 1:1 aus unserer Quelle entnommen und jährlich beim Update auf neue Daten 1:1 textuell verglichen. Alle Veränderungen an Name sind daher kontraproduktiv. Natürlich könnte Krd den Vergleich smarter machen, … Aber man könnte das auch mit dem obigen Mechanismus erschlagen. Was meinst du? Name in {{Denkmalliste Österreich Tabellenzeile}} ist jetzt nur ein Beispiel, es könnten auch andere Stellen/UserInnen Stringvergleiche machen, die nach solchen Ersetzungen schief gehen. Dazu kenne ich die individuelle Arbeitsweise bei vielen Updates nicht (WLPA, WLE, …)
• Unnötig finde ich, dass bei wertlosen Voragenparametern alle spaces hinter dem = entfernt werden, auch wenn die Formatierung |_ = _\n ist. Füllt man den Parameter aus, muss der Zwischenraum wieder ergänzt werden. Diese Ersetzung müllt nebstbei bei großen, vorlagenbasierten Listen die diff ziemlich zu. Mit trim:false ist das ziemlich smart. RTFM. Das Problem was bleibt: unbedarfte Anwender konfigurieren dein Skript nicht richtig.
• (Spaces zur Deutlichkeit als _ dargestellt) Aufgefallen ist mir, dass dein Skript zwar ' _' durch ' ' ersetzt, nicht aber das entsprechende '_ ' mit dem Space vorne.

mit autoFormatTemplates brauche ich den m=multiline parameter gar nicht. (danke, wieder was neues gelernt: RTFM, RTFM, always RTFM.)

lg --Herzi Pinki (Diskussion) 12:15, 14. Mär. 2016 (CET)

Den Vorschlag von Boshomi oben, bei den benutzerdefinierten Änderungen für jedes Suchen-Ersetzen-Paar auch einen Editkommentar angeben kann halte ich für eine Verbesserung im Sinne der Akzeptanz der durch das Skript durchgeführten Änderungen. lg --Herzi Pinki (Diskussion) 12:15, 14. Mär. 2016 (CET)

Hallo ihr beiden. Das Mockup ist großartig und die damit verbundenen Ideen ebenso, vielen lieben Dank dafür. Leider habe ich vieles von dem, was ihr schreibt, noch nicht verstanden.

1. Was meinst du mit „Parametern, die links auf Commons darstellen“? So etwas wie |Commons = Kategoriename in Denkmallisten?
2. Gedankenstriche sind meines Wissens auch in den englischen Kategorienamen auf Commons zu verwenden. Eine Lösung könnte also darin bestehen, diese Kategorien zu verschieben.
3. Mit typographischen Hochkommas mache ich gar nichts. Das dürfte eine benutzerdefinierte Ersetzung sein. Kannst du mir ein konkretes Beispiel zeigen?
4. Das mit dem Namensparameter ist sehr interessant. Es wäre sehr hilfreich, eine ganz konkret Liste von Änderungen zu haben, die dort vorkommen.
5. Die Ersetzung von  \s+ ist benutzerdefiniert. Die kannst du bei dir erweitern, wenn sie mehr tun soll.

--TMg 11:14, 17. Mär. 2016 (CET)

Nur zum Mockup und common.js: Der Hintergrund ist, dass ich viel mit unterschiedlichen Browsern und Geräten arbeite, und gerne auch lange Listen einstelle. Die Daten so eines Formulars werden meines Wissens nach aber nur im LocalStorage abgelegt, und sind damit spezifisch für nur einen Computer und einen Browser. Mit Hilfe der Variable in common.js kann man seine festen Einstellungen überall verwenden.

Die Schaltfläche im Mockup "auf Standard zurücksetzen" würde bedeuten, dass man default-Einstellungen von Autoformatter übernimmt. "common.js einlesen" würde dann bedeuten, dass zusätzlich die in common.js gespeicherten Objekte einliest.

Alternativ wäre nur eine Schaltfläche "auf Standard zurücksetzten" und dafür eine zusätzliche eine Schaltfläche "alle/keine auswählen" für benutzerdefinierte Ersetzungen, In diesem Fall würde "auf Standard zurücksetzen" bedeute, dass auch common.js eingelesen wird.  Frohes Schaffen — Boshomi ☕⌨☺   13:32, 17. Mär. 2016 (CET)