Wikipedia Diskussion:Typografie/Automatische Leerzeichen

entwicklungsphase

thread automatische leerzeichen herverschoben von WD:TYP. -- seth 00:04, 25. Aug. 2012 (CEST)

gudn tach!
in bugzilla:18443 kommt derzeit mal wieder etwas bewegung rein. es geht dabei um das automatische anzeigen richtiger leerzeichen, ohne dass wir autoren haesslichen source code schreiben muessen. wenn wir als autoren also etwa schreiben "100 m" oder "z.B." oder "z. B." oder "S. 616" , dann soll das dem Leser "richtig" dargestellt werden. "richtig" heisst, dass da jeweils ein umbruchgeschuetztes schmales leerzeichen reingesetzt werden sollte. aber nur in der darstellung! und nicht im wiki-source-code! das bewahrt die lesbarkeit des source-codes, nimmt usern etwas typografische denkarbeit ab und fuehrt aber letztlich trotzdem zu einem typografisch saubereren ergebnis.
beim prozentzeichen ist sowas aehnliches bereits jetzt der fall. allerdings wird da derzeit aus dem leerzeichn in "5 %" nur ein normalbreites umbruchgeschuetztes leerzeichen gemacht. bewerkstelligt wird das ganze mithilfe regulaerer ausdruecke.
mein anliegen hier ist nun, dass wir gemeinsam ein konzept fuer diesen automatismus entwerfen. ob er dann letztelich von den developers umgesetzt wird, sehen wir dann. ich fange mal mit einer tabelle an, und werde die im laufe der diskussion weiteranpassen. -- seth 22:22, 27. Jul. 2012 (CEST), 10:38, 28. Jul. 2012 (CEST)

+1--*thing goes (Diskussion) 22:45, 17. Mai 2016 (CEST)

tabellen verschoben auf die projektseite. -- seth 00:04, 25. Aug. 2012 (CEST)

oh, ich muss weg. aeh, ich schick das jetzt aber trotzdem ab und schreib morgen weiter. -- seth 22:22, 27. Jul. 2012 (CEST)

noch abzuklaeren: wie ist locale eingestellt: was matcht \b als wortgrenze? was ist z.b. mit hochzahlen? -- seth 10:38, 28. Jul. 2012 (CEST)

Heinzelmännchen …

• Deutschsprachig

  Die häufigsten mehrteiligen Abkürzungen in deutschsprachigen Texten sind (ohne akademische Titel wie Dr. med.):

  a.a.O. a.D. d.h. d.i. d.Ä. d.J. d.R. e.V. h.c. i.A. i.d.F. i.d.R. i.R. i.S.d. i.V. m.W.v. n.Chr. o.Ä. o.J. s.o. s.u. u.a.m. u.a. u.Ä. u.U. u.v.a. v.a. v.Chr. v.u.Z. z.B. z.S. z.T.

• International
  1. Eine Zahl,
  2. ggf. gegliedert durch ,.' als englische deutsche schweizerische Tausendertrennzeichen
  3. ggf. mit ., als Dezimaltrennzeichen, aber passend zum Tausendertrennzeichen
  4. ggf. in Exponentialschreibweise
  5. gefolgt von einem Kurzzeichen wie (kleine Auswahl an Beispielen):

     $ ₤ € ¥ ₳ ฿ ₵ ¢ ₡ ₢ ₫ ₯ ₠ ₴ ₭ ℳ ₥ ₦ № ₰ ៛ ₨ ₪ ৳ ₮ ₩ DM US$ USD EUR CHF CAD AUD GBP °C °F °R kB MB GB TB m s l t kg m/s m/s² t/m³ g/cm² g/l mmol/l kg/m² kg/l t/m² km/h A F H N T V Bq Cd Pa Sv mol VA V/m mA N/m² pF N/m³ sm kn µm mm cm hm km m² cm² km² mm² m³ dm³ cm³ mm³ km³ ha Ar hl dl cl ml µF µV eV W kW MW Ws kWh mW MW GW kV Ω kΩ mΩ

  Zu beachten ist, dass es zwei gleichberechtigte µ gibt; ein älteres ANSI-µ bei U+00B5 und ein späteres im Kontext des ganzen Alphabets bei U+03BC.

• Anmerkung zu den Guillemets

  Ich bin damit nicht richtig glücklich. Im deutschen Schriftsatz zeigen sie nach innen. Dementsprechend wird der Donaudampfschifffahrtskapitän »Heinrichson« zusammenhängend mit drei Wörtern in der Zeile verklumpt. (Ggf. Fenster schmaler ziehen) Solche Regeln sollten von der Sprache des Textes abhängig gemacht werden, wobei wir noch die Deutschschweizer haben; die sind aber durch schweizbezogen markiert, woraus man eigentlich eine Content-Language de-CH ableiten könnte.

• Die Technik sollte von der Grundsprache der Seite (des Projekts) abhängig gemacht werden. Auf meta: sollte es die Sammlung der jeweils sprachbezogenen Zusammensetzungen nebst Auflösung geben, die weiterentwickelt werden kann und Basis wie Dokumentation für Programmierer sein müsste.
• Gut finde ich den Ansatz mittels <span> statt eines Zeichens; damit sind Suchvorgänge möglich, bei denen sonst utopische Unicode-Eingaben erforderlich wären, und Darstellungsprobleme bei mangelhaften Zeichensätzen im weltweiten Einsatz können nicht entstehen. Nicht restlos verstanden habe ich oben die Konstruktion mit display:none; ein <span /> mit der entsprechenden width müsste eigentlich reichen (was kein Zeichen wäre); das unsichtbare Leerzeichen mit display:none ist lediglich für Suchvorgänge gedacht?

Schönes Wochenende und gutes Gelingen --Gräfin Typo (Diskussion) 08:03, 28. Jul. 2012 (CEST)

oh, toll! heinzelmaennchen! :-) hab schon mal einen teil oben eingebaut.

dass die substitutionen sprachabhaengig erfolgen sollen, habe ich im bug-ticket bereits angesprochen. sehen die da auch so.

• abkuerzungen wie "Dr.": brauchen wir die? wobei ohnehin zu ueberlegen waere, ob wir so viele seltener gebraeuchliche abkuerzungen ueberhaupt supporten wollen.
• zahlen: es ist kompliziert, rein syntaktisch zu erfassen, wann innerhalb von zahlen leerzeichen eingefuegt werden sollen und wann nicht.
• guillemets: stimmt, das hab ich mir auch schon gedacht, koennte man in dem kontext mal im bugtracker ansprechen.
• zum span-monster: im bugticket habe ich die diskussionen dazu verlinkt. ich denke, da sollte irgendwo auch was dazu stehen.

-- seth 10:38, 28. Jul. 2012 (CEST)

Meiner Meinung nach sollten die typographischen Leerzeichen – so wie die anderen typographischen Sonderzeichen – bei der Eingabe und nicht bei der Ausgabe erzeugt werden. Die Unicodezeichen sollten also in der Datenbank stehen und zwar direkt in UTF-8 und nicht als HTML-Entität. Die Ersetzungsregeln bei der Ausgabe sind immer wieder fehlerhaft und stören an einigen Stellen. Beispielsweise ist das automatische geschützte Leerzeichen vor dem Prozentzeichen in Tabellen und Überschriften fehlerhaft. Statt Ausgaberegeln sollte meiner Meinung nach der Editor verbessert werden, damit bei der Eingabe bereits die geschützten Leerzeichen eingegeben werden. --Fomafix (Diskussion) 12:55, 28. Jul. 2012 (CEST)

+1--*thing goes (Diskussion) 22:45, 17. Mai 2016 (CEST)

Der Editor gehört zum jeweiligen Browser, den können die Wikimedia-Leute nicht verbessern. Ausnahmen könnte man mit Sonderformatierung behandeln (übrigens: konkrete Beispiele wären interessant). Natürlich ist das nur dann eine gute Lösung, wenn diese Ausnahmen äußerst selten sind. --84.130.154.214 13:27, 28. Jul. 2012 (CEST)

Zu UTF-8: Das fände ich eigentlich auch besser. Leider wird z.B. das geschützte schmale Leerzeichen, wenn ich mich richtig erinnere, von vielen Ausgabegeräten nicht richtig oder überhaupt nicht unterstützt, auch c&p, Suchen, Umwandeln in andere Formate usw. müssen darauf eingestellt sein, und an vielem davon können die Wikimedia-Leute nichts ändern. --84.130.154.214 13:56, 28. Jul. 2012 (CEST)

Der Editor des Browsers kann mit JavaScript beeinflusst werden. Die einfachste Umsetzung wären Ersetzungsregeln vor dem Speichern durchlaufen werden. Besser sind natürlich vom Anwender beeinflussbare Eingabemöglichkeiten. Ob UTF-8 oder HTML-Entitäten hat erst mal nichts mit der Ausgabe zu tun. Wenn es konkrete Probleme mit einzelnen Zeichen bei bestimmten Browsern gibt, kann können hier Ausgaberegeln angewendet werden, bei der diese Unicodezeichen – egal ob als HTML-Entität oder als UTF-8 – durch passende Alternativen ersetzt werden. --Fomafix (Diskussion) 14:31, 28. Jul. 2012 (CEST)

