Hilfe Diskussion:Tabellen

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Diese Diskussionsseite dient dazu, Verbesserungen an der Hilfeseite „Tabellen“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.
Archiv
Wie wird ein Archiv angelegt?

Tabellen-Abschnitte Einklappen/Ausklappen[Quelltext bearbeiten]

Ist es möglich, Tabellen-Abschnitte ein- bzw. ausklappbar zu machen, falls ein Abschnitt etwas lang ist und die oberen relevanter für den Leser sind? --GamerAndWriter (Diskussion) 19:01, 6. Nov. 2023 (CET)[Beantworten]

data-sort-type="date"[Quelltext bearbeiten]

Hallo,

mein Problem hängt wohl damit zusammen, dass ich österreichisches statt "normales" Deutsch als Standardsprache eingestellt habe. Jedenfalls stelle ich fest, dass ich beispielsweise in der Liste der Autonomen Republiken Russlands bei Sortierung nach Gründungsdatum die im Januar 1930 gegründete Republik Mordwinien als letztgegründete gelistet bekomme. Im Vorschaumodus wird sie mir aber richtig einsortiert, wenn ich mir den Spaß erlaube, den Januar zu einem Jänner zu korrigieren. Mit "?uselang=de-DE" hinten in der URL wird auch richtig sortiert.

Kann man das irgendwo softwareseitig implementieren, dass auch bei de-AT Januar als Monat erkannt wird? Wo darf man solche Probleme melden? … «« Man77 »» Alle Angaben ohne Gewehr. 23:45, 8. Jan. 2024 (CET)[Beantworten]

Hast du mal versucht folgendes |data-sort-value="10. 01. 1930"| vor das Datum zu setzen, passiert es dann auch noch? --Liebe Grüße, Lómelinde Diskussion 09:33, 9. Jan. 2024 (CET)[Beantworten]
Hi Lómelinde. Ja, damit wäre es richtig sortiert. Danke für die Nachfrage/Idee.
Aus Interesse: Ich nehme an, dass bei dir die Liste der österreichischen Landeshauptleute#Burgenland falsch sortiert wird, weil bei dir der Jänner nicht als Monat erkannt wird?
Es ist zwar schön, dass es einen funktionierenden Workaround gibt, aber bei einem häufigen Anwendungsfall wie Jänner/Januar erhoff ich mir eine generelle Problembeseitigung. Und die muss, wie mir scheint, über die Frage des de-DE vs. de-AT noch ein gutes Stück hinausgehen. … «« Man77 »» Alle Angaben ohne Gewehr. 10:54, 9. Jan. 2024 (CET)[Beantworten]
Ja das stimmt, wird dann merkwürdig sortiert. Da kann ich dir aber auch nicht wirklich helfen, da müsstest du Perfektes Chaos fragen, er weiß, wo das in den Modulen geändert werden müsste, falls das geht. --Liebe Grüße, Lómelinde Diskussion 15:59, 9. Jan. 2024 (CET)[Beantworten]
Danke. Ping @PerfektesChaos:
In meinen Augen ist der grundsätzliche Fehler, dass die Sortierung von den Benutzereinstellungen abhängig gemacht wird. Wenn nach Datum sortiert wird, sollte es egal sein, ob man sich das Menü in österreichischem Deutsch, in Albanisch oder in Tamazight anzeigen lässt, die Projektsprache ist hier Deutsch und (nicht nur, aber insbesondere) im Deutschen ist der 11.01.1930 zwischen dem 4. August 1911 und dem 23. März 1954, und zwar unabhängig davon, ob man den Monat vor dem Februar als Jänner kennt oder als Januar. Es gibt im Deutschen nun mal zwei Bezeichnungen, die in diesem Projekt (teils in einem engeren Rahmen) erlaubt sind. Die Benutzer-Spracheinstellungen sollen keine Auswirkungen darauf haben, ob die Sortierung bei der Liste der Autonomen Republiken Russlands oder bei der Liste der österreichischen Landeshauptleute oder bei keiner von beiden funktioniert.
Ich weiß leider auch nicht, wo das definiert ist oder wie man das reparieren kann, aber ich wünsch mir schon mit gewissem Nachdruck, dass Januar und Jänner (und sofern das mitdefiniert ist die Abkürzungen Jan. und Jän.) im Kontext von data-sort-type="date" als gleichwertig implementiert werden. Wenn es hierfür ein Phabricator-Ticket braucht, bitte um Unterstützung, weil ich ehrlich nicht weiß, in welche Queue etc. das gehören würde. … «« Man77 »» Alle Angaben ohne Gewehr. 17:22, 9. Jan. 2024 (CET)[Beantworten]

Problemschilderung

  • Erster Bericht in über einem Dutzend Jahren.
  • Hätte häufiger auffallen müssen.
  • Möglicherweise frischer Bug.
  • Ggf. nicht in der Sortierung selbst verursacht, sondern Nebenwirkung einer anderweitig geänderten Konfiguration.

