Wikipedia:Umfragen/Konzept für mathematische Formeln

Ziel der Umfrage

Diese Umfrage soll helfen, ein zukunftsfähiges Konzept für mathematische Formeln zu finden. Anlass ist die zunehmende Verwendung des VisualEditors. Mein Wunsch als Initiator der Umfrage ist es, am Ende eine Auswahl an Lösungsvorschlägen zu haben, die man mit anderen Projekten und Sprachversionen diskutieren und den Entwicklern zur Umsetzung vorschlagen kann. Entschuldigung außerdem für die lange Problemerläuterung, ich hoffe es wird dadurch verständlicher.--Debenben (Diskussion) 11:49, 15. Sep. 2017 (CEST)

Diese Umfrage lief vom 15. September 2017 bis zum 15. Oktober 2017. Vielen Dank an alle, die teilgenommen haben.

Probleme

 P1  Für Nutzer des VisualEditors

• Benutzer des VisualEditors können keine Formeln so einrücken, dass sie zu dem Rest des Artikels passen. Für neue Autoren ist dies unverständlich (Beispiel) und möglicherweise frustrierend, wenn bei existierenden Formeln immer die Anzeigeoption „Standard“ ausgewählt ist, sie selber aber mit „Standard“ keine eingerückten Blockformeln erzeugen können.
• Wenn sie die formal korrekten Optionen für die Anzeige auswählen, ist das Layout für die Leser anschließend uneinheitlich.
• Die Bezeichnung „Standard“ im visuellen Formeleditor suggeriert, es würde automatisch das Richtige gewählt oder es könnte in Abhängigkeit von irgendwelchen Einstellungen beides sein.

 P2  Für Autoren

• Die aktuelle „Standard“-Formatierung ist für fast alle Zwecke falsch, denn sie muss jedes Mal, entweder als Blockformel mit einem manuellen Absatz und Doppelpunkteinrückung verwendet werden, oder als Inlineformel mit manueller Anpassung der Formatierung von großen Zeichen.
• Vielen Autoren sind mit den entsprechenden LaTeX-Befehle wie \textstyle weniger vertraut, da sie gewohnt sind, dass die Formatierung automatisch angepasst wird.
• Das manuelle Setzen des Parameters display="inline" würde den Quelltext unübersichtlicher machen.

 P3  Für Nutzer von Text-zu-Sprache-Programmen

• Die Einrückung mit Doppelpunkt ist ein „Missbrauch einer Definitionsliste“.

 P4  Als Ursache für weitere Probleme

• Es gibt für keine Formatierungsart eine zufriedenstellende Möglichkeit im Fließtext auf eine Blockformel zu verweisen.
• Der im VisualEditor angezeigte Parameter "id" wird auch für Inlineformeln angezeigt, obwohl auf diese nicht verwiesen werden kann und hat keinen sichtbaren Effekt.
• Entsprechende Behelfsmöglichkeiten werden nicht vom visuellen Formeleditor unterstützt, sind nicht mit display="block" kompatibel und ermöglichen keine automatische Nummerierung.

Detailliertere Erläuterungen finden sich (ausklappbar) in den nachfolgenden Abschnitten Hintergrund, Statistik und FAQ.

