Vorlage Diskussion:Lang

Auf dieser Seite werden Abschnitte ab Überschriftebene 2 automatisch archiviert, die seit 5 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Archiv

Archiv1

Kanji und Hanja

Gemischtschriftliches Japanisch sollte mit ja-Jpan gekennzeichnet werden.* Ich bin mir aber nicht sicher, was für innerhalb deutscher Texte einzeln auftretende reine Kanji-Wörter am besten wäre. ja-Hani sieht ganz gut aus, aber man könnte zur Kennzeichnung aller Shinjitai-Kanji enthaltenden Texte auch für ja-Hans plädieren – schließlich markieren wir ja auch in chinesischen Texten nicht nur diejenigen Zeichen einzeln, die eine vom Langzeichen verschiedene Kurzform haben. Kyūjitai-Kanji könnte man mit ja-Hant markieren.

Ebenso wüßte ich gern, ob etwas gegen die Verwendung von ko-Hant statt ko-Hani zur Markierung von Hanja spricht. Vorlage:Koreanischer Name sollten wir dann ändern. Übrigens gibt es sogar vereinzelt mischschriftliche Texte, die vereinfachte Zeichen benutzen.

Falls allerdings Hans und Hant nicht nur auf chinesischsprachige Texte, sondern auch auf Japanisch und Koreanisch anzuwenden sind, wozu dient dann eigentlich Hani?

Sobald wir uns klarer geworden sind, wo Grauzonen und Problemfälle liegen und welche Fragen noch offen sind, sollten wir vielleicht mal bei der ISO 15924 Registration Authority nachfragen, für welche Situationen welche Codes gedacht sind. Ich halte auch einen eigenen Code für koreanische Mischschrift enstprechend Jpan für sinnvoll. Wikipeditor 16:35, 21. Okt. 2006 (CEST)

Über Nachfrage sollten wir wirklich einmal nachdenken. Ko-Hans ist unsinnig, sehe ich das richtig? Ich nehme einfach an, dass man bei der Registration Authority nicht darüber nachgedacht hat. Für Japanisch ist viel weniger Hant sinnvoll, als eine Jahresangabe wie 1901/1996 für Deutsch. --chrislb 问题 17:37, 21. Okt. 2006 (CEST)

* Jpan wird offenbar tatsächlich nicht als Standardschrift für ja vorausgesetzt/ergänzt, sondern muß angegeben werden. W. 2006-10-23

Siehe [1] und die Antworten darauf. --chrislb 问题 22:11, 27. Okt. 2006 (CEST)

Besten Dank! Wikipeditor 23:23, 29. Okt. 2006 (CET)

Wie sieht das aus, wenn man Lateinumschrift kennzeichnet? Von der Sprache her wäre das ja auch noch Chinesisch, Japanisch oder Koreanisch, aber ein anderes Schriftsystem (analog zu Kanji, Kana oder Hangeul). Ich finde, das sollte man auch kennzeichen (Für

Screenreader

o.ä.), aber vielleicht wünscht man nicht, dass der Browser dann automatisch die Lateinschrift aus der entsprechenden asiatischen Schrift aussucht, die sehen ja teilweise etwas hässlich aus bzw. passen dann nicht zur normalen deutschen Schrift? -- Hellstorm 17:54, 20. Aug. 2007 (CEST)

Der letzte Stand der Diskussion war, dies hier erstmal nicht zu tun, da es das Schriftbild negativ beeinflusst. Ansonsten mal direkt Benutzer:Wikipeditor fragen. --chrislb 问题 13:38, 21. Aug. 2007 (CEST)

Mit was wird eigentlich Zhuyin/Bopomofo gekennzeichnet? zh-Hant passt ja nicht so ganz, oder? -- Hellstorm 17:47, 27. Aug. 2007 (CEST)

Kann man alles in der oben verlinkten Subtag-Registry suchen: zh-Bopo. --Mps 17:50, 27. Aug. 2007 (CEST)

Dann werd ich das vielleicht mal oben in der „Sonstiges“-Liste ergänzen. -- Hellstorm 21:07, 27. Aug. 2007 (CEST)

Verwendung

Hallo,

ich sehe nach der Lektüre des Abschnitts "Definition" ein, daß eine Auszeichnung "exotischer" Sprachen durchaus sinnvoll ist, aber muß man die englische Sprache auch durch diese Vorlage auszeichnen? Mir sind heute folgende edits aufgefallen, die ich für fragwürdig halte: [2], [3], [4]. (Es tut mir leid, hier die Beiträge eines einzelnen Nutzers herauszustellen, aber diese sind mir nunmal aufgefallen)

Hier sind zwei dinge, die mir Kopfschmerzen bereiten: 1.) Würde dies konsequent umgesetzt, hätten wir diese Vorlage in so gut wie jedem Artikel der WP und würden damit 2.) die Einstiegshürde für neue Nutzer noch höher setzen (die Quelltexte sind ohnehin schon recht kompliziert geworden, muss man dies durch sowas noch steigern?).

Meiner Meinung nach sollte man darüber nachdenken, ob es möglich ist, die Verwendung dieser Vorlage auf einige Sprachen zu beschränken. Viele Grüsse,--Michael 10:23, 14. Jun. 2007 (CEST)

Hallo Michael, Du hättest auch einige meiner Edits in letzter Zeit als Beispiel anführen können (;-)), da ich die Vorlage auch immer wieder einbaue. Von daher meine Gründe, warum ich denke, dass die Vorlage sinnvoll ist, auch und teilweise gerade für "Standardsprachen" wie Englisch oder Französisch.

Die oben angegebenen Gründe sind soweit ich das sehe unabhängig von der Sprache, wobei je nach Punkt mal mehr, mal weniger bedeutend. Aber speziell bei der Unterstützung von Screenreadern ist nach meinem Wissenstand primär die Auszeichnung der Standardsprachen wichtig, da die meisten der Produkte nur diese Sprachen unterstützen. Und Wikipedia wurde, wenn ich mich recht erinnere eh schon wegen schlechter Accessibility kritisiert. Auch Suchmaschinen können diese Information sicher unabhängig davon, welche Sprache es genau ist, gut gebrauchen ("Antwortseiten, geschrieben in ..." bei Google).

Einfachheit des Quelltextes ist sicher ein wichtiges Argument, Vorlagen sind ein generelles Konzept in der Wikipedia, das man nach einmaligem Verstehen vielfach einsetzten kann.

Viele Grüße, --S.K. 11:18, 14. Jun. 2007 (CEST)

Inzwischen ist die Vorlage aus den ersten beiden Artikeln bis auf den Einleitungssatz längst verschwunden. --87.153.115.194 05:15, 12. Apr. 2017 (CEST)

Falsche Sprachangaben?

In vielen Artikeln, besonders bei Manga/Anime, sind viele Namen in japanischer Schrift durch die Vorlage Lang gekennzeichnet.

Allerdings scheint es die Codes ja-Kana, ja-Hani oder ja-Jpan nicht im offiziellen Standard zu gebenn. Laut ISO-3166-1, für die Kennzeichnung des Landes, und ISO-639-2, für die Kennzeichnung der Sprachen, sollte laut RFC 3066 jpn-JPN (Kana und Hiragana) oder chi-JPN (Kanji) verwendet werden. (Es gibt noch weitere Möglichkeiten Codes für die gleichen Sprachen zu bilden, allerdings würde auch eine Variante 3-3 reichen, da alle Sprachen und Länder damit abgedeckt sind.) Das W3C bezieht sich ebenfalls auf RFC 3066.

Ist nun die Angabe von ja-Kana und Co. falsch oder nicht? Der Konvention scheinen sie mir jedenfalls nicht zu entsprechen. --Niabot (Diskussion) 13:02, 2. Okt. 2007 (CEST)

Siehe dazu auch oben #Definition. --*Rawk!* Polly want a cracker! 13:26, 2. Okt. 2007 (CEST)

Aus dieser Definition lassen sich aber keinesfalls ja-Kana oder ja-Hani ableiten, da diese schreibweisen (Sprachen) zu keinem Standard gehören. Siehe auch oben genannten Link: W3C I18n. --Niabot (Diskussion) 13:52, 2. Okt. 2007 (CEST)

Ergänzung: Nach der neuesten Regelung wären diese Angaben erlaubt, allerdings setzt dies die Erweiterung RFC 4646 voraus. XML und XHTML in aktueller Version (wie sie von Wikipedia verwendet werden) beschränken sich aber auf RFC 3066. Somit wäre eine Angabe die über "language-region-variant" hinausgeht nicht konform. --Niabot (Diskussion) 14:03, 2. Okt. 2007 (CEST)

Doch die lassen sich aus W3C I18n ableiten. In diesem Dokument ist das Format als
langtag = (language["-" script]["-" region]*("-" variant)*("-" extension)["-" privateuse]) definiert. Damit kann man Scripts angeben, was über dein genanntes language-region-variant hinausgeht. Desweiteren steht in W3C I18n über die möglichen Script-Angaben und die Language Subtag Registry, dass All of the initial records have the date "2005-10-16" as shown above. Hani, Kana, Hira und Hrkt gehören zu dieser initialen Menge und können damit als nach W3C I18n festgelegt gelten. --Mps 14:30, 2. Okt. 2007 (CEST)

Dann vestehe ich aber nicht, dass in [5] folgender Satz steht: „The script subtag is new in RFC 4646. The subtags come from, and are kept up to date with, the list of ISO 15924 script codes.“

Demnach wird RFC 4646 vorrausgesetzt, welches aber ein Nachfolger von RFC 3066 ist. XML (1.0) selber legt aber nur RFC 3066 als Standard fest. Wohingegen sich XHTML (1.0) auf HTML (4.01) bezieht und sogar nur RFC 1766 zulassen würde. Ich weiß jetzt nicht inwieweit diese Tags abwärtskompatibel sind, vermute aber, dass sie dies eben nicht sind. --Niabot (Diskussion) 14:47, 2. Okt. 2007 (CEST)

Sie sind abwärtskompatibel, denn in RFC 1766 steht The information in the subtag may for instance be: […] Script variations, such as az-arabic and az-cyrillic. Das heisst das Script-Angabe zwar zulässig sind, jedoch noch nicht normiert waren, d.h. man nach Gutdünken irgendwas hinschreiben konnte. So wird zum im Beispiel darunter z.B. arabic als Script-Angabe verwendet. RFC 3066 verwendet auch nur eine generische Angabe Language-Tag = Primary-subtag *( "-" Subtag ) und schreibt lapidar Tags with second subtags of 3 to 8 letters may be registered with IANA, according to the rules in chapter 5 of this document. (Anmerkung: nur ein Buchstabe ist ungültig, zwei Buchstaben sollen als ISO 3166 alpha-2 angesehen werden). Meint also die IANA wird sich schon was einfallen lassen, nimmt aber wiederum keine Definition vor. RFC 4646 nimmt dann schließlich eine Definition von Subtag vor. RFC 4646 kann damit als Spezialisierung der eher generisch gehaltenen RFC 1766 und RFC 3066 angesehen werden, so dass Anwendungen die beide letztere unterstützen auch RFC 4646 unterstützen, aber eben nicht die Informationen aus den Subtag-Einträgen nutzen können. --Mps 17:47, 2. Okt. 2007 (CEST)

Danke für den Hinweis, dann kann ich ja jetzt beruhigt ja-Hani-JPN etc. hinschreiben. :P --Niabot (Diskussion) 20:42, 2. Okt. 2007 (CEST)

Erstens vermute ich, wenn man schon die Region hinzuschreibt, müßte es JP statt JPN heißen. Zweitens ist es wohl aber besser, …-JP nicht hinzuzuschreiben, weil sonst der Eindruck entstünde, der markierte Text enthalte Ausdrücke, die es so in Dialekten anderen Regionen nicht (oder mit anderer Bedeutung) gibt, oder die Region sei für das Schriftbild von Belang. Es dürfte nur wenig japanisches Vokabular (oder Grammatik) geben, das außerhalb Japans lebende Japanischsprecher nicht oder anders verwenden. Für Eigennamen – besonders Personennamen – dürfte die Region unnötig sein, es sei denn, der Name z.B. ein und desselben Menschen wird in zwei Regionen gleicher Schrift regelmäßig unterschiedlich geschrieben/transkribiert. Viel Spaß bei der Entscheidung, welche Schreibungen bereits Übersetzungen in eine andere Sprache darstellen und welche lediglich Transkriptionen sind.

Im Übrigen dachte ich immer, offiziell seien alle Kodes, die die Registry hergibt, falls dort etwas fehlt, bedienen wir uns in Erwartung baldiger Aufnahme einstweilen bei ISO 15924, und wie wir das Ganze benutzen sollen, stünde in den relevanten Dokumenten auf w3c.org. Wikipeditor 00:57, 14. Okt. 2007 (CEST)

Frage zu Artikeln mit japanischen Namen

Diese Vorlage sollte ja verwendet werden um anderssprachige Elemente zu kennzeichnen. Häufig schreibt man aber Dinge wie in folgendem Beispiel:

''Elenore Baker'' ({{Lang|ja-Jpan|エリノア・ベイカー}}, ''Erinoa Beikā'')

Wäre es hier nicht korrekter

''Elenore Baker'' ({{Lang|ja-Jpan|エリノア・ベイカー}}, ''{{Lang|ja-Latn-JA|Erinoa Beikā}}'')

zu schreiben? Ich sehe hier allerdings ein kleines Problem darin, dass der eigentliche Text in Vorlagen erstickt. --Niabot (Diskussion) 22:12, 4. Okt. 2007 (CEST)

Die Kennzeichnung von romanisiertem Text wurde bisher nicht vorgenommen, dies war u.a. bedingt durch ein Problem der Schriftarten bei der Darstellung. Der angesprochene Punkt gilt z.B. auch für Pinyin wie mit {{Lang|ja-Latn|Máo Zédōng}}. Falls du Interesse hast da weiter nachzuforschen, dann würde ich dich bitten Benutzer:Wikipeditor anzusprechen und nach dem aktuellen Stand zu fragen. Deine Länderangabe JA finde ich überflüssig, und sollte laut Spezifikation möglichst entfallen, wenn kein besonderer Hintergrund vorliegt. --chrislb 问题 04:04, 5. Okt. 2007 (CEST)

Ja das mit dem JA ist hier unter Umständen nicht ganz korrekt, da mir zu diesem fiktionalen Beispiel nicht wirklich ein Grund einfällt, es nach Japan drücken zu wollen. Ich werde mich an Benutzer:Wikipeditor wenden. --Niabot (Diskussion) 09:16, 5. Okt. 2007 (CEST)

Zuviel der Ehre – chrislb hat bestimmt mehr zum Thema gelesen als ich. Zwar habe ich mich seit Monaten nicht mehr damit beschäftigt, aber das Problem dürfte immer noch folgendes sein: Einerseits wäre es eigentlich richtig, bloße Umschriften nicht wie Übersetzungen zu behandeln. Andererseits bestechen die Fonts, die in Internetbrowsern zur Anzeige ostasiatischer Sprachen eingestellt sind, durch Masse statt Klasse, etwa in bezug auf diakritische Zeichen, die ja gerade in Umschriften oft vorkommen. Für solche CJK-fontinternen Probleme dürfte es technisch bedingt auf absehbare Zeit keine Lösung geben. Die eigentlich Schuldigen sind aber wohl eher die heutigen Browser, die nämlich den zur Darstellung eines Textes zu verwendenden Font noch nicht nach der Schrift, sondern der Sprache des Textes auswählen – mal abgesehen von ein paar registrierten Wikilesern, die ihr Stylesheet entsprechend erweitert haben. Sobald Browser auf Schrift statt Sprache achten, haben wir das Problem nicht mehr. "Korrekte" Etikettierung scheint sich in der Wikipedia bislang nicht durchgesetzt zu haben. Das kommt der Lesbarkeit (und Ästhetik) für Menschenaugen zugute. "Korrekte" Etikettierung wäre aber ein kleiner Anreiz für Anbieter von Browsern, deren Fontauswahlkriterium zu ändern; vielleicht sprechen auch eines Tages Vorleseprogramme in Artikeln über die Phonetik von Fremdsprachen nicht mehr alles deutsch aus. Wikipeditor 00:57, 14. Okt. 2007 (CEST)

Wo Vorlage überall einbauen?

Hallo. Wie bereits gesagt, sind wir gerade dabei, in Artikeln über Thailand die Vorlage:Lang einzubauen. Dabei ist mir nicht so ganz klar, wo sie überall benutzt werden soll. Speziell hier: Im Artikel Nakhon Ratchasima gibt es unten unter Einzelnachweise einen Link auf die thailändische Wikipedia. Soll die Vorlage dort auch benutzt werden? Wenn ja, wie wird sie da eingebaut, dass der Link noch funtioniert? --Hdamm 08:55, 29. Mai 2008 (CEST)

Laut W3C (siehe weiter oben in der Diskussion) soll die Vorlage für alle fremdsprachigen Worte (nicht nur andere Schriftsysteme), die in der Muttersprache des Schriftstücks nicht gebräuchlich sind, mit Sprachauszeichnungen (der Vorlage) versehen werden. Dazu gibt es leicht geteilte Meinungen, aber bei wichtigen Begriffen sollte man dies ruhig machen, da hier die Auszeichnung auch zum Verständnis beiträgt. PS: Ich korrigiere das eben mal. -- ▪Niabot▪議論▪ 09:13, 29. Mai 2008 (CEST)

Ja danke. Das ist doch ne ganz gute Lösung so. --Hdamm 10:18, 29. Mai 2008 (CEST)

Was sollen die ganzen verschiedenen Schrifttags bei Japanisch?

Die Frage kam zwar schon einmal auf, aber ich sehe immer noch nicht den Sinn von ja-Jpan und ja-Hani und ja-Kana und ja-Hira. Jede japanische Schriftart hat sowohl Kanji als auch Kana drin (von einigen ganz wenigen ausgenommen, die aber wohl kaum für den normalen Gebrauch sind), daher ist die zusätzliche Angabe im Grunde völlig unnütz. Wir schreiben ja auch nicht en-Latn, sondern einfach nur en (ich weiß, in dieser Registry steht drin, daß sich die Schrifttags nicht implizieren, aber da müßte man auch mal realistisch sein). Und welcher japanische Text besteht nur aus Kana oder nur aus Kanji (jetzt mal von Kinderbüchern und Kanbun abgesehen)? Zum einen hat sowieso kein Browser die Möglichkeit, zwischen den verschiedenen Schrifttags umzuschalten (oder welcher kann das?), d.h. im Grunde machen wir das im Moment sowieso zu richtig, obwohl es kein Browser kann. Zum anderen wird niemals jemand sich sagen „Ich will die Kanji aus der Schriftart und die Kana aus der anderen“. Eine japanische Schriftart ist Japanisch, fertig. Da nimmt man Kana und Kanji für. Das einzige, was für Japanisch interessant wäre, wäre ja-Hant, bei der man dann notfalls eine chinesische oder koreanische Schriftart nehmen kann, die z.B. den

示偏

anders darstellt. Schreiben wir ansonsten auch ko-Hani und ko-Hang? Da benutzen wir doch meines Wissens auch einfach nur ko. Ich wäre sehr dafür, diese ganze Verwirrung zu verhindern und einfach nur noch {{lang|ja|

日本語

}} bzw. in absoluten Ausnahmefällen {{lang|ja-Hant|

所

}} zu benutzen. Wer wäre noch dafür? Dann müßte man mal die Namenskonventionsseite ändern. -- Hellstorm 19:28, 12. Apr. 2009 (CEST)

Da wäre ich nicht abgeneigt. Schließlich steht ja auch in den i18n noch der kleine Beisatz, dass die Angaben möglichst so unpräzise wie möglich formuliert sein sollen. "The golden rule when creating language tags is to keep the tag as short as possible" [6] Einzig eine Unterscheidung zwischen ja und ja-Latn würde ich belassen wollen, da hier wirklich bei der Darstellung von den Browsern nachgebessert werden kann (unterschiedliche Schriftbreiten, Raster). Die restliche Unterscheidung macht oftmals wenig Sinn, insbesondere dann, wenn japanische Zeichen (Kanji, Kana, Hiragana) mit lateinischen Zeichen vermischt werden. Hier sollte dann ein einfaches ja reichen, egal ob es aus Japan stammt oder nicht. -- ▪Niabot▪議論▪+/− 19:56, 12. Apr. 2009 (CEST)

Achso, ihr wollt also allen international gültigen Konventionen trotzen und einfach euer eigenes Ding durchziehen, ja? Und das ohne den Sinn dieser Tags verstanden zu haben!? Einfach mal http://tools.ietf.org/rfc/bcp/bcp47.txt. http://en.wikipedia.org/wiki/ISO_15924 und http://en.wikipedia.org/wiki/IETF_language_tag zu Gemüte ziehen. Ich persönlich habe bisher auch bloß Hans, Hant und Jpan verwendet, hatter aber keine komplett in Hira oder Kana verfassten Texte. Aber ich sehe nicht, warum man generell von Hira, Kana und HrKt abraten sollte. Jpan ist als suppress script registriert: http://www.iana.org/assignments/language-subtag-registry, also braucht man es nicht extra hinschreiben, aber deswegen muss man eben die anderen hinschreiben.

Im übrigen ist der Scripttag optional. Es reicht auch nur ja, aber die anderen sind halt alle spezieller. Man muss also nicht unbedingt ja-Hira hinschreiben wenn man nicht möchte, da Hira ja in Jpan drin ist. Von standardisierten Tags abzuraten halte ich hier für völlig daneben. Es gibt Text-to-Speech verfahren, die diese Tags nutzen können und man kann sich zum Beispiel spezielle Browser-Addons holen, die z.B. Hiragana hervorheben anhand dieses Scripttags. Zumindest ist das so möglich und andersherum nicht. Den normalen User interessiert es eh nicht, denn im schlimmsten Fall sieht er gar nicht so eng und beachtet es sowieso nicht. --Tauwasser 09:48, 17. Jul. 2009 (CEST)

unbekanntes iso-kürzel

sollten wir nicht ein feature für unbekannten sprachcode ergänzen, optimalerweise einfach "?" (ich mach das so ;) - dann könnte entweder ein wartungslink auf die iso-code seiten kommen, oder wir tragen das in eine wartungskategorie ein - um fachliches abarbeiten zu ermöglichen, ginge etwa auch erwitertere anfragen, wer hat zum beispiel gerade den isocode für altägypisch oder koptisch im kopf? - so könnte man wartungslisten für einzelne spachportale ergänzen: unserer altegyptenabteilung hat das sicherlich parat, und freut sich wohl, das kompetent zu bearbeiten --W!B: 11:54, 14. Dez. 2009 (CET)

Wenn die Sprache unbekannt ist wird laut BCP 47 als Sprachkürzel und (für undefined) verwendet. --Mps 12:57, 14. Dez. 2009 (CET)

ah, ja, das ist auch nicht schlecht, wusste ich gar nicht --W!B: 13:01, 14. Dez. 2009 (CET)

Referenzliste

Kann man eine kurze Referenzliste der wichtigsten für Vorlage:lang gebrauchten Kürzel erstellen? Das wären die wichtigsten Sprachen (de, fr, en, es, it, ru), sowie die wichtigsten Terminologie-Sprechen (lat, grc) und vielleicht über eine Parameter-Statistik von Vorlage:lang die wichtigsten dort verwendeten Sprachen. (nicht signierter Beitrag von 93.197.151.32 (Diskussion) 19:22, 2. Jan. 2011 (CET))

Mongolisch

Für die traditionelle mongolische Schrift sollte nicht die lang-Vorlage, sondern die Vorlage:MongolUnicode verwendet werden. --Gregor Kneussel (Diskussion) 16:16, 1. Dez. 2013 (CET)

Dadurch das {{MongolUnicode}} keinerlei Sprachauszeichnung vornimmt, muss (zumindest sollte) {{Lang}} dennoch verwendet werden, solange MongolUnicode das nicht selber macht. --Mps 、かみまみた^Disk. 17:38, 1. Dez. 2013 (CET)

Die Vorlage mnS-Mong führt zu einer falschen waagrechten Darstellung der mongolischen Schrift: mongolisch ᠰᠤᠮᠤ

