Mehrsprachigkeit, Beurteilung

[beatovich]

hallo

Aufgabe: Erstelle eine Mehrsprachigkeit für die Kissthemes, die berücksichtigt, dass jede Seite mehr oder minder vollständige Übersetzungen beinhaltet mit jeweils eigenen Sprachoptionen.

Lösungsnsatz:

Syntaxguideline

html lang=de

Übersetzungstätigkeit: Konvertiere

<p>Deutsch</p>

nach

<p lang="multi">
<span lang="it">Italiano</span>
<span lang="fr">Francais</span>
<span lang="de">Deutsch</span>
</p>

Elementtypen spielen keine Rolle.

Falls eine Sprachwahl vorliegt, wird diese im html-Element in data-lang gspeichert.

Das zugehörige CSS.

In _.lang ist der Wert von html lang gespeichert. Dieser Wert bleibt konstant.

	html[lang="'+_.lang+'"] [lang="multi"] > :not([lang="'+_.lang+'"]){display:none}\
	html[data-lang="en"] [lang="multi"] > [lang="en"],\
	html[data-lang="es"] [lang="multi"] > [lang="es"],\
	html[data-lang="de"] [lang="multi"] > [lang="de"],\
	html[data-lang="fr"] [lang="multi"] > [lang="fr"],\
	html[data-lang="it"] [lang="multi"] > [lang="it"]{display:initial}\
	html[data-lang] [lang="multi"] > [lang]:last-of-type{display:initial}\
	html[data-lang="en"] [lang="multi"] > [lang="en"] ~ [lang="'+_.lang+'"],\
	html[data-lang="es"] [lang="multi"] > [lang="es"] ~ [lang="'+_.lang+'"],\
	html[data-lang="de"] [lang="multi"] > [lang="de"] ~ [lag="'+_.lang+'"],\
	html[data-lang="fr"] [lang="multi"] > [lang="fr"] ~ [lang="'+_.lang+'"],\
	html[data-lang="it"] [lang="multi"] > [lang="it"] ~ [lang="'+_.lang+'"]{display:none}\

Das funktioniert, sollte aber rationeller notiert werden.

Allgemeine Mechanik

• WENN COOKIE -> data-lang = Cookie Wert
• SONST WENN QUERSTRING -> data-lang = QS Wert
• SONST keine spezifische Usersprache.

Es ist zu erwarten, dass das Dokument-html von Autoren erstellt wird, die sehr wenig über html wissen. Die Syntax muss entsprechend einfach bleiben.

Das hiessige Konzept stellt eine unnötige Schrierigkeit. Die Fallback-Sprachversion muss die letzte notierte Version sein (CSS kann anders nicht greifen.) Sprachversionen müssen unmittelbare Kinder des Elements mit lang="multi" sein.

Einschränkung: Diese Form von Mehrsprachigkeit manipuliert keine einzelnen Attributwerte. Betroffen sind Attribute wie aria-label, title

Eine funktionierende Implementation liegt vor.

Ich möchte jetzt eure Kritik hören.

[pl]

Es ist zu erwarten, dass das Dokument-html von Autoren erstellt wird, die sehr wenig über html wissen. Die Syntax muss entsprechend einfach bleiben.

Autoren sollten mit der Sprachthematik gar nichts zu tun haben. Sondern einfach nur in ihrer Sprache schreiben.

MfG

[beatovich]

hallo

Es ist zu erwarten, dass das Dokument-html von Autoren erstellt wird, die sehr wenig über html wissen. Die Syntax muss entsprechend einfach bleiben.

Autoren sollten mit der Sprachthematik gar nichts zu tun haben. Sondern einfach nur in ihrer Sprache schreiben.

aha!

[Gunnar Bittersmann]

@@beatovich

Sprachversionen müssen unmittelbare Kinder des Elements mit lang="multi" sein.

Welches es nicht geben sollte. multi ist kein gültiger Wert fürs lang-Attribut; das dürfen nur Sprachkürzel sein. Verwende bspw. class="multilingual".

Das funktioniert, sollte aber rationeller notiert werden.

