Sprachauflösung

Jeder Glossarbegriff, Markenstimme-Text, jede Regel und jede Modellkonfiguration wird für eine Sprache gespeichert. Wenn die Engine eine Übersetzungsanfrage verarbeitet, ermittelt sie, welche gespeicherten Einträge auf die Anfrage-Sprache zutreffen – mit exakten Code-Treffern, Vererbung über regionale Varianten hinweg und Fallback, wenn kein exakter Eintrag vorhanden ist. Dieselbe Auflösung gilt für alle vier Konfigurationsbereiche.

So funktioniert's#

Sprachen werden bei der Eingabe in eine kanonische Form normalisiert und anschließend in genau dieser Form gespeichert und zurückgegeben. Groß-/Kleinschreibung und Trennzeichen werden vereinheitlicht, Subtags bleiben erhalten.

Der Abgleich funktioniert bidirektional über die Subtag-Grenze hinweg: Eine gespeicherte Sprache gilt für eine Anfrage, wenn sie entweder exakt übereinstimmt oder eine die übergeordnete Form der anderen ist. Auch zwei Schreibweisen derselben Sprache passen zusammen, wenn keine der beiden der anderen übergeordnet ist, aber die Region die Schrift festlegt: Die reine Regionsform und die Form mit expliziter Schrift sind äquivalent (zh-CN ≡ zh-Hans-CN, zh-TW ≡ zh-Hant-TW).

Auflösung bei mehreren Treffern#

Wenn mehr als ein gespeicherter Eintrag passt, priorisiert die Engine sie und verwendet den besten:

• Exakte Übereinstimmung oder Sprachstandard zuerst. Für eine de-Anfrage wird de-DE (die CLDR-Standardregion für Deutsch) bevorzugt, danach das allgemeine de.
• Danach die höchste Spezifität als Tie-Breaker.
• Jede andere passende Region bleibt als Fallback erhalten – ein Kunde, dessen einziger Eintrag de-CH ist, bekommt ihn weiterhin für eine de-Anfrage, wenn nichts Besseres passt, damit keine Konfiguration verwaist.

Ranking vs. Auswahl#

Das obige Ranking legt die Reihenfolge für Bereiche fest, die kombiniert werden, und bestimmt den Gewinner bei Bereichen, aus denen genau ein Eintrag gewählt wird:

Skriptsicherheit#

Eine zusätzliche Regel gilt nur für Glossar-custom_translation-Einträge, deren Text an eine bestimmte Orthografie gebunden ist. Eine Basissprache mit uneindeutigem Schriftsystem – sr (kyrillisch oder lateinisch), zh (vereinfacht oder traditionell) – muss beim Schreiben auf ein Schriftsystem festgelegt werden, entweder durch ein explizites Schriftsystem (zh-Hans, sr-Cyrl) oder durch eine Region, die es bestimmt (zh-CN → vereinfacht, sr-RS → kyrillisch, gemäß CLDR). Nur ein wirklich allgemeiner Code ohne Schriftsystem und ohne Region wird abgelehnt. Beim Lesen sind diese Festlegungen gleichwertig – ein unter zh-Hans-CN gespeicherter Begriff gilt auch für eine zh-CN-Anfrage und umgekehrt –, aber eine allgemeine zh-Anfrage, deren Schriftsystem unbekannt ist, übernimmt keinen auf ein Schriftsystem festgelegten Eintrag. Senden Sie daher für vorhersehbare Ergebnisse ein explizites Schriftsystem oder eine Region. Sprachen mit nur einem Schriftsystem, wie de, benötigen kein Schriftsystem und lösen de ganz normal zu de-DE auf. non_translatable-Einträge werden unabhängig vom Schriftsystem durchgereicht.

Beispiel#

Eine Engine, die mit regionalen Codes konfiguriert ist (en-US zu fr-FR, de-DE, nb-NO) und Anfragen mit Basiscodes erhält (fr, de, no):

• Ein fr-Ziel übernimmt die Glossarbegriffe, Markenstimme-Texte und Regeln aus fr-FR – als Standard für fr, nicht als letzter Ausweg, weil fr-FR die CLDR-Standardregion für Französisch ist.
• Eine Quelle mit en passt zu en-US-Einträgen – das Matching ist bidirektional.
• Ein no-Ziel übernimmt nicht nb-NO. no und nb sind unterschiedliche Sprach-Subtags, kein Regionenpaar; verwenden Sie nb als Ziel.

Sprachauflösung mit der API nutzen#

Die Auflösung erfolgt automatisch, wenn Sie den localize endpoint aufrufen. Die Engine gleicht die sourceLocale und targetLocale der Anfrage mit den Glossarbegriffen, Markenstimme-Texten, Regeln und Modellkonfigurationen ab, die sie anwendet – zusätzliche Parameter sind nicht nötig.

Nächste Schritte#