Nach meiner Erinnerung war das Problem, dass der Editor bei Mozilla-Browsern geschützte Leerzeichen durch normale ersetzt, und zwar bei jedem Speichern. --84.130.154.214 14:53, 28. Jul. 2012 (CEST)

Ja, das ist richtig. Der aktuelle Firefox macht das aber anscheinend nicht mehr. Beispiel: „ “ Mit welcher Version dieser Fehler im Firefox behoben wurde, kann ich aber nicht sagen. --Fomafix (Diskussion) 15:30, 28. Jul. 2012 (CEST)

gudn tach!

ich hab noch nicht verstanden, was Fomafix meint: wo genau ist das umbruchgeschuetzte leerzeichen vor einem prozentzeichen falsch/stoerend? im bugticket wurde ja ebenfalls als punkt herausgestellt, dass die fehleranfaelligkeit extrem niedrig sein muss.

unicode-whitespace bei der eingabe hat zwei nachteile: 1. man sieht ihn nicht und kann ihn nicht gescheit unterscheiden (z.b. von gewoehnlichen leerzeichen 0x20) oder bei eingabe ueber entities: der wiki source code wird haesslich/schlechter lesbar vor allem fuer neulinge. 2. iirc gab es copy-paste- sowie suchprobleme bei der verwendung nicht-gaengiger leerzeichen. 3. die browserproblematik ist afaik nach wie vor vorhanden und wird vermutlich erst in ein paar jahren als ausgestorben zu bezeichnen sein, siehe dazu die im bugticket angegebenen links. da wurde bereits ausgiebig drueber diskutiert. -- seth 10:26, 29. Jul. 2012 (CEST)

Ich habe den Fehler als Bug 38797 gemeldet. --Fomafix (Diskussion) 20:37, 29. Jul. 2012 (CEST)

ok, scheint aber etwas zu sein, dass a) extrem selten auftritt und b) leicht zu beheben ist. -- seth 22:45, 30. Jul. 2012 (CEST)

• deutschsprachige Abkürzungen
  • \b – Vor einer der genannten Abkürzungen muss immer ein Leerzeichen/Zeilenumbruch oder eine öffnende runde Klammer stehen. Ist das nicht der Fall, handelt es sich eher um einen Satzfehler/Schreibfehler oder den falschen Kontext. So gibt es irgendwelche Western-Dampflokomotiven G.W.R.o.N.Y. oder dergleichen; vielleicht ist es Teil einer biochemischen Formel oder ein astronomischer Bezeichner oder sonstwas. Solche würden \b erfüllen und ein unerwünschtes Leerzeichen in eine Formel usw. einfügen.
  • In vielen Wikitexten sehe ich, dass bereits explizite &nbsp; in den Abkürzungen eingefügt wurden. Auch diese sollten von &#160; in neue Pseudo-nnbsp umgewandelt werden.
  • Die über Nacht herbeigezauberte Liste häufiger Abkürzungen stammte aus der Bürokommunikation. In der Verwendung mögen sich Korrespondenz und enzyklopädische Texte unterscheiden. Ein Datenbankauszug könnte statistisch analysiert werden – \ba\.( | )?D\. – betreffend Oberst a.D., Hauptmann d.R., Pfarrer i.R., Leutnant z.S. und sich als irrelevant erweisende Muster können ausscheiden.
  • Einige Abkürzungen von Floskeln könnten auch in Großschreibung am Satzanfang stehen, wobei Z.B. und U.U. optisch und sprachlich grässlich sind und von WP-Autoren anders formuliert werden sollten. D.h. ist meist auch kein stilistischer Gipfel, aber nicht so schlimm wie zwei Großbuchstaben.
  • Aus alter Rechtschreibung gibt es noch z.Zt. / z.Z.
• Unicode im Wikitext
  • Wie l.seth schon richtig ausführte, haben Normalbenutzer keinerlei Möglichkeit, die Zeichen im Bearbeitungsfeld zu unterscheiden; es sei denn, sie würden WikEd benutzen und hätten sich intellektuell mit der Bedeutung der unterschiedlichen Dinger auseinandergesetzt.
  • Würden nun Unicode-Leerzeichen in den Wikitext eingebracht, etwa automatisch beim Abspeichern, dann würden durch C&P im Lauf der Zeit umbruchgeschützte schmale Leerzeichen im Wikitext verstreut werden und an Stellen und zwischen Wörtern landen, zwischen denen kein schmales Leerzeichen erwünscht ist, erst recht der Umbruch auf mysteriöse Weise verhindert würde. Hier spukt’s!
  • Beim Suchen nach Zeichenketten im Wikitext und HTML würden dann manche gefunden werden, andere seltsamerweise nie.
  • Wenn typografisch anspruchsvollere Zeichencodes im Wikitext verwendet werden, dann sollten sie auch einen deutlich sichtbaren Mehrwert im Endprodukt haben; erst recht dann, wenn sie im normalen gleichabständigen (monospace) Bearbeitungsfeld nicht sichtbar zu unterscheiden sind. Der Halbgeviertstrich (etwa als Gedankenstrich) sieht beim Bearbeiten zwar aus wie der Viertelgeviertstrich („Bindestrich“), aber bringt eine erhebliche optische Verbesserung. Das &nbsp; ist für Autoren sichtbar, und mittlerweile hat man sich daran gewöhnt – im Gegensatz etwa zu 2006. Typografische Anführungszeichen lassen sich im Bearbeitungsfeld voneinander unterscheiden, wenn es auch beim ASCII-Apostroph und den Akzentzeichen gelegentlich etwas hapert. Hingegen ist der Vorteil des etwas schmaleren Abstands zwischen einem z. und einem B. und ein möglicherweise noch nicht vorhanden gewesener Schutz vor Umbruch kein weltbewegender Vorteil; wenn das nachgeschaltet ohne Belästigung der Benutzer und ohne revert des Wikitextes und dessen kodierungstechnische Überwachung realisiert werden kann, mag man es angehen.
  • Hinzu kommt, dass nicht zweifelsfrei sichergestellt ist, dass alle Leser weltweit die Unicode-Leerzeichen korrekt dargestellt bekommen; dann ist aber der Schaden größer als der begrenzte Nutzen.
• HTML-Konstrukt
  • Allmählich erschließt sich mir der Sinn: Wenn das im fertigen HTML-Dokument mit C&P verbreitet wird, entsteht ein ASCII-Leerzeichen zwischen den beiden Nachbarn und keinerlei Unicode-Leerzeichen wird generiert. Beim manuellen Suchen im Text wird es mit Leerzeichen gefunden. Sehr schön!
• Prozentzeichen

  Ich hatte das so verstanden, dass vor dem Prozentzeichen eine Ziffer 0–9 und ein Leerzeichen stehen müssen.

  Das gibt zwar immer noch unbeabsichtigte Trffer wie beim DOS-Macro

  ECHO %1 %2 %3 %4

  vermeidet aber das angesprochene Problem.

Liebe Grüße --Gräfin Typo (Diskussion) 09:01, 3. Aug. 2012 (CEST)

Es sollte sich eigentlich auch längst bis zur Gräfin Typo herumgesprochen haben, dass zwischen Teilen einer Akürzung wie „z. B.“, „a. a. O.“ usw. Leerzeichen stehen, und Beiträge vom (nur bedingt, wie ich weiß) lustigen Seth mit seiner permanenten Kleinschreibung sind oftmals überhaupt nicht geeignet, Klarheit in eine Diskussion hereinzubringen! --Ronald (Diskussion) 06:47, 5. Aug. 2012 (CEST)

gudn tach!

oh, viele ergaenzungen von Gräfin Typo. :-)

zu den dt.-spr. abk.:

• \b bei abkuerzungen ersetzen: richtig. hab's oben eingebaut.
• nbsp war schon drin; #160 ist es jetzt auch
• vorkommnisse an abkuerzungen: da werde ich mal jemanden fragen.
• grossschreibung am anfang: eingebaut.
• abk. von "zur Zeit/zurzeit": eingebaut

unicode: da stimme ich uneingeschraenkt zu. weltbewegend ist der vorteil wirklich nicht, aber er wuerde (laengerfristig) viele viele ueberfluessige edits verhindern.

html-konstrukt: ja, das ist ziemlich genial. bastelte user:Quilbert in jahr 2008. damals hatten wir versucht, es ueber eine vorlage {{\}} einzufuehren, vergeblich (und im nachhinein betrachtet wohl auch zurecht, weil die methode ueber php weitaus sauberer ist.)

prozentzeichen: derzeit lautet die substitution '/(.) (?=\\?|:|;|!|%|\\302\\273)/' => '\\1 ', d.h., vor einem '%' muss stehen: ein beliebiges zeichen (ausser einem zeilenumbruch), gefolgt von einem leerzeichen. dass das fehleranfaellig ist, hat Fomafix in bugzilla:38797 dargelegt. ziffern (und ein leerzeichen) sind aber nicht das einzige, was vor einem prozentzeichen stehen duerfte, wenn ein schmales, umbr.-gesch. leerzeichen besser waere. beispiele:

