Benutzer Diskussion:Schnark

Automatische Archivierung

Auf dieser Seite werden Abschnitte sonntags automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Die Archivübersicht befindet sich unter Archiv. Das momentan verwendete Archiv ist Archiv 1.

antispoof

1. Ich habe soeben mit Lustgefühl dein antispoof entdeckt.

   Die gelisteten Codes werde ich durchgehen und mein Skript ggf. entsprechend ausbauen.

   Eigentlich müsste man antispoof so ausbauen können, dass es ohne WP und sogar fast außerhalb von Brausern funktioniert.

2. Die erste Zeile verlinkt auf sich selbst; vermutlich ist das Link ohne .js gemeint.
3. Ich erlaube mir anzuregen, für den ANR unerwuenscht um \u2028 zu erweitern; auf Spezialseiten (unsichtbar) kommt es vor und darf es auch.

   Er taucht gelegentlich auf (Silke, nebenbei statt 14k 15,8) und stört auch Suchvorgänge.

   Wenn ein Darstellungsprogramm spontan weiche Zeilenumbrüche einfügt, etwa um eine mehrzeilige Tabellenzelle umzubrechen, wird es durch C&P eingeschleppt. So wohl auch Sargoth von toolserver.org/~emijrp/imagesforbio hier.

   Gleiches gilt für den paragraph separator \u2029.

4. Das LRM \u200E kommt auf Versionsunterschieden hinter Links vor; wer von dort ein Wikilink kopiert und in einen Artikel einfügt, schleppt es in das Linkziel ein. Ich lösche es dann wieder heraus. Im deutschsprachigen ANR wäre es meist unerwuenscht.
5. Unicode-Block Dingbats würde ich empfehlen gesondert zu bannen.

   Zwar sind die grafischen Zeichen als Windows-Font mit Codes von 161 bis 255 usw. bekannt, aber nicht mal aktuelle Windows-Version-Fonts verstehen sie mit der Codierung U+2700...27BF. Unixoide Systeme kennen noch nicht mal ein Glyph.

   Vor allem aus dem Einleitungssatz ersetze ich zurzeit die "Gestorben-Zeichen" 271D,271E,271F, die Autoren zur besonders schnuckligen Ausschmückung verwenden.

   Wenn du nächstes Jahr mal einen dump hast und dein grep einen regexp kann, der von \x2700-\x27BF geht, wäre ich gelegentlich an einem Überblick interessiert, wie häufig Dingbats im Wikitext vorkommen und ob es sich lohnt, einzelne davon ebenfalls automatisiert durch normale Zeichen zu ersetzen.

   U+2160...217F sind unlesbare Römische Zahlen (!), die ich bereits durch ASCII ersetze. Was die Leute auf ihren Rechnern so alles ausgraben …

6. WikEd gibt seinen kleinen orangen Quadraten ebenfalls ein tooltip mit (siehe hier), auf dem eine Beschreibung des Zeichens steht.

   Gleichwohl muss ich mir den Artikel mit &action=raw holen und lokal speichern, um den Wikitext im HexEditor zu lesen.

Habe einen wunderschönen Tag, möglichst an einem prasselnden Kaminfeuer, ansonsten Sonne im Herzen --PerfektesChaos 13:09, 15. Dez. 2010 (CET)

1. Die meisten Dinge sind relativ ausgereift, wo vermutlich noch Verbesserungsbedarf besteht, ist das Chaos, das die unüberschaubare Menge an umgedrehten kleinen e anrichtet. Vergleiche Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 15#umgedrehtes kleines e. Da müsste ich aber mal die Zeit finden mir durchzulesen, welches e eigentlich wofür gedacht ist.
2. Ja
3. +
4. Ich vermute, dass du die Klammer im Kommentar falsch interpretiert hast, (nur für Spezialseiten) bezieht sich nicht auf unsichtbar, sondern auf außer ... LRM. \u2028, \u2029 werden immer, \u200E auf Nicht-Spezialseiten markiert.
5. Ich werde demnächst alle Dingbats, die missbraucht werden könnten, in unerwuenscht stecken, die römischen Zahlen kann ich zwar fast alle lesen, aber auch diese werden dort landen.

   Die Ausdrücke mal über den gesamten Dump laufen zu lassen hatte ich sowieso vor, bisher scheiterte es daran, dass ich keine Ahnung habe, wie ich in bash Zeichen jenseits von \x00FF als Code eingebe und zu faul war, diese Zeichen mir alle aus der Zeichentabelle zu kopieren.

6. Der Code steht übrigens in en:User:Cacycle/wikEd.js ganz unten, \u3000 fehlt also noch bei mir.

Ein völlig überheizter Computerraum ist ja fast ein prasselndes Kaminfeuer (zumindest im Vergleich zu Hörsälen, in denen übers Wochenende immer die Fenster aufstehen) --Schnark 10:01, 16. Dez. 2010 (CET)

grep hat von Unicode leider keine Ahnung, aber in all solchen Krisenfällen rettet einen ja Perl. Hier das Ergebnis (Stand September): Dingbats werden vor allem in Unterschriften, in einem Fall auch als Benutzername genutzt, sodass die FzW-Archive etc. voll davon sind. In Artikeln gibt es folgende Gruppen:

• Artikel über Zeichen: Unicode-Block Dingbats, Raute, Sternchen (Schriftzeichen), Davidstern, Pfeil (Symbol), Herz (Symbol), Victory-Zeichen, Malzeichen, Liste lateinischer Abkürzungen, Aldusblatt, ♁, Häkchen (Schriftzeichen), Kreuz (Christentum), MacArabic, Dickes Ausrufezeichensymbol, Kreuzchen, ✘, Herz (Farbe)
• Verwendung in Legenden: Brobergen, Toszek, Holzstoff, Stromverdrängungsläufer, Refiner
• Häkchen, Kreuze und Xe: Blutgruppe (✕), Leerzeichen, Cc65, Verfahren nach Quine und McCluskey, Reign in Blood, Interferenz (Linguistik) (✓✗), Master-Theorem (✔✘)
• Sonstiges: Stella Matutina (Orden) (❐), LM.C (❤), Hansa-Bauprogramm (✠)
• fehlerhaft: Mons, Lanškroun, Grafen von Freiburg (✝)

--Schnark 09:20, 18. Dez. 2010 (CET)

Ein viel größeres Problem als Dingbats sind Zeichen aus dem Block zur privaten Verwendung (Benutzer:Schnark/privat), unsichtbare Zeichen (obwohl ich das LRM rausgelassen habe ist es immer noch eine gigantisch große Liste), und anderer Zeichenunfug (♰ wird wesentlich häufiger missbraucht als ✝, gefühlt jede zweite Schule nummeriert ihre Gebäude für die römisch nummerierten Sekundarstufen römisch). Was ich im Augenblick noch als Liste (vor allem für SLAs …) zu bieten habe ist solches Zeug in Titeln (Benutzer:Schnark/titel). Wie ist deine Meinung zu ⅓ etc. ? --Schnark 09:29, 20. Dez. 2010 (CET)