Monatsnamen

  • Das MediaWiki-Skript interpretiert gregorianische, auch julianische und anderweitig kompatible Datumsformate in Jahreskalendern.
  • 7 gsrflt 1987 wird mit einer Liste von 12 Monatsnamen oder Abkürzungen davon aus den ersten drei Buchstaben verglichen, bei Kleinschreibung.
  • Die Liste der 12 stammt aus CLDR.
  • Die erkannten Monatsnamen werden auf die Zahlen 1–12 abgebildet.
  • Trennzeichen wie Leerzeichen und Punkte sind zulässig/erforderlich.
  • Das gesamte Datum muss taggenau sein und hier der europäischen Anordnung Tag Monat Jahr entsprechen.
  • Hebräischer Kalender geht vermutlich auch durch, die Jahreszahlen fallen meist etwas höher aus.

Seitensprache

  • Es gilt die Projektsprache; genauer: die Seiteninhaltssprache.
  • Das ist bei uns immer de.
  • Entsprechend der Seiteninhaltssprache wird die Liste der 12 Monatsnamen auf mögliche Inhalte angewendet.
  • Benutzersprache ist natürlich Nonsens.
  • Ich kann eine Seite in französischer Sprache lesen und eine deutsch- oder englischsprachige Umgebung nutzen. Die Monatsnamen sind und bleiben logischerweise französisch.
  • „Jänner“ kann bei uns noch nie funktioniert haben.

Österreichisch

  • Die Idee, in manchen Seiten Österreichisch (Jänner) zu verwenden und in anderen Reichsdeutsch, und in derselben Seite womöglich beides, ist nicht kompatibel mit der Liste der 12 Monatsnamen.
  • Hier die globale Infrastruktur und die automatisierten Prozesse zu verändern wäre ein sehr erheblicher Eingriff.
  • Da wird sich auch niemand bei MediaWiki drauf einlassen.

Lösung: Vorlage:DatumZelle mit einer Reihe von Vorteilen:

  • Es können blanke Jahreszahlen, taggenaue Angaben oder nur Monat mit Jahr frei kombiniert werden.
  • Es können Modifikationen wie vor nach bis seit um ca. ab vorangestellt werden und werden ggf. inhaltlich adäquat interpretiert und berücksichtigt.
  • Es gibt AT=1 für die österreichische Darstellung.
  • Das Eingabeformat ist sehr frei und maximal tolerant.
  • Die Standard-Ausgabe verwendet abgekürzte Monatsnamen und feste Verbindung zwischen Tagesnummer und Monatsnamenkürzel. Das hat folgende Vorteile:
    • Die Ausfüllung des Feldes ist relativ harmonisch, nicht so ungleichmäßig Mai/November.
    • Auf Smartphones (etwa die Hälfte der ANR-Abrufe) sind schmale Spalten willkommen, damit möglichst die gesamte Tabelle oder zumindest der wesentliche Anteil aufs Display passt.
  • Es kann das Datum mit <ref> oder Anmerkungen und Zusätzen frei kombiniert werden. Die MediaWiki-Software fordert genau nur das taggenaue Datum in der Zelle, um die Zeichenkette interpretieren zu können.

VG --PerfektesChaos 22:42, 9. Jan. 2024 (CET)[Beantworten]

Hi. Es sei nachgefragt, um ein Missverständnis auszuschließen: Deine Lösung wäre, jede Tabellenzelle mit so etwas wie einem Datum explizit mit Vorlage:DatumZelle zu befüllen?! … «« Man77 »» Alle Angaben ohne Gewehr. 23:15, 9. Jan. 2024 (CET)[Beantworten]
Yep. Das wird bereits in 11.103 Artikeln für 467.724 Datumsangaben genau so gehandhabt. VG --PerfektesChaos 00:39, 10. Jan. 2024 (CET)[Beantworten]

Linkziele oder Anker in Tabellen[Quelltext bearbeiten]

Ich bin heute zufällig in Hilfe:Tags #id auf die Regel gestossen: „Identifizierer müssen mit einem Buchstaben beginnen und dürfen kein # enthalten.“ Das war mir bisher nicht bekannt, da im umseitigen Abschnitt Hilfe:Tabellen #Linkziele oder Anker in Tabellen nichts davon steht. Dabei fiel mir ein, dass wir im Artikel Proteste gegen Rechtsextremismus in Deutschland und Österreich 2024 in den Tabellen zahlreiche Verlinkungen auf die einzelnen Tage haben, deren Identifikatoren sämtlich mit einer Ziffer statt mit einem Buchstaben beginnen. Bisher sind dadurch, soweit mir bekannt ist, noch keine Probleme aufgetreten; die Links funktionieren einwandfrei. Dennoch frage ich mich, können wir die Identifikatoren der Linkziele so lassen, wie sie sind, oder sollten wir sie vorsichtshalber ändern? Wenn eine Ziffer am Anfang eines Identifikators unschädlich ist, sollte die Regel in Hilfe:Tags #id gelockert werden. Wenn eine Ziffer am Anfang aber tatsächlich nicht zulässig ist, müsste das auch im umseitigen Abschnitt klar gesagt werden; denn auf der Hilfe-Seite zu Tags werden es die wenigsten finden. Es wäre dann dem letzten Absatz des umseitigen Abschnitts der Satz hinzuzufügen: „Das erste Zeichen muss ein Buchstabe sein.“ --BurghardRichter (Diskussion) 19:04, 1. Apr. 2024 (CEST)[Beantworten]