• variablen: "a %"
• terme: (a+b) %

wobei man sich ueberlegen koennte, ob man da vielleicht tatsaechlich einfach besser tex oder ein manuelles nbsp verwendet. ich sprech's mal im bug ticket an.

in pre-tags und in code-tags sollten die substitutionen eigentlich ohnehin nicht ausgefuehrt werden. denn zum einen werden da eh monospace-fonts verwendet und zum anderen wird zumindest in pre eh nicht automatisch umbrochen. in code kann alles moegliche stehen. -- seth 10:23, 5. Aug. 2012 (CEST)

gudn tach!

hab noch "Art./Abs./S." (gefolgt von einer zahl) ergaenzt. -- seth 23:59, 10. Aug. 2012 (CEST)

gudn tach!

hab jetzt mal selbst einen w:de-dump nach obigen abkuerzungen durchstoebert. es kommen anscheinend alle vor. die haeufigkeiten - unter vernachlaessigung der gross-/kleinschreibung des ersten buchstabens - sind im einzelnen:

verschoben auf die projektseite. -- seth 00:04, 25. Aug. 2012 (CEST)

-- seth 14:23, 12. Aug. 2012 (CEST)

Wenn das Aka entdeckt, geht ihm einer ab ;-)) Liebe Grüße --Volker Paix  ^… 16:11, 12. Aug. 2012 (CEST)

gudn tach!

Aka fuehrt meines wissens nur richtige korrekturen durch, also solche die im einklang mit unseren richtlinien sind. abkuerzungen zu ersetzen gehoert nicht dazu, also wird ihm die liste auch egal sein. -- seth 19:04, 12. Aug. 2012 (CEST)

• Ich habe mal bei den Ausdrücken die Großschreibung entfernt, die nicht am Satzanfang auftreten können/sollen, also im falschen Kontext wären. Bei „u.Ä.“ habe ich erstmal das ([\xC4]) stehengelassen, weil ich nicht weiß, wie das mit der ASCII-Kodierung sein soll; man könnte auch noch die ältere Rechtschreibung „u.ä.“ mitnehmen – so auch bei „o.ä.“.
• Das ? kann vermutlich in $s_re integriert werden. Nicht aber das \K – bei den dreiteiligen (musste ich erstmal suchen, der erste Term schien mir zunächst bei der Ersetzung zu fehlen).
• Der Ausdruck am Anfang kann noch um \x5B (öffnende eckige Klammer) erweitert werden; kommt auch öfters vor.
• Eigentlich kann nach Floskel-Abkürzungen (d.h., u.U., z.T., …) nur Leerzeichen oder Komma kommen, wenn ein Satz weitergehen muss. Bei den anderen ist es ein

  [ )\x5D,;?!'"„“’‚‘“”«»‹›]

• Kann es sein, dass die statistischen d.R. („der Reserve“) eine Teilmenge von i.d.R. sind? Dann gäbe es nur 310 Leutnants d.R. Andersherum hätte das gepasst; offenbar unabhängig. G.T.
• Es wäre zu entscheiden, bei welcher Häufigkeit (vierstellig?) sich der Aufwand für das Durchsuchen jeder Seite im Verhältnis zu anderthalb Millionen Artikeln lohnen würde.
• Werden die RegExp eigentlich auf die HTML-Seite oder auf den Wikitext angewendet? Es kämen generell noch < und > als Begrenzer in Frage, die von vorangehenden oder folgenden Tags stammen.

Liebe Grüße --Gräfin Typo (Diskussion) 08:47, 16. Aug. 2012 (CEST)

Heute fielen mir noch auf: († 1865) und (* 1634)

LG --Gräfin Typo (Diskussion) 18:17, 16. Aug. 2012 (CEST)

gudn tach!

• kleinschreibung bei "o.ä." und "u.ä." ist jetzt drin.
• das mit dem '?' hatte ich nicht integriert, weil ich ansonsten zwei geschweifte klammern um den variablennamen haette schreiben muessen. ;-)
• das \K heisst soviel wie "alles links davon: nur suchen, aber nicht ersetzen".
• oeffnende eckige klammer hab ich noch eingebaut (braucht nicht maskiert zu werden)
• ende der abkuerzungen: ah, sehr gut, danach wollte ich dich auch schon fragen. ich fang mal an, das einzubauen.
• zu den anzahlen: ich suche mit dem ausdruck

  /[ >(]([a-zA-ZäöüÄÖÜß]\.(?:$s_re?[a-zA-ZäöüÄÖÜß]{1,3}\.)+)/g
  

  nach abkuerzungen, d.h. nach den jeweils laengsten. allerdings habe ich im script die gross-/kleinschreibung des ersten buchstabens absichtlich ignoriert. es gibt anscheinend viele "D.R.", denn "d.R." gibt es nur 488, ich ergaenze mal die case-sensitiven zahlen oben.
• wegen lt ung gt muss ich noch mal nachschauen. (todo)
• hab noch geburts- und sterbedaten ergaenzt.
• die suchstrings habe ich jetzt mit "- statt '-anfuehrungszeichen eingeschlossen, damit die verwendeten bausteine aufgeloest werden.
• hab noch "S. xx ff." ergaenzt.

-- seth 00:33, 17. Aug. 2012 (CEST)

Sehr gute Initiative. In der Tab. vermisse ich neben iV/i.V. noch iVm/i.V.m.

Wünschen würde ich mir derartiges auch für Datumsangaben zwischen Tag und Monat, wo sich &nbsp; mittlerweile durchsetzt (Bspl. 17. August 2012 zu 17. August 2012, sprich: 17.&nbsp;August 2012). Anders gesagt: Zwischen [Monat MMM oder MMMM] und vorstehender Tageszahl [1 bis Monatsende 30/31 bzw. für Feb. 28/29] könnte die autom. Einsetzung des geschützten Leerzeichens viel Arbeit ersparen (inkl. Vermeidung div. Hin- und Her-Edits wegen unterschiedlicher Meinung mehrerer Editierender).

--Elisabeth (Gegen Sexismus und Misogynie in der Wikipedia.) 02:25, 17. Aug. 2012 (CEST)

• Optimal wäre es, die erste Tabelle in diesem Thread um einige Spalten zu ergänzen: „Satzanfang möglich“ und „Floskel“.
  • Dann würde sie in eine Dokumentation übergehen, auch zur Wartung der Software (Was haben die sich bloß dabei gedacht?).
  • Vielleicht sollte man mit diesem Thread auf eine Unterseite umziehen, auch als Dokumentation?
• Die Subtraktion der möglichen Großschreibung ist aufschlussreich: Offenbar kommt „u.U.“ nur fünfmal am Satzanfang vor usw. Wenn es dadurch beschleunigt würde, könnte auf die Großschreibung in diesen Fällen verzichtet werden.
  • Während „d.Ä.“ nur 4 Großschreibungen kennt (Schreibfehler, vielleicht bei Vornamen, andere Bedeutung), sind 800 „D.J.“ auffällig; vielleicht DJ? Wegen fragwürdigem Kontext eher nicht verändern.

Liebe Grüße --Gräfin Typo (Diskussion) 08:42, 17. Aug. 2012 (CEST)

verschiebe-ende. -- seth 00:04, 25. Aug. 2012 (CEST)

gudn tach!

ok, ich habe also nun die diskussionsseite herverschoben und die tabellen auf die zugehoerige projektseite geklatscht.

• "i.V.m." hat immerhin ueber 350 treffer im dump, weshalb ich es mal mit aufnehme.
• datumsangaben sind jetzt auch drin. ach so, sollten da schmale oder normalbreite leerzeichen rein? hab jetzt erst mal schmale genommen.
• "satzanfang moeglich" habe ich als punkt aufgenommen. zu "floskel": aeh, ist das nicht etwas zu pauschal? unter floskel verstehe ich etwas nichtssagendes, dass aus stilistischen gruenden besser weggelassen werden sollte. du scheinst das hier mehr als grammatischen begriff zu gebrauchen. ich habe jetzt zwei spalten fuer die vorgaenger- und nachfolgerzeichen hinzugefuegt, allerdings muessten die noch befuellt werden.
• grossschreibung bei "u.u." entfernt
• "D.J.": gibt wohl viele DJs, die sich so schreiben und viele leute, deren vornamen mit "D.J." abgekuerzt werden. -- seth 01:20, 25. Aug. 2012 (CEST)

• @Floskeln: Ich bezog mich damit auf die Allerweltsphrasen, z.B. u.U., weil sie überall im Satz auftreten können und allerlei davor und dahinter stehen kann, und auch Großschreibung am Satzanfang möglich ist. Hingegen sind die Nicht-Floskeln feststehende (Fach-)Ausdrücke, die auch keine stilistischen Probleme aufwerfen und die offenbar immer nach einer anderen Angabe stehen – also nie am Satzanfang: e.V., v.Chr., a.D., d.J.; weiterhin kann vor ihnen keine öffnende Klammer stehen.
• @grossschreibung bei "u.u." entfernt: Übrigens verwahrt sich der Duden in „Textverarbeitung“ unter „Abkürzungen“ (2.) ausdrücklich dagegen, abgekürzte Floskeln am Satzanfang zu verwenden; U. U. sieht auch grottig aus.
• Wahrscheinlich kommt bei jeder Großschreibung auch ein Doppel-Vorname in Frage; solange es genau zwei Vornamen wären, gäbe es auch kein Problem damit. Nur: Sind es drei abgekürzte Vornamen oder analoge Namensbestandteile, würden jetzt zwei von ihnen eng nebeneinander stehen, während zum dritten davor oder hinter normaler Weißraum bliebe. Deshalb am besten die optionale Großschreibung des ersten Buchstabens komplett canceln; ist wohl hoffentlich ohnehin selten.
• Die Disk-Abschnitts-Überschrift ganz oben kann eigentlich raus; oder wäre durch etwas wie „Entwicklungsphase“ zu ersetzen.

Liebe Grüße --Gräfin Typo (Diskussion) 11:36, 4. Sep. 2012 (CEST)

gudn tach!

floskeln: ich denke, ich hatte verstanden, was du meinst. bloss fand ich den begriff "floskel" in diesem kontext befremdlich, weil ich ihn nur wertend kannte.

doppelvornamen: ja, da gibt's sehr viele, aber es gibt nur wenige leute mit mehr als zwei abgekuerzten vornamen. bei den zweibuchstabigen abkuerzungen der form /[a-z]\.[A-Z]\./ koennte man zwar die grossschreibung des ersten buchstabens weglassen, aber bei "Z.B.", "E.V." und "A.D." sind nach einer stichprobe von mir schon fast immer auch die geschuetzten schmalen leerzeichen angebracht.

ueberschrift: ok.

wollen wir "x. Jh." noch aufnehmen? -- seth 23:49, 4. Sep. 2012 (CEST)

@Jh.: Na klar; ich nehme an, du hast meine Post mitgelesen? Schönen Abend --Gräfin Typo (Diskussion) 18:20, 5. Sep. 2012 (CEST)

;-), vor "Jahrhundert" (ausgeschrieben) soll also auch ein schmales umbruchgeschuetztes leerzeichen stehen, oder? -- seth 00:20, 8. Sep. 2012 (CEST)