Du willst also dasjenige Kind eines .multilingual{:.language-css}-Containers (um beim obigen Vorschlag zu bleiben) anzeigen, dessen Sprache mit der in _.lang vorgegebenen überseinstimmt, und wenn es kein solches gibt, dann das letzte?

Also alle anderen ausblenden (hier in Sass-Syntax mit der vorgegebenen Sprache in $lang):

$lang: 'en';

.multilingual > :not([lang|="#{$lang}"]):not(:last-child),
.multilingual > [lang|="#{$lang}"] ~ :last-child
{
	display: none;
}

Es werden alle Kindelemente von .multilingual ausgeblendet, deren Sprache nicht mit $lang übereinstimmt, außer dem letzten, was als Defaultsprache erhalten bleibt. Wenn es ein Kindelement von .multilingual gibt, dessen Sprache mit $lang übereinstimmt und dieses nicht das letzte ist, dann wird auch das letzte ausgeblendet.

☞ Codepen zum Rumspielen

Zum Vergleichen habe ich |= verwendet. Womöglich ist aber nicht [lang|="…"], sondern :lang(…) die bessere Wahl. ☞ Stylen anhand von Sprachattributen

Was es mit dem html[data-lang] bei dir auf sich hat, habe ich nicht so ganz verstanden.

LLAP 🖖

[beatovich]

hallo

@@beatovich

Sprachversionen müssen unmittelbare Kinder des Elements mit lang="multi" sein.

Welches es nicht geben sollte. multi ist kein gültiger Wert fürs lang-Attribut; das dürfen nur Sprachkürzel sein. Verwende bspw. class="multilingual".

Kein Problem.

Das funktioniert, sollte aber rationeller notiert werden.

Du willst also dasjenige Kind eines .multilingual{:.language-css}-Containers (um beim obigen Vorschlag zu bleiben) anzeigen, dessen Sprache mit der in _.lang vorgegebenen überseinstimmt, und wenn es kein solches gibt, dann das letzte?

nicht ganz, siehe unten.

Also alle anderen ausblenden (hier in Sass-Syntax mit der vorgegebenen Sprache in $lang):

$lang: 'en';

.multilingual > :not([lang|="#{$lang}"]):not(:last-child),
.multilingual > [lang|="#{$lang}"] ~ :last-child
{
	display: none;
}

Es werden alle Kindelemente von .multilingual ausgeblendet, deren Sprache nicht mit $lang übereinstimmt, außer dem letzten, was als Defaultsprache erhalten bleibt. Wenn es ein Kindelement von .multilingual gibt, dessen Sprache mit $lang übereinstimmt und dieses nicht das letzte ist, dann wird auch das letzte ausgeblendet.

☞ Codepen zum Rumspielen

Zum Vergleichen habe ich |= verwendet. Womöglich ist aber nicht [lang|="…"], sondern :lang(…) die bessere Wahl. ☞ Stylen anhand von Sprachattributen

SCSS ist hier noch keine Option.

Was es mit dem html[data-lang] bei dir auf sich hat, habe ich nicht so ganz verstanden.

<html lang="de" data-lang="fr" data-lang-options="de fr it">

• lang="de" stellt hier die Hauptsprache dar, welche auch durch Sprachwahl nicht verändert wird.
• data-lang="fr" stellt (z.B) die Sprache dar, welche durch User-Action, Cookie oder Querystring gewählt wird/wurde, dieses Attribut kann auch fehlen.
• data-lang-options="de fr it" diese Sprachwahlbuttons werden auf dieser Seite zur Verfügung gestellt.

Es wäre falsch lang selber zu ändern, da ja die Mehsprachigkeit nur für Teile des Dokuments erstellt ist.

In dem Fall ist lang="de" die Fallback-Sprache, falls die gewünschte Sprachversion nicht für einen bestimmten Bereich verfügbar ist.

[Gunnar Bittersmann]

@@beatovich

SCSS ist hier noch keine Option.

Ja, das hatte ich der Einfachheit halber im Codepen verwendet. Du generierst dein Stylesheet anders, um das _.lang da rein zu bekommen. Nur wie? JavaScript?

