Benutzer:PerfektesChaos/js/editToolStrIns/x

aus Wikipedia, der freien Enzyklopädie
< Benutzer:PerfektesChaos‎ | js‎ | editToolStrIns
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 9. März 2022 um 22:11 Uhr durch imported>PerfektesChaos(310926) (linkupdate).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Diese Seite ist für die Diskussion programminterner Details vorgesehen.

Vorschläge für Definitionen von Einfügungen bitte auf der allgemeinen Diskussionsseite eintragen.

Zweiter Prototyp

Kopiert von BD:✓ #editToolStrIns:

  • Vollzug.
    • Eventuelle Auffälligkeiten bitte berichten (mit Opera bisher nur flüchtig rumgespielt).
  • Neugierig: Was sollen eigentlich deine UDF machen? Vielleicht lassen sich ja daraus noch ein paar allgemeinverfügbare Features bauen.

Beste Grüße --PerfektesChaos 21:28, 23. Nov. 2011 (CET)

Teste ich dann gleich mal. Freue mich schon auf mathLogic, das hab ich ständig vermisst:-) Kann das nicht gleich ins default-Modul wandern?
Wow, sowas gut dokumentiertes hab ich selten gesehen. Ich habs aber noch nicht geschafft, den ganzen Quellcode zeilenweise durchzugehen :-) Was mir aufgefallen ist:
  • Du verwendest ziemlich viel with-Statements. Abgesehen davon, dass sie die Code-Ausführung bremsen, finden es viele unübersichtlich - aber das ist halt dein Stil. Ich hätte eine große function verwendet, der der "Namespace" als Parameter übergeben wird.
  • Die Konfig mit ihren geschachtelten Arrays ist extrem unübersichtlich. Ich würde a) Schließende Klammern auf dieselbe Ebene wie die öffnenden stellen - und dabei eine neu Zeile "in Kauf nehmen" b) vielleicht keine Spezifikationen als Gruppen erlauben? c) Konstanten für die Typ-Nummer einführen (siehe Beispiel).
    Auf Objekte umstellen kommt wohl nicht mehr in Frage. Ich glaube nicht dass Weglassen von [] im "compressed mode" viel bringt.
if (! mw.libs.Insertion) mw.libs.Insertion = {};
(function(namespace) {
   var gui = namespace.gui = {};
   gui...

   var STR_SEQUENCE = 1;
   var HTML_STR = 0;
   var NO_SEPARATOR = [ 0, false ];
   ...
   namsepace.l10n['de'] = {
      hintList: "Zeichensatz auswählen",
      hintMenu: "Element auswählen",
      defs: {
         "example": [
            null, // wofür steht das hier gleich nochmal?
            [ STR_SEQUENCE, "ÄäÖößÜü" ],
            [ [ "„", "“" ], // hier fängt an...
              [ "‚", "‘" ],
              ...
              [ "›", "‹" ],
              [ "–", "", "", "Bisstrich/Gedankenstrich" ]
            ], // ...was dort aufhört
            [ ["+"], // besser verständlich als ohne Klammern - ist "+" etwa ein weiterer Array-Typ-Identifkator?
              [ "−", "", "", "mathematisches Minus" ],
              [ "·", "", "", "mathematisches Mal" ]
            ],
            NO_SEPARATOR, // kann selbst der Laie deuten
            [ STR_SEQUENCE, "×÷≈≠±≤≥²³½†#*‰§€¢£¥$¿¡∞‣•" ],
            [ [ "〈", "〉", "", "CJK: Spitze Klammern" ],
              "…", "→", "↔" ]
            ],
            [ HTML_STR, "<br />var: " ]
         ]
      }
   };
   ...
})(mw.libs.Insertion);
  • Ein schwerer Fehler schwant mir: Du hast die Sortierung der Liste der Reihenfolge der Keys im Object .l10n[...].list überlassen? Bitte noch umstellen. a) Es funktioniert zwar meist, doch keine Skriptengine der Welt garantiert diese Reihenfolge b) wie soll man das denn umsortieren können? Array.splice wäre hilfreich. Daher bitte list als Array von ids und die Titel in die entsprechenden i10n-Objekte (auf language-Ebene, während die Defs auf globaler Ebene liegen).
  • Tests: enableForAllFields() funktioniert leider noch nicht:-C, muss ich mal überschreiben:-) API und User-Anpassung werd ich mal ausprobieren – insbesondere warum mein Verschieben von #edittools (über die textarea) nicht mehr geht muss ich mal schauen. Ist aber immerhin schonmal anpassbar:-) Auffälligkeiten gibts keine, nicht mal bemerken tut mans wirklich – die Neuerung versteckt sich in einem Tooltip "TEST editToolIns 0.2":-)