Korrekt wäre MnS|{{MongolUnicode in senkrechter Darstellung: mongolisch ᠰᠤᠮᠤ

Für manche mögen das nur Krakel sein, für den Mongolen ist es seine Schrift. Für weitere Informationen siehe:
https://de.wikipedia.org/w/index.php?title=Sum_(China)&diff=222132968&oldid=222132681

Regnart (Diskussion) 09:34, 17. Apr. 2022 (CEST)

Dahinter steckt ja die generische Fragestellung, wie man Schriften mit einer Schreibrichtung von oben nach unten in einen Fließtext mit Schreibrichtung von links nach rechts einbettet. Dazu gibt es ja sicher Erfahrungen im professionellen/wissenschaftlichen Satz. Dabei geht es nicht darum, Mongolisch „falsch“ darzustellen (oder gar Mongolen nicht ernst zu nehmen), sondern es geht um eine vernünftige Lesbarkeit und Darstellung gemischtsprachiger Texte. Das ein (Block-)Zitat mit den heutigen Möglichkeiten die natürliche Schreibrichtung von Mongolisch verwendet, darüber besteht vermutlich Konsens. „Spannend“ sind kurze mongolische Texte in „viel“ deutschem Text.

Dazu könnte ich mir vorstellen, dass {{Lang}} und die davon abgeleiteten Vorlagen wie {{MnS-Mong}} einen Parameter anbieten, die Schreibrichtung zu wählen. Damit wird es zum Entscheid des Artikelautors, wann/wo welche Schreibrichtung zum Einsatz kommt.

--S.K. (Diskussion) 19:23, 17. Apr. 2022 (CEST)

Die Vorlage:lang sieht nur Rechts-nach-Links-Schriften vor, aber keine senkrechten Schriften wie zum Beispiel auch die Mandschurische Schrift. Meine Frage war eigentlich, warum man nicht MnS|{{MongolUnicode verwenden kann, das - zumindest auf meinem Computer - eine korrekte Darstellung erzeugt. Natürlich sprengen senkrechte Einsprengsel den Zeilenabstand, wie Du im Abschitt "Geschichte" des Mandschu-Artikels sehen kannst. Aber die Innere Mongolei ist heute ein Hochtechnologie-Standort (Metalle der Seltenen Erden, Raumfahrt), da kommt man um die Mongolen nicht herum. Und nachdem modernes Mongolisch, ähnlich wie Englisch, anders ausgesprochen wird, als man es schreibt, wäre die Wiedergabe von Ortsnamen, Behörden etc. in mongolischer Schrift schon hilfreich, damit der interessierte Leser das auch im Lexikon findet. Also warum nicht MnS|{{MongolUnicode? Die anderen sind anders - manche Menschen schreiben waagrecht, manche Menschen schreiben senkrecht. Damit sollte man doch eigentlich leben können. --Regnart (Diskussion) 08:13, 18. Apr. 2022 (CEST)

Das „Problem“ mit {{mnS|{{MongolUnicode|}}}} ist wie im Edit-Kommentar beschrieben, erst einmal das {{MnS}} eine Weiterleitung auf {{MnS-Cyrl}} ist. Das heißt, der erste Parameter, der mongolische Text, wird von der Vorlage in kyrillischer Schrift erwartet und nicht in mongolischer Schrift. Um das erste Problem zu vermeiden, könnte man {{mnS-Mong|{{MongolUnicode|}}}} verwenden:

{{mnS-Mong|{{MongolUnicode|ᠰᠤᠮᠤ}}|mn-Cyrl=Сум}}
mongolisch ᠰᠤᠮᠤ kyrillisch Сум

Das ergibt optisch das von dir gewünschte Ergebnis, aber das was dort intern passiert, ist ziemlicher „Unsinn“. :-( Die erste Vorlage mns-Mong sagt schon, der Text ist in mongolischer Sprache und Schrift, die zweite Vorlage MongolUnicode sagt noch einmal, das ist mongolische Schrift, aber ohne Angabe der Sprache. Außerdem ist die Vorlage MongolUnicode konzeptionell/in der Implementierung ziemlich veraltet.

Langer Rede, kurzer Sinn: Man kriegt es optisch „hingebastelt“, aber ohne das mnS-Mong die Schreibrichtung von oben nach unten unterstützt, ist das Ergebnis schlecht.

Und die konzeptionellen Fragen von oben (wann verwendet man die Schreibrichtung von oben nach unten, wann nicht) sind damit noch nicht adressiert.

--S.K. (Diskussion) 16:05, 18. Apr. 2022 (CEST)

Also ich bin mit dem Ergebnis zufrieden. Der Leser braucht ja nicht zu wissen, was im Hintergrund mit den Vorlagen abläuft; der interessiert sich nur für das, was auf dem Bildschirm dargestellt wird. Ich habe das jetzt mal in den Artikel Sum (China) eingebaut.

Zur konzeptionellen Frage würde ich sagen, dass bei Mongolisch und Mandschurisch nur die Schreibung von oben nach unten verwendet wird. Ich kann es mit meinem Gewissen nicht vereinbaren, Mongolisch waagrecht zu schreiben. Aber wenn ein Autor aus ästhetischen Zeilenabstandsgründen darauf besteht waagrecht zu schreiben, werde ich mich da nicht einmischen. --Regnart (Diskussion) 20:23, 18. Apr. 2022 (CEST)

lang|ja gibt auf Android falsche Zeichen aus, z.B. 土 statt 生

Hier habe ich ein Problem mit Japanisch: Diskussion:Kyōiku-Kanji.

Dieser Artikel enthält eine Liste von ca. 1000 Schriftzeiten. Kein Problem bei Anzeige auf dem Windows PC, aber einige Zeichen (5%?) werden auf der Wikipedia Android App falsch angezeigt, z.B. 生, 虫, 火, 王. Gleiches Symptom im englischen Artikel en:Kyōiku kanji#First_grade_.2880_kanji.29 . Dort habe ich für Zeichen 35 und 68 die Syntax geändert und damit das Problem gelöst:

32 || {{lang|ja|[[wikt:生|生]]}}

35 || [[wikt:虫|虫]]

68 || {{lang|ja-r|[[wikt:火|火]]}}

70 || {{lang|ja|[[wikt:王|王]]}}

Die Lösung ja-r habe ich im Wiktionary-Quelltext gefunden. Es steht aber nicht in diesem IANA-Link http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

Wie können wir erreichen, das es auch mit einfachem "ja" funktioniert? --Tim2007viatge (Diskussion) 22:59, 9. Sep. 2016 (CEST)

Hmmm, statt hier bei der technischen Vorlagenprogrammierung vielleicht besser in Redaktionen wie PD:Japan anfragen. Die kennen sich mit dem spezifischen Problem eher aus und hatten eventuell schon mal was damit zu tun.
Wenn ein Code globale Wirkung haben soll, dann muss er RFC 5646 entsprechen.
- Damit müsste das ein extension subtag gemäß RFC:5646 #section-3.7 sein.
- Problem: Es sind nur t und u bekannt und offiziell registriert:
  - RFC 6497 - BCP 47 Extension T
  - RFC 6067 - BCP 47 Extension U

Bekannter und standardisiert ist der Einfluss von ISO 15924 – das könnte und soll durchaus auf Softwaresysteme wirken.
- Hier kämen in Frage:
  1. ja-Hrkt Japanese syllabaries (alias for Hiragana + Katakana)
  2. ja-Jpan Japanese (alias for Han + Hiragana + Katakana)
- Ich habe keine Ahnung, ob eine Silbenschrift etwas mit den beanstandeten Schriftzeichen zu tun haben könnte. Ausprobieren.
- Es gäbe noch nachgestellte Codes gemäß ISO 3166, hier neben ja-JP vielleicht fiktive Varianten in den Nachbarstaaten ja-KR oder ja-TW

Viel Erfolg --PerfektesChaos 11:07, 10. Sep. 2016 (CEST)

Hrkt ist falsch, da dies Kana beschreibt, während das Problem wohl bei Kanji auftritt. Jpan ist korrekt, aber überflüssig, da es gemäß https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry als Suppress-Script für den Sprachcode ja ausgezeichnet ist, d.h. als wegzulassender Standardwert. ja-KR oder ja-TW sind ebenfalls unsinnig.

Wichtiger wäre herauszufinden warum der Fehler auftritt, statt an Symptomen herumzudoktern. Eine Lösung darf zudem nicht gegen Standards verstoßen.

Mir ist zudem aufgefallen, dass der Fehler bei mir auch unter Chrome/Win10 im Visual Editor (nicht jedoch in der Normalansicht) auftritt. Ich werde mir das daher mal anschauen. Was ich weiß ist dass es kein Darstellungsproblem ist, da wenn man das Schriftzeichen herauskopiert und woanders einfügt, ebenfalls das falsche kopiert wird. Aus irgendeinem Grund werden tatsächlich die Zeichen an sich ersetzt und nicht einfach nur falsche Glyphen im Font ausgewählt. --Mps 、かみまみた^Disk. 13:17, 10. Sep. 2016 (CEST)

Das ist wohl ein Softwarefehler seitens Wikipedia. Der Fehler tritt reproduzierbar unter verschiedenen Browsern im Visual Editor auf, dass z.B. im Artikel Kyōiku-Kanji für Eintrag 35 八 statt 虫 angezeigt wird. Im Seitenquellcode steht an dieser Stelle:

<span lang="ja" about="#mwt37" typeof="mw:Transclusion" data-mw="{"parts":[{"template":{"target":{"wt":"lang","href":"./Vorlage:Lang"},"params":{"1":{"wt":"ja"},"2":{"wt":"[[wikt:虫|虫]]"}},"i":0}}]}" id="mwATE" class="ve-ce-focusableNode ve-ce-leafNode ve-ce-mwTransclusionNode" contenteditable="false"><a rel="mw:ExtLink" href="https://de.wiktionary.org/wiki/%E5%85%AB" title="wikt:八">八</a></span>

--Mps 、かみまみた^Disk. 21:32, 12. Sep. 2016 (CEST)

Also, die lang="ja-r" verweist nicht auf eine valide registrierte Extension.
- iana.org – nur t und u sind zurzeit registriert.
- Das -r ist damit schlicht ein Syntaxfehler, wahrschinlich kann man auch lang="ja-q" hinschreiben und per Seiteneffekt wegen der nicht ganz interpretierten Spezifikation tritt irgendein Effekt auf.
Schreibt ihr das Problem mit Erwartung und Angabe im Quelltext und dargestelltem Zeichen nochmals mittels der U+-Notation auf, statt die Zeichen hinzuschreiben?
- Es gibt ein Matrix-Problem: Wenn auf einer Wiki-Seite aus jedem X ein U gemacht wird, und ihr beschwert euch auf einer Wiki-Diskussionsseite über das U, dann ist nicht klar, ob das U nun geträumt oder ein X oder sonstwas ist.
- Vielleicht lässt sich dem Wertebereich der Hexcodes auch bereits ein Lösungsansatz entnehmen.
Oben hatte ich ob des scheinbar hilfreichen lang="ja-r" Beispiele für korrekte Subtags für Schrift bzw. Region genannt, die möglicherweise eine Software beeinflussen.

VG --PerfektesChaos 15:08, 13. Sep. 2016 (CEST)

@PerfektesChaos: Hallo, anbei die komplette Liste (ermittelt mittels Regex \[\[wikt:(.)\|\1\]\].+?title=""wikt:(.)"">\2 mit \1 (Linkziel) ≠ \2 (Linktext) – im Quelltextmodus sind beide gleich, im VisualEditor-Modus nicht) von Kyōiku-Kanji mit falschen Einträgen (links jeweils Soll, rechts Ist) im VisualEditor-Modus:

[entfernt, siehe bearbeitete Kopie von PerfektesChaos unten] --Mps 、かみまみた^Disk. 23:40, 21. Sep. 2016 (CEST) --Mps 、かみまみた^Disk. 00:03, 21. Sep. 2016 (CEST)

CJK range scramble

Conversation in this sub-section partially shifting to English heading for broader audience.

All codepoints below U+FFFF.
Shifts in entire 256 double-octet blocks.

@Mps:

Wenn die Liste unten stimmig ist, kannst du zur Entlastung des Archivs die aus deinem Beitrag entfernen.
Kann es irgendeinen sprachlichen Grund für die Verschiebung zwischen zwei Zeichenbereichen geben?
- Es gibt Traditional Chinese → Simplified Chinese.
- Und halfwidth → fullwidth.
- Aber das wären zwei oder drei Standardwerte für eine Verschiebung; das da unten sind Dutzende.
- Die Zeichen werden auch aus einem weiten Bereich katapultiert; es betrifft nicht nur eine Schriftvariante von einigen 100 Zeichen.
Ich habe jetzt nicht verstanden, wann genau das Problem auftritt.
- Die ursprüngliche Meldung lautete auf „im Android“ gemäß Abschnittsüberschrift.
- Jetzt ist vom VE die Rede.
- Das heißt: Das Problem besteht nur im VE-Modus, dann aber immer, Mobil und Desktop, während es beim Angucken und bei der Quelltextbearbeitung in Ordnung ist?
- Weil mit Android VE benutzt wurde, wurde das zunächst nur dort sichtbar?
- Wenn man das aber als (invalides) lang="ja-r" deklariert, bleibt es ungestört? lang="ja-a" und lang="ja-b" ebenso? Und bei explizitem lang="ja" passiert genau was?
- Hast du noch mehr Desktop-Browser zum Ausprobieren? Android und Chrome sind beide aus dem Hause Google und teilen sich Bibliotheken und Methoden.
Kann man den hier gefundenen Zeichenbereich allgemeiner beschreiben; japanese fullwidth ideographs oder so?
Bei der Frage nach Hexcodes hatte ich mir schon was gedacht.

U+4E0D 不 → U+540D 名 +0600
U+4E16 世 → U+5916 外 +0B00
U+4E21 両 → U+6821 校 +1A00
U+4E26 並 → U+6226 戦 +1400
U+4E3B 主 → U+753B 画 +2700
U+4E45 久 → U+6D45 浅 +1F00
U+4E57 乗 → U+5B57 字 +0D00
U+4E71 乱 → U+5C71 山 +0E00
U+4E73 乳 → U+5973 女 +0B00
U+4E89 争 → U+7389 玉 +2500
U+4E8B 事 → U+898B 見 +3B00
U+4EA1 亡 → U+7BA1 管 +2D00
U+4EAC 京 → U+72AC 犬 +2400
U+4EC1 仁 → U+54C1 品 +0600
U+4ECA 今 → U+8ECA 車 +4000
U+4ECF 仏 → U+65CF 族 +1700
U+4ED8 付 → U+9AD8 高 +4C00
U+4EE3 代 → U+53E3 口 +0500
U+4EE4 令 → U+53E4 古 +0500
U+4EE5 以 → U+65E5 日 +1700
U+4EEE 仮 → U+76EE 目 +2800
U+4EF2 仲 → U+96F2 雲 +4800
U+4EF6 件 → U+5CF6 島 +0E00
U+4EFB 任 → U+96FB 電 +4800
U+4F1A 会 → U+591A 多 +0A00
U+4F1D 伝 → U+671D 朝 +1800
U+4F3C 似 → U+663C 昼 +1700
U+4F4D 位 → U+524D 前 +0300
U+4F59 余 → U+6559 教 +1600
U+4F7F 使 → U+897F 西 +3A00
U+4F8B 例 → U+898B 見 +3A00
U+4F9B 供 → U+529B 力 +0300
U+4FA1 価 → U+7BA1 管 +2C00
U+4FBF 便 → U+5BBF 宿 +0C00
U+4FDD 保 → U+5DDD 川 +0E00
U+4FE1 信 → U+54E1 員 +0500
U+4FEE 修 → U+76EE 目 +2700
U+4FF3 俳 → U+53F3 右 +0400
U+4FF5 俵 → U+5FF5 念 +1000
U+5009 倉 → U+4E09 三 -0200
U+500B 個 → U+4E0B 下 -0200
U+500D 倍 → U+540D 名 +0400
U+5019 候 → U+7D19 紙 +2D00
U+501F 借 → U+571F 土 +0700
U+5024 値 → U+5224 判 +0200
U+505C 停 → U+4F5C 作 -0100
U+5065 健 → U+5165 入 +0100
U+5074 側 → U+5E74 年 +0E00
U+5099 備 → U+5199 写 +0100
U+50B7 傷 → U+8CB7 買 +3C00
U+50CD 働 → U+6BCD 母 +1B00
U+50CF 像 → U+65CF 族 +1500
U+512A 優 → U+592A 太 +0800
U+5143 元 → U+5343 千 +0200
U+5146 兆 → U+5546 商 +0400
U+5149 光 → U+8349 草 +3200
U+5150 児 → U+5B50 子 +0A00
U+515A 党 → U+9B5A 魚 +4A00
U+5171 共 → U+5C71 山 +0B00
U+5175 兵 → U+7D75 絵 +2C00
U+5177 具 → U+9577 長 +4400
U+5178 典 → U+5E78 幸 +0D00
U+518A 冊 → U+7F8A 羊 +2E00
U+51AC 冬 → U+72AC 犬 +2100
U+51B7 冷 → U+8CB7 買 +3B00
U+51E6 処 → U+5DE6 左 +0C00
U+5200 刀 → U+4E00 一 -0400
U+5207 切 → U+4E07 万 -0400
U+520A 刊 → U+4E0A 上 -0400
U+5217 列 → U+6C17 気 +1A00
U+521D 初 → U+671D 朝 +1500
U+5225 別 → U+6625 春 +1400
U+5229 利 → U+5929 天 +0700
U+5236 制 → U+7236 父 +2000
U+5237 刷 → U+7537 男 +2300
U+5238 券 → U+4E38 丸 -0400
U+523B 刻 → U+753B 画 +2300
U+526F 副 → U+606F 息 +0E00
U+5272 割 → U+8272 色 +3000
U+5275 創 → U+7D75 絵 +2B00
U+5287 劇 → U+6587 文 +1300
U+529F 功 → U+539F 原 +0100
U+52A0 加 → U+8CA0 負 +3A00
U+52A9 助 → U+5CA9 岩 +0A00
U+52AA 努 → U+89AA 親 +3700
U+52B9 効 → U+70B9 点 +1E00
U+52C7 勇 → U+8AC7 談 +3800
U+52C9 勉 → U+59C9 姉 +0700
U+52D5 動 → U+4ED5 仕 -0400
U+52DD 勝 → U+5DDD 川 +0B00
U+52E2 勢 → U+77E2 矢 +2500
U+52E4 勤 → U+53E4 古 +0100
U+5305 包 → U+8005 者 +2D00
U+5316 化 → U+5916 外 +0600
U+5317 北 → U+6C17 気 +1900
U+533A 区 → U+753A 町 +2200
U+533B 医 → U+753B 画 +2200
U+5348 午 → U+5148 先 -0200
U+5352 卒 → U+9752 青 +4400
U+5354 協 → U+9854 顔 +4500
U+5357 南 → U+5B57 字 +0800
U+535A 博 → U+9B5A 魚 +4800
U+5370 印 → U+6570 数 +1200
U+5371 危 → U+5C71 山 +0900
U+5375 卵 → U+7D75 絵 +2A00
U+539A 厚 → U+5B9A 定 +0800
U+53B3 厳 → U+8DB3 足 +3A00
U+53C2 参 → U+4FC2 係 -0400
U+53CB 友 → U+7ACB 立 +2700
U+53CD 反 → U+6BCD 母 +1800
U+53CE 収 → U+91CE 野 +3E00
U+53D6 取 → U+4ED6 他 -0500
U+53E5 句 → U+65E5 日 +1200
U+53EF 可 → U+8DEF 路 +3A00
U+53F0 台 → U+58F0 声 +0500
U+53F2 史 → U+96F2 雲 +4300
U+53F8 司 → U+7CF8 糸 +2900
U+5404 各 → U+5104 億 -0300
U+5408 合 → U+6708 月 +1300
U+540E 后 → U+660E 明 +1200
U+5411 向 → U+4F11 休 -0500
U+5426 否 → U+6226 戦 +0E00
U+5438 吸 → U+4E38 丸 -0600
U+544A 告 → U+534A 半 -0100
U+5468 周 → U+5168 全 -0300
U+5473 味 → U+5973 女 +0500
U+547D 命 → U+767D 白 +2200
U+548C 和 → U+4E8C 二 -0600
U+5531 唱 → U+5F31 弱 +0A00
U+554F 問 → U+4F4F 住 -0600
U+5584 善 → U+5F84 径 +0A00
U+55B6 営 → U+5BB6 家 +0600
U+5668 器 → U+5168 全 -0500
U+56E0 因 → U+7AE0 章 +2400
U+56E3 団 → U+53E3 口 -0300
U+56F0 困 → U+58F0 声 +0200
U+56F2 囲 → U+96F2 雲 +4000
U+56F3 図 → U+53F3 右 -0300
U+56FA 固 → U+51FA 出 -0500
U+5727 圧 → U+5927 大 +0200
U+5728 在 → U+6728 木 +1000
U+5730 地 → U+7530 田 +1E00
U+5742 坂 → U+6642 時 +0F00
U+5747 均 → U+5247 則 -0500
U+578B 型 → U+898B 見 +3200
U+57CE 城 → U+91CE 野 +3A00
U+57DF 域 → U+98DF 食 +4100
U+57FA 基 → U+51FA 出 -0600
U+5802 堂 → U+5E02 市 +0600
U+5831 報 → U+5F31 弱 +0700
U+5834 場 → U+6C34 水 +1400
U+5869 塩 → U+6B69 歩 +1300
U+5883 境 → U+5E83 広 +0600
U+5893 墓 → U+9593 間 +3D00
U+5897 増 → U+6797 林 +0F00
U+58F2 売 → U+96F2 雲 +3E00
U+5909 変 → U+4E09 三 -0B00
U+590F 夏 → U+5C0F 小 +0300
U+5922 夢 → U+6F22 漢 +1600
U+5931 失 → U+5F31 弱 +0600
U+594F 奏 → U+4F4F 住 -0A00
U+596E 奮 → U+7F6E 置 +2600
U+597D 好 → U+767D 白 +1D00
U+59B9 妹 → U+70B9 点 +1700
U+59BB 妻 → U+53BB 去 -0600
U+59CB 始 → U+7ACB 立 +2100
U+5A66 婦 → U+5B66 学 +0100
U+5B58 存 → U+5358 単 -0800
U+5B5D 孝 → U+4E5D 九 -0D00
U+5B63 季 → U+6B63 正 +1000
U+5B6B 孫 → U+516B 八 -0A00
U+5B85 宅 → U+5185 内 -0A00
U+5B87 宇 → U+6587 文 +0A00
U+5B88 守 → U+4E88 予 -0D00
U+5B89 安 → U+7389 玉 +1800
U+5B8C 完 → U+4E8C 二 -0D00
U+5B97 宗 → U+6797 林 +0C00
U+5B99 宙 → U+5199 写 -0A00
U+5B9D 宝 → U+8C9D 貝 +3100
U+5B9F 実 → U+539F 原 -0800
U+5BA4 室 → U+4EA4 交 -0D00
U+5BB3 害 → U+8DB3 足 +3200
U+5BB9 容 → U+70B9 点 +1500
U+5BC4 寄 → U+9EC4 黄 +4300
U+5BC6 密 → U+96C6 集 +3B00
U+5BCC 富 → U+91CC 里 +3600
U+5BD2 寒 → U+89D2 角 +2E00
U+5BDF 察 → U+98DF 食 +3D00
U+5BF8 寸 → U+7CF8 糸 +2100
U+5BFA 寺 → U+51FA 出 -0A00
U+5C02 専 → U+5E02 市 +0200
U+5C04 射 → U+5104 億 -0B00
U+5C06 将 → U+5206 分 -0A00
U+5C0A 尊 → U+4E0A 上 -0E00
U+5C0E 導 → U+660E 明 +0A00
U+5C11 少 → U+4F11 休 -0D00
U+5C31 就 → U+5F31 弱 +0300
U+5C3A 尺 → U+753A 町 +1900
U+5C45 居 → U+6D45 浅 +1100
U+5C4A 届 → U+534A 半 -0900
U+5C4B 屋 → U+624B 手 +0600
U+5C55 展 → U+4F55 何 -0D00
U+5C5E 属 → U+805E 聞 +2400
U+5C64 層 → U+8D64 赤 +3100
U+5DDE 州 → U+56DE 回 -0700
U+5DE3 巣 → U+53E3 口 -0A00
U+5DE5 工 → U+65E5 日 +0800
U+5DEE 差 → U+76EE 目 +1900
U+5DF1 己 → U+67F1 柱 +0A00
U+5DFB 巻 → U+96FB 電 +3900
U+5E03 布 → U+4E03 七 -1000
U+5E0C 希 → U+540C 同 -0A00
U+5E2B 師 → U+592B 夫 -0500
U+5E2D 席 → U+4E2D 中 -1000
U+5E2F 帯 → U+6E2F 港 +1000
U+5E30 帰 → U+7530 田 +1700
U+5E33 帳 → U+8033 耳 +2200
U+5E38 常 → U+4E38 丸 -1000
U+5E55 幕 → U+4F55 何 -0F00
U+5E72 干 → U+8272 色 +2400
U+5E73 平 → U+5973 女 -0500
U+5E79 幹 → U+5F79 役 +0100
U+5E7C 幼 → U+547C 呼 -0A00
U+5E81 庁 → U+8981 要 +2B00
U+5E8F 序 → U+798F 福 +1B00
U+5E95 底 → U+6295 投 +0400
U+5E97 店 → U+6797 林 +0900
U+5E9C 府 → U+559C 喜 -0900
U+5EA6 度 → U+9EA6 麦 +4000
U+5EA7 座 → U+8CA7 貧 +2E00
U+5EAD 庭 → U+8AAD 読 +2C00
U+5EB7 康 → U+8CB7 買 +2E00
U+5EF6 延 → U+5CF6 島 -0200
U+5EFA 建 → U+51FA 出 -0D00
U+5F01 弁 → U+4E01 丁 -1100
U+5F0F 式 → U+5C0F 小 -0300
U+5F15 引 → U+5915 夕 -0600
U+5F1F 弟 → U+571F 土 -0800
U+5F37 強 → U+7537 男 +1600
U+5F53 当 → U+4F53 体 -1000
U+5F80 往 → U+9580 門 +3600
U+5F85 待 → U+5185 内 -0E00
U+5F8B 律 → U+898B 見 +2A00
U+5F8C 後 → U+4E8C 二 -1100
U+5F93 従 → U+9593 間 +3600
U+5F97 得 → U+6797 林 +0800
U+5FA9 復 → U+5CA9 岩 -0300
U+5FB3 徳 → U+8DB3 足 +2E00
U+5FC5 必 → U+65C5 旅 +0600
U+5FD7 志 → U+53D7 受 -0C00
U+5FD8 忘 → U+9AD8 高 +3B00
U+5FDC 応 → U+66DC 曜 +0700
U+5FE0 忠 → U+7AE0 章 +1B00
U+5FEB 快 → U+58EB 士 -0700
U+601D 思 → U+671D 朝 +0700
U+6025 急 → U+6625 春 +0600
U+6027 性 → U+5927 大 -0700
U+6069 恩 → U+6B69 歩 +0B00
U+60AA 悪 → U+89AA 親 +2900
U+60C5 情 → U+65C5 旅 +0500
U+60F3 想 → U+53F3 右 -0D00
U+610F 意 → U+5C0F 小 -0500
U+611B 愛 → U+541B 君 -0D00
U+611F 感 → U+571F 土 -0A00
U+614B 態 → U+624B 手 +0100
U+6163 慣 → U+6B63 正 +0A00
U+61B2 憲 → U+60B2 悲 -0100
U+6211 我 → U+4F11 休 -1300
U+6238 戸 → U+4E38 丸 -1400
U+6240 所 → U+5C40 局 -0600
U+624D 才 → U+524D 前 -1000
U+6253 打 → U+4F53 体 -1300
U+6279 批 → U+5F79 役 -0300
U+627F 承 → U+897F 西 +2700
U+6280 技 → U+9580 門 +3300
U+6298 折 → U+5B98 官 -0700
U+62C5 担 → U+65C5 旅 +0300
U+62DB 招 → U+56DB 四 -0C00
U+62DD 拝 → U+5DDD 川 -0500
U+62E1 拡 → U+54E1 員 -0E00
U+62FE 拾 → U+5BFE 対 -0700
U+6301 持 → U+4E01 丁 -1500
U+6307 指 → U+4E07 万 -1500
U+6319 挙 → U+7D19 紙 +1A00
U+6368 捨 → U+5168 全 -1200
U+6388 授 → U+4E88 予 -1500
U+63A1 採 → U+7BA1 管 +1800
U+63A2 探 → U+5BA2 客 -0800
U+63A8 推 → U+98A8 風 +3500
U+63EE 揮 → U+76EE 目 +1300
U+640D 損 → U+540D 名 -1000
U+64CD 操 → U+6BCD 母 +0700
U+652F 支 → U+6E2F 港 +0900
U+6539 改 → U+8239 船 +1D00
U+653E 放 → U+793E 社 +1400
U+6545 故 → U+6D45 浅 +0800
U+6551 救 → U+6751 村 +0200
U+6557 敗 → U+5B57 字 -0A00
U+6563 散 → U+6B63 正 +0600
U+656C 敬 → U+516C 公 -1400
U+6574 整 → U+5E74 年 -0700
U+6575 敵 → U+7D75 絵 +1800
U+6599 料 → U+5199 写 -1400
U+65AD 断 → U+8AAD 読 +2500
U+65B9 方 → U+70B9 点 +0B00
U+65D7 旗 → U+53D7 受 -1200
U+6613 易 → U+5F13 弓 -0700
U+661F 星 → U+571F 土 -0F00
U+6620 映 → U+6B20 欠 +0500
U+6628 昨 → U+6728 木 +0100
U+662D 昭 → U+4E2D 中 -1800
U+6669 晩 → U+6B69 歩 +0500
U+666F 景 → U+606F 息 -0600
U+6674 晴 → U+5E74 年 -0800
U+6696 暖 → U+9996 首 +3300
U+6697 暗 → U+6797 林 +0100
U+66AE 暮 → U+5BAE 宮 -0B00
U+66B4 暴 → U+52B4 労 -1400
U+66F2 曲 → U+96F2 雲 +3000
U+66F8 書 → U+7CF8 糸 +1600
U+6700 最 → U+4E00 一 -1900
U+6709 有 → U+4E09 三 -1900
U+670D 服 → U+540D 名 -1300
U+6717 朗 → U+6C17 気 +0500
U+671B 望 → U+541B 君 -1300
U+671F 期 → U+571F 土 -1000
U+672A 未 → U+592A 太 -0E00
U+672B 末 → U+592B 夫 -0E00
U+672D 札 → U+4E2D 中 -1900
U+673A 机 → U+753A 町 +0E00
U+6750 材 → U+5B50 子 -0C00
U+6761 条 → U+8C61 象 +2500
U+6765 来 → U+5165 入 -1600
U+6771 東 → U+5C71 山 -0B00
U+677E 松 → U+767E 百 +0F00
U+677F 板 → U+897F 西 +2200
U+679A 枚 → U+5B9A 定 -0C00
U+679C 果 → U+559C 喜 -1200
U+679D 枝 → U+8C9D 貝 +2500
U+67FB 査 → U+96FB 電 +2F00
U+6804 栄 → U+5104 億 -1700
U+682A 株 → U+592A 太 -0F00
U+6839 根 → U+8239 船 +1A00
U+683C 格 → U+663C 昼 -0200
U+6848 案 → U+5148 先 -1700
U+685C 桜 → U+4F5C 作 -1900
U+6885 梅 → U+5185 内 -1700
U+68B0 械 → U+65B0 新 -0300
U+68D2 棒 → U+89D2 角 +2100
U+68EE 森 → U+76EE 目 +0E00
U+690D 植 → U+540D 名 -1500
U+691C 検 → U+591C 夜 -1000
U+696D 業 → U+516D 六 -1800
U+6975 極 → U+7D75 絵 +1400
U+697D 楽 → U+767D 白 +0D00
U+69CB 構 → U+7ACB 立 +1100
U+69D8 様 → U+9AD8 高 +3100
U+6A19 標 → U+7D19 紙 +1300
U+6A21 模 → U+6821 校 -0200
U+6A29 権 → U+5929 天 -1100
U+6A2A 横 → U+592A 太 -1100
U+6A39 樹 → U+8239 船 +1800
U+6A4B 橋 → U+624B 手 -0800
U+6A5F 機 → U+675F 束 -0300
U+6B21 次 → U+6821 校 -0300
U+6B32 欲 → U+9032 進 +2500
U+6B4C 歌 → U+884C 行 +1D00
U+6B62 止 → U+5F62 形 -0C00
U+6B66 武 → U+5B66 学 -1000
U+6B6F 歯 → U+606F 息 -0B00
U+6B74 歴 → U+5E74 年 -0D00
U+6B8B 残 → U+898B 見 +1E00
U+6BBA 殺 → U+4EBA 人 -1D00
U+6BCE 毎 → U+91CE 野 +2600
U+6BD2 毒 → U+89D2 角 +1E00
U+6BD4 比 → U+59D4 委 -1200
U+6BDB 毛 → U+56DB 四 -1500
U+6C0F 氏 → U+5C0F 小 -1000
U+6C11 民 → U+4F11 休 -1D00
U+6C37 氷 → U+7537 男 +0900
U+6C38 永 → U+4E38 丸 -1E00
U+6C42 求 → U+6642 時 -0600
U+6C60 池 → U+9060 遠 +2400
U+6C7A 決 → U+7A7A 空 +0E00
U+6C7D 汽 → U+767D 白 +0A00
U+6CB3 河 → U+8DB3 足 +2100
U+6CB9 油 → U+70B9 点 +0400
U+6CBB 治 → U+53BB 去 -1900
U+6CBF 沿 → U+5BBF 宿 -1100
U+6CC9 泉 → U+59C9 姉 -1300
U+6CD5 法 → U+4ED5 仕 -1E00
U+6CE2 波 → U+77E2 矢 +0B00
U+6CE3 泣 → U+53E3 口 -1900
U+6CE8 注 → U+96E8 雨 +2A00
U+6CF3 泳 → U+53F3 右 -1900
U+6D0B 洋 → U+4E0B 下 -1F00
U+6D17 洗 → U+6C17 気 -0100
U+6D3B 活 → U+753B 画 +0800
U+6D3E 派 → U+793E 社 +0C00
U+6D41 流 → U+5341 十 -1A00
U+6D74 浴 → U+5E74 年 -0F00
U+6D77 海 → U+9577 長 +2800
U+6D88 消 → U+4E88 予 -1F00
U+6DB2 液 → U+60B2 悲 -0D00
U+6DF1 深 → U+67F1 柱 -0600
U+6DF7 混 → U+53F7 号 -1A00
U+6E05 清 → U+8005 者 +1200
U+6E08 済 → U+6708 月 -0700
U+6E1B 減 → U+541B 君 -1A00
U+6E29 温 → U+5929 天 -1500
U+6E2C 測 → U+672C 本 -0700
U+6E6F 湯 → U+606F 息 -0E00
U+6E80 満 → U+9580 門 +2700
U+6E96 準 → U+9996 首 +2B00
U+6F01 漁 → U+4E01 丁 -2100
U+6F14 演 → U+6614 昔 -0900
U+6F54 潔 → U+9854 顔 +2900
U+6F6E 潮 → U+7F6E 置 +1000
U+6FC0 激 → U+7BC0 節 +0C00
U+706B 火 → U+516B 八 -1F00
U+706F 灯 → U+606F 息 -1000
U+7070 灰 → U+6570 数 -0B00
U+707D 災 → U+767D 白 +0600
U+70AD 炭 → U+8AAD 読 +1A00
U+7121 無 → U+6821 校 -0900
U+7136 然 → U+7236 父 +0100
U+713C 焼 → U+663C 昼 -0B00
U+719F 熟 → U+539F 原 -1E00
U+71B1 熱 → U+82B1 花 +1100
U+71C3 燃 → U+5FC3 心 -1200
U+7247 片 → U+5247 則 -2000
U+7248 版 → U+5148 先 -2100
U+7267 牧 → U+7167 照 -0100
U+7269 物 → U+6B69 歩 -0700
U+7279 特 → U+5F79 役 -1300
U+72AF 犯 → U+8CAF 貯 +1A00
U+72B6 状 → U+5BB6 家 -1700
U+7387 率 → U+6587 文 -0E00
U+738B 王 → U+898B 見 +1600
U+73ED 班 → U+77ED 短 +0400
U+73FE 現 → U+5BFE 対 -1800
U+7403 球 → U+4E03 七 -2600
U+7406 理 → U+5206 分 -2200
U+751F 生 → U+571F 土 -1E00
U+7528 用 → U+6728 木 -0E00
U+7531 由 → U+5F31 弱 -1600
U+7533 申 → U+8033 耳 +0B00
U+754C 界 → U+884C 行 +1300
U+7551 畑 → U+6751 村 -0E00
U+7559 留 → U+6559 教 -1000
U+7565 略 → U+5165 入 -2400
U+7570 異 → U+6570 数 -1000
U+7591 疑 → U+6691 暑 -0F00
U+75C5 病 → U+65C5 旅 -1000
U+75DB 痛 → U+56DB 四 -1F00
U+767A 発 → U+7A7A 空 +0400
U+767B 登 → U+6B7B 死 -0B00
U+7684 的 → U+5F84 径 -1700
U+7687 皇 → U+6587 文 -1100
U+76AE 皮 → U+5BAE 宮 -1B00
U+76BF 皿 → U+5BBF 宿 -1B00
U+76CA 益 → U+8ECA 車 +1800
U+76DB 盛 → U+56DB 四 -2000
U+76DF 盟 → U+98DF 食 +2200
U+76F8 相 → U+7CF8 糸 +0600
U+7701 省 → U+4E01 丁 -2900
U+770B 看 → U+4E0B 下 -2900
U+770C 県 → U+540C 同 -2300
U+771F 真 → U+571F 土 -2000
U+773C 眼 → U+663C 昼 -1100
U+7740 着 → U+5C40 局 -1B00
U+77E5 知 → U+65E5 日 -1200
U+77F3 石 → U+53F3 右 -2400
U+7802 砂 → U+5E02 市 -1A00
U+7814 研 → U+6614 昔 -1200
U+7834 破 → U+6C34 水 -0C00
U+78BA 確 → U+4EBA 人 -2A00
U+78C1 磁 → U+54C1 品 -2400
U+793A 示 → U+753A 町 -0400
U+793C 礼 → U+663C 昼 -1300
U+7956 祖 → U+6E56 湖 -0B00
U+795D 祝 → U+4E5D 九 -2B00
U+795E 神 → U+805E 聞 +0700
U+7968 票 → U+5168 全 -2800
U+796D 祭 → U+516D 六 -2800
U+7981 禁 → U+8981 要 +1000
U+79C1 私 → U+54C1 品 -2500
U+79CB 秋 → U+7ACB 立 +0100
U+79D1 科 → U+91D1 金 +1800
U+79D2 秒 → U+89D2 角 +1000
U+79D8 秘 → U+9AD8 高 +2100
U+79FB 移 → U+96FB 電 +1D00
U+7A0B 程 → U+4E0B 下 -2C00
U+7A0E 税 → U+660E 明 -1400
U+7A2E 種 → U+592E 央 -2100
U+7A40 穀 → U+5C40 局 -1E00
U+7A4D 積 → U+524D 前 -2800
U+7A74 穴 → U+5E74 年 -1C00
U+7A93 窓 → U+9593 間 +1B00
U+7AE5 童 → U+65E5 日 -1500
U+7AF6 競 → U+5CF6 島 -1E00
U+7B11 笑 → U+4F11 休 -2C00
U+7B1B 笛 → U+541B 君 -2700
U+7B2C 第 → U+672C 本 -1400
U+7B46 筆 → U+5546 商 -2600
U+7B49 等 → U+8349 草 +0800
U+7B4B 筋 → U+624B 手 -1900
U+7B54 答 → U+9854 顔 +1D00
U+7B56 策 → U+6E56 湖 -0D00
U+7B97 算 → U+6797 林 -1400
U+7BB1 箱 → U+82B1 花 +0700
U+7BC9 築 → U+59C9 姉 -2200
U+7C21 簡 → U+6821 校 -1400
U+7C73 米 → U+5973 女 -2300
U+7C89 粉 → U+7389 玉 -0900
U+7CD6 糖 → U+4ED6 他 -2E00
U+7CFB 系 → U+96FB 電 +1A00
U+7D00 紀 → U+4E00 一 -2F00
U+7D04 約 → U+5104 億 -2C00
U+7D05 紅 → U+8005 者 +0300
U+7D0D 納 → U+540D 名 -2900
U+7D14 純 → U+6614 昔 -1700
U+7D1A 級 → U+591A 多 -2400
U+7D20 素 → U+6B20 欠 -1200
U+7D30 細 → U+7530 田 -0800
U+7D42 終 → U+6642 時 -1700
U+7D44 組 → U+5144 兄 -2C00
U+7D4C 経 → U+884C 行 +0B00
U+7D50 結 → U+5B50 子 -2200
U+7D66 給 → U+5B66 学 -2200
U+7D71 統 → U+5C71 山 -2100
U+7D76 絶 → U+7A76 究 -0300
U+7D79 絹 → U+5F79 役 -1E00
U+7D9A 続 → U+5B9A 定 -2200
U+7DBF 綿 → U+5BBF 宿 -2200
U+7DCF 総 → U+65CF 族 -1800
U+7DD1 緑 → U+91D1 金 +1400
U+7DE8 編 → U+96E8 雨 +1900
U+7DF4 練 → U+76F4 直 -0700
U+7E26 縦 → U+6226 戦 -1C00
U+7E2E 縮 → U+592E 央 -2500
U+7E3E 績 → U+793E 社 -0500
U+7E54 織 → U+9854 顔 +1A00
U+7F6A 罪 → U+756A 番 -0A00
U+7F72 署 → U+8272 色 +0300
U+7FA4 群 → U+4EA4 交 -3100
U+7FA9 義 → U+5CA9 岩 -2300
U+7FCC 翌 → U+91CC 里 +1200
U+7FD2 習 → U+89D2 角 +0A00
U+8001 老 → U+4E01 丁 -3200
U+8003 考 → U+4E03 七 -3200
U+8015 耕 → U+5915 夕 -2700
U+8056 聖 → U+6E56 湖 -1200
U+8077 職 → U+9577 長 +1500
U+8089 肉 → U+7389 玉 -0D00
U+80A5 肥 → U+63A5 接 -1D00
U+80B2 育 → U+60B2 悲 -2000
U+80BA 肺 → U+4EBA 人 -3200
U+80C3 胃 → U+5FC3 心 -2100
U+80CC 背 → U+91CC 里 +1100
U+80F8 胸 → U+7CF8 糸 -0400
U+80FD 能 → U+56FD 国 -2A00
U+8108 脈 → U+6708 月 -1A00
U+8133 脳 → U+8033 耳 -0100
U+8178 腸 → U+5E78 幸 -2300
U+8179 腹 → U+5F79 役 -2200
U+81D3 臓 → U+67D3 染 -1A00
U+81E3 臣 → U+53E3 口 -2E00
U+81E8 臨 → U+96E8 雨 +1500
U+81F3 至 → U+53F3 右 -2E00
U+8208 興 → U+6708 月 -1B00
U+820C 舌 → U+540C 同 -2E00
U+820E 舎 → U+660E 明 -1C00
U+822A 航 → U+592A 太 -2900
U+826F 良 → U+606F 息 -2200
U+82B8 芸 → U+5CB8 岸 -2600
U+82BD 芽 → U+7FBD 羽 -0300
U+82E5 若 → U+65E5 日 -1D00
U+82E6 苦 → U+5DE6 左 -2500
U+82F1 英 → U+67F1 柱 -1B00
U+8336 茶 → U+7236 父 -1100
U+8377 荷 → U+9577 長 +1200
U+83DC 菜 → U+66DC 曜 -1D00
U+8449 葉 → U+8349 草 -0100
U+8457 著 → U+5B57 字 -2900
U+84B8 蒸 → U+5CB8 岸 -2800
U+8535 蔵 → U+5F35 張 -2600
U+85AC 薬 → U+72AC 犬 -1300
U+866B 虫 → U+516B 八 -3500
U+8695 蚕 → U+6295 投 -2400
U+8840 血 → U+5C40 局 -2C00
U+8846 衆 → U+5546 商 -3300
U+8853 術 → U+4F53 体 -3900
U+8857 街 → U+5B57 字 -2D00
U+885B 衛 → U+725B 牛 -1600
U+8863 衣 → U+6B63 正 -1D00
U+8868 表 → U+5168 全 -3700
U+88C1 裁 → U+54C1 品 -3400
U+88C5 装 → U+65C5 旅 -2300
U+88CF 裏 → U+65CF 族 -2300
U+88DC 補 → U+66DC 曜 -2200
U+88FD 製 → U+56FD 国 -3200
U+8907 複 → U+4E07 万 -3B00
U+898F 規 → U+798F 福 -1000
U+8996 視 → U+9996 首 +1000
U+899A 覚 → U+5B9A 定 -2E00
U+89A7 覧 → U+8CA7 貧 +0300
U+89B3 観 → U+8DB3 足 +0400
U+89E3 解 → U+53E3 口 -3600
U+8A00 言 → U+4E00 一 -3C00
U+8A08 計 → U+6708 月 -2300
U+8A0E 討 → U+660E 明 -2400
U+8A13 訓 → U+5F13 弓 -2B00
U+8A2A 訪 → U+592A 太 -3100
U+8A2D 設 → U+4E2D 中 -3C00
U+8A31 許 → U+5F31 弱 -2B00
U+8A33 訳 → U+8033 耳 -0A00
U+8A3C 証 → U+663C 昼 -2400
U+8A55 評 → U+4F55 何 -3B00
U+8A5E 詞 → U+805E 聞 -0A00
U+8A66 試 → U+5B66 学 -2F00
U+8A69 詩 → U+6B69 歩 -1F00
U+8A71 話 → U+5C71 山 -2E00
U+8A8C 誌 → U+4E8C 二 -3C00
U+8A8D 認 → U+518D 再 -3900
U+8A95 誕 → U+6295 投 -2800
U+8AA0 誠 → U+8CA0 負 +0200
U+8AA4 誤 → U+4EA4 交 -3C00
U+8AAC 説 → U+72AC 犬 -1800
U+8AB2 課 → U+60B2 悲 -2A00
U+8ABF 調 → U+5BBF 宿 -2F00
U+8AD6 論 → U+4ED6 他 -3C00
U+8AF8 諸 → U+7CF8 糸 -0E00
U+8B1B 講 → U+541B 君 -3700
U+8B1D 謝 → U+671D 朝 -2400
U+8B58 識 → U+5358 単 -3800
U+8B66 警 → U+5B66 学 -3000
U+8B70 議 → U+6570 数 -2600
U+8B77 護 → U+9577 長 +0A00
U+8C37 谷 → U+7537 男 -1700
U+8C46 豆 → U+5546 商 -3700
U+8C4A 豊 → U+534A 半 -3900
U+8CA1 財 → U+7BA1 管 -1100
U+8CA8 貨 → U+98A8 風 +0C00
U+8CAC 責 → U+72AC 犬 -1A00
U+8CB4 貴 → U+52B4 労 -3A00
U+8CB8 貸 → U+5CB8 岸 -3000
U+8CBB 費 → U+53BB 去 -3900
U+8CBF 貿 → U+5BBF 宿 -3100
U+8CC0 賀 → U+7BC0 節 -1100
U+8CC3 賃 → U+5FC3 心 -2D00
U+8CC7 資 → U+8AC7 談 -0200
U+8CDB 賛 → U+56DB 四 -3600
U+8CDE 賞 → U+56DE 回 -3600
U+8CEA 質 → U+81EA 自 -0B00
U+8D70 走 → U+6570 数 -2800
U+8D77 起 → U+9577 長 +0800
U+8EAB 身 → U+5EAB 庫 -3000
U+8ECD 軍 → U+6BCD 母 -2300
U+8EE2 転 → U+77E2 矢 -1700
U+8EFD 軽 → U+56FD 国 -3800
U+8F2A 輪 → U+592A 太 -3600
U+8F38 輸 → U+4E38 丸 -4100
U+8F9E 辞 → U+8A9E 語 -0500
U+8FB2 農 → U+60B2 悲 -2F00
U+8FBA 辺 → U+4EBA 人 -4100
U+8FD1 近 → U+91D1 金 +0200
U+8FD4 返 → U+59D4 委 -3600
U+8FF0 述 → U+58F0 声 -3700
U+8FF7 迷 → U+53F7 号 -3C00
U+8FFD 追 → U+56FD 国 -3900
U+9000 退 → U+4E00 一 -4200
U+9001 送 → U+4E01 丁 -4200
U+9006 逆 → U+5206 分 -3E00
U+901A 通 → U+591A 多 -3700
U+901F 速 → U+571F 土 -3900
U+9020 造 → U+6B20 欠 -2500
U+9023 連 → U+7523 産 -1B00
U+9031 週 → U+5F31 弱 -3100
U+904A 遊 → U+534A 半 -3D00
U+904B 運 → U+624B 手 -2E00
U+904E 過 → U+4F4E 低 -4100
U+9053 道 → U+4F53 体 -4100
U+9054 達 → U+9854 顔 +0800
U+9069 適 → U+6B69 歩 -2500
U+9078 選 → U+5E78 幸 -3200
U+907A 遺 → U+7A7A 空 -1600
U+90E1 郡 → U+54E1 員 -3C00
U+90E8 部 → U+96E8 雨 +0600
U+90F5 郵 → U+5FF5 念 -3100
U+90F7 郷 → U+53F7 号 -3D00
U+90FD 都 → U+56FD 国 -3A00
U+914D 配 → U+524D 前 -3F00
U+9152 酒 → U+9752 青 +0600
U+9178 酸 → U+5E78 幸 -3300
U+91CD 重 → U+6BCD 母 -2600
U+91CF 量 → U+65CF 族 -2C00
U+91DD 針 → U+5DDD 川 -3400
U+9244 鉄 → U+5144 兄 -4100
U+9271 鉱 → U+5C71 山 -3600
U+9280 銀 → U+9580 門 +0300
U+9285 銅 → U+5185 内 -4100
U+92AD 銭 → U+8AAD 読 -0800
U+92FC 鋼 → U+98FC 飼 +0600
U+9332 録 → U+9032 進 -0300
U+93E1 鏡 → U+54E1 員 -3F00
U+9589 閉 → U+7389 玉 -2200
U+958B 開 → U+898B 見 -0C00
U+95A2 関 → U+5BA2 客 -3A00
U+95A3 閣 → U+5BA3 宣 -3A00
U+9632 防 → U+9032 進 -0600
U+964D 降 → U+524D 前 -4400
U+9650 限 → U+5B50 子 -3B00
U+965B 陛 → U+725B 牛 -2400
U+9662 院 → U+5F62 形 -3700
U+9664 除 → U+8D64 赤 -0900
U+9678 陸 → U+5E78 幸 -3800
U+967A 険 → U+7A7A 空 -1C00
U+967D 陽 → U+767D 白 -2000
U+968A 隊 → U+7F8A 羊 -1700
U+968E 階 → U+7F8E 美 -1700
U+969B 際 → U+529B 力 -4400
U+969C 障 → U+559C 喜 -4100
U+96D1 雑 → U+91D1 金 -0500
U+96E3 難 → U+53E3 口 -4300
U+96EA 雪 → U+81EA 自 -1500
U+9759 静 → U+6559 教 -3200
U+975E 非 → U+805E 聞 -1700
U+9762 面 → U+5F62 形 -3800
U+9769 革 → U+6B69 歩 -2C00
U+97F3 音 → U+53F3 右 -4400
U+9802 頂 → U+5E02 市 -3A00
U+9806 順 → U+5206 分 -4600
U+9810 預 → U+6210 成 -3600
U+9818 領 → U+8A18 記 -0E00
U+982D 頭 → U+4E2D 中 -4A00
U+984C 題 → U+884C 行 -1000
U+984D 額 → U+524D 前 -4600
U+9858 願 → U+5358 単 -4500
U+985E 類 → U+805E 聞 -1800
U+98DB 飛 → U+56DB 四 -4200
U+98EF 飯 → U+8DEF 路 -0B00
U+98F2 飲 → U+96F2 雲 -0200
U+990A 養 → U+4E0A 上 -4B00
U+9928 館 → U+6728 木 -3200
U+99AC 馬 → U+72AC 犬 -2700
U+99C5 駅 → U+65C5 旅 -3400
U+9A13 験 → U+5F13 弓 -3B00
U+9AA8 骨 → U+98A8 風 -0200
U+9CE5 鳥 → U+65E5 日 -3700
U+9CF4 鳴 → U+76F4 直 -2600
U+9ED2 黒 → U+89D2 角 -1500
U+9F3B 鼻 → U+753B 画 -2A00

VG --PerfektesChaos 10:37, 21. Sep. 2016 (CEST)

Nein, sprachlich gibt es keinen Grund, da die vertauschten Zeichen nicht miteinander verwandt sind.

Ich habe alle Zeichen nochmal nach den unteren 8 Bit gruppiert und dabei hat sich herausgestellt, das Äquivalenzklassen gibt, d.h. ein Zeichen U+xxyy wird immer auf das unten aufgeführte Zeichen der Äquivalenzklasse yy (fett markiert) abgebildet.

U+4E00 一
U+4E01 丁
U+5E02 市
U+4E03 七
U+5104 億
U+8005 者
U+5206 分
U+4E07 万
U+6708 月
U+4E09 三
U+4E0A 上
U+4E0B 下
U+540C 同
U+540D 名
U+660E 明
U+5C0F 小
U+6210 成
U+4F11 休
U+5F13 弓
U+6614 昔
U+5915 夕
U+5916 外
U+6C17 気
U+8A18 記
U+7D19 紙
U+591A 多
U+541B 君
U+591C 夜
U+671D 朝
U+571F 土
U+6B20 欠
U+6821 校
U+6F22 漢
U+7523 産
U+5224 判
U+6625 春
U+6226 戦
U+5927 大
U+6728 木
U+5929 天
U+592A 太
U+592B 夫
U+672C 本
U+4E2D 中
U+592E 央
U+6E2F 港
U+7530 田
U+5F31 弱
U+9032 進
U+8033 耳
U+6C34 水
U+5F35 張
U+7236 父
U+7537 男
U+4E38 丸
U+8239 船
U+753A 町
U+753B 画
U+663C 昼
U+793E 社
U+5C40 局
U+5341 十
U+6642 時
U+5343 千
U+5144 兄
U+6D45 浅
U+5546 商
U+5247 則
U+5148 先
U+8349 草
U+534A 半
U+624B 手
U+884C 行
U+524D 前
U+4F4E 低
U+4F4F 住
U+5B50 子
U+6751 村
U+9752 青
U+4F53 体
U+9854 顔
U+4F55 何
U+6E56 湖
U+5B57 字
U+5358 単
U+6559 教
U+9B5A 魚
U+725B 牛
U+4F5C 作
U+4E5D 九
U+805E 聞
U+675F 束
U+9060 遠
U+8C61 象
U+5F62 形
U+6B63 正
U+8D64 赤
U+5165 入
U+5B66 学
U+7167 照
U+5168 全
U+6B69 歩
U+756A 番
U+516B 八
U+516C 公
U+516D 六
U+7F6E 置
U+606F 息
U+6570 数
U+5C71 山
U+8272 色
U+5973 女
U+5E74 年
U+7D75 絵
U+7A76 究
U+9577 長
U+5E78 幸
U+5F79 役
U+7A7A 空
U+6B7B 死
U+547C 呼
U+767D 白
U+767E 百
U+897F 西
U+9580 門
U+8981 要
U+5E83 広
U+5F84 径
U+5185 内
U+6587 文
U+4E88 予
U+7389 玉
U+7F8A 羊
U+898B 見
U+4E8C 二
U+518D 再
U+7F8E 美
U+798F 福
U+6691 暑
U+9593 間
U+6295 投
U+9996 首
U+6797 林
U+5B98 官
U+5199 写
U+5B9A 定
U+529B 力
U+559C 喜
U+8C9D 貝
U+8A9E 語
U+539F 原
U+8CA0 負
U+7BA1 管
U+5BA2 客
U+5BA3 宣
U+4EA4 交
U+63A5 接
U+9EA6 麦
U+8CA7 貧
U+98A8 風
U+5CA9 岩
U+89AA 親
U+5EAB 庫
U+72AC 犬
U+8AAD 読
U+5BAE 宮
U+8CAF 貯
U+65B0 新
U+82B1 花
U+60B2 悲
U+8DB3 足
U+52B4 労
U+5BB6 家
U+8CB7 買
U+5CB8 岸
U+70B9 点
U+4EBA 人
U+53BB 去
U+7FBD 羽
U+5BBF 宿
U+7BC0 節
U+54C1 品
U+4FC2 係
U+5FC3 心
U+9EC4 黄
U+65C5 旅
U+96C6 集
U+8AC7 談
U+59C9 姉
U+8ECA 車
U+7ACB 立
U+91CC 里
U+6BCD 母
U+91CE 野
U+65CF 族
U+91D1 金
U+89D2 角
U+67D3 染
U+59D4 委
U+4ED5 仕
U+4ED6 他
U+53D7 受
U+9AD8 高
U+56DB 四
U+66DC 曜
U+5DDD 川
U+56DE 回
U+98DF 食
U+7AE0 章
U+54E1 員
U+77E2 矢
U+53E3 口
U+53E4 古
U+65E5 日
U+5DE6 左
U+96E8 雨
U+81EA 自
U+58EB 士
U+77ED 短
U+76EE 目
U+8DEF 路
U+58F0 声
U+67F1 柱
U+96F2 雲
U+53F3 右
U+76F4 直
U+5FF5 念
U+5CF6 島
U+53F7 号
U+7CF8 糸
U+51FA 出
U+96FB 電
U+98FC 飼
U+56FD 国
U+5BFE 対

Ich hatte mir das im VE auf Safari und Chrome unter iOS, sowie IE/Edge/Chrome unter Win10 angeschaut. In Normalansicht (Mobile de.m.wikipedia.org und Desktop de.wikipedia.org) und Quelltextansicht, sowie der Wikipedia-App unter iOS gibt es keine Fehler. Android-Geräte habe ich nicht und kann es mir deswegen darunter nicht anschauen.

Die Effekte unter unterschiedlichen lang-Attributen werde ich mir noch anschauen. --Mps 、かみまみた^Disk. 23:39, 21. Sep. 2016 (CEST)

Ich weiß nicht – ich fürchte, deine neue Liste berücksichtigt nicht, was ich zuvor schon geschrieben hatte:

Verschiebungen in vollständigen Blöcken zu 256.
Heißt: Vom einen zum anderen werden ganzzahlige Vielfache von 256₁₀ = 100₁₆ addiert oder subtrahiert.
Der Umfang der Verschiebung ist jedoch völlig planlos.
Heißt: Die hinteren 8 Bit bleiben immer erhalten, während die signifikanteren 8 Bit vorne wahllos ausgewürfelt werden.
Oben stehen die +/- der jeweiligen Verschiebung.

Ich warte noch den Einfluss des lang="ja" usw. ab, um vollständiges Material zu haben, einen Fehlerreport auf Phabricator schreiben zu können und das Ursachenfeld bestmöglich eingekreist zu haben.

VG --PerfektesChaos 16:59, 22. Sep. 2016 (CEST)

Meine neue Liste zeigt genau das gleiche, nur eben die 100₁₆-Restäquivalenzklassen. Das heißt die signifikanten vorderen 8 Bit sind nicht völlig planlos, sondern pro Restklasse (= hintere 8 Bit) immer die gleichen, wodurch es nach einer Verschiebung um 100₁₆ aussieht. Wenn man sich bei deiner Liste (meiner alten Liste) auf der linken Seite des Pfeils nur die letzten 8 Bit anschaut, sieht man das bei allen Zeichen mit den gleichen hinteren 8 Bit haben immer das gleiche falsche Zeichen erzeugt wird bzw. für alle Eingabewerte uin gilt uout = meineNeueListeMitFettgedrucktemAlsIndex[uin mod 100₁₆] . --Mps 、かみまみた^Disk. 20:22, 22. Sep. 2016 (CEST)

Ah, so, jetzt habe auch ich das verstanden. Schick.
Sortiert man das dann nach dem vorderen Oktett, dann ergibt sich eine Häufung bei einigen Werten, während dementsprechend andere in den 256 nie auftreten:
- 4E 51 53 59 5B 5F 67 sind in mehr als sechs Resultaten vertreten.
- Leider ist keine Formel ersichtlich, nach der das vordere Oktett aus dem hinteren errechnet werden könnte; das wäre das Sahnehäubchen bei der Identifikation des wild gewordenen Algorithmus.
Es gibt ja in dem Range von 20.000 Zeichen auch einige, die heil bleiben; sonst wäre der Aufschrei seitens der Japaner größer und lauter.
- Wann warum welches hi ist und wann nicht sehe ich nicht, ist auch egal.
- Bislang finde ich keine offenen Bugs dazu im Phabricator.
Irgendeine Funktion schaltet sich unter bestimmten Bedingungen ein; keine Idee, welche wann und warum. Oberhalb FFFF gibt es diverse Probleme; drunter ist heutzutage eigentlich alles unauffällig.
Nun fehlt nur noch die Info, ob und wie lang="ja" und lang="ja-a" die Chose beeinflussen.

--PerfektesChaos 12:50, 23. Sep. 2016 (CEST)

Verwendung der Vorlage für englischsprachige Eigennamen?

Hallo, im Zuge der Quelltextbearbeitung von Government House (Neuseeland) ist mir aufgefallen, dass dort dutzendfach die Lang-Vorlage für Eigennamen verwendet wird. Meines Erachtens nicht sinnvoll, da kein wirklicher Vorteil, dafür wird aber der Quelltext für automatische Bot-Läufe fast unleserlich und die Editier-Schwelle für Neulinge angehoben. Gibt es da Richtlinine oder Empfehlungen, oder zumindest Meinungen? Gruß --Invisigoth67 (Disk.) 20:43, 14. Jan. 2017 (CET)

„Neuseeland“ ist das richtige Stichwort; anhand deiner Anfrage hätte es des Klammerlemma nicht bedurft, und ich hätte dir auch so sagen können, das dieses Government House in Neuseeland liegen müsse.

Es gibt dort einen Benutzer, der alle fraglichen Artikel der Region als Hauptautor bearbeitet und exzessiv jeden englischsprachigen Terminus in die Vorlage einschließt. Aus keinem anderen Themenbereich wäre mir das bekannt; allenfalls mal bei einem vereinzelten Artikel.

Regeln oder Richtlinien gibt es keine.

Zumindest was Washington und New York angeht, sind derartige Sequenzen sowohl Screenreadern als auch deutschen Rechtschreibprogrammen als englischsprachig bekannt, und die Verwendung der Vorlage ist überflüssig.

VG --PerfektesChaos 20:51, 14. Jan. 2017 (CET)

Danke für Deine Antwort. Offenbar ein Mehr an Barrierefreiheit für Screenreader und ein Weniger für Quelltextanalysebots. Wie ich gesehen habe, wurde der Benutzer auch schon mindestens einmal auf seine Verwendung der Vorlage eher erfolglos angesprochen. Also diesbezüglich Neuseeland wohl einfach umschiffen und ggf. Kurs auf andere Insellösungen nehmen. ;-) --Invisigoth67 (Disk.) 18:13, 16. Jan. 2017 (CET)

Leider hat der besagte Benutzer in der Zwischenzeit schon in zahlreichen anderen Artikeln den Quellcode mit tausenden überflüssigen Lang-Vorlage zugemüllt. Der Quelltext wird so total unpflegbar. Ich denke dies kann nicht der Zweck dieser Vorlage sein. Für die Screenreader muss definitiv eine bessere Lösung gefunden werden als diese Vorlage. Ich werde WP:VM machen müssen wenn dies so weiter geht. Könnte man mal irgend ein Bot losschicken, der all diese unnötigen Vorlageneinbindungen wieder entfernt? --Thomei08 16:19, 11. Sep. 2017 (CEST)

Text mit Sprachcode `grc-Latn` wird ungewollt kursiv gedruckt

Hallo!

Wenn ich mit {{lang|grc-Latn|archē}} ein altgriechisches Wort in lateinischer Schrift wiedergebe, dann wird es automatisch kursiv gesetzt. Das ist aber nicht das erwartbare Verhalten. Vergleiche hierzu: Das englische Wort in {{lang|en|principle}} wird auch nicht kursiv gesetzt. Ich gebe ja Parameter 2 „Textpassage“ an, nicht Parameter 3 „Umschrift“, dessen Inhalt dokumentiertermaßen kursiv gesetzt werden würde. Das ist erstens ein Problem, weil es nicht zu erwarten ist, zweitens weil die Vorlage deshalb an Nützlichkeit einbüßt: Ich kann nicht mehr das fettgedruckte Lemma mit {{lang|grc-Latn|…}} auszeichnen, weil es dann außerdem kursiv gemacht werden würde.

Wäre es möglich, das zu beheben?

Liebe Grüße
Gorlingor (Diskussion) 13:24, 18. Jun. 2017 (CEST)

Es wird ja auch eindeutig in der Dokumentation behauptet: „Die Vorlage selbst hat keinen direkten visuellen Effekt, sie stellt lediglich Metainformationen bereit.“ --Gorlingor (Diskussion) 13:43, 18. Jun. 2017 (CEST)

Wenn du explizit die Verschriftung Latn auf eine (nichtlateinische) Schrift angibst, dann wird davon ausgegangen, dass du die Transkription (usw.) einer vorangehenden nichtlateinischen Textpassage meist. Und dies ist per WP:FWF kursiv zu schreiben.

Die lose Angabe von grc-Latn bringt relativ wenig Erkenntnisgewinn, und hilft keiner Software, damit irgendwas zu machen. Gedacht ist das so, dass du zunächst das altgriechische Wort polytonisch angibst und anschließend die Transkription. Nur um ein Lemma zu fetten bedarfst du keiner Hinweise. Wir setzen bei weitem nicht jede irgendwo mal auftretende englische Phrase, jedes New York und jedes Birmingham und Loire in eine Sprachvorlage.

Dass das keine optische Veränderung auslösen würde, ist übrigens immer schon falsch gewesen und heutzutage erst recht: Durch Webfonts, früher CSS, soll ja gerade eine andere Darstellung bewirkt werden, wo dies in einschlägigen Schriften/Sprachen konfiguriert ist.

VG --PerfektesChaos 14:55, 18. Jun. 2017 (CEST)

„Wenn du explizit die Verschriftung Latn auf eine (nichtlateinische) Schrift angibst, dann wird davon ausgegangen, dass du die Transkription (usw.) einer vorangehenden nichtlateinischen Textpassage meist. Und dies ist per WP:FWF kursiv zu schreiben.“

Es ist aber nicht die Umschrift einer vorangehenden nichtlateinischen Textpassage. Erstens würde ich sonst wohl Parameter 2 (Textpassage) mit Parameter 3 (Umschrift) verwenden. Zweitens würde ich sowieso nicht wollen, dass eine Vorlage meint, „clever“ sein zu müssen und undokumentiert irgendwelche Auszeichnungen vorzunehmen. Das verstößt gegen das principle of least astonishment
und macht den Code unnötig komplexer.

„Die lose Angabe von grc-Latn bringt relativ wenig Erkenntnisgewinn, und hilft keiner Software, damit irgendwas zu machen.“

Was daran ist das Argument für den (undokumentierten) Sonderfall, dass Latn-Text in Parameter 2 kursiv gesetzt wird?

„Dass das keine optische Veränderung auslösen würde, ist übrigens immer schon falsch gewesen und heutzutage erst recht: Durch Webfonts […]“

Die Doku spricht davon, dass ein „direkter visueller Effekt“ unterbleibt. Wenn der Client fremdsprachigen Text anders rendert, dann wird das „indirekt“ aus den Metainformationen gezogen. Hier wird aber „direkt“ der Text kursiv gesetzt. --Gorlingor (Diskussion) 15:29, 18. Jun. 2017 (CEST)

Lass es doch einfach bleiben; du hilfst niemandem damit und machst nur den Quelltext komplizierter.

Es ist schlicht nicht erwünscht und bringt keinerlei Verbesserung, jeden Giovanni, Heather und José in die lang-Vorlage einzuschließen; dazu war die auch noch nie gedacht gewesen und wurde über ein Jahrzehnt nur sparsam verwendet.

Wenn du es unbedingt kompliziert haben willst, dann kannst du den bislang nicht in der Doku gelisteten style-Parameter dranhängen:
|style=font-style:normal

VG --PerfektesChaos 15:38, 18. Jun. 2017 (CEST)

Warum reagierst Du so gereizt? Und was soll dieses Strohmann-Argument mit den Vornamen? „archē“ oder „logos“ sind nunmal eindeutig Wörter einer anderen Sprache. Sie werden nicht nur nicht deutsch flektiert, sondern sogar kleingeschrieben, obwohl es Substantive sind. --Gorlingor (Diskussion) 15:48, 18. Jun. 2017 (CEST)

Fremdsprachige Lemmata und interne Links

Es gibt ja auch in der deutschsprachigen Wikipedia Artikel, die ein fremdsprachiges Lemma haben, beispielsweise Filmtitel oder ausländische Organisationen, für die es keinen offiziellen deutschen Namen gibt. Ein einfaches Beispiel aus dem Englischen wäre der Film The King’s Speech.

Alle Gründe, die am Anfang der Vorlagendokumentation für den Gebrauch der Vorlage:lang genannt sind, treffen meines Erachtens auch auf das Artikellemma zu. Aber wie läßt sich das praktisch umsetzen, also wie läßt sich ein Artikel mit korrekt ausgezeichnetem Lemma erstellen? Als anonymer Nutzer würde ich den Artikel English example lemma erstellen, indem ich die Suche Special:Search?search=English+example+lemma aufrufe und dann auf "Quelltext Editor" klicke, aber wie kann ich dabei die Sprache korrekt auszeichnen? Und ist es für angemeldete Nutzer möglich, fehlende Sprachauszeichnungen nachträglich hinzuzufügen?

Und gleich noch eine zweite Frage: Wenn ich auf einen Artikel mit fremdsprachigem Lemma verlinke, wie lautet die korrekte Syntax? Einfach [[English example lemma]] (d.h. die Sprache des Links wird anhand der Auszeichung der verlinkten Seite automatisch erkannt) oder [[{{lang|en|English example lemma}}]] oder {{lang|en|[[English example lemma]]}}? --77.189.132.196 20:54, 22. Okt. 2017 (CEST)

Letztgenannte Frage zuerst: Aus Wiki-taktischen und pflegerischen Gründen ist in diesem Fall die zweite von dir benannte Form zu bevorzugen; die erste geht nicht, denn dann wäre die gesamte HTML-Syntax Teil des Lemmas und du müsstest das Lemma als verlinkte Seite ein zweites Mal aufführen.

Den Teil davor habe ich nicht verstanden. Das Lemma weiß nicht, dass es in irgendeiner Sprache oder Schrift notiert ist.

Im H:SEITENTITEL könntet du aber wohl für die Darstellung des Artikels die Sprache der Überschrift angeben; habe ich aber noch nie gesehen und wüsste auch nicht, wozu das gut sein soll.

VG --PerfektesChaos 21:16, 22. Okt. 2017 (CEST)

Ich bin im Internet nur mittelmäßig bewandert, daher mag jemandem mit mehr Wissen ein Teil meiner Frage als unlogisch oder die Antworten offensichtlich erscheinen. Um zunächst auf Deine Frage einzugehen, warum ich die Sprache der Überschrift angeben möchte. Für mich persönlich ist der wichtigste Grund: Damit sehbehinderte Menschen auch die Überschrift richtig vorgelesen bekommen. Es ist sicherlich ein langfristiges Ziel und niemals vollkommen zu erreichen, aber idealerweise stehen eines Tages sämtliche Inhalte aus Wikipedia allen Menschen auf der Welt uneingeschränkt zur Verfügung. Um das zu erreichen, müssen einzelne Nutzer damit anfangen zumindest einmal zu versuchen Inhalte barrierefrei zu gestalten, siehe WP:Barrierefreiheit#Kennzeichnung_fremdsprachiger_Inhalte.

Der von dir verlinkten Seite entnehme ich, daß die Überschrift nachträglich im Wikitext mit {{DISPLAYTITLE:...}} beeinflußt werden kann. Ich habe es mal nach dem Prinzip {{DISPLAYTITLE:{{lang|en|English example lemma}}}} beim Artikel The King’s Speech ausprobiert. Das ergibt im HTML-Quelltext einen header "h1" mit "lang=de" und einem eingebetteten "span" mit "lang=en", die Überschrift sollte also zumindest korrekt vorgelesen werden. Wenn das die beste Variante ist, könnte man das als Beispiel in die Doku von Vorlage:lang aufnehmen. Ob die anderen Varianten {{lang|en|{{DISPLAYTITLE:English example lemma}}}} oder analog mit Vorlage:Korrekter Titel Vorteile haben, mochte ich nicht ausprobieren, das kann einer IP auf Artikelseiten leicht als Vandalismus ausgelegt werden, und die Spielwiese ist mit solchen Sonderfällen überfordert.

Dafür habe ich auf der Spielwiese die Verlinkung ausprobieren können. Am besten funktioniert die Variante [[English example lemma#deutscher Anker|{{lang|en|English example lemma}} #deutscher Anker]]. Test:

The King’s Speech

#Handlung. Das könnte auch in die Doku.--77.189.132.196 00:14, 23. Okt. 2017 (CEST)

Moderne Screenreader können schon längst Englisch.
- Sie haben außerdem ein Wörterbuch, das New York, Capuccino und Marseille kennt.
- Sie müssen auch den Unterschied in der Aussprache der Namen „Michaela“ und „Draeger“ kennen.
- Sie kennen weiterhin einen englischen Grundwortschatz und gängige globale Geografie und schalten dann selbsttätig versuchsweise um, falls eine Vokabel in Deutsch nicht erkannt wird.
- Wenn da ein „The“ davorsteht, weiß ein guter Screenreader schon seit Jahren, dass nunmehr höchstwahrscheinlich eine englischsprachige Phrase folgen wird, die irgendwann auch wieder aufhört.
Diese Vorlage war ursprünglich dazu gedacht, vereinzelte Begriffe von zentraler Bedeutung für den Artikel zu kennzeichnen.
- Einige wenige Autoren (zwei oder drei?) sind dazu übergegangen, in „ihren“ Artikeln flächendeckend ausnahmslos jedes Fremdwort mit dieser Vorlage zu markieren.
- Damit sind diese Artikel inzwischen völlig unlesbar und nicht mehr bearbeitbar geworden, weil teilweise 500 Einbindungen der umseitigen Vorlage gezählt wurden.
- Die Wikisyntax wurde dermaßen kompliziert notiert, dass diese Autoren selbst mit der Handhabung überfordert sind und die fraglichen Artikel regelmäßig zentral wegen Syntaxfehlern gemeldet werden, weil die Verschachtelung von Kursivschrift und Verlinkungen mit der Vorlage mal wieder versemmelt wurde.
Dass jedem sehbehinderten Menschen alles bestmöglich präsentiert würde, ist sicher ein unterstützenswertes Ziel.
- Nur hilft das nichts, wenn die Artikel von unseren Autoren kaum noch bearbeitet und gepflegt werden können, weil sie mit -zig Syntax-Extras und Sonderregeln gepflastert sind, die man erst mal alle erlernen muss, bevor man etwas ändern kann.
- Nicht zuletzt werden durch übermäßige Verkomplizierung die sehbehinderten Menschen von der Bearbeitung der Artikeltexte dann als erste ausgeschlossen.
- Auch durch klare inhaltliche Strukturierung, einfachen Satzbau und navigatorische Syntaxelemente werden für optisch oder anderweitig eingeschränkte Menschen Barrieren niedrig gehalten. Wie Fremdwörter ausgesprochen werden sollen, mag sich der Screenreader gefälligst selbst überlegen.
Dass die Verbesserung der Artikeltexte mit möglichst geringen Hürden jedem Internetnutzer möglich sein soll ist Grundprinzip der Wikipedia.
Ich werde deshalb umseitig sicher keine Anregungen geben, wo man noch alles diese Vorlage verbauen könnte.

VG --PerfektesChaos 10:11, 23. Okt. 2017 (CEST)

Ich hatte angenommen, daß die Vorlage bisher vor allem deshalb nicht verwendet wird, weil es sie noch nicht so lange gibt und vielen Autoren das Wissen darüber fehlt. Die Existenz einer Vorlage ist für mich normalerweise ein Hinweis darauf, daß sie auch benutzt werden darf und sollte, sofern diesbezüglich in der Dokumentation keine Vorbehalte oder Einschränkungen vermerkt sind. Bisher ist dort die einige Einschränkung: „Fremdworte, [...] die auch im Deutschen üblich sind.“

Wenn aber, wie Du schilderst, noch gar kein Konsens darüber besteht, ob und in welchen Fällen eine Verwendung nützlich und wünschenswert ist und wann sie eher schadet und vermieden werden sollte, dann ist es mir natürlich kaum möglich, mich in dieser Hinsicht sinnvoll zu engagieren. Ich möchte ja weder umsonst Arbeit hineinstecken, noch kann ich selbst die von Dir gemachten Abwägungen abschließend beurteilen. Für mich persönlich sehe ich keine nennenswerten Probleme in der Verwendung, solange sie nicht verpflichtend ist, aber ich halte mich auch nicht für einen durchschnittlichen Nutzer. Die Auswirkungen auf Mitarbeit, Lesbarkeit, Fehleranfälligkeit, usw. lassen sich vermutlich nur mit geeigneten statistischen Tests objektiv ermitteln.

Der Artikel The King’s Speech, an dem ich mich gestern probiert habe, ist zunächst einmal gesichtet worden (ein Revert, ganz oder in Teilen, ist natürlich weiterhin jederzeit möglich) und könnte ein Beispiel für die Sinnhaftigkeit oder Sinnlosigkeit des Unterfangens sein. Angesichts Deiner Antwort will ich aber nun erst einmal abwarten, wie sich die Diskussion unter anderen Mitarbeitern weiterentwickelt.--89.15.131.13 15:55, 23. Okt. 2017 (CEST)

Es gibt die Vorlage seit 2005, sie ist in über 120.000 Artikeln eingebunden, und gegen eine Verwendung in Maßen spricht nichts.

Heißt: Inhaltlich wichtige Schlüsselbegriffe können durchaus damit ausgestattet werden; etwa eine Etymolgie des Lemmas im Einleitungsabschnitt.

Problematisch würde nur das Unterfangen, jedes fremdsprachliche Wort damit auszustatten – darauf lässt aber der Ansatz „stehen eines Tages sämtliche Inhalte aus Wikipedia allen Menschen auf der Welt uneingeschränkt“ schließen.

Vor einem Dutzend Jahren hatte man lediglich die technische Möglichkeit einer Kennzeichnung von Fremdsprachen geschaffen, allerdings versäumt, auch Regeln für den Einsatz beizugeben. Das war im ersten Jahrzehnt auch nicht erforderlich gewesen. Erst in jüngerer Zeit ergab sich bei vereinzelten Autoren eine exzessive, inflationäre und störende Verwendung.

Deine Artikelbearbeitung ist zunächst einmal als nicht schädlich eingestuft worden; soweit ich ermitteln konnte, ist das das einzige derart bestückte Lemma. Da das Lemma aber mit dem Wort „The“ beginnt, wissen zeitgenössische Screenreader ohnehin, dass mutmaßlich eine englischsprachige Phrase folgt. Diese Überlegungen hat aber ein Sichter, der lediglich kontrolliert, dass Artikelinhalte nicht beschädigt werden, mit Sicherheit nicht angestellt.

VG --PerfektesChaos 16:25, 23. Okt. 2017 (CEST)

Bisher habe ich nicht geahnt, daß es ein "zu viel" geben könnte und eine Abwägung stattzufinden hat, was noch „in Maßen“ ist. Ich hatte tatsächlich daran gedacht, langfristig gesehen jedes fremdsprachliche Wort (nicht jedes Fremdwort!) zu kennzeichnen. Um niemanden zu überfordern, würde ich nur nicht von jedem Autor fordern, sich an der Arbeit zu beteiligen. In den meisten Artikeln gibt es ja überhaupt keine Worte oder Texte in fremden Sprachen, aber wo welche vorkommen, hätte ich die Vorlage auch benutzt. Die Kriterien für die von Dir geforderte Abwägung sind hingegen nicht dokumentiert. Falls es tatsächlich hilfreiche Kriterien gibt, dann wäre es gut, wenn die auch in der Dokumentation aufgeführt sind, ansonsten kann sich niemand danach richten. Es wäre dann eine reine Gefühlssache, was „in Maßen“ oder maßlos ist, und verschiedene Autoren fühlen da sicherlich unterschiedlich.

Du hast z.B. Texte erwähnt, die von modernen Screenreadern automatisch erkannt werden. Die Screenreader sind natürlich nur einer von mehreren Gründen, die in der Dokumentation für den Einsatz der Vorlage genannt sind. Aber selbst wenn man dieses Kriterium heranzieht, wie soll ein Autor prüfen, ob ein moderner Screenreader (welcher?) die Sprache auch so erkennt? Ich glaube kaum, daß das bisher irgend jemand gemacht hat, und ich zweifele daran, ob der Prüfungsaufwand den Nutzen rechtfertigt. Im Gegenteil, wenn nur ein Teil der fremdsprachigen Texte markiert ist, kann kaum noch einer die Gründe nachvollziehen und Streit ist vorprogrammiert. Ein einfaches Kriterium, z.B. alle Fremdsprachen aber keine Fremdworte, halte ich daher für vorteilhaft.

Letztendlich kann und will ich nicht entscheiden, wie der Einsatz der Vorlage gehandhabt werden soll. Die möglichen Nachteile und Probleme, die Du beschreibst, halte ich durchaus für bedenkenswert. Die Entscheidung zur Einschränkung des Einsatzbereiches sollten die angemeldeten Nutzer (meinetwegen auch Du) treffen und dokumentieren, dann richte ich mich gerne danach. Ich bin keinesfalls daran interessiert, hier im Alleingang irgend etwas umzukrempeln. Solange keine Klarheit herrscht, würde ich mich daher mit weiteren ähnlichen Bearbeitungen eher zurückhalten.--89.15.131.13 17:51, 23. Okt. 2017 (CEST)

Ganz allgemein sind die Dokumentationen der Vorlagen nur dazu da, die technische Funktionalität zu erläutern.
- Für die Frage, wie und wo sie inhaltlich und enzyklopädisch passen, sind ggf. Projektrichtlinien zuständig.
- Es gibt nirgendwo eine Projektrichtlinie, die dazu anregt, Zitate, „würde ich nur nicht von jedem Autor fordern, sich an der Arbeit zu beteiligen“ – „tatsächlich daran gedacht, langfristig gesehen jedes fremdsprachliche Wort“ mit dieser Vorlage zu kennzeichnen.
- Es gibt bislang auch noch keine Richtlinie, die ausdrücklich klarstellt, dass eine inflationäre Anwendung unterbleiben soll.
- Allmählich habe ich den Eindruck, dass das erforderlich wird.
- Seit 2005 sind wir ohne solche Extra-Regeln ausgekommen, und die Autoren hatten sich von selbst auf inhaltlich wichtige Begriffe beschränkt.
- Es sind auch nur zwei Autoren, die teilweise alle 500–700 fremdsprachlichen Wortgruppen in einem Artikel mit dieser Vorlage versehen haben, und auch auf vielfache Ansprache von dieser Narretei nicht abzubringen waren.
- Du kannst ja mal projektweit vortragen, dass in allen über zwei Millionen Artikeln alle fremdsprachlichen Wortgruppen jetzt nachträglich gekennzeichnet werden sollen. Allerdings müsstest du dir überlegen, wozu das gut sein soll, denn Screenreader werden das mit zunehmender eingebauter Intelligenz und Wörterbuch-Baumstrukturen um so weniger brauchen, je mehr man in die Zukunft blickt. Wenn es eigentlich aber überhaupt keinen Sinn hat, jedoch die Bearbeitung der Artikel erschwert und zusätzliche Hürden errichtet und weitere Regeln etabliert, wird man dir vorhalten, dass wir mit der inhaltlich-technischen Pflege und Aktualisierung unseres Artikelbestandes bereits zu 100 % ausgelastet sind und keine Zeit und Kapazitäten für sinnfreie Arbeitsbeschaffungsmaßnahmen haben.
In einem Artikel, der von einem britischen Politiker handelt, oder einer US-amerikanischen Rockband oder von einem französischen Maler oder spanischem Dorf oder italienischer autostrada kommen riesige Mengen an fremdsprachlichen Wortgruppen vor; insbesondere wenn man wie unsere beiden Helden auch noch in den Einzelnachweisen jedes Washington und jedes MTV und jeden Namen eines Journalisten mit der Vorlage dekoriert.
Ich habe dir brav deine Fragen beantwortet. Dafür habe ich 7000 Bytes und über eine Stunde aufgewendet, die an anderer Stelle verloren gegangen ist. Ich denke, es ist dir klar geworden, dass dein Vorhaben unerwünscht ist, und es nunmehr reicht.

VG --PerfektesChaos 19:08, 23. Okt. 2017 (CEST)

Diese Vorlage ist nicht ausgreift und die Pflegebarkeit des Quellcodes ist nicht mehr gegeben.

Ich möchte hier ein Problem mit dieser Lang-Voralge ansprechen. Diese Vorlage hier scheint einiges nicht zu Ende gedacht zu sein.
Zuerst möchte ich vorausschicken, dass ich die Nutzen dieser Voralge durchaus sehe und verstehe. Die Barriesenfreiheit ist ein berechtigtes Anliegen. Leider ist die Umsetzung dieser Lang-Volrage leider ziemlich schlecht ausgefallen: "
Die Stadt befindet sich rund 78 km südostöstliche von {{lang|mi|[[Tauranga]]}} und rund 27 km nordwestwestlich von {{lang|mi|[[Opotiki]]}} direkt an der Mündung des [[Whakatane River|{{lang|mi|Whakatane}} {{lang|en|Rivers}}]] in den [[Pazifischer Ozean|Pazifischen Ozean]]. Das Stadtzentrum liegt unterhalb des Ausläufers der ''{{lang|mi|Raungaehe}} {{lang|en|Range}}'', die an der Küste in dem in die See hineinreichenden ''{{lang|mi|Kohi}} {{lang|en|Point}}'' enden. Die Felsen, die die sichtbare Verwerfung der [[Whakatane Fault|{{lang|mi|Whakatane}} {{lang|en|Fault}}]] darstellen, unterbrechen an dieser Stelle den fast 100 km langen Sandstrand der [[Bay of Plenty (Bucht)|{{lang|en|Bay of Plenty}}]].<ref name="LINZ_Topo250_maps" />" Wiki-Code aus dem Artikle: Whakatāne.
Mir erschliesst sich der Sinn von einer solchen flächendeckende Einbindung einer Vorlage nicht. So könnte man auch gleich die ganze Wikipedia auf HTML-Code umstellen. Der Vorteil der geringen Komplexität des Wiki-Codes geht so total verloren.
Es gibt bisher keinen Konsens über die flächendeckende Verwendung dieser Voralge. Trotzdem werden von einigen Benutzern flächendeckend immer mehr damit Artikel so verunstaltet, dass der Quellcode nahezu unplfegbar wird und die Fehlergefahr explodiert. Es müsste möglich sein, dass ein fremdsprachiger Therm nur einmal pro Artikel "vervorlagt" werden müsste. Alle anderen Nennungen sollte die Media-Wiki-Software selbst einfügen. So würden der Quellcode trotzdem übersichtlich und pflegbar bleiben. Ich würde vorschlagen diese Voralge zu deaktivieren, bis hier eine Weiterentwickeln stattgefunden hat. Als mindestens müssen klare Regeln her, wie die Vorlage sinnvoll eingesetzt werden soll. Der jetzige Zustand ist eine Zumutung für alle die mit den Wiki-Codes arbeiten. --Thomei08 12:08, 6. Nov. 2017 (CET)

Eine „Deaktivierung“ der Vorlagenfunktion würde am Wikitext der von dir beanstandeten Artikel genau Null ändern; der sähe hinterher genauso aus wie vorher.
Hingegen würde es um einiger weniger Artikel willen die 120.000 sinnvollen Einbindungen treffen.
Insbesondere dort, wo nichtlateinische Schriften beteiligt sind, würde der nachteilige Effekt für die Darstellung der Seite auftreten, dass ULS nicht mehr ausgelöst und keine Webfonts geladen werden, um die Textpassage richtig darstellen zu können.
Das Problem sind zwei oder drei Benutzer, die in „ihren“ Artikeln in der Tat jedes fremdsprachliche Wort verbasteln, so dass es teilweise auf 500–700 Einbindungen kommt, weil selbst in den Einzelnachweisen noch jedes New York als Verlagsort dekoriert wird.
Diese Benutzer wissen sehr genau, dass das unerwünscht ist, und werden bereits seit Jahren erfolglos aufgefordert, diese exzessive Vorlagenanwendung zu unterlassen.
Auch in den Abschnitten hierdrüber ist das öfters nachzulesen; etwa beginnend bei #Verwendung der Vorlage für englischsprachige Eigennamen?.
mi ist die Maori-Sprache; Tauranga und Whakatane haben was mit Neuseeland zu tun und den Screenreader für deutsche Webseiten, der Maori kann und besonders ausspricht, möcht ich sehen und hören.
Es steht dir weder zu, eigenmächtig eine Höchstbegrenzung an Einbindungen dieser Vorlage pro Artikel zu verkünden, noch eine „Deaktivierung“ zu veranlassen. Da die fraglichen Massenanwender in der Regel „Hauptautoren“ sein werden, steht es dir auch nicht zu, dort so ohne Weiteres die Vorlageneinbindungen zu entfernen.
Du kannst projektweite konsensuale Wege (am wirksamsten ein Meinungsbild) beschreiten, um eine Richtlinie zu bewirken, die den Einsatz auf sinnvollen und nicht inflationären Gebtauch beschränkt.
Ansonsten kannst du bei Artikeln, zu denen du maßgeblich beiträgst, die Vorlageneinbindungen durch einfachen Text ersetzen.
Die Vorlage ist im Übrigen sehr wohl ausgereift, für tausend Verwendungen in einem Artikel kann sie nichts.

VG --PerfektesChaos 15:10, 6. Nov. 2017 (CET)

formatfehler

Kasachisch

,

Kirgisisch

haben jetzt eine absurde normalgröße, ein unnützes font-size: 120% von irgendwo. --W!B: (Diskussion) 22:48, 30. Okt. 2018 (CET)

Beide Sprachen werden in arabischer oder kyrillischer Schrift erwartet.
Siehe dazu:
Wenn du explizit eine Transkription aus diesen Sprachen angeben möchtest, müsstest du kk-Latn bzw. ky-Latn benennen:
Kasachisch
,
Kirgisisch
.
Für die Völker am Südrand der ehemaligen Sowjetunion ist es typisch, dass sie aus geschichtlichen Gründen ihre Sprache in arabischer oder kyrillischer Schrift notieren; einige Staatenlenker liebäugeln damit, als amtliche Schrift die lateinische Notation einzuführen. Bislang scheint das aber noch keiner verordnet zu haben. Vielleicht beschließt zuvor der Erdogan, dass die türkische Sprache wieder nur noch in arabischer Schrift erscheinen dürfe.
Die von dir als Beispiel angeführten Textstücke haben sich übrigens auch auf von-rechts-nach-links umgesetzt.
Wenn du mir konkrete Beispiele nennst, kann ich die Artikel in den nächsten Tagen auch geeignet überarbeiten.
Bis Ende des Jahres werde ich vermutlich Textpassagen, deren tatsächlich verwendetes Schriftsystem nicht zur behaupteten Sprache passt, mit einer ausgeblendeten Fehlermeldung und einer Wartungskategorie ausstatten; mal schaun.

VG --PerfektesChaos 11:00, 31. Okt. 2018 (CET)

Sprachcode no wird nicht unterstützt

Hallo,

bei Lutefisk wird der Parameter no nicht unterstützt:

„Lutefisk (dänisch ludfisk oder
ludefisk
) ist ein traditionelles nordisches Fischgericht.“

Benutzer:Rudolph H hat dort als Workaround nb eingesetzt, aber das ergibt eine andere, verengte Aussage, da die andere norwegische Standardvarietät nn nicht mehr enthalten ist. --S.K. (Diskussion) 07:09, 17. Dez. 2018 (CET)

Mhmm, knifflige Angelegenheit.

no ist heutzutage eine Macro-Sprache, also eine Sprachenfamilie, siehe hier (und ICANN seit 2005-10-16).

Damit muss der Code von Software nicht mehr verstanden werden.

Deshalb kennt ihn auch MediaWiki nicht mehr; die wollen CLDR sehen.

Allerdings war er jahrzehntelang verwendet worden, und viele ältere Ressourcen sind als solche gekennzeichnet worden.

Der Syntaxcheck der Vorlage fragt erstmal MediaWiki, die sagen isnich, und deshalb die Fehlermeldung, weil damit gilt der Parameter als unbekannt.

Werde ich wohl zu Weihnachten eine Übersteuerung einbauen müssen; haben wir öfter.

Bei der Angabe in der einfachen Direktverwendung wird no bereits akzeptiert.
Ist ja sowieso Service, über 200 nicht so ganz explizit dokumentierte Vorlagenparameter gleich mit anzubieten, und gegenüber alten Zeiten durchaus ein autorenfreundlicher Fortschritt und liefert auch bessere Semantik.
Damit nun nicht wirres Zeug in den Parameternamen landet, erlaubt sich die Vorlage eine Plausibilitätsprüfung.

LG --PerfektesChaos 12:33, 17. Dez. 2018 (CET)

Was heißt „Damit muss der Code von Software nicht mehr verstanden werden.“? Speziell in Situationen wie der geschilderten, wenn man Aussagen treffen will, die für eine ganze Makrosprache gelten, oder wenn man eine Aussage nicht spezifischer machen will oder kann, ist m.E. die Verwendung solcher Makrosprachcodes legitim.

Von daher: wäre klasse, wenn du eine Lösung finden könntest. Auch weil es {{NoS}} schon gibt und daher schwer verständlich, warum der Sprachcode einmal „erwartungsgemäß“ funktioniert, ein anderes mal nicht.

Danke und Gruss, --S.K. (Diskussion) 22:57, 17. Dez. 2018 (CET)

Was heißt „Damit muss der Code von Software nicht mehr verstanden werden.“?
- In das HTML-Dokument werden ja die lang=-Infos eingebaut.
- Diese sind witzlos, wenn die Kodierungen unbekannt sind.
- Im HTML-Dokument sollen sie ja bewirken, dass Screenreader, Übersetzungsprogramme (wie GoogleTranslator), Rechtschreibprogramme, und die Weiterverarbeitung nach C&P in Office-Dokumenten funktionieren soll.
- Deshalb ist es auch egal, ob ein schlauer Wikipedianer wüsste, dass das nach ISO 639 aber doch ein Synonym wäre; etwa ein Drei-Buchstaben-Code als Alias für einen Zwei-Buchstaben-Code. Software kennt immer nur die Standard-Variante, keine Aliasse.
Norwegisch ist sowieso eine Geschichte für sich.
- Die haben 1000 Rechtschreibungen; in jedem Fjord eine eigene, je nachdem was da mal der örtliche Lehrer beschlossen hatte.
- Zwei moderne und ein paar historische sind halbwegs standardisiert (Duden-mäßig).
- Allerlei Software hat Extras eingebaut für unspezifisches Norwegisch und kann damit umgehen, auch wenn eigentlich nicht definiert.
In dem Moment, in dem eine Verschriftung angegeben wird, muss auch die Verschriftungssprache angegeben sein.
- Im fraglichen Artikel tauchte eine Vokabel in einer bestimmten Schreibung auf.
- Korrekterweise hätte dort auch angegeben sein müssen, ob diese Schreibung bok oder ny wäre, oder zufällig in beiden gleich.
- Ohne Spezifikation des Schreibsystems sind verschriftete Angaben sinnfrei, weil man nicht weiß welche.
- Deshalb sind auch Makrosprachen nicht geeignet, um Aussagen über eine verschriftete Vokabel zu treffen, weil daraus nicht hervorgeht, ob diese konkret in einer ganz bestimmten Schreibung präsentierte Vokabel denn nun bok oder ny oder sonstwas wäre.
Ich erwähnte bereits, dass ich Richtung Weihnachtsfeiertage die Parameterkontrolle geeignet aufweichen würde, um no zu tolerieren; dann ist es überflüssig, da noch draufrumzureiten. Ja, kommt ja, ich werde die teure hauseigene Code-Liste nehmen und nicht die billigere von MediaWiki.

LG --PerfektesChaos 11:15, 18. Dez. 2018 (CET)

Danke für die Anpassung!

Wir müssen das auch nicht mehr weiter diskutieren, obwohl manche deiner Aussagen m.E. doch ziemlich apodiktisch sind. Als Gegenbeispiel schau z.B. wie Google Translate mit Nowegisch umgeht: https://translate.google.de/#view=home&op=translate&sl=no&tl=de&text=

Sprachcode: no
Quelltext Bokmål: et hus ==> ein Haus
Quelltext Nynorsk: eit hus ==> ein Haus

Zumindest Google Translate kann anscheinend mit der Makrosprache no umgehen, bietet sie sogar exklusiv in der Sprachauswahl an.

Danke und Gruss, --S.K. (Diskussion) 19:13, 18. Dez. 2018 (CET)

@PerfektesChaos: Oben wird no inzwischen unterstützt. Das sieht gut aus, danke! Ist das noch „In Arbeit“ oder kann man es schon im Artikelnamensraum verwenden? Danke und Gruss, --S.K. (Diskussion) 11:13, 29. Dez. 2018 (CET)

Ist ANR-fähig robust; hatte über die Weihnachtsruhe mal wieder einen größeren Schub an Programmierung, Bestandsanpassung und Vereinheitlichung aufgearbeitet. Mehr im Laufe des Tages auf der Doku-Seite hier. Guten Rutsch --PerfektesChaos 11:20, 29. Dez. 2018 (CET)

Im ANR verwendet. Danke und auch einen guten Rutsch! --S.K. (Diskussion) 12:35, 30. Dez. 2018 (CET)

Sehr schön! --Rudolph H (Diskussion) 12:54, 30. Dez. 2018 (CET)

Widerspruch mit WP:TYPO

Die Idee der Vorlage ist gut, aber bei der Umsetzung entstehen Fragen:

Wieso macht die Vorlage aus

Die Insel heißt {{lang|fr|Réunion |de=Wiedervereinigung }}

den Text A

Die Insel heißt

Réunion

obwohl sie nach WP:TYPO den Text B

Die Insel heißt

Réunion

„Wiedervereinigung“

machen müsste?

Kann jemand den Widerspruch mit WP:TYPO aufräumen? Dort steht, dass die Bedeutungsangabe in ganzen anführungszeichen zu setzen ist, nicht in halben.
Müsste beim Text A nicht ein Komma nach dem Réunion stehen? Also Die Insel heißt Réunion, deutsch ‚Wiedervereinigung‘

Ich musste gerade den Artikel Schienenverkehr in Indien nacheditieren weil dort sich jemand auf der DISK über die Typographie des Artikels beschwert hatte. Ich benutze die Möglichkeit der Bedeutungsangabe mit der Vorlage nicht mehr, da diese offenbar eine falsche Typographie erzeugt. Schade. --Pechristener (Diskussion) 02:37, 29. Dez. 2018 (CET)

Dies folgt der WP:FWF in einem Jahrzehnt konsistenter Praxis: diff, diff und ist mit diff unter ausdrücklicher Berufung auf WD:TYP / WP:TYP so der Standard.

Dann musste jemand seine persönliche Nase durchsetzen und hat die klare konsistente einheitliche Darstellung auf zwei gleichberechtigt beliebig auszuwählende ausgedehnt; Vorlage:lang folgt der ursprünglichen Konvention mit weiter Verbreitung und ist damit auch für linguistischen Kontext geeignet und kompatibel zum Bestand zwecks Einheitlichkeit innerhalb desselben Artikels.
- WD:FWF #Nochmal Anführungszeichen stellt dar, dass 2008 gemäß WP:TYP die deutsche Übersetzung eines fremdsprachigen Begriffs in einfache Anführungszeichen gesetzt wird.
- Dem folgt die Richtlinie wie auch die Vorlage.
In der heute gültigen Fassung von WP:TYP #Bedeutungsangaben sind mit „oder auch“ beide Formen gleichberechtigt aufgeführt, das (ältere) „untere Beispiel“ zeigt den Quellcode mit einfachen Anführungszeichen.
Die Behauptung, mit der diese Diskussion eröffnet wurde, ist somit schlicht falsch:
- „Dort steht, dass die Bedeutungsangabe in ganzen anführungszeichen zu setzen ist, nicht in halben.“
- Steht dort aber nicht.
Was das Komma angeht, so hätte das eigentlich auch in der „nackten Version“ in dieser Situation mitgeliefert werden sollen; habe ich inzwischen ergänzt, danke für den Hinweis. Die neuartigen Parameter werden vorwiegend bei den spezialisierten Sprach(namen)-Vorlagen verwendet; dort stand das Komma von jeher hinter geeigneten Ausdrücken.
Die Bearbeitung hinterließ jetzt leere Parameterzuweisungen; das wird ab heute als Fehler gemeldet und später auch kategorisiert werden.
Am Rande bemerkt sollte diese Vorlage nicht inflationär um jeden Preis für jedes Fremdwort eingesetzt werden; wichtig ist sie für alle nicht-lateinischen Schriften und für Begriffe von zentraler Bedeutung, namentlich das Lemma des Artikels und dessen Etymologie. Bislang wurde aber noch kein Konsens für eine einschlägige und den Quelltext nicht überfrachtende Regelung hergestellt; es gibt auch nur zwei Autoren, die die Vorlage vielhundertfach für jedes englische oder ungarische Wort in einem Artikel einsetzen.

VG --PerfektesChaos 09:27, 29. Dez. 2018 (CET)

@PerfektesChaos:Ok, vielen Dank für die Aufklärung. Ich hatte in der WP:TYPO überlesen, dass beide Varianten von Anführungszeichen gültig sind, was aber glaube ich, auch nicht immer so war. Vielen Dank für den Hinweis auf WP:FWF, eine Seite, die ich bis jetzt gar nicht kannte. Wieso wird aber dort nicht explizit darauf hingewiesen, dass sowohl „“ wie auch ‚‘ verwendet wird und weshalb sich auf WP:TYPO keine Beispiel befindet, dass die Vorlage so verwendet, wie sie jetzt gerade ist, ist mir noch nicht ganz klar. Der Einsatz der Vorlage scheint auch nicht ganz klar zu sein. Den Hinweis auf die nicht zu häufige Verwendung habe ich bis jetzt auch noch nicht angetroffen.--Pechristener (Diskussion) 03:39, 6. Jan. 2019 (CET)

lang ist kürzer als Sprache...

... aber lang kommt wohl auch von language, was wieder langer ist als Sprache ;) . Im Sinne der "Barrierefreiheit" halte ich die Verwendung der deutschen Sprache für sinnvoll. Andere Vorlagen werden ja üblicherweise auch übersetzt. ...Sicherlich ^Post 22:54, 12. Jan. 2019 (CET)

Grundsätzlich bin ich ja durchaus für sehr sprechende und selbsterklärende Namen von Vorlagen zu haben.

Hier liegt der Sachverhalt jedoch etwas anders:

lang|en| ist die Repräsentation von:
- lang="en"
- Beispiel: {{lang|en|language}} expandiert zu
  <div lang="en" dir="ltr" class="description en" style="display:inline;">language</div>
- Das ist auch im Wikitext des ANR vielfach zu finden; beispielsweise mit poem.
Auch als Parameter lang= ist es aus dem gleichen Grund in allerlei Vorlagen verwendet, mit genau dieser Bedeutung.
Somit werden nicht nur blinde, sondern auch neue Benutzer sich damit abfinden und es erlernen müssen, dass es diesen Ausdruck lang nun einmal gibt.

Der Name der der Vorlage ist Tausenden von Autoren seit einem Dutzend Jahren vertraut; sie wurde unter diesem Namen 100.000-fach im ANR verbaut.

Sie jetzt nachträglich umzubenennen würde allen Beteiligten aufzwingen, dass sie lernen müssten, ein neuer Name wäre gleichbedeutend mit einem alten. Im Artikelbestand würde noch für ein Jahrzehnt die bisherige Form stehen. Es muss sich dann also jeder Autor zukünftig mit zwei Namen aber gleicher Funktion geistig beschäftigen. Dieser Migrationsaufwand und die entstehende langjährige Verkomplizierung frisst von vornherein jeglichen muttersprachlichen Effekt auf. Insbesondere wird dieses Doppellernen auch allen neuen Benutzern aufgezwungen, für die es dadurch noch komplizierter wird, was im Widerspruch zum Ziel des Abbaus von Barrieren steht.
Bot-Läufe zur Umbenennung von Vorlagen gibt es übrigens nicht; dieser hier würde bei permanenter Maximalgeschwindigkeit rund drei Monate am Stück dauern und würde Beobachtungslisten und Versionsgeschichten in unverhältnismäßiger Weise belasten.

Hinzu kommt, dass Sprache an und für sich die genaue Funktion auch nicht wiedergibt und missverständlich wäre; ein Manko, dass auch dem bisherigen Namen anhaftet.

Die wirkliche Funktion ist: Fließtext-Textfragment in Sprache.
Jemand, der Vorlage:Sprache zum ersten Mal irgendwo aufgelistet sieht, könnte sich darunter auch vorstellen, dass hier der Name einer Sprache angezeigt und ggf. verlinkt wird, wie das etwa Vorlage:enS ausführt: englisch.

Deine Anregung hättest du ca. 2005/2006 vortragen müssen.

VG --PerfektesChaos 16:46, 13. Jan. 2019 (CET)

Font zh-Hant und zh-Hans zu groß

Ich führe hier eine Diskussion weiter, die in Vorlage Diskussion:Zh#Font neuerdings zu groß? begonnen hat.
Unlängst hat es offenbar ein Änderung für die Sprachen zh-Hant und zh-Hans (aber nicht für zh-Hani) gegeben (und dies wirkt sich jetzt in der Vorlage zh aus). Der Font ist jetzt vergrößert und – wie es Benutzer:Furfur so treffend schreibt – „sieht es dysproportional aus. Die Schriftzeichen sind deutlich größer als in zh.wikipedia.“ Vorher (Größe 100 %) war es eindeutig besser lesbar.

Text mit zh-Hans	Monat und Mond (beide „ 月 “) sind im Chinesischen ( 中文 ) dasselbe.
Text mit zh-Hani	Monat und Mond (beide „ 月 “) sind im Chinesischen ( 中文 ) dasselbe.
Text ohne Vorlage	Monat und Mond (beide „月“) sind im Chinesischen (中文) dasselbe.

Oder hier ein real existierender Wikipediatext:

Am Anfang steht „Deng Xiaoping (chinesisch

鄧小平

/

邓小平

) ... ...“ weiter unten dann: „Sein Vater gab ihm den Namen Deng Xiansheng (邓先圣) [...], im Alter von fünf Jahren bekam er von seinem Lehrer den Namen Deng Xixian (邓希贤).“

Ich plädiere dafür, die Vergrößerung rückgängig zu machen -- Wassermaus (Diskussion) 12:59, 21. Jan. 2019 (CET)

Ich habe das jetzt reduziert und Hani einbezogen.

Eine leichte Vergrößerung tut den Zeichen jedoch gut; früher sahen fast alle Benutzer nur Käsekästchen, aber heute sollte das schon zu etwas mehr als Brei verschwimmen.

Danke für den Hinweis --PerfektesChaos 13:35, 21. Jan. 2019 (CET)

谢谢 (auf deutsch: merci!) -- Wassermaus (Diskussion) 19:01, 21. Jan. 2019 (CET)

Bei mir sind

月

und

中文

mit {{lang|zh-Hans|...}} immer noch größer als

月

und

中文

mit {{lang|zh-Hani|...}}. Am meinem globalen Wiki-Stylesheet kann es nicht liegen, denn erstens ist dort nur eine Mindestgröße für CJK-Zeichen definiert, und zweitens für beide gleich. Kann es sein, dass der de.WP-Vergrößerungsalgorithmus bei {{lang|zh-Hans|...}} und {{lang|zh-Hant|...}} doppelt angewendet wird, zum Beispiel zusätzlich noch einmal für das enthaltene {{lang|zh|...}}? Lieben Gruß —LiliCharlie (Disk.) 20:42, 21. Jan. 2019 (CET)

@LiliCharlie: Hmmmh, immer ärgerlich, wenn es zu solchen nicht vorhergesehenen Nebeneffekten kommt – sorry for that; aber wir müssten uns so allmählich für alle weiterentwickeln, und dewiki muss dann auch mal aus den ersten Kinderschuhen raus und erwachsen werden.

In deiner globalen CSS sehe ich pt nach der 18; das ist seltsam, denn es gehört zu auf Papier ausgedruckten Dokumenten. Für den Bildschirm müsste es 18px heißen, was üblicherweise das gleiche Erscheinungsbild ergeben wird.
Vieles an diesen Angelegenheiten ist auch von individuellen technischen Gegebenheiten abhängig; Betriebssystem, installierte Fonts, Browser, persönliche Einstellungen. Deshalb überblicke ich nicht immer jede Auswirkung bei allen.
Du könntest freundlicherweise in deiner hiesigen common.css einfügen:

.Hani, .Hans, .Hant {
   font-size: 100% ! important;
}

Das wäre das genaue Gegenstück zur hiesigen Vorgabe für alle Benutzer und macht diese wieder rückgängig.

Zukünftig können die Darstellungen hierzuwiki übrigens per Schriftsystem adressiert werden und müssen nicht mehr für jede Sprache einzeln aufgezählt werden.
Ein Übereinanderliegen mehrerer Definitionen kann ich ausschließen. Da müsste auch in der zh-Vorlage ziemlich wild der Wurm drin sein, und wenn diese überhaupt nicht beteiligt ist dann gleich gar nicht.
Insgesamt geht es darum, für über 200 menschliche Sprachen und bislang mehrere Dutzend Schriftsysteme eine möglichst einfache und überschaubare und leicht zu pflegende moderne Architektur auch in den Vorlagen umzusetzen. Bislang gab es einen gruseligen Wildwuchs und rund 50 unterschiedliche Programmierungen, auch mit jeweils verschiedenen Parameternamen für die gleichen Zwecke.

Gutes Gelingen --PerfektesChaos 22:37, 21. Jan. 2019 (CET)

Danke, PerfektesChaos, das Einfügen von .Hani, .Hans, .Hant { font-size: 100% ! important; } auf meinem dewiki-Stylesheet hatte den gewünschten Effekt.

Ich bin darauf gespannt, wie „die Darstellungen hierzuwiki ... per Schriftsystem adressiert werden“ sollen. Wichtig ist mir einerseits, dass im CJK-Bereich weiterhin per Sprache (und manchmal per Land!) adressiert werden kann und zum Beispiel zwischen zh-Hans

禅

und ja

禅

(„Chan/Zen“) unterschieden werden kann, zwischen zh-Hans

龜

und zh-Hant

龜

und zwischen zh-Hant-TW

扁

und zh-Hant-HK

扁

. (zh-Hant-TW

扁

wird auf meinem System falsch dargestellt als

⿸户𠕁

wie in Hongkong und Festlandchina statt mit der taiwanischen Zeichenform

⿸戶𠕁

. Die Unterscheidung zwischen zh-Hant-TW und zh-Hant-HK ist so essentiell, dass mein Firefox nicht alleine dasteht, sie seit Jahr und Tag standardmäßig zu unterstützen, nur ist offensichtlich dewiki noch nicht so weit gekommen...) Und natürlich ist auch wichtig, dass Unicode-Zeichen, die zu den Pseudo-Schriftsystemen mit den ISO 15924-Codes Zyyy („undetermined/common“) und Zinh („inherited“) gehören korrekt behandelt werden und zum Beispiel ein U+00B7 middle dot in einem sinisierten und in chinesischen Zeichen geschriebenen Namen als Teil der chinesischen Schrift erkannt wird und entsprechend formatiert dargestellt wird. Lieben Gruß —LiliCharlie (Disk.) 00:19, 22. Jan. 2019 (CET)

Was du auflistest, ist ja wohl auch im letzten Dutzend Jahre so gewesen und kann zukünftig nur irgendwann besser werden?

Wir sind mittelfristig in der Lage, die Kodierung von Textsequenzen zu analysieren und etwa Zeichen von lateinisch auf fullwidth oder halfwidth zu konvertieren, sofern das in bestimmtem Kontext gewünscht würde.

Allerdings bin ich vermutlich der Einzige, der das beherrscht, und auf Jahre ausgebucht.

Der gesamte Sektor der Sprach-Schrift-Text-bezogenen Vorlagen wird in diesen Jahren allmählich aufgeräumt, systematisiert, vereinheitlicht, vereinfacht; dabei bin ich allerdings momentan bei den nichtlateinischen Buchstabenschriften und habe mir die Silben- sowie ideografischen Schriftsysteme für den Abschluss vorgesehen; schon weil ich außer dem Zeichen für Baum und dem davon abgeleiteten Zeichen für Wald nix lesen kann.

VG --PerfektesChaos 11:05, 22. Jan. 2019 (CET)

Also ich habe kein common.css (wusste gar nicht, dass es das gibt), und bei mit sind die Zeichen mit zh-Hans (erste Zeile der Tabelle oben) immer noch deutlich größer (und aus meiner Sicht zu groß), während der Text mit zh-Hani normal aussieht (d.h. so wie ohne Benutzung der Vorlage - dritte Zeile) -- Wassermaus (Diskussion) 22:50, 30. Jan. 2019 (CET)

Ich vermute jedoch, dass du als offenkundig sprachkundig auf deinem Rechner schöne, große Fonts installiert und konfiguriert hast, oder im Browser passende Einstellungen vorgenommen hast. Damit kannst du auch ohne Vorlage alle Einzelheiten der Zeichen gut erkennen.

Normalsterbliche Leser sehen jedoch die Grundausstattung aus ihren Rechnern, und für die ist ein Hant-Zeichen genauso hoch wie ein lateinisches X und dieses aber mit wesentlich weniger Kleinkram verziert.

Probiere doch mal die angegebene Regel, um wieder die exakt gleiche Schriftgröße wie bei lateinischen Buchstaben zu erhalten, wenn du persönlich damit glücklicher bist. 谢谢 – was bei mir nur zwei schwarze Kleckse ohne unterscheidbare Einzelheiten ergibt.

VG --PerfektesChaos 23:24, 30. Jan. 2019 (CET)

In unseren Artikeln kommen (sehr) häufig Begriffe nebeneinander vor, von denen manche in Kurz- und Langzeichen identisch geschrieben werden und das Markup zh-Hani erhalten, während andere in Kurzzeichen anders als in Langzeichen geschrieben werden und entsprechend mit zh-Hans respektive zh-Hant markiert sind. Ich empfinde die auf de.WP dadurch entstehende typografische und die Lesbarkeit infrage stellende momentane Situation als eine mittelmäßige Katastrophe, die schleunigst behoben werden sollte. Lieben Gruß —LiliCharlie (Disk.) 23:37, 30. Jan. 2019 (CET)

P.S. Meines Erachtens sollten zh-Hani und zh zur gleichen Darstellung führen und sich in der Größe nicht von zh-Hans und zh-Hant unterscheiden; über eine davon unterschiedene Ausgabe vom zh-Bopo (Bopomofo) und insbesondere von zh-Latn (Pinyin usw., das besser nicht größer als der ebenfalls in lateinischer Schrift geschriebene deutsche Fließtext dargestellt werden sollte) lässt sich diskutieren. Lieben Gruß —LiliCharlie (Disk.) 23:52, 30. Jan. 2019 (CET)

Lesbarkeit – das ist ja ein großes Wort, das du da einführst.

Ein lateinisches E hat drei horizontale Striche, mit zwei Zwischenräumen um hindurchzuschaun.
谢 hat circa acht horizontale Ebenen und sieben Zwischenräume.
Normale Leser haben ihre Darstellung schon von der Installation her so konfiguriert, dass die drei Linien des lateinischen E gut unterscheidbar sind. Vier oder maximal fünf Linien übereinander mögen notfalls auch noch gehen.
Sieben oder acht Linien führen jedoch dazu, dass kaum noch Platz für die trennenden Zwischenräume bleibt, weshalb das ganze Schriftzeichen zu einem leicht zebramäßigen schwarzen Klumpen zerläuft. Lesbar oder als Schriftzeichen wahrnehmbar ist das für normale Leser nicht mehr.

Wenn etwas katastrophal ist, dann ist es die Forderung, die komplizierter aufgebauten Han*-Zeichen dürften nicht größer werden als ein lateinisches E – das kann für die Gesamtheit aller Leser nicht erbaulich werden, wenn in unseren Texten lateinische und CJK-Zeichen gemischt in einer Zeile auftreten.

Ich gehe sehr stark davon aus, dass ihr als Schriftkundige in euren Konfigurationen irgendwas angestellt habt, dass ihr eure CJK-Zeichen noch erkennen könnt. Das kann ein spezieller Font oder die Browser-Konfiguration sein, oder das schon gefundene Wiki-CSS. Das seht dann aber nur ihr, und der Rest der Welt (mich eingeschlossen) nimmt etwas anderes wahr.

Ich habe auf euren Wunsch hin die Vergrößerung nur noch auf moderate 110 % eingestellt; das hat schon kaum die eigentlich beabsichtigte Wirkung, aber es ist nicht höher als ein lateinisches Ê mit einem Akzent und kann nicht die behauptete fürchterliche Wirkung haben. Dieses E hat genau den gleichen Vergrößerungsfaktor, und es führt ja nun nicht gerade zum Totalschaden.

Nebenbei bemerkt sollten immer alle nichtlateinischen Textfragmente in die einschlägigen Vorlagen eingeschlossen sein, damit sie der einheitlichen Konfiguration zugänglich werden.

VG --PerfektesChaos 00:25, 31. Jan. 2019 (CET)

Wieso werden Zeichenfolgen im Schriftsystem zh-Hani unterschiedlich groß dargestellt als die in zh-Hans und zh-Hant? – Schließlich sind die Zeichen in zh-Hans und zh-Hant per definitionem sich überschneidende Teilmengen der Zeichen in zh-Hani (und natürlich der in zh). Lieben Gruß —LiliCharlie (Disk.) 00:33, 31. Jan. 2019 (CET)

Bei mir sind alle Hani, Hans, Hant genau gleich groß; und ohne Vorlagenwirkung auch genauso groß wie ein lateinischer Großbuchstabe, beispielsweise EHMSTW.

Ich habe eine Normalbenutzerkonfiguration, zumindest was alle nichtlateinischen Schriften anginge.

Ich gehe schwer davon aus, dass ihr Schriftgelehrten euch über ein Jahrzehnt Wiki- und anderer Lektüre eine private Umgebung eingerichtet habt, so dass bei euch die Welt normal und hübsch aussieht. Nur ist dieses Erscheinungsbild nicht das, welches 99,9 % der Leser der Wikipedia zu Gesicht bekommen.

Bis vor einigen Jahren konnte ich keine CJK-Zeichen sehen, sondern sah immer nur Rechtecke mit dem Hexadezimalcode der Zeichen darin. Zu der Zeit war es mir auch völlig egal. In jüngerer Zeit hat aber auch das billigste Dummsmartphone Chinesisch und Japanisch und Koreanisch gelernt, und jetzt erscheinen bei unserer Leserschaft die Schriftzeichen nicht mehr als Rechtecke. Also müssen sie halbwegs manierlich ausschauen und nicht als schwarze Kleckse, selbst wenn kaum ein Leser das wirklich entziffern könnte.

Die Aufgabe liegt nun darin, einen Weg zu finden, wie für eure persönlichen Einstellungen derselbe Wikitext annehmbar aussieht, der auch für Standardleser mit der Grundeinstellung des Betriebssystems ohne Sprachkenntnisse anschaulich wirkt.

Die Mengenlehre hat mit der Angelegenheit nichts zu tun; die Rechnerkonfigurationen arbeiten anders.

Bopo hatte ich bislang nicht auf dem Radar, kommt aber in Kürze.

VG --PerfektesChaos 01:00, 31. Jan. 2019 (CET)

Für mich persönlich ist nach Umsetzung deines Hinweises zur Änderung meines dewiki-Stylesheets alles gut, aber Wassermaus hat vor ein paar Stunden geschrieben: „... bei mit sind die Zeichen mit zh-Hans (erste Zeile der Tabelle oben) immer noch deutlich größer (und aus meiner Sicht zu groß), während der Text mit zh-Hani normal aussieht (d.h. so wie ohne Benutzung der Vorlage - dritte Zeile)“. Da ich nach jahrelanger Beobachtung keinen Anlass sehe, an Wassermausens Zuverlässigkeit zu zweifeln, komme ich zu dem Schluss, dass Zeichenfolgen mit besonderen chinesischen Kurzzeichen für die Mehrzahl unserer Benutzer größer dargestellt werden als Zeichenfolgen mit Zeichen, deren chinesische Kurz- und Langzeichen identisch sind; auch im letzgenannten Fall handelt es sich jedoch um Zeichenfolgen in chinesischen Kurzzeichen (und zusätzlich um welche in chinesischen Langzeichen, denn beide sind [d. h. happen to be] identisch). Lieben Gruß —LiliCharlie (Disk.) 01:16, 31. Jan. 2019 (CET)

Wobei ich anempfehlen würde, deiner CSS-Spezifikation noch ein .Bopo, voranzustellen.

Woher der Browser beim individuellen Leser seine Schriftzeichen zur Darstellung der CJK bezieht, ist sehr stark vom Betriebssystem und dessen Grundausstattung abhängig.

Durchschnittsleser werden hier nichts gemacht, installiert, konfiguriert haben.

Gleichwohl können mehrere Schriftdefinitionsdateien zusammenwirken. So kann ich mir gut vorstellen, dass Hans in einem vorrangigen Font mit enthalten ist, weil darüber wohl moderne Kommunikation abgewickelt würde. Damit versucht das Darstellungssystem erstmal auszukommen. Wenn nun Zeichencodes nicht enthalten sind, etwa weil die Codes spezifisch Hant oder Hani zuzurechnen wären, dann kramt ein modernes System so lange in allen anderen Schriftdefinitionsdateien, bis es ihm möglichst gelungen wäre, jedes Zeichen irgendwie darzustellen.

Dabei kommen die Zeichen jedoch aus unterschiedlichen Schriftdefinitionsdateien in unterschiedlichem Stil mit unterschiedlichen Charakteristika und Attributen. Deshalb müssen die nicht zwangsläufig optisch zusammenpassen.

Wir hatten vor einem Dutzend Jahren mal sowas Ähnliches mit Griechisch gehabt: Der Standard-Zeichensatz, unter Windows typischerweise „Arial“, enthielt damals (wenn überhaupt) nur die Basiszeichen für Neugriechisch. Wenn nun Altgriechisch (also sogenanntes Polytonisch) dargestellt werden sollte, dann kamen diese Zeichen aus einem nachrangigen Font und hatten ggf. einen anderen Designer und andere Charakteristika. Damit sahen in einem Wort die Buchstaben mit diakritischen Zeichen (echt alt) aber deutlich anders aus als die undekorierten Buchstaben (neu). Nachdem jedoch die Rechner immer fetter ausgestattet werden und das Standard-Arial usw. auch das komplette Altgriechisch aus einem Guss enthält, passt es mittlerweile. Bis dahin konnte über CSS die Rangfolge der Schriften beeinflusst werden.

Hern/Frau Wassermaus lege ich die Spezifikation einer CSS-Deklaration nahe, ggf. auch unter expliziter Angabe der auf den verwendeten Rechnern installierten Profi-Schriftarten, wodurch sich das Betriebssystem nicht mehr wahllos zusammensucht, was es grad an grafischen Definitionen finden kann.

Auf Unicode-Mailinglisten war ich noch nie, bezweifle auch dass sie mit der Problematik hier etwas zu tun hätten.

VG --PerfektesChaos 01:51, 31. Jan. 2019 (CET)

Hier geht es nicht um font-family, sondern ausschließlich um font-size. Weshalb sollte es nicht möglich sein, für Text in zh-Hani und zh-Hans (sowie auch zh-Hant und zh) bei Betriebssystem und/oder Browser eine einheitliche Schriftgröße anzufragen? Lieben Gruß —LiliCharlie (Disk.) 02:02, 31. Jan. 2019 (CET)

Weil die absolute sichtbare Zeichengröße zu den Charakteristika gehört, die von Schriftartdatei zu Schriftartdatei unterschiedlich ausfallen können.

Bitte mal Letter angucken, und die Skizze rechts. Zwar arbeiten Browser nicht mehr mit Bleibuchstaben, aber das Grundprinzip und die Maße haben sich seit 500 Jahren nicht geändert.

font-size beschreibt die Kegelhöhe d, also die Bleiletter drumrum. Heute: Das umschreibende Rechteck. Hingegen ist das sichtbare Zeichen, das Schriftbild, auf allen vier Seiten von Fleisch umgeben. Die Wahl der Abmessungen ist in das Belieben der Schriftdesigner gestellt und muss nicht zusammenpassen, ist nur innerhalb desselben Font mit Glück oder in aller Regel identisch – kann jedoch von Schriftsystem zu Schriftsystem innerhalb derselben Schriftartdatei stark variieren und sogar über das eigentlich umschreibende Rechteck hinausgreifen, was bei asiatischen Schriften häufiger mal passiert.

VG --PerfektesChaos 02:15, 31. Jan. 2019 (CET)

Wassermaus hat nicht geschrieben, dass Text in zh-Hans und zh-Hani in verschiedenen Fonts dargestellt würden. (Auch auf meinem System sind beide ununterschieden; zh-Hani und zh default to zh-Hans.) Davon ausgehend, dass zur Darstellung beider dieselbe Schriftart (d. h. typeface bzw. font) benutzt werden bleibt die unterschiedliche Schriftgröße. (Als ich am 21. Jan 2019 um 20:21 MEZ geschrieben habe: „Bei mir sind

月

und

中文

mit {{lang|zh-Hans|...}} immer noch größer als

月

und

中文

mit {{lang|zh-Hani|...}}“ war ich mir sicher – ich wiederhole: sicher – und ich bin es angesichts der auf meinem System installierten Fonts noch immer –, dass ich beide mit derselben Schrift „Noto Sans SC“ betrachte.) — Es geht hier ausdrücklich um keine Font-Frage, sondern um eine Frage der Schriftgröße – insbesondere auch der Schriftgröße desselben Fonts. Lieben Gruß —LiliCharlie (Disk.) 02:44, 31. Jan. 2019 (CET)

Hallo @LiliCharlie, Wassermaus: nur zur Info: eine ähnliche Diskussion haben wir gerade bei der Devanagari-Schriftvorlage (mittlerweile allerdings wohl entschärft, man sieht das frühere Problem nur noch an den Bildschirmfotos). Gruß --Furfur^{⁂ Diskussion} 18:53, 19. Feb. 2019 (CET)

Falsche Ausgabe bei Malayalam

Die veraltete Codierung des Zeichens ൻ als ന്‍ funtioniert nicht:

{{lang|ml|ന്‍}} →
ന്‍
{{MlS|ന്‍}} → Malayalam ന്

Der ZWJ am Ende wird offenbar abgeschnitten. --androl ☖☗ 19:04, 24. Mai 2019 (CEST)

Parameter LONG

Hallo @PerfektesChaos:

bei {{Lang/Latn-nachgestellt/Doku}} wird der Parameter LONG unterstützt, bei {{Lang/Latn/Doku}} nicht. Gibt es dafür einen tieferen Grund? (Ist mir beim Erstellen von {{PiS-Latn}} aufgefallen, eigentlich hatte/habe ich dort keinen Bedarf für die Nachstellung gesehen.)

Danke und Gruss, --S.K. (Diskussion) 19:18, 11. Jun. 2019 (CEST)

Das liegt eher an der überkommenen nachgestellt-Familie, die aus Kompatibilitätsgründen zu unterstützen war.

Die nachgestellt-Familie gehört eigentlich zum Kyrillischen, also mit Vorlage:lang/Cyrl-nachgestellt/Doku dokumentiert, und betrifft den Großraum Ex-Sowjetunion und dort vor meiner Zeit eingeführte Sitten.

Vorlage:kuS-Latn (Kurmandschi) schiene mir eher Präzedenzfall zu sein:

kurdisch کوردی lateinisch Kurmancî, englisch Kurdish language

Die anderen Sprachvarianten sind immer technisch möglich; es ginge bei Parameter LONG nur um die Frage, ob das explizit in der Dokumentation aufgelistet werden würde.

Ich denke, mit zunehmender Ausbreitung der neuen Vorlagentechnologie wird das Prinzip allmählich bekannter werden, und dann fällt die Notwendigkeit, alles überall zu erwähnen irgendwann weg.

Insofern:

पाळि

funktioniert ja. Stünde bloß nicht explizit in der Doku, weil vielmehr müsste die Latn-Universaldoku Parameter für Sinh und Mymr erhalten, und das ist wohl weniger der Hit. Weil kämen Dutzende Parameter für die Doku in Frage.

Pali Pāli, singhalesisch पाळि funktioniert ja auch. Steht nur nicht in der Doku.

Je später die Sprachnamensvorlagen im Lauf der Jahre angelegt werden, desto geringer ist der Bedarf und desto seltener die Anwendung. Alles, was jetzt noch neu hinzukommt, scheint mir ziemlich exotisch. Die Doku-Schablone wird dadurch aber irgendwann unbeherrschbar.

LG --PerfektesChaos 19:47, 11. Jun. 2019 (CEST)

Danke für die Erläuterungen! Quelle der Verwirrung war, dass ich den Parameter LATN bei Vorlage:lang/Latn/Doku übersehen habe. :-( Als es dann nicht funktioniert hat, habe ich mit {{AzS-Latn}} die „falsche“ -Latn-Vorlage als Beispiel erwischt; {{KuS-Latn}} wäre eine „richtige“ Referenz gewesen. Dann wäre ich auch auf LATN gestoßen.

Danke und Gruss, --S.K. (Diskussion) 01:56, 13. Jun. 2019 (CEST)

PS: Klar wird die Anzahl Verwendungen bei späteren Vorlagen-Erstellungen tendenziell niedriger. Aber die Sprachauszeichnungsvorlagen sind als „Familie“ designed. Da finde ich Konsistenz in der Familie gesamthaft ein gutes Argument, dass für mich eher auch bei diesen Fällen für die Anlage einer entsprechenden Vorlage spricht.

bs

bosnisch wird vorrangig latein geschrieben, und gehört nicht std kursiv. für die kyrillische variante braucht es eine ergänzung. --W!B: (Diskussion) 09:33, 14. Aug. 2019 (CEST)

Es verhält sich so, dass Bosnisch derzeit meistens mit einem lateinischen Schriftsystem (latinica) geschrieben wird, daneben mit einem kyrillischen (bosančica) und fast nur noch historisch mit einem persisch-arabischen (arebica). Bei der IANA ist für ersteres die Sprachauszeichnung bs-Latn und für zweiteres bs-Cyrl registriert; letzeres ist nicht registriert, und die beiden registrierten werden als redundant betrachtet, d. h. bs kann für beide benutzt werden. Siehe IANA Language Subtag Registry.
Kursivschrift dient nach Kursivschrift#Anwendung folgendem grundsätzlichen Zweck: „Generell zeigt eine kursive Hervorhebung an, dass es sich ... um ein Fremdwort aus einer anderen Sprache handelt ... Das Schriftbild verliert dadurch seine potenzielle Ambiguität.“ Wir verwenden also Kursivschrift um der Leserschaft Klarheit zu geben, dass es sich um objektsprachlichen (fremdsprachlichen) Text handelt und nicht um metasprachlichen (deutschen). Lieben Gruß —LiliCharlie (Disk.) 10:38, 14. Aug. 2019 (CEST)

?? {{lang|bs|Босна и Херцеговина }} →

Босна и Херцеговина

- kyrillisch gehört nicht kursiv. nie. --W!B: (Diskussion) 10:16, 15. Aug. 2019 (CEST)

Schreibstu {{lang|bs-Cyrl|Босна и Херцеговина}} →

Босна и Херцеговина

– dann weiß Vorlage, dass du beabsichtigst, kyrillisch zu schreiben, und unterlässt die Kursivierung, und eines Tages wirst du sogar einen Anschiss bekommen, falls du ein lateinisches „o“ oder griechisches omikron als zweiten Buchstaben reintippst, oder a bzw. alpha als letzten. VG --PerfektesChaos 15:32, 15. Aug. 2019 (CEST)

Och menno, wir sind ja auf ner Vorlagendisku, warum sagt mir das denn keiner?

Na, dann kopier mal {{lang|bs-Cyrl|Бoснa и Xepцeговинa}} auf eine Seite im ANR und guck dir den HTML-Code in der Seitenvorschau an.

VG --PerfektesChaos 18:58, 15. Aug. 2019 (CEST)

In kyrillischer Kursivschrift werden auf meinem System aufgrund des Sprachen-Markups bs sogar Glyphen zur Darstellung verwendet, wie sie für Sprachen des untergegangenen Jugoslawiens üblich und für Sprachen der untergegangenen UdSSR eher unüblich sind, siehe Kyrillisches Alphabet#Kursive und aufrechte Formen. Da gibt es nichts zu meckern. Lieben Gruß —LiliCharlie (Disk.) 19:56, 15. Aug. 2019 (CEST)

Falscher Link bei ko-Hani

Beim Artikel Sudogwon wollte ich folgende Auszeichnung verwenden:

„Aus diesem Grund wurde die Region traditionell ''Gyeonggi jibang'' ({{lang|ko-Hang|경기 지방|ko-Hani=京畿地方|de=Region Gyeonggi}}) genannt.“

Das wird aber wie folgt dargestellt:

„Aus diesem Grund wurde die Region traditionell Gyeonggi jibang (
경기 지방
) genannt.“

Der Link geht zum (japanischen) Kanji statt korrekterweise dem (koreanischen) Hanja.

Grundsätzlich stellt sich mir eh die Frage, ob man bei zwei Schriften für die gleiche Sprache das in dieser Form rendern soll. M. E. wäre es besser, die beiden Schriften hintereinander darzustellen und nicht durch die deutsche Übersetzung auseinander zu reissen.

Ich habe es jetzt durch zwei mal lang gelöst. Das ist semantisch weniger aussagekräftig und reduziert etwas die „sexiness“/Mächtigkeit der Vorlage, aber die Darstellung ist so, wie ich sie erwarten würde:

„Aus diesem Grund wurde die Region traditionell ''Gyeonggi jibang'' ({{lang|ko-Hang|경기 지방}}, {{lang|ko-Hani|京畿地方|de=Region Gyeonggi}}) genannt.“

„Aus diesem Grund wurde die Region traditionell Gyeonggi jibang (
경기 지방
,
京畿地方
) genannt.“

Danke und Gruß, --S.K. (Diskussion) 07:36, 28. Sep. 2019 (CEST)

Insgesamt eine etwas neue Situation für mich und das Modul.

Wenn du erneut eine Sprache als Parameter angibst, hier ko-Hani, dann wird eigentlich eine andere Sprache erwartet, also englisch, französisch oder deutsch. Es geht dann auch um eine sinngemäße Übersetzung in eine Fremdsprache, nicht um eine alternative Verschriftung.
Eine andere Verschriftung derselben Sprache bedürfte eher des Schriftparameters:
- {{lang|ko-Hang|경기 지방|Hani=京畿地方|de=Region Gyeonggi}}
- 경기 지방
Dabei ist momentan die Reihenfolge noch nicht korrekt, aber anzustreben ist in der Tat die alternative Verschriftung unmittelbar auf den Stammbegriff folgend; bzw. auf die Transkription(en), die zuallererst dem Stammbegriff folgt, weil in einer anderen Schriftkultur ggf. eine alternative Transkription vorliegen könnte.
Da muss ich mich erstmal wieder in das Modul einlesen; ich erinnere mich dumpf, dass sowas mit Kyrillisch-Arabisch ging, weiß aber nicht mehr wie das in einer ehemaligen südlichen Sowjetrepublik ablief.
Worauf Hani verlinkt, kann ich korrigieren, nachdem ich die Bedeutung von Hanb Hang Hani Hano Hans Hant restlos verstanden habe.
Sollte es sich herausstellen, dass es Hani gleichzeitig als japanische und koreanische Schrift gäbe, bekomme ich ein philosophisches Problem. „Lateinische“ Schrift bleibt lateinische Schrift, auch wenn damit finnisch oder italienisch notiert wird, und ist keine Privatangelegenheit von „Latein“. Die ISO kennt nur eine sprachlose Schrift.
Für die Erforschung bedarf ich des langen Wochenendes mit Brückentag, für das sich bereits wieder ein Dutzend mehrstündige Aufgaben angesammelt haben, so dass ich mich frage, ob mir 3.–6. Ktober kenügend Kraft und Konzentration für knifflige Knobelaufgaben kredenzen werden.
Ganz allgemein verstehe ich inhaltlich null von dem, was ich da mache, und setze die Angaben der ISO um.

LG --PerfektesChaos 14:43, 28. Sep. 2019 (CEST)

Danke für die Erläuterungen. Zu einigen deiner Punkte:

„Eine andere Verschriftung derselben Sprache bedürfte eher des Schriftparameters“
- M.E. ist das nicht generisch genug. Es kann ja prinzipiell sein, dass man einen Begriff mit in mehreren Sprachen mit jeweils zwei Verschriftungen hat: Japanische und Chinesisch (siehe z.B. die Vorlage {{Zh}}, die mehrere Verschriftungen unterstützt) sind da sicher wegen des kulturellen Austausches gute Kandidaten. Oder dein kyrillisch/arabisch-Beispiel gemischt mit Chinesisch könnte ich mir auch vorstellen.
„Sollte es sich herausstellen, dass es Hani gleichzeitig als japanische und koreanische Schrift gäbe, bekomme ich ein philosophisches Problem.“
- Verstehe ich, aber würde mich nicht völlig überraschen, wenn eine Verschriftung vielleicht aus abstrakter technischer Sicht gleich ist, aber im Alltag/aus politischen Sensibilitäten heraus zwei Bezeichnungen hat, siehe Hangeul vs. Chosŏn’gŭl, die immerhin beide auf Koreanisches Alphabet weiterleiten.

Viel Erfolg und Zeit über das lange Wochenende, --S.K. (Diskussion) 08:39, 29. Sep. 2019 (CEST)

PS: Wenn ich so darüber nachdenke, dann ist eine kontextabhängige Auflösung einer Komponente nichts völlig ungewöhnliches:

de=Deutsche Sprache
de-CH=Schweizer Hochdeutsch
ko-Hang-KR=Koreanisch mit Hangeul-Schrift (Südkorea)
ko-Hang-KP=Koreanisch mit Chosŏn’gŭl-Schrift (Nordkorea)

--S.K. (Diskussion) 12:51, 29. Sep. 2019 (CEST)

Die Reihenfolge hatte ich über den Brückentag programmtechnisch gelöst.

Über Hani ja ko brüte ich aber weiterhin und bin mit dem Denken und Verstehen noch nicht fertig.

Mir kam ein unerwartetes altgriechisches Blockzitat in die Quere, das mich eine Woche Arbeitskraft kostete und immer noch nicht abgeschlossen ist.

LG --PerfektesChaos 14:05, 9. Okt. 2019 (CEST)

IPA pro Sprache?

Hallo @PerfektesChaos:

Bei Rom steht in der Einleitung:

„Rom (lateinisch Rōma; italienisch Roma [ˈroːma]), amtlich
Roma Capitale
, ist die Hauptstadt Italiens.“

„'''Rom''' ({{laS|Rōma}}; {{itS|Roma|IPA=ˈroːma}}), amtlich {{lang|it|''Roma Capitale''}}, ist die [[Italienische Gemeinden#Sonderstatus Roms|Hauptstadt]] [[Italien]]s.“

Eigentlich wollte ich es mit einer Vorlage formatieren, weil es ja der gleiche Begriff in zwei Sprachen ist:

„'''Rom''' ({{laS|Rōma|it=Roma|IPA=ˈroːma}}), amtlich {{lang|it|''Roma Capitale''}}, ist die [[Italienische Gemeinden#Sonderstatus Roms|Hauptstadt]] [[Italien]]s.“

was aber zu folgender Anzeige führt:

„Rom (lateinisch Rōma [ˈroːma], italienisch Roma), amtlich
Roma Capitale
, ist die Hauptstadt Italiens.“

Das ist nicht das gewünschte Ergebnis, weil die Aussprache „fälschlicherweise“ beim lateinischen und nicht beim italienischen Wort ausgegeben wird. Das Ergebnis ist, wenn man es durchdenkt, aber absolut nachvollziehbar und logisch, weil das IPA sich auf die Grundsprache der Vorlage bezieht.

Ich habe dann die folgenden Varianten probiert (schienen mir noch mögliche/vorstellbare Erweiterungen, die ins Parameterkonzept der Vorlage passen würden):

„'''Rom''' ({{laS|Rōma|it=Roma|it-IPA=ˈroːma}}), amtlich {{lang|it|''Roma Capitale''}}, ist die [[Italienische Gemeinden#Sonderstatus Roms|Hauptstadt]] [[Italien]]s.“

„Rom (), amtlich
Roma Capitale
, ist die Hauptstadt Italiens.“

oder

„'''Rom''' ({{laS|Rōma|it=Roma|IPA-it=ˈroːma}}), amtlich {{lang|it|''Roma Capitale''}}, ist die [[Italienische Gemeinden#Sonderstatus Roms|Hauptstadt]] [[Italien]]s.“

„Rom (), amtlich
Roma Capitale
, ist die Hauptstadt Italiens.“

Sie funktionieren aber nicht, weil die Parameter in der Form nicht bekannt sind.

Man könnte es natürlich so lösen:

„'''Rom''' ({{itS|Roma|IPA=ˈroːma|la=Rōma}}), amtlich {{lang|it|''Roma Capitale''}}, ist die [[Italienische Gemeinden#Sonderstatus Roms|Hauptstadt]] [[Italien]]s.“

„Rom (italienisch Roma [ˈroːma], lateinisch Rōma), amtlich
Roma Capitale
, ist die Hauptstadt Italiens.“

Aber dann wird die Gewichtung anders gesetzt, nicht von der ursprünglichen Sprache (Latein) zur heutigen (Italienisch), sondern anders herum.

Gibt es schon eine Möglichkeit, dass gewünschte mit einer Vorlagenverwendung zu erreichen oder siehst du das als mögliche/sinnvolle Erweiterung an, die du irgendwann in deiner unendlich verfügbaren freien Zeit einmal ermöglichen könntest? Hätte vermutlich den „netten“ Nebeneffekt, dass man auch bei mehreren Sprachen jeweils die Aussprache angeben könnte.

Danke und Gruß, --S.K. (Diskussion) 04:07, 9. Okt. 2019 (CEST)

Die Logik ist folgende:

Es gibt einen Stamm-Ausdruck: 1=
Zu diesem Stamm-Ausdruck gibt es Audio, IPA, Allerwelts-Transkriptionen, fachliche Transkriptionen, Übersetzungen usw.

Neben diesem Bezug auf den „Stamm-Ausdruck“ jetzt auch noch Bezugnahmen zweiter Ebene, hier auf eine Übersetzung einzuführen, würde mindestens jeden zukünftigen Autor ausbooten.

Es gibt bereits über 1000 sinnvolle Parameter.
Das sind so viele, dass sie noch nicht mal mehr einzeln auf der Doku aufgezählt werden können, sondern nur noch nach Mustern beschrieben werden können.
Jetzt noch Parameter zweiter Ordnung einzuführen knackt nicht nur Autoren, sondern auch systematische Auswerter (Skripte/Bots) und zukünftige Programmierer von Auswertungen des Wikitextes.
Das kann man noch nicht einmal mehr verständlich dokumentieren.

Wenn der Pflichtparameter 1= wegfiele, ist die Vorlage sofort eindeutig fehlerhaft eingebunden.

Nach deiner Theorie würde der optionale Parameter it= sofort zu einem Pflichtparameter. Das ist aber mit keiner trivialen Auswertung mehr zu analysieren.
Vielmehr sagt die umseitige Doku, dass nur 1= ein Pflichtparameter wäre; alles andere hingegen ist optional.

Im vorliegenden Fall würde ich als „Stamm-Ausdruck“ italienisch, ggf. mit Übersetzungen in moderne Sprachen wählen; englisch, französisch.

Dahinter käme das Wörtchen „aus“ oder vielleicht „nach antik“, „in der Antike“.
Dahinter der antike Name als neue {{lang}}.
Die italienische Form wie auch die anderer Sprachen sind aus der antiken Form entstanden. Dabei ist es bei englisch auch egal, ob die Briten sich das aus dem modernen Italienisch abgeguckt hatten, oder schon seinerzeit in Londinium. Wobei Englisch von den Grafschaften der Angeln kommt (Anglia; anglosaxon), und die waren ein halbes Jahrtausend nach den Römern auf der Insel eingefallen. Wobei ein Jahrtausend nach den Römern die Normannen die Gegend eroberten, und ihre romanische Sprache als Sprache der Führungsschicht etablierten, und das vielleicht auf diesem Weg nochmal importierten.

Die lang-Vorlage ist eigentlich dazu da, Übersetzungen oder Synonyme anzubieten. Bei Eigennamen, die in verschiedenen Zeitaltern gebräuchlich waren, ist die Logik eine andere: Roma wird nicht ins Lateinische übersetzt, wie ins Englische oder Deutsche; es ist auch kein Synonym eines Fachausdrucks. Vielmehr ist die italienische Form der moderne Eigenname zum originalen antiken Eigennamen der am selben Ort befindlichen Siedlung. Wobei die ollen Römer in ihren Inschriften keinen Strich über ein O gemeißelt hatten.

LG --PerfektesChaos 14:01, 9. Okt. 2019 (CEST)

Danke für die Erläuterung. Einige Kommentare/Bemerkungen:

Stammausdruck:
- Verstanden. Aber im Kern steckt, nachdem ich auch noch einmal darüber nachgedacht habe, hinter meinem Vorschlag oben eigentlich die Aufhebung dieser Asymmetrie der Bevorzugung einer Sprache, die die anderen Sprachen nur als "Beiwerk"/Übersetzung ansieht. Das richtige mentale Model für diesen Ansatz wäre dann eher das eines Begriffs der mit in verschiedenen Sprachen dargestellt wird. Jede Sprache hat dabei jeweils verschiedene Attribute. Dabei ist das Basisattribut jeder Sprache der Text in einer Standardschrift, dieser ist natürlich pro Sprache Pflicht. Audio, IPA, Transkriptionen, … sind dann optionale weitere Attribute die für jede Sprache angegeben werden können. Aber alle Sprachen sind gleichberechtigt, haben allenfalls eine Ordnung.
Das ganze wäre dann auch völlig unabhängig davon, ob ich einen antiken Begriff, Ortsname, Allerweltsbegriff oder was auch immer habe.

Meinungen? Einschätzungen?

--S.K. (Diskussion) 06:36, 10. Okt. 2019 (CEST)

Ich versteh schon, worauf du hinauswillst, aber das kapiert keiner mehr.

Die Verwendung in 100.000 Artikeln ist eine andere.
Schon die jetzige Parameterversorgung ist nicht mehr konventionell dokumentierbar, nur in Mustern zu erklären. Deins geht völlig dahin.

Dein Modell ist auch arg angreifbar, denn es setzt eine Identität eines Begriffs in vielen Sprachen und das gleichzeitig an. Schon das klappt nicht, wie wir seit H:INT und schon de-internen BKS wissen müssten.

Die Reichweite dieser Gleichsetzungen ist eng begrenzt.
Je weiter das vom Stamm-Begriff weggeht, desto breiter streut die Mehrdeutigkeit und Teekesselei.
Die Umkehrung der Übersetzungsrichtung ist in der Regel bereits nicht mehr möglich; Stamm-A lässt sich mit Fremd1-X oder Fremd1-Y übersetzen, aber die Übersetzung von Fremd1-X ist nicht notwendig Stamm-A, weil vielleicht eine Umschreibung. Ein Kugellager ist ein rundes Sofa, und das ist eine uneckige Chaiselongue. Deshalb ist menschlichen Sprachen die „Asymmetrie der Bevorzugung einer Sprache“ immanent, die du zum Verschwinden bringen möchtest.
Daraus ergibt sich aber gerade die „Bevorzugung einer Sprache“ , denn nur von der Ausgangssprache aus klappt das sternförmig in alle Richtungen, aber nicht wieder zurück und alle Übersetzungen „gleichberechtigt“ und ohne „Bevorzugung einer einzelnen“ geht das gleich gar nicht, insbesondere nicht Fremd1↔Fremd2. Wie hängen Pest, Ofen und der Staat Ungarn zusammen? Und die russischen, englischen oder französischen Übersetzungen von Pest und Ofen?
Historische Abfolgen ergeben sich gleich gar nicht.

Du kannst gern eine Meta-Vorlage für Linguisten bauen, in der du deine Ansichten in interne Aufrufe getrennter lang-Vorlagen umsetzt.

Und dann versuch mal, das verständlich zu dokumentieren, für alle Sprachen und Schriften der Welt, und alle Sonderfälle, und mit dem VisualEditor einsetzbar.
Und dann such mal Anwendungsfälle in unseren Artikeln.
Die Technikaffinität unserer Linguisten ist sehr unterschiedlich ausgeprägt.

Am Ende wird man dir höflich mitteilen: Wikipedia ist nicht Wiktionary.

Wer soll überhaupt einen semantischen Vorteil davon haben, dass angeblich fünf Begriffe in fünf Sprachen nebst vier IPA und drei Transkriptionen alle identisch wären, weil sie in derselben Vorlageneinbindung miteinander gleichgesetzt wurden? Sie sind natürlich nicht gleich, und höchstens ein Computerhirn könnte sich für diese Behauptung interessieren und sowas aus der Wikisyntax herauslesen und das dann auch noch falsch beigebracht bekommen. Menschliche Leser des Artikels sehen hingegen nicht die gemeinschaftliche Vorlageneinbindung, und in HTML wird diese hoffentlich auch nicht widergespiegelt.

Für die Leser des Artikels ist das jedenfalls desaströs, nicht nur für die Autoren: Eine schier endlose Aufreihung von Vokabeln, Sprachnamen, IPA, Transkription, Sprachname, Audio, Vokabel, Sprachname, Vokabel, Transkription, Sprachnamen, IPA, Sprachnamen, Vokabeln, Audio, Transkription. Wer braucht das wozu?

Dann besser mal einen Punkt machen, und in neuem Satz aus dem Griechischen über Latein und mittelhochdeutsch mit Lautverschiebung nach Englisch.

Erklär mal mit deiner Meta-Vorlage verständlich, wie man von κϋβερνήτης κϋβερνητήρ kybernetes gubernator gouverneur governor von Steuermann zu Kybernetik=Informatik und US-Bundesstaat kommt, nebst IPA und Audio überall.

Und dann erklär dem griechischen Reeder noch, warum er den Direktor einer Notenbank angestellt habe.

LG --PerfektesChaos 17:17, 10. Okt. 2019 (CEST)

Naja, ob das keiner mehr kapiert finde ich noch nicht eindeutig. Im Kern schwebt mir ja etwas wie folgt vor (ich wähle mal bewusst neue Vorlagennamen):

{{Begriff {{Sprache |code=la |text=Rōma }} {{Sprache |code=it |text=Roma |IPA=ˈroːma }} }}

Damit wird die "flachgeklopfte" lange Liste von Parametern von {{Lang}}, die man nur noch als Gruppen von Parametern beschreiben kann, viel klarer, weil man ja pro Klasse eine "Unter-/Detailvorlage" hat. Diese "Unter-/Detailvorlagen" sind dann schlicht klassische Vorlagen mit eindeutigen Parameternamen. Was man als "neues" Konzept braucht ist das einer Liste von "Unter-/Detailvorlagen". Aber das haben wir ja de facto schon heute z.B. bei den Eisenbahnern mit den Infoboxen für Strecken (du kennst sicher noch mehr Beispiele).

Inhaltlich habe ich ja ganz bewusst Begriff und nicht Wort oder ähnliches geschrieben, sprich, die Gruppe steht für ein klares semantisches Konzept und für das wird die jeweilige Bezeichnung in verschiedenen Sprachen angegeben. Sprich die Gruppe steht nicht für Note, sondern

Note (Musik) mit {{Begriff {{Sprache |code=de |text=Note }} {{Sprache |code=en |text=note }} }} vs.
Schulnote mit {{Begriff {{Sprache |code=de |text=Note }} {{Sprache |code=en |text=grade }} }}

Sprich, die Vorlage entspricht einer der Bedeutungen in Wiktionary zu einem Wort, bei wikt:Note wären die Beispiele oben die Bedeutungen [1] bzw. [3]. Damit sind die Interwiki- und BKS-Aspekte, die du ansprichst m.E. adressiert.

Und ja, das kann man missbrauchen, wenn man es übertreibt und 50 verschiedene Sprachen mit jeweils mehreren Transkriptionen, IPA und was auch immer nutzt. Aber das ist mehr dem Einsatz als dem Konzept geschuldet, und dann müsste man eher mal mit der Person reden, die die Vorlagen in dieser Form einsetzt, dass dafür Wiktionary vielleicht der bessere Ort ist.

--S.K. (Diskussion) 07:56, 11. Okt. 2019 (CEST)

Etwas näher am jetzt ließe sich das wie folgt umsetzen:

{{Begriff |sprache1={{Sprache |code=la |text=Rōma }} |sprache2={{Sprache |code=it |text=Roma |IPA=ˈroːma }} }}

Dann müsste man "nur" TemplateData beibringen, dass die Parameter spracheX vom Typ template sind und die erlaubten Vorlagen sind Sprache. Das müsste der VisualEditor interpretieren können und es sollte umsetzbar und für "Normalsterbliche" nutzbar.

{{Sprache}} müsste dabei ein für {{Begriff}} leicht parsebares Format (JSON?) liefern.

Nicht völlig utopisch, oder?

--S.K. (Diskussion) 19:47, 11. Okt. 2019 (CEST)

BK

Das ist nicht Thema dieser Vorlage hier.

Einen Datentyp template gibt es nicht und kann es nicht geben, weil die inneren Vorlageneinbindungen zum Zeitpunkt der Auswertung der äußeren Vorlage bereits expandiert sind und der äußeren Vorlage grundsätzlich nicht bekannt ist, wie diese Wertzuweisungen zustandekamen.

Hinsichtlich der Namensgebung für Vorlagen sind wir nicht mehr so lasch wie vor anderthalb Jahrzehnten bei wenigen Hundert Vorlagen; die beiden von dir gewählten Namen verdeutlichen nicht hinreichend den Sinnzusammenhang. Unter mittlerweile 70.000 Vorlagen und bei absehbar mickrigen Einbindungszahlen ist eine unspezifisch Sprache genannte Vorlage nur verwirrend und führt zur Konfusion mit der hier 100.000-fach eingebundenen Vorlage und stört die richtige Artikelarbeit.

Der Sinn der gesamten Aktion erschließt sich mir immer noch nicht.

Wie jetzt schon mehrfach gefallen: Wikipedia ist kein Wiktionary.
Oder, wie es offiziell an erster Stelle heißt: In Artikeln sollen in erster Linie Begriffe erläutert und keine gängigen deutschen Wörter erklärt werden, wie dies ein Wörterbuch macht.
Ich wüsste keinen einzigen Artikel, wo eine solche Wortfeld-Fremdsprachen-Auflistung zulässig oder sinnvoll wäre.
In einem Artikel zu Medizin-Themen gibt es eine kurze Erläuterung, wo griechisch-lateinisch der Name für die Krankheit oder den Knochen herkäme. In manchen Artikeln gibt es einen eigenen Abschnitt zur Wortherkunft, mit in richtiger Sprache erläuterter Geschichte, wann und wo der Begriff entstanden sei und wie er sich verbreitet habe und wie sich die Bedeutung gewandelt hätte.
Die hier beabsichtigte standardisiert generierte Aufzählung von Wörtern mit ihren Übersetzungen und Aussprache in verschiedenen Sprachen ist gegenüber richtig geschriebenen Erläuterungen blass und langweilig, und was das in unseren Artikeln zu suchen habe und wen das interessieren solle wurde immer noch nicht verdeutlicht.

VG --PerfektesChaos 20:28, 11. Okt. 2019 (CEST)

„Datentyp template gibt es nicht und kann es nicht geben“

Es geht bei TemplateData ja um den Zeitpunkt der Erstellung/Bearbeitung der Vorlage und nicht um den Zeitpunkt der Vorlagen-Ausführung/-Auswertung, da spielt TemplateData ja gar keine Rolle. Deswegen kann es den Datentyp schon geben. Dem Aspekt, dass die äußere Vorlage zuerst ausgewertet wird und die innere Vorlage nur das Ergebnis dieser Auswertung bekommt habe ich ja Rechnung getragen, indem ich gesagt habe, dass das Ergebnis der äußeren Vorlage ein parsebares Format haben muss (JSON), dass dann die innere Vorlage auswerten kann. Die innere Vorlage braucht es „nur“, weil die Wikipedia-Vorlagensyntax nur elementare Typen als Parameter kennt und (noch?) keine komplexen Typen/Objekte erlaubt. Die innere Vorlage simuliert/kompensiert das.

Namensgebung

Wir führen ja erst einmal eine Anforderungs-/Designdiskussion, keine Implementierungsdiskussion. Die aktuelle Namensgebung soll dabei die intendierte Semantik illustrieren, mehr nicht. In der Implementierung könnte die innere Vorlage z.B. {{Begriff/Sprache}} heißen oder auch ganz anders, aber das ist für die jetzige Diskussion m.E. nicht ausschlaggebend.

Sinn

Da verweise ich auf den Ausgangspunkt der Diskussion. Ich bin auf eine konkrete Situation gestoßen, die ich wie oben geschildert nicht adäquat abbilden konnte. Dafür suche ich eine Lösung. Der Rest der Diskussion liefert Hintergrundüberlegungen/einen konzeptionellen Rahmen für die möglichen Lösungen, nicht mehr und nicht weniger. Und nein, ich will nicht den Abschnitt Etymologie eines Artikels durch eine Einbindung der Vorlage ersetzen, ich bin primär „nur“ auf der Suche nach einer Lösung für das Eingangsproblem. Wenn im Rahmen dessen die Vorlage einfacher und verständlicher wird, ist das ein positiver Seiteneffekt, da du ja zurecht auf die Mächtigkeit und dementsprechend schwere Dokumentierbarkeit des Status quo hingewiesen hast.

--S.K. (Diskussion) 10:25, 12. Okt. 2019 (CEST)

Ich kann dir leider nicht überallhin folgen. Könntest du versuchen, uns das von dir Gemeinte anhand einer Vorlagenspielwiesen-Version der von dir vorgeschlagenen Vorlage {{Begriff}} (und/oder einer Spielwiesen-Version der vorgeschlagenen Vorlagen-Dokumentation einschließlich diverser Anwendungsbeispiele mit Quellcodes und deren Effekten) näherzubringen? Lieben Gruß —LiliCharlie (Disk.) 20:21, 11. Okt. 2019 (CEST)

Kann ich einmal versuchen, aber ich kenne LUA nicht wirklich und habe auch immer nur sporadisch Zeit für Wikipedia und noch viel seltener länger am Stück. Aber ich kann auf die Schnelle versuchen, die Idee anhand einer Expansion der Vorlagen darzustellen.

{{Begriff |sprache1={{Sprache |code=la |text=Rōma }} |sprache2={{Sprache |code=it |text=Roma |IPA=ˈroːma }} }}
Expandiert zu {{Begriff |sprache1={ "code": "la", "text": "Rōma" } |sprache2={ "code": "it", "text": "Roma", "IPA": "ˈroːma" } }} (BTW: Das könnte jemand der JSON kennt auch manuell ohne die Vorlage Sprache in den Quelltext schreiben).
Expandiert zu dem Text wie initial beschrieben.

--S.K. (Diskussion) 10:25, 12. Okt. 2019 (CEST)

Ähnliche Situation bei Latakia, diesmal mit dem Parameter DMG, den man in dieser Situation/Form nicht verwenden kann:

„'''Latakia''', auch ''Lattakia'', ''Ladiqiya'', das [[antike]] ''Laodicea'' oder ''Laodikeia'' ({{elS|Λαοδίκεια|tr=Lazkiye|ar=اللاذقية|DMG=al-Lāḏiqiyya}}, im Dialekt ''il-Lāzʾiyye''), ist mit ihrem [[Hafen Latakia|Hafen]] die einzige große [[Syrien|syrische]] Hafenstadt am [[Mittelmeer]] und zugleich Hauptstadt des [[Gouvernement Latakia|Gouvernements Latakia]].“

„Latakia, auch Lattakia, Ladiqiya, das antike Laodicea oder Laodikeia (, im Dialekt il-Lāzʾiyye), ist mit ihrem Hafen die einzige große syrische Hafenstadt am Mittelmeer und zugleich Hauptstadt des Gouvernements Latakia.“

--S.K. (Diskussion) 06:59, 21. Okt. 2019 (CEST)

Es ist überhaupt nicht Sinn und Zweck dieser Vorlage, in einem einzigen Aufruf zwei Dutzend Übersetzungen und Transkriptionen und Audio und IPA für ein halbes Dutzend Sprachen zu liefern und leserverständlich automatisiert als Liste zu formatieren.
- Es geht zuallererst darum, zu dem Stammbegriff Transkriptionen und Audio und IPA zu liefern.
- Als Sahnehäubchen, zur Erleichterung für die Autoren und zur Verbesserung der Performance lässt sich noch die Übersetzung in jeweils genau eine Sprache+Schreibung angeben.
- Der Sinn der Vorlage ist die Ausstattung des Stammbegriffs mit den geeigneten Auszeichnungen für Schriftsystem und Sprache, damit Software-Systeme das richtig entsprechend der Wünsche und Ausstattung der Leser darstellen können.
- Die historische Programmierung, bevor ich dies verfeinert hatte, kannte ganze zwei unbenannte Parameter für Textsegmente +style. Heute sind es 1000. Und damit basta.
- Ende von Fahnenstange.
Was du da anstrebst, führt zu dann absolut nicht mehr durchschaubaren Kompositionen von Parameternamen und eine für keinen späteren Autor noch nachvollziehbare Auswirkung deines Parameterbreis.
- Abgesehen davon würde es in den folgenden Jahrzehnten den nachfolgenden Programmierern nicht zu verantwortende Schulden bei der Weiterentwicklung und Pflege der Programmierung in Lua oder vielleicht anderen Sprachen aufbürden.
- Und deine Vorstellungen von JSON im ANR gehen nun mal gar nicht. Schon einige Vorlagenprogrammierer hatten gemeutert, als sie sich für erweitertes TemplateData mit JSON befassen mussten; im ANR hat das nix am Suchen.
Zwei Beispiele, wie halt solche Begrifflichkeiten aussehen:
1. Das '''Allod''' ([[altniederfränkisch]] ''allōd'', „volles Eigentum“, zu ''all'' „voll, ganz“ und ''ōd'' „Gut, Besitz“; [[mittellatein]]isch ''{{lang|la|allod}}'' oder ''{{lang|la|allodium}}''), auch '''Eigengut''' oder '''Erbgut''' oder '''freies Eigen''',
2. '''Iraklio''' ({{elS|Ηράκλειο}} {{N.Sg.}}, [[Giechische Toponyme#Diglossie|veraltet auch]] '''Iraklion''', in seitens der Stadt selbst verwendeter Schreibung '''Heraklion''', {{grcS|Ἡράκλειον}}, '''Herakleion''', im Mittelalter ''Chandakas'', in der Zeit der venezianischen Herrschaft ''Candia'', danach {{trS|Kandiye}}, {{elS|Μεγάλο Κάστρο|Megalo Kastro|prefix=1}}
  Worauf soll sich denn dann der Schalter prefix=1 beziehen, und wie machst du das in deinem konfusen Parametermix den Autoren und der Vorlagenprogrammierung klar?
  Und was ist daran so schlimm, in verständlicher und durch verbindende Wörtchen gegliederter Form die umseitige Vorlage mehrfach einzubinden?
Es gibt überhaupt keinen Grund, solche komplexen Darstellungen vieler Sprachen durch nur einen einzigen Vorlagenaufruf mit ein oder zwei Dutzend Parameternamen im Artikel darzustellen, und dabei zu suggerieren, alle Parameterwerte würden exakt dieselbe Bedeutung haben, was schlicht nicht stimmt.
- Die einzigen, die ein Interesse an der angeblichen jedoch fälschlichen Gleichsetzung aller dieser Begriffe haben könnten, wären Quelltext-auswertende Software-Systeme.
- Für das HTML-Dokument und damit für die Leser kommt hingegen exakt dasselbe heraus, egal mit wie vielen Vorlagenaufrufen realisiert.
Das, was du da anstrebst, ist ein Lexem.
- Das kannst du gern in deiner eigenen Vorlage umsetzen, mit 100.000 Parameternamen, von mir aus auch mit JSON.
- Das ist allerdings keine Aufgabe der Wikpedia, wie WP:WWNI ausdrücklich feststellt, sondern klassisch des Wiktionary.
- Neuerdings steigt sogar Wikidata in dieses Geschäft ein und pfuscht in die Computerlinguistik mit einer plumpen und naiven Vorstellung der Gleichsetzung von Begriffen hinein.
Mal ein schlichtes Beispiel: „Platz“. Englisch: place, square, location, position, point, room, space.
- Rückübersetzt:
  - location ist Anschrift, Wohnsitz, Stelle, Ort, Platz.
  - Trafalgar place gibt es nicht, das Ding heißt Trafalgar Square aber im Deutschen nicht Trafalgar-Quadrat.
  - Ein Fußballplatz ist kein football place sondern ein football field und damit ein Fußballfeld.
  - Der Rennfahrer kommt nicht auf den 3. place, sondern in der 3. position ins Ziel.
- Diese stumpfe Gleichschaltung von Lexemen und der Kinderglaube an die 1:1-Bedeutungsumschreibung ist so armselig, so euphorisch frühe 1990er wie nur was.
Für diese Vorlage: EOD.

VG --PerfektesChaos 12:31, 21. Okt. 2019 (CEST)

Du baust lauter Scheinargumente auf und regst dich dann über diese auf (sogar verständlich, wenn es so wäre wie du argumentierst) ohne meine Erklärungen mal in Ruhe zu lesen. Weil

nein, ich will nicht beliebige Wörter und Bedeutungen zu einem Lexem mischen,
nein, es werden nicht Begriffe gleichgesetzt,
nein, ich will nicht x tausend Parameter haben. Im Gegenteil würde mein Vorschlag die jetzigen Tausend Parameter auf zwei Vorlagen aufteilen mit einmal vielleicht 3-5 Parameter (je nachdem wie viele Sprachen man in einer Vorlagenverwendung gleichzeitig unterstützt) und einmal ca. 10-15 (je nachdem wie viele Arten von wissenschaftlichen Transkriptionen man neben den Basisparametern unterstützt),
nein, ich will kein JSON im Artikelsnamensraum stehen haben,
nein, ich will Wikipedia nicht in Wiktionary verwandeln,
nein, ich stecke nicht im "1990er-Kinderglauben" fest,
nein, nein, nein.

Aber ja, in einem sind wir uns einig, auf der aktuellen Basis lohnt sich keine weitere Diskussion.

--S.K. (Diskussion) 19:21, 21. Okt. 2019 (CEST)

'deutsch' fehlt bei nur einer Übersetzung.

In der Dokumentation steht:

Der Übersetzung wird der Sprachname vorangestellt; dieser (abgesehen von „deutsch“) auch verlinkt.

Allerdings ist das derzeit nicht der Fall, wenn nur die deutsche Übersetzung angegeben ist:

{{lang|en|Foo|de=Bar}} ergibt:

Foo

Ist das Absicht; warum ist das nicht dokumentiert und kann man die Sprachen-Nennung erzwingen? Dieser IP-Edit hat mich auf dieses Problemchen gebracht. -- Michi 23:42, 7. Apr. 2020 (CEST)

Die Formatierung folgt Wikipedia:Fremdwortformatierung und diese sieht ein derartig vorangestelltes Wort nicht vor.
Die anderen (Dritt-)Sprachen stehen kursiv (wenn lateinisch verschriftet); die deutsche Übersetzung gerade und dafür in Anführungszeichen.
In den allermeisten Fällen ist trivial erkennbar, wo ein deutschsprachiges Wort vorliegt und wo nicht.
- Die Philosophie (von altgriechisch φίλος phílos ‚Freund‘ und
  σοφία
  ‚Weisheit‘) ist …
Sollte das im Einzelfall irgendwo einmal unklar sein, weil das deutsche Wort – vielleicht selbst ein Fremdwort – nicht als deutsch wahrnehmbar wäre, dann mag man dies individuell außerhalb der Vorlage ergänzen und nach Belieben formatieren.
Beim benannten Diff hatte es hingegen keinerlei Unklarheit gegeben, und es war recht überflüssig und gouvernantenhaft, das für die letzten Deppen nochmal zu erklären und aufzublähen. An die nächste Erwähnung von Paris schreiben wir jetzt dran, dass es sich dabei um eine Stadt handeln würde?
Es gibt Tausende von Bestandseinbindungen, auch in den abgeleiteten Sprachnamenvorlagen, die das ebenfalls nicht erwarten. Insofern würde sich eine Umprogrammierung mal eben so ohnehin verbieten.
Es gibt Zigtausende von Erklärungen, die keinerlei Vorlage benutzen und es ebenso standardisiert formatieren und eine offenkundige deutsche Übersetzung ebenfalls nicht als „deutsch“ kennzeichnen; wie es halt seit einem Dutzend Jahren gelebte Praxis ist.

LG --PerfektesChaos 14:42, 8. Apr. 2020 (CEST)

Schriftname gleich Sprachname

Bei Ulaanbaatar habe ich folgende Formatierung verwendet:

'''Ulaanbaatar''' ({{mnS-Cyrl|Улаанбаатар|mn-Mong=ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ|de=Roter Held}})

Das führt zu folgendem Ergebnis:

Ulaanbaatar (mongolisch Улаанбаатар, mongolisch ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ deutsch ‚Roter Held‘)

Der erste Link führt zu Mongolische Sprache, der zweite korrekterweise zu Mongolische Schrift, der Unterschied ist aber nicht einfach zu sehen, weil beide Links mit „mongolisch“ beschriftet sind. --S.K. (Diskussion) 20:01, 2. Aug. 2020 (CEST)

Sprachvariante wird nicht richtig angezeigt

Bei Luzerne wird in der Einleitung die britische und amerikanische Bezeichnung angegeben:

„Die Luzerne […], britisches Englisch lucerne, amerikanisches Englisch alfalfa genannt, ist eine […]“

Eigentlich wollte ich das so darstellen:

{{enS-GB|lucerne|en-US=alfalfa}}

was aber aktuell nicht wie gewünscht/erwartet funktioniert:

britisches Englisch lucerne, englisch alfalfa

Auch anders herum klappt es nicht:

{{enS-US|alfalfa|en-GB=lucerne}} ==> amerikanisches Englisch alfalfa, englisch lucerne

lang direkt zeigt ein anderes Verhalten, es kennt den Parameter mit Ländervariante nicht:

{{lang|en-GB|lucerne|en-US=alfalfa}} ==>
lucerne
{{lang|en-US|alfalfa|en-GB=lucerne}} ==>
alfalfa

--S.K. (Diskussion) 03:33, 14. Aug. 2021 (CEST)

Das ist keine Übersetzung.

Du kannst und darfst nicht en in en „übersetzen“.

Du könntest höchstens eine Umschrift in kyrillischen oder griechischen Buchstaben angeben.

Sprachvarianten sind eigenständige Haupt-Terme, mit eigenständiger Audio-Datei und eigenständiger IPA, und grundsätzlich nicht als „Übersetzung“ geeignet.

lateinisch Medicago sativa, englisch lucerne, englisch alfalfa – tja, und was brachte dir in diesem Fall 2×„englisch“?

Du hast ja bereits eine funktionierende Lösung angegeben. Wo ist Problem?

Es ist grundsätzlich nicht Sinn der Sache, in eine einzige Vorlageneinbindung maximal viele Wortformen als Parameter hineinzuquetschen. Das hat auch keine semantische Folgen; bei Auswertung unserer Artikel durch eine Software zählt nicht der Wikitext, sondern das HTML-Dokument, und das kennt nur eine zusammenhanglose Aufzählung von Wörtern ohne eine semantische Beziehung untereinander. Es ist völlig egal wie viele Vorlageneinbindungen daran beteiligt waren.

Die angebotene Lösung bietet im Vergleich zu früheren Zeiten maximal viel Komfort bei der Angabe eines Begriffs, seiner Umschriften und Übersetzungen. Mehr hält die Programmlogik nicht mehr aus (ist ohnehin schon nur noch durch mich persönlich zu pflegen, gnade meinen Nachkommen) und kann auch von keinem Autor dann noch robust bedient werden.

VG --PerfektesChaos 13:33, 15. Aug. 2021 (CEST)

Okay, wenn das das Design ist, dass man nur die Kombination Sprache-Schrift angeben soll, aber nicht Sprache-Staat (IETF würde ja sogar Sprache-Schrift-Staat erlauben), dann wäre meine Hoffnung, dass dann - wie bei {{Lang}} auch - eine Fehlermeldung kommt, das man die Vorlage jenseits ihrer Spezifikation/ihres Einsatzzweckes nutzt. Dein Lateinisch-Beispiel zeigt ja, dass das sonst ziemlich verwirrend wird. --S.K. (Diskussion) 15:20, 15. Aug. 2021 (CEST)

Anonym

Suche

Vorlage Diskussion:Lang

Namensräume

Mehr

Seitenaktionen

Inhaltsverzeichnis

Kanji und Hanja

Verwendung

Falsche Sprachangaben?

Frage zu Artikeln mit japanischen Namen

Wo Vorlage überall einbauen?

Was sollen die ganzen verschiedenen Schrifttags bei Japanisch?

unbekanntes iso-kürzel

Referenzliste

Mongolisch

lang|ja gibt auf Android falsche Zeichen aus, z.B. 土 statt 生

CJK range scramble

Verwendung der Vorlage für englischsprachige Eigennamen?

Text mit Sprachcode `grc-Latn` wird ungewollt kursiv gedruckt

Fremdsprachige Lemmata und interne Links

Diese Vorlage ist nicht ausgreift und die Pflegebarkeit des Quellcodes ist nicht mehr gegeben.

formatfehler

Sprachcode no wird nicht unterstützt

Widerspruch mit WP:TYPO

lang ist kürzer als Sprache...

Font zh-Hant und zh-Hans zu groß

Falsche Ausgabe bei Malayalam

Parameter LONG

bs

Falscher Link bei ko-Hani

IPA pro Sprache?

'deutsch' fehlt bei nur einer Übersetzung.

Schriftname gleich Sprachname

Sprachvariante wird nicht richtig angezeigt

Navigation

Navigation

Mitmachen

Wikiwerkzeuge

Wikiwerkzeuge

Anonym

Suche

Vorlage Diskussion:Lang

Kanji und Hanja

Verwendung

Falsche Sprachangaben?

Frage zu Artikeln mit japanischen Namen

Wo Vorlage überall einbauen?

Was sollen die ganzen verschiedenen Schrifttags bei Japanisch?

unbekanntes iso-kürzel

Referenzliste

Mongolisch

lang|ja gibt auf Android falsche Zeichen aus, z.B. 土 statt 生

CJK range scramble

Verwendung der Vorlage für englischsprachige Eigennamen?

Text mit Sprachcode grc-Latn wird ungewollt kursiv gedruckt

Fremdsprachige Lemmata und interne Links

Diese Vorlage ist nicht ausgreift und die Pflegebarkeit des Quellcodes ist nicht mehr gegeben.

formatfehler

Sprachcode no wird nicht unterstützt

Widerspruch mit WP:TYPO

lang ist kürzer als Sprache...

Font zh-Hant und zh-Hans zu groß

Falsche Ausgabe bei Malayalam

Parameter LONG

bs

Falscher Link bei ko-Hani

IPA pro Sprache?

'deutsch' fehlt bei nur einer Übersetzung.

Schriftname gleich Sprachname

Sprachvariante wird nicht richtig angezeigt

Navigation

Wikiwerkzeuge

Seitenwerkzeuge

Weitere Projekte

Versteckte Kategorien

Text mit Sprachcode `grc-Latn` wird ungewollt kursiv gedruckt