1. First of all – Danke für Deine Mühe.
2. Also, an die privaten Zeichen als Gesamt-Block hatte ich noch gar nicht gedacht; da muss ich mich erstmal 'reinlesen.
3. Allgemein sollten alle die Zeichen ersetzt werden, die nicht weit verbreitet sind, und für die es auf ASCII/ANSI-Ebene einen Ersatz gibt. Auf Windows sind die exotischen Codes teils nur in Arial/Times zugeordnet, unter Mac und unixoid sind sie noch viel seltener in den Fonts.
   • Wenn in Hebräisch, Kyrillisch, Farsi, IPA etwas dargestellt werden soll, können es eben nur diejenigen lesen, die solche Schriften installiert haben. Das ist schon okay und nicht zu ändern.
   • Artikel über Zeichen, die nun gerade selbstreferentiell diese Unicode-Zeichen beschreiben, dürfen sie selbstverständlich enthalten.
     Aus genau diesem Grund lässt meine Skript-Automatik sowas auch in Ruhe.
   • Von den hochgestellten Ziffern sind nur 1,2,3 ANSI; daneben gibt es die hochgestellten Zeichen 4–9,0 und alle tiefgestellten Ziffern, die i.A. unlesbar und durch HTML-tags zu ersetzen sind.
   • Von den Brüchen sind nur ¼ ½ ¾ ANSI. Alle anderen sind zurzeit vielfach unlesbar und im laufenden Text als numerische Angabe meist problemlos manuell durch 1/3 ersetzbar (Vorsicht mit 1⅓), wenn das auch typografisch nicht ganz so schick ist – besser als ein ￭ allemal. Im Artikel-Titel wird man es wohl belassen müssen, auch in künstlerischem Zusammenhang.
   • Dass die römischen Zahlen gaga sind, darüber waren wir uns wohl oben schon klar. Konsequent ASCII; Verschiebereste SLA; würde ich glatt machen.
   • Bei Brobergen, Holzstoff, Refiner hat sich ein Autor viel Mühe gegeben; wenn man ihm die Fummelei wegnimmt, fließen Tränchen. Bei Stromverdrängungsläufer ist es nur eine, da tut es eine ASCII-(1). In Toszek habe ich noch nichts gefunden; muss mir dringend ein antispoof installieren.
   • Ein Kreuz bei Blutgruppe lässt sich ja wohl ohne Bedeutungsverlust durch ein ASCII-X ersetzen.
     • A propos: Ich erinnere mich aus deinem PD-Bereich an gekreuzte Schwerter als genealogisches Zeichen, das viele nicht lesen können und wo ein X-Kreuz auch keinen befriedigenden Ersatz gab.
     • Beim ✠ muss man also aufpassen, ob es „gefallen“ bedeuten soll oder einfach durch ein dagger-† ersetzt werden kann.
   • Die Ja-Häkchen mit Nein-Kreuz in Tabellen sollten durch eine Mini-Version unserer grün-roten Ja/Nein-Vorlage ersetzt werden und alles Weitere in der Vorlage geklärt werden. Vor einem Dreivierteljahr hatte ich mal damit angefangen, das Projekt nach widerständig-indifferentem Gebrummel nicht weiterverfolgt und mich auf SyntaxTextMod fokussiert. Ein X lässt sich aber auch in ASCII schreiben.
   • Zum Hansa-Bauprogramm hatte ich das Link vorhin einem maritim interessierten Kollegen geschickt; der meint, dass das zwar die richtig schöne Original-Darstellung von diesem Germanischer Lloyd #Die Klassenangabe des Germanischen Lloyd wäre, aber weil man seit Einführung von Schreibmaschine und Computer mit Ersatzzeichen leben gelernt habe, würde jeder vom Fach auch ein ASCII-Pluszeichen kapieren. Hier werde ich beide Artikel sinnreich ergänzen und verlinken.
   • Herzchen werden sich nicht vermeiden lassen, wenn ein Herz gemeint ist.
   • Zu Stella Matutina (Orden) habe ich kein Ersatz-Quadrat gefunden; ein wenig zusätzliche Kryptik täte diesem Artikel aber keinen Abbruch.
   • Dann fallen mir noch Ligaturen ein, die außer in diesem Artikel selbst und über Buchdruckerkunst nichts in allgemeinen Texten zu suchen haben. C&P kann aber auch ein Fluch sein; wenn die Leute ihre Artikel selbst an der Tastatur tippen würden, statt sie aus professionellen Texten zu klauen, könnte sowas nicht vorkommen.
   • Die weichen nicht-umbrechenden Trennstriche im Artikel-Titel sind natürlich C&P-gaga und sollten durch exerziermäßige Artikel-Verschiebung aus dem WP-Bestand gelöscht werden, bevor das noch jemand mit C&P weiterschleppt.
   • Die em-Dash in Titeln sind wohl alle typografisch falsch und wären gleichfalls durch Verschiebung zu eliminieren.
   • Die kombinierenden Akzente können in ihrem Sprachkontext durchaus legitim und unvermeidlich sein, wenn es keinen kombinierten Glyph gibt – müsste im Einzelfall analysiert werden.
   • U+20E0=COMBINING ENCLOSING CIRCLE BACKSLASH ist ja wohl ein Witz; das musste ich erstmal in der Unicode-Tabelle nachschlagen. Da hätte man den Artikel-Titel aber auch gleich noch in color=red setzen können. Als Kuriosität drinlassen. Kein ANR verlinkt darauf.
   • Die Preußen werden wohl auch unter Commons mit einer Verschiebung ohne ein U+009F=<control>APPLICATION PROGRAM COMMAND besser zu finden sein, spendieren wir also mal ein scharfes s.
   • FF5E;FULLWIDTH SPACING TILDE – weil ja:WP und ko:WP auf D.C. – Da Capo verlinken, kann ja wohl problemlos eine normale Tilde gesetzt werden oder die WL auch gleich ersatzlos gelöscht werden.
   • Zu allem anderen kann ich im Moment nichts sagen, weil ich nur ￭ sehen kann.
4. Tja, in den historischen Original-manpages zu grep ist [\x2700-\x27BF] auch nicht beschrieben; aber einen Versuch war's wert. Manchmal packen die Implementierungen es trotzdem.

Liebe Grüße, einen angenehmen Tag und gelegentlich eine besinnliche Verschnaufpause --PerfektesChaos 13:09, 20. Dez. 2010 (CET)

Nachdem ich auf Grund der unglaublichen Menge teils nur Stichproben analysieren konnte, weiß ich nicht mehr, ob ich verzweifelt sein soll oder amüsiert, jedenfalls ist alles wesentlich schlimmer, als du es dir vorstellst. Ein paar Beobachtungen:

Drittel sind als Bruch so häufig vertreten, dass es unmöglich ist, sie auszumerzen, zumal sie in der neuen Bearbeitungsleiste (ebenso wie Achtel, was wirklich Unfug ist) zum Einfügen per Klick stehen.

Weiche Trennstriche werden per C&P in Massen eingeschleppt, ganz dringende Bitte, dass dein Skript sie automatisch löscht, es gibt genau einen Fall, wo ein weicher Trennstrich sinnvoll ist: Weiches Trennzeichen, dort steht er als &shy;. Alles andere: Raus.

Geschützte Leerzeichen können sinnvoll sein, aber nicht, wenn man sie direkt (also nicht als &nbsp;) einfügt (was ebenfalls unübersichtlich häufig vorkommt), und ganz bestimmt nicht (du wirst es nicht glauben, aber es ist die bittere Wahrheit) wenn sie auch noch als Name eines benannten Einzelnachweises verwendet werden.

ad Toszek: gut versteckt im Bild befindet sich ein Davidstern für die Synagoge.

ad Ligaturen: was einem so begegnet, wenn man sich eigentlich gerade um PD kümmern wollte

grep scheint bei mir Byte-weise zu arbeiten, wenn ich von Hand UFT-8 kodiere und in Zeichenklassen keine Mehrbyte-Zeichen verwende, geht es. --Schnark 09:29, 21. Dez. 2010 (CET)

Ich habe mit Zufällige Artikel auch schon allerlei Gegurke gefunden, und ich nehme dir unbesehen ab, dass Vieles gaga ist. Mit debugmsg hatte ich mich über allerhand Auffälligkeiten informiert und daraus Anregungen bezogen.

• Drittel etc. wird man wegen des Formatierungsproblems 1⅓ auch nicht automatisch durch 1/3 ersetzen können; wer sowas sieht und es 'rausschmeißen möchte, muss es eben manuell tun. Und wenn die Bearbeitungsleiste es jetzt vorsieht und sich kein gewaltiger Protest erhebt, scheint es bei der Mehrzahl der Fonts inzwischen zu funktionieren; es war über viele Jahre ein Problem. Hören wir mal auf die Resonanz.
• Ich habe den Quelltext meines Skriptes soeben dahingehend geändert, dass aus URL und Wikilinks Weiche Trennstriche ersatzlos gelöscht werden.
  Was den Mengentext angeht, bin ich mir nicht schlüssig. Das Thema ist seit 15 Jahren in der weltweiten Diskussion. Früher waren Browser mit der schnellen Worttrennung bei der Darstellung powermäßig überfordert, und man trennte die Zeile am Leerzeichen. Heute wird die Option „Darstellung mit Worttrennung“ ernsthaft diskutiert, und sinnvoll gesetzte Kann-Trennmarken shy würde ich deshalb nicht pauschal löschen wollen. Leistungsmäßig ist es bei heutigen PC durchaus machbar, bei der Textdarstellung automatische Worttrennung vorzunehmen. Vielleicht ist das in wenigen Jahren wikitext-Standard. Im allgemeinen Skript würde ich das deshalb nicht weltweit und projektübergreifend vorsehen wollen, aber es gibt eine benutzerdefinierte Ersetzung, mit der du löschen kannst was immer du magst:

Benutzer:Schnark/js/Wikisyntax-config.js (siehe unten)

(Ich hebe das \xAD nicht als Entity hervor, das normale Editierfenster zeigt es gar nicht und WikEd ja wohl als türkisigen Strich).

