Wikipedia Diskussion:Lua/Modul/Multilingual

Vorlagenprogrammierung	Diskussionen	Lua			Test	Unterseiten
		Modul	Deutsch	English		Modul:	Dokumentation

Redudanzen reduzieren

Mittlerweile sind viele Sprachen in die CLDR-Extension übernommen: LocalNamesDe. Spricht etwas dagegen, auf Modul:Multilingual/names diese Einträge herauszunehmen? Zusatzfrage: Sind die Keys casesensitiv? ["crh-Cyrl"] hier lokal vs. 'crh-cyrl' in CLDR? — Raymond ^Disk. 11:32, 7. Nov. 2018 (CET)

Es gibt die Seite Modul:Multilingual/cldr mit derzeitigem Stand 2015, die genau den in CLDR vorhandenen Zustand reflektieren soll.

Falls du das in relevanten Abschnitten auf den Stand 2018 bringen möchtest (ich bin zurzeit heillos überlastet), würde uns Wikipedia:Technik/MediaWiki/Sprachen/Synopsis erzählen, wo was zu tun ist. Namentlich: Wo es vielleicht durchaus beabsichtigte Unterschiede in der Schreibweise zwischen uns und CLDR gäbe, die beibehalten werden müssten, wo CLDR unsere Übersetzungen lernen sollte, und wo es inhaltsgleiche Redudanzen gäbe, die jetzt entfernt werden können.

Die Keys sind von unserer Seite case-sensitive in dem Sinn, dass unsere Abfragen auf die Lua-Tabellen im standardisierten Format erfolgen. Aus einem Artikelquelltext heraus ist es egal, weil das Lua-Modul zunächst mal jede Schreibweise in das standardisierte Format bringt, und danach in dieser Syntax die genannten Tabellen abfragt. Für gelegentliche weniger intelligente Exoten-Anwendungen gibt es zuweilen eigentlich nicht erforderliche Nur-Kleinschreibung-Bezeichner.

LG --PerfektesChaos 11:45, 7. Nov. 2018 (CET)

Als ersten Schritt werde ich Modul:Multilingual/names entschlacken um Einträge, die in LocalNamesDe identisch vorhanden sind. Da ich genauso chronisch überlastet bin wie du, werde ich mich um Modul:Multilingual/cldr später kümmern. — Raymond ^Disk. 11:59, 7. Nov. 2018 (CET)

NEIN, bitte genau umgekehrt.

Die Einträge in Modul:Multilingual/names sind teilweise mitnichten redundant.

Du verursachst damit insgesamt Mehrarbeit, insbesondere für mich, und vernichtest den Überblick über die komplexe Materie.

Wenn Modul:Multilingual/cldr abschnittsweise durch geeignete RegExp-Operationen aktualisiert ist, ergibt sich die konsistente Anpassung von Modul:Multilingual/names automatisch und fehlersicher. Wenn du beides in verdrehter Reihenfolge machen würdest, dann macht das erstens die doppelte Arbeit und produziert außerdem vorhersehbare Fehler.

LG --PerfektesChaos 12:20, 7. Nov. 2018 (CET)

Was passiert automatisch? Und wieso muss es überhaupt Modul:Multilingual/cldr geben, wenn doch die offiziellen Übersetzungen aus der CLDR-Extension kommen, Ausnahmen in der LocalNamesDe der CLDR-Extension definiert sind. Das sieht für mich alles hochgradig redundant und schwierig zu pflegen aus. Eigentlich bräuchten wir hier lokal doch höchstens eine einzige Datei für Ausnahmen von der Ausnahme. — Raymond ^Disk. 12:27, 7. Nov. 2018 (CET)

Nachtrag: Wieso hast du überhaupt "en-GB" hier nachtragen müssen? Es steht doch schon viel länger in Modul:Multilingual/cldr drin? Was also ist das führende Modul und wo stehen die Ausnahmen drin? — Raymond ^Disk. 12:32, 7. Nov. 2018 (CET)

Modul:Multilingual/cldr ist nichts anderes als eine durch RegExp-Operationen gewonnene transformierte Kopie von *De.php usw. usw.

Modul:Multilingual/cldr vermerkt, welche Übersetzungen bereits in CLDR angekommen sind.

