Ein Glossar gibt der Lokalisierungs-Engine präzise Kontrolle über bestimmte Begriffe – entweder, indem es eine feste Übersetzung erzwingt, oder indem es die Übersetzung vollständig verhindert. Glossarbegriffe haben Vorrang vor der Einschätzung des Modells, sodass die Engine sie bei jeder Anfrage konsistent anwendet.
Ein Glossar ist organisationseigen: ein benannter Container für Begriffe, der per Verknüpfung auf eine Lokalisierungs-Engine angewendet wird. Ein Glossar kann jede Engine steuern, die es braucht, und eine Engine kann mehrere Glossare anwenden.
So funktioniert's#
| Objekt | Felder |
|---|---|
| Glossar | Name, Beschreibung und die Quellsprachen, die es abdeckt. Enthält beliebig viele Begriffe. |
| Begriff | Quellsprache, Zielsprache, Quelltext, Zieltext, Typ, Hinweis. |
Wenn die Engine eine Übersetzungsanfrage verarbeitet, ruft sie über semantische Suche relevante Begriffe aus allen verknüpften Glossaren ab – dabei gleicht sie die Bedeutung des Eingabetexts mit den gespeicherten Quellbegriffen ab, nicht exakte Zeichenfolgen.
| 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") |
Glossare sind organisationseigen#
| Aktion | Auswirkung |
|---|---|
| Ein Glossar erstellen | Es existiert auf Organisationsebene und gilt für nichts, bis es verknüpft wird |
| Mit einer Engine verknüpfen | Jeder darin enthaltene Begriff kann für die Übersetzungen dieser Engine abgerufen werden |
| Mit mehreren Engines verknüpfen | Dieselben Begriffe gelten für alle – einmal bearbeiten, und jede Engine folgt |
| Mehrere Glossare mit einer Engine verknüpfen | Ihre Begriffe werden zu einem gemeinsamen Abruf-Pool zusammengeführt |
| Von einer Engine trennen | Die Engine wendet es nicht mehr an. Das Glossar und seine Begriffe bleiben erhalten. |
| Ein Glossar löschen | Wird abgelehnt, solange noch eine Engine es anwendet – zuerst trennen. Beim Löschen werden auch seine Begriffe entfernt. |
| Eine Engine löschen | Glossare und Begriffe bleiben bestehen. Sie gehören der Organisation, nicht der Engine. |
Die Reihenfolge der Verknüpfungen spielt keine Rolle. Wenn zwei verknüpfte Glossare denselben Quelltext für dasselbe Sprachpaar definieren, kann sich eines von beiden durchsetzen – halte einen Begriff an genau einer Stelle.
Verwalte Glossare unter Glossaries in der Seitenleiste der Organisation. Im Tab Glossary einer Engine siehst du die Begriffe, die sie aktuell anwendet, und kannst Glossare verknüpfen oder trennen.
Quellsprachen#
Ein Glossar legt fest, welche Quellsprachen es abdeckt. Ein custom_translation, dessen Quellsprache nicht dazugehört, wird beim Schreiben abgelehnt – auf jedem Weg, einschließlich Dashboard, API, eines angewendeten Engine-Vorschlags und Provisioning. Die Prüfung verwendet dieselbe großzügige Sprachzuordnung wie beim Lesen, daher akzeptiert ein Glossar, das en abdeckt, auch einen en-US-Begriff.
Lass die Quellsprachen leer, dann akzeptiert das Glossar jede Quellsprache.
Nicht übersetzbare Begriffe sind ausgenommen: Es gibt keine Übersetzung in der Quellsprache, an die sie gebunden werden könnten. Sie werden außerdem nur einmal mit einer Wildcard-Zielsprache gespeichert – unabhängig davon, welche Zielsprache du sendest. Der Begriff ist damit in jeder Sprache geschützt; Kopien pro Sprache wären nur Duplikate.
Glossartypen#
Benutzerdefinierte Übersetzungen#
Erzwinge eine bestimmte Übersetzung für einen Begriff. Die Engine verwendet immer deine Ü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#
Verhindere, dass ein Begriff übersetzt wird. Die Engine übernimmt den Quelltext unverändert – in jeder Zielsprache.
| 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#
Glossarbegriffe werden nach Bedeutung abgeglichen, nicht per exaktem Zeichenfolgenvergleich. Wenn die Engine eine Übersetzungsanfrage erhält, erzeugt sie Embeddings für den Eingabetext und findet Begriffe mit semantisch ähnlichem Quelltext.
Das bedeutet: Ein Begriff für "Deploy" passt auch zu "Deploying", "deployment" und "deploy your application" – ganz ohne separate Einträge für jede Variante.
Hinweisfeld
Nutze das Hinweisfeld, um Begriffe mit mehreren Bedeutungen eindeutig zu machen. Zum Beispiel passt ein Begriff für "bank" mit dem Hinweis "financial institution" nicht zu "river bank" im Eingabetext.
Wildcard-Sprachen#
Setze Quell- oder Zielsprache auf *, damit ein Begriff für alle Sprachpaare gilt.
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-Begriffe und sprachspezifische Begriffe werden kombiniert – sie überschreiben sich nicht gegenseitig.
Sprachabgleich#
Glossarbegriffe werden auch über regionale Varianten hinweg abgeglichen, nicht nur über exakte Sprachcodes. Ein de-Begriff gilt für de-DE; ein de-DE-Begriff gilt auch für eine allgemeine de-Anfrage. Gleichrangige Varianten wie de-DE und de-AT teilen niemals Begriffe. Wenn mehrere Treffer vorliegen, gewinnt die CLDR-Standardregion. Dieselben Regeln gelten für Markenstimme, Regeln und Modellkonfigurationen. Unter Locale Resolution findest du das vollständige Verhalten, einschließlich der Script-Sicherheitsregel für benutzerdefinierte Übersetzungen.
Glossare vs. Regeln vs. Markenstimmen#
Jedes davon erfüllt einen eigenen Zweck in der Konfiguration der Engine:
| Glossar | Regel | Markenstimme | |
|---|---|---|---|
| Steuert | Einzelne Begriffe | Sprachliche Konventionen | Ton und Stil insgesamt |
| Granularität | Pro Begriff | Pro Regel | Text pro Sprache |
| Abgleich | Semantisch (nach Bedeutung) | Alle passenden Regeln enthalten | Der einzelne Text mit der besten Übereinstimmung |
| 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" |
Alle drei sind organisationseigene Container, die eine Engine per Verknüpfung anwendet: Glossare enthalten Begriffe, rulesets enthalten Regeln und eine Markenstimme enthält einen Text pro Sprache.
Regelvorrang
Glossarbegriffe haben in der Hierarchie der Engine die höchste Priorität. Wenn ein Glossarbegriff mit einer Regel kollidiert, gewinnt das Glossar. Gestalte Regeln so, dass sie das Glossar ergänzen, statt es zu duplizieren.
Glossare mit der API nutzen#
Glossarbegriffe werden automatisch angewendet, wenn du den localize endpoint aufrufst. Die Engine ruft aus den Glossaren, die sie anwendet, semantisch relevante Begriffe für das Quell-/Zielsprachpaar ab und fügt sie dem Prompt hinzu. Zusätzliche Parameter sind nicht nötig.
| Aufruf | Zweck |
|---|---|
POST /glossaries | Ein Glossar für die Organisation erstellen |
GET /organizations/:id/glossaries | Die Glossare der Organisation mit Anzahl der Begriffe und Engines auflisten |
GET /glossaries/:id/glossary-items | Die Begriffe eines Glossars auflisten, gruppiert nach Quelltext |
POST /glossary-items mit glossaryId | Einen Begriff zu einem Glossar hinzufügen |
PUT /engines/:id/glossaries | Die Menge der Glossare ersetzen, die eine Engine anwendet |
DELETE /engines/:id/glossaries/:glossaryId | Die Anwendung eines Glossars auf eine Engine beenden |
GET /engines/:id/glossary-items | Alle Begriffe auflisten, die eine Engine aktuell anwendet |
ownerEngineId auf POST /glossary-items funktioniert weiterhin – es schreibt in das Standardglossar der Engine. Bevorzuge glossaryId.
Zugriff#
org:glossary:read und org:glossary:edit steuern Glossare und die darin enthaltenen Begriffe; um eines mit einer Engine zu verknüpfen, brauchst du auf dieser Engine zusätzlich engine:edit. Eine Berechtigung pro Glossar gibt jemandem Lese- und Bearbeitungszugriff auf ein einzelnes Glossar statt auf alle Glossare der Organisation. Siehe Roles & Permissions.
Glossare über MCP verwalten#
Wenn du den Lingo.dev MCP server nutzt, kann dein KI-Coding-Assistent Glossare und ihre Begriffe direkt verwalten:
"Create a glossary called Product terms covering English, and
apply it to the web engine.""Add a term: translate 'workspace' to 'espace de travail'
for English to French.""Mark 'GraphQL' as non-translatable for all locales."