Eine Regel ist eine benannte sprachliche Anweisung, die die Lokalisierungs-Engine auf eine Zielsprache anwendet — zum Beispiel „Straße in Adressen zu Str. abkürzen“, nicht „lockerer schreiben“. Regeln leben in Regelsätzen: organisationsweiten Containern, die eine Engine durch Verknüpfung anwendet. So kann ein einzelner Regelsatz jede Engine steuern, die ihn braucht.
Regeln hießen früher Anweisungen
Im Dashboard heißen sie jetzt Regeln und sind in Regelsätzen gruppiert. Die REST-API stellt eine einzelne Regel weiterhin unter /instructions bereit, bei unveränderten Feldnamen — geändert hat sich nur, wo eine Regel geschrieben wird: rulesetId hat ownerEngineId ersetzt.
So funktioniert's#
Ein Regelsatz gehört Ihrer Organisation, nicht einer Engine. Erst wenn Sie ihn mit einer Engine verknüpfen, werden seine Regeln angewendet — auf die Engine selbst wird nichts kopiert.
| Objekt | Felder |
|---|---|
| Regelsatz | Name, Beschreibung. Enthält beliebig viele Regeln. |
| Regel | Name, Zielsprache (oder *), Text. |
Wenn eine Übersetzungsanfrage eingeht, sammelt die Engine jede Regel aus allen verknüpften Regelsätzen, deren Zielsprache zur targetLocale der Anfrage passt, und fügt sie zusammen mit der Markenstimme und dem Glossar in den LLM-Prompt ein. Regeln konkurrieren nicht miteinander: Alle passenden Regeln werden berücksichtigt, sortiert nach der am besten passenden Sprache, damit die präziseste Vorgabe zuerst kommt.
| Feld | Beschreibung |
|---|---|
| Name | Eine kurze Bezeichnung zur Identifizierung der Regel (z. B. „deutsche formelle Anrede“) |
| Zielsprache | Die Sprache, für die diese Regel gilt, oder * für alle Sprachen |
| Text | Die sprachliche Regel, in natürlicher Sprache formuliert |
Viele Regeln pro Sprache
Erstellen Sie so viele Regeln, wie eine Sprache braucht. Jede Regel sollte genau einen Aspekt abdecken — das macht sie einzeln testbar, durch die rules KI-Bewertung bewertbar und sicher löschbar.
Regelsätze gehören der Organisation#
| Aktion | Auswirkung |
|---|---|
| Einen Regelsatz erstellen | Er existiert auf Organisationsebene und gilt für nichts, bis er verknüpft wird |
| Mit einer Engine verknüpfen | Jede darin enthaltene Regel gilt für die Übersetzungen dieser Engine |
| Mit mehreren Engines verknüpfen | Dieselben Regeln gelten für alle — einmal ändern, und jede Engine folgt |
| Mehrere Regelsätze mit einer Engine verknüpfen | Alle enthaltenen Regeln werden kombiniert |
| Von einer Engine lösen | Die Engine wendet ihn nicht mehr an. Der Regelsatz und seine Regeln bleiben erhalten. |
| Einen Regelsatz löschen | Wird abgelehnt, solange ihn noch eine Engine anwendet — zuerst lösen. Beim Löschen werden auch seine Regeln entfernt. |
| Eine Engine löschen | Regelsätze und Regeln bleiben bestehen. Sie gehören zur Organisation, nicht zur Engine. |
Verwalten Sie Regelsätze unter Regeln in der Seitenleiste Ihrer Organisation. Im Tab Regeln einer Engine sehen Sie, was diese Engine aktuell anwendet, und können Regelsätze verknüpfen oder lösen.
Vordefinierte Anweisungen#
Lingo.dev kuratiert einen Katalog gebrauchsfertiger Regeln — Sprachkonventionen, die die meisten Teams brauchen und die nur selten jemand explizit festhält. Öffnen Sie Predefined Instructions im Tab Regeln einer Engine und wählen Sie die gewünschten aus. Sie werden direkt mit der Engine verknüpft statt über einen Regelsatz, und Sie können sie jederzeit wieder lösen.
Kuratierten Regeln stehen im Prompt vor Ihren eigenen. So verfeinert oder überschreibt eine von Ihnen geschriebene Regel die Grundlage, statt mit ihr zu konkurrieren.
Regeln vs. Markenstimmen#
Beide beeinflussen das Übersetzungsergebnis — aber auf unterschiedlichen Ebenen:
| Markenstimme | Regel | |
|---|---|---|
| Umfang | Allgemeiner Ton, Stil, Formalität | Eine konkrete sprachliche Regel |
| Pro Sprache | Ein Text pro Sprache, eine Stimme pro Sprache und Engine | Viele Regeln pro Sprache |
| Angewendet | Der einzelne Text mit der besten Übereinstimmung | Alle passenden Regeln werden kombiniert |
| Wildcard | Ja (* fungiert als Standardstimme) | Ja (* gilt für alle Sprachen) |
| Beispiel | „Verwende informelles du, technischen Ton“ | „Straße in Adressen immer zu Str. abkürzen“ |
Verwenden Sie eine Markenstimme, um festzulegen, wie Ihr Produkt in einer Sprache spricht — etwa bei Formalität, Register und Satzstil.
Verwenden Sie Regeln, um konkrete Konventionen festzulegen, die das Modell sonst leicht übersehen würde — etwa Abkürzungen, Zeichensetzung, Einheitenformatierung oder sprachspezifische Grammatikmuster.
Beides greift ineinander: Die Markenstimme setzt den Ton, Regeln kümmern sich um die Sonderfälle.
Effektive Regeln schreiben#
Jede Regel sollte eine einzelne, eindeutige Anweisung enthalten. Die Engine übernimmt den vollständigen Text in den LLM-Prompt — deshalb ist Klarheit entscheidend.
Gute Regeln#
Always use the Oxford comma in English lists.In Japanese, use full-width parentheses （）instead of half-width ().For German addresses, abbreviate "Straße" to "Str." and
"Nummer" to "Nr."When translating percentage values for French, add a
non-breaking space before the percent sign: 42 %.Was Sie vermeiden sollten#
- Vage Vorgaben, die sich mit der Markenstimme überschneiden („lockerer schreiben“) — das gehört stattdessen in die Markenstimme
- Mehrere unabhängige Anweisungen in einer Regel — trennen Sie sie, damit jede einzeln getestet werden kann
- Regeln, die dem Glossar widersprechen — Glossarbegriffe haben in der Hierarchie der Engine Vorrang
Wildcard-Sprache#
Setzen Sie die Zielsprache auf *, um eine Regel auf alle Sprachen anzuwenden. Das ist praktisch für sprachunabhängige Konventionen:
Never translate product feature names: "Smart Compose",
"Quick Actions", "Flow Builder".Preserve Markdown formatting in all translated strings.
Keep bold (**), italic (*), and link syntax [text](url) intact.Sprachspezifische Regeln und Wildcard-Regeln werden beide berücksichtigt, wenn die Engine eine Anfrage verarbeitet — sie werden kombiniert, nicht überschrieben.
Regeln mit der API verwenden#
Regeln werden automatisch angewendet, wenn Sie den localize endpoint aufrufen. Die Engine sammelt jede Regel aus den Regelsätzen, die sie anwendet, die zur targetLocale der Anfrage passt (plus alle *-Regeln). Zusätzliche Parameter sind nicht nötig.
| Aufruf | Zweck |
|---|---|
POST /rulesets | Einen Regelsatz für die Organisation erstellen |
GET /organizations/:id/rulesets | Die Regelsätze der Organisation mit Regel- und Engine-Anzahlen auflisten |
GET /rulesets/:id/rules | Die Regeln eines Regelsatzes auflisten |
POST /instructions mit rulesetId | Einem Regelsatz eine Regel hinzufügen |
PUT /engines/:id/rulesets | Die Regelsätze ersetzen, die eine Engine anwendet |
DELETE /engines/:id/rulesets/:rulesetId | Die Anwendung eines Regelsatzes für eine Engine beenden |
GET /engines/:id/instructions | Alle Regeln auflisten, die eine Engine aktuell anwendet |
ownerEngineId auf POST /instructions funktioniert weiterhin — es schreibt in den eigenen Regelsatz der Engine und erstellt einen, wenn die Engine noch keinen hat. Bevorzugen Sie rulesetId.
Zugriff#
org:ruleset:read und org:ruleset:edit steuern Regelsätze und die darin enthaltenen Regeln; um einen Regelsatz mit einer Engine zu verknüpfen, ist auf dieser Engine zusätzlich engine:edit erforderlich. Eine Berechtigung pro Regelsatz gibt jemandem Lese- und Bearbeitungszugriff auf einen einzelnen Regelsatz statt auf alle Regelsätze der Organisation. Siehe Rollen & Berechtigungen.
Regeln über MCP verwalten#
Wenn Sie den Lingo.dev MCP server verwenden, kann Ihr KI-gestützter Coding-Assistent Regeln und Regelsätze direkt erstellen, aktualisieren und löschen:
"Create a ruleset called German conventions and apply it to
the marketing engine.""Add a rule to that ruleset: always abbreviate Straße to Str.
in addresses.""Add a wildcard rule: never translate the term Smart Compose."