Modul:Multilingual/names dient nicht nur der Darstellung in unseren Artikeln, sondern weiß durch den automatischen Abgleich auch, wo wir schon Übersetzungen haben, die noch nach „oben“, zu CLDR gemeldet werden müssten, damit sie nach Einpflegen dort in alle Anwendungen verbreitet werden können.

Der Kommunikationskanal MediaWiki→CLDR scheint in manchen Jahren dünn zu sein, aber die Hoffnung ist, dass CLDR mehr und mehr Übersetzungen von uns lernt, damit alle lokalen Definitionen nach der Verteilung von oben wieder immer weiter ausgedünnt werden können.

Aus der Synopsis lässt sich automatisch ablesen, wo wir bereits inhaltsgleich mit CLDR sind, und deshalb die lokalen Definitionen eliminiert werden können.

Zum Nachtrag: Weil die MediaWiki-Software und CLDR keine deutschsprachige Übersetzung von en-GB bzw. en-UK kennen oder zum fraglichen Zeitpunkt kannten. Das sind so die Tücken, weshalb die Synopsis die Arbeitsgrundlage ist. Es gab eine Beschwerde eines Autors aus dem Zitationsbereich, und es wurde tatsächlich nicht deutschsprachig angezeigt, deshalb von mir lokal bis auf Weiteres nachgerüstet.

Zur Hierarchie: Dominierend für die Darstellung im Artikel ist Modul:Multilingual/names und gibt eine für unsere Zwecke geeignete Form vor, wenn der nichts weiß, dann die Antwort von MediaWiki. Es gibt aber viele Fälle, wo in MediaWiki nur die englischsprachige Form steht, oder eine für uns unpassende Schreibweise. Und MediaWiki besteht seinerseits wohl aus CLDR und MW-Anpassungen.

LG --PerfektesChaos 12:47, 7. Nov. 2018 (CET)

Modul:Multilingual/cldr habe ich für "de" und "en" gemäß CLDR 34 aktualisiert. Seit einigen Jahren wird im übrigens jedes neue CLDR-Release zeitnah nach MediaWiki importiert. Wikipedia:Technik/MediaWiki/Sprachen/Synopsis sollte sich jetzt automatisch (nach meinem Edit) aktualisiert haben? D.h. jetzt darf ich Redundanzen aus Modul:Multilingual/names entfernen? — Raymond ^Disk. 14:16, 7. Nov. 2018 (CET)

Zwischenzeitlich noch die LocalNamesDe.php und LocalNamesEn.php aus der CLDR-Extension in Modul:Multilingual/cldr nachgetragen. Wikipedia:Technik/MediaWiki/Sprachen/Synopsis schaut jetzt viel besser aus :-) — Raymond ^Disk. 15:07, 7. Nov. 2018 (CET)

(BK) Fein, danke soweit.

• Wenn du dir jetzt Wikipedia:Technik/MediaWiki/Sprachen/Synopsis anschaust, und nach der letzten Spalte sortierst, dann gibt es genau vier Einträge, die inzwischen redundant sind:

Sprache	Code	Bezeichnung
de	bgn	Westliches Belutschi
de	lrc	Nördliches Luri
de	wbp	Warlpiri
en	lrc	Northern Luri

Wenn du dir die weiteren Ergebnisse nach der letzten Spalte anguckst, dann gibt es folgende relevante Schlagwörter:

• Learn – wir wissen was, aber CLDR noch nicht.
• Upstream – wir wissen was, aber CLDR noch nicht, und empfehlen Übernahme.
  • Wenn es eine aktive Kontaktperson bei CLDR gibt, die dort einpflegen kann, dann wäre dies anzuregen.
• Proposal – Änderungsvorschläge.
  • nds-nl – Richtig: Niederdeutsch (Niederlande) – Falsch: Niedersächsisch – häufiger Irrtum, nds hat nichts mit „Niedersachsen“ zu tun, sondern steht für „Niederdeutsch“
  • en – no – Norwegian (bokmål) – da haben wir möglicherweise noch einen Fehler, denn das gehört zu nb – schaue ich mir noch an
• Unterschiede der Form; Beispiele:
  • Krimtatarisch (Kyrillisch) ./. Krimtatarisch (kyrillische Schrift) – das ist für unsere Artikel zu umständlich, wir möchten die kürzere Form anzeigen.
  • Serbokroatisch ./. Serbo-Kroatisch – wir brauchen das für unsere Artikel aus Konsistenzgründen in einem Wort; es ist auch die Standardschreibweise gemäß Duden.