Auch dieses gern; bis die Anzahl der Jahrhunderte eine vier- oder fünfstellige Zahl ergibt, ist das typografisch unproblematisch. Es ist immer etwas unglücklich, wenn am Zeilenende eine Ordinalzahl steht, die somit auf einen Punkt endet; flüchtige und schlechte Leser nehmen das erstmal als Satzende wahr. Bei den Standardformulierungen mit Datumsangaben ergibt sich aus dem Satzfluss, dass der Satz dort noch nicht zu Ende sein kann, aber wenn die Zahl ein- oder zweistellig ist, schiebt man sie gern auf die neue Zeile. Und inhaltlich bilden die Zahl und das Wort „Jahrhundert“ ohnehin eine Einheit.

Whitespace: Es gibt einige Restbestände in den Artikeln, die an den interessanten Stellen &thinsp; oder möglicherweise numerische Entity-Formen oder das Unicode-Zeichen direkt verwenden. Da hier der Umbruch möglich ist, könnten sie in den Regulären Ausdruck $s_re einbezogen werden.

Ich weiß nicht so genau, wie viele seltene Fälle man in die Aktion einbeziehen sollte, ohne alle Benutzer und Millionen nicht betroffener Seiten unnötig auszubremsen.

Liebe Grüße --Gräfin Typo 18:08, 11. Sep. 2012 (CEST)

Alternativer Vorschlag

Mir liegt typografisch korrekte Darstellung auch ziemlich am Herzen, von daher fand ich es schade, dass damals dieses Meinungsbild eingeschlafen war, aber wahrscheinlich hätte es mangels Browserunterstützung seinerzeit eh keine Chance gehabt.

Naja, wie dem auch sei, ich würde hier gerne noch einen Vorschlag von damals aufgreifen, den ich eigentlich am Schönsten von allen fand, er erspart vor Allem das Erstellen langer Abkürzungslisten.

Man könnte einen Unterstrich „_“ für „ “, also das schmale geschützte Leerzeichen, zwei Unterstriche „__“ für „ “ also das geschützte Leerzeichen verwenden. Das müsste dann nur in der Wikisoftware entsprechend gewandelt werden, so wie es momentan bereits mit dem Prozentzeichen geschieht. Das ist dann für jeden schreibbar und Fehler beim Kopieren sind eigentlich ausgeschlossen und sollten auffallen. Die einzige Stelle, in der noch oft Unterstriche verwendet werden, sind Links (interne wie externe), die lassen sich automatisch rausfiltern. An den homöopathisch vorhandenen restlichen Stellen kann schließlich mit dem nowiki-Tag gearbeitet werden.

Viele Grüße --Sepp (Diskussion) 15:41, 2. Jan. 2013 (CET)

Die Idee mit dem Unterstreichungs-Strich ist super. Ähm, wäre super gewesen, wenn von Anfang an in der Wikisyntax vorhanden gewesen.

• Innerhalb von URL, math, syntaxhighlight usw. bliebe der Strich erhalten; im freien Text hätte er wie vorgeschlagen ausgetauscht werden können. Er kommt dort nur selten vor; man bekäme ihn immer noch über &#95; oder <nowiki>_</nowiki>.
• Nur ist das jetzt anderthalb Millionen de-Artikel, Hunderte Wiki-Projekte und zehn Jahre zu spät.
• Würde man die Software jetzt ändern, hätte das auch Wirkung auf die Darstellung aller früheren Seitenversionen. Und wenn in einer archivierten Diskussion vor fünf Jahren jemand etwas als _wichtig_ herausgestellt hatte, dann wäre das heute nicht mehr ganz so wichtig und deshalb sinnverfälschend. Also müsste ab seinem Edit jede einzelne Seitenversion erstmal mit &#95; ausgestattet werden, damit alle Seitenversionen originalgetreu gelesen werden können.
• Das muss natürlich in allen WMF- und Wikia-Projekten so rückwirkend geändert werden, in allen Seitenversionen.

Liebe Grüße --Gräfin Typo 08:50, 3. Jan. 2013 (CET)

Hallo, ich sehe da um ehrlich zu sein, nicht das große Problem. Im ersten Punkt sind wir uns ja einig, das müsste halt gefiltert werden. Was das _wichtig_ angeht: Man entweder man baut für den Fall Unterstrich+Leerzeichen auch einen Filter ein, oder man überarbeitet die Seitenversionen erst bei Aufruf via Bot, oder man lässt einen Bot über alles laufen, oder man ersetzt die Unterstriche automatisch erst in Seiten ab einem bestimmten Datum (mein Favorit) oder man schenkt sich den ganzen Aufwand und einzelne Diskussionsbeiträge wären eben nicht ganz originalgetreu lesbar. Ich meine, hier wurden schon ganz andere Umstellungen erfolgreich durchgeführt (die ganzen Datei-Links zum Beispiel) und die Idee der RegEx-Liste halte ich praktisch nicht für machbar, sie wird immer unvollständig bleiben, Zahlen unter 2100 werden nie vernünftig dargestellt werden können und es wird gerade dort auch eine Reihe falscher Ersetzungen geben. Von dem Aufwand mal ganz zu schweigen. --Sepp (Diskussion) 12:55, 3. Jan. 2013 (CET)

gudn tach!

wenn ich mich recht entsinne, ist die unterstrich-idee schon ein paar mal begraben worden, unter anderem weil die sourcecode-lesbarkeit und die -usability darunter leidet. es gab auch schon mini-vorlagen, die gezielt fuer diverse leerzeichen eingesetzt werden konnten. aber auch diese wurden geloescht.

so wie man sich als user i.d.r. nicht darueber gedanken machen muessen sollte, wo eine zeile getrennt wird, so koennte es auch einen automatismus geben, der dem user die entscheidung und arbeit abnimmt, wann welches leerzeichen gesetzt werden soll. das waere wesentlich besser als den user mit neuen meta-symbolen zu konfrontieren.

dass man vor %-zeichen keine leerzeichen zu setzen braucht und die software sich darum kuemmert, verstand bisher jeder sehr schnell. das mit den meta-zeichen ist wesentlich komplizierter, vor allem, weil man sich dann (als user) um viele ausnahmen gedanken machen muss, weil mal ein solches metazeichen literal und manchmal eben als metazeichen interpretiert wird. -- seth 00:51, 5. Jan. 2013 (CET)

