Sprachen und Locales

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-CodesLink zu diesem Abschnitt kopieren

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.

Der Code aus deiner Konfiguration ist der, den verbatra überall speichert: Dateipfade, die Lock-Datei und der Cache. 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.

Abdeckung je ProviderLink zu diesem Abschnitt kopieren

Wie gut eine Sprache übersetzt wird, ist Sache des Providers; jede Zeile verlinkt die eigene Liste des Anbieters.

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 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.

Wie jeder Provider den Code bekommtLink zu diesem Abschnitt kopieren

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 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.

Unterstützung vor einem Lauf prüfenLink zu diesem Abschnitt kopieren

Bevor etwas ausgegeben wird, beurteilt verbatra jede konfigurierte Locale anhand des Providers, und verbatra doctor --locales 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 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 VariantenLink zu diesem Abschnitt kopieren

Ein Schrift- oder Regions-Subtag ändert, was der Provider gefragt wird, nicht, wie verbatra etwas speichert:

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.

PluraleLink zu diesem Abschnitt kopieren

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 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.
• 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.
• 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-WarnungenLink zu diesem Abschnitt kopieren

verbatra check 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 laufenLink zu diesem Abschnitt kopieren

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 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 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 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 ModelleLink zu diesem Abschnitt kopieren

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.
• Ein spezialisiertes Übersetzungsmodell außerhalb von verbatra nutzen und das Ergebnis über den Roundtrip mit der Arbeitsmappe zurückholen, der dieselben Integritätsprüfungen ausführt. Keines davon passt an openai-compatible, denn es sind keine Chat-Modelle: MADLAD-400 (Apache-2.0, über 400 Sprachen), TranslateGemma (55 Sprachen, Gemma-Nutzungsbedingungen) und NLLB-200 (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 funktioniert für jede Sprache.