• Nachzutragen bzw. eliminierungsfähig bei uns: dsb, hsb (waren eigentlich auch nur Merker)
• Heißt in Summe: ganze sechs Einträge in Modul:Multilingual/names könnten gelöscht werden.
  • Ähm – wie viele beabsichtigtest du unter der Überschrift „Redundanzen reduzieren“ zu entfernen?

LG --PerfektesChaos 15:13, 7. Nov. 2018 (CET)

(nach BK) „Zwischenzeitlich noch die LocalNamesDe.php und LocalNamesEn.php aus der CLDR-Extension in Modul:Multilingual/cldr nachgetragen.“

• Das dürfte ein Fehler gewesen sein, denn damit wurde die Information vernichtet, welche Einträge nach „oben“ zu CLDR zu melden sind.

LG --PerfektesChaos 15:13, 7. Nov. 2018 (CET)

Eins vorweg: Und wenn es nur 1 Redundanz wäre, so war die Arbeit nicht vergebens. Mehrfache Datenhaltung macht die Arbeit nicht einfacher und schöner.

Im Detail schaue ich mir die Unterschiede auch noch in den nächsten Tagen an und dann einen Patch für LocalNamesDe.php schreiben. Wir wollen ja, dass alle deutschsprachigen Projekte in- und außerhalb der WMF-Welt etwas davon haben.

Informationen habe ich natürlich keine vernichtet. Was nach CLDR gemeldet werden kann, ist stets aktuell aus der LocalNamesDe.php abzulesen. Die Zahl der Leute, die das tun könnten und wollen, geht gegen 0. Ich weiß nicht, ob du dich schonmal mit dem Prozess bei CLDR beschäftigt hast. Es ist alles sehr langwierig und aufwending. Ich habe seit diesem Jahr einen Account für Deutsch dort und auch eine Änderung vorgeschlagen. Wurde zumindest für das Release 34 nicht angenomen. Vermutlich zu wenige Votes erhalten. Und bei nur 2 Releases pro Jahr muss jemand wirklich viiiiiellll Geduld haben, sich dort zu engagieren. Langfristig sinnvoll, kurzfristig setze ich auf die LocalNamesXx.php. — Raymond ^Disk. 15:35, 7. Nov. 2018 (CET)

Syntaxhervorhebungsfehler

Warum erzeugt