Ich stimme ja grundsätzlich zu, dass eine Automatisierung am nettesten wäre, aber ich kann mir beim besten Willen nicht vorstellen, wie das halbwegs verlässlich funktionieren soll. An dieser Stelle hat das jemand anders ganz nett zusammengefasst, ein paar andere Aspekte hatte ich noch mal hier angesprochen. Eine vollständige Lösung des Leerzeichen-Problems ist ohne Meta-Zeichen nicht zu erreichen, und jede Automatisierung wird das Zeichen auch an falschen Stellen setzen und damit den Sinn von Artikeln wesentlich stärker verfälschen, als wenn in irgendwelchen alten Diskussionen mal Zeichen falsch ersetzt werden (falls keine Weiche für alte Seiten eingebaut wird). @seth: Hättest Du irgendwelche Links auf Diskussionen, in denen die Unterstrich-Idee aus den von Dir angesprochenen Gründen versandete? Ich habe bloß ein paar Seiten gefunden, wo es zwar Einwände gab, aber keine völlige Ablehnung, primär aus Mangel an gangbaren Alternativen. Außer ein paar Seiten zu ASCII-Art und Informatik sind mir auch keinerlei Beispiele bekannt, wo Unterstriche im Fließtext vorkämen. --Sepp (Diskussion) 08:09, 7. Jan. 2013 (CET)

Ein konkretes Beispiel für "wird das Zeichen auch an falschen Stellen setzen" in Bezug auf den hier gemachten konkreten Automatisierungsvorschlag wäre hilfreich, ersatzweise auch eine genauere Erläuterung der Begründung für diese Einschätzung. Bist Du kompetent in automatisierter Textverarbeitung, oder äußerst Du nur mal so eine Vermutung? Hier wurde festgestellt, "dass die fehleranfaelligkeit extrem niedrig sein muss", und das scheint mir auch Diskussionsgrundlage zu sein. Wenn sich mit den beschriebenen Techniken nicht erreichen lässt, dass Fehler extrem selten sind, dürfte der Vorschlag vom Tisch sein. --84.130.254.49 15:02, 8. Jan. 2013 (CET)

• Er war das letzte Tier dieser Art. 1765 wurde es geschlachtet.
• Die Platte erreichte in der Hitparade Platz 12. Juli machte sich danach auf Tour
• Er belegte Platz 13. August Rudolph Mayer brach daraufhin das Studium ab. (in diesem und dem vorherigen Beispiel müsste, nebenbei bemerkt, zusätzlich ein schmales Leerzeichen zwischen „Platz“ und Zahl)
• Das Formelzeichen für Schwefel ist S. 1797 wurde dies so festgelegt.
• Auf 3 GB sind etwas anderes als 3 GiB (uneinheitlich innerhalb eines Satzes)

Der Hauptkritikpunkt bleibt für mich aber, dass der Ansatz das Problem zwar angeht, aber nicht endgültig lösen kann; allein die Einheiten dürften ein nahezu unlösbares Thema bleiben, viele andere Stellen, wo schmale Leerzeichen hingehören können niemals berücksichtigt werden und solche Fälle sind völlig hoffnungslos. Ich kann die Last, die diese die RegEx im Verhältnis zum Rest des Seiten-Renderns erzeugen, nicht abschätzen, würde so etwas in ein eigenes Programm, wenn es Performance nicht zum Nulltarif gibt, aber eher nicht einbauen. --Sepp (Diskussion) 21:30, 8. Jan. 2013 (CET)