• Das mit „Geschützte Leerzeichen“ habe ich nicht verstanden, hättest du ein wikilink für action=raw? Mein Skript wird künftig im wikitext aufgefundene \xA0 durch Entity &nbsp; ersetzen. Damit würden sie der normalen Bearbeitung zugänglich, und es kann menschlich entschieden werden, ob sie sinnvoll sind.
  Schon vor Jahren hatte ich mal am Server herumgespielt, und hatte wohl die Erfahrung gemacht, dass ein in den Wikitext mit C&P oder über Skript-Zuweisung eingefügtes \xA0 bei der Abspeicherung oder beim Retrieval in normales \x20 verwandelt wurde. Deshalb habe ich hier auch nicht mehr detaillierter nachgeforscht, weil ich davon ausging, dass keine vorhanden sein können. Bei betitelten Wikilink-Zielen und Bild-Namen ersetze ich &nbsp; meiner Erinnerung nach bereits durch normales Leerzeichen, werde das aber nochmal checken.
• ad Toszek Davidstern – ah, ich hatte nach eingekreisten Ziffern gesucht. Das ist ja dann ganz sinnvoll; einen besseren Ersatz haben wir nicht, und es gäbe Sicherlich-Ärger.
• Unicode-„Privater Bereich“: Da scheinst du etwas missverstanden zu haben. Dies sind Kodierungen, die man sich privat mit eigenen Glyphen belegen und etwa in einer PDF-Datei durch eingebettete Fonts mitliefern kann, die ansonsten nur auf dem privaten PC einen Sinn hätten. In einem weltweiten Projekt sicher nicht. U+E000-F8FF sowie PUA, Ebenen 15+16, siehe Liste der Unicode-Blöcke.
• grep – Ich habe noch nie einen Dump unterm Messer gehabt, und ich verzichte dankend. (Es reicht mir, wenn du einen an der Backe hast) Es kann aber deiner Schilderung nach gut sein, dass diese Datei nicht in UCS, sondern in UTF kodiert ist (es steht kein ä sondern ä). Das ist auch sinnvoll, wenn die DB überwiegend lateinischschriftige Texte enthält; es spart mehrere 100 MB ein.
  Vielleicht mal grep --help angucken; es kann sein, dass dein grep sogar ein --encoding=UTF oder sowas kennt. Standardmäßig arbeitet es meist nach dem 25 Jahre alten POSIX, es gibt aber etwa auch ein --perl-regexp, das dir gelegen kommen mag. Weil vor 25 Jahren das Byte und das Zeichen noch 8bit hatten, wird weder in der durchsuchten Datei noch im regexp etwas anderes erwartet. --text könnte bereits ausreichen, die Interpretation als UTF zu erzwingen, falls grep irrigerweise der Meinung war, es sei eine binary Datei und solle Byte für Byte betrachtet werden.

--PerfektesChaos 19:27, 21. Dez. 2010 (CET)

Gegen &shy;s habe ich nichts, nur gegen die im Normalfall unsichtbaren \xAD.

\xA0 in Titeln werden in \x20 umgewandelt (also auch in Bildern), im Text bleiben sie, Beispiel hab ich grad keines.

Was soll ich beim privaten Bereich falsch verstanden haben?

Mit der Hilfe zu grep konnte ich mich nie anfreunden, da sich grep sowieso immer anders benimmt, als es dort steht. Nach Experimenten tut grep das, was grep tun soll, aber dass bzgrep sich wie egrep verhält steht nirgends.

Zwei weitere Listen: komische Zeichen: Benutzer:Schnark/ungewöhnlich; griechisch-nicht-griechische Kombinationen: Benutzer:Schnark/griechisch. --Schnark 09:42, 22. Dez. 2010 (CET)

• nur gegen die im Normalfall unsichtbaren \xAD – Kleines Weihnachtsgeschenk:

Modif_Text = Modif_Text.concat(
             [ [String.fromCharCode(173),  "­"] ]);

Benutzer:Schnark/js/Wikisyntax-config.js

if (wgTitle != "Ligatur (Typografie)") {   // !RL!
   Modif_Text = Modif_Text.concat(
                 [ ["ff",
                    "ff"],
                   ["fi",
                    "fi"],
                   ["fl",
                    "fl"],
                   ["ffi",
                    "ffi"],
                   ["ffl",
                    "ffl"],
                   ["st",
                    "st"]
                            ]      );
}   // Ligatur (Typografie)

(Den Code zuvor oben habe ich entfernt, weil nicht funktionsfähig und dazu gefährlich)

• Was soll ich beim privaten Bereich falsch verstanden haben? Du schreibst oben: „Zeichen aus dem Block zur privaten Verwendung (Benutzer:Schnark/privat)“. Das ist aber feststehender Begriff für andere Blöcke ab 57344₁₀. Bei Benutzer:Schnark/privat liegst du aber unter 10000₁₀, und du könntest wohl auch keine "privaten Zeichen" sehen. Ich nahm dies aber zum Anlass, solche Zeichen in Entities zu wandeln.
• Ich werde versuchen, \xA0 im Text unterzubringen, bleibe auch dankbar für Artikelbeispiele.
• An einigen der von dir aufgefischten Artikel werde ich mich im Weihnachtsurlaub erproben, Danke dafür.
• Mittelfristig wäre das eine Sache für SK und sein checkwiki.

Falls wir nichts mehr voneinander hören, mach dich unterm Tannenbaum schön lang! --PerfektesChaos 18:11, 22. Dez. 2010 (CET)

• Deinen Code werde ich bei Gelegenheit übernehmen, danke dafür!
• Alle unter /privat aufgelisteten Texte enthalten ein Zeichen aus E000–F8FF, die in den meisten Fällen als Ersatzzeichen in Einzelfällen aus Dreck und in wenigen Fällen gar nicht zu sehen sind.
• Ich werde wohl über Weihnachten dazu kommen, ein paar Beispiele für \xA0 direkt im Text zu finden.

Auch dir frohe Weihnachten! --Schnark 09:17, 23. Dez. 2010 (CET)

/privat: Aaaah – frei nach dem Motto: „Ein Patient, der Läuse hat, kann auch Flöhe haben.“ Jetzt habe auch ich sie gefunden.
Die Experimentalversionen -2.91 (x24.js) enthalten u.a.:

• \xA0 im freien Text würde immer &nbsp; – dazu debugmsg "charRemoveUndesired" aufpoppend (ungetestet)
• Private Use Zeichen werden numerisches Entity (funktioniert)
• shy wird immer aus Linkziel entfernt (ungetestet)

Lass es dir gutgehn --PerfektesChaos 12:52, 23. Dez. 2010 (CET)

Falls du ein paar Test-Artikel mit \xA0 brauchst: Anime, BASIC, Freie Hansestadt Bremen, Bettina von Arnim, Bibel, Bulgarien, Baden (Land), Candela, Coulomb, Sprachelemente von C-Sharp, Compact Disc, Estnische Sprache. Statistisch gesehen macht das etwa 10700 Artikel mit einem \xA0 (estnische Sprache hat ID 1313). Viele Grüße --Schnark 10:07, 27. Dez. 2010 (CET)

Danke schön, ich kümmere mich drum.

Zurzeit räume ich noch mit Römischen Zahlen auf /privat und /ungewöhnlich auf, ein Fan ostasiatischer Pkw scheint viele Fonts auf seinem Rechner gehabt zu haben. Die Sekundarstufe II ist schon Geschichte; lass mich dieses Jahr da noch ein wenig eindampfen.

Bisher hat mir das schon neue Erkenntnisse über den HYPHEN gebracht; bin aber mit dem Denken noch nicht ganz fertig.

Wir sehen voneinander --PerfektesChaos 10:44, 27. Dez. 2010 (CET)

