Abstrakte Wikipedia/Darstellung von Sprachen

Sprach-Objekte

Tracked in Phabricator:
Task T263000

Stand März 2021 stellt Wikifunctions Sprachen dar, indem ihre MediaWiki-Sprachcodes genutzt werden (z.B. "en" für Englisch, "ja" für Japanisch, etc.). Der monolinguale Text, der die englische Bezeichnung "Type" darstellt, sieht beispielsweise wie folgt aus:

{ "type": "Monolingual text", "language": "en", "text": "Type" }

{ "Z1K1": "Z11", "Z11K1": "en", "Z11K2": "Type" }

Hierbei haben sowohl "en" als auch "type" den Typ Z6/String.

Der Vorschlag ist, den Typ für Z11K1/Sprache von Z6/String in einen neuen Typ zu ändern, nämlich Z60/Natürliche Sprache. Z60/Natürliche Sprache hat nur einen Schlüssel, den Z60K1/Sprachcode des Typs Z6/String. Dies würde bedeuten, dass die obige Darstellung in folgendes geändert werden würde:

{ "type": "Monolingual text", "language": "English", "text": "Type" }

{ "Z1K1": "Z11", "Z11K1": "Z1002", "Z11K2": "Type" }

Vorteile von Objekten gegenüber Codes

• Statt uns Sprachcodes merken zu müssen, können wir die gleiche Suche wie für jedes andere Objekt nutzen
• Wenn der Leser die Sprache der Benutzeroberfläche ändert, wird er die Sprachnamen in seiner Sprache sehen und nicht Sprachcode, mit dem er sich möglicherweise nicht auskennt
• Wir können eine generische Validierung des Sprachobjekts nutzen, statt etwas fest zu kodieren, dass sich auf das Sprachsystem von MediaWiki verlässt
• Der letzte Punkt ist besonders relevant, wenn wir über andere Implementierungen nachdenken, die den Wikifunctions-Code unterstützen: Sie müssten Teile des Sprachsystems von MediaWiki reimplementieren, um ein konsistentes Verhalten zu zeigen

Vorteile von Code gegenüber Objekten

• Wir haben bereits eine API, die uns eine Liste von Codes bietet und wir können innerhalb des Wikis die gleiche Quelle nutzen, um zu validieren, dass die Sprachcodes gut sind
• Wir sind mehr an "en" als an "Z1002" gewöhnt
• Die aktuelle Komponente Z12/Multilingualer Text ist sehr schnell. Es ist wahrscheinlich, dass das Neuschreiben der Komponente, um Objekte zu nutzen, insgesamt wesentlich langsamer wäre
• MediaWiki hat bereits eine wirklich gute Unterstützung für Sprachen und Sprachen in unterschiedlichen Namen. Wir können dies nutzen, statt unsere eigene Lösung zu entwickeln, um den Namen in unterschiedlichen Sprachen anzuzeigen

Sprachnamen

Ernsthaft? Wir haben bereits alle Sprachnamen in allen Sprachen in MediaWiki und wir haben auch die Sprachnamen in Wikidata. Jetzt sollen wir sie noch ein drittes Mal haben? Was ist daran cool?

OK, OK, ist es nicht. Diese Namen wiederzuverwenden wäre wirklich schön.

Es gibt aber einen Haken - wenn wir hierfür einmal etwas codieren, das darauf angewiesen ist, Teil einer MediaWiki-Installation zu sein, würden wir im Grunde verlangen, dass jede Auswertungsmaschine diesen Teil von MediaWiki neu erstellt. Oder sie verlässt sich auf CLDR. Beides fühlt sich belastend an.

Ein Weg, um dies zu erreichen, wäre, die Bezeichnungen der Sprachen aus MediaWiki zu generieren, sie dann bei Bedarf im Datenverzeichnis von WikiLambda zu regenerieren und sie dann bei Bedarf neu zu laden.

Ein zusätzlicher Schritt wäre, die Bearbeitung von Bezeichnungen für Sprachobjekte zu sperren und zu verlangen, dass die Änderung der Bezeichnungen den etablierten MediaWiki-Prozess hierfür durchläuft. Ohne sie zu sperren könnten wir Probleme mit einer bidirektionalen Synchronisierung bekommen, die Änderungen von Wikifunctions-Benutzern mit Änderungen aus dem Wiki abgleicht.

BCP-47-Zuordnungen

Wir haben bereits Zuordnungen von BCP 47 zu den MediaWiki-Sprachcodes! Lass uns diese wiederverwenden, statt unsere eigenen zu erfinden.

Ich weiß.

