--- title: "Sprachen und Locales" description: "Welche Sprachen verbatra übersetzen kann, wie Locale-Codes bei jedem Provider ankommen und wie Plurale und Rechts-nach-links-Text behandelt werden." type: "concept" --- # Sprachen und Locales Welche Sprachen verbatra übersetzen kann, wie Locale-Codes bei jedem Provider ankommen und wie Plurale und Rechts-nach-links-Text behandelt werden. verbatra hat keine eigene Sprachliste: Es akzeptiert jeden gültigen BCP-47-Locale-Code, du kannst also die Sprachen nutzen, die dein Provider unterstützt, und in einem reinen Handarbeits-Projekt alle. verbatra schreibt jeden Code so, wie der Provider ihn erwartet, misst jede Übersetzung an den Pluralregeln ihrer Sprache und warnt dich vor einem Lauf, wenn ein Provider eine Locale nicht bedienen kann. ## Locale-Codes [#locale-codes] Jede Locale in deiner Konfiguration muss ein gültiger BCP-47-Tag sein, etwa `fr`, `pt-BR`, `sr-Latn` oder `es-419`; für Dateien namens `pt_BR.json` schreibst du `pt-BR` und setzt `files.localeStyle` auf `posix`. Die vollständigen Regeln stehen unter [Locale-Codes](https://verbatra.kreitz-webdev.de/de/docs/config-file.md#locale-codes). Der Code aus deiner Konfiguration ist der, den verbatra überall speichert: Dateipfade, [die Lock-Datei](https://verbatra.kreitz-webdev.de/de/docs/the-lock-file.md) und [der Cache](https://verbatra.kreitz-webdev.de/de/docs/the-cache.md). Eine Provider-eigene Schreibweise gibt es nur innerhalb eines Requests. Schreibst du einen Code um, den du schon übersetzt, etwa `pt_BR` zu `pt-BR`, bleibt seine Geschichte erhalten; siehe [Ein umgeschriebener Locale-Code](https://verbatra.kreitz-webdev.de/de/docs/the-lock-file.md#ein-umgeschriebener-locale-code). ## Abdeckung je Provider [#abdeckung-je-provider] Wie gut eine Sprache übersetzt wird, ist Sache des Providers; jede Zeile verlinkt die eigene Liste des Anbieters. | Provider | Sprachen | Gesendeter Code | Glossar | Tonfall | | --- | --- | --- | --- | --- | | `anthropic` | Keine feste Liste. [Claude multilingual support](https://platform.claude.com/docs/en/build-with-claude/multilingual-support) | Wie geschrieben, plus englische Namen für Sprache, Schrift und Region | Begriffe der Locale im Prompt | Im Prompt | | `openai` | Keine feste Liste. [Using the OpenAI API in different languages](https://help.openai.com/en/articles/6742369-how-do-i-use-the-openai-api-in-different-languages) | Wie geschrieben, plus Namen | Begriffe der Locale im Prompt | Im Prompt | | `gemini` | [Gemini language support](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/google-models#languages-gemini) | Wie geschrieben, plus Namen | Begriffe der Locale im Prompt | Im Prompt | | `opencode` | Was das gewählte Zen-Modell abdeckt | Wie geschrieben, plus Namen | Begriffe der Locale im Prompt | Im Prompt | | `openai-compatible` | Was das Modell abdeckt, das du betreibst | Wie geschrieben, plus Namen | Begriffe der Locale im Prompt | Im Prompt | | `deepl` | [DeepL supported languages](https://developers.deepl.com/docs/getting-started/supported-languages) | Auf DeepLs Codes normalisiert | Nur ein vorab angelegtes DeepL-Glossar per `glossaryId`, für 32 Sprachen | DeepL-Formality für einige Sprachen, nicht mit einem Free-Key | | `google-translate` | [Cloud Translation language support](https://docs.cloud.google.com/translate/docs/languages) (für die Basic-Stufe v2, die verbatra nutzt, gilt die NMT-Liste) | Für Chinesisch und Norwegisch normalisiert, sonst wie geschrieben | Keins | Keiner | | `libretranslate` | Die auf deinem Server installierten Modelle; [die Upstream-Liste](https://docs.libretranslate.com/) zeigt, was sich installieren lässt | Nur die Sprache, außer `pt-BR`, `zh-Hans` und `zh-Hant` | Keins | Keiner | | `none` | Entfällt: Es wird kein Provider aufgerufen | Es wird nichts gesendet | Entfällt | Entfällt | Was das in der Praxis heißt: - **LLM-Provider** haben keine geschlossene Liste. Sie versuchen jede Sprache, die du nennst, und die Qualität lässt nach, wo Trainingsdaten dünn sind, eine Zielsprache mit wenig Ressourcen verdient also ein menschliches Review. [Review-Flags](https://verbatra.kreitz-webdev.de/de/docs/translation-safety.md#review-flags) zeigen auf die verdächtigsten Ergebnisse. - **DeepL und Google Cloud Translation** haben eine geschlossene Liste, die vor einem Lauf geprüft wird. - **LibreTranslate** bedient die Modelle, die dein Server installiert hat. - Einen `tone` oder ein Glossar, das ein Provider nicht umsetzen kann, meldet verbatra als Hinweis; siehe [Tonfall und Glossar über die Provider hinweg](https://verbatra.kreitz-webdev.de/de/docs/providers.md#tonfall-und-glossar-über-die-provider-hinweg). ### Wie jeder Provider den Code bekommt [#wie-jeder-provider-den-code-bekommt] DeepL und Google Cloud Translation bekommen manche Codes in ihrer eigenen Schreibweise, und DeepL lehnt ein reines `en`- oder `pt`-Ziel vor jedem Request ab. LLM-Provider bekommen den Code plus die [englischen Namen](https://verbatra.kreitz-webdev.de/de/docs/translation-safety.md#namen-von-sprache-schrift-und-region) von Sprache, Schrift und Region. `localeMap` in den `options` des Providers überschreibt den Code pro Locale; die vollständige Zuordnung steht unter [An den Provider gesendete Locale-Codes](https://verbatra.kreitz-webdev.de/de/docs/providers.md#an-den-provider-gesendete-locale-codes). ## Unterstützung vor einem Lauf prüfen [#unterstützung-vor-einem-lauf-prüfen] Bevor etwas ausgegeben wird, beurteilt verbatra jede konfigurierte Locale anhand des Providers, und [`verbatra doctor --locales`](https://verbatra.kreitz-webdev.de/de/docs/cli/doctor.md#locale-unterstützung) gibt die Urteile aus: - **supported**: Der Code, den verbatra sendet, steht in der Tabelle des Providers, oder der Provider ist ein LLM. - **unverified**: Nur die Basissprache steht in der Liste, der Code kommt aus einem expliziten `localeMap`-Eintrag, oder der Provider ist ein LibreTranslate-Server, dessen Modelle nur aus seiner Live-Liste bekannt sind. Sie wird übersetzt, mit der Warnung `LOCALE_UNVERIFIED_BY_PROVIDER`. - **unsupported**: Weder der Code noch seine Basissprache steht in der Liste. `translate`, `watch` und ein Retranslate eines einzelnen Keys lehnen den ganzen Lauf mit [`LOCALE_UNSUPPORTED_BY_PROVIDER`](https://verbatra.kreitz-webdev.de/de/docs/error-codes.md#locale_unsupported_by_provider) ab. Lass die Locale mit `--locales` weg, oder, wenn der Provider die Sprache später hinzugefügt hat, ordne sie in `localeMap` zu: Einem expliziten Eintrag wird vertraut. Die mitgelieferten Tabellen sind Kopien der Listen der Anbieter (DeepL mit 125 Codes und Google mit 198, beide vom 2026-09-28); `verbatra doctor --live` prüft die aktuelle Liste. Für einen LLM-Provider wird nichts abgelehnt. Ein Ziel außerhalb der Sprachen, die LLMs bekanntermaßen gut übersetzen, bekommt die Warnung `LOCALE_NOT_WELL_TESTED` als Anstoß, seine Ausgabe zu reviewen. Die Liste vergleicht die Basissprache, `pt-BR` zählt also als Portugiesisch: Arabisch (`ar`), Chinesisch (`zh`), Niederländisch (`nl`), Englisch (`en`), Französisch (`fr`), Deutsch (`de`), Hindi (`hi`), Indonesisch (`id`), Italienisch (`it`), Japanisch (`ja`), Koreanisch (`ko`), Polnisch (`pl`), Portugiesisch (`pt`), Russisch (`ru`), Spanisch (`es`), Schwedisch (`sv`), Türkisch (`tr`), Ukrainisch (`uk`) und Vietnamesisch (`vi`). ## Schriften und regionale Varianten [#schriften-und-regionale-varianten] Ein Schrift- oder Regions-Subtag ändert, was der Provider gefragt wird, nicht, wie verbatra etwas speichert: | Deine Locale | DeepL | Google Cloud Translation | LibreTranslate | LLM-Provider | | --- | --- | --- | --- | --- | | `pt-BR` / `pt-PT` | `PT-BR` / `PT-PT` | `pt-BR` / `pt-PT` | `pt-BR` / `pt` | Portuguese (Brazil) / Portuguese (Portugal) | | `es-419`, `es-MX` | `ES-419` | `es-419`, `es-MX` | `es` | Spanish (Latin America), Spanish (Mexico) | | `zh-Hans` / `zh-Hant` | `ZH-HANS` / `ZH-HANT` | `zh-CN` / `zh-TW` | `zh-Hans` / `zh-Hant` | Chinese (Simplified) / Chinese (Traditional) | | `sr-Latn` / `sr-Cyrl` | `SR` für beide | `sr-Latn` / `sr-Cyrl` | `sr` für beide | Serbian (Latin) / Serbian (Cyrillic) | DeepL und LibreTranslate behalten eine Schrift nur für Chinesisch, `sr-Latn` und `sr-Cyrl` bekommen also die Schrift, die die Engine für Serbisch schreibt; ein LLM-Provider, dem die Schrift mit Namen genannt wird, ist die verlässliche Wahl. Das Flag `LENGTH_RATIO_OUTLIER` gewichtet Zeichen nach Schrift, kompakter chinesischer, japanischer oder koreanischer Text gilt also nicht als zu kurz, und ein Glossarbegriff in einer Schrift ohne Leerzeichen zwischen Wörtern wird als Enthaltensein abgeglichen. ## Plurale [#plurale] verbatra liest die Pluralkategorien einer Sprache, Ordinalzahlen eingeschlossen, aus den CLDR-Regeln in den ICU-Daten von Node.js: Englisch hat zwei Kardinalkategorien, Russisch und Polnisch vier, Arabisch und Walisisch sechs, Japanisch nur `other`. Für eine Locale ohne Regeln in Node.js nimmt der Hinweis des Laufs `one` und `other` an, Integritäts-Gate, `check` und `doctor` verlangen nur `other`; die Prüfung `plural-rules` von [`verbatra doctor`](https://verbatra.kreitz-webdev.de/de/docs/cli/doctor.md) nennt so eine Locale. Wie ein Plural korrekt bleibt, hängt vom Format ab: - **i18next** kennzeichnet jede Form mit einem CLDR-Suffix (`items_one`, `items_few`). Fehlt der Quelle eine Kategorie, die das Ziel braucht, meldet der Lauf `PLURAL_CATEGORIES_INCOMPLETE`; mit `generatePlurals: true` und einem LLM-Provider schreibt verbatra die fehlenden Formen. Siehe [Eine Sprache hinzufügen](https://verbatra.kreitz-webdev.de/de/docs/add-a-language.md#sprachen-mit-mehr-pluralkategorien). - **next-intl und ARB** halten einen ganzen ICU-Plural in einem Wert, und ein Wert, dessen Zweige nicht zur Zielsprache passen, wird abgelehnt; siehe [Plural-Zweige je Zielsprache](https://verbatra.kreitz-webdev.de/de/docs/translation-safety.md#plural-zweige-je-zielsprache). - **Apple, Android und gettext** reichen genau die Formen durch, die jede Locale hat, und eine fehlende Form musst du von Hand ergänzen. gettext behält seinen `Plural-Forms`-Header wie geschrieben. ### Plural-Warnungen [#plural-warnungen] [`verbatra check`](https://verbatra.kreitz-webdev.de/de/docs/cli/check.md#pluralkategorien) und `verbatra doctor` warnen vor jedem Plural, dem eine Kategorie fehlt, die seine Sprache verwendet, in jedem oben genannten Format außer gettext, dessen Formen seinem eigenen Header folgen; Plurale in anderen Formaten werden nicht geprüft. DeepL, Google Cloud Translation und LibreTranslate übersetzen die vorhandenen Formen, erzeugen aber nie neue. ## Sprachen, die von rechts nach links laufen [#sprachen-die-von-rechts-nach-links-laufen] Arabisch, Hebräisch, Persisch, Urdu und andere Sprachen, die von rechts nach links laufen, brauchen keine Sonderbehandlung: Ein Wert wird gelesen, gesendet, geprüft und so zurückgeschrieben, wie er ist, ohne hinzugefügte, entfernte oder umgeordnete Richtungszeichen. Was das für dich heißt: - **Setz die Richtung in deiner App, nicht in den Strings**, mit dem Attribut `dir`, CSS oder der Layoutrichtung deiner Plattform. Die [Inline-Markup-Prüfung](https://verbatra.kreitz-webdev.de/de/docs/translation-safety.md#inline-markup-parität) lehnt eine Übersetzung ab, die ein `dir`-Attribut hinzufügt, das die Quelle nicht hat. - **Richtungsmarken sind Text** und dürfen wegfallen; prüf Übersetzungen, die eine brauchen. Offene Einbettungen, Überschreibungen oder Isolierungen (schließt die Quelle ihre) und neue Überschreibungen lösen [`BIDI_CONTROLS_CHANGED`](https://verbatra.kreitz-webdev.de/de/docs/error-codes.md#bidi_controls_changed) aus. - **Eine geänderte Platzhalter-Reihenfolge** löst nur `INTEGRITY_REORDERED` aus, weil eine andere Reihenfolge in einer anderen Sprache oft richtig ist. - **Studio zeigt Werte von rechts nach links** für jede Locale, deren Schrift so läuft, nach der Richtung des Browsers oder der wahrscheinlichen Schrift der Locale (`ku-Arab` von rechts nach links, `ku` von links nach rechts). Nur die Anzeige ändert sich. - **[`verbatra pseudo --mode bidi`](https://verbatra.kreitz-webdev.de/de/docs/cli/pseudo.md) zeigt deine Quelle von rechts nach links** in einer `ar-XB`-Pseudolocale und deckt Annahmen über Links-nach-rechts-Layout auf, bevor es eine Übersetzung gibt. Gespiegelte Bilder und Icons prüfst du selbst. ## Ressourcenarme Sprachen und lokale Modelle [#ressourcenarme-sprachen-und-lokale-modelle] Für eine Sprache, die dein gehosteter Provider schlecht abdeckt: - **Ein lokales Modell über `openai-compatible` betreiben.** Es muss ein auf Anweisungen trainiertes Chat-Modell sein, das ein JSON-Objekt zurückgibt; siehe [Ein lokales Modell wählen](https://verbatra.kreitz-webdev.de/de/docs/providers.md#ein-lokales-modell-wählen). - **Ein spezialisiertes Übersetzungsmodell außerhalb von verbatra nutzen** und das Ergebnis über den [Roundtrip mit der Arbeitsmappe](https://verbatra.kreitz-webdev.de/de/docs/manual-translation.md) zurückholen, der dieselben Integritätsprüfungen ausführt. Keines davon passt an `openai-compatible`, denn es sind keine Chat-Modelle: [MADLAD-400](https://huggingface.co/google/madlad400-3b-mt) (Apache-2.0, über 400 Sprachen), [TranslateGemma](https://huggingface.co/google/translategemma-4b-it) (55 Sprachen, Gemma-Nutzungsbedingungen) und [NLLB-200](https://huggingface.co/facebook/nllb-200-distilled-600M) (etwa 200 Sprachen, aber CC-BY-NC-4.0, also nicht für ein kommerzielles Produkt). Prüf die Lizenz jedes Modells selbst. - **Einen Menschen übersetzen lassen.** Der [Arbeitsablauf ohne maschinelle Übersetzung](https://verbatra.kreitz-webdev.de/de/docs/human-only-workflow.md) funktioniert für jede Sprache.