1. Zu den Zeichencodes habe ich mich zwischenzeitlich hier bzw. dort weiter geäußert. Benutzerdefinierte Möglichkeiten stehen da.
2. Die Römischen Zahlen habe ich soweit aus den Titeln herausgeätzt. An den ungewöhnlichen Zeichen knabbere ich weiter; in Dortmund sitzt offenbar ein Fan, auf dessen watchlist ich möglicherweise unangenehm auffalle. Bewusst kombiniert werden hier die Römischen Zahlen mit Ligaturen „Seite 14ff“.
3. Danke für die \A0; ich werde ggf. einige Reguläre Ausdrücke überdenken müssen.
   Zur Estnischen Sprache fällt mir ein Schwank ein: Eine sehr ähnliche Sprache beginnt mit F., das Quasi-Nachbarland auch. Dazu gibt es ein WP-Portal, das von jemand mit charakteristischem P im Namen dominiert wird. Dieser duldet in "seinem" Portal keinerlei &nbsp; und ersetzt sie alle in jedem Artikel durch einfache Leerzeichen, weshalb es im Lauf der Zeit zu mehreren Edit-Wars kam und wohl auch einige Autoren dieses Portal verließen (auch wegen anderer Herrschaftsallüren). Es kann sein, dass im Zuge einer Software-Änderung Autoren des Portals einen Dreh fanden, unsichtbare geschützte Leerzeichen unbemerkt in Artikel einzuschmuggeln. Vielleicht gibt es ja thematische Häufungen. Von meiner Seite aus lasse ich sie unverändert, hier zu ändern ist selbst zu definieren.
4. Die Erkennung unerwarteter Strichelchen konnte ich durch deine Analyse ausbauen; auch etwa in PD werden sie jetzt als solche verstanden.

Guten Rutsch --PerfektesChaos 00:58, 31. Dez. 2010 (CET)

Frohes Neues erstmal!

• Ich beichte einen bug auf WikisyntaxTextMod/usage/typogr, von dir übernommen in Wikisyntax-config.js
  Ich kaufe ein E, äh, nein, ich klaue ein e. Statt

["([a-z])['´`]ne?\\b", "$1’n"],

muss es heißen

["([a-z])['´`](ne?)\\b", "$1’$2"],

… ich hatte nachträglich noch ein fakultatives e endeckt und vergessen, es in die Ersetzung aufzunehmen.

• Nicht verstanden habe ich bei dir:

['(ISSN(?:\\s|\\|)\\d\\d\\d\\d)–(\\d\\d\\d\\d)', '$1-$2'],

Die ersetzte zweite Klammer ist in der ersten enthalten; ich würde annehmen, es sei '$1-$3' gemeint (C&P von der vorangehenden Zeile).
Ich mache sowas Ähnliches, wandle aber gleich in die Vorlage:

var dashes = String.fromCharCode(45,173,8208,8209,8210,8211,8212,8213,8722);
["\\bISSN(:|:?( | )+)([0-9]{4})[" + dashes + " ]?([0-9]{3}[0-9xX])\\b",
 "{"+"{ISSN|$3-$4}}"],

• antispoof habe ich mittlerweile zu laufen und erfreue mich daran.
  Im Normalfall sollte der n-Dash (Geviertstrich, U+2014, 8212) jedoch nicht angemeiert werden; er ist absolut unproblematisch und steht auch auf der CP1252.
  m-Dash ist computermäßig ebenfalls unbedenklich, gehört aber nicht in die deutsche Typografie. Falls du den nDash weiter als bemerkenswert einschätzt, würde ich bitten, einen "heftig"-Modus auf die ToDo-List zu setzen, der standardmäßig nicht eingeschaltet ist.
• Auf die Gefahr hin, dass ich etwas blind bin: Bei Estnische Sprache finde ich weder aktuell noch August 2010 noch 2006 ein eigenständiges \xA0, sondern nur als UTF-Bestandteil in den Interwikis. Weder Hexedit noch antispoof (Statistik unter Titelzeile) finden es als Zeichen.
  In anderen Artikeln sah ich aber das \xA0 und glaube grundsätzlich an seine Existenz.
• Dir vermutlich bekannt? Sicherheitshalber commons:MediaWiki:Titleblacklist + MediaWiki:Titleblacklist

Bis dennele --PerfektesChaos 18:40, 4. Jan. 2011 (CET)

Das e habe ich übernommen, danke für den Hinweis. Bei der ISSN-Korrektur stimmt meine Zählung, mit ?: eingeleitete Klammern zählen bei der Zählung nicht mit (zumindest FF weiß das).

Einen n-Dash sollte mein antispoof eigentlich nicht hervorheben, nur mit einem Tooltip versehen – andernfalls könnte man hier nicht die 3 – 1 = 2 Fehler sehen −, was in meinen Augen sinnvoll, aber nicht störend ist. Der Gedankenstrich und das Minus sind in der Sonderzeichenleiste unten einfach so nahe, dass solche Fehler an der Tagesordnung sind. Den m-Dash hebe ich wirklich nur auf Grund der Tatsache hervor, dass er in deutscher Typographie nicht vorkommen sollte.

Beim nbsp hatte ich etwas geschummelt, der Ausdruck hatte auch nach thinspace gesucht, solche kommen ein paar direkt im Wikitext vor.

Hier verkümmert die Titleblacklist nur zu einer Benutzernamen-Verbietungsliste, daneben gibt es noch mw:Extension:AntiSpoof, die das Nebeneinander griechischer und lateinischer etc. Buchstaben verhindern sollte, und mindestens ein Missbrauchsfilter verhindert auch irgendwelche Benutzernamen (Nummer 14, ist aber privat, sodass nur Admins sehen können, wen sie damit eigentlich aussperren).

Viele Grüße --Schnark 09:40, 5. Jan. 2011 (CET)