Vorsicht ist die Mutter der Porzellankiste, und wer es weiß, sollte besser keine Sprungziele mit Ziffern beginnen lassen.
  • Wo das trotzdem anders gehandhabt wurde, mag es einstweilen so bleiben, oder wenn es jemand auffällt gelegentlich anderer Bearbeitungen dezent anpassen (Problem: Bestandsnutzungen außerhalb der aktuellen Seite).
Es sind mehrere Probleme vorstellbar:
  • Browser können das als Pixel-Zeilen innerhalb der HTML-Seite statt HTML-Element interpretieren und entsprechend 547 Pixel von oben scrollen.
  • XML duldet es nicht.
  • Es gibt keine Deklaration, die Ziffern zu Beginn einer Sprungadresse ausdrücklich erlaubt. Da ist im HTML-Standard jedoch vieles unklar; etwa ob die Bezeichner einer class= Case-sensitive sind oder ob das unterschiedliche wären (hingegen die id= Groß- und Kleinschreibung beachten, aber vermutlich ASCII-getrimmt werden dürften oder auch nicht).
Es werden vielleicht nicht sofort Probleme beobachtet; das bedeutet jedoch nicht, dass für alle Ewigkeiten Fehlfunktionen ausgeschlossen sind. Wer es weiß, besser vorsorglich Inkompatibilitäten vermeiden, gibt ohnehin schon genug unerklärliches Software-Verhalten.
Wir haben Abschnittsüberschriften, die verlinkt werden können; jedoch nicht ohne Grund generiert die Wiki-Software alternative Sprungziele
h-Überschrift.
Ich selbst hätte im angegebenen Beispiel verankert: id="Datum-2024-04-01"
Es gibt so etliche Geheimnisse der Wiki-Syntax und barrierefreien und robusten und mobiltauglichen und sicheren Quelltexte, dass normale Menschen keine Chance haben, alles zu bedenken.
VG --PerfektesChaos 19:22, 1. Apr. 2024 (CEST)[Beantworten]
Vielen Dank für die ausführliche Antwort! Dass es in der WP Dinge gibt, die unerklärbar erscheinen, damit werden wir wohl leben müssen. Zumindest beruhigt es mich etwas, dass ich wohl nicht der einzige bin, dem manchmal solche seltsamen Dinge auffallen. Ich werde die Sache in dem genannten Artikel mal gelegentlich bereinigen. Dass es Links von aussen auf die Anker gibt, ist unwahrscheinlich (allenfalls vielleicht auf Diskussionsseiten); und wenn, dann wird es auch kein Unglück sein. Dass Abschnittslinks nach Änderung einer Abschnittsüberschrift nicht mehr richtig funktionieren, kommt viel öfter vor.
Bleibt nur noch die Frage: Sollen wir die Regel, dass Linkziele mit einem Buchstaben beginnen müssen, umseitig mit aufnehmen? Ich wäre dafür, allein schon wegen der Konsistenz der Hilfe-Seiten, d.h. damit nicht ein und derselbe Sachverhalt auf zwei verschiedenen Hilfe-Seiten unterschiedlich geregelt ist; das würde Verwirrung erzeugen, so wie es mir passiert ist. Ich möchte es aber nicht ohne dein Einverständnis ändern. Viele Grüsse, --BurghardRichter (Diskussion) 21:58, 1. Apr. 2024 (CEST)[Beantworten]
Nein.
Umseitig soll Tabellensyntax übersichtlich beschreiben, keine id-HTML-XML-Philosophie.
  • Unix-Philosophie: Mache nur eine Sache, und die mache richtig und gut (McIlroy #1 = Gancarz #2).
  • In den letzten 24 Stunden dürftest du eine andere Disk mitgelesen haben, in der jemand auf einer anderen Hilfeseite ebenfalls eine Dublette zu H:Tags explizit ausführen wollte.
  • Dann wird jede Hilfeseite so überladen und unübersichtlich, dass niemand mehr in der Flut von Details noch irgendwas wiederfindet oder die Seite noch anfassen mag.
Umseitig ist bereits an der passenden Stelle H:Tags #id verlinkt, und damit ist für umseitig der Fall erledigt.
VG --PerfektesChaos 00:10, 2. Apr. 2024 (CEST)[Beantworten]