Der Vorschlag ist ähnlich wie der für Sprachnamen: Letztendlich sind es zwei ziemlich einfache Funktionen. Diese können über einen ähnlichen Ansatz wie den oben erklärten aktuell gehalten werden, indem die Zuordnungen aus MediaWiki neu erstellt, hochgeladen und ihre Bearbeitung möglicherweise eingeschränkt wird.

Sprachrückfall

Tracked in Phabricator:
Task T268671

Lass uns das später lösen. Es könnte für die Benutzeroberfläche und für Zielsprachen unterschiedliche Lösungen geben.

Listen von Sprachen

Es gibt bereits einige Sprachlisten. Hier sind ein paar relevante:

1. Sprachen für die Benutzeroberfläche: Die Sprachen, die von der Benutzeroberfläche von MediaWiki unterstützt werden, d.h. die Sprachen, in denen Elemente der Benutzeroberfläche von MediaWiki gerendert werden können (dies unterscheidet sich von den MediaWiki-Inhaltssprachen, siehe das MediaWiki-Handbuch zu Sprachen)
2. Die Liste von Sprachen, in denen es auf Wikidata Lexeme gibt
3. Die MediaWiki-Inhaltssprachen
4. Die Liste von Wikipedia-Sprachversionen
5. Das deutschsprachige Wiktionary hat eine Liste aller 8.163 Sprachcodes, die durch die Vorlagen der Communities 'anerkannt' sind: wikt:de:Wiktionary:Sprachen - In anderen Wiktionaries gibt es möglicherweise eine ähnliche Liste

Eine ähnliche Liste von Sprachlisten ist Léas Liste von Sprachlisten in Wikidata.

Ursprünglich haben wir in Erwägung gezogen, dass wir Benutzeroberflächensprachen haben (in welchen Sprachen ist die Benutzeroberfläche von Wikifunctions verfügbar?), die unabhängig von den Zielsprachen sind (in welchen Sprachen kann die Wikifunctions-Bibliothek zur Generierung natürlicher Sprache Inhalte generieren?), nach Diskussion haben wir jedoch entschieden, dass es für jeden hilfreicher wäre, wenn wir diese beiden Listen aufeinander abstimmen. Es wird vielleicht etwas mehr Aufwand sein, aber letztlich wird es die Situation für jeden verbessern.

Ursprüngliche Liste von Sprachen

Die MediaWiki-Benutzeroberflächensprachen basieren auf den Sprachen, die von der MediaWiki-Benutzeroberfläche unterstützt werden.

MediaWiki identifiziert Sprachen durch die Nutzung von kurzen Zeichenketten, die den Codes der ISO 639 oder BCP 47 ähneln (aber nicht immer mit diesen identisch sind). Die vollständige Liste dieser Codes ist über die LanguageInfo-API verfügbar. Zu dem Zeitpunkt, als dieser Text geschrieben wurde, gab es 858 Sprachen in dieser Liste. Wir werden mit dieser Liste als erster Sprachliste beginnen. Die Quelle der Liste dieser Sprachen ist auf der Diskussionsseite beschrieben.

Die Liste von Sprachen, die wir derzeit in Z12/Multilingualer Text unterstützen und die den Parameter uselang akzeptieren, ist die vollständige Liste der 858 Sprachen.

Beachte, dass dies eine sehr inklusive Sicht darauf ist, was eine Sprache ist: Nur um ein paar Beispiele zu geben: Die Liste enthält "de-formal" und sowohl "uz", "uz-latn", als auch "uz-cyrl", etc.

Zuweisung von ZIDs

Hier ist der Vorschlag für die Zuweisung der ersten Reihe von Sprachen zu ZIDs:

• Wir nutzen als erstes die Liste der offiziellen Arbeitssprachen der UN und weisen diesen die ersten paar ZIDs zu (auf diesen Weg gibt es die Möglichkeit, sich diese Sprachen zu merken, wenn man mit dem System arbeitet). Die Reihenfolge ist alphabetisch und basiert auf dem Code.
  • Z1001/Arabic (ar)
  • Z1002/English (en)
  • Z1003/Spanish (es)
  • Z1004/French (fr)
  • Z1005/Russian (ru)
  • Z1006/Chinese (zh)
• Darüber hinaus beginnen wir mit Z1011 und gehen bis Z1861 und ordnen die anderen 852 Sprachen, die sich in der vollständigen Liste von Benutzeroberflächensprachen befinden, basierend auf der alphabetischen Reihenfolge ihrer Codes zu. Alle weiteren Sprachen werden chronologisch hinzugefügt.

Alternativen: Statt eine alphabetische Reihenfolge zu nutzen, können wir auch einen Hash verwenden oder sie zufällig zuordnen. Die Sortierung nach der Anzahl der L1- oder L2-Sprecher ist aufgrund fehlender verlässlicher Statistiken schwierig.