Hintergrund Der Unterschied zwischen Block und Inlineformeln: Es gibt zwei Arten der Formatierung mathematischer Formeln: Im Fließtext eingebettete Formeln, genannt Inlineformeln und abgesetzte Formeln, genannt Blockformeln: Fließtextfließtextfließtext $Inlineformel$ fließtextfließtext $Blockformel$ fließtextfließtextfließtext. In der Literatur ist es üblich, Blockformeln einheitlich zentriert oder eingerückt zu setzen. Außerdem werden Formeln mit großen Zeichen wie $\sum _{n=0}^{\infty }$ als Inlineformeln so dargestellt: $\textstyle \sum _{n=0}^{\infty }$, damit sie in eine Zeile passen und den Textfluss nicht stören. Weiterhin ist es üblich, Blockformeln mit einer Nummer zu versehen um im Fließtext auf sie verweisen zu können. Diese Nummerierung erfolgt üblicherweise einheitlich rechtsbündig oder linksbündig vor einer Blockformel und kann nach Bedarf manuell abgeschaltet werden. In LaTeX würde man zum Beispiel schreiben: Fließtextfließtextfließtext $Inlineformel$ fließtextfließtext \begin{equation} Blockformel \end{equation} fließtextfließtextfließtext. und die passende Formatierung geschieht automatisch. Wie die Formeln aktuell in Wikipedia gesetzt werden: In der deutschsprachigen Wikipedia ist Fließtextfließtextfließtext <math>Inlineformel</math> fließtextfließtext :<math>Blockformel</math> fließtextfließtextfließtext. üblich. Große Zeichen werden nicht automatisch für Inlineformeln angepasst, sondern müssen manuell mit LaTeX-Befehlen wie \textstyle verkleinert werden und die Einrückung von Blockformeln durch einen Doppelpunkt erzeugt werden. Dass es keine zwei unterschiedlichen Befehle für Inlineformeln und Blockformeln gibt hat historische Gründe: Die <math> Umgebung hat zunächst einfach ein Bild erzeugt, dessen Plazierung den Autoren überlassen war. Diese verwenden seitdem in allen großen Projekten und Sprachversionen einen Doppelpunkt, um Blockformeln einzurücken. Das resultierende Bild war nicht dafür gemacht, im Fließtext verwendet zu werden. Mit normalen Zeichen können jedoch viele mathematische Symbole und Ausdrücke nicht im Fließtext dargestellt werden oder die Darstellung ist fehlerhaft und anders als in den Blockformeln. Um das Problem zu lösen gibt es in den Wikipedia-Projekten unterschiedliche Herangehensweisen. In der englischsprachigen Wikipedia gibt es eine große Zahl von Vorlagen wie w:en:Template:Math, deren Verwendung jedoch umstritten ist, siehe w:en:Wikipedia:Rendering math zu Vor- und Nachteilen. In der deutschsprachigen Wikipedia wurde sich darauf geeinigt, diese Vorlagen nicht einzuführen, sondern auch im Fließtext <math> zu verwenden, in der Hoffnung, dass die Darstellung besser wird. Seitdem wird <math> im Fließtext und für Blockformeln gleichermaßen verwendet. Die Probleme und Versuche sie zu lösen: Diese aktuelle Praxis hat zunächst mal zwei Nachteile. Zum Einen muss die die Anpassung der Formatierung von großen Symbolen in Inlineformeln manuell durch den Autor vorgenommen werden. Zum Anderen stellt die Einrückung mit Doppelpunkt ein „Missbrauch einer Definitionsliste“ dar und sollte gemäß Hilfe:Textgestaltung vermieden werden. Die gesamte Entwicklung und Verbesserung von <math> wird vollständig von freiwilligen Entwicklern gestemmt. Diese haben in einem Versuch das Problem zu beheben, vor längerer Zeit in dem Computerprogramm, dass die mathematischen Formeln in das gewünschte Ausgabeformat umwandelt, einen neuen Parameter "display" eingeführt. Diesem Parameter lässt sich direkt im Quelltext der Wert "block" oder "inline" zuweisen, sodass man schreiben kann Fließtextfließtextfließtext <math display="inline">Inlineformel</math> fließtextfließtext <math display="block">Blockformel</math> fließtextfließtextfließtext. was dargestellt wird als Fließtextfließtextfließtext ${\textstyle Inlineformel}$ fließtextfließtext $$Blockformel$$ fließtextfließtextfließtext. Die passende Formatierung von großen Formelzeichen geschieht dann wie bei LaTeX automatisch. Die Initiativen für diesen neuen Parameter eine autorenfreundliche Kurzschreibweise zu finden sind damals mangels Unterstützern gescheitert. Das manuelle Setzen dieser neuen Parameter hat sich in der deutschsprachigen Wikipedia bisher nicht durchgesetzt. Es gibt in der deutschsprachigen Wikipedia nur ungefähr 39 Artikel die display="inline" enthalten und 5 Artikel die display="block" enthalten. Quasi alle Autoren verwenden weiterhin die am Anfang genannte Schreibweise. Für lange Zeit war es kein großes Problem, dass diese Parameter nicht verwendet wurden. Inzwischen gibt es jedoch den VisualEditor, der insbesondere neuen Wikipedia-Autoren das Bearbeiten von Artikeln erleichtern soll und dafür auch mit einem prinzipiell sehr guten visuellen Formeleditor ausgestattet wurde, sodass Autoren die Möglichkeit haben, auch ohne Kenntnisse von LaTeX, mathematische Formeln zu bearbeiten. Der visuelle Formeleditor bietet folgende Optionen: Dies entspricht den Möglichkeit der Formatierung ohne Parameter sowie dem Setzen der Parameter display="inline" und display="block" so wie in obigem Beispiel. Nicht unterstützt wird, eine Formel mit der aktuell üblichen Formatierung mit Doppelpunkt einzurücken. Nachteil der so eingeführten Schreibweise dieser neuen Parameter ist, dass der Quelltext für den Autor länger ist und desshalb, wenn jedes Formelzeichen im Fließtext als <math display="inline">Formelzeichen</math> geschrieben wird, sehr schnell unübersichtlich wird. Artikel, die mathematische Zeichen konsequent mit LaTeX formatieren können viele Inlineformeln innerhalb eines Satzes enthalten, z.B. bei Satz des Pythagoras drei Sätze mit jeweils sieben Inlineformeln. Die Zentrierung von Blockformeln ist die Standardeinstellung bei LaTeX, würde aktuell bei Wikipedia jedoch bewirken, dass die Formatierung nicht mehr einheitlich ist. Um auch Formeln, die mit display="block" Parameter gesetzt werden, eingerückt darzustellen, wurde in der englischsprachigen Wikipedia folgender Eintrag in w:en:MediaWiki:Common.css vorgenommen: .mwe-math-fallback-image-display, .mwe-math-mathml-display { margin-left: 1.6em !important; margin-top: 0.6em; margin-bottom: 0.6em; } Dies bewirkt, dass Formeln mit display="block" Parameter so wie die Formeln mit vorangestelltem Doppelpunkt aussehen. In Fällen, wo Blockformeln zum Beispiel in einer Aufzählung verwendet werden und eine größere Einrückung erforderlich ist, kann oder muss diese weiterhin mit einem Doppelpunkt erfolgen. Wie man auf Blockformeln verweisen kann: Um im Fließtext eindeutig auf Blockformeln verweisen zu können, werden Blockformeln üblicherweise durchnummeriert. Das funktioniert in LaTeX so, dass man ihnen mit \label{NameDerFormel} einen Namen zuweisen kann und im Fließtext mit \ref{NameDerFormel} einen Verweis mit der entsprechenden Nummer bekommt. In Wikipedia gibt es diese Möglichkeit bisher nicht. Meistens wird beispielsweise pauschal auf „die obige Definition“ verwiesen, in der Hoffnung, dass der Leser weiß welche gemeint ist. Manchmal werden sie manuell mit (*) oder (1) am Ende gekennzeichnet, teilweise werden Vorlagen wie Vorlage:NumBlk verwendet. Eine Möglichkeit aktuell bei Wikipedia ein Verhalten zu generieren, dass den in der Literatur üblichen Konventionen ähnelt wäre, mit <math id="NameDerFormel"> einer Formel einen Namen zu geben und dann im Fließtext darauf zu verweisen: Fließtextfließtextfließtext {{NumBlk|:|<math id="MeineBlockformel">Blockformel</math>|1}} fließtext [[#MeineBlockformel|(1)]] fließtext. was dargestellt wird als Fließtextfließtextfließtext $Blockformel$     (1)   fließtext (1) fließtext. Diese Art der Nummerierung ist vergleichsweise unkonventionell, uneinheitlich, umständlich und unflexibel, weil sie keine automatische Nummerierung beinhaltet. Es gibt auch keine Möglichkeit sicherzustellen, dass kein Name zweimal vergeben wird und nur Blockformeln einen solchen bekommen. Die Verlinkung mit Hilfe des Parameters "id" funktioniert nicht nur bei mathematischen Formeln sondern auch bei anderen Objekten. Das besondere ist, dass sich bei <math> diese "id" auch mit dem LaTeX-Befehl \label setzen lässt. Diese Funktion wurde eingebaut in der Hoffnung, dass für mathematische Formeln in Zukunft ähnliche Verweise wie bei LaTeX bzw. <ref> möglich sind. Eine solche Möglichkeit ist bisher jedoch nicht programmiert, weil die Umsetzung einerseits technisch anspruchsvoll ist und andererseits darauf angewiesen ist, dass es eine einfache Möglichkeit gibt, ohne Gefahr von Verwechselung eine Blockformel von einer Inlineformel zu unterscheiden, wie sie mit dem Parameter display="block" gegeben wäre. Obwohl die Funktionalität in dem gewünschten Umfang nicht vorhanden ist, wird bei der Bearbeitung von Formeln ein Eingabefeld "id" im VisualEditor angezeigt, sowohl bei Inlineformeln, als auch bei Blockformeln. Statistik Formatierung Anzahl der Formeln in Hauptnamensräumen Anzahl der betroffenen Artikel Anzahl Seiten in allen Namensräumen <math> 237.779 19.995 37.099 <math> am Zeilenanfang mit ≥ 1 Doppelpunkten 65.577 <math> am Anfang eines neuen Paragraphen ohne Doppelpunkt 5.123 <math> in eigenem Paragraphen mit ≥ 1 nachfolgenden Zeichen 55.435 <math> in eigenem Paragraphen mit < 1 nachfolgenden Zeichen / davon Inlineformeln (Schätzung) 15.265 / 2.712 display="block" / "inline" 4 / 40 30 / 59 <chem> 1 1 200 <ce> ca. 20 5 22 Hier fehlt eine Grafik, die leider im Moment aus technischen Gründen nicht angezeigt werden kann. Wir arbeiten daran! Hier fehlt eine Grafik, die leider im Moment aus technischen Gründen nicht angezeigt werden kann. Wir arbeiten daran! Stand: 9.9.17 / Alle Angaben ohne Gewähr / Die Anzahl der Vorkommen wurden mit diesem Script aus den XML-Dumps ermittelt / Die Schätzung basiert auf dieser Hochrechnung Häufig gestellte Fragen Ich kenne mich nicht mit math bzw. LaTeX aus, warum soll ich mich beteiligen? Du bist genau die Zielgruppe des visuellen Formeleditors, die das Problem aktuell am meisten betrifft. Gerade für diejenigen, die normalerweise keine Formeln bearbeiten oder neu bei Wikipedia sind, wäre es wünschenswert, dass die Layoutoptionen des visuellen Formeleditors verständlich sind und sie sich nicht um besondere Anpassungen wie \textstyle kümmern müssen. Ich verwende den VisualEditor nicht, warum soll ich mich beteiligen? Dann gehörst Du wahrscheinlich zu denjenigen, die sich am meisten darüber ärgern würden, wenn die Lesbarkeit des Quelltextes durch konsequente Verwendung von <math display="inline"> </math> verschlechtert wird. Was ist mit <chem>? Die neue Erweiterung <chem>, bzw. (veraltet) <ce>, die <math> für die Formatierung chemischer Formeln ablösen soll hat noch einige Fehler und wird daher noch nicht verwendet. Die Probleme sind identisch zu <math>, sodass die gleiche Lösung gewählt werden kann.

Lösungsmöglichkeiten

Die Lösungsmöglichkeiten sind nicht vollständig. Manche sind kombinierbar, andere schließen sich gegenseitig aus oder sind als vorübergehende Lösungen denkbar. Wenn Dir wichtige Argumente fehlen oder Du einen besseren Lösungsvorschlag hast, dann ergänze sie bitte!

Die Lösungsmöglichkeiten mit den besten Pro/Contra Stimmverhältnissen sollen weiterverfolgt werden.

 L1  Die Formatierung von Blockformeln mit dem VisualEditor soll nicht möglich sein (Status Quo)

Die aktuell übliche Formatierung mit Doppelpunkt soll beibehalten werden. Da Autoren mit dem VisualEditor nicht die Möglichkeit haben ihre Artikel so zu formatieren wie es aktuell üblich ist bzw. wie sie es wünschen, wird ihnen empfohlen den Quelltexteditor zu benutzen.

Contra-Argumente

• Das letzte Meinungsbild zum VisualEditor hat ergeben, dass die Bearbeitungsmöglichkeit mit dem VisualEditor gewünscht wird.
• Die Probleme der aktuellen Syntax bleiben bestehen.

 L2  Der VisualEditor soll Blockformeln mit Doppelpunkt einrücken

Die aktuell übliche Formatierung mit Doppelpunkt soll beibehalten werden. Damit Autoren die Möglichkeit haben auch den VisualEditor zu benutzen, soll der VisualEditor diese Möglichkeit anbieten.

Pro-Argumente

• Der VisualEditor lässt sich zur Formatierung von Formeln verwenden.
• Keine Umstellung der aktuellen Syntax erforderlich.

Contra-Argumente

• Die anderen Probleme der aktuellen Syntax bleiben bestehen.

 L3  MediaWiki:Common.css soll angepasst werden

Mit Hilfe der MediaWiki:Common.css soll die Formatierung von Formeln die display="block" verwenden in der deutschsprachigen Wikipedia so angepasst werden, dass sie für den Leser genau so wie die Formatierung mit Doppelpunkt aussieht.

Pro-Argumente

• Der VisualEditor lässt sich zur Formatierung von Formeln verwenden.
• Keine Umstellung der aktuellen Syntax erforderlich.
• Lässt sich einfach (z.B. vorübergehend) implementieren und einfach wieder ändern.

Contra-Argumente

• Die anderen Probleme der aktuellen Syntax bleiben bestehen.

 L4  <math> ohne Parameter sollen Inlineformeln sein

Diese Möglichkeit erfordert eine Umstellung des Verhaltens von <math>, womit gleichzeitig die problematische „Standard“-Formatierung abgeschafft wird. Die aktuell übliche Formatierung ohne Parameter wird für die Formatierung der häufigeren Inlineformeln verwendet. In besonderen Fällen, in denen in einer Inlineformel die Formatierung großer Symbole wie in Blockformeln gewünscht ist, muss dies explizit mit \displaystyle geschehen. Damit die aktuellen Blockformeln nicht mit den kleineren Symbolen formatiert werden, muss bei diesen der Parameter display="block" ergänzt werden, wobei damit der Doppelpunkt entfernt werden kann.

Pro-Argumente

• Die Probleme der aktuellen Syntax lassen sich lösen.
• Keine Umstellung für Inlineformeln nötig.
• Aktuell aus Nachlässigkeit ohne \textstyle formatierte Inlineformeln werden besser formatiert.

Contra-Argumente

• Erfordert eine Syntaxumstellung für alle Blockformeln.
• Wenn die Formatierung nicht manuell kontrolliert wird, können absichtlich ohne \textstyle formatierte Formeln schlechter formatiert werden.

 L5  Es soll eine kürzere Syntax für Inlineformeln eingeführt werden

Für Inlineformeln sollen in einer neuen Umgebung geschrieben werden, die eine kürzere Syntax verwendet. Zum Beispiel <$> inspiriert von dem Befehl $ in LaTeX oder eine andere Schreibweise, die nicht länger als <math> ist.

Pro-Argumente

• Die Probleme für Inlineformeln lassen sich lösen.
• Die Lesbarkeit des Quelltextes wird keinesfalls schlechter.
• <math> braucht sein Verhalten nicht zu ändern.
• Bei der Umstellung ist klar, welche Artikel bereits die neue Syntax verwenden.

Contra-Argumente

• Erfordert eine Syntaxumstellung für alle Inlineformeln.
• Für Lösung der Probleme für Blockformeln müssen zusätzlich alle Blockformeln angepasst werden.

 L6  Das Layout von Blockformeln soll durch lokale Vorlagen umgesetzt werden

Die <math>-tags würden bei Blockformeln innerhalb einer Vorlage wie Vorlage:NumBlk geschrieben, welche die Formatierung mit Doppelpunkt ablösen soll.

Pro-Argumente

• Die Formatierung ist lokal einfach änderbar.
• Der Funktionsumfang der lokalen Vorlage lässt sich einfacher erweitern und verbessern.

Contra-Argumente

• Erfordert eine Syntaxumstellung für alle Blockformeln.
• Trotz der Vorlage wären noch <math>-tags mit entsprechenden Parametern erforderlich.

 L7  Alle Formeln sollen lokale Vorlagen verwenden

Es werden neue Vorlagen, wie in der englischsprachigen Wikipedia die Vorlage w:en:Template:Tmath eingeführt, welche die <math>-tags komplett ersetzen.

Pro-Argumente

• Die Formatierung ist lokal einfach änderbar.
• Der Funktionsumfang der lokalen Vorlage lässt sich einfacher erweitern und verbessern.

Contra-Argumente

• Innerhalb der Vorlage kann keine normale LaTeX-Syntax benutzt werden, sondern es müssen für Zeichen wie {{ = | besondere Vorlagen verwendet werden, die derzeit vom Visuellen Formeleditor und externen LaTeX-Editoren nicht unterstützt werden.
• Erfordert eine Syntaxumstellung für alle Formeln.

Abstimmung

 L1  Die Formatierung von Blockformeln mit dem VisualEditor soll nicht möglich sein (Status Quo)

•  Kontra Der VisualEditor erleichtert erfahrenen und unerfahrenen Autoren die Bearbeitung von Artikeln enorm. So gut wie alle üblicherweise verwendeten Funktionen und Syntaxelemente sind inzwischen benutzbar, das sollte auch für Formeln gelten. --CorrectHorseBatteryStaple (Diskussion) 00:42, 15. Sep. 2017 (CEST)
•  Kontra Zustimmung zu meinem Vorredner (auch in den meisten anderen Punkten) –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Kontra Der VisualEditor ist für neue Autoren in der Tat essentiell, es sollte ein andere, technische Lösung gefunden werden. --Minihaa (Diskussion) 19:13, 15. Sep. 2017 (CEST)
•  Kontra Der VE ist da und wird benutzt, ignorieren hilft niemandem weiter. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Kontra, obviously, selbst als VE-Hasser. Btw klingt die Formulierung der Frage irgendwie nach einem Dagegen-stimmen-um-dafür-zu-sein-Bürgerentscheid :-) --nenntmichruhigip (Diskussion) 21:00, 17. Sep. 2017 (CEST)
•  Kontra--Lena1 (Diskussion) 12:06, 18. Sep. 2017 (CEST)
•  Kontra --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:54, 23. Sep. 2017 (CEST)
•  Kontra Der VisualEditor soll beide Formatierungsmöglichkeiten beherrschen. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Pro --Boehm (Diskussion) 10:16, 5. Okt. 2017 (CEST) Wer im Latex-Stil eine Formel bearbeitet, und das ist zweifelsohne die beste Methode für komplizierte Formeln, der braucht keinen VisualEditor. Da ist es dann Wurst, ob man die Formeln mit dem VisualEditor einrücken kann. Der VisualEditor ist praktisch für kleine Änderungen und für Anfänger, aber um Formeln zu editieren dann doch ungeeignet, denn man muss sich mit Latex auseinandersetzen.
•  Kontra --Coffins (Diskussion) 21:35, 15. Okt. 2017 (CEST)

 L2  Der VisualEditor soll Blockformeln mit Doppelpunkt einrücken

•  Kontra Das wäre eine Zweckentfremdung des HTML-Elements. Macht auch die Anpassung des Layouts unflexibler (?? Lässt sich der Effekt der Einrückung per Doppelpunkt mit CSS aufheben?). --CorrectHorseBatteryStaple (Diskussion) 00:46, 15. Sep. 2017 (CEST)
  • (hier mal mit Aufzählungsliste als Diskussionseinrückung :-D) Natürlich kann man auch Beschreibungslisten (aka Definitionslisten) per CSS anders aussehen lassen, beispielsweise wie eine Tabelle. Beispielcode, der einfach nur die Einrückung entfernt: dd{margin:0!important;} --nenntmichruhigip (Diskussion) 20:58, 17. Sep. 2017 (CEST)
•  Kontra –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Kontra Das entstehende <dd> ohne <dt> wäre ein HTML5-Syntaxfehler. --PerfektesChaos 13:30, 15. Sep. 2017 (CEST)
•  Kontra Das wäre der Barrierefreiheit durch Screenreader nicht dienlich. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Kontra --nenntmichruhigip (Diskussion) 20:58, 17. Sep. 2017 (CEST)
•  Kontra Wäre semantisch falsch. --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:55, 23. Sep. 2017 (CEST)
•  Kontra Klingt nach »Taggen für den Renderer«. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Neutral --Boehm (Diskussion) 10:19, 5. Okt. 2017 (CEST) Löst das Problem nicht, ist aber pragmatisch.
•  Kontra --Coffins (Diskussion) 21:35, 15. Okt. 2017 (CEST)

 L3  MediaWiki:Common.css soll angepasst werden

•  Pro Gute Zwischenlösung bis sich eine einheitliche Lösung etabliert hat. --CorrectHorseBatteryStaple (Diskussion) 00:54, 15. Sep. 2017 (CEST)
•  Pro –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Neutral Angewöhnung und Entwöhnung und Geräte-Browser-MW-Tücken führen eher zu mehr Verwirrung, als dass eine Zwischenlösung viel hilft. Lieber in einem Akt gleich richtig. --PerfektesChaos 15:26, 15. Sep. 2017 (CEST)
•  Pro Das scheint mir – neben der Abschaffung des VEs – die einzige wirkliche Lösung zu sein. --DaB. (Diskussion)
•  Neutral Mir fehlt das technische Hintergrundwissen um diese Option bewerten zu können. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Pro --Stefan »Στέφανος« ⸘…‽ 21:56, 19. Sep. 2017 (CEST)
•  Pro --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Pro --Jojhnjoy (Diskussion) (Aktivität) (Schwerpunkte) 12:40, 23. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:56, 23. Sep. 2017 (CEST)
•  Kontra Diese Option gaukelt eine Pseudolösung vor. Lieber eine klare Definition von Inline- und Blockformeln etablieren. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Pro -- -- Leif Czerny 11:37, 2. Okt. 2017 (CEST)
•  Neutral --Boehm (Diskussion) 10:23, 5. Okt. 2017 (CEST) Pseudolösung
•  Pro --Coffins (Diskussion) 21:32, 15. Okt. 2017 (CEST)

 L4  <math> ohne Parameter sollen Inlineformeln sein

•  Neutral Besser fände ich die explizite Angabe bei jeder Formel. Wer das Verhalten der math-Umgebung nicht kennt, weiß sonst nicht, was passiert. Falls ein default-Wert gesetzt werden soll, am besten für Inline-Formeln, da es davon am meisten gibt und dort mehr code eher störend wirken kann. --CorrectHorseBatteryStaple (Diskussion) 00:54, 15. Sep. 2017 (CEST)
•  Neutral –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Pro Übersichticherer Fließtext, wenn einzelne Variablen erwähnt werden; Blöcke können länger sein, sind herausgehoben und haben meist längeren Inhalt. --PerfektesChaos 13:32, 15. Sep. 2017 (CEST)
•  Pro Eine explizite Angabe wäre syntaktisch logischer, ein Verhalten wie ganz normaler Fließtext als Standard würde ich aber als neuer Autor erwarten und macht den Quelltext auch lesbarer. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Pro Einerseits wäre dass nicht ganz korrekt, da viele Formeln eben als freistehende Formel (Block) verwendet werden und eine implizite Behandlung als Inline semantisch falsch wäre, andererseits trägt es massiv zur Quellcodeübersichtlichkeit bei wenn gerade Inline-Formeln (die oft auch simplest sind) keine Extraauszeichnung benötigen. --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:59, 23. Sep. 2017 (CEST)
•  Pro Lieber die zahlenmäßig geringeren Blockformeln explizit als Block definieren, als an den massenhaften Inlineformeln zu drehen. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Kontra Ich würde es für unpraktisch halten, wenn alle (zahlenmäßig nicht so geringen) Blockformeln geändert werden müssten. -- UKoch (Diskussion) 21:01, 1. Okt. 2017 (CEST)
•  Pro --Boehm (Diskussion) 10:26, 5. Okt. 2017 (CEST)
•  Kontra Nicht akzeptabel fände ich insbesondere, wenn damit beabsichtigt ist, dass automatisch alle großen Symbole bei inline-Formeln umformatiert werden, wie hier: statt $\sum _{n=0}^{\infty }$ als Inlineformel $\textstyle \sum _{n=0}^{\infty }$. Dies ist m.E. keineswegs der Standard in der mathematischen Literatur und sollte nur bei begründetem Bedarf benutzt und dann eben auch explizit im Quelltext erkennbar sein. Ein (zufällig gewähltes) Beispiel aus Wikipedia ist Lineare_Optimierung_(Spieltheorie) - diese Seite wäre m.E. mit anders formatierten Summenzeichen nicht mehr gut lesbar. Man sieht dort auch, dass sogar Matrizen als Inline-Formeln ohne Sonderformatierung absolut sinnvoll sein können.

Zudem gibt es auf sehr vielen Seiten Inline-Formeln, die einfach nur eine einzelne Variable enthalten - bei diesen tritt keinerlei Problem auf. --Graf Alge (Diskussion) 13:44, 14. Okt. 2017 (CEST)

@Graf Alge: Dass Inlineformeln mit \textstyle formatiert würden wäre ein beabsichtigter Nebeneffekt. Letztlich ist es natürlich eine Frage des Layouts und persönlichen Vorlieben, genauso ob man Blockformeln zentriert oder lieber eingerückt darstellt. Ich finde die großen Summenzeichen im Artikel Lineare_Optimierung_(Spieltheorie) im Fließtext ehr störend. Inlineformeln, die nicht als \textstyle formatiert sind kenne ich eigentlich nur aus Wikipedia. Ich bin die lezten Veröffentlichungen auf ArXiv durchgegangen [1] und kann keine \displaystyle-Formel im Fließtext finden. Eigentlich bin ich davon ausgegangen, dass es Konsens ist, eine Formatierungsmöglichkeit für Inlineformeln und eine für Blockformeln zu haben und Inlineformeln standardmäßig \textstyle sein sollen. Die Möglichkeit manuell \displaystyle, \textstyle, \scriptstyle etc. festzulegen bliebe bestehen und denkbar wäre auch eine Benutzereinstellung oder ähnliches, die alle Inlineformeln standardmäßig mit \displaystyle formatiert. Das würde allerdings nur dann funktionieren, wenn nicht in jeder entsprechenden Inlineformel \textstyle "hardcodiert" ist.--Debenben (Diskussion) 17:50, 14. Okt. 2017 (CEST)

•  Pro in der Hoffnung, dass es für die Ausstattung jeder ganzzeiligen Formel im Artikelbestand mit einem "Block-Parameter" eine mindestens semi-automatische Script-Lösung geben wird. Im Bereich Physik dürfte davon so gut wie jeder Sachartikel betroffen sein.---<)kmk(>- (Diskussion) 18:37, 14. Okt. 2017 (CEST)
•  Pro --Coffins (Diskussion) 21:32, 15. Okt. 2017 (CEST)

 L5  Es soll eine kürzere Syntax für Inlineformeln eingeführt werden

•  Pro Allerdings nicht als vollständigen Ersatz, sondern als zusätzliche Option. Wenn sich das durchsetzt könnten nach und nach die alten Formeln umgestellt werden. --CorrectHorseBatteryStaple (Diskussion) 00:54, 15. Sep. 2017 (CEST)
•  Neutral Verschiedene Syntaxvarianten, die das gleiche Ergebnis haben, bergen immer die Gefahr einer zusätzlichen Verwirrung. –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Kontra Wenn in <math> der Default inline ist, und bislang <math> sowieso per Doppelpunkt usw. in eine Blockformatierung gebracht wurde, dann sind <math> und <$> äquivalent und gleichbedeutende Aliasse für ein seit einem Jahrzehnt eingeführtes Syntaxelement verwirren mehr, als dass sie irgendwem helfen. Es gibt ja noch <ce>. Allen sonstigen Quelltextlesern ist ein Wort math ein selbsterklärender Tipp zur Entschlüsselung.--PerfektesChaos 15:22, 15. Sep. 2017 (CEST)
•  Kontra Sehe ich keinen Grund für. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Kontra Unnötig. --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:59, 23. Sep. 2017 (CEST)
•  Kontra Stiftet eher Verwirrung, für eine Funktion zwei Möglichkeiten zu haben. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Pro Zusätzliche Ausdruckmöglichkeiten finde ich gut? -- Leif Czerny 11:39, 2. Okt. 2017 (CEST)
•  Pro --Boehm (Diskussion) 10:30, 5. Okt. 2017 (CEST) Mir gefällt die Idee.
•  Neutral Ich würde <$> als zusätzliche Ausdrucksmöglichkeit für (kurze) Inline-Formeln begrüßen, aber nur wenn damit keine automatische Sonderformatierung verbunden ist (s. mein Einwand im vorigen Abschnitt L4).--Graf Alge (Diskussion) 13:51, 14. Okt. 2017 (CEST)
•  Pro Der langfristig größte Nachteil von  L4  ist die zusätzliche Tipparbeit und Unübersichtlichkeit des Quelltexts durch den zusätzlichen Parameter. Das würde neutralisiert werden, wenn es für Formelblöcke eine eigene Umgebung gäbe, die mit möglichst wenig zusätzlichen Zeichen auskommt. Mein Vorschlag: <mathb> Rein technisch sollte so eine neue Syntax leicht umzusetzen sein.---<)kmk(>- (Diskussion) 19:30, 14. Okt. 2017 (CEST)
•  Pro --Coffins (Diskussion) 21:33, 15. Okt. 2017 (CEST)

 L6  Das Layout von Blockformeln soll durch lokale Vorlagen umgesetzt werden

•  Kontra Sehr unübersichtlicher Code. --CorrectHorseBatteryStaple (Diskussion) 00:54, 15. Sep. 2017 (CEST)
•  Kontra –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Neutral Hinsichtlich Rahmen, Hinterlegung, Nummerierungsposition usw. interessante Ausbaumöglichkeiten. Bei einem benannten Parameter hält sich das Gleichheitszeichenproblem in Grenzen, nur Pipe und }} erfordern besonderes Escape. --PerfektesChaos 15:14, 15. Sep. 2017 (CEST)
•  Kontra Blockformeln sollten eine ähnliche Syntax haben wie Inlineformeln, alles andere verwirrt. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Kontra Unnötig umständlich. --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:59, 23. Sep. 2017 (CEST)
•  Kontra Vorlagen bringen unnötige Komplexität ins Spiel, die durch  L4  vermieden werden kann. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Kontra --Boehm (Diskussion) 10:32, 5. Okt. 2017 (CEST) Lieber nicht.
•  Kontra --Coffins (Diskussion) 21:34, 15. Okt. 2017 (CEST)

 L7  Alle Formeln sollen lokale Vorlagen verwenden

•  Kontra Zu großer Aufwand, gibt die vielen bekannte Syntax weitgehend auf. --CorrectHorseBatteryStaple (Diskussion) 00:54, 15. Sep. 2017 (CEST)
•  Kontra –Schnark 10:16, 15. Sep. 2017 (CEST)
•  Kontra Nö. --Nothingserious (Diskussion) 19:46, 16. Sep. 2017 (CEST)
•  Kontra--Lena1 (Diskussion) 12:06, 18. Sep. 2017 (CEST)
•  Kontra Unnötig umständlich. --Mps、かみまみた^Disk. 15:44, 20. Sep. 2017 (CEST)
•  Neutral --Methodios (Diskussion) 21:59, 23. Sep. 2017 (CEST)
•  Kontra Vorlagen bringen unnötige Komplexität ins Spiel, die durch  L4  vermieden werden kann. --Carsten (Diskussion) 18:02, 24. Sep. 2017 (CEST)
•  Kontra Alle Formeln im gesamten Artikelbestand umformatieren erscheint mir als Arbeitsbeschaffungsmaßnahme. -<)kmk(>- (Diskussion) 21:03, 1. Okt. 2017 (CEST)
•  Kontra --Boehm (Diskussion) 10:34, 5. Okt. 2017 (CEST) Lieber nicht.
•  Kontra --Coffins (Diskussion) 21:34, 15. Okt. 2017 (CEST)

Ich lehne die Umfrage ab

• …

Anmerkung

Da ich hier was von chem für math; Inlineformeln oder Blockformeln und Gespräche mit Entwicklern und anderen Projekten und ähnliches lese: sollte das irgendwann irgendwo wirklich auch mal Einfluss auf andere Projekte haben, so denkt bitte auch an Wikisource (wo der VE noch nicht? richtig funktioniert und man solche Themen wohl noch nicht auf dem Schirm haben sollte). Auch dort werden math-Formeln inline und im Block genutzt, wie z.B. unter s:Über das Gravitationsfeld eines Massenpunktes nach der Einsteinschen Theorie. Das muss zukünftig auch weiterhin möglich sein. --Anika (Diskussion) 12:58, 24. Sep. 2017 (CEST)

@Anika Die Probleme und mögliche Lösungen betreffen auch Wikisource, ich habe desshalb hier mal etwas geschrieben. Texte wie der verlinkte, die Lösungsmöglichkeit L6 mit s:Vorlage:MathForm1 oder s:Vorlage:MathForm2 verwenden müssten für die derzeit favorisierte Lösung L4 umgestellt werden. Der VE würde derzeit mit diesen Vorlagen nicht funktionieren, auch dann nicht, wenn man wie Vorschlag L3 die Commons.css für Wikisource anpasst.--Debenben (Diskussion) 14:31, 24. Sep. 2017 (CEST)

Auswertung

Die aktuelle Praxis der Doppelpunkteinrückung  L1  bzw.  L2  wird abgelehnt und soll ersetzt werden. Die Lösungsmöglichkeiten  L6  und  L7  (Verwendung von lokalen Vorlagen) finden keine Zustimmung.

Eine Anpassung der Common.css  L3  wird als mögliche vorübergehende Lösung gesehen. Langfristig wird eine Umstellung der Syntax gemäß  L4  oder  L5  gewünscht.

--Debenben (Diskussion) 19:10, 23. Okt. 2017 (CEST)

Weitere Entwicklung

Es gibt eine erfreuliche Nachricht zu verkünden: Seit heute ist hier eine neue MediaWiki-Version live, welche die png-Bilder für mathematische Formeln aus den svg-Bildern erzeugt. Das bedeutet insbesondere, dass softwareseitig viele Abhängikeiten und Einschränkungen, die für die seperate png-Bilderzeugung mit texvc erforderlich waren, wegfallen. An dieser Stelle einen sehr großen Dank an Physikerwelt, der dies durch sein jahrelanges, freiwilliges Engagement möglich gemacht hat.

Im Moment sind wir dabei eine Kommission aufzustellen phab:T195861 um das weitere Vorgehen zu besprechen. Herzliche Einladung an alle Interressierten (@KaiMartin, Boehm, ...:?) sich zu beteiligen.--Debenben (Diskussion) 17:08, 30. Mai 2018 (CEST)

Das ist eine gute Nachricht. Danke Physikerwelt! Mal schauen, ob sich das Neue in der Praxis bewährt. Ich hoffe es sehr. Funktioniert die SUL Anmeldung auch beim Phabricator? Oder muss man sich da extra anmelden mit einem anderen Account? --Boehm (Diskussion) 20:03, 30. Mai 2018 (CEST)