@UDF: Weiß ich jetzt gar nicht mehr so genau, wofür ich das wollte:-) Bei den Editbuttons fehlt es mir extrem, und ich denke bei den Texteinfügungen lassen sich sicher ein paar nützliche Features finden. Wenn ich was entwickeln sollte, das nicht nur bei mir lauffähig ist (dependencies), dann schreib ich es in Repository. -- ✓ Bergi 00:52, 24. Nov. 2011 (CET)

<!-- wenn du die Diskussion lieber auf einer Skript-bezogenen Seite (auch auf mw:) weiterführen willst um sie der Nachwelt zu erhalten, einfach verschieben -->

  • Danke für die freundliche und intensive Stellungnahme.
  • Kopiert nach w:de:Benutzer:PerfektesChaos/js/editToolStrIns/x #Zweiter Prototyp.
  • Eine Antwort gibt es dort heute Abend, wenn ich mit dem Denken fertig geworden bin.
Liebe Grüße --PerfektesChaos 14:03, 24. Nov. 2011 (CET)

In der Reihenfolge subjektiver Wichtigkeit:

  • Reihenfolge im list Object
    Danke für den Hinweis, mit Version 0.3 auf Array geändert; genauso user.custom jetzt Array.
    Wohl kein existierender Browser ändert was an der Reihenfolge in einem Objekt. Mit dem Parsen kommt es als first comes first serves in den Speicher. Gleichwohl gibt es keinerlei Sprachdefinition, die eine Reihenfolge beim for…in vorschreibt, und soll natürlich sauber geschrieben sein. Gut aufgepasst.
    Beachte: list ist auch nicht dafür vorgesehen, mit splice manipuliert zu werden. Typischerweise wäre list statisch zu vereinbaren, sowohl auf Projektebene wie auch als user.list mit Vorrang. Um Optionen an die Spitze zu setzen, ist user.custom im Angebot – dieses übernimmt das Suchen, Umsortieren und Ausblenden von Optionen.
    Bereits implementiert, noch nicht getestet. Jetzt jeweils Array mit ID auf jedem geraden Index und sichtbarer Optionstitel auf dem ungeraden Index (+1).
    Achso, ja. Wenn man da nicht mit splice ran darf, muss man halt das ganze Ding neu setzen um an den hinteren Optionen was zu ändern – wird einem aber auch nicht erspart bleiben, da man ja auch wegen der Ladereihenfolge nur an user.custom ändern sollte. -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
    • Ja, wenn ein Benutzer schon an die Liste will, dann wird erwartet, dass er entsprechend der eigenen Sprachkünste aus den 35 Optionen der momentanen dewiki ein Dutzend als user.list macht.
    • Und wer Ungarisch oder Vietnamesisch besonders oft benötigt, kann sich mit user.custom hu und vi an die Spitze setzen.
    --PerfektesChaos 19:36, 25. Nov. 2011 (CET)
  • with-Statements und große function
    Dazu habe ich mich vorhin hier geäußert.
    Ich mag es einfach nicht, wenn zwischen öffnender und schließender Klammer 2300 Zeilen liegen. Solange das nicht offiziell wird, behalte ich den Stil aus C++ bei. Dort gibt es das Problem nur bei der (deklarativen) Klassendefinition, und da wird auch gemault, wenn das Statement über einige 100 Zeilen gehen muss. Bei der anschließenden Implementierung zu den Deklarationen hat jede Einheit dann ihre Qualifizierung.
  • Wirkung auf alle Felder
    Muss an Opera liegen, oder du hast vielleicht was verbastelt. Mit FF und IE geht es prinzipiell für alle textarea und Text-input (rev:103074) – wobei das Upload-Formular auf Commons auch noch muckt. Konnte ich noch nicht identifizieren; jQuery-Objekte sind mühsam zu debuggen.
    Es geht übrigens wohl auch mit den „EditTools“ (MediaWiki:Onlyifediting.js) – was daran liegt, dass dies wikibits::insertTags() verwendet, die als legacy durch die neue mw.toolbar.insertTags() realisiert sein müssten, der textSelection("encapsulateSelection") aufruft.
    Nö, liegt an MediaWiki. Wir laufen hier auf 1.18_WMF, und da heißt die relevante Code-Stelle noch immer $( '#wpSummary, #wpTextbox1' ). Allerdings ist auch richtig, dass ich sämtliche Inputboxen bis auf #wptextbox1, die es irgendwo gibt, im DOM umherschiebe oder gar ersetze - das könnte zu Fehlern führen :-) -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
    Wohl letzteres, denn ohne Bearbeitungskonflikt sind auch nur #wpSummary und #wpTextbox1 sichtbar, und zwischen den beiden kann ich auch mit IE und Opera und Chrome hin- und herfokussieren, auch mit Onlyifediting.js.
  • vielleicht keine Spezifikationen als Gruppen erlauben?
    Wer vieles bringt, wird manchem etwas bringen …
    Die optische Gliederung in Gruppen wie in dewiki und enwiki ist unverzichtbar; enwiki setzt wohl für die US-Highschool noch Erläuterungstexte davor. Alle bereits existierenden Erscheinungsbilder sind auch zu unterstützen.
    Ich rechne damit, dass sich über 100 Sprachdefinitionen in global.defs ansammeln werden. Sie werden bei jedem Abruf übertragen und müssen dort (von mir) den Umständen entsprechend möglichst gut komprimiert werden. Dazu bedarf es der Aneinanderreihung unterschiedlich gepackter Gruppenformate. Das hier für nur 16 Sprachen ist mir zu geschwätzig und bei Unicode-darstellbaren Einzelzeichen unpraktisch; im Übrigen herzlich ineffizient mit um 1000 einzelnen Zeichenketten.
    Den Code von global.defs muss niemand durchlesen, der sich als Benutzer oder projektweit seine eigene Definition schreiben will.
    Es bedarf vielmehr noch einiger glücklicher Beispieldefinitionen mit foo…bar, whaffle und ping-pong in den unterschiedlichen Formaten. Erfahrungsgemäß nehmen sich die Leute gern eine Kopiervorlage und tippen ihren eigenen Text über das foo bar.
    Solch ein Ragout, es muß Euch glücken …
  • Ich glaube nicht dass Weglassen von [] im "compressed mode" viel bringt.
    Es ist mir egal, ob jemand die Klammern um jede einzelne Spezifikation setzen möchte oder nicht. Das Skript versteht beides.
    Genau das meinte ich ja mit "keine Spezifikationen als Gruppen" erlauben. Aber richtig, wer liest schon die Quelltexte durch:-) -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
    Nebenbei eine Korrektur der Statistik:
    • jquery.wikiEditor: für 16 Sprachen (minimiert) 20 kB mit 2200 Zeichenketten
    • Ich: 14 kB für 70 Sprachen plus enwiki/dewiki, in 1300 Zeichenketten
    --PerfektesChaos 19:36, 25. Nov. 2011 (CET)
  • NO_SEPARATOR = [ 0, false ];
    Das wird sich mit Version 0.3 erledigt haben und bleibt als undokumentiertes Feature in der Schublade.
    Jetzt reicht ein schlichtes false für diesen zero width joiner &zwj; – die Ziffer 0 funktioniert auch.
  • Konstanten für die Typ-Nummer einführen
    Das würde voraussetzen, dass zuvor schon von mw die Definition in den Browser des Benutzers geladen wurde. Ansonsten ist weder die Definition des Objekts noch der Konstanten bekannt.
    Das kann aber noch Jahre dauern.
    Ich denke, das ist nur der erste Kulturschock. Nach kurzem Einlesen und Gewöhnung findet man für seine eigenen Definitionswünsche schon sein individuelles Format. Nach kurzem Hinsehen kommt man auch ohne die Anleitung und Beispielsammlung auf die Kodierung.
    Insgesamt wird nur eine Handvoll Leute weltweit und eher auf Projektebene völlig neue Menü-Definitionen schreiben. Wenn, dann nimmt man bereits vorhandene Definitionen, überschreibt sie und schiebt sie mit Silvana+Gutti zusammen.
    Für Benutzer wohl interessanter ist die persönliche Konfiguration der Auswahlliste.
    Die Konstanten hab ich auch nur für die Leserlichkeit der Definitionen gedacht, nicht für Benutzeranpassungen - es sind ja nur lokale Variablen. Aber stimmt, es gilt dasselbe wie oben: Den Quelltext liest niemand und alle Welt arbeitet mit c&p-Snippets. -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
  • Schließende Klammern auf dieselbe Ebene wie die öffnenden stellen - und dabei eine neu Zeile "in Kauf nehmen"
    Das ist eine Frage, die man auf der Seite mit Beispielen umsetzen kann.
    Der zentrale Quellcode muss das nicht zwingend für die global.defs so handhaben.
    Die Definitionen auf Projektebene mag sich jeder selbst formatieren wie er mag. Die dewiki und enwiki stehen ja nur übergangsweise im zentralen Skript.
    Ansonsten meckert Schnark öfters, wenn ich zuviele Zeilen nehme – und da war doch noch jemand?
    Ja, natürlich tippe ich eine Zeile schneller als \n\t\t… Wenn ich es ausführlich mache (immer öfters), achte ich aber strengst darauf, dass schließende )}] auf derselben Ebene wie die öffnende Zeile stehen. -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
    Das handhabe ich bei normalen Kontrollstrukturen genauso; sogar mit einem Kommentar bei wichtigen schließenden Klammern. Aber hier in den defs bringt es nur drei Fast-Leerzeilen, und die Struktur ist durch die führenden ID bereits eindeutig erkennbar. Und dass die Arrays mit der angemessenen Zahl schließender Klammern versehen sind, darf man locker unterstellen. --PerfektesChaos 19:36, 25. Nov. 2011 (CET)
  • Auf Objekte umstellen kommt wohl nicht mehr in Frage.
    Das kommt schon allein deshalb nicht in Frage, weil die Reihenfolge der Zeichenketten von Bedeutung ist …
    Schon klar, ich meinte sowas wie [{type:"charsequence", values:"abcdefg"}, …]. Auch hübsch (vielleicht nicht so effizient, da bereits zu Definition ausgeführt): [charsequence("abcdefg"), tupel(503, 512), …] oder so… Ist aber wie bei den Konstanten, es ist reine Stilsache und würde auf verschleiernden, lokalen Funktionen basieren. -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
  • Zu UDF fiel mir inzwischen ein Beispiel ein:
    Datum in Internetquelle – hatte ich nicht sogar von dir in den letzten Tagen irgendwo gelesen, wie du es jemand erklärt und auf den Bookmarklet-Vorschlag in der Vorlage verwiesen hattest?
    Jedenfalls werde ich für cite web eine Beispiel-UDF schreiben und in die künftige Snippet-Sammlung stellen.
  • nicht mal bemerken tut mans wirklich
    Schon mal mit dem Teil im VNR gewesen?
    Gut, die nr-spezifischen Listen sind aber auch das einzige sichtbare… Nur dass ich im VNR höchstens beim Dokuschreiben mal die Sonderzeichenleiste nutze, und dass ich das Selektionsmenü zu benutzen hab ich mir schon lange abgewöhnt - außer „Standard“ konnte ich nichts gebrauchen. -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
    Tja, dann warte mal das Austesten am Wochenende ab, und dann lohnt sich die Komposition eines @Bergi in user.defs, und das user.custom = ["@Bergi", "meins!"];
    Die dewiki-Definition bildet ja auch bewusst den momentanen Zustand von MediaWiki:Onlyifediting 1:1 nach, genauso wie die enwiki mit einer kleinen Abweichung beim recycelten IPA deren Tool simuliert. Jede andere Umgestaltung würde bei Einführung erst eines MB bedürfen – wo ist mein geliebtes Litauisch geblieben?
    --PerfektesChaos 19:36, 25. Nov. 2011 (CET)