{{#invoke:Multilingual/test|f|_f_=fair|fr|_r_=fr}}

jeweils Fehler? Liegt das an diesem enclose im Modul:UnitTests/invoke? Ich wollte eh schon fragen, ob das nicht auch geändert werden müsste, aber da ich nun von Lua keinen blassen Schimmer habe, weiß ich nicht einmal, wo genau sich das auswirkt. Aber ich hatte die Seite schon fokussiert. Aber ich bekam ja einen „Geduld“-Rüffel. --Liebe Grüße, Lómelinde Diskussion 16:12, 20. Apr. 2020 (CEST)

Das kann gut sein.

Das fragliche Modul ist uralt, wurde wohl noch vor derartiger enclose-Neuerungen programmiert.

Schaue ich mir heute nacht mal an, sind dann gleich noch einige anderen Modernisierungen einzubauen.

LG --PerfektesChaos 17:53, 20. Apr. 2020 (CEST)

Alles klar. Dankeschön. --Liebe Grüße, Lómelinde Diskussion 18:17, 20. Apr. 2020 (CEST)

es-ES (european Spanish)?

• I Premios Ópera XXI. In: Ópera XXI. 8. April 2019, abgerufen am 1. März 2020 (europäisches Spanisch). 

Why does it say (european Spanish)?

• I Premios Ópera XXI. 8. April 2019 (europäisches Spanisch). 

Yo no hablo español, no inglés, hablamos alemán.
Ähm ja falls ich hier überhaupt richtig bin. --Liebe Grüße, Lómelinde Diskussion 16:45, 24. Jul. 2020 (CEST)

Naja, passt schon.

Haben wir noch nicht auf deutsch; bekannt sind pt-BR, en-US und so.

Muss ich halt konfigurieren gehn.

Ist das europäische im Unterschied zum südamerikanischen Spanisch, genauso wie pt-BR.

LG --PerfektesChaos 17:49, 24. Jul. 2020 (CEST)

Ich dachte zuerst es steht dort so ausgeschrieben und wollte den Text ändern. Sah dann aber nur das Kürzel und wunderte mich ein wenig. Als wenn ich einen Unterschied aus pt-BR zu pt heraushören könnte, ich würde mich schon schwertun die Sprache überhaupt herauszuhören. :-) Dankeschön. --Liebe Grüße, Lómelinde Diskussion 18:00, 24. Jul. 2020 (CEST)

Südamerikanisches Spanisch ist leicht zu hören, die te-eitschen nicht. Geschriebene Unterschiede wüsste ich nicht.

Vorlage:esS-ES → Spanien Spanien – LG --PerfektesChaos 18:06, 24. Jul. 2020 (CEST)

E Es Es E Es klingt lustig. Ja Spanisch kann viele Facetten haben, die Dominikaner sprechen es noch anders. --Liebe Grüße, Lómelinde Diskussion 18:26, 24. Jul. 2020 (CEST)

Oh nun passt es ja, prima, Dankeschön und noch einen angenehmen Abend. --Liebe Grüße, Lómelinde Diskussion 19:12, 24. Jul. 2020 (CEST)

hbs – serbokroatisch

Auf Kategorie:Wikipedia:Vorlagenfehler/Parameter:Sprachcode steht hbs in der Tabelle als richtiger Sprachcode, statt dem veralteten sh. hbs wird von Vorlage:Literatur leider noch als ungültig gemeldet, ISO 639-3 wohl nicht kompatibel. Sprachcode hbs sowie Vorlage:hbsS wurden in letzter Zeit vermehrt eingefügt. Kann hbs im Modul ergänzt werden? Pintsknife (Diskussion) 16:28, 7. Dez. 2022 (CET)

Oaaahrrgh, die schon wieder.

Das ist so ein Kuddelmuddel-Sprachcode, der eigentlich auch überhaupt nicht für eine Publikation verwendet werden kann; deshalb meckern die auch.

Kurzfassung: Das war eine Sprache in Ex-Yugoslawien, die es eigentlich gar nicht richtig gibt.

Hinzu kommt, dass sie in zwei verschiedenen Schriften geschrieben wird, nämlich Kyrillisch und Lateinisch, und dass aus diesem Sprachcode nicht hervorgeht, welche.

Eigentlich müsste die Sprache der Publikation mit serbisch (typischerweise Kyrillisch), kroatisch oder bosnisch (typischerweise Lateinisch) explizit angegeben werden.

Müsstest du zur Auflösung Balkan-Experten dransetzen, die das zuordnen können.

Ist mir zu kompliziert, mich da reinzudenken, und ich habe schlicht keine Zeit dafür.

VG --PerfektesChaos 21:11, 7. Dez. 2022 (CET)

Naja, Serbokroatische Sprache gab es schon, deswegen gab es ja eine Zeit lang diesen Sprachcode sh Zumindest für „historische Publikationen“ z.B. aus dem ehemaligen Jugoslawien ist „serbokroatisch“ eine valide Angabe. Aber halt nicht mehr mit dem nicht mehr definiertem Code sh sondern mit dem weitgehend äquivalentem hsb. Von daher wäre das sehr hilfreich, wenn hsb bei {{Literatur}} unterstützt würde. --S.K. (Diskussion) 13:33, 8. Dez. 2022 (CET)

Wie ist der Stand, wird der Sprachcode noch ergänzt. Ich hätte da noch en-ZA für afrikanisches Englisch, ist auch oft eingebunden, aber wird von der Vorlage nicht verarbeitet. Wenn ich mir die Sprachcodes so ansehe, gibt es bestimmt noch einige, die nicht erkannt werden. Vielleicht weil sie nur Nischensprachen sind, ich weiß das nicht genau. Allerdings ist die bloße Anzeige des Sprachcodes statt der richtigen Sprache in der Vorlage unschön und man fragt sich was der Code da bezweckt. Pintsknife (Diskussion) 14:50, 30. Jan. 2023 (CET)

de-Latf wird auch noch nicht richtig erkannt und entsprechend angezeigt. --Pintsknife (Diskussion) 18:25, 24. Jul. 2023 (CEST)

Was soll ich denn mit Latf?

• Das ist „lateinische Frakturschrift“.
• Es gibt keine „deutsche Sprache in Frakturschrift“. Es gibt auch keine „deutsche Sprache in hebräischer Schrift“ und keine „deutsche Sprache in japanischer Schrift“ und keine „deutsche Sprache in kyrillischer Schrift“.
• Es gibt nur de-AT, de-CH, de-DE.
• Es gibt aber kein de-ES als „Deutsch wie es in Spanien gesprochen wird“. Weil eine erfasste und in Wörterbüchern und Grammatiken dargestellte Sprachvariante nicht existiert.

Es wäre erstmal nachzuweisen, dass es eine Sprachvariante „Englisch wie es in Südafrika gesprochen wird“ überhaupt im realen Leben gibt.

• Es gibt meines Wissens nur en-GB, en-US, en-CA und en-AU. Sonst nix.

Jeder Dödel kann formal an jeden Sprachcode einen Schriftcode oder einen Ländercode dranbamseln.

• Daraus wird dann aber noch keine benannte Sprachvariante.
• Ergo kann hier auch kein Name einer Sprachvariante bekannt sein.
• Also muss ein überflüssiges Anhängsel von einem Sprachcode wieder abgebaut werden.
• „Deutsche Sprache in Frakturschrift“ gibt es nicht, nur „Deutsche Sprache“. Also ist de-Latf Nonsens und schlicht de.

Es gibt auch nur pt und pt-BR.

• Jedes pt-US und pt-Cyrl und pt-Latn ist dummes Zeug und solche Anhängsel müssen gelöscht werden.

VG --PerfektesChaos 22:40, 24. Jul. 2023 (CEST)

en-ZA: südafrikanisches Englisch. Wikipedia behauptet, das gibt es. --S.K. (Diskussion) 23:01, 24. Jul. 2023 (CEST)

…und de-Latf auch nach ISO 15924 und Fraktur (Schrift). Vielleicht nicht „Deutsche Sprache in Frakturschrift“, sondern eher „Deutsch in lateinischer Schrift“. Warum sollte es entgegen der belegten Artikel diese Sprachcodes nicht geben. Es wäre nicht verkehrt wenn unsere Vorlagen und Module aktualisiert werden und die Sprachcodes unterstützen, wenn sie eben auch in einer Enzyklopädie verwendet werden. Damit kein Code-Schnipsel im Artikel steht, sondern direkt die gewünschte Sprache. Und nur weil aktuell die Vorlagen und Module damit nicht umgehen können müssen doch nicht gleich diese Sprachcodes wie vorgeschlagen gelöscht werden. Was wäre schwierig an einem Update. Die Artikel und Normen belegen ja bereits dass es sich um richtige Sprachcodes handelt. Ich geh davon aus, dass de-Latf für „Deutsch in lateinischer Schrift“ und en-ZA für „Südafrikanisches Englisch“ deshalb nicht aufgenommen wird, da die Einbindungen möglichst simpel bleiben sollen und deshalb kein weder Dialekt noch Varietät rein sollen. So als Argument, gerne bestätigen, dann hat sich das erledigt. Kann ja jeder nochmal selbst nachfragen, wenn es mal der Fall ist. Genau ist diese vereinfachte Angabe jedoch nicht, wenn der Autor dies extra angeben möchte. Für den normalen Leser, wie mir, sollte es wohl reichen und nicht weiter stören. Jedenfalls erzeugen diese beim Einbau wie bspw. Liste der Regierungsräte des Kantons Nidwalden eine Fehlermeldung und wandeln den Code nicht in eine Sprache um. --Pintsknife (Diskussion) 01:01, 25. Jul. 2023 (CEST)

• Es gibt kein „Deutsch in Schreibschrift“ und kein „Deutsch in Großbuchstaben“ und kein „Deutsch in Frakturschrift“ und kein „Deutsch in Sütterlin“.
  • Es gibt auch kein „Deutsch wie es in Uruguay gesprochen wird“.
  • Es gibt maximal Deutsch in den Varianten Österreich, Schweiz, Deutschland.
  • Alles andere ist Unsinn.
  • „Deutsch in lateinischer Schrift“ ist genauso sinnfrei, weil die lateinische Schrift die einzige ist, in der standardmäßig die deutsche Sprache notiert wird. Angaben zu spezifischen Schriften gibt es nur, wenn aus historischen Gründen eine Sprache üblicherweise in mehreren Schriften gleichberechtigt notiert wird; typischerweise Kyrillisch, Arabisch und Lateinisch in den Randgebieten der ehemaligen Sowjetunion.
• Es gibt fast 8000 Sprachcodes und als Anhängsel rund 300 Staats- und Schriftkürzel.
  • Damit lassen sich formal-theoretisch 2,5 Millionen angeblicher Sprachnamen mit einem Anhängsel bilden.
  • Es gibt aber diese fiktiven angeblichen „Sprachen“ überhaupt nicht.
  • In der deWP kommen fast 1000 vor, und Ende.
  • Viele der 8000 Sprachen kennen nur wenige 1000 Menschen, haben keine Schrift und demzufolge keine Bücher und wir haben da auch nichts zitierfähig, und diese Menschen sind sogar schon ausgestorben und da werden auch nie mehr Texte geschrieben und es gibt auch keine deutsche Bezeichnung für solche Sprachen.
  • Jedem, der da als Autor nicht-existente „Sprachen“ zusammenwurschtelt oder von irgendeinem Webserver unreflektiert übernimmt, müssen diese Anhängsel wieder abgeschnitten werden, statt dass wir anfangen nicht-existente „Sprachen“ zu erfinden wie „Deutsch in Frakturschrift“.
  • Nein, wir werden uns nicht 2,5 Millionen sinnfreie Sprachnamen ausdenken, um jeden Schwachsinn darzustellen.
• Für en-ZA wurde ja mittlerweile die sinnvolle Existenz dieser Sprachvariante nachgewiesen; dementsprechend jetzt konfiguriert.
  • CLDR kennen das bislang nicht.

VG --PerfektesChaos 19:14, 25. Jul. 2023 (CEST)

Ich stimme zu. Die Schrift verändert die Sprache nicht. Besonders nicht, wenn, wie bei Fraktur, die Buchstaben nur andere Formen haben; das lange s verändert auch nichts an der Sprache. Goethes Faust wurde bis 1941 in Fraktur gedruckt und danach in Antiqua. Der Text ist der gleiche.

Nehmen wir als Extrembeispiel eine Sprache, die in fünferlei Schriften geschrieben wird: die indische Sprache Santali. Es gibt mehr Santals als Bulgaren, aber weil die Sprecher dieser Sprache größtenteils bitterarme Landarbeiter sind, wurde sie erst im 19. Jahrhundert geschrieben. Und zwar in Lateinschrift durch die Missionare. Da die Santals im Grenzgebiet mehrerer indischer Bundesstaaten leben, wird ihre Sprache je nach Bundesstaat auch in der bengalischen Schrift, der Oriya-Schrift und der Devanagari-Schrift geschrieben. Keine dieser vier hat sich durchgesetzt, weil die meisten Santals andere Probleme haben als Bücher zu schreiben. Schließlich erfand der Lehrer Raghunath Murmu 1925 eine eigene Schrift für Santali, das Ol Chiki. Diese Schrift setzt sich langsam durch, weil eine eigene Schrift zu haben für viele Inder das Kennzeichen einer Bildungssprache ist.

Es handelt sich in allen fünf Fällen um die gleiche Sprache, die mit Bengalisch, Odia und Hindi nicht verwandt ist und mit europäischen Sprachen natürlich auch nicht. Nur weil Ol Chiki die besten Chancen hat, zum Standard für Santali zu werden, brauchen wir keine Sprachcodes für die anderen vier Schriften. Man kann sie ja in Ol Chiki umschreiben.

--Curryfranke (Diskussion) 18:39, 27. Jul. 2023 (CEST)

Da es aktuell zum Thema wieder einige Änderungen in betroffenen Artikeln gibt, möchte ich hier mal einige Punkte ansprechen. Leider sind bislang kaum weitere Meinungen von dritten dazugekommen, was es erschwert zu einer abgesegneten Lösung zu kommen, mit der gearbeitet werden kann. Folgende Punkte:

• hbs taucht immer noch auf Kategorie:Wikipedia:Vorlagenfehler/Parameter:Sprachcode in der Tabelle unter richtig auf, wiederspruch zur oberen Aussage hbs sei nicht zu verwenden. Entweder als richtig im Modul ergänzen, oder in der Tabelle rausnehmen.
• en-ZA wurde bereits zugelassen und im Modul von PC ergänzt, leider durch einen Komplettrevert der de-Latf betrifft wieder draußen.
• de-Latf, Es ist ein gültiger Code, aber kein Sprachcode, gehört also in der Praxis nicht in den Parameter Sprache=. Seh ich mittlerweile auch. Leider ging es heute wieder in den entsprechenden Artikel los. Da es nicht richtig geklärt wurde. Pintsknife (Diskussion) 15:49, 6. Aug. 2023 (CEST)

„Es gibt auch keine „deutsche Sprache in hebräischer Schrift“?“ siehe:http://www.von-humboldt.de/usrdata/vhchrono/WvH_1766-1790.html unter „vor 1787-12-25“ „sie hatten eine Geheimschrift erfunden (deutsche Sprache in hebräischer Schrift)“. Und viele Menschen jüdischen Glaubens haben Deutsch in hebräischer Schrift geschrieben (Moses Mendelssohn und viele andere); und dann siehe hier: Anleitung das Deutsche mit hebräischer Schrift zu schreiben, Übungsstück. Es geht um 2 Sachen: einmal die Sprache, das wird über ISO 639 gelöst, in den verschiedenen Varianten, also 2 oder 3 Buchstaben als Code (alles nicht abschließend, und kann ergänzt werden). Das andere ist die Schrift ISO 15924 (gerade erneuert): Im Bibliotheksbereich wurde schon früh (also im vergangenen Jahrtausend) in eine Fußnote vermerkt: In Fraktur (Student*innen schreiben das entsprechende Buch dann erst gar nicht in die Bücher-Leseliste). In anderen Sprachfamilien ist die Verknüpfung Sprache/Schrift noch viel wichtiger: https://www.iso.org/schema/isosts/v1.0/doc/n-cvd0.html. Das Latf an de zu hängen ist wohl tatsächlich unglücklich? Obwohl: Nach https://unicode.org/iso15924/iso15924-codes.html: Latf = Latin (Fraktur variant). Es ist eher üblich, den Ländercode an den Sprachcode zu hängen: http://www.lingoes.net/en/translator/langcode.htm Listen wie diese gibt es häufig. Weiterführende Lit.: https://www.w3.org/International/articles/language-tags/index.en ; https://unicode.org/iso15924/ ; und diese Liste zeigt, dass German nicht nur de ist: https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry . Und ein letztes: es gibt keine letztgültigen Lösungen, Sprache und ist immer im Wandel, wie alles. Aber zu sagen, das und das gibt es nicht, na ja ... Wie wäre es für die Schrift einen separten Paramenter anzubieten? Könnte diese Liste: https://unicode.org/iso15924/iso15924.txt importiert werden und dem Paramenter hinterlegt werden?: --Ettiwdreg (Diskussion) 01:26, 18. Aug. 2023 (CEST)

Modul:Multilingual/names

@PerfektesChaos Zu deinem Revert: Einverstanden, da habe ich zu kurz gedacht. Unabhängig davon frage ich mich schon länger, warum wir lokal Sonderformen der Sprachen vorhalten. Es gibt ja auch eine Welt außerhalb der deutschsprachigen Wikipedia, die alle von einem richtigen Eintrag im CLDR, zumindest der LocalNamesDe.php. profitieren würden. Konkret geht es um

• Lokal: be-tarask = Weißrussisch (Taraškievica)
• CLDR: be-tarask = Weißrussisch (Taraschkewiza)
• Lokal: de-formal = Deutsch (Sie-Anrede)
• CLDR: de-formal = Deutsch (Sie-Form)
• Lokal: nl-informal = Niederländisch (informell)
• CLDR: nl-informal = Niederländusch (informelle Anrede) <-- ups, da ist sogar ein typo drin
• Lokal: simple = Vereinfachtes Englisch
• CLDR: simple = einfaches Englisch

Ich habe keine Präferenzen für irgendeine der Schreibweisen. Vielleicht kann @Brettchenweber uns hier bei den richtigeren/besseren Schreibweisen helfen?

--Raymond ^Disk. 10:14, 1. Dez. 2023 (CET)

Erstmal wusste ich nicht, dass CLDR unsere -formal und -informal kennen würde.

Ich hatte diese genauso wie simple und be-tarask für MediaWiki-Privatgewächse gehalten, da etwa simple auch nicht in ISO 639 verwurzelt ist, und sowas auch nicht nach den expliziten Regeln herleitbar ist gemäß RFC 5646 – Tags for Identifying Languages. (englisch)..

Wikipedia:Technik/MediaWiki/Sprachen beschäftigt sich auch mit dem Kram.

Die Wiederherstellung hatte ich gemacht, weil derartige MediaWiki-Codes irgendwo vorkamen, woran ich mich aber nach bald einem Jahrzehnt nur noch nebelhaft erinnern kann.

„Niederländusch“ rechtfertigt eine Beibehaltung bis auf Weiteres; wenn CLDR mysteriöserweise MediaWiki-de-formal inzwischen kennt dann fein. „Sie-Anrede“ war zumindest vor einem Jahrzehnt mal die hiesige Bezeichnung; von irgendwo hier hatte ich das übernommen gehabt.

Die Wiki-Oberfläche nennt übrigens seit einiger Zeit de-x-formal, was dann besser angepasst ist an RFC 5646.

Das „Niederländusch“ haben wir in Spezial:Einstellungen auch gar nicht; dort nl-x-informal mit der deutschsprachigen Bezeichnung Nederlands (informeel).

VG --PerfektesChaos 11:13, 1. Dez. 2023 (CET)

Ah, und grad gefunden: Wikipedia:Technik/MediaWiki/Sprachen/de beispielsweise nutzt das außerhalb des ANR. Grad auch mit „Niederländusch“.

Was mir jetzt auch noch auffällt, ist fehlende Einheitlichkeit bei CLDR; mal „Form“, mal „Anrede“, bei mir nur Anrede:

• de-formal = Deutsch (Sie-Form)
• nl-informal = Niederländusch (informelle Anrede)

VG --PerfektesChaos 11:21, 1. Dez. 2023 (CET)

@PerfektesChaos „Niederländusch“ ist aber eindeutig ein typo, oder? Sollte eher „Niederländisch“ mit i statt u heißen?

be-tarask, de-formal, nl-informal und simple kommen aus dem MediaWiki-Core: Names.php und wurden für die Lokalisierung nach LocalNamesDe.php (und andere Sprachen) der CLDR-Extension übernommen. Es sind MediaWiki-Eigengewächse, aber sie sind eben da. Wann und wie die x-Varianten (de-x-formal, nl-x-informal)eingeführt wurden, und vor allem aus welcher Datei sie kommen, ist leider an mir vorbeigegangen.

Mit geht es jetzt vor allem darum, dass wir uns auf eine gute deutsche Übersetzung einigen, damit alle Projekte davon protitieren. Z.B. auch Wikidata ,hier eine Testseite mit vielen Sprachen . --Raymond ^Disk. 11:43, 1. Dez. 2023 (CET)

Nur damit ich es richtig verstehe: Anders als abschnittseinleitend angegeben, kommen -formal und -informal nicht aus CLDR, sondern aus irgendwelchen MediaWiki-internen Ressourcen?

Zur Übersetzung: Die en-Übersetzungen bzw. Stammbezeichnungen verwenden address, was sinngemäß dem deutschen „Anrede“ entsprechen würde, und „Anrede“ war meiner Erinnerung nach auch die langjährige Präsentation hierzuwiki. Das Wort „Sie“ zählt zu den „Anredepronomen“, und insofern erscheint mir „Sie-Anrede“ auch die verständlichere Erläuterung für Unbeteiligte.

„Niederländusch“ ist aber eindeutig ein Bug.

Als ich den umseitigen Spaß eingerichtet hatte, kannten #language usw. die -formal und -informal noch nicht oder nicht in jeder Situation; weil eben deshalb dort hinterlegt.

Die syntaktische Verbesserung durch -x- muss noch überall eingearbeitet werden, aber nicht mehr dieses Wochenende.

VG --PerfektesChaos 12:27, 1. Dez. 2023 (CET)

@PerfektesChaos Richtig. Die Definition der Sprachnamen mit -formal und -informal kommen aus einer MediaWiki-internen Ressourcen. Die Übersetzung ins Deutsche und einigen andere Sprachen aus der CLDR-Erweiterung. --Raymond ^Disk. 12:58, 1. Dez. 2023 (CET)