1. non-capturing parentheses – Du hast recht.
   Die Konstrukte mit (? stehen bei mir allerdings auf der schwarzen Liste der gebannten RegExp-Eweiterungen etwa gegenüber JavaScript 1.3 – weil regelmäßig Ursache von Inkompatibilitäten, dazu auch mit Posix, grep, Lisp; und durch andere Formulierung vermeidbar, deshalb mir geistig nicht so präsent. JScript kennt es aber mittlerweile auch schon.
2. nDash – Ah, ja, ich arbeite mich erst allmählich in die rosarot gesprenkelten Artikel ein. Sorry for confusion.
3. Was mich aber auf eine Anregung bringt:
   • \u00A0 (und ggf. nur im dargestellten Artkel &#160;) hellgrau (wie in OpenOffice.org) oder pastellgelb oder hellblau unterlegen
     Test: 4 % und «Guillemets» bzw. « Guillemets »
   • Schmales Leerzeichen in jeglicher Kodierung in entsprechend unterscheidbarem Pastellton unterlegen
   • Und von dieser Idee dann auch noch WikEd zu überzeigen, Realisierung zu erwarten für etwa 2013.
4. Und weil ich gerade bei Anregung war:

count + ' verdächtige' + (count==1 ? 's' : '') + ' Zeichen gefunden!</span>'

• Weiche Trennstriche habe ich dir für einen gelegentlichen Lauf des autoedit.js-Niedermetzelns übriggelassen.

(PS: Den Schwesterprojekten nach sperren sich die Admins u. a. ihre Benutzernamen, auch solche, die den Stewards, Checkuser etc. zum Verwechseln ähnlich sehen – also etwa ein Raymοnd; und wohl allerlei Varianten von 18 etc. – wird ja wohl sinnvoll sein)

Einen sonnigen Tag --PerfektesChaos 13:52, 5. Jan. 2011 (CET)

Mahlzeit!

1. Im Nachgang zu meiner vorherigen Bemerkung über Sichtbarmachung von nbsp möchte ich dir meinen Lernerfolg nicht vorenthalten: Vorlage:ArS
   • Bei Umwandlung von Vorlagen zum Cache-Schnipsel wird   nbsp→#160
   • Rot für \xA0 wäre dann im Allgemeinen etwas übertrieben, hellgelb würde reichen. Zig Vorlagen verwenden irgendwo nbsp an Seitenzahlen, Paragrafenzeichen etc.
   • Im konkreten Fall ist rot allerdings mal angesagt, denn wenn wie hier der arabische Text etwas länger ist, machen die nbsp typografisch überhaupt keinen Sinn; höchstens wenn nur ein paar wenige Buchstaben dargestellt werden sollten. Hingegen wäre RLM...LRM angebracht. Why ever.
   • Zu den Ur-Autoren gehört nebenbei ein gelöschter S.K., der mit einem bekannten SK identisch sein dürfte.
2. PD-technisch überfordert bin ich vom sachgerechten Umgang mit den ALTERNATIVNAMEN bei Wilhelm von Rubruk#Namensvarianten.

Have a nice day --PerfektesChaos 12:52, 6. Jan. 2011 (CET)

2. In Zukunft wird ein Geviertstrich übrigens nur noch in Artikeln bemängelt, auf Diskussions- und anderen Seiten haben ihn zu viele in der Signatur.

3. Da ich in weiser Voraussicht für color in highlight.js bereits eine Funktion zugelassen habe, wäre eine farbliche Hinterlegung definitiv kein Problem, da ich durch meine Modulverwaltung eine Standardkonfiguration leichter überschreiben kann als du, liegt es an dir, für die Zeichen, die derzeit in benennen stehen, eine Farbe (einschließlich transparent) zu bestimmen. Was WikEd angeht bist du zu optimistisch, es hat ja schon ein Jahr und mehrere Beschwerden auf Cacycles Disk gedauert, bis er mal den Fehler ein einzelnes Leerzeichen in der Kat.-sortierung zu enfernen behoben hat.

4. Perfektionist

5. Im Prinzip könnte man tatsächlich auf der Basis von autoedit.js einen Bot programmieren (und mit der neuen Version, die es gleich gibt, erst recht), aber ich habe es eigentlich nicht vor.

6. Inzwischen sollte die Antispoof-Extension das Anlegen eines Benutzers Raymοnd verhindern, wenn es einen Raymond gibt, so was stammt also noch aus der Urzeit.

1. Geschützte Leerzeichen stehen übrigens automatisch auch vor jedem Satzzeichen (Plenk#Sonderfall_Französisch), wo sie die Software ebenso wie vor das Prozentzeichen setzt. Jener S.K. hat übrigens nur eine gelöschte Benutzerseite und ist immer noch aktiv. Und dass eine Person nicht innerhalb von 10 Sekunden erst diesen und dann jenen Edit macht, bezweifle ich sehr stark.

2. Im Prinzip: alle in ALTERNATIVNAMEN aufnehmen. In der Praxis: so lassen wie es ist.

Viele Grüße --Schnark 09:38, 7. Jan. 2011 (CET)

Commons:Commons:Forum#Neues Gadget fuer automatische Uebersetzung

Hallo Schnark. Viellicht interessiert dich diese Diskussion (wo ich dein extratabs.js erwähnt habe). --Leyo 09:41, 7. Jan. 2011 (CET)

Hab dort meinen Senf hinterlassen. --Schnark 09:51, 7. Jan. 2011 (CET)

fullscreen.js

Hallo Schnark, ich muss dir mal ein Würdigung für deine Skripte aussprechen. Das fullscreen.js ist klein aber sehr fein.(für Netbooks ausgezeichnet) LG -- Perhelion 22:13, 9. Jan. 2011 (CET)

Als Warnung: Beim Schreiben des Skripts ist mir mein Browser oft genug abgestürzt. Ich glaube zwar, dass jetzt alles so funktioniert, wie es sollte, aber ein bisschen Vorsicht ist in der Anfangszeit geboten, zumal ich das Skript im Augenblick selber nicht verwende und so Fehler nicht selber finden kann. --Schnark 09:36, 10. Jan. 2011 (CET)

Ok, danke der Warnung. Ich benutze hauptsächlich den FF, manchmal noch IE oder Chrome, bist jetzt nichts aufgefallen (verschiedene PCs). Eine kleine Inkompatibilität zum "Monobook" Frame von (Benutzer:)PDD besteht jedoch, das liegt aber eher an diesem. Da dieses eine absolute Position hat, könnte man es auch durch ein Mouseover ein- und ausblenden lassen. (das wär noch das Wenigste). Vorlage:Smiley/Wartung/:)  Momentan will ich auch wieder etwas JS basteln. LG -- Perhelion 16:52, 10. Jan. 2011 (CET)

wikieditor.js

Hallo Schnark, ich teste gerade deine Module weiter. Jedoch ist bei der neuen Werkzeugleiste ein Bug (wie ich meine) aufgetreten. Sie erscheint erst wenn ich auf die Standard/Erweitert/Debug klicke. :(. Meine Konfiguration scheint auch gänzlich ignoriert zu werden. :( Und die Erklärung ist (wie ich meine) ein klein wenig verwirrend. Vorlage:Smiley/Wartung/:s  LG -- Perhelion 18:04, 11. Jan. 2011 (CET)

Du bindest mein Skript zweimal ein, zuerst mit meiner, dann mit deiner Konfiguration. Da meine Modulverwaltung aber Doppeleinbindungen ignoriert, wird deine Konfiguration ganz zu Recht nicht beachtet. Wenn du die Zeile jsmodules.load('[[Benutzer:Schnark/js/wikieditor.js]]', {before: '[[Benutzer:Schnark/js/Wikieditor-config.js]]'}); entfernst, dann könnte/sollte/müsste es funktionieren. --Schnark 09:09, 12. Jan. 2011 (CET)

Danke und sorry (habe dich gar nicht gesehen in meiner Beo). Ja, hätte ich auch drauf kommen können Vorlage:Smiley/Wartung/hm . Funzt jetzt problemlos! Also ich muss sagen deine neue Bar ist wirklich sehr vielversprechend und toppt alle meine Erwartungen.Vorlage:Smiley/Wartung/anbet  Dann hätte ich noch die kleinen Fragen, die sich mir bei der Anleitung gestellt haben. Stimmt es dass ich die alten Befehlsnamen hätte nicht ändern brauchen? Mit der doppelten Modul-Einbindung war jetzt auch nicht ganz so eindeutig. Die modulisierte persönliche Konfiguration ist ebenfalls was ganz neues (bin mir nicht ganz sicher über einen wirklichen Anwendervorteil, deshalb nehme ich noch etwas Abstand davon). Ich habe einfach mal dein vector übernommen, dabei ist mir aufgefallen dass diese noch(?) auf dich persönlich zugeschnitten sind (oder sind diese noch nicht als allg. Module freigegeben)!? PS: stelle grad fest dass den Smilies ein Semikolon; angehengt wird. Beste Grüße PS: Somit fehlt nicht mehr wirklich viel für den Monobook-Ersatz von PDD -- Perhelion 20:19, 14. Jan. 2011 (CET)

Die alten Befehlsnamen musstest du ändern, nur wenn du um meine jsmodules.js einen großen Bogen gemacht und einfach importScript('Benutzer:Schnark/js/wikieditor.js'); geschrieben hättest, wären Befehle für die (fast vollständige) Abwärtskompatibilität eingebunden worden. Der Hintergrund ist der, dass Benutzer, die nichts ändern wollen, einfach nur die Zeile für die Einbindung ändern müssen, die anderen aber nicht den alten Ballast mit sich schleppen müssen. Was in meiner vector.js steht, hat nicht unbedingt viel mit dem zu tun, was bei mir an Skripten wirklich eingebunden wird, da ich (was du auch kannst) per Cookies unter Benutzer:Schnark/js/modulverwaltung#Konfiguration deiner Skripte alles mögliche ein- und ausschalte. (Einer der Vorteile meiner Einbindungsfunktion.) Das Semikolon sehe ich im Quelltext auch, sobald ich ein bisschen darüber meditiert habe, wie es da rein kam, werde ich es entfernen. --Schnark 09:34, 15. Jan. 2011 (CET)

Ein Wochenende im Spukschloss

Was habe ich gelernt?

1. Bislang kein Erröten, steht aber in den Scans, kein WikEd; nur HexEdit von raw half:
   • 200B;ZERO WIDTH SPACE
   • 202C;POP DIRECTIONAL FORMATTING
   • U+2715 wird rot, U+2716 nicht.
2. Neu: 2044;FRACTION SLASH   Nur in: Vorlage:Bruch sinnvoll
3. U+2122 ™ TradeMark ist zulässig nach lateinischen und beliebigen Buchstaben
4. NBSP sollte als U+00A0 hellgrauen statt rötlichen Hintergrund bekommen, analog zu office.org
5. Benutzer:Schnark/Wartung/Unsichtbar/Ausnahmeliste#MacArabic editieren und über letzte Zeile staunen; in den nächsten Tagen werde ich hier etwas forschen
6. lrm und rlm sollte vom js und künftigen Scans ignoriert werden, wenn links bzw. rechts davon ein Zeichen U+0590--08FF oder (seltener) U+FB50--FDFF U+FE70--FEFF U+10800--10FFF steht; eigentlich reicht auch umgekehrt positiv U+0007--U+058F. Siehe Liste der Unicode-Blöcke
7. Die beiden nullbreiten Zeichen zw*j sind innerhalb U+0590--109F okay. Was zwj (8205) am Ende der Zeichenkette macht, so in Links auf ml:WP üblich und notwendig, müsste mal ein Sprachexperte erläutern. Eigentlich müsste man die zw*j am Anfang/Ende einer Zeile (auch vor und nach Leerzeichen) doch löschen können? Traue ich mich aber nicht.

Wenn ich keinen Widerspruch lese, werde ich deine Wartungsseiten allmählich etwa wie folgt umstrukturieren:

/Wartung --+-- /LeerNull --+-- /Dump.2011-01
                           +-- /Ausnahmen
                           +-- /Nichtlat
                           +-- /Gesperrt

bzw.

/Wartung --+-- /Strich --+-- Dump.2011-01

Hintergrund ist, dass die Dumps und Scans irgendwann überholt sind und gelöscht werden sollten; die Ausnahmelisten enthalten jedoch Infos, die bleiben sollten. Dann müssen die bleibenden Seiten aber im "Pfad" zuerst stehen.

Eine begeisternde Woche wünscht nach Ende der Gespensterstunde --PerfektesChaos 01:20, 24. Jan. 2011 (CET)

1. 200B und 202C stehen eindeutig in unerwuenscht drin, muss ich mal genauer utnersuchen, 2716 fehlt tatsächlich (vermutlich dachte ich, dass so etwas wirklich niemand verwendet)
2. Eben weil es in Vorlage:Bruch sinnvoll ist, ist 2044 nichts für antispoof, nur für den nächsten Dumpscan.
3. Steht derzeit noch drin, da TradeMark von vielen als nicht unbedingt enzyklopädie-geeignet angesehen wird. Ich denke mal darüber nach.
4. In Kürze
5. HTML-Quelltext sieht auch sehr interessant aus <naps/> Warum können die Araber nicht auch einfach von links nach rechts schreiben?
6. In Kürze
7. In Kürze und auch keine Ahnung
8. Da ich Ausnahmen teils schon vorher von Hand rausfiltere, halte ich eine Umstrukturierung für unnötig, löschen kann man auch Seiten, ohne dass Unterseiten betroffen sind, aber ich gebe dir freie Hand. Bei Portalen bin ich übrigens keineswegs der Ansicht, dass sie grundsätzlich nach Gesperrt gehören, solange es sich nicht um einen sehr internen Arbeitsbereich handelt. --Schnark 09:22, 24. Jan. 2011 (CET)

1. 200B​200B und 200C‌200C werden eindeutig markiert, nur dann, wenn dummerweise weder links noch rechts davon etwas steht, sieht man die Markierung nicht. 2716 steht jetzt in meiner TODO-Liste.

4. Der Monitor hier ist vollkommen unkalibriert, nenn mir also einfach mal den Hex-Farbcode, den du haben willst (kann auch für jedes Zeichen ein eigener sein)

6. und 7. Stehen jetzt in meiner TODO-Liste. --Schnark 09:47, 25. Jan. 2011 (CET)

1. Die tauchten wohl auch jeweils im Artikel vor einem \n oder zwischen zwei \n auf. In der Scan-Liste standen sie zwischen den > und < der nowiki und waren deshalb dort sichtbar. Weil ich aber erst durch antispoof auf die Existenz solcher Biester kam, sind sie jetzt dem ASCII-Space gleichgestellt worden und werden nach und nach bei Trim-Operationen mit entfernt.

2. Ja; es war Dumpscan gemeint, nicht aber dargestellter Text.

3. TradeMark ist ein juristisches Merkmal. Das mag bei der Diskussion irgendwelcher Verwertungsrechte im Artikel sinnvoll und notwendig sein; ansonsten ist es stilistisch sicher unschön, von Microsoft® Windows® 7® zu schreiben – aber kein Syntaxfehler.

4. #C0C0C0 wäre ein Grauton für NBSP, der bei unterschiedlichen Lichtverhältnissen und Monitoreinstellungen deutlich von Weiß zu unterscheiden sein müsste, aber noch nicht als schwarzer Block wirken würde.

6./7. Die User Community dankt.

8. naja, ich stelle mir die erste Listen-Ebene ggf. als eine Übersichtsseite zum Thema vor, von der aus auf umfangreiche Listen-Seiten (blieb anfänglich wegen Zeitüberschreitung bei zuviel Spukzeichen hängen) als Blätter verzweigen. So plane ich für irgendeine schwache Stunde eine kleine Ausarbeitung zum Thema /RechtsLinks und deren Sinn im Wikitext. – Das Löschen hängt vom Biorhythmus und sonstigem Zustand des Admins ab; ich habe es schon erlebt, dass in dieser Situation auch ungefragt alle Unterseiten mitgelöscht werden: die haben anscheinend auch einen Knopf oder Einstellung für „/Archiv sowie /Archiv/2007 mitlöschen“. – Portale hatte ich mir angeguckt; es waren teils Disku-ähnliche Passagen, teils längst erledigte Bastelarbeiten. Die Portal/Redaktion-Leute reagieren mitunter arg allegorisch, wenn wildfremde Leute aufschlagen und in diesem Bereich unverständliche edits machen. Ändern würde ich (ggf. per Disku), wenn aktuelle Kopiervorlagen etc. im Portal stünden, deren Weiterverbreitung in den ANR zu befürchten wäre. Ansonsten agiere ich lieber diskret und rufe mir ungern schlafende Hunde an den Hals.

Einen angenehmen Tag noch --PerfektesChaos 14:15, 25. Jan. 2011 (CET)

3. Da ich offensichtlich ® erlaube, überlege ich es mir nochmal. Bei einem Zeichen, das nicht auf der Tastatur ist, ist auch so was nicht zu befürchten.

4., 6., 7. NBSP etc. werden wie korrekte RLM etc. angegraut. Viele Grüße --Schnark 09:14, 26. Jan. 2011 (CET)

Nachtrag: Gewöhnungsbedürftig auf der Beobachtungsliste --Schnark 09:16, 26. Jan. 2011 (CET)

Guten Morgen; danke für die NBSP.

Zu Beobachtungsliste und RLM äußere ich mich gerade auf Benutzer:Schnark/Wartung/RechtsLinks.

C U L8er --PerfektesChaos 09:43, 26. Jan. 2011 (CET)

Guten Morgen mal wieder,
ich muss einfach mal loswerden, dass antispoof+highlight eine echte Bereicherung für typografisch sorgfältig arbeitende Autoren sind.
Den Dumpscans konnte ich entnehmen, dass es im Artikelbestand Non-ANSI (Windows-)Zeichen 128–159 gibt, die der Server heutzutage nicht mehr akzeptieren würde. Meine Doku werde ich anpassen müssen.
Weiter so --PerfektesChaos 09:26, 27. Jan. 2011 (CET)

• War Zeit (ANR=19979). Würde statt auf der Disku versteckt besser auf die Benutzerseite passen.
• @Beobachtungsliste – bei mir ist nichts Auffälliges; aber wir arbeiten ja nicht statisch, sondern mit eingebauter Intelligenz; notfalls die Anwendung bestimmter Regeln auf ns≥0 begrenzen.
• Habe die unsichtbaren Zeichen ausgewertet; werden künftig (mit x29.js) als Entities zur Entfernung sichtbar gemacht.
• Auch die türkischsprachige WP kann ab 3.0 im Vollprogramm gleich behandelt werden.

Have a wonderful day --PerfektesChaos 01:34, 28. Jan. 2011 (CET)

2. Ich habe in meinen Einstellungen unter „Letzte Änderungen“ den Punkt „Erweiterte Darstellung der „Letzten Änderungen“ (benötigt JavaScript)“ aktiviert, damit wird die Beobachtungsliste mit vielen geschützten Leerzeichen gestylt. Da auf den Spezialseite, auf denen antispoof sinnvoll ist, (also hauptsächlich Spezial:Alle Seiten) geschützte Leerzeichen keine Rolle spielen, werden die wohl bald in ns == -1 rausfliegen. --Schnark 10:44, 28. Jan. 2011 (CET)

betr. Auszeichnung

Hallo Schnark,

wenn Du mit auf der Urkunde zeichnen möchtest muss Du es hier machen: Benutzer:Graphikus/Fleißige Biene Gruß --Graphikus 10:45, 28. Jan. 2011 (CET)

Habe im Dschungel der HTML-Tags die richtige Stelle gefunden. --Schnark 10:52, 28. Jan. 2011 (CET)

och, wenn Du sie nicht genau gefunden hättest, hätte ich die Seite wieder aufgestellt. Brauchte ja nur Deine Signatur. Und weil das ja wirklich ein Dschungel auch heute noch für mich an völlig kryptischen Zeichen ist, habe ich extra diese Unterseite angelegt. Danke Grüße --Graphikus 10:57, 28. Jan. 2011 (CET)

WikisyntaxTextMod 2.94

Hallöchen,

1. dass nach zwei Monaten ein Bug in WSTM gefunden wurde, hast du ja selbst schon mitbekommen. Allerdings mache ich routinemäßig erst mal einen längeren Abschlusstest mit der komprimierten r-Version, bevor ich dich ohnehin informiere. (Inzwischen erneuert; ich weiß nicht, ob du dazu deine Versionsnummer nochmals hochsetzen müsstest.)
2. Perhelion fand ein Problem mit dem URL-RegExp für wikimedia.org (unbekannte Subdomain stats. wurde zerwurstet); ein kleines "^" behob dies.
3. Somit sind alle für 3.0 vorgesehenen Kleinigkeiten bereits allgemein verfügbar, wie der y-Flag im RegExp (deine Anwendung werde ich versuchen noch im Laufe des Abends zu verstehen), und das Sichtbarmachen ausgewählter Spezial-Zeichen als Entities.
4. Zu sonstigen Neuerungen habe ich mich dort geäußert, wo kürzlich Edelmetall-Tierchen für fleißige Tierchen thematisiert wurden.

Viel Spaß --PerfektesChaos 18:28, 30. Jan. 2011 (CET)

1. Da ich das Skript auf meiner Beobachtungsliste habe, bekomme ich alle Änderungen auch ohne deinen Hinweis mit, zumindest wenn nicht ein ganz bestimmter Benutzer meint, die Archivierung auf allen von mir beobachteten Diskussionen umzuändern.
2. Aus 1. folgt, dass ich das auch mitbekommen habe.
3. Ich empfehle dir, nicht zu verstehen zu versuchen, was es macht, ich verstehe es nämlich selbst nicht. Das y verhält sich nicht so, wie ich es erwartet habe, und ich konnte auch nicht herausfinden, wie es sich tatsächlich verhält. Ich werde den Ausdruck daher gleich noch einmal umändern – ohne y.

Viele Grüße --Schnark 09:13, 31. Jan. 2011 (CET)

3. Irgendwie verhielt sich der Ausdruck in meiner Testumgebung so wie sollte, hier stellt er aber den größten Unfug an. Also am besten noch nicht versuchen zu verstehen und vor allem nicht verwenden. --Schnark 12:45, 1. Feb. 2011 (CET)

Die Behandlung von Anführungszeichen ist jetzt zwar eine komische Bastellösung, funktioniert aber bis jetzt gut. --Schnark 12:49, 3. Feb. 2011 (CET)

Wie kommen die Spoof-Zeichen in den Wikitext?

Du hast ja einen guten Namen im Community-Bereich; vielleicht lässt man dir einen Edit durchgehen:

• Hilfe:Textgestaltung
  geschützten Bindestrich (Unicode-Zeichen Nummer 8209 bzw. (hex) 2011): Müller&#x2011;Lüdenscheid, Regenhose und &#8209;jacke verwenden.

Besonders pfiffig ist, das -jacke zu schützen.
Es wird Frühling. --PerfektesChaos 09:43, 1. Feb. 2011 (CET)

Bist du sicher, dass es keinen Browser gibt, der die Zeile zwischen dem Bindestrich und der jacke umbricht? Einem IE 6 würde ich so etwas nämlich zutrauen. Und solange sich sowieso keiner an die dort formulierten Regeln zur Textgestaltung hält, habe auch ich keine Lust bei 175 − 1 Leuten aufzufallen. --Schnark 09:56, 1. Feb. 2011 (CET)

Hat nichts mit obigem zu tun, aber zu deiner Information: [1]. --Schnark 10:24, 1. Feb. 2011 (CET)

Hm*, dies wurde auch ohne Konsens eingefügt auch wenn es praktisch erscheinen mag. Es ist doch nur eines von zwei Entities die wirklich zu gebrauchen sind? Vielleicht sollte man doch auf breiterer Fläche fragen? Zudem ist das Bsp. wirklich schlecht, wann sollte man ihn überhaupt verwenden? Und warum stört es? -- Perhelion 11:14, 1. Feb. 2011 (CET)

Man könnte es vielleicht durch ein sinnvolleres Beispiel wie 5‑jährig ersetzen. --Schnark 11:42, 1. Feb. 2011 (CET)

Danke für techblog (was du alles für Seiten kennst), ich habe die zweite Februarwoche für eine erfolgreiche Einführungsphase vorgemerkt; war dies problemlos und ohne Rückfall auf 1.16 verlaufen, werde ich mediaWiki.config und mediaWiki.loader in unserem Kontext testen, ResourceUpdater einführen und dann WSTM auf 3.0 hacken.

Geschützter Bindestrich munkelt etwas; ich kann mich erinnern, dass vor vielen Jahren mal irgendwas Seltsames geschah, was aber auch wieder gefixt wurde. Umgekehrt beschert es aber allen anderen das Risiko, statt eines Strichs ein Quadrat zu sehen oder vor dem Strich am linken Rand noch ein Leerzeichen. Grundsätzlich ist es eine unkluge Taktik, die temporär möglichen Schwächen einer einzelnen früheren Software-Version dadurch auszutricksen, dass man den gesamten Datenbestand dauerhaft mit Krücken-Konstruktionen verseucht, und dazu auch noch „offiziell“ aufzufordern.

Das Beispiel „Müller-Lüdenscheid“ ist ja ebenfalls typografischer Unsinn, weil hier ganz normal getrennt wird, wie auch Lüden- scheid im normalen Text. Fordert man regelwidrig ein Zusammenhalten, würde es am rechten Rand eine übermäßige Lücke reißen. Der geschützte Bindestrich gehört zu sehr kurzen Bestandteilen (ein oder zwei Zeichen) wie in dem Artikel erwähnt, ansonsten etwa zu der chemischen Formel.

Ansonsten ist in HTML eine gesonderte hartkodierte Zeichenverwendung sinnlos, weil dies von den für Umbruch zuständigen Algorithmen im Browser übernommen wurde oder mittelfristig wird; die Spezialzeichen gehören weder nach HTML noch in den Wikitext, sondern in persönliche Textverarbeitung und Schriftsatz/DTP.

--PerfektesChaos 12:58, 1. Feb. 2011 (CET)

Nach Perhelions Eingriff hat es sich ja erledigt, und aufs techblog bin ich auch nur über die Mailingliste gestoßen. --Schnark 09:16, 2. Feb. 2011 (CET)

@Perhelion: Danke schön; ich gestehe, diese Seite seit mehr als fünf Jahren nicht mehr gelesen und auch nicht beobachtet zu haben. Der Hilfetext soll prägnant einen Überblick über häufige Syntaxelemente insbesondere in Wikisyntax geben, vor allem Newcomer anleiten – und keine umfassende Darstellung aller denkbaren und in bestimmten Zusammenhängen sinnvollen typografischen Feinheiten geben. Juja mit 333 edits (wohl vom Schiller-Gymnasium Pirna) war dazu wohl nicht berufen. --PerfektesChaos 09:50, 2. Feb. 2011 (CET)

Trotzdem werde ich mich zukünftig weniger in dieses Thema involvieren, bei dem Wort „5-jährig“ konnte ich mich nicht mehr beherrschen. Um den typografisch richtigen Bindestrich scheint es sich ja nicht zu handeln, s. Hilfe:Sonderzeichen#Satzzeichen unterschiedliche Größe? Nach nochmaligen Test stell ich fest das die Breite des Striches sich irgendwie verändert -- - (geschützt‑ist‑breiter?). Was in de:Wiki diesbezüglich eventuell noch fehlt ist dies: en:Wikipedia:Line break handling. -- Perhelion 10:27, 2. Feb. 2011 (CET)

Was ich jetzt festgestellt habe (ohne weiter zu recherchieren) ist, dass auf einem anderen PC die Bindestriche doch gleichlang sind (Win7, nicht gleichlang XP vermutlich einfach der Font) jedoch auch nicht optisch gleich, marginal sieht der geschützte weicher aus (am besten würde das wieder ein Screencopy zeigen, verblüffend).

-

‑

-- Perhelion 19:20, 2. Feb. 2011 (CET)

Tatsächlich bricht der IE6-8 am Bindestrich um (aber wen störts?) und beim IE6 sieht der Bindestrich auch tatsächlich gleich aus, beim IE8 ist er allerding doppelt so lang wie der geschützte!? -- Perhelion 09:56, 3. Feb. 2011 (CET)

Bei mir (FF, Arial) ist der geschützte Bindestrich etwas kürzer als der normale. --Schnark 10:03, 3. Feb. 2011 (CET)

Es gibt im resultierenden Text keinerlei Bedeutungs-Unterschied zwischen dem Allerwelts-ASCII-Bindestrich-Minus und den beiden Unicode-Varianten. Leser des dargestellten Textes brauchen keine Lupe, um aus einem Pixel oder dot Breitenunterschied irgendwelche Schlüsse zu ziehen. Es ist ins Belieben der Font-Designer gestellt, auch alle drei Strichelchen exakt deckungsgleich zu vereinbaren. Mindestens die beiden nicht für HTML, sondern für feinere Typografie gedachten Unicode-Striche sollten immer die identische Glyphe verwenden. Mahlzeit --PerfektesChaos 12:52, 3. Feb. 2011 (CET)

Wikieditor – Leiste entfernen

Hallo Schnark, erst mal vielen Dank für die tollen JS-Möglichkeiten, die du hier zur Verfügung stellst! Ich habe mal anhand deiner Anleitungen versucht, die Hilfeleiste im Bearbeiten-Fenster zu entfernen, es ist mir jedoch nicht geglückt. Könntest du einen raschen Blick auf meine vector.js werfen und mir sagen, woran es scheitert? Ist alles noch recht übersichtlich … Gruß, --Nirakka 19:02, 2. Feb. 2011 (CET)

Hallo nochmal, sieht alles ok aus von hier. Leere mal komplett den Cache vom Browser (manchmal funzt es nicht die einzelne Seite zu renewen), welchen benutzt du denn? (Vielleicht sieht Schnark den Fehler doch gleich) LG -- Perhelion 19:35, 2. Feb. 2011 (CET)

Ich leere den Cache grundsätzlich, nachdem ich Änderungen am JS vorgenommen habe. Ich verwende gerade den neusten Firefox (Stable). Gruß, --Nirakka 19:37, 2. Feb. 2011 (CET)

Drücke mal Strg+Umschalt+J, steht dort diesbezüglich ein Fehler? -- Perhelion 19:49, 2. Feb. 2011 (CET)

Hier mal ein Screenshot. --Nirakka 19:53, 2. Feb. 2011 (CET)

Problem behoben. Habe das Firefox-Addon userChromeJS mal deaktiviert und wieder aktiviert und im Zuge dessen natürlich den Browser neu gestartet. Auch wenn ich jetzt nicht weiß, ob das Deaktivieren oder der Neustart des Rätsels Lösung war – die Leiste ist jedenfalls weg. Gruß, --Nirakka 20:00, 2. Feb. 2011 (CET)

Oha* :) Das "fremde" Script wars jedenfalls (und stoppte wohlmöglich dein komplettes vector.js). Ich würde dir raten alle weiteren Scripte mittels Schnarks Modulverwaltung einzubinden (das fängt Fehler ab oder wie in der Anleitung beschrieben kannst du Module ohne zu editieren ausschalten). Die Scripte bei dir schaue ich mir auch mal an ;). bb -- Perhelion 20:07, 2. Feb. 2011 (CET)

Benutzer:TMg/autoFormatter.js

Hallo, ich würde gerne nach wie vor den o. g. autoFormatter benutzen. Leider funktioniert er nicht mehr, seit ich deine Module verwende, weder so noch so. Kannst du dir das mal angucken? Gruß, --Nirakka 01:23, 3. Feb. 2011 (CET)

Da im oben verlinkten Screenshot ein Fehler in autoFormatter.js zu sehen war, habe ich das Problem einfach mal weitergereicht. Falls das noch nicht hilft, wäre wieder die Ausgabe der Fehlerkonsole (sowohl im Bearbeiten-Modus als auch beim Lesen) wie oben hilfreich (Beschränkung auf „Fehler“ statt „Alle“ reicht). Hast du schon vorher die neue Werkzeugleiste verwendet? Funktioniert es im abgesicherten Modus? --Schnark 09:51, 3. Feb. 2011 (CET)

Ich habe im Zuge der JS-Änderungen meine Einstellungen unberührt gelassen. Unter Beta-Funktionen ist bei mir die erweiterte Werkzeugleiste aktiviert, die meinst du vermutlich. Im abgesicherten Modus funktioniert es ebenso wenig. Hoffentlich kann TMg da etwas machen! Gruß, --Nirakka 12:52, 3. Feb. 2011 (CET)

Was zeigt denn die Fehlerkonsole (Strg+Umschalt+J) an? --Schnark 12:53, 3. Feb. 2011 (CET)

Zu welchem Zeitpunkt? Im Bearbeiten-Fenster? Im abgesicherten Modus? --Nirakka 12:53, 3. Feb. 2011 (CET)

Für den Anfang würden mal die Fehler reichen, die beim Bearbeiten angezeigt werden. --Schnark 12:54, 3. Feb. 2011 (CET)

Wenn ich das richtig sehe, tritt nur der folgende Fehler auf:

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

Gruß, --Nirakka 13:10, 3. Feb. 2011 (CET)

Und nach Abschicken des Beitrags außerdem dieser:

Fehler: wgWikiEditorEnabledModules is not defined
Quelldatei: http://de.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=Benutzer:TMg/autoFormatter.js
Zeile: 226

--Nirakka 13:11, 3. Feb. 2011 (CET)

Ich habe das Script mal bei mir eingebunden, funktioniert auch, nur ich glaube nicht wie es sollte. Es staucht den gesamten Text zusammen indem alle Leerzeilen einfach gelöscht werden!? -- Perhelion 16:51, 3. Feb. 2011 (CET)

War bei mir jedenfalls nie so, als es noch funktioniert hat. --Nirakka 17:12, 3. Feb. 2011 (CET)

Aja, stelle auch gerade fest, dass es zufällig (momentan) nur der erste Artikel ist den ich getestet habe: Plants vs. Zombies was sagt der bei dir? -- Perhelion 17:20, 3. Feb. 2011 (CET)

Funktioniert bei mir gerade auf allen Seiten! War das des Rätsels Lösung? --Nirakka 17:22, 3. Feb. 2011 (CET)

Das ganze Durcheinander ist durch eine Schusseligkeit von mir verursacht worden. Ich hoffe, dass alle Folgefehler repariert sind. Ggf. Umschalt+Neu Laden klicken, um den Webbrowser zum Aktualisieren zu zwingen. Wenn es noch Probleme gibt, gebt mir bitte Bescheid. --TMg 17:52, 3. Feb. 2011 (CET)

(@TMg:) Wenn es bei euch funktioniert muss es im Zusammenhang mit einem Modul von Schnark sein!? Der Fehler tritt bei mir (immernoch) in mehreren Artikeln mit FF 3.6-4.0 Win XP,7 auf jedoch nicht in Chrom, den IE (6,8) konnte ich nicht testen da er von den Scripten scheinbar nicht unterstützt wird. @Nirakka das 2. Script von dir funktioniert nun seltsamer Weise auch nicht mehr (ajax_request undefinied, nun deaktiviert). @Schnark Modulkonfiguration funktioniert auch nicht mehr (Warnung: Leerer String an getElementById() übergeben.) -- Perhelion 22:35, 3. Feb. 2011 (CET)

Was genau tritt beim autoFormatter für ein Fehler bei dir auf? Bei mir bestand das Problem ja ausschließlich daran, dass sich der Button nicht anklicken ließ. Das Script macht im Übrigen das, was es soll (Feuerfuchs). Und was für ein 2. Script von mir meinst du? Den Nutzerstatus? Der hat bei mir nie Probleme gemacht. Gruß, --Nirakka 00:08, 4. Feb. 2011 (CET)

Dass der Fehler im autoFormatter erst nach der Umstellung auf mein Skript auftrat, lag einfach am Browsercache, der davor noch die alte Version ohne Fehler hatte. @Perhelion: Da du das Skript nur beim Bearbeiten einbindest, musst du den Browsercache komplett leeren, bei einigen der üblichen Cache-Leerungs-Tastaturkürzeln wird nämlich nur das aktualisiert, was in der augenblicklichen Seite eingebunden ist.

Zu "2. Script": Ich werden Benutzer:Steef389 gleich erklären, worin das Problem besteht, ab Dienstag wären vermutlich sowieso alle betroffen, die sein Skript verwenden.

Modulkonfiguration: Auf welchen Seiten tritt der Fehler auf (Nur Benutzer:Schnark/js/modulverwaltung, alle Benutzerseiten, …)? Erscheint die Tabelle gar nicht, oder nur fehlerhaft, oder tritt der Fehler beim aktivieren oder deaktivieren auf? Welcher Browser (insbes.: Ist er zu jQuery kompatibel)? --Schnark 09:24, 4. Feb. 2011 (CET)

Modulkonfiguration funktioniert bei mir einwandfrei, FF 3.6.13. Ist es denn generell sinnvoll, den wikieditor nur beim Bearbeiten einzubinden? --Nirakka 12:48, 4. Feb. 2011 (CET)