Vorschau auf Version 0.3:

  • list und user.custom als Array.
  • Mitselektiertes Leerzeichen am Ende des gesamten Wikitextes bei WikEd rauswerfen.
  • zero width joiner durch false
  • UDF kann encapsulateSelection-Objekt zurückgeben und braucht nicht mehr selbst einzufügen.
  • Modi replace und RegExp werden ausgetestet sein.

Realistisch: Ende des Wochen-Ende

So, und jetzt Gute Nacht! --PerfektesChaos 01:50, 25. Nov. 2011 (CET)

Danke für die umfangreiche Antwort. Ich hab einfach mal dazwischengeschrieben, in der Hoffnung dass es dich nicht stört. Freue mich schon auf 0.3! BTW: Die Leerzeichen-vor-Satzzeichen-Entfernung in deinem WikiSyntaxTextMod springt auf meine Smileys an (auch wenns dein BNR ist). -- ✓ Bergi 15:56, 25. Nov. 2011 (CET)
  • Und wieder mal ein neues Phänomen für WSTM: Smileys. Ich werde die (nicht standardmäßige, sondern benutzerdefinierte) Satzzeichenkorrektur um nach Doppelpunkt- oder Semikolon-Augen auftretende Nasenformen ergänzen. Sonst ist er den ANR gewohnt. Richtig erkannt: Es ist eine Seite in meinem eigenen BNR, und keine BD; nur deshalb sprang WSTM an. ;-)
  • Dazwischenschreiben ist okay, der Diskussionsfluss ist ja nachvollziehbar.
