Benutzer Diskussion:TMg/autoFormatter

Diskussion

regengine.js

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

ISSN

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

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

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

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

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

Leerzeichen vor Maßeinheiten

Hallo, dein Script vergeht sich leider an Weblinks. Aus

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

wollte es dies machen:

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

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

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

Ich bekomm’s nicht hin

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

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

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

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

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

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

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

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

Duden kann ich mal nachschauen...

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

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

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

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

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

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

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

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

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

Lemmata mit Klammer

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

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

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

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

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

Was noch gut wäre

Hallo, ich habe mir gestern dein Script importiert :)

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

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

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

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

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

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

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

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

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

Ideen aus den Skripten von ✓ und PerfektesChaos

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

1. Steuerzeichen entfernen, außer Tab und Zeilenumbruch. Kommt in der Praxis allerdings nie vor oder MediaWiki beachtet es schon.
2. Doppelte Leerzeichen in Fließtext könnte man ersetzen. Andererseits, wozu? Bringt keinen Vorteil, nur verwirrende Diffs. Genauso für Tabs. Nur Leerräume am Zeilenende entferne ich, weil diese beim Bearbeiten „unsichtbar“ sind und das Entfernen einen Vorteil bringt (verlässlicheres Navigieren im Bearbeitungsfenster).
3. Manche wünschen sich bei leeren Vorlagenparametern die Beibehaltung des Leerzeichens nach dem Gleichheitszeichen. Sehe ich anders.
4. Nach *, # und : am Zeilenanfang (beliebig viele) immer ein Leerzeichen einfügen. Wichtig: Ausschließlich im Artikelnamensraum. Ausnahmefälle (innerhalb von <nowiki> etc.) sind sehr problematisch.
5. Beim Zeilentrenner |--- in Tabellen mehrfache Striche kürzen. 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)

upright

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

Zu viele Änderungen

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

1. bitte nicht gaengige abkuerzungen wie "u.a.", "ca.", ... ersetzen (siehe WP:RS#Korrektoren, WP:WSIGA#Abk.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)

Dann scheint dein Script aber einen Fehler zu haben, (gerade ebend eingebunden, eventuell in Abhängigkeit eines anderen Scripts s.u.) bei mir wurde jegliche Leerzeile entfernt (ja dass widerspricht den Empfehlungen). Scheint aber ein Bug zu sein, hier der diesbez. Artikel: Plants vs. Zombies -- Perhelion 16:44, 3. Feb. 2011 (CET)

math und -

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)

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)

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)

wgWikiEditorEnabledModules is not defined

Auf meiner Diskussion hat Nirakka ein Problem mit meinen und deinem Skript gemeldet, und ich würde die Verantwortung ganz gerne auf dich schieben :-)

Ich kann angemeldet im FF und unangemeldet im IE nachvollziehen, dass $j.fn.wikiEditor immer (auch wenn man nicht im Bearbeiten-Modus ist) definiert ist und damit als true ausgewertet wird, während wgWikiEditorEnabledModules nur beim Bearbeiten definiert ist und damit in

if ($j && $j.fn.wikiEditor && wgWikiEditorEnabledModules && wgWikiEditorEnabledModules['toolbar'])

einen Fehler erzeugt. Die Zeile sollte also besser

if ($j && $j.fn.wikiEditor && typeof wgWikiEditorEnabledModules == 'object' && wgWikiEditorEnabledModules['toolbar'])

heißen. Alternativ oder zusätzlich und auch in den anderen Fällen wäre natürlich auch eine Beschränkung auf wgAction == 'edit' || wgAction == 'submit' sinnvoll. Ob das schon alle Probleme löst, weiß ich nicht, aber schaden kann es nichts. --Schnark 09:38, 3. Feb. 2011 (CET)

Hallo TMg, diesbezüglich tritt dann ein weiterer (womöglich kompatiblitäts) Fehler auf:

Fehler: invalid range in character class
Quelldatei: https://secure.wikimedia.org/wikipedia/de/w/index.php?action=raw&ctype=text/javascript&title=Benutzer:TMg/autoFormatter.js
Zeile: 122

(vielleicht äußerst sich dies deshalb in dem oben beschriebenen Bug: bez. Leerzeilen) -- Perhelion 17:05, 3. Feb. 2011 (CET)

Missverständliches deutsches Datumsformat durch Langform ersetzen

/* Missverständliches deutsches Datumsformat durch Langform ersetzen */
regex = new RegExp("([^0-9–-|])0?(3[01]|[12]?[0-9])\\. *0?" + (1 + i) + "\\. *([12][0-9]{3}[^0-9–-])", "g");

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