Nachtrag: Ich finde zwar die Unterstrich-Variante besser als die RegEx-Lösung, letztere aber auf jeden Fall viel besser als den Status quo und bin von der bisherigen Arbeit schwer beeindruckt. Nur, weil dass in meinen anderen Posts vielleicht nicht ganz so rüberkam (; --Sepp (Diskussion) 21:38, 8. Jan. 2013 (CET)

Gut, das illustriert m.E. das Fehlerpotential. Die angegebenen Formulierungen sind freilich gerade wegen der Zweideutigkeit schlecht und wären auch ohne Einführung des Vorschlags hier verbesserungswürdig (was in Zitaten aber nicht möglich wäre), weshalb so etwas in der Wikipedia nur schwer zu finden sein dürfte. Ob solche Fälle häufiger als extrem selten auftreten, müsste daher immer noch ein Praxistest zeigen. Einige Dutzend Fälle wären vielleicht akzeptabel und mit einer Ausnahmeliste zu behandeln. Soweit ich weiß, raten die Programmierer davon ab, von unserer Seite mit Performance zu argumentieren. --84.130.245.249 11:57, 10. Jan. 2013 (CET)

Ich halte wenig von der Unterstrich-Idee. Sie würde den momentanen Zustand nur unbedeutend verbessern. Anstatt überall   in die Artikel streuen zu müssen, muss man überall _ hinein streuen. Klar, das ist kürzer und hat dadurch gewisse Vorteile, aber der Pflegeaufwand, es überall an die korrekten Stellen einzufügen, bleibt der selbe. Es wird vergessen, steht an falschen Stellen usw. Ich präferiere eine Lösung, die in wenigen, dafür häufig auftretenden Fällen ganz automatisch vorgeht. Einen vernünftigen Kompromiss, der weder zu viele Fehlersetzungen erzeugt noch zu viele erwünschte Ersetzungen auslässt. Ganz vermeiden lässt sich weder das eine noch das andere. Es sollten nur solche Fälle ausgewählt werden, in denen ein Umbruchschutz eine so signifikante Verbesserung mit sich bringt, so dass ein paar Ausreißer wie die oben dargestellten in Kauf genommen werden können. Der Text wird ja nicht verfälscht. Es wird lediglich ein Zeilenumbruch möglicherweise ein Wort zu früh durchgeführt. Konkreter: Ich würde wie unten schon gesagt auf keinen Fall Leerzeichen einsetzen, wo vorher keine waren. Einen Umbruch zu verhindern, ist eine Sache. Ein Zeichen dazu zu erfinden, eine ganz andere. Des weiteren halte ich Umbrüche vor allem dann für unschön, wenn dadurch ein einzelnes Zeichen auf der nächsten Zeile landet. Eine Zeile sollte nie mit „B.“ beginnen. Dagegen ist es viel weniger tragisch, wenn eine Zeile mit „Januar“ beginnt. Das zugehörige „1.“ am Ende der vorherigen Zeile stört dort weniger. Wir nutzen Flattersatz, die Zeilenenden sind ohnehin unruhig. An Daten würde ich deshalb nichts ändern. Zuletzt ist die Sache mit den Maßeinheiten schon aufgrund ihrer Fülle extrem fehleranfällig. Das müsste mindestens radikal reduziert werden, um die Zahl der zwangsläufig auftretenden Fehlersetzungen in ein Verhältnis zu den erwünschten Ersetzungen zu bringen. --TMg 12:39, 10. Jan. 2013 (CET)

Codereview von TMg

Ein paar ungeordnete Anmerkungen:

• Die Abkürzungen mit Häufigkeiten unter 200 würde ich raus werfen. Einmal aus persönlichen Gründen, weil ich bei denen ohne nachzusehen kaum erraten könnte, was sie bedeuten (i. d. F. = „in der Ferne“?). Aber auch aus Performancegründen und für die leichtere Nachvollziehbarkeit und Wartung.
• Vor und nach den Abkürzungen eckige Klammern zu erlauben, kommt mir merkwürdig vor. Von Daten (1. Mai) abgesehen würde das bedeuten, Weiterleitungen (20. Jh.), Begriffsklärungen (i. A.) und sogar Unsinn (z. Z.) sozusagen zu „veredeln“. Beim Prozentzeichen ist das auch nicht erlaubt (Test: 100 % vs. 100 %).
• Aus meiner Erfahrung heraus weiß ich, dass komplizierte reguläre Ausdrücke wie bei den Maßeinheiten signifikante Performancelecks sein können.
• Die Fehleranfälligkeit ist sehr hoch, wenn man die Leerstelle optional macht. So etwas wie „?q=(2m)“ kann durchaus auch innerhalb einer URL vorkommen. Bei mir gibt es eine Sichtprüfung, deshalb erlaube ich mir diese Flexibilität. Wenn es wie hier aber um eine Vollautomatik geht, muss die Leerstelle meiner Meinung nach in allen Fällen verpflichtend vorhanden sein, so wie das beim Prozentzeichen ja auch der Fall ist (Test: 100%).
• Auch Zeilenumbrüche würde ich ausnehmen, aus deinem \s also wirklich nur ein Leerzeichen machen.
• „z. B.:“ mit Doppelpunkt sollte erlaubt sein. Ebenso bei einigen ausgewählten anderen Abkürzungen.
• Sind unter den am Ende erlaubten Anführungszeichen nicht auch welche, die am Ende einer Anführungszeichen-Paarung gar nicht vorkommen dürfen? Außer im Griechischen? Und dort auch nur sekundär?
• Vor einer Abkürzung könnte man theoretisch noch folgende Zeichen erlauben: !, + und | (Tabellensyntax), #, *, : und ; (Listensyntax), ' (fett/kursiv), > (<ref>z. B. in Einzelnachweisen</ref>). Wobei bei jedem Zeichen abzuwägen wäre, was für False Positives es auslösen könnte.

--TMg 18:41, 6. Jan. 2013 (CET)

gudn tach!

sehr gute hinweise!

zum ersten punkt: das betrifft zwar nur 5 abkuerzungen, aber ich habe da nichts dagegen. ist erledigt.

zum zweiten punkt: vor gewissen abkuerzungen oeffende eckige klammern "[" zu erlauben, hat Gräfin Typo weiter oben angeregt, weil es haeufig vorkomme. aber bzgl. der links hast du recht: das span-gedoens wuerde die links entlinken. das macht die ganze sache etwas komplizierter, z.b. wegen sowas wie Straße des 17. Juli. hmm, muss ich mir mal durch den kopf gehen lassen.

performance: ich vermute, dass hier nicht so schlimm sein wird, weil die gerenderten artikel iirc normalerweise gecacht werden. bin mir da aber nicht sicher.

leerstelle optional/URLs: das ist ein aehnlicher fall wie mit den wikilinks (punkt 2). externe und interne links (nicht jedoch deren titel) sollten vermutlich einfach in ruhe gelassen werden. fallen dir noch weitere, nicht-verlinkte faelle ein, bei denen das schief gehen wuerde?

zeilenumbrueche: hmm, ich ueberlege, warum ich \s und nicht " " genommen hatte. weiss nicht mehr, evtl. wegen verschiedener weiterer leerzeichen? denn an sich stimme ich dir zu, der zeilenumbruch sollte nicht ersetzt werden.

doppelpunkt: ja, was die nachfolgenden zeichen betrifft, muss man wohl ohnehin noch mal durchgehen und sowohl die tabelle ergaenzen als auch die regexps noch mal durchgehen, ob das jeweils passt. hab das zeichen jetzt einfach erst mal pauschal ergaenzt.

anfuehrungszeichen: da bin ich ueberfragt. Gräfin Typo, weißt du hier bescheid?

wikisyntax-metazeichen vor abkuerzungen: oha, stimmt eigentlich. andererseits koennte man, um false positives zu vermeiden einfach verlangen, dass nach den tabellen- und aufzaehlungsmetazeichen ein leerzeichen gesetzt werden soll (was glaube ich eh die meisten so handhaben und teilweise sogar einige user nachtraeglich so formatieren). dann muessten nur ' und > beruecksichtgit werden. -- seth 22:44, 10. Jan. 2013 (CET)

Fragen: Gibt es schon einen Softwaretest für die Regex-Sammlung? Am besten einer mit einer Art Punktesystem (Unterscheidung zwischen Tests, die keinesfalls fehlschlagen dürfen und welchen, bei denen es akzeptabel wäre). Ist überhaupt geklärt, an welcher Stelle im Parser-Vorgang das greifen soll? Wirklich auf den rohen Wikitext? Wäre es nicht einfacher, das erst ganz am Ende mit dem fertigen HTML zu machen? Oder geschickt in den Parservorgang eingewebt, so dass wirklich nur Text-Nodes bearbeitet werden? Das würde automatisch bspw. Ersetzungen in Vorlagen- oder Parameternamen verhindern und es würde meinen Vorschlag mit der Wikisyntax bedeutungslos machen. --TMg 23:12, 10. Jan. 2013 (CET)

Ich hatte oben bereits die Frage gestellt:

• Werden die RegExp eigentlich auf die HTML-Seite oder eine Vorstufe als vorgekautem HTML-Schnipsel angewendet, oder auf den puren Wikitext?

Davon hängt die Beantwortung vieler dieser Fragen ab.

• Wenn schon Wikitext-Elemente in HTML umgewandelt wurden, dann sind eckige Klammern vor Abkürzungen genauso unproblematisch wie runde; war es das nicht, gäbe es z. B. und entfällt damit. Wenn es schon verdaut wurde, dann ist das Linkziel bereits eine URL und enthält kein Leerzeichen mehr, und keinen Zeilenumbruch und keine eckige Klammer; der Linktitel kann hingegen formatiert werden. Ein interessanter Fehlerfall wäre auch, was sonst eigentlich passiert, wenn jemand innerhalb von math oder syntaxhiglight eine Abkürzung verwendet. Wird das im Wikitext mittels span ersetzt, müsste das in der Seitendarstellung sichtbar werden; wird das vorproduzierte HTML bearbeitet, ist das völlig unproblematisch. Weil solche Klagen aber bislang bei Prozentzeichen und Guillemets nicht laut wurden, hoffe ich darauf, dass HTML bearbeitet wird. Andernfalls wäre bei jedem Computerprogramm, in dessen Quelltext ein Prozentzeichen in entsprechender Konstellation stünde, das &#160; sichtbar geworden und das hätte wohl mal jemand gestört.
• Wenn es HTML ist, dann ist vermutlich auch das \n irrelevant. Müsste man mal genauer in die generierten HTML-Quellcodes schauen; meiner Erinnerung nach steht jedes Block-Element in einer Zeile und diese beginnt somit mit dem < des Block-Elements.
• Dafür wären mit oder ohne HTML > davor und < dahinter okay.
• Die schließenden Anführungszeichen würde ich liberal handhaben, da sehr oft von den Autoren typografisch falsche Zeichen bis hin zu Akzentzeichen benutzt werden. Schaden richtet das nicht an. Akut und Gravis können den Anführungszeichen hinzugefügt werden.
• Fehler werden weitgehend ausgeschlossen, wenn davor und/oder danach ein geeigneter Kontext steht. Selbst ein minimaler Fehler unter Hunderttausenden von Seiten würde kaum auffallen, weil es ohnehin nur um ein schmales Leerzeichen geht; ein ganzer Weißraum wird etwas schmaler oder ein kleiner Abstand wird eingefügt. Bei Quellcode müsste das monospace es wieder glattmachen? Dafür kenne ich Hunderttausend Seiten mit weitaus auffälligeren typografischen Fehlern.
• Die statistische Analyse der Häufigkeit hatte ich selbst eingangs angeregt und habe kein Problem mit der Streichung in der Wikipedia tatsächlich selten vorkommender Abkürzungen. Meine Liste stammte aus einer Sammlung für Bürobetrieb in MS Word, und Wikipedia-Juristen verwenden meinem Eindruck nach auch gern solche Dinger – i.d.F. ist: Gesetz „in der Fassung vom“, i.S.d. ist: „im Sinne des“ §, i.V.m. ist: „in Verbindung mit“ §§, m.W.v. ist: Vorschrift/Bescheid „mit Wirkung vom“. Persönlich würde ich die Schwelle sogar bei 1000 sehen.

Liebe Grüße --Gräfin Typo 08:27, 11. Jan. 2013 (CET)

gudn tach!

es gibt noch keinen software-test. aber es ist richtig, dass mal einer gebastelt werden sollte. aus zeitgruenden schaffe ich das aber vermutlich nicht alleine.

an welcher stelle beim parsen: die idee ist, den regexp-kram bei der stelle zu ergaenzen, bei der schon jetzt automatische leerzeichen bei prozent-zeichen ersetzt werden, siehe Parser.php. somit waere das von TMG oben genannte link-problem auch gar nicht gegeben: bei 5 % und $5\%$ wird kein leerzeichen ersetzt, bei "5 %" schon. kurz: es geht also nicht um den puren wikitext, sondern um einen "vorgeparsten". -- seth 11:18, 10. Mai 2013 (CEST)

Großschreibung am Satzanfang

Hallo! Mir ist aufgefallen, dass bei vielen Abkürzungen die Möglichkeit einer Großschreibung am Satzanfang gesehen wird. Laut Regeln (DUDEN) dürfen Abkürzungen wie v. a., u. a. oder z. B. jedoch nie am Satzanfang stehen und demgemäß auch nicht großgeschrieben werden!--XanonymusX (Diskussion) 18:38, 5. Aug. 2013 (CEST)

Es würde so oder so nur um das automatisierte Ersetzen eines normalen, umbrechenden Leerzeichens durch ein geschütztes gehen. Am Aussehen des Artikels darf das nichts ändern. Weder dürfen (sichtbare) Glyphen ausgetauscht werden (also auch nicht automatisch groß geschrieben), noch dürfen Zeichen dazu erfunden werden (also kein Einsatz eines geschützten Leerzeichens, wo vorher gar keins war, wobei wir uns diesbezüglich wie es scheint nicht einig sind, siehe oben). --TMg 22:19, 5. Aug. 2013 (CEST)

gudn tach!

@XanonymusX: niemand verbietet abkuerzungen am satzanfang, aber grundsaetzlich sollte man sie versuchen zu vermeiden. da sie also grundsaetzlich vorkommen koennen, war deren erkennung auch beruecksichtigt. -- seth 09:32, 2. Nov. 2013 (CET)

Nun ja, im Rechtschreibduden heißt es: »Abkürzungen, die für mehr als ein Wort stehen, werden am Satzanfang in der Regel nicht verwendet.« Das ist nicht gerade ein Verbot, aber eine Umsetzung der Rechtschreibung nach Dudenempfehlungen ist im deutschen Sprachraum doch üblich.--XanonymusX (Diskussion) 11:50, 2. Nov. 2013 (CET)

gudn tach!

"in der regel" heisst soviel wie meistens. und das deckt sich auch mit Wikipedia:Typografie/Automatische_Leerzeichen#H.C3.A4ufigkeiten_von_Abk.C3.BCrzungen. -- seth 12:15, 2. Nov. 2013 (CET)

Ich kann mir freilich keinen sinnvollen Fall denken, in dem „Z. B.“ oder „V. A.“ vorkommen sollte. Aber egal, besser für alle Fälle gerüstet …--XanonymusX (Diskussion) 21:06, 2. Nov. 2013 (CET)

o mit º

Ich brauche für einen Artikel ein „o“ mit einem º darüber, finde das entsprechende Zeichen aber nicht. FraCbB (Diskussion) 18:42, 19. Aug. 2015 (CEST)

Mit kombinierenden Zeichen: o̊. Aus welchem Schriftsystem/Sprache ist das denn? Vielleicht gibt's ja doch ein normales Zeichen. --nenntmichruhigip (Diskussion) 19:02, 19. Aug. 2015 (CEST)

Ist so eine Art verhunztes Latein aus dem Landbuch Karls IV. für den Artikel Berlin-Buch. FraCbB (Diskussion) 19:54, 19. Aug. 2015 (CEST)

Klingt so als könntest du guten Gewissens obige Lösung nutzen. --nenntmichruhigip (Diskussion) 20:02, 19. Aug. 2015 (CEST)

Worttrennung '/-'

Hatte gerade das Problem: Wie macht man dem Browser klar, dass er bei

ErstesHauptwort/-begriff

nach dem '/' trennen darf, aber nicht nach dem '-' ? So als Idee für diese "Automatik-Seite" hier, dass man als Autor einfach Wiki-Quelltext

/-

schreiben kann, und Wikipedia automatisch regelt, dass daraus beim Umbruch korrekt

ErstesHauptwort/

-begriff

wird... --arilou (Diskussion) 12:11, 23. Nov. 2015 (CET)

PS: Hab's übrigens nicht hingekriegt!

Ich würd's mit U+002F U+200B U+2011 versuchen ;-) --nenntmichruhigip (Diskussion) 07:43, 24. Nov. 2015 (CET)

Danke, scheint so zu funktionieren, wie man sich das richtigerweise vorstellt ;-)