Und an dieser Stelle nochmal offiziell und abschließend: Schönes und sonniges Herbstwochenende --PerfektesChaos 19:36, 25. Nov. 2011 (CET)
So, noch ein paar Fragen und Beobachtungen:
  • Was benutzt du denn für ein minfy-Tool? Die Zeilenumbrüche drinzulassen gefällt mir sehr, nur habe ich das nirgendwo gefunden.
  • Es gibt leider noch kein Doku für .user. Liege ich richtig, dass user.custom vorne an die Liste drangebappt wird (evtl. nach oben holt) und user.list die Default-Liste überschreibt?
  • Das Skript instanziert sich eine Toolbar in sämtlichen auf der Seite vorkommenden .mw-editTools, funktionieren tut jedoch nur eine davon. Mein Vorschlag: .gui.$wrapper werde ein Element mit id (div#editToolStrIns) statt Klasse. Beim Init wird nach einem Element mit dieser id gesucht und nur wenn keines gefunden wird, wird in $(".mw-editTools").first() eines erschaffen.
  • Ich persönlich finde die vielfache Wiederholung von <…><…/> zumindest bei den Extension- und Inclusion-Tags ziemlich störend, vielleicht magst du die 4. Stelle mit den tagname füllen. Außerdem fände ich es super, wenn du Mathlogic und Symbols im globalen def-Repository statt in dem für enwiki bereitstellen würdest, mein Userscript sieht derzeit etwas merkwürdig aus:
defs: {
 get MathLogic() { return [null, mw.libs.editToolStrIns.l10n.enwiki.defs.MathLogic[0]]; },
 get Symbols() { return mw.libs.editToolStrIns.l10n.en.defs.Symbols.slice(0, -1); },
 …
}
Antwort unter #Vierter Prototyp --PerfektesChaos 23:43, 30. Nov. 2011 (CET)

Dritter Prototyp

0.3 soeben live gegangen.

  • Insbesondere Objekt-Array wo Reihenfolge maßgeblich.
  • Doku-Seiten noch nicht überarbeitet, nachmittags oder heute Abend, mal sehen.

Enjoy. --PerfektesChaos 09:36, 28. Nov. 2011 (CET)

Vierter Prototyp

  • 0.4 mit verbessertem WikEd-Handling und Kleinkram live.
  • Doku aktualisiert.

VG --PerfektesChaos 13:36, 30. Nov. 2011 (CET)

  • Was benutzt du denn für ein minfy-Tool?
    • Mein eigenes. Traue niemandem, erst recht nicht dem MW-minifier.
    • Ich habe ihn in LISP geschrieben; wenn du damit wirklich was anfangen kannst, klaube ich die Komponenten aus meinen Bibliotheken zusammen und stelle ihn auf eine Unterseite.
    • Wenn unerwartet eine Produktivversion abschmiert, kann man das Statement nachlesen; mindestens die Programmeinheit erkennen und sogar unmittelbar debuggen. Wenn jQuery mit Zeilenlänge 1000 auf die Nase fällt, weil irgendein Spendenbanner irgendein kaputtes Event schießt, habe ich selbst müde Blicke aufgegeben.
    • Ich lasse nicht nur die Zeilenumbrüche drin, sondern auch wichtige Kommentare; etwa mit Datum oder nowiki. Außerdem verkette ich meine String-Literale vorab.
  • Es gibt leider noch kein Doku für .user.
    • Es gibt sowohl die en (Oberseite deines Beispiels) wie auch ins Deutsche rückübersetzt, aber vielleicht nicht verständlich genug und bislang mager an Beispielen.
  • Liege ich richtig, dass user.custom vorne an die Liste drangebappt wird (evtl. nach oben holt) und user.list die Default-Liste überschreibt?
    • Jep. “The non-false assignments appear on top of the selection list.” und „Die Zuweisungen ungleich false erscheinen am Beginn der Auswahlliste“. Weiters: “Set this list as authoritative.”
  • Das Skript instanziert sich eine Toolbar in sämtlichen auf der Seite vorkommenden .mw-editTools, funktionieren tut jedoch nur eine davon.
    • Bislang ist an unmanipulierte Standard-Skins und Formulare gedacht, die nur ein Element in der Klasse .mw-editTools enthalten.
    • Wenn es mehrere Elemente der Klasse .mw-editTools gibt, muss ich davon ausgehen, dass der Benutzer mehrere Bearbeitungsbereiche hat, deren jedes mit Werkzeugkasten ausgestattet werden soll. Im weiteren Entwicklungsgang kann auf diese Situation eingegangen werden. Dazu muss ich aber erstmal jQuery-Erfahrungen sammeln, welche $Elemente zu klonen wären (ich füchte: alle). Das Datenmodell wird ja geteilt. Coding #Multiple tool areas benennt den momentanen Stand. Insgesamt hört sich das schlimmer an, als es ist, weil nur der ohnehin einmal generierte .gui.$container entsprechend oft tiefgeklont werden müsste; es docken sowieso immer nur Klone der einmal gebauten Menüs daran an, wenn eine andere Option selektiert wird.
      • Nachtrag: Mittlerweile wurde der Quellcode wie folgt geändert: Es werden beliebig viele Elemente ausgestattet (noch nicht ansatzweise getestet). --PerfektesChaos 20:05, 2. Dez. 2011 (CET)
    • Um auf deiner speziellen Seite vielleicht besser klarzukommen, könnte ich ggf. eine neue API-Funktion .run() anbieten, die zum gewünschten Zeitpunkt die Initialisierung beginnt. Ein öffentliches .off=true verhindert bereits den automatischen Start, allerdings aus anderem Hintergrund.
      • Nachtrag: Mittlerweile wurde der Quellcode wie folgt geändert: Mit .off=true den automatischen Start nach dem Laden verhindern; mit .update() nachholen. --PerfektesChaos 20:05, 2. Dez. 2011 (CET)
    • .gui.$wrapper werde ein Element mit id (div#editToolStrIns) statt Klasse. Beim Init wird nach einem Element mit dieser id gesucht und nur wenn keines gefunden wird, wird in $(".mw-editTools").first() eines erschaffen. – wie vor; mehrere Instanzen und damit weder .first() noch andere Landeplätze.
  • Ich persönlich finde die vielfache Wiederholung von <…><…/> zumindest bei den Extension- und Inclusion-Tags ziemlich störend
    • Die sind für meine Oma.
    • Der momentane Zustand ist praktisch 1:1 der momentanen Onlyifediting nachgebaut, so dass kaum Unterschiede zu bemerken wären.
    • Weniger syntaxfeste Benutzer brauchen das und kapieren es sonst nicht.
    • Der Sinn, warum ich eine benutzerkonfigurierbare Alternativlösung geschrieben habe, ist gerade, dass diejenigen sich ihre eigenen Formate und Zusammenstellungen bauen können, denen irgendwas nicht gefällt.
  • Außerdem fände ich es super, wenn du Mathlogic und Symbols im globalen def-Repository statt in dem für enwiki bereitstellen würdest.
    • Wenn ich etwas in defs.global hineinschreibe, muss ich auch eine weltweite Ewigkeitsgarantie abgeben. Das habe ich bislang nur für Finance getan.
    • Ich weiß kaum, was genau weltweit dauerhaft MathLogic ist (A, B, X); noch viel weniger weiß ich, was Symbols sein sollen: Spielkarten, Dingbats, Pfeile, Sternzeichen, Schachfiguren, Religionszeichen, Schaltpläne, Landkarten, Musiknoten, Architekturzeichen? Welche Auswahl? Und in welcher Reihenfolge? Mit mathematischen Zeichen habe ich mich gerade erst bei TeX durchgequält und noch keine allseits und jeden befriedigende Reihenfolge und Struktur gefunden.
    • Kopier (+paste) dir einfach die Definitionen und bau sie dann so um, wie du sie haben möchtest; dazu ist es da. Die enwiki stehen nur temporär drin. Es gibt auch eine enwiki-Version von Kyrillisch, alle acht Zeichen eine Verschnaufpause, abwechselnd ein Groß- und ein Kleinbuchstabe; und eine globale, erst alle Großbuchstaben in einem Zug und dann als neue Gruppe alle Kleinbuchstaben (was bei allen Sprachen geht, weil bei „ß“ und anderen nicht immer Paare auftreten). Es wäre bei Einführung Sache lokaler Projekte, sich per MB und Kampfabstimmung über die standardmäßig angebotenen Sprachen, ihre Reihenfolge und dann die Sortierung und die angezeigten Titel zu streiten. Das mag dann projektweit als übersichtliche Basisversion angeboten werden, und jeder fortgeschrittene Benutzer baut sich sein eigenes „0“-Standardmenü nach individuellen Bedürfnissen. Und wer spezielle, für uns exotische Sprachinteressen hat, der holt sie sich an die Spitze der Auswahl, und dafür mag man Maltesisch oder Galicisch oder Sorbisch oder Isländisch (zusätzlich zu Skandinavisch) im Standardangebot weglassen. Wer kann in der dewiki schon Thai oder Laotisch?
Hoffentlich zum Verständnis beitragend, bald bettreif, Gut’s Nächtle --PerfektesChaos 23:43, 30. Nov. 2011 (CET)

Andere Projekte

Commons

wikisource.de

Abgerufen von „https://de.wikiup.org/index.php?title=Benutzer:PerfektesChaos/js/editToolStrIns/x&oldid=220954810“