Ein Glossar gibt der Lokalisierungs-Engine präzise Kontrolle über bestimmte Begriffe – entweder indem es eine exakte Übersetzung erzwingt oder jede Übersetzung komplett verhindert. Glossarregeln haben Vorrang vor der eigenen Einschätzung des Modells, sodass die Engine sie bei jeder Anfrage konsistent anwendet.
So funktioniert's#
Jeder Glossareintrag gehört zu einer Lokalisierungs-Engine und wird anhand eines Paars aus Ausgangssprache und Zielsprache abgeglichen (oder * für jede Sprache). Wenn die Engine eine Übersetzungsanfrage verarbeitet, ruft sie relevante Glossareinträge per semantischer Suche ab – dabei wird die Bedeutung des Eingabetexts mit gespeicherten Begriffen abgeglichen, nicht nur die exakte Zeichenfolge.
| Feld | Beschreibung |
|---|---|
| Ausgangssprache | Die Sprache des Ausgangstexts oder * für jede Ausgangssprache |
| Zielsprache | Die Sprache des Zieltexts oder * für jede Zielsprache |
| Ausgangstext | Der Begriff in der Ausgangssprache |
| Zieltext | Die vorgeschriebene Übersetzung (oder derselbe Begriff für nicht übersetzbare Begriffe) |
| Typ | custom_translation oder non_translatable |
| Hinweis | Optionaler Kontext zur eindeutigen Zuordnung des Begriffs (z. B. "Substantiv, die Produktfunktion") |
Glossartypen#
Benutzerdefinierte Übersetzungen#
Erzwingen Sie eine bestimmte Übersetzung für einen Begriff. Die Engine verwendet immer Ihre Übersetzung statt der des Modells.
| Ausgangstext | Zieltext | Ausgangssprache | Zielsprache |
|---|---|---|---|
| Deploy | Bereitstellen | en | de |
| 911 | 112 | en | de |
| Workspace | espace de travail | en | fr |
Verwenden Sie benutzerdefinierte Übersetzungen für:
- Produktbegriffe mit etablierten Übersetzungen
- Kulturelle Anpassungen (Notrufnummern, Maßeinheiten)
- Begriffe, bei denen das Modell wiederholt das falsche Synonym wählt
Nicht übersetzbare Begriffe#
Verhindern Sie, dass ein Begriff übersetzt wird. Die Engine übernimmt den Ausgangstext unverändert.
| Ausgangstext | Zieltext | Typ |
|---|---|---|
| Lingo.dev | Lingo.dev | non_translatable |
| OAuth | OAuth | non_translatable |
| GraphQL | GraphQL | non_translatable |
Verwenden Sie nicht übersetzbare Begriffe für:
- Marken- und Produktnamen
- Technische Protokolle und Standards
- Eigennamen, die in der Ausgangssprache bleiben sollen
Semantischer Abgleich#
Glossareinträge werden nach Bedeutung abgeglichen, nicht per exaktem Zeichenfolgenvergleich. Wenn die Engine eine Übersetzungsanfrage erhält, erzeugt sie Embeddings für den Eingabetext und findet Glossareinträge mit semantisch ähnlichen Ausgangsbegriffen.
Das bedeutet: Ein Glossareintrag für "Deploy" passt auch auf "Deploying", "deployment" und "deploy your application" – ohne dass Sie für jede Variante einen eigenen Eintrag anlegen müssen.
Hinweisfeld
Verwenden Sie das Hinweisfeld, um Begriffe mit mehreren Bedeutungen eindeutig zuzuordnen. Ein Glossareintrag für "bank" mit dem Hinweis "financial institution" wird zum Beispiel nicht mit "river bank" im Eingabetext abgeglichen.
Wildcard-Sprachen#
Setzen Sie Ausgangssprache oder Zielsprache auf *, um einen Glossareintrag auf alle Sprachpaare anzuwenden.
Häufige Muster:
| Ausgangstext | Ausgangssprache | Zielsprache | Anwendungsfall |
|---|---|---|---|
| Lingo.dev | * | * | Den Markennamen in keiner Sprache übersetzen |
| API | en | * | "API" in allen Zielsprachen unübersetzt lassen |
| Deploy | en | de | Für diesen englischen Begriff eine bestimmte deutsche Übersetzung verwenden |
Wildcard-Einträge und sprachspezifische Einträge werden kombiniert – sie überschreiben sich nicht gegenseitig.
Sprachabgleich#
Glossareinträge werden sprachübergreifend auch über regionale Varianten hinweg abgeglichen, nicht nur über exakte Sprachcodes. Ein Eintrag de gilt auch für de-DE; ein Eintrag de-DE gilt auch für eine Anfrage mit bloßem de. Gleichrangige Varianten wie de-DE und de-AT teilen jedoch nie Einträge. Wenn mehrere Einträge passen, gewinnt die CLDR-Standardregion. Dieselben Regeln steuern auch Markenstimme, Anweisungen und Modellkonfigurationen. Unter Locale Resolution finden Sie das vollständige Verhalten – einschließlich der Skriptsicherheitsregel für benutzerdefinierte Übersetzungen.
Glossar vs. Anweisungen vs. Markenstimmen#
Jedes davon erfüllt einen eigenen Zweck in der Konfiguration der Engine:
| Glossar | Anweisung | Markenstimme | |
|---|---|---|---|
| Steuert | Einzelne Begriffe | Sprachliche Regeln | Ton und Stil insgesamt |
| Granularität | Pro Begriff | Pro Regel | Pro Sprache |
| Abgleich | Semantisch (nach Bedeutung) | Alle für die Sprache eingeschlossenen | Alle für die Sprache eingeschlossenen |
| Vorrang | Am höchsten – überschreibt die Einschätzung des Modells | Mittel – lenkt das Modell | Am niedrigsten – setzt den Kontext |
| Beispiel | "Deploy" → "Bereitstellen" | "Straße zu Str. abkürzen" | "Informelles du, technischer Ton" |
Regelvorrang
Glossarbegriffe haben in der Regelhierarchie der Engine den höchsten Vorrang. Wenn ein Glossareintrag mit einer Anweisung kollidiert, setzt sich das Glossar durch. Formulieren Sie Anweisungen so, dass sie das Glossar ergänzen, statt es zu duplizieren.
Glossare mit der API nutzen#
Glossareinträge werden automatisch angewendet, wenn Sie den localize endpoint aufrufen. Die Engine ruft semantisch relevante Einträge für das Paar aus Ausgangssprache und Zielsprache ab und fügt sie dem Prompt hinzu.
Zusätzliche Parameter sind nicht nötig – die Engine übernimmt Abruf und Einbindung.
Glossare über MCP verwalten#
Wenn Sie den Lingo.dev MCP server verwenden, kann Ihr KI-gestützter Coding-Assistent Glossareinträge direkt verwalten:
"Add a glossary entry: translate 'workspace' to 'espace de travail'
for English to French.""Mark 'GraphQL' as non-translatable for all locales."