Wikipedia Diskussion:Meinungsbilder/Typographie (Zwischenräume)
Titel
BearbeitenSei doch so gut und verschiebe das Meinungsbild auf einen aussagekräftigeren Titel, da dieses Meinungsbild nur einen kleinen Teil, aber wohl eine wichtigen Teil betrifft. Ein Titel à la «Leerzeichentypografie» und ähnliche wäre angebrachter. --dvdb 22:54, 15. Jul. 2008 (CEST)
- Schon gemacht. „Leerzeichentypographie“ fand ich etwas zu schwerfällig, habe das MB deswegen nach Wikipedia:Meinungsbilder/Typographie (Zwischenräume) verschoben. --Debianux 23:23, 15. Jul. 2008 (CEST)
2. Versuch
BearbeitenAnscheinend will das MB niemand verbessern, obwohl es von vielen kritisiert wurde. Ich schlage deshalb vor, das MB parallel zum MB Aufhebung der schweizbezogen-Regelung vom 4. August 2008 bis am 31. August 2008 laufen zu lassen. --Debianux 00:48, 18. Jul. 2008 (CEST) Ps.: Ich bin jetzt für ca. zwei Wochen inaktiv.
Zuviele Optionen
BearbeitenKann man das Ganze kürzen? Schönen Gruß --Heiko 10:25, 18. Jul. 2008 (CEST)
- Das ganze wurde hier schon bedeutend gekürzt. Eine weitere Verkürzung finde ich nicht sinnvoll. --Debianux 14:47, 18. Jul. 2008 (CEST)
- Meinungsbilder mit 4 Optionen und 2 Unteroptionen funktionieren nicht in der WP. Sehr oft funktionieren bereits MBs nur mit den Auswahlmöglichkeiten Ja/Nein/Enthaltung/Ablehnungen nicht. Viele Abstimmer lesen nur quer, haben keine Lust sich richtig einzulesen und lehnen daher schon ab. Aus einem abgelehnten MB folgt der ursprüngliche Status Quo. Ich würde das ganze auf eine Frage reduzieren: „Sollen Formatierungsmöglichkeiten im Fließtext wie
,{{/}}
, 
usw., die das Layout verbessern aber die Lesbarkeit des Quelltextes verschlechtern, verwendet werden oder nicht?“ Nach so einer Grundsatzentscheidung kann man dann das auf WP:TYPO weiterdiskutieren. Schönen Gruß --Heiko 14:59, 18. Jul. 2008 (CEST)
- Meinungsbilder mit 4 Optionen und 2 Unteroptionen funktionieren nicht in der WP. Sehr oft funktionieren bereits MBs nur mit den Auswahlmöglichkeiten Ja/Nein/Enthaltung/Ablehnungen nicht. Viele Abstimmer lesen nur quer, haben keine Lust sich richtig einzulesen und lehnen daher schon ab. Aus einem abgelehnten MB folgt der ursprüngliche Status Quo. Ich würde das ganze auf eine Frage reduzieren: „Sollen Formatierungsmöglichkeiten im Fließtext wie
Eine Tabelle mit den Optionen wäre nett. Zum einen mit dem Wiki-Quellcode, zum anderen mit dem Ergebnis --Heiko 10:29, 18. Jul. 2008 (CEST)
Ich muss dem Einwand von Heiko zustimmen. Ich begreife zur Zeit nicht so ohne Weiteres, für was man hier abstimmen soll, ob man für mehr als eine Option stimmen darf etc. Es werden einfach viel zu viele Fragen auf einmal gestellt und in einem einzigen Meinungsbild zusammen gewürfelt. So weit ich das überblicke, sind das hier vier Meinungsbilder in einem: Punkt vs. Leerstelle als Tausendertrennzeichen, NBSP vs. NARROW NO-BREAK SPACE, NARROW NO-BREAK SPACE vs. THINSP, HTML-Kodierung vs. Vorlagen. So kann niemals ein irgendwie brauchbares Ergebnis aus dieser Umfrage entstehen. Bitte auf eine klare Fragestellung reduzieren und neu starten! --TM 22:46, 19. Jul. 2008 (CEST)
Barrierefreiheit
BearbeitenHat schon mal jemand von Euch geprüft was ein Screenreader aus diesem Zeichensalat, der zu halben Leerzechen führt, macht? Wenn das nicht 100% funktioniert hat der Kram hier nix verloren, da die Belange von Sehbehinderten vor irgendwechen Spielereien gehen. Und umständlich ist es sowieso. Ich werde mich z.B. weigern solch gekünsteltes Zeugs zu benutzen, wo ich eine schöne breite Leertaste habe. Und der Quelltext wird so auch unlesbar. Weissbier 10:37, 18. Jul. 2008 (CEST)
- Oh, guter Aspekt, vielleicht mal eine Testseite erstellen und Lalü bitten, mal seinen Screenreader drüberlesen zu lassen? Viele Grüße, —mnh·∇· 10:41, 18. Jul. 2008 (CEST)
- Ich habe nachstehend mal die 3 Testzeilen von Weissbier eingefügt und kommentiert. Die Zahlen 1, 2 und 3 werden in Zeile 1 mit normalen und Zeile 2 und 3 mit halben Leerzeichen getrennt:
- Normale Leerzeichen: 1 2 3
- Halbe Leerzeichen: 1 2 3
- Halbe Leerzeichen, Variante 2: 123
Bei Variante 2 gibt der Screenreader Jaws zwar die Leerzeichen aus, die Betonung ist aber etwas merkwürdig. Bei Variante 3 erkennt meine Software keine Leerzeichen zwischen den Zahlen. Variante 2 wäre also theoretisch OK, aber mir persönlich wird der Quelltext dadurch zu unübersichtlich. Getestet mit IE6 und Jaws 7.1. -- Lalü 17:21, 18. Jul. 2008 (CEST)
- Eigentlich ist ja "Software erkennt keine Leerzeichen" die Richtige Variante, oder? Es geht ja u.a. darum, Zahlen wie
- 12345 (keine Tausendertrenner)
- 12.345 (Punkt als Tausendertrenner)
- 12'345 (Apostroph als Tausendertrenner)
- 12 345 (Leerzeichen als Tausendertrenner)
- 12345 (Hilfskonstruktion schmales Leerzeichen als Tausendertrenner)
- 12 345 (  als Tausendertrenner)
- 12 345 ( als Tausendertrenner)
- als "zwölftausenddreihundertfünfundvierzig" vorzulesen. Schönen Gruß --Heiko 17:27, 18. Jul. 2008 (CEST)
- @Lalü: Was heißt, deine Software erkennt bei der Variante 2 keine Leerzeichen zwischen den Zahlen? Gibt sie die Zahl als 123 (hundertdreiundzwanzig) aus? --Debianux 17:40, 18. Jul. 2008 (CEST)
- Ich weiß ja nicht, wie es bei euch aussieht, bei mir sieht es jedenfalls sehr seltsam aus... (Win-XP + FF3) --RalfR → DOG 2008 17:49, 18. Jul. 2008 (CEST)
- @Ralf Roletschek: Versuch’s mal mit einer anderen Schriftart. Mozilla Firefox 3 auf Microsoft Windows XP sollte eigentlich gehen (siehe hier). (nicht signierter Beitrag von Debianux (Diskussion | Beiträge) 18:14, 18. Jul. 2008 (CEST))
- An die komischen Zeichen habe ich mich in der Wikipedia längst gewöhnt. Und das ist kein Einzelfall, habe ich schon an den verschiedensten Rechnern gesehen. Ich habe keine exotischen Einstellungen, werde auch nicht extra für Wikipedia andere Schriften installieren. --RalfR → DOG 2008 18:21, 18. Jul. 2008 (CEST)
- @Ralf Roletschek: Versuch’s mal mit einer anderen Schriftart. Mozilla Firefox 3 auf Microsoft Windows XP sollte eigentlich gehen (siehe hier). (nicht signierter Beitrag von Debianux (Diskussion | Beiträge) 18:14, 18. Jul. 2008 (CEST))
- Ich weiß ja nicht, wie es bei euch aussieht, bei mir sieht es jedenfalls sehr seltsam aus... (Win-XP + FF3) --RalfR → DOG 2008 17:49, 18. Jul. 2008 (CEST)
- Ich bitte um Entschuldigung, ich hatte mich falsch ausgedrückt: Zeile 2 ist OK, Zeile 3 nicht. Das bedeutet, dass Variante 1 OK ist und Variante 2 nicht. Bei Zeile 3 wird einfach nur 123 ohne Leerzeichen ausgegeben. -- Lalü 17:55, 18. Jul. 2008 (CEST)
- Wenn bei dir bei Zeile 3 »einhundertdreiundzwanzig« ausgegeben wird, wäre das korrekt. Ein »eins Leerzeichen zwei Leerzeichen drei« wäre hingegen falsch. --Debianux 18:14, 18. Jul. 2008 (CEST)
- *quetsch* Nicht unbedingt, beispielsweise bei Zahlen mit nachgestellter Einheit könnte sich das ohne Leerzeichen ziemlich eigenwillig anhören. Da kommt noch hinzu, dass sowas wie "zwölf-geschweifte Klammer auf-geschweifte Klammer auf-Backslash-geschweifte Klammer zu-geschweifte Klammer zu-Kilogramm" im Quelltext alles andere als vorteilhaft ist. Übrigens danke an Lalü für den Test. Viele Grüße, —mnh·∇· 03:12, 20. Jul. 2008 (CEST)
- Wenn bei dir bei Zeile 3 »einhundertdreiundzwanzig« ausgegeben wird, wäre das korrekt. Ein »eins Leerzeichen zwei Leerzeichen drei« wäre hingegen falsch. --Debianux 18:14, 18. Jul. 2008 (CEST)
- Ich bitte um Entschuldigung, ich hatte mich falsch ausgedrückt: Zeile 2 ist OK, Zeile 3 nicht. Das bedeutet, dass Variante 1 OK ist und Variante 2 nicht. Bei Zeile 3 wird einfach nur 123 ohne Leerzeichen ausgegeben. -- Lalü 17:55, 18. Jul. 2008 (CEST)
@Ralf: Menü "Ansicht" -> Zeichenkodierung -> Unicode (UTF-8) dürfte helfen. War bei mir jedenfalls so. Weissbier 18:51, 18. Jul. 2008 (CEST)
- UTF-8 ist eingestellt. Im IE7 und Safari sehe ich ein kleines Quadrat, nur in Opera gibts keine Probleme. Ich hab das schon auf Vista-Kisten gesehen, unter Win-2000, am Mac - das ist keine Ausnahme. --RalfR → DOG 2008 19:49, 18. Jul. 2008 (CEST)
- *ratlos* Weissbier 11:52, 19. Jul. 2008 (CEST)
- Dann ist es mit größter Wahrscheinlichkeit trotzdem die Schriftart; die von dir verwendete Schriftart im Screenshot (Bild:Scr-leerz.gif) sieht auf jeden Fall recht merkwürdig aus. DejaVu wäre eine kostenlose Schriftart, die zudem noch unter einer freien Lizenz steht; damit hättest du sicher keine Probleme mehr. Nach der Installation müsstest du nur noch die Einstellungen im Mozilla Firefox anpassen. Debianux 14:26, 3. Aug. 2008 (CEST)
- Bei Safari konnte ich lange schmale geschützte Leerzeichen als solche lesen, seit einiger Zeit werden sie aber gar nicht mehr dargestellt. Ich nehme diese Seite nicht auf meine Beobachtungsliste, bei Antwort bitte pingen:
{{ping|Peter Gröbner}}
. -- Peter Gröbner -- 16:03, 19. Sep. 2017 (CEST)
- Bei Safari konnte ich lange schmale geschützte Leerzeichen als solche lesen, seit einiger Zeit werden sie aber gar nicht mehr dargestellt. Ich nehme diese Seite nicht auf meine Beobachtungsliste, bei Antwort bitte pingen:
- Dann ist es mit größter Wahrscheinlichkeit trotzdem die Schriftart; die von dir verwendete Schriftart im Screenshot (Bild:Scr-leerz.gif) sieht auf jeden Fall recht merkwürdig aus. DejaVu wäre eine kostenlose Schriftart, die zudem noch unter einer freien Lizenz steht; damit hättest du sicher keine Probleme mehr. Nach der Installation müsstest du nur noch die Einstellungen im Mozilla Firefox anpassen. Debianux 14:26, 3. Aug. 2008 (CEST)
Das funktioniert ja überhaupt nicht
BearbeitenWenn ich   in den Quelltext eingeben, dann steht da auch  . Es werden damit gar keine halben Leerzeichen erzeugt. Was soll denn bitte dieser Blödsinn nun wieder? Oder glaubt Ihr ernsthaft jemand gebe <span style="margin-left:0.167em">....</span> bei jedem § etc. ein. Das der Quelltext damit völlig unlesbar wird, dürfte zudem offensichtlich sein. Ich fürchte da solltet Ihr noch mal in Euch gehen, bevor Ihr Euch mit so einem MB an die Öffentlichkeit wagt. Weissbier 14:49, 18. Jul. 2008 (CEST)
- Hallo Weissbier. Es hat niemand behauptet, dass » « funktioniert. Ein » « hingegen funktioniert prima. ;) Lieber Gruß, Debianux 14:55, 18. Jul. 2008 (CEST)
- Nachtrag: Falls bei dir auch ein » « nicht funktioniert, könnte es daran liegen, dass du den Opera-Browser verwendest (siehe hier). --Debianux 15:02, 18. Jul. 2008 (CEST)
- Ich hatte das vermittels c&p aus dem Infokasten übernommen. Grummel. test: 1 2 AHA, danke. --Weissbier 15:10, 18. Jul. 2008 (CEST)
Ziel?
BearbeitenWas war gleich das Ziel? Butter bei die Fische: Welcher Fall ist im Bereich Typographie eigentlich nicht geregelt? Die Kenntnis von Wikipedia:Wie schreibe ich gute Artikel, Wikipedia:Wie gute Artikel aussehen, Wikipedia:Typografie, Wikipedia:Schreibweise von Zahlen setze ich voraus. Soll nicht heißen, dass man den Bereich nicht übersichtlicher gestalten könnte, aber so zu tun als betrete man Neuland ist abenteuerlich. -- Achates Wer nichts weiß, muss alles glauben. 15:46, 18. Jul. 2008 (CEST)
- Habe das nun korrigiert: „Ziel dieses Meinungsbildes ist es, im Bereich typographische Zwischenräume einheitliche Regeln zu definieren.“ --Debianux 16:10, 18. Jul. 2008 (CEST)
- Wo widersprechen sich die Regeln, weil wir plötzlich einheitliche Regeln brauchen. Im Gegenteil hat die Löschung der Vorlage sogar einen Sonderweg geschlossen. -- Achates Wer nichts weiß, muss alles glauben. 16:40, 18. Jul. 2008 (CEST)
- „Ziel dieses Meinungsbildes ist es, im Bereich »typographische Zwischenräume« Regeln zu definieren, damit das Schriftbild der Wikipedia einheitlicher wird und nicht mehr verschiedene Varianten verwendet werden.“ So besser? --Debianux 17:44, 18. Jul. 2008 (CEST)
- Und als Nächstes basteln wir uns Ligaturen? Ist ja per CSS machbar. Vergiß es. Wikipedia ist Informatik-vorbelastet. Wenn es nach den Erfahrungen von Lalü keine Probleme gibt, wäre ich dafür. Solange einem hier aber br-Tags wegeditiert werden und durch Doppel-Enter ersetzt werden... Typographie ist hier unerwünscht. *seufz* --RalfR → DOG 2008 18:01, 18. Jul. 2008 (CEST)
- Das Eszett (»ß«) und das der Buchstabe »w« sind übrigens auch Ligaturen (»ß« aus »ſ« und »s«; »w« aus »v« und »u«), die sogar du selbst benutzt. Weitere Ligaturen, die du unbewusst verwendest: »&«, »%« und sogar das »@«-Zeichen. --Debianux 19:24, 18. Jul. 2008 (CEST)
- Ich weiß. Meine Ex-Frau hat Bleisetzer gelernt und ich arbeite seit über 20 Jahren nebenbei für die Zeitung. Bei mir rennst du offene Türen ein. --RalfR → DOG 2008 19:46, 18. Jul. 2008 (CEST)
- Wieso sollte man sich in der Wikipedia nicht um Typographie kümmern? Klar sind Ligaturen hier nicht angebracht, aber die Sache mit den Zwischenräumen sollte machbar sein. Ich versehe es immer noch nicht, weshalb die Vorlagen »Zahl« und »\« gelöscht wurden … Auch sollte allen einleuchten, dass Wikipedia-Artikel häufig ausgedruckt werden, und dort stört ein »"Zitat"« oder ein »z.
B.«. --Debianux 19:53, 18. Jul. 2008 (CEST)
- Wieso sollte man sich in der Wikipedia nicht um Typographie kümmern? Klar sind Ligaturen hier nicht angebracht, aber die Sache mit den Zwischenräumen sollte machbar sein. Ich versehe es immer noch nicht, weshalb die Vorlagen »Zahl« und »\« gelöscht wurden … Auch sollte allen einleuchten, dass Wikipedia-Artikel häufig ausgedruckt werden, und dort stört ein »"Zitat"« oder ein »z.
- Ich weiß. Meine Ex-Frau hat Bleisetzer gelernt und ich arbeite seit über 20 Jahren nebenbei für die Zeitung. Bei mir rennst du offene Türen ein. --RalfR → DOG 2008 19:46, 18. Jul. 2008 (CEST)
- Das Eszett (»ß«) und das der Buchstabe »w« sind übrigens auch Ligaturen (»ß« aus »ſ« und »s«; »w« aus »v« und »u«), die sogar du selbst benutzt. Weitere Ligaturen, die du unbewusst verwendest: »&«, »%« und sogar das »@«-Zeichen. --Debianux 19:24, 18. Jul. 2008 (CEST)
- Und als Nächstes basteln wir uns Ligaturen? Ist ja per CSS machbar. Vergiß es. Wikipedia ist Informatik-vorbelastet. Wenn es nach den Erfahrungen von Lalü keine Probleme gibt, wäre ich dafür. Solange einem hier aber br-Tags wegeditiert werden und durch Doppel-Enter ersetzt werden... Typographie ist hier unerwünscht. *seufz* --RalfR → DOG 2008 18:01, 18. Jul. 2008 (CEST)
- „Ziel dieses Meinungsbildes ist es, im Bereich »typographische Zwischenräume« Regeln zu definieren, damit das Schriftbild der Wikipedia einheitlicher wird und nicht mehr verschiedene Varianten verwendet werden.“ So besser? --Debianux 17:44, 18. Jul. 2008 (CEST)
- Wo widersprechen sich die Regeln, weil wir plötzlich einheitliche Regeln brauchen. Im Gegenteil hat die Löschung der Vorlage sogar einen Sonderweg geschlossen. -- Achates Wer nichts weiß, muss alles glauben. 16:40, 18. Jul. 2008 (CEST)
Mich persönlich stört sowas nicht. Das ist mir herzlich egal. Weissbier 11:54, 19. Jul. 2008 (CEST)
- Was genau ist nicht geklärt? Was genau verbesserungsbedürftig? -- Achates Wer nichts weiß, muss alles glauben. 01:50, 20. Jul. 2008 (CEST)
- Oh, verbesserungsbedürftig ist reichlich: das Benutzerinterface ist katastrophal, von der Optik überall verkorkste Tabellen, lausige Bildpositionierung, riesige Weißraumlöcher in Artikeln, überproportionierte und vollkommen uneinheitliche Infoboxen und kleine bunte Flaggen, die das Layout kaputtkloppen (nicht selten mit Listenpunkten davor). Wenn es hinduistische Bäume gibt, ist vermutlich die Höchststrafe nach Wiedergeburt eine BILD oder ein Wikipedia-Artikel zu werden. Ach, Du meintest mit den Leerzeichen? Eigentlich nix, geschützte Leerzeichen höchst sparsam verwenden ist klar genug, Sonderwege braucht's nicht, es geht auch so prima. Außer, man möchte Korinthen… —mnh·∇· 03:22, 20. Jul. 2008 (CEST)
- Das heißt: Meinungsbild in die Tonne kloppen oder ablehnen? -- Achates Wer nichts weiß, muss alles glauben. 12:21, 20. Jul. 2008 (CEST)
- Am besten Ersteres. Siehe mein obiger Einwand. Es ist völlig unklar, welche Frage dieses Meinungsbild eigentlich klären will. --TM 22:43, 21. Jul. 2008 (CEST)
- Ich kann eigentlich nur einen sinnvollen Grund für dieses Meinungsbild erkennen: Es ist ein Rekordversuch. Hier will ein Benutzer innert kürzest möglicher Zeit zwei UÖD schaffen (die andere Baustelle ist Wikipedia:Meinungsbilder/Aufhebung der schweizbezogen-Regelung). Im Ernst, hier besteht nun wirklich nicht Bedarf für eine Regegelung. Solange dies ein Wiki ist, bei dem jeder mitmachen darf, gibt es grössere ästhetische Grausamkeiten als zu breite Leerzeichen oder getrennte Zahlen. Ab in die Tonne mit diesem Meinungsbild. -- Bernaner 08:51, 24. Jul. 2008 (CEST)
- Solche Meinungen kommen, wenn man es zum überwiegenden Teil mit Leuten zu tun hat, die sich mit Typographie nicht beschäftigen. Jahrhunderte alte Regeln des Satzes werden einfach ignoriert. Weißraumlöcher? Ja, die werden von der schwarzen Zunft ganz bewußt gesetzt und Bilder ebenso. Hier sind Bleiwüsten beliebt, da hat so ein MB keine Chance auf Erfolg. --RalfR → DOG 2008 09:07, 24. Jul. 2008 (CEST)
- Weißt du, solange ich in der Mehrzahl der WP-Artikel mindestens einen Schreibfehler finden kann, berührt mich jetzt die Punktweite von Leerräumen nicht so sonderlich. Zumal dieses Problem so hochgestochen ist, dass es noch nicht einmal eine Lösung im Standard-HTML gefunden hat. Viele Autoren sind schon mit der Rechtschreibung überfordert. Und Typografie war noch nie Aufgabe des Autors. -- Harro von Wuff 10:38, 24. Jul. 2008 (CEST)
- Ist natürlich was Wahres dran. Aber wir haben hier keine Druckvorstufe. Das hat sich auch bei Wikipress sehr deutlich gezeigt, der Satz war extrem aufwendig. Zu den Schreibfehlern äußere ich mich mal vorsichtshalber nicht ;) --RalfR → DOG 2008 10:52, 24. Jul. 2008 (CEST)
- Weißt du, solange ich in der Mehrzahl der WP-Artikel mindestens einen Schreibfehler finden kann, berührt mich jetzt die Punktweite von Leerräumen nicht so sonderlich. Zumal dieses Problem so hochgestochen ist, dass es noch nicht einmal eine Lösung im Standard-HTML gefunden hat. Viele Autoren sind schon mit der Rechtschreibung überfordert. Und Typografie war noch nie Aufgabe des Autors. -- Harro von Wuff 10:38, 24. Jul. 2008 (CEST)
- OT: @RalfR: vorsicht mit Schlussfolgerungen. ...mit Typographie nicht beschäftigen... oder der Typographie in der Wikipedia nicht den Stellenwert einräumen, den sie ihr in gedruckten Werken einräumen. Aber auch dort sollte gelten, dass der Inhalt wichtiger ist als die Gestaltung. -- Bernaner 10:55, 24. Jul. 2008 (CEST)
- Solche Meinungen kommen, wenn man es zum überwiegenden Teil mit Leuten zu tun hat, die sich mit Typographie nicht beschäftigen. Jahrhunderte alte Regeln des Satzes werden einfach ignoriert. Weißraumlöcher? Ja, die werden von der schwarzen Zunft ganz bewußt gesetzt und Bilder ebenso. Hier sind Bleiwüsten beliebt, da hat so ein MB keine Chance auf Erfolg. --RalfR → DOG 2008 09:07, 24. Jul. 2008 (CEST)
- Ich kann eigentlich nur einen sinnvollen Grund für dieses Meinungsbild erkennen: Es ist ein Rekordversuch. Hier will ein Benutzer innert kürzest möglicher Zeit zwei UÖD schaffen (die andere Baustelle ist Wikipedia:Meinungsbilder/Aufhebung der schweizbezogen-Regelung). Im Ernst, hier besteht nun wirklich nicht Bedarf für eine Regegelung. Solange dies ein Wiki ist, bei dem jeder mitmachen darf, gibt es grössere ästhetische Grausamkeiten als zu breite Leerzeichen oder getrennte Zahlen. Ab in die Tonne mit diesem Meinungsbild. -- Bernaner 08:51, 24. Jul. 2008 (CEST)
- Am besten Ersteres. Siehe mein obiger Einwand. Es ist völlig unklar, welche Frage dieses Meinungsbild eigentlich klären will. --TM 22:43, 21. Jul. 2008 (CEST)
- Das heißt: Meinungsbild in die Tonne kloppen oder ablehnen? -- Achates Wer nichts weiß, muss alles glauben. 12:21, 20. Jul. 2008 (CEST)
- Oh, verbesserungsbedürftig ist reichlich: das Benutzerinterface ist katastrophal, von der Optik überall verkorkste Tabellen, lausige Bildpositionierung, riesige Weißraumlöcher in Artikeln, überproportionierte und vollkommen uneinheitliche Infoboxen und kleine bunte Flaggen, die das Layout kaputtkloppen (nicht selten mit Listenpunkten davor). Wenn es hinduistische Bäume gibt, ist vermutlich die Höchststrafe nach Wiedergeburt eine BILD oder ein Wikipedia-Artikel zu werden. Ach, Du meintest mit den Leerzeichen? Eigentlich nix, geschützte Leerzeichen höchst sparsam verwenden ist klar genug, Sonderwege braucht's nicht, es geht auch so prima. Außer, man möchte Korinthen… —mnh·∇· 03:22, 20. Jul. 2008 (CEST)
andererseits ist zu bedenken, welchen immensen aufwand wir um tabellen, bilder und sogar audio/video, TeX, info- und naviboxen, usw. betreiben, da ist das ja geradezu „minimalinvasiv“: es stimmt eben nicht, dass inhalt und layout prinzipiell zu trennen sind: layout inklusive typographie ist eine form der Texterschließung = sie bereitet die vorhanden informationen so auf, dass sie effektiver erfassbar sind (das schmale leerzeichen zwischen Maßzahl und Maßeinheit mach diese eben als (textliche) einheit besser erfassbar, so wie WP:LIT eine literaturangabe oder eine bildunterschrift ein bild lesbarer macht)- es hat ja schon einen grund, dass die ASCII-textwüsten der 80er-Jahre ausgestorben sind (ebeso wie die entsprechenden DOS/Kommandozeilen-oberflächen weitgehend), so wie es einen grund hat, dass sich die typographie (papier, zu elektr. medium) sich über jahrhunderte entwickelt hat, oder dass rechtschreibung erfunden wurde - alles das ist kein gimmick, sondern dient dazu, sich effektiv auf die inhalte konzentrieren zu können, und jede maßnahme ist ein bausteinchen zu einem gesamten guten erscheinungsbild - nicht um seiner selbst willen, sondern um die gehirnkapazität des lesers (nicht des autors/herausgebers!) statt "erkennen" (des inhaltes) fürs denken (über den inhalt) freizuhalten: das ist das ziel allen publizierens --W!B: 14:31, 3. Aug. 2008 (CEST)
- Sehe das ganz genauso. Und wenn so eine Regelung eingeführt wird, dann wird ja keinem der Kopf abgerissen, wenn er es aus Versehen oder auch mit Absicht falsch macht, aber diejenigen, denen ein vernünftiges Schriftbild wichtig ist, die müssen dann nicht mehr damit rechnen, dass ihnen alles wegeditiert wird. --Ff-Sepp 10:12, 29. Jan. 2009 (CET)
Vorschlag 3
Bearbeiten.. versteht ich nicht: ist das als genereller verzicht auf den schmalen abstand, den nicht-umberchenen abstand, oder überhaupt alles (also nur-Ascii "SPACE") geplant? --W!B: 14:22, 2. Aug. 2008 (CEST)
- Beim Vorschlag 3 geht es darum, weder den schmalen (geschützten/ungeschützten), noch den ganzen, geschützten Zwischenraum zu verwenden. Mit anderen Worten: Es wird ausschließlich »SPACE« (U+0020) – also den ganzen, ungeschützten Zwischenraum – verwendet. --Debianux 20:59, 2. Aug. 2008 (CEST)
Automatisierbarkeit?
BearbeitenPrinzipiell wäre es ja schöner, wenn sich die Autoren um all das nicht kümmern müssten und wir den Quellcode einfach halten könnten. Wäre es nicht möglich, die Zwischenräume automatisiert serverseitig einsetzen zu lassen? (So wie es afaik bei Prozentzeichen geschieht – dort wird derzeit ein normales geschütztes Leerzeichen automatisch eingesetzt. Man vergleiche etwa bei 45 % den Wiki-Quellcode mit dem HTML-Quellcode.) Man müsste dann lediglich noch entscheiden, welches Zeichen man ausgeben lässt – Browserkompatibilität eben – aber die Eingabe und der damit verbundene Aufwand fiele weg.
Natürlich setzt das voraus, dass die Regeln computerverständlich formuliert werden können, aber wenigstens bei Dingen wie Paragraphen- und Rechenzeichen wird die Lage nicht anders als beim Prozent sein. Für Abkürzungen ginge es wohl auch – mit einer Tabelle bekannter Abkürzungen oder einer allgemeinen Erkennungslogik. Sollte doch funktionieren – oder hab ich ein Problem übersehen? --Tobias K. 17:19, 2. Aug. 2008 (CEST)
- Ein Automatisier-Mechanismus wäre natürlich die beste Lösung. Bei den Abkürzungen ist es aber meines Erachtens praktisch unmöglich, ein schmaler, nicht umbrechbarer Zwischenraum einzufügen; die vernünftigste Lösung wäre hier, auf Abkürzungen, die aus mehreren abgekürzten Wörtern bestehen, zu verzichten (Beispiel: »zum Beispiel« oder »bspw.« an Stelle von z.B.). Bei den Paragraphen würde eine Automatisierung auch nur für einfache Fälle funktionieren (zum Beispiel: §5), bei komplizierteren, längeren Fällen (zum Beispiel: §6ff.) ist auch hier eine Automatisierung praktisch unmöglich. Auch bei den Einheitszeichen ist eine Automatisierung meines Erachtens ein Ding der Unmöglichkeit (oder wie soll die Software wissen, dass zum Beispiel »mA« eine Einheit ist? Willst du hier auch eine Liste mit allen möglichen (vermutlich fast unendlichen möglichen) Einheiten erstellen? Eine Ausnahme wäre das Grad-Zeichen; hier sollte eine Automatisierung möglich sein – schließlich funktioniert es ja auch beim Prozent-Zeichen. Bei den Rechenzeichen wäre eine Automatisierung vermutlich möglich – solange nicht fälschlicherweise das »hyphen-minus« verwendet wird. Hier haben wir aber auch die Möglichkeit, für mathematische Formeln das TeX-Markup zu verwenden. --Debianux 21:43, 2. Aug. 2008 (CEST)
- Ich denke schon, dass es möglich wäre, zumindest für
- Rechenzeichen. Viel außer Grundrechenarten, ein Gleichheits- und Ungleichheitszeichen wird man ohne TeX nicht setzen, damit sind die Fälle hoffentlich beschränkt. Das Hyphen-Minus sollte man eh korrigieren, dann passt das auch.
- Paragraphen. Mir fallen so viele Fälle nicht ein. Zwischen § und Ziffer und zwischen Ziffer und dem f./ff. Wo müssten denn noch welche hin?
- Gradzeichen – wie du sagst.
- ‰ ‱ – wenn Prozent, dann auch das…
- Problem sind in der Tat
- Abkürzungen. Sind natürlich eh bei vielen nicht erwünscht, insofern ist die Frage, ob es häufiger Autoren gibt, die einerseits die Abkürzungen verwenden, aber andererseits auch typografische Zeichen in ihren Text setzen würden.
- Einheiten. Quasi unmöglich, ja. Bin daran gescheitert, als ich einem Bot die Erkennung beibringen wollte (Präfix+Einheit, dazu noch Exponenten, Divisionen …) – es gibt vor allem eindeutig zu viele false positives, so heißt „das“ normalerweise nicht „Dekasekunden“.
- Bis auf die Einheiten und die Abkürzungen würde ich es doch zunehmend für lohnend halten, den Server die Arbeit machen zu lassen. Allheilmittel ist natürlich nicht.
- Interessant wären noch praktische Erwägungen, etwa die nötige Serverlast. Höher als Vorlageneinbindung ist sie aber meiner laienhaften Meinung sicher nicht. --Tobias K. 23:52, 2. Aug. 2008 (CEST)
- es gibt sicher eine menge fälle, die automatisiert abfangbar sind: für § gibt es natürlich Vorlage:§ und konsorten, die angepasst werden können, z. B., d. h. etwa könnten wie % über das CSS gemacht werden, auch das projekt mit Vorlage:Zahl,
formatnum
(das mal so nicht geklappt hat), Vorlage:Literatur für die seitenangaben, .. - aber ebensoviele eben doch nicht.. --W!B: 14:18, 3. Aug. 2008 (CEST)
- es gibt sicher eine menge fälle, die automatisiert abfangbar sind: für § gibt es natürlich Vorlage:§ und konsorten, die angepasst werden können, z. B., d. h. etwa könnten wie % über das CSS gemacht werden, auch das projekt mit Vorlage:Zahl,
- Ich denke schon, dass es möglich wäre, zumindest für
auf jeden fall könnten wir sicher mal sichten, welche techniken alle vermeiden, einen nbsp;/thinsp;/nnbsp; im quelltext direkt setzten zu müssen --W!B: 14:46, 3. Aug. 2008 (CEST)
- Ich kann einfach immer noch nicht verstehen, weshalb die Vorlage:\ nun trotzdem gelöscht wurde; ein »{{\}}« ist sogar weniger Quelltext-belastend als ein » « oder sogar ein » «. Debianux 14:57, 3. Aug. 2008 (CEST)
- warum? ganz einfach, weil sie unvorbereitet in die welt gesetzt war: da hätte das lobbing, das jetzt hier gemacht wird, vorher gemacht gehört: jetzt hat die sache wellen geschlagen, und es wird mühsamer.. --W!B: 20:06, 4. Aug. 2008 (CEST)
Zum Thema Prozentzeichen hab ich noch mal im Archiv gewühlt und den Diff von der Einführungs-Bekanntgabe sowie den mit dieser Neuerung erledigten Bug gefunden. Inwieweit man auch projektspezifische Dinge auf diese Weise einhängen könnte, weiß ich nicht. Eine RegEx-basierende Lösung, die idealerweise auch sprachweise konfiguriert werden könnte, wäre wohl das Optimum. Was genau geht, wissen wohl erst mal nur die Devs (bis wir sie gefragt haben). --Tobias K. 00:27, 5. Aug. 2008 (CEST)
- wow danke, nocht interessanter ist übrigens der fix: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/23415
- das wäre auch denkbar für Gedankenstrich (keine schmales leerzeichen)
- jedenfalls ist dort leicht herauszulesen, was alles direkt in Parser.php geht, und nicht über vorlagen gemacht werden braucht - dort kann dereinst einfach implementiert werden --W!B: 21:59, 17. Okt. 2008 (CEST)
- Danke für deine Initiative (Meinungsbild) zu diesem Aspekt! Ich bin durch "S. 123ff." <=> "S. 123 ff." darauf gestossen, was leicht automatisierbar sein sollte. Hier Liste meiner Argumente (pro "S. 123 ff."):
- ff. steht als Abkürzung für ein Wort ("folgende"), das man beim Ausschreiben nicht direkt hinter die Zahl setzen würde.
- Beim Bundesverfassungsgericht schreibt man mit Leerstelle
- Hier Autorenhinweis zu ff. mit geschützter Leerstelle
- Habe die Seite auf meine Beobachtungsliste gesetzt, würde mich aber trotzdem freuen, informiert zu werden, wenn die Abstimmung startet. Besten Gruss --Grey Geezer 17:47, 11. Dez. 2008 (CET)
- Ich werde dich gerne informieren, wenn das Meinungsbild startet. Sobald ich Zeit habe, werde ich das Meinungsbild jedoch noch komplett überarbeiten; in der momentanen Form wird es wohl nicht gestartet. Lieben Gruß, Debianux 22:31, 11. Dez. 2008 (CET)
- Danke für deine Initiative (Meinungsbild) zu diesem Aspekt! Ich bin durch "S. 123ff." <=> "S. 123 ff." darauf gestossen, was leicht automatisierbar sein sollte. Hier Liste meiner Argumente (pro "S. 123 ff."):
Quelle?
BearbeitenAus welchem Standardwerk der deutschen Typographie stammen denn die Forderungen über die Verwendung der Zwischenräume die Thema dieses Meinungsbildes werden sollen, für welche Anwendungsbereiche sind sie dort vorgesehen und wo gibt es – außer in DIN 5008 – möglicherweise andere Festlegungen? – Schnargel 17:19, 3. Aug. 2008 (CEST)
- Zum einen sind es typographische Gepflogenheiten, zum anderen eine Zusammenfassung aus mehreren Fachbüchern und Portalen/Seiten im Internet, die sich mit der Typographie – hier speziell mit Zwischenräumen – beschäftigen. Eine recht gute Übersicht findet sich übrigens auch im Duden (24. Auflage), dort unter der Überschrift »Textverarbeitung und E-Mails«. Duden schreibt übrigens: »Die folgenden […] Hinweise gelten für Satzsysteme und für moderne Textverarbeitungssysteme.« Da Artikel von der Wikipedia häufig ausgedruckt werden, bin ich der Meinung, dass solche »Regeln« auch hier gelten sollten – wenn auch vielleicht nicht im selben Ausmaß. Auch am Bildschirm finde ich eine saubere Typographie wünschenswert. --Debianux 17:54, 3. Aug. 2008 (CEST)
- Saubere Typographie halte ich auch für wünschenswert, allerdings halte ich eine solide Referenz auf die man sich beziehen kann für ebenso wünschenswert. Wenn man typographische Regeln hier aus ein paar Büchern und da von ein paar Webseiten zusammenstellt und dann noch mit Gepflogenheiten ergänzt mag man zwar im großen und ganzen eine Sammlung sinnvoller Regeln erhalten, der nächste setzt aber seine Prioritäten anders und kommt mit dem selben Verfahren zu einem genauso sinnvollen Regelwerk, das dann aber etwas abweicht. Du kannst ja sicher noch etwas Literatur und Webseiten nennen.
- Wie dem auch sei. Ich sehe oft, dass zu der Wikipedia beitragende Schreiber nicht einmal in der Lage sind, überhaupt ein Leerzeichen an mancher richtigen Stelle zu setzen (ganz zu schweigen von dem korrekten Einsatz von „-“, „–“ und „ – “) und daran wird auch ein Meinungsbild nichts ändern. Um weiter Fortgeschrittenen die Arbeit nicht unnötig schwer zu machen wäre es, wie oben gesagt, sinnvoll, die Arbeit von der Software erledigen zu lassen. Das würde bedeuten, dass bei der Eingabe nur normale (und eventuell noch normale feste) Leerzeichen verwendet werden und bei der Ausgabe die entsprechenden Leerzeichen (und Punkte in Zahlen) in typographisch passendere umgewandelt werden. Zur Umwandlung würde man ein „Helferlein“ wie das für die schweizerische Rechtschreibung verwenden, welches mit einer Anzahl regulärer Ausdrücke die entsprechenden Leerzeichen einsetzt. Im Gegensatz zu der von Dir oben geäußerten Meinung denke ich, dass sich mit noch verhältnismäßigem Aufwand über 90 % der entsprechenden Leerzeichen erkennen lassen. Auch eine Erkennung von „§ 6 ff.“ ist einfach möglich.
- Dies hätte die deutlichen Vorteile der einfacheren Les- und Schreibbarkeit des Quelltextes und der Abschaltmöglichkeit oder Wahl einer anderen Umwandlung für spezielle Screenreader oder Browser. – Schnargel 22:19, 3. Aug. 2008 (CEST)
- Natürlich wäre es am besten, die Software könnte alles alleine machen. Wie ist es denn genau mit dem Prozentzeichen? Ist es die Software MediaWiki selbst, welche diese Änderung (»90 %« → »90 %«) vornimmt? Dann müsste man sich wohl mit den Programmierern in Verbindung setzten. Wegen dem Standardwerk: Ich kann dir gerade nicht sagen, in welchem Werk die Zwischenräume-Frage am besten wiedergegeben wird – die Bücher habe ich nicht bei mir zu Hause, da sie recht teuer sind; ich werde aber in den nächsten Tagen in der Bibliothek vorbei schauen. Wenn ich mich nicht irre, ist die Zwischenraum-Frage im Werk »Detail-Typographie« (evt. auch mit »f« an Stelle von »ph«) am besten aufgeführt. Für den Alltag (also das Schreiben von Dokumenten am Computer) beziehe ich mich meistens auf das erwähnte Kapitel im Duden. Wenn nun alles per Software geregelt werden könnte, sollte man dann dieses Meinungsbild auf die Frage, ob man die veraltete Punkt-Schreibweise bei Zahlen aufgeben und die ISO-31-konforme Schreibweise (mit schmalen, nicht umbrechbaren Zwischenräumen) einführen soll, reduzieren? Debianux 11:36, 4. Aug. 2008 (CEST)
- Ich war nun heute in der Bibliothek und habe in den Typographie-Büchern nachgeschaut. Die Zwischenraum-Frage wird im Buch »Detailtypografie« sehr ausführlich behandelt (unter anderem Seiten 171–201, Kapitel »Satzzeichen und weitere Satzdetails«). Hier die Angaben zum Buch:
- Friedrich Forssman, Ralf de Jong: Detailtypografie – Nachschlagewerk für alle Fragen zu Schrift und Satz. 2. Auflage. Verlag Hermann Schmidt Mainz, Kassel 2004, ISBN 978-3-87439-642-4, S. 171–201.
- Die beste – und nicht allzu detaillierte – Übersicht, die man auch hier für die Wikipedia benutzen könnte, befindet sich aber trotzdem im Duden (siehe oben erwähntes Kapitel). Das »Problem« ist eben auch, dass die Festabstände nicht von allen Editoren gleich behandelt wird, weshalb es nicht die einzige Regel dazu gibt. Debianux 19:55, 5. Aug. 2008 (CEST)
Name?
Bearbeitenübrigens find ich "Zwischenraum" etwas befremdlich, Leerzeichen (zu fachsprachlich wohl Leerraum bzw. Weißraum wär korrekt.. --W!B: 20:04, 4. Aug. 2008 (CEST)
- In der Typographie ist Wortzwischenraum am geläufigsten. Damit es aber allen klar ist, können wir gerne einen anderen Begriff verwenden. Debianux 21:34, 4. Aug. 2008 (CEST)
- wusste ich gar nicht, na dann passts ja..
- Ich habe das Wort Zwischenraum gewählt, weil Wortzwischenraum ja nicht ganz stimmt – es geht ja hier nicht um Zwischenräume zwischen Wörtern, sondern zwischen Zahlen und Einheiten, Zahlen und Rechenzeichen, Ziffern etc. Leerzeichen und Leerschritt werden in der Typographie meines Wissens fast nie gebraucht, Weißraum wäre falsch, da der Raum zwischen zwei Zeilen (Zeilenabstand) auch Weißraum ist (also nicht nur zwischen zeichen). Leerraum habe ich in diesem Zusammenhang noch nie gehört. Weißabstand wäre eigentlich das korrekteste Wort für dieses typographische Phänomen, da es jedoch zu fachsprachlich klang, habe ich Zwischenraum bevorzugt. Schließlich wäre ein sog.Festabstand ein Weißabstand mit fester Größe, der also auch im Blocksatz unveränderlich bleibt. Debianux 19:17, 5. Aug. 2008 (CEST)
- wusste ich gar nicht, na dann passts ja..
Zu kompliziert
Bearbeitenich persönlich finde den aufbau falsch: das MB sollte sich in drei konkrete abschnitte untergliedern:
- sollen wir überhaupt
und die schmalen 
und&nnsp;
verwenden- ja immer (i.S.e. Richtlinie)
- al gusto, aber nicht revertieren, wenn sie eingefügt werden (sanftes Einschleifen)
- nur den nbsp; - die schmalen nie
- nein, nie und keines
- wenn ja (und das sollten auch die ausfüllen, die es ablehen: man kann dagegen sein, sich dann aber für das kleinere über entscheiden), wie soll es technisch umgesetzt werden? hier etwa auch option auf mehrere alternativen, oder streng nur das eine oder andere
- mit HTML-entity
- mit Unicode direkt (adhoc nicht erkennbar, setzt 4. voraus, und wohl auch einen button..)
- mit Vorlagen (siehe 3., 4.)
- wie soll der workaround für die browser aussehen, die die zeichen nicht korrekt darstellen können (wen das nicht interessiert, der braucht nicht weiterlesen..):
- im wiki-quelltext (also dann mit Vorlage: setzt 2.3 voraus), wie es die - der whitespace hab sie selig - geweste Vorlage:\ gemacht hat
- im CSS, indem standardmässig die drei unicodepoints durch etwas anderes ersetzt werden
- gar nicht, der leser soll sich selbst ein JavaScript installieren oder seine CSS anpassen, wenn angemeldet
- Zusatzfragen:
- und wenn ja vorlagen, wie sollen sie heissen?
{{\}}
=nnbsp: Vorlage:\ - wie die anderen? geht nicht:{{_}}
=nbsp: {{_}} |{{ }}
=thinsp: {{ }}- etwa wie TeX:
{{\}}
=nbsp: Vorlage:\ |{{\;}}
=thinsp: Vorlage:\; |{{\,}}
=nnbsp: Vorlage:\, {{nbsp}}
=nbsp |{{thinsp}}
=thinsp |{{nnbsp}}
=nnbsp - dient dann primär punkt 4.2
- sollen wir an einer darstellung in WikiEd, oder einem Gadget arbeiten? wie soll es dargestellt werden?
- z. B. lief Kaiser Franz I. 30 000 m (Texteditoren machen das so)
- z._B. lief Kaiser Franz_I. 30_000_m (stört den Lesefluss weniger)
- sollen in den edittools und den editbuttons std-mässig alle drei zeichen auftauchen?
- und wenn ja vorlagen, wie sollen sie heissen?
--W!B: 20:39, 4. Aug. 2008 (CEST)
- Ich finde dein Vorschlag nicht schlecht, er ist aber meines Erachtens etwa gleich kompliziert wie das Meinungsbild im Moment ist. Ich denke, wir sollten zuerst abklären, ob eine automatische Realisierung möglich wäre (siehe meinen Kommentar im Abschnitt Quelle?) und uns erst dann über den Inhalt des Meinungsbildes den Kopf zerbrechen. Eventuell wäre es sinnvoll, ein Meinungsbild zu erstellen, das ausschließlich die Frage beantworten soll, ob wir die veraltete Zahlenschreibweise erneuern wollen (1.234 → 1 234). Debianux 21:42, 4. Aug. 2008 (CEST)
- das halte ich für so gefährlich, wie Vorlage:\ zu erstellen: insellösungen sind nie gut, entweder gscheit, oder garnicht: die argumente, die gegen diese vorlage waren (sie dienten auch nur der zahlentypo, waren dahingehend eindeutig, und haben sich nicht gändert, es wär nur ein widerherstellungsversuch auf umwegen: imho vermischt auch dieses MB die beiden fragen, also sollten sie vielleicht wirklich getrennt werden, und die zahlenfrage danach erledigt werden (bei ablehnung des grund-MBs wär sie hinfällig, umgekehrt reisst sie die prinzipielle frage vielleicht mit in den abgrund
- sonst hast Du aber sicherlich recht: ich wollte mehr sichten, welche konkreten fragen/angebote über lösungen zu präsentieren wären.. --W!B: 01:21, 5. Aug. 2008 (CEST)
- Und wenn wir’s bei der Zahlen-Schreibweise so machen würden wie unsere französischsprachigen Kollegen? Sie verwenden {{formatnum:…}} um eine Zahl zu formatieren (siehe zum Beispiel Abschnitt Villes im Artikel Suisse) und zwar in der Schreibweise »12 234« (ja, ich wusste, dass uns die Franzosen immer ein wenig voraus sind ☺), da wäre es sicherlich möglich, analog dazu einen schmalen, nicht umbrechbaren Zwischenraum einzufügen. Nun ja, das Problem wäre vermutlich wieder das selbe wie bei der Zahl-Vorlage; eventuell kommen wir aber bei einem Meinungsbild zu einem anderen Ergebnis als bei der Löschdiskussion der Zahl-Vorlage. Übrigens: Wer ist für die korrekte Formatierung von »formatnum« verantwortlich? Irgend ein Super-Admin? Debianux 10:09, 5. Aug. 2008 (CEST)
Ich würde bei Frage 1 zwischen Punkt 2 und 4, vielleicht anstelle von Punkt 3 ergänzen „nur in Vorlagen und Tabellen; nie im Fließtext“. Wichtiger ist es aber tatsächlich erst einmal die technischen Möglichkeiten (MediaWiki-Anpassung) für automatische Leerzeichenersetzung zu eruieren, bevor man den Wikiquelltext mit Steuerungsbefehlen zukleistert. Schönen Gruß --Heiko 10:02, 5. Aug. 2008 (CEST)
Sichtung der technischen Optionen
Bearbeitenzu Kenntnisnahme:
- Kategorie:Vorlage:Zahlenformatierung neu, jetzt im Angebot, mit vielen schönen Sachen..
;) --W!B: 16:42, 5. Sep. 2008 (CEST)
- aber leider ohne Vorlage:Zahl und Vorlage:\ ;( Debianux 20:42, 6. Sep. 2008 (CEST)
- jupp, aber wer weiß, was das MB bringt.. --W!B: 15:41, 25. Sep. 2008 (CEST)
- aber leider ohne Vorlage:Zahl und Vorlage:\ ;( Debianux 20:42, 6. Sep. 2008 (CEST)
Behinderung der Mitarbeit
BearbeitenWenn ich als einzelner Nutzer das mache, was hier an bürokratischen Fesseln und Arbeitsverursachung für minimalste Verbesserung ersonnen wird, werde ich wegen Projektstörung infinit gesperrt, und zwar vermutlich zu Recht. Als Autor kann, will und werde ich mich mit Inhalten und zughöriger basismäßiger Form beschäftigen, sicher nicht mit mehr. Alles, was in der Vorschau nicht gut erkennbar und nicht mit vertretbarem Aufwand und zugleich relevantem Ergebnis gestaltet werden kann, hat hier m.E. nichts verloren. Wir haben zahllose gute Autoren und Mitarbeiter, die nur sporadisch mitmachen (können) und die weder die Zeit noch den Nerv haben, dieses Bürokratiemonster hier zu verstehen oder gar umzusetzen. Bislang ist Wikipedia gut ohne diese Detailverbesserungswut ausgekommen. Ich bitte dringend, die Sache auf ein oder zwei grundlegene Anliegen, die man in einem Absatz überzeugend darstellen kann, zu vereinfachen oder das Ganze bitte bleiben zu lassen. Ich werde jedenfalls - ohne jede kompliziere Formatierung - für alle derzeitigen Änderungen mit NEIN stimmen. Das bringt m.E. so nichts. Sorry für die klaren Worte, Grüße Felix Sandberg 08:57, 16. Sep. 2008 (CEST)
- ganz im gegenteil: vielen dank dafür - imho triffst Du den punkt: sinnvoll sind nur lösungen, die den autor nicht behindern (oder nicht mehr als andere typographische konventionen wie „“ statt "", × statt x, oder – statt - ) - wenns nicht einfach ist, taugts eh nicht --W!B: 22:11, 17. Okt. 2008 (CEST)
Keine anderen Sorgen?
BearbeitenHat die Wikipedia keine anderen Sorgen, haben nur manche Formalisten Langeweile oder soll hiermit nur die Basis für neuen Konfliktstoff gelegt werden? Wenn hier manche der Meinung sind, dass es nicht so sehr auf den informativen und belegten Inhalt von Artikeln ankommt, sondern die Gewichtung auf korrekte Typografie zu legen ist, dann frage ich mich ernsthaft, wohin das führen soll. Und das sage ich als einer, der sich sehr wohl immer wieder mit typografischen Verbesserungen von Inhalten beschäftigt. Noch wichtiger sind aber noch immer die Inhalte. Wenn es darum geht, dass lesenswerte Artikel weitgehend typografisch korrekt sein sollen und exzellente Artikel absolut typografisch korrekt sein müssen, dann stimme ich dem ebenso zu, wie ich dies für „normale“ Artikel kategorisch ablehne. Wer auch immer will, der kann sich ja mit der korrekten Typografie beschäftigen und als Lektor Artikel verbessern, wobei es dann auch wünschenswert wäre, sich auf der Benutzerseite in einer Kategorie als Lektor darzustellen. Damit wäre dann jenen Schreibern geholfen, die Artikel einer Kandidatur zuführen wollen. Selbst (gut bezahlte) Journalisten von Qualitätsmedien oder auch Buchautoren kümmern sich nur bis zu einem gewissen Grad um eine korrekte Typografie und lassen die Texte gerne von Lektoren prüfen und verbessern. Warum sollte es in der Wikipedia anders sein, wie im normalen Leben? Oder will wirklich ernsthaft jemand hier in einem freien Projekt verlangen, dass Benutzer erst tagelanges Studium betreiben müssen, ehe sie für Artikelinhalte einen Finger krumm machen dürfen? Das kann sicher nicht der Weisheit letzter Schluss sein! -- Steindy 02:35, 4. Okt. 2008 (CEST)
- richtig: was auch immer beschlossen wird, es muss a) optional in der artikelarbeit und b) die "einfache" typographie einfach erweiternd sein (wie eins oben: „“ statt "", × statt x, oder – statt - ) - wird je ein autor "geschimpft", wenn er gute artikelarbeit macht, aber die typographie simpel verwendet? hoffentlich nein, man liest mit freuden, und bessert kommentarlos und gerne nach.. (ich zumindest) - so stell ich mir das mit den leerräumen auch vor --W!B: 22:17, 17. Okt. 2008 (CEST)
Wie weiter?
BearbeitenAufgrund der großen Ablehnung des Meinungsbildes, die ich an den Kommentaren dieser Diskussionsseite spüre, ist es vermutlich kluger, wenn man das Meinungsbild auf die grundlegende Fragen beschränkt, ob Vorlagen (wie die gelöschte Vorlage:\), die einen schmalen, nicht umbrechbaren Zwischenraum simulieren, verwendet werden dürfen oder nicht. Erst danach sollte entschieden werden, wie es mit der Zahlenschreibweise (Tausendertrennzeichen) in der Wikipedia weitergehen soll. Was meint ihr?
Was die Automatisierbarkeit betrifft, hatte ich mit meinen Nachforschungen bisher keinen Erfolg. Wer könnte mir hier helfen?
Debianux 15:26, 6. Okt. 2008 (CEST)
- ganz meiner meinung: wir solten die fragen „ob überhaupt“, die „Zahlenschreibweise“ und die suche nach methoden, die eine spätere einfache verwendung vorbereiten (parser, vorlagen, CSS, JS-skripte), oder sie als persönliche anpassung ermöglichen, voneinander trennen..
- nachdem Tobias K. den code in der Parser.php aufgegegabelt hat, hab ich dort weitergeschrieben.. --W!B: 22:04, 17. Okt. 2008 (CEST)
Und wie wird das Ganze realisiert?
BearbeitenUnd wie wird dann diese Vorschrift realisiert?
- Wenn man die Benutzer ermahnt und mit Sperrungen droht, dann verliert die Wikipedia (gute) Mitarbeiter und der Wikipedia droht ein Imageschaden.
- Korrektur durch andere Benutzer: Administratoren sind mit Vandalen und Edit-Wars beschäftigt, zur Zeit sind 11894 Artikel ungesichtet (die Sichter sind also auch beschäftigt), und viele Benutzer sind nicht 24 Stunden pro Tag in der Wikipedia und übernehmen lieber inhaltliche Verbesserungen.
Das heißt, dann wird bald in den Artikeln ein Rückstand wie beim Sichten sein. Da hilft nur, die Änderungen automatisch durch Bots zu realisieren. Man sollte zumindest keine Benutzer darüber ermahnen, um nicht ein schlechtes Image zu bekommen. -- Tofra Diskussion Beiträge 20:54, 2. Nov. 2008 (CET)
Gründe für dieses Meinungsbild
BearbeitenDa hier einige ja stark gegen dieses Meinungsbild wettern, eine kurze Zusammenfassung, warum ich es wichtig finde:
- es ist keine Formalie, die keinen Sinn hat, sondern erhöht die Lesbarkeit von Texten mit vielen Zahlen stark
- wird wohl niemandem mit Ausschluss gedroht, wenn er bei der Einstellung von Texten das nicht beachtet
- ist die Ergänzung um die richtigen Leerzeichen nicht sonderlich aufwendig und kann sukzessive durch Leute erfolgen, denen daran gelegen ist
- es sieht einfach besser aus
Ich finde die momentane Gestaltung des Meinungsbildes gut durchdacht, und befürworte es ausdrücklich! --Ff-Sepp 17:22, 18. Nov. 2008 (CET)
- 100 % dahinter. Ein logischer, gut formulierter Artikel kann an Glaubwürdigkeit verlieren, wenn durch die typographische Darstellung "Merkwürdigkeiten" entstehen. Die Darstellungsform IST wichtig und als Hilfe für Autoren und Leser gedacht, nicht als Joch! Gruss --Grey Geezer 10:06, 12. Dez. 2008 (CET)
Aufbau unlogisch
BearbeitenEs bleibt unlogisch, warum plötzlich innerhalb 3 noch darüber abgestimmt wird, ob man denn "z.B." oder "z. B." schreibt. Das ist doch eine völlig andere Baustelle, die dementsprechend auch von allen oder niemand beantwortet werden sollte.
Es sollte in der Abstimmung klar sein, ob sich Benutzer "generell" für eine Lösung aussprechen - oder nur unter der Voraussetzung, daß alle/viele/bestimmte Browser das darstellen können. Man kann nicht von allen Teilnehmern erwarten, daß sie da den Überblick haben - auch nicht nach der (mir zumindest nur teilweise verständlichen) Tabelle auf der Meinungsbildseite. Informationen über Barrierefreiheit habe ich gar nicht gefunden (oder wo habe ich die übersehen?).
W!Bs Vorschlag vom 4. August finde ich komplizierter, aber sehr viel demokratischer - wer verschachtelte Abstimmungen veranlaßt, sollte trotzdem allen Beteiligten die Möglichkeit geben, sich für und gegen alle Unter-Varianten auszusprechen (vgl. auch erster Abschnitt zum "z.B."/"z. B.").
... nur für den Fall, daß das Meinungsbild wirklich noch zustandekommt... --Ibn Battuta 06:01, 21. Nov. 2008 (CET)
- Das Meinungsbild ist in der aktuellen Version tatsächlich zu kompliziert – unlogisch finde ich es aber nicht wirklich; schließlich hat die Schreibweise »z. B.« oder »z.B.« auch direkt mit dem Zwischenraum zu tun. Sobald ich Zeit habe, werde ich das Meinungsbild jedoch von Grund auf neu strukturieren. Ich finde W!Bs Vorschlag nicht schlecht und werde ihn sehr wahrscheinlich als Grundlage nehmen. Das wegen der Barrierenfreiheit kläre ich nochmals ab; wir haben schon einmal darüber diskutiert aber nicht alle Varianten getestet. Debianux 09:48, 21. Nov. 2008 (CET)
übrigens ist als neuer faktor dazugekommen, dass ja das automatische erstellen von pdfs unserer artikel näher kommt (ich weiß aber nicht, wo die diskussionsplattform dazu ist) - jedenfalls wird die ganz vergessene druckvorschau damit wieder fröhliche urstände feieren, und typographische sauberkeiten (neben den abständen natürlich auch das einfügen in die DIN A4-seite, also maßnahmen bzlg. zu langer infoboxen, tabelen, sauberer bildeinbindung, usw.) zunehemend wichtig werden - in einem pdf schaut sowas noch scheußlicher aus als am bildschirm, ausserdem liegen die umbrüche typischerweise nicht mehr dort, wo sie der autor erwartet.. wenn jemand weiß, wo die pdf-disks stattfinden, wäre interessant, die leistungsfähigkeit unseres pdf-exporters anzuklären.. (eine alte seite 2006 ist hier)
zum anderen ist aber die Wikipedia:Kurier#Spende für Benutzerfreundlichkeit Stanton Grant-initiative zu einfacherem sourcecode zu bedenken: zweifellos wird es auf eine lösung hinauslaufen, in der es einen plaintext gibt, über den (automatisch und/oder per handarbeit der erfahreneren autoren) eine akzeptable präsentation gestülpt wird - da das aber wohl bis 2010 dauern wird, sind auf jedenfall alle lösungen, die sich per bot, vorlage oder noch besser CSS/JS steuern oder umbauen lassen, vorzuzuziehen: der wildwuchs an formatierung im text hat ja auch seine schattenseiten, also geht es um einfache, klar strukturierte lösungen --W!B: 09:54, 12. Dez. 2008 (CET)
- Da das PDF-Feature seit heute auch auf DE-WP funktioniert habe ich mir mal die PDF-Version meiner Labor-Seite Benutzer:Debianux/Labor#Browser-Unterstützung heruntergeladen und angeschaut … und war ehrlich gesagt sehr enttäuscht: Weder der schmale, nicht umbrechbare Zwischenraum, noch unser Workaround mit
<span style="margin-left:0.167em"> … </span>
wird korrekt dargestellt!   bricht sogar um! :( Debianux 13:54, 27. Jan. 2009 (CET)- oje.. wir sind vielleicht wirklich unserer zeit voraus.. --W!B: 19:03, 27. Jan. 2009 (CET)
- Oder dann ist diese Software veraltet … Was hälst du eigentlich von einer Umstellung der Zahlenschreibweise auf
123 456
, also mit einem ganzen, nicht umbrechbaren Zwischenraum (siehe auch letzter Abschnitt)? Debianux 19:33, 27. Jan. 2009 (CET)
- Oder dann ist diese Software veraltet … Was hälst du eigentlich von einer Umstellung der Zahlenschreibweise auf
- oje.. wir sind vielleicht wirklich unserer zeit voraus.. --W!B: 19:03, 27. Jan. 2009 (CET)
Ganz anderer Vorschlag
BearbeitenIch weiß, dass ich damit chancenlos bin, aber ich habe einen ganz anderen Vorschlag. Wiki-Markup war ja mal als einfach eingebbares, menschenlesbares Markup gedacht. Mit dieser Grundidee sollte das Leerzeichen, dass am häufigsten gebraucht wird aber "fehlt" durch ein simples "_" im Wiki-Quelltext codiert werden:
12_345_678_Hz 36_°C
Wie das gerendert wird kann in den benutzerspezifischen Einstellungen gewählt werden. Default für nicht angemeldete Benutzer irgendetwas "harmloses" (z.B: ). Wennn sich die Softwareunterstützung für korrekte Typographie in fünf Jahren gebessert hat, kann ein besserer Default benutzt werden. Der Quelltext aber bleibt langzeitstabil.
Mit der gleichen Begründung würde ich mit auch "--" für Bindestriche wünschen.
--Pjacobi 15:10, 17. Dez. 2008 (CET)
- Keine schlechte Idee; müsste man mal auf bugzilla.wikimedia.org vorschlagen. Wie würdest du denn aber zwischen dem schmalen und dem »normalen« nicht-umbrechbaren Zwischenraum/Leerzeichen unterscheiden? Debianux 15:19, 17. Dez. 2008 (CET)
- die idee mit dem _ ist ja schon haeufiger genannt worden. ich glaube, dass die idee vor allem daran gescheitert ist, dass keiner geglaubt hat, dass das jemals implementiert werden wuerde. ein noch zu loesendes problem dabei ist:
- wie gibt man dann den literalen unterstrich ein? (iow: wie stellt man einen unterstrich dar? <nowiki>_</nowiki> waere halt irgendwie nicht so schoen.)
- die unterscheidung zwischen den beiden verschiedenen leerzeichen koennte man afaics recht einfach durch "_" vs. "__" loesen, wobei obiges problem bestehen bleibt.
- vielleicht waere "_" = underscore, "__" = "schmales, nicht umbrechbares leerzeichen", "___" = "nicht umbrechbares leerzeichen" ein ansatz. -- seth 15:28, 17. Dez. 2008 (CET)
- Gibt es eine legitime Anwendung des Unterstrichs außer in Programmquelltexten? --Pjacobi 15:44, 17. Dez. 2008 (CET)
- Mir kommt gerade auch keine Anwendung in den Sinn – außer natürlich bei Zeitleisten. Debianux 16:24, 17. Dez. 2008 (CET)
- danach suchen geht per wiki-suche wohl leider nicht. aber ich hab noch welche gefunden in Nickname, Wildcard (Informatik), Uniform Resource Locator, Emoticon, ASCII-Art, in einigen internetadressen und natuerlich auch in wikilinks, in denen ja eh schon "_" = " " gilt.
- ich vermute, dass einem im bugtracker noch mehr leute mehr beispele nennen wuerden. -- seth 16:32, 17. Dez. 2008 (CET)
- Gibt es eine legitime Anwendung des Unterstrichs außer in Programmquelltexten? --Pjacobi 15:44, 17. Dez. 2008 (CET)
- Folglich wäre es besser,
_
nicht zu »missbrauchen«. Wenn wir aber__
oder___
verwenden würden, so würde ich__
für den gewöhnliche (nicht-schmalen) und___
für den schmalen nicht-umbrechbaren Zwischenraum empfehlen, da der gewöhnliche nicht-umbrechbare Zwischenraum weit mehr vorkommt als der schmale. Debianux 16:41, 17. Dez. 2008 (CET)- 3 underscores fuers schmale und 2 fuers normale widerspricht imho der intuition. wo sollten denn eigentlich ueberall gewoehnliche non-breaking spaces stehen? spontan faellt mir da nur ein: zwischen titel und name sowie evtl. zwischen tageszahl und monat.
- aber ehrlich gesagt wuerde mir der missbrauch des "_" dennoch irgendwie am besten gefallen, weil es die eingabe am ehesten vereinfachen wuerde. urls und wikilinks sollten ja keine probleme bereiten. zwischen code-tags wird man ebenfalls kein geschuetztes leerzeichen brauchen. fraglich ist, wieviel da noch uebrig bleibt.
- ach, ich frag jetzt einfach mal Raymond, ob er schon mal sagen, kann, was er prinzipiell fuer durchfuehrbar haelt und was nicht. -- seth 17:28, 17. Dez. 2008 (CET)
- Ich bin ja nicht gerne ein Spielverderber, aber Bug 3461 Syntax extensions: special character for non-breaking space (& nbsp ;) schimmelt schon etwas länger vor sich hin :-/ — Raymond Disk. Bew. 17:41, 17. Dez. 2008 (CET)
- oha, danke fuer die schnelle antwort. den kommentaren nach zu urteilen, haben viele nur halbwissen ueber die ganze sache. hoffen wir, dass einer der programmierer den ueberblick behaelt. naja, ich hab jetzt jedenfalls fuer den bug gevotet. jetzt wird bestimmt alles gut. *huestel* -- seth 18:32, 17. Dez. 2008 (CET)
- + 1 Stimme von mir … Debianux 23:29, 17. Dez. 2008 (CET)
- oha, danke fuer die schnelle antwort. den kommentaren nach zu urteilen, haben viele nur halbwissen ueber die ganze sache. hoffen wir, dass einer der programmierer den ueberblick behaelt. naja, ich hab jetzt jedenfalls fuer den bug gevotet. jetzt wird bestimmt alles gut. *huestel* -- seth 18:32, 17. Dez. 2008 (CET)
- Ich bin ja nicht gerne ein Spielverderber, aber Bug 3461 Syntax extensions: special character for non-breaking space (& nbsp ;) schimmelt schon etwas länger vor sich hin :-/ — Raymond Disk. Bew. 17:41, 17. Dez. 2008 (CET)
- Folglich wäre es besser,
Meinungsbild eingeschlafen
BearbeitenIch habe das Meinungsbild unter die »eingeschlafenen« einsortiert. Wir müssen das Meinungsbild nicht starten, um zu wissen, dass es sowieso abgelehnt würde. Mikrotypographie wird in der Wikipedia (leider) nicht gern gesehen. Solange das   noch nicht von allen Browsern bzw. Schriftarten unterstützt wird, hat es wohl keinen Sinn, sich mit diesem Thema zu beschäftigen. Die Wiederherstellung der \-Vorlage macht ebenfalls keinen Sinn, da das span-Workaround momentan ausschließlich im Artikel Zifferngruppierung verwendet wird. Mein momentan einziges Anliegen hinsichtlich Typographie ist, die Zahlenschreibweise in der gesamten deutschsprachigen Wikipedia analog zur französischsprachigen Wikipedia auf die Form 1 234 567
zu wechseln. Vorschläge und Mitstreiter sind herzlich willkommen. Allen an diesem Meinungsbild Beteiligten ein herzliches Dankeschön. Debianux 16:02, 25. Jan. 2009 (CET)
- an dieser stelle noch ein mal der hinweis auf die von mir oben verlinkte diskussion. wenn Raymond damit durchkommen wuerde, koennten wir sogar das ex-template "\ " wieder aufleben lassen, da die argumente der loeschung sich ja iirc vor allem auf die eingabe-komplexitaet bezogen. wenn die eingabe allerdings leichter wuerde, z.b. durch
123_456
(statt123{{\ }}456
) haette das afaics chancen, durchzukommen. wir muessten eigentlich nur die damaligen template-gegner dazu fragen. von nbsp zwischen zahlen bin ich ehrlich gesagt nicht (mehr) so begeistert, weil dieses leerzeichen zu breit ist. -- seth 19:09, 25. Jan. 2009 (CET)- jetzt ist folgende frage: gehts um den schmalen zwischenraum, oder um abstand statt punktschreibweise? - ich würde folgendes prognostizieren:
- umstellung verbindlich abstand statt punkt als meinungbild würde vier tage alt, bevor es wegen 200 ablehnungen wegen „überregulierung“ (mit mutmasslich weniger charmanter formulierung) eingestampft würde
- umstellung verbindlich schmaler abstand statt punkt als meinungbild würde nur 6 stunden alt, und noch dazu auf jahre das anliegen des schmalen leerzeichesn mit diskreditieren
- also würde ich wie auch immer noch dafür plädieren, die beiden fragen auseinander zu halten (erstere ist eine politische, die auch die CH-frage betrifft, zweitere eine rein typographische) --W!B: 12:53, 28. Jan. 2009 (CET)
- jetzt ist folgende frage: gehts um den schmalen zwischenraum, oder um abstand statt punktschreibweise? - ich würde folgendes prognostizieren:
insgesamt hielte ich es immer noch sinniger, vorerst ein JSkript für die privatskin zu schreiben, das die zeichenfolge [##]#.### durch nbsp/thinsp ersetzt (bevor wir quelltextänderungen ins visier nehmen), um zu testen, wie gut das funktioniert (bei der Kategorie:Vorlage:Zahlenformatierung hat sich ja einiges dahingehend getan, seitens der CHer) - ich würde mich auch anbieten, das skript mitzutesten, insbesondere in hinsicht auf den Firefox, der ja ein skript nach 3 sekunden stoppt: es dürfte also etliche listenartikel geben, die sich so nicht konvertieren lassen --W!B: 13:03, 28. Jan. 2009 (CET)
- Puh, wehe bei all den Artikeln, wo irgendwer per Copy&Paste einen Wert mit drei Nachkommastellen und Dezimalpunkt (statt Komma) angegeben hat. Wie wäre es, wenn wir den Unterstrich ("_") als Code für ein geschütztes, kurzes Leerzeichen verwenden? Ich sehe gerade nicht, wo der Unterstrich bereits jetzt eine andere, sinnvolle Anwendung hat. Ein doppelter Unterstrich ("__") könnte das normale geschützte Leerzeichen codieren und ist für Laien viel einfacher zu verstehen als der übliche nbsp-HTML-Code. Wenn mit Absicht Unterstriche angezeigt werden sollen, dann würde man ein herkömmliches Leerzeichen als Escape-Code voranstellen (" _") oder anfügen ("_ "). Ein Sonderfall fällt mir noch ein: innerhalb von Weblinks darf ein Unterstrich nicht als geschütztes Leerzeichen interpretiert werden. --Birger 01:36, 12. Feb. 2009 (CET)
- Ich bin auch großer Fan dieses Unterstrich-Vorschlags, leider wurde der bisher nicht sonderlich positiv aufgenommen. --Ff-Sepp 08:58, 12. Feb. 2009 (CET)
- @Birger: Hier wird der normale Unterstrich zum Beispiel verwendet: [[Open_Source|Open Source]]. Es gibt immer noch viele Newbies, die so verlinken … Oder in URLs. Debianux 10:00, 12. Feb. 2009 (CET)
- Das ließe sich beheben, indem die eckigen Klammern unverändert gelassen werden, ebenso Quelltextschnipsel. Die Anzahl anderweitig allein stehender Unterstriche ohne Leerzeichen vor oder hinter demselben dürfte klar gegen null tendieren, in den seltenen verbleibenden Fällen könnte man dann die nowiki-Tags nutzen. Vorteil dieser Regelung ist auch, dass nicht-registrierte Benutzer wegen der IE-Problematik immer ein nbsp angezeigt bekommen, registrierte, die Wert auf korrekte Typographie legen und einen modernen Browser verwenden hingegen optional das korrekte Leerzeichen einschalten können. Wenn der IE6 dann in ein paar Jahren nur noch einen Marktanteil von einem Prozent hat, könnte dann vollständig und ohne Arbeit auf das richtige Leerzeichen umgestellt werden. --Ff-Sepp 10:14, 12. Feb. 2009 (CET)
- Das wäre natürlich super! In ein paar Jahren gibt es sowieso nur noch Free/Libre Open Source Software. :) Debianux 10:40, 12. Feb. 2009 (CET)
- Das ließe sich beheben, indem die eckigen Klammern unverändert gelassen werden, ebenso Quelltextschnipsel. Die Anzahl anderweitig allein stehender Unterstriche ohne Leerzeichen vor oder hinter demselben dürfte klar gegen null tendieren, in den seltenen verbleibenden Fällen könnte man dann die nowiki-Tags nutzen. Vorteil dieser Regelung ist auch, dass nicht-registrierte Benutzer wegen der IE-Problematik immer ein nbsp angezeigt bekommen, registrierte, die Wert auf korrekte Typographie legen und einen modernen Browser verwenden hingegen optional das korrekte Leerzeichen einschalten können. Wenn der IE6 dann in ein paar Jahren nur noch einen Marktanteil von einem Prozent hat, könnte dann vollständig und ohne Arbeit auf das richtige Leerzeichen umgestellt werden. --Ff-Sepp 10:14, 12. Feb. 2009 (CET)
- Hab nun (patschvornkopp) auch die Diskussion im unmittelbar vorhergehenden Abschnitt "Ganz anderer Vorschlag" gesehen und gelesen. Wenn man den dort angegebenen Links folgt, findet man alle hier geäußerten Gedanken in ähnlicher Form wieder. Siehe also insbesondere Bug 3461 aus dem Jahr 2005. Gar nicht schlecht ist allerdings auch die automatische Ersetzung beim Rendern des Texts laut Bug 13619, die bei vorhandenem Text keine Nacharbeit erforderlich macht. Am besten wäre jedoch vermutlich eine Kombination beider Ideen: Automatische Ersetzung beim Rendern von Standardsituationen, zusätzliche geschützte Leerzeichen werden per Unterstrich definiert. --Birger 01:39, 14. Feb. 2009 (CET)
Browsertabellen
BearbeitenMan sollte diese beiden Tabellen
http://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Typographie_%28Zwischenr%C3%A4ume%29#Browser-Unterst.C3.BCtzung
http://de.wikipedia.org/wiki/Benutzer:Raphael_Frey/Labor#Browser-Unterst.C3.BCtzung
z. B. per Vorlage synchronisieren. --Itu 22:28, 17. Feb. 2010 (CET)