Der U+002F ist einfach der '/', muss ja nicht komplizierter werden als nötig ;-)

--arilou (Diskussion) 08:54, 24. Nov. 2015 (CET)

Links zu Phabricator-Tasks

Mag jemand aktuelle Links zu aktiven Phabricator-Tasks einfügen und evtl. einen Satz zum aktuellen Stand? --Diwas (Diskussion) 14:28, 8. Feb. 2016 (CET)

Vorangehende und nachfolgende Zeichen

ergaenzend zu WD:Typografie#Leerzeichen:

gudn tach LiliCharlie, net, ℳ웃79, Bleistift2, ())¯_¯_¯_¯_>2, Nenntmichruhigip, Wolfgang Rieger, StephanGruhne, PerfektesChaos, Gräfin Typo, TMg!
gut, dass mal wieder darueber diskutiert wird. das motiviert auch, Wikipedia:Typografie/Automatische_Leerzeichen voranzubringen. dazu koennte ich noch etwas hilfe gebrauchen. und zwar:

• die hinteren beiden spalten der tabelle Wikipedia:Typografie/Automatische_Leerzeichen#Substitutionstabelle sollten noch geprueft bzw. ergaenzt werden. moegt ihr mir da helfen? derzeit gehe ich davon aus, dass ueberall, wo in der letzten spalte nichts steht, )] ,;:?!'"‘’‚“”«»‹› dort stehen sollte. was laesst sich vermutlich jedoch in einigen faellen einschraenken, richtig? -- seth 00:55, 21. Mär. 2016 (CET)

Wie habe ich die möglichen vor/nach-Zeichen zu verstehen? Würde, wenn ein anderes Zeichen dort steht, kein Leerzeichen automatisch er- oder gesetzt? StephanGruhne (Diskussion) 12:46, 25. Mär. 2016 (CET)

gudn tach!

genau. :-) -- seth 20:33, 25. Mär. 2016 (CET)

Morgen,

ich verstehe es immer noch nicht. Kannst du vielleicht anhand eines Beispiels erläutern, was mit „nachfolgende Zeichen” gemeint ist? Danke
())¯_¯_¯_¯_>2 (Diskussion) 11:44, 27. Mär. 2016 (CEST)

Ein nachfolgendes Zeichen ist ein Zeichen, das auf die vorangegangen Zeichen folgt. Das, was wir hier erzeugen, sind Zeichenketten (Strings). Es geht nun um Ersetzung von Zeichenketten, etwa die Zeichenkette »z. B.« soll durch eine andere ersetzt werden. Nach der Zeichenkette »z. B.« folgt ein weiteres Zeichen, beispielsweise ein » «. Jenes Leerzeichen folgt auf die vorangegangenen Zeichen, es ist also ein nachfolgendes Zeichen. LG, ℳ웃79 ^✍ 18:43, 28. Mär. 2016 (CEST)

Wenn also z.B. hinter „z. B.” ein Zeilenumbruch steht, dann darf das Leerzeichen durch ein schmales, geschütztes Leerzeichen ersetzt werden. Wenn dagegen dahinter ein Zeichen folgt, das nicht in der Tabelle gelistet ist, dann darf nichts ersetzt werden, sodass z. B. „z. B.89“ nicht ersetzt wird?
())¯_¯_¯_¯_>2 (Diskussion) 20:41, 28. Mär. 2016 (CEST)

Richtig, genau um sowas geht es. Es gibt andere Konstellationen, wo zufällig solche Zeichengruppen zusammentreffen, von Formeln über Automodelle zu Güterzuglokomotiven und Asteroiden, und die sollen nicht gesprengt werden. VG --PerfektesChaos 21:31, 28. Mär. 2016 (CEST)

seth, wieso berücksichtigst Du denn überhaupt das vorangehende und nachfolgende Zeichen? Es geht doch auch so, ohne?! LG, ℳ웃79 ^✍ 18:45, 28. Mär. 2016 (CEST)

gudn tach!

die idee ist, moeglichst wenige false positives zu erzielen, siehe antwort von PerfektesChaos (zeitlich nach, aber direkt ueber deiner frage). schwierig sind z.b. auch meta-sprachliche artikel wie etwa Abkürzung#Abkürzungen_mit_Punkt_und_Leerzeichen. da moechte man teilweise gerade keinen automatismus. -- seth 12:46, 29. Mär. 2016 (CEST)

Das dacht’ ich mir schon. Allerdings, was ist denn mit <nowiki></nowiki> o. Ä. für solche Fälle? Weil das die Sache ja deutlich vereinfachen+beschleunigen würde. LG, ℳ웃79 ^✍ 20:52, 29. Mär. 2016 (CEST)

Unser Quelltext beschreibt auf möglichst einfache Weise die enzyklopädischen Inhalte.

Er wird nicht den zeitweiligen Macken irgendwelcher Software angepasst.

Insbesondere kann man es von keinem Autor erwarten, dass bei der Aufzählung der Qualitätsstufen von Rohmilchkäse an ein solches Verhalten der Software gedacht und irgendwas eingefügt wird (wobei das obendrein vom Zeitpunkt der Textanalyse abhängen würde; wenn die obige Methodik greift, sind womöglich HTML-Kommentare und <nowiki> schon längst wieder aus dem vorverdauten Text entfernt), und der nächste Autor sieht konfusen Unsinn und schmeißt sowas wieder raus.

Die Software hat es mit möglichst geringer Fehlerquote richtig zu machen. Wobei das Problem nicht so sehr der um ein paar Pixel schmalere Weißraum wäre, sondern das Zusammenbappen von zwei längeren Codes links und rechts, die auf eine neue Zeile geschrieben würden und am rechten Rand eine größere Lücke reißen würden.

VG --PerfektesChaos 21:14, 29. Mär. 2016 (CEST)

Interessant.

(OT: „Er wird nicht den zeitweiligen Macken irgendwelcher Software angepasst“ würde bedeuten, dass wir   nutzen, egal wie’s Browser darstellen. [Was ich bevorzugen würde.] Du selbst aber bist gegen dessen Nutzung – also für Anpassung an Software-Macken. Nur mal so …)

Ich wollte zwar darauf hinaus, eine galantere Lösung zu finden … aber OK. LG, ℳ웃79 ^✍ 16:02, 30. Mär. 2016 (CEST)

4 Jahre…

…ist es her, seit diese Geschichte begonnen hat. Gibt es noch Hoffnung, dass sie umgesetzt wird?--*thing goes (Diskussion) 22:48, 17. Mai 2016 (CEST)

gudn tach!

momentan haengt es wohl daran. -- seth 22:46, 22. Dez. 2016 (CET)

ich nun einen patch submittet, hab aber keine ahnung, wie lange es dauert, bis sich jemand zum code review bereiterklaert. -- seth 10:37, 23. Dez. 2016 (CET)

@Lustiger seth, Umherirrender: Ich sehe Probleme damit, ohne mich in den Review einbringen zu wollen:

• Die meisten Regeln sind nur deutschsprachig sinnvoll; es wird aber derzeit keine Unterscheidung hinsichtlich der Inhaltssprache des Gesamtprojekts getroffen; im Prinzip gäbe es sogar eine Sprache per Seite.
• Die (physikalischen) Einheiten wären sprachunabhängig.
• Deshalb könnten auch die HTML-Konstrukte pauschal vereinbart bleiben.
• Eigentlich bräuchte es für sowas eine saubere Konfigurationsstruktur; also nur die sprachunabhängigen Regeln direkt in parser.php und abhängig von Inhaltssprache und Einzelprojekt ein Array mit spezifischen Regeln, und externe Konfiguration.
• Ich empfehle Nachbesserung.

Trotzdem danke; LG --PerfektesChaos 11:29, 23. Dez. 2016 (CET)

gudn tach!

zum ersten punkt: was meinst du mit "eine Sprache per Seite"? grundsaetzlich faend ich's auch besser, wenn man diese regeln lokalisieren wuerde. das ist aber bisher wohl noch nicht vorgesehen.

zum zweiten punkt: ich weiss nicht, wie die diesbzgl. typografischen regeln in anderen sprachen sind.

zum vierten punkt: ja. allerdings stecke ich zu wenig in dem source code drin, um beurteilen zu koennen, wo die lokalisieren stattfinden sollte. deswegen habe ich einfach den patch submittet und warte nun auf feedback. -- seth 16:29, 23. Dez. 2016 (CET)

• (ersten) Sprache per Seite: Steht hier nicht im Mittelpunkt.
  • Spezialseiten stehen komplett in der jeweiligen Sprache des momentanen Lesers, sofern das Systemnachrichten-Gewusel sauber gebaut ist und diese Sprache unterstützt.
  • Grundsätzlich wäre es möglich, jede Wikiseite einzeln in einer individuellen menschlichen Spache zu konfigurieren. Stell dir mal ein wohl derzeit nicht existierendes {{LANGUAGE:fr}} vor.
  • Auf mw: gibt es Übersetzungen von Hilfeseiten; ich glaube, die haben sowas, wohingegen die Inhaltssprache des Gesamtprojekts mw: Englisch ist.
  • Mindestens die Inhaltssprache des Gesamtprojekts müsste aber für die meisten deiner Regeln Deutsch sein; so als erste Näherung. Ich weiß nicht so genau, ob und wie ein mw:Manual:Hooks/PageContentLanguage Auswirkungen hätte.
  • Auf Nicht-Spezialseiten kann man französischsprachigen Artikel-Inhalt inmitten portugiesischen Portalrahmens haben.
• (zweiten) Die Abkürzungen in den meisten Regeln sind rein deutschsprachig und haben woanders keinen Sinn.
  • Prozentzeichen, Guillemets und Paragrafenzeichen sowie physikalische Einheiten sind sprachunabhängig.
• (vierten) Mit sowas würde sich der Umherirrende besser auskennnen als ich. Komme da nicht so oft vorbei.
• (neu) Es gibt ein Prinzip namens „Trennung von Programm und Daten“.
  • Würde heißen, dass in der Funktion zu parser.php nur die Auswertung eines von außen kommenden Arrays/Objekts erfolgt; ggf. auch die Definiton des HTML-Zeugs.
  • Die sprachunabhängigen Regeln wären in einem Konfigurationsarray separat zu definieren.
  • Je nach momentaner Sprache würde dies um spezielle Regeln ergänzt, womöglich überschrieben werden.

Genug Weihnachtsgeschenke --PerfektesChaos 17:09, 23. Dez. 2016 (CET)

Risiken des Leerzeichen-Postprocessings

Drei gravierende Risiken bestehen:

1. Die Qualitätssicherung des Ergebnisses bewegt sich außerhalb jeglicher Machbarkeit.
2. Anwender haben nur umständlich die Möglichkeit, das Standardverhalten auszuhebeln, falls nötig.
3. Der Wiki-Quelltext bleibt unverändert "falsch"

Eleganter, standardkonformer und vor allem sicherer (!) wäre es evtl.,

1. den Wiki-Editor aufzupeppen, so dass dieser bei der Eingabe das womöglich geeignete Leerzeichen automatisch verwendet, diese Aktion vom Anwender aber jederzeit überschrieben werden kann (vgl. Autokorrektur/Autoformatierung in Word) und
2. diesen entsprechend besser gestalteten Wiki-Quelltext wahlweise per php "uralt-browser-toleranter" zu rendern, oder es dem Anwender zu ermöglichen, dies abzuschalten und die Originalzeichen von seinem Browser anzeigen zu lassen.

Damit hätten wir zugleich die beste denkbare Qualitätssicherung, nämlich eine Einzelfall-Sichtprüfung. Nachteilig wäre, dass die Verbesserungen erst nach einiger Zeit zum Tragen kommen, wenn mehr und mehr Artikel bearbeitet werden, und dass Javascript-blockierte Browser höchstwahrscheinlich nicht in den Genuss des "Typografie-Assistenten" kämen.

Meinungen? --*thing goes (Diskussion) 23:27, 17. Mai 2016 (CEST)

Sehe ich auch so… --nenntmichruhigip (Diskussion) 12:50, 18. Mai 2016 (CEST)

gudn tach!

zu den drei risiken:

1. QS laesst sich immer irgendwie bewerkstelligen.
2. wenn wir mal einen ueberblick bekommen ueber solche faelle, koennen wir dafuer vielleicht auch noch eine loesung finden.
3. das ist bereits jetzt beim prozentzeichen der fall und es stoert vermutlich niemanden.

zu dem vorschlag:

1. welche zeichen genau sollten da vom browser eingefuegt werden?
2. den zweiten punkt verstehe ich nicht. doch, jetzt. -- seth 00:45, 25. Dez. 2016 (CET)

eine loesung, die js erfordert, wuerde vermutlich dazufuehren, dass leute mit deaktiviertem js die syntax versehentlich kaputt machen koennten, oder? -- seth 22:43, 22. Dez. 2016 (CET)

gudn tach!

hab mir das nochmal durch den kopf gehen lassen. letztlich geht das, was nenntmichruhigip schreibt, in die gleiche richtung wie das, was Fomafix in [1] schrieb. und vielleicht habt ihr recht. vielleicht waere es am besten, wenn schon in der datenbank die richtigen zeichen verwendet werden.

mein stand ist noch, dass z.b. U+202f nicht von allen browsern/systemen gescheit angezeigt werden kann. aber selbst wenn es so waere, koennte man ja trotzdem schon mal im original-wikitext, der in der datenbank ablegt ist, die richtigen zeichen verwenden und dann eben bei der ausgabe ggf. noch anpassen.

schwierig und kompliziert wuerde es allerdings, im wikitext die stellen herauszufinden, die automatisiert manipuliert werden sollen. die stelle in Parser.php, an der die %-geschichte bereits jetzt eingefuegt ist, ist eigentlich sehr gut geeignet dafuer, weil durch ein pre-parsing bereits einiges ausgesiebt wird (z.b. links, mathe-umgebungstexte etc.). ich denke, das wird dort, wo die software bei der eingabe etwas aendern muesste, schwieriger.

vielleicht wuerde das ganze soo schwierig, dass es noch weitere jahre bis zur umsetzung dauern wuerde. auf der anderen seite haetten wir hier eine loesung, mit der man schon jetzt arbeiten koennte (sobald der patch freigegen wird). an der langfristigen loesung koennte man unabhaengig davon weiterhin basteln und in ein paar jahren dann de patch rueckgaengig machen.

ich faend's jedenfalls schade, wenn wir jetzt die ganze sache vorerst beerdigen wuerden, nur weil eine bessere loesung zwar denkbar waere, jedoch noch ewig bis zur umsetzung brauchen wuerde. -- seth 00:45, 25. Dez. 2016 (CET)

User:*thing goes schrieb, ich hatte nur bestätigt :-) Der obige Vorschlag setzt an einer noch anderen Stelle an: Der Punkt 2 wäre im Wikitext-Parsing von MediaWiki umzusetzen, wo (falls da überhaupt Bedarf für besteht) U+202F für die Ausgabe durch ein normales (oder anderes schmales und/oder geschütztes) Leerzeichen ersetzt würde. Das dürfte mEn selbst in sowas wie MathML unproblematisch sein, da U+202F mutmasslich noch weniger als Syntaxbestandteil interpretiert wird als die, durch die es ersetzt wird. Lediglich eine Ersetzung durch U+0020 könnte eventuell Nebenwirkungen haben. Das würde völlig unabhängig von irgendwelchen RegExps für alle U+202F wirken, auch wenn die manuell irgendwo eingegeben wurden.

Punkt 1 würde schon vor dem Speichern ansetzen, nämlich im jeweils verwendeten Editor. Also z.B. eine entsprechende Funktion im VE, oder ein (vorerst wohl Benutzer-, später evtl MW-internes) Gadget für den klassischen Quelltexteditor. Also quasi ein Leerzeichen-Preprocessing statt dem von dir vorgeschlagenen Postprocessing. --nenntmichruhigip (Diskussion) 11:33, 26. Dez. 2016 (CET)