Sprachauflösung

Jeder Glossareintrag, jede Markenstimme, jede Anweisung und jede Modellkonfiguration wird für eine Sprache gespeichert. Wenn die Engine eine Übersetzungsanfrage verarbeitet, ermittelt sie, welche gespeicherten Einträge für die angefragte Sprache gelten – mit exakten Treffern, Vererbung über regionale Varianten hinweg und Fallbacks, 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.

Skriptsicherheit#

Eine zusätzliche Regel gilt nur für Glossareinträge vom Typ custom_translation, deren Text an eine bestimmte Orthografie gebunden ist. Eine Basissprache mit mehrdeutiger Schrift — sr (Kyrillisch oder Lateinisch), zh (vereinfacht oder traditionell) — muss beim Schreiben auf eine Schrift festgelegt werden, entweder durch eine explizite Schriftangabe (zh-Hans, sr-Cyrl) oder durch eine Region, die sie bestimmt (zh-CN → vereinfacht, sr-RS → Kyrillisch, gemäß CLDR). Nur ein tatsächlich unqualifizierter Code ohne Schrift und ohne Region wird abgelehnt. Beim Lesen sind diese festgelegten Formen äquivalent: Ein Glossar, das als zh-Hans-CN gespeichert ist, gilt auch für eine Anfrage in zh-CN und umgekehrt. Eine unqualifizierte Anfrage in zh, deren Schrift unbekannt ist, greift jedoch nicht auf eine Zeile mit festgelegter Schrift zu. Senden Sie daher für vorhersehbare Ergebnisse eine explizite Schrift oder Region. Sprachen mit nur einer Schrift, wie de, benötigen keine Schriftangabe und lösen de ganz normal zu de-DE auf. Einträge vom Typ non_translatable werden unabhängig von der Schrift 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 das fr-FR-Glossar, die Markenstimme und die Anweisungen – eingestuft 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 gespeicherten Glossaren, Markenstimmen, Anweisungen und Modellkonfigurationen ab – zusätzliche Parameter sind nicht erforderlich.

Nächste Schritte#