LLAP 🖖

[beatovich]

hallo

@@beatovich

SCSS ist hier noch keine Option.

Ja, das hatte ich der Einfachheit halber im Codepen verwendet. Du generierst dein Stylesheet anders, um das _.lang da rein zu bekommen. Nur wie? JavaScript?

Ja. Aber ich kann zur Zeit, wo ich das CSS genriere nur das Attribut lang aus dem html Element auswerten, da ja die andere Variable data-lang später noch verändert wird. Trotzdem muss ich wegen der Cookie und QueryString auswertung bereits korrekt reagieren, das heisst, die vorgesehenen Fälle müssen sofort korrekt gerendert werden.

Praktisch haben wir es immer nur mit 2-4 sprachversionen zu tun. Ich kann also mit dieser Version leben.

Es nimmt mich aber wunder, ob man das doch etwas generalisieren kann, und besonders, ob ich diese Bedingung wegbekomme, dass die Fallbackversion (welche dem lang Attribut im html Element entsprechen soll) immer zuletzt notiert werden soll. Das stört mich aktuell am meisten.

[Gunnar Bittersmann]

@@beatovich

Ja. Aber ich kann zur Zeit, wo ich das CSS genriere nur das Attribut lang aus dem html Element auswerten, da ja die andere Variable data-lang später noch verändert wird. Trotzdem muss ich wegen der Cookie und QueryString auswertung bereits korrekt reagieren, das heisst, die vorgesehenen Fälle müssen sofort korrekt gerendert werden.

Du ermittelst also mit JavaScript aus Cookie und QueryString die Sprache. Dann kannst du doch genau die gezeigte Regel mit JavaScript generieren: neuer Pen.

Wenn du Browser unterstützen musst, die die Backticks nicht verstehen, dann mit Stringkonkatenation.

ob ich diese Bedingung wegbekomme, dass die Fallbackversion (welche dem lang Attribut im html Element entsprechen soll) immer zuletzt notiert werden soll.

Das wird wohl mit CSS nichts.

Aber wenn du sowieso mit JavaScript dran bist: Warum läufst du nicht über alle .multilingual-Knoten und entscheidest jeweils anhand der dort verfügbaren Sprachen, der aus Cookie und QueryString ermittelten gewünschten Sprache und aus der Fallbacksprache, welche im jeweiligen Knoten angezeigt werden soll?

LLAP 🖖

[beatovich]

hallo

@@beatovich

Ja. Aber ich kann zur Zeit, wo ich das CSS genriere nur das Attribut lang aus dem html Element auswerten, da ja die andere Variable data-lang später noch verändert wird. Trotzdem muss ich wegen der Cookie und QueryString auswertung bereits korrekt reagieren, das heisst, die vorgesehenen Fälle müssen sofort korrekt gerendert werden.

Du ermittelst also mit JavaScript aus Cookie und QueryString die Sprache. Dann kannst du doch genau die gezeigte Regel mit JavaScript generieren: neuer Pen.

Das ist mir auch schon durch den Kopf gegangen. Ich kann ein eindeutiges Style-Element aktualisieren.

Angenommen: lang=de, data-lang=fr

.multilingual > :not([data-lang|="fr"]):not(:last-child),
.multilingual > [data-lang|="fr"] ~ :last-child
{
	display: none;
}

Die Frage ist nur:

• kein Cookie, mein QS -> kein data-lang Attribut

Es sollte jetzt alles ausgeblendet werden das nicht der dokument-Sprache entspricht.

Die Initialisierung sollte also sein:

.multilingual > :not(:last-child)
{
	display: none;
}

ob ich diese Bedingung wegbekomme, dass die Fallbackversion (welche dem lang Attribut im html Element entsprechen soll) immer zuletzt notiert werden soll.

Das wird wohl mit CSS nichts.

So denke ich auch.

Aber wenn du sowieso mit JavaScript dran bist: Warum läufst du nicht über alle .multilingual-Knoten und entscheidest jeweils anhand der dort verfügbaren Sprachen, der aus Cookie und QueryString ermittelten gewünschten Sprache und aus der Fallbacksprache, welche im jeweiligen Knoten angezeigt werden soll?

Ich kann natürlich diese Zeit investieren. Aber, warum das DOM verändern, wenn es ja (eventuell) doch wieder restauriert werden muss?

[beatovich]

hallo

Aber wenn du sowieso mit JavaScript dran bist: Warum läufst du nicht über alle .multilingual-Knoten und entscheidest jeweils anhand der dort verfügbaren Sprachen, der aus Cookie und QueryString ermittelten gewünschten Sprache und aus der Fallbacksprache, welche im jeweiligen Knoten angezeigt werden soll?

Ich kann natürlich diese Zeit investieren. Aber, warum das DOM verändern, wenn es ja (eventuell) doch wieder restauriert werden muss?

Also so schlimm ist es nicht. Eine einmalige Aktion kann sicherstellen, dass die Version, die der Document Sprache entspricht, immer das letzte Element ist.

[beatovich]

hallo

Also so schlimm ist es nicht. Eine einmalige Aktion kann sicherstellen, dass die Version, die der Document Sprache entspricht, immer das letzte Element ist.

	var col = document.querySelectorAll('[lang=""] > [lang="'+_.lang+'"]');
	for(var i = 0; i < col.length; i++){ col[i].parentElement.appendChild( col[i] );}

Damit sind nur noch Aufrufe ohne Javascript aussen vor.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Du ermittelst also mit JavaScript aus Cookie und QueryString die Sprache.

Äh, Moment! Der erste Anlaufpunkt sollte die Accept-Language-Angabe im HTTP-Header sein. ☞ Sprachvereinbarung (language negotiation)

LLAP 🖖

[beatovich]

hallo

Du ermittelst also mit JavaScript aus Cookie und QueryString die Sprache.

Äh, Moment! Der erste Anlaufpunkt sollte die Accept-Language-Angabe im HTTP-Header sein. ☞ Sprachvereinbarung (language negotiation)

Du meinst die letzte...

Die Sache ist die, dass du diese eventuell gar nicht nutzen willst, da die Browser-konfiguration nicht dem User-Wunsch entsprechen muss.

[Gunnar Bittersmann]

@@beatovich

Äh, Moment! Der erste Anlaufpunkt sollte die Accept-Language-Angabe im HTTP-Header sein. ☞ Sprachvereinbarung (language negotiation)

Du meinst die letzte...

Von der Priorität her die letzte, ja.

Die Sache ist die, dass du diese eventuell gar nicht nutzen willst

Doch! Weil sie in den meisten Fällen doch ohne weitere Interaktion das richtige Ergebnis liefert.

da die Browser-konfiguration nicht dem User-Wunsch entsprechen muss.

Deshalb ist es ja die von der Priorität her die letzte. Von der Verarbeitung her die erste, weil es die anderen Möglichkeiten, die Sprache zu ermitteln, in den meisten Fällen gar nicht geben muss.

LLAP 🖖

[beatovich]

hallo

Doch! Weil sie in den meisten Fällen doch ohne weitere Interaktion das richtige Ergebnis liefert.

da die Browser-konfiguration nicht dem User-Wunsch entsprechen muss.

Deshalb ist es ja die von der Priorität her die letzte. Von der Verarbeitung her die erste, weil es die anderen Möglichkeiten, die Sprache zu ermitteln, in den meisten Fällen gar nicht geben muss.

Es ist also so, dass es von der Priorität her noch andere Anwärter nach cookie und query-string und vor language negotiation gibt. Das meinte ich mit eventuell.

[beatovich]

hallo

Äh, Moment! Der erste Anlaufpunkt sollte die Accept-Language-Angabe im HTTP-Header sein. ☞ Sprachvereinbarung (language negotiation)

Der erste Anlaufpunkt ist mit Javascript nicht zugänglich. Darum sollten sich die DOM-Spezifizierer mal kümmern.

[ursus contionabundo]

Es werden alle Kindelemente von .multilingual ausgeblendet, deren Sprache nicht mit $lang übereinstimmt,

Soll heißen, Du lieferst bei jedem Seitenabruf jede Übersetzung aus?

Praktisch haben wir es immer nur mit 2-4 sprachversionen zu tun.

Naja. Dann gänge das gerade noch... muss bei serverseitigem Skripting aber nicht sein.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Verwende bspw. class="multilingual".

Sagt’s und schreibt im Code multilang. Ich hab’s hier im Thread und in meinen Pens in multilingual geändert, um keine Verwirrung zu stiften. Oder noch mehr? 😉

LLAP 🖖

[beatovich]

hallo

@@Gunnar Bittersmann

Verwende bspw. class="multilingual".

Sagt’s und schreibt im Code multilang. Ich hab’s hier im Thread und in meinen Pens in multilingual geändert, um keine Verwirrung zu stiften. Oder noch mehr? 😉

Ich bin immer noch nicht glücklich

class="multilingual" ist definitiv zu lange

Ich übelege derzeit:

<p lang="">
  <span lang="de">Deutsch</span>
  <span lang="it">Italiano</span>
  <span lang="fr">Francais</span>
</p>

Ein leeres language Attribut erscheint schlimmstenfalls sinnfrei. Gerade deshalb wird man es für keinen anderen Zweck verwenden.

[beatovich]

hallo

$lang: 'en';

.multilingual > :not([lang|="#{$lang}"]):not(:last-child),
.multilingual > [lang|="#{$lang}"] ~ :last-child
{
	display: none;
}

☞ Codepen zum Rumspielen

ich habe jetzt folgendes umgesetzt (auf deine Anregung)

	html[lang|="'+_.lang+'"]:not([data-lang]) [lang=""] > :not([lang|="'+_.lang+'"]) {display:none}
	html[data-lang|="en"] [lang=""] > :not([lang|="en"]):not(:last-of-type),
	html[data-lang|="es"] [lang=""] > :not([lang|="es"]):not(:last-of-type),
	html[data-lang|="de"] [lang=""] > :not([lang|="de"]):not(:last-of-type),
	html[data-lang|="fr"] [lang=""] > :not([lang|="fr"]):not(:last-of-type),
	html[data-lang|="it"] [lang=""] > :not([lang|="it"]):not(:last-of-type){display:none}
	html[data-lang|="en"] [lang=""] > [lang|="en"] ~ [lang|="'+_.lang+'"],
	html[data-lang|="es"] [lang=""] > [lang|="es"] ~ [lang|="'+_.lang+'"],
	html[data-lang|="de"] [lang=""] > [lang|="de"] ~ [lang|="'+_.lang+'"],
	html[data-lang|="fr"] [lang=""] > [lang|="fr"] ~ [lang|="'+_.lang+'"],
	html[data-lang|="it"] [lang=""] > [lang|="it"] ~ [lang|="'+_.lang+'"]{display:none}

Eindeutig besser ist hier, dass wir kein display:initial mehr brauchen im Vergleich zu meiner ursprünglichen Version.

[beatovich]

folgendes Schreckgespenst

<span id="langoptions" aria-label="Sprachwahl - Language Selection">
	<button title="Deutsch" aria-label="Deutsch" onclick="setLangCookie(this.lang)" lang="de">de</button>
	<button title="English" aria-label="English" onclick="setLangCookie(this.lang)" lang="en">en</button>
	<button title="Espagnol" aria-label="Espagnol" aria-current="lang" onclick="setLangCookie(this.lang)" lang="es">es</button>
	<button title="Français" aria-label="Français" onclick="setLangCookie(this.lang)" lang="fr">fr</button>
	<button title="Italiano" aria-label="Italiano" onclick="setLangCookie(this.lang)" lang="it">it</button>
</span>

Mängelliste

• Event Delegation kommt noch
• Eventuell das span ersetzen mit fieldset mit visuell verborgenem legend.
• Vermeide menschenlesbare Information in Attributen (es sei denn sie sind bereits übersetzt).

Das besondere Problem ist das Wort Sprachwahl. Optimaler Weise schreibt man dieses in der Sprache des Lesers. Gerade diese kenne ich aber nicht.

[Gunnar Bittersmann]

@@beatovich

<span id="langoptions" aria-label="Sprachwahl - Language Selection">

Wird nicht der Elementinhalt im Screenreader durch den Wert von aria-label ersetzt? Werden die Buttons denn überhaupt angesagt?

	<button title="Deutsch" aria-label="Deutsch" onclick="setLangCookie(this.lang)" lang="de">de</button>

Warum nicht auch eine vernünftige Beschriftung für sehende Nutzer? Bist du sicher, dass alle mit den Kürzeln de, en, fr, it etwas anfangen können?

Außer das Cookie zu setzen passiert nichts? Soll nicht auch sofort die Sprache gewechselt werden?

	<button title="Espagnol" aria-label="Espagnol" aria-current="lang" onclick="setLangCookie(this.lang)" lang="es">es</button>

Espagnol kommt mir nicht spanisch vor. Eher italienisch? Du meinst Español.

lang ist kein gültiger Wert für aria-current. [WAI-ARIA 1.2]

• Vermeide menschenlesbare Information in Attributen (es sei denn sie sind bereits übersetzt).

Die Sprachbezeichner in den jeweiligen Zielsprachen sollen gar nicht übersetzt werden.

Das besondere Problem ist das Wort Sprachwahl. Optimaler Weise schreibt man dieses in der Sprache des Lesers. Gerade diese kenne ich aber nicht.

Ein Bild sagt mehr als tausend ein unverständliches Wort.

LLAP 🖖

[beatovich]

hallo

@@beatovich

<span id="langoptions" aria-label="Sprachwahl - Language Selection">

Wird nicht der Elementinhalt im Screenreader durch den Wert von aria-label ersetzt? Werden die Buttons denn überhaupt angesagt?

Schau dir die aktuelle Online Version https://beat-stoecklin.ch/pub/website_multilang.html an. Da wird fieldset / legend eingesetzt.

	<button title="Deutsch" aria-label="Deutsch" onclick="setLangCookie(this.lang)" lang="de">de</button>

Warum nicht auch eine vernünftige Beschriftung für sehende Nutzer? Bist du sicher, dass alle mit den Kürzeln de, en, fr, it etwas anfangen können?

Das hiesse dann ein select Element.

Dann wird die aktuelle Sprache sichtbar angezeigt. Die mag einem dann auch spanisch vorkommen.

Außer das Cookie zu setzen passiert nichts? Soll nicht auch sofort die Sprache gewechselt werden?

Nur eine Fehlfunktion könnte erklären, warum der Sprachwechsel nicht sofort erfolgt. Wo scheitert's?

	<button title="Espagnol" aria-label="Espagnol" aria-current="lang" onclick="setLangCookie(this.lang)" lang="es">es</button>

Espagnol kommt mir nicht spanisch vor. Eher italienisch? Du meinst Español.

Wird korrigiert

lang ist kein gültiger Wert für aria-current. [WAI-ARIA 1.2]

Dann sollte es das schleunigst werden. Ich kann den Wert auch leer lassen.

• Vermeide menschenlesbare Information in Attributen (es sei denn sie sind bereits übersetzt).

Die Sprachbezeichner in den jeweiligen Zielsprachen sollen gar nicht übersetzt werden.

Das besondere Problem ist das Wort Sprachwahl. Optimaler Weise schreibt man dieses in der Sprache des Lesers. Gerade diese kenne ich aber nicht.

Ein Bild sagt mehr als tausend ein unverständliches Wort.

Angesichts dessen, dass der Ausdruck Wählen Sie ihre Sprache nicht effektiv sinnvoll anwendbar ist, wandert man sich, dass Unicode genu für diese Mitteilung keinen Codepunkt definiert hat.

Das ist wohl der Einzig Fall, wo man entschuldigt ist, dass man ein Icon nicht mit Text begleitet.

[Gunnar Bittersmann]

@@beatovich

Schau dir die aktuelle Online Version https://beat-stoecklin.ch/pub/website_multilang.html an.

Irgendwas stimmt da nicht. Ich bekomme die Seite initial auf französisch präsentiert; in der Sprachauswahl ist aber DE hervorgehoben.

Und noch was stimmt nicht:

Anstatt absoluter Positionierung wäre da vielleicht float: right oder Flexbox besser.

Und sollte nicht die Sprachauswahl gleich vorne im DOM stehen, gleich nach dem Skip-Link?

Warum nicht auch eine vernünftige Beschriftung für sehende Nutzer? Bist du sicher, dass alle mit den Kürzeln de, en, fr, it etwas anfangen können?

Und für nichtsehende könnte sie auch aussagekräftiger sein:

	<button title="Deutsch" aria-label="Diese Seite auf deutsch" onclick="setLangCookie(this.lang)" lang="de">de</button>

Das hiesse dann ein select Element.

Bitte nicht. [qa-navigation-select]

Ob die Sprachkürzel als Beschriftung in deiner Sprachauswahl taugen, hängt von deiner Zielgruppe ab. Auf Webseiten hast du aber allen Platz der Welt, um die Sprachen auszuschreiben: Deutsch, English, Español, Français, Italiano. Die aktuelle Sprache muss im Menü nicht auftauchen; nur die anderen jeweils verfügbaren.

Das title-Attribut kann dann dazu genutzt werden, die Sprachbezeichnungen in der aktuellen Sprache anzuzeigen, bspw. auf der englischen

	<button title="German" onclick="setLangCookie(this.lang)">
		<span lang="de">
			<span class="visually-hidden">Diese Seite auf</span>
			deutsch
		</span>
	</button>

Außer das Cookie zu setzen passiert nichts? Soll nicht auch sofort die Sprache gewechselt werden?

Nur eine Fehlfunktion könnte erklären, warum der Sprachwechsel nicht sofort erfolgt. Wo scheitert's?

Was tut die Funktion setLangCookie()? Mehr als ihr Name aussagt?

lang ist kein gültiger Wert für aria-current. [WAI-ARIA 1.2]

Dann sollte es das schleunigst werden.

Reich einen Vorschlag ein!

Ich kann den Wert auch leer lassen.

Nochmal nachgelesen: ja, kannst du. aria-current="" wird als aria-current="true" gewertet. aria-current="lang" übrigens auch.

Das ist wohl der Einzig Fall, wo man entschuldigt ist, dass man ein Icon nicht mit Text begleitet.

Nicht einmal mit Alternativtext.

LLAP 🖖

[beatovich]

hallo

@@beatovich

Schau dir die aktuelle Online Version https://beat-stoecklin.ch/pub/website_multilang.html an.

Irgendwas stimmt da nicht. Ich bekomme die Seite initial auf französisch präsentiert; in der Sprachauswahl ist aber DE hervorgehoben.

Da war doch tatsächlich noch ein data-lang="fr" im Original Quelltext.

Und noch was stimmt nicht:

stimmt, um die 600px.

gefixt

Anstatt absoluter Positionierung wäre da vielleicht float: right oder Flexbox besser.

Und sollte nicht die Sprachauswahl gleich vorne im DOM stehen, gleich nach dem Skip-Link?

naja, da gibt's verschiedene Anwärter. Da werde ich mir noch Gedanken machen. Die Themes sind ja strukturell nicht in Stein gemeiselt.

Das hiesse dann ein select Element.

Bitte nicht. [qa-navigation-select]

Ob die Sprachkürzel als Beschriftung in deiner Sprachauswahl taugen, hängt von deiner Zielgruppe ab.

Die ist ja immer noch einsprachig. Ich werde mir den Aufwand nicht machen. Aber andere User dürfen sicher das Theme an ihre Bedürfnisse anpassen.

Auf Webseiten hast du aber allen Platz der Welt, um die Sprachen auszuschreiben: Deutsch, English, Español, Français, Italiano. Die aktuelle Sprache muss im Menü nicht auftauchen; nur die anderen jeweils verfügbaren.

Ich wüsste nicht, dass sich Webseiten allen Platz der Wahl nehmen.

Denkbar wäre dann eine Klappbox, wenn ich da nur ein Box-Label/Icon hätte, das immer verständlich ist. Solche Lösungen können nur site-spezifisch (von anderen) entschieden werden und sind deshalb ausserhalb meiner Domäne.

Das title-Attribut kann dann dazu genutzt werden, die Sprachbezeichnungen in der aktuellen Sprache anzuzeigen, bspw. auf der englischen

Es ist sicher gut, das title-Attribut befüllt zu haben, damit man es via CSS für den Button-Text bei Bedarf nutzen kann.

	<button title="German" onclick="setLangCookie(this.lang)">
		<span lang="de">
			<span class="visually-hidden">Diese Seite auf</span>
			deutsch
		</span>
	</button>

Diese Mitteilung diese Seite auf ... ist aber nur zum Teil richtig. Man wählt auch den Zustand für jede nächste mehrsprachige Seite.

Ich neige dazu, dass Sprachkürzel in den meisten Fällen ausreichen. Eventuell kann der Sprach-Vollname dienen.

Alles andere aber kann mehr Verwirrung stiften.

Was tut die Funktion setLangCookie()? Mehr als ihr Name aussagt?

Sie setzt das attribut data-lang= $lang im html Element

Ich kann mir einen besseren Namen ausdenken: setUserLang()

Ich erwarte aber nicht, dass Theme-User mit dem Funktionsnamen in Berührung kommen.

Ich kann den Wert auch leer lassen.

Nochmal nachgelesen: ja, kannst du. aria-current="" wird als aria-current="true" gewertet. aria-current="lang" übrigens auch.

Meine Vermutung ist, dass jeder Wert, der aus Sicht der assistiven Technologie nicht einem registrierten Wert entspricht, schlicht als true verstanden wird. Operativ sollte die aktuelle Schreibweise also kein Problem darstellen.

Das ist wohl der Einzig Fall, wo man entschuldigt ist, dass man ein Icon nicht mit Text begleitet.

Nicht einmal mit Alternativtext.

Was mich dazu bringt, wie ich bei Mehrsprachigkeit mit alt-texten umgehen soll.

Ist die Funktion des alt-textes der einer Beschreibung, so ist aria-describedby vorzuziehen. Dort sind Übersetzungen einfach anzubringen.

[Gunnar Bittersmann]

@@beatovich

stimmt, um die 600px.

Was ist das, px? 🤔

Ob die Sprachkürzel als Beschriftung in deiner Sprachauswahl taugen, hängt von deiner Zielgruppe ab.

Die ist ja immer noch einsprachig.

Das meinte ich nicht, sondern: wie technikaffin? Wie vertraut mit Sprachkürzeln?

Diese Mitteilung diese Seite auf ... ist aber nur zum Teil richtig. Man wählt auch den Zustand für jede nächste mehrsprachige Seite.

Von mir aus: „diese Website auf …“

Ich neige dazu, dass Sprachkürzel in den meisten Fällen ausreichen. Eventuell kann der Sprach-Vollname dienen.

Alles andere aber kann mehr Verwirrung stiften.

Dieses „diese Website auf …“ ist nur für Screenreader gedacht und soll nicht visuell dargestellt werden.

Ich kann mir einen besseren Namen ausdenken: setUserLang()

Macht Sinn.

Nochmal nachgelesen: ja, kannst du. aria-current="" wird als aria-current="true" gewertet. aria-current="lang" übrigens auch.

Meine Vermutung ist, dass jeder Wert, der aus Sicht der assistiven Technologie nicht einem registrierten Wert entspricht, schlicht als true verstanden wird.

Um dir das Nachlesen zu ersparen (die Quelle hatte ich ja verlinkt): ja, deine Vermutung stimmt.

LLAP 🖖

[beatovich]

hallo

Das meinte ich nicht, sondern: wie technikaffin? Wie vertraut mit Sprachkürzeln?

Ich habe jetzt die folgende Version implemntiert

https://beat-stoecklin.ch/pub/website_multilang.html

Fokusier mal die Language Buttons.

[beatovich]

hallo

Eine live Demo zur Mehrsprachigkeit

https://beat-stoecklin.ch/pub/website_multilang.html

Ihr könnt auch den Quellcode anschauen.