„Benutzer Diskussion:TMg/autoFormatter“ – Versionsunterschied

Zum Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

regengine.js

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

ISSN

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Leerzeichen vor Maßeinheiten

Hallo, dein Script vergeht sich leider an Weblinks. Aus

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

wollte es dies machen:

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Ich bekomm’s nicht hin

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

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

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

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

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

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

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

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

Duden kann ich mal nachschauen...

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

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Lemmata mit Klammer

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Was noch gut wäre

Hallo, ich habe mir gestern dein Script importiert :)

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

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Ideen aus den Skripten von ✓ und PerfektesChaos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

zu 18) Benutzer:PDD/convertEntities.js

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

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

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

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)

Ich bekomm’s auch nicht hin

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

upright

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Zu viele Änderungen

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

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

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

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

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

gudn tach!

@Elvaube:

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

@Alex:

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

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

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

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

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

gudn tach!

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

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

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

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

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

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

gudn tach!

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

gudn tach!

schau mal auf WP:AN#zugriff_auf_user-js. dort mache ich einen vorschlag zu einem kompromiss. was haeltst du davon? -- seth 12:25, 15. Jan. 2011 (CET)

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

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

leerzeilen nach absätzen

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

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

Viertelgeviertstrich nicht in <math> ersetzen

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

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

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

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

gudn tach!

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

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

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

t = arr.join("");

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Wikipedia:Datumskonventionen#Verlinkungen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Falsche Ersetzung in Vorlage:Charts

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Invalid range in character class

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Benutzer:Ianusius/Bot

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

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

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

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

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

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

ISBN

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

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

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

gudn tach!

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

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

sollte es, wenn ich ihn richtig verstehe, besser

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Veränderung der Dateinamen

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

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

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

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

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

Dokumentation zur Maßeinheit %

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

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

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

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

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Eckige Klammer wird zu Unrecht entfernt

Hallo TMg,

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

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

wird zu

[[Kategorie:Staatsministerium (Bayern)|Staatskanzlei]

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

nehme mal an das kam von:

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

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

gudn tach!

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

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

Problem mit Infoboxen

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

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

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

geschützte Leerzeichen bei Rechtsverweisen

Hallo,

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

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

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

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

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

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

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

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

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

Galeriebilder

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

[[Datei:blubb.jpg|Text]]

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Decodierung von Abschnittslinks

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

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

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

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

Jahreszahlen

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

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

ISBN-Nummern falsch formatiert

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Normdatenvorlage mit ändern?

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

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)

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 [3]. 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)

Anführungszeichen

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Interlanguage-Links

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

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

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

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

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

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

Infobox Stadion

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Externe Links

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

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

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

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

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

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

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

Hexadezimale Farbdefinition

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Lokalisierung

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

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

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

includeonly in beta

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Galerie

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 16:46, 2. Okt. 2012 (CEST)

Schaltfläche

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

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

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

Weitere Vorschläge

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

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

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

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

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

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

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

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

Doppelpunkt als Schutz? --Seth Cohen 20:51, 7. Okt. 2012 (CEST)

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

Dateinamen in Infoboxen (Beta)

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

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

Doch, dringend. ;-)

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

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

autoFormatReplacements

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

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

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

Ach so.

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

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

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

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

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

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

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

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

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

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

Prozentangaben

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

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

Falscher Fehler? :-D

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 15:20, 3. Okt. 2012 (CEST)

Einheiten

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

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

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

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

Symbol

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

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

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

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

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

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

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

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 22:19, 26. Okt. 2012 (CEST)

Cursor

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 22:15, 26. Okt. 2012 (CEST)

Großschreibung von Vorlagen

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

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

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

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

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

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

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

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

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

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

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

• {{Belege fehlen}}: Erledigt.
• Belege, Quelle, Quellen, Quellen fehlen: Nein, da Weiterleitungs-Auflösung erkennbar kein Konsens.
• {{Coordinate}}, Koordinate: Bin mir unsicher. Weiterleitungs-Auflösung wahrscheinlich kein Konsens.
• {{Dieser Artikel}}: Erledigt.
• {{EnS}} usw.: Bin mir unsicher, da sehr viele.
• {{Fishbase}}: Scheint mir zu wenig allgemein.
• {{Internetquelle}}, Weblink: Erledigt incl. Weiterleitungs-Auflösung.
• {{Rotten Tomatoes}}, Rottentomatoes: Erledigt incl. Weiterleitungs-Auflösung.
• {{Siehe auch}}, See also: Erledigt incl. Weiterleitungs-Auflösung.
• {{Wikinews}}, {{Wikiquote}} usw.: Erledigt.

Erst mal vielen Dank!

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

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

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

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)

Vorlage Charts

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

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

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

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

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

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

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

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

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

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

Geschweifte Klammern

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

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

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

Sieh mal, was hier mit den ä passiert.

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

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

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

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

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

Sieht gut aus.

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

Jahreszahlenbereich

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

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

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

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

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

Parameter Datei

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

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

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

Wikilinks

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

Reguläre Ausdrücke in benutzerdefinierten Ersetzungen

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

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

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

Kodierung und Dekodierung

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

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

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

Anführungszeichen innerhalb der Vorlagen Zitat und "

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

Schrägstriche

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

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

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

Dieser Abschnitt kann archiviert werden. TMg 23:20, 2. Nov. 2012 (CET)