Ein praktischer Vue 3 i18n‑Workflow für große Apps: Schlüsselbenennung, Pluralregeln, QA‑Checks und Release‑Schritte, um fehlende Übersetzungen in Produktion zu vermeiden.
Sobald deine App ein paar hundert Strings überschreitet, ist das Erste, was normalerweise kaputtgeht, selten Vue I18n. Es ist die Konsistenz. Leute fügen Keys in unterschiedlichen Stilen hinzu, duplizieren dieselbe Idee unter verschiedenen Namen, und niemand ist sich sicher, welche Messages gefahrlos gelöscht werden können.
Fehlende Übersetzungen hören auch auf, selten zu sein. Sie tauchen in normalen Nutzerpfaden auf, besonders in weniger genutzten Bildschirmen wie Einstellungen, Fehlerzuständen, leeren Zuständen und Benachrichtigungen.
Wenn eine Übersetzung fehlt, sehen Nutzer meist einen von drei Fehlern: eine leere UI (ein Button ohne Beschriftung), rohe Keys (wie checkout.pay_now) oder ein seltsamer Fallback, bei dem ein Teil der Seite die Sprache wechselt. Keines davon fühlt sich wie ein kleines Bug an. Es lässt die App kaputt wirken.
Deshalb ist ein Vue 3 i18n‑Workflow wichtiger als die konkrete Bibliothek. Die Bibliothek macht, was du ihr sagst. Im großen Maßstab stimmen Teams oft nicht darin überein, wie „fertig“ aussieht.
Ein häufiges Beispiel: Ein Entwickler liefert einen neuen „Invite teammate“‑Flow mit 40 neuen Strings. Die englische Datei wird aktualisiert, aber die französische nicht. In Staging sieht alles gut aus, weil der Tester Englisch nutzt. In Produktion sehen französische Nutzer eine Mischung aus übersetzter und nicht übersetzter UI, und der Support bekommt Screenshots von rohen Keys.
Die Lösung ist, zu definieren, was „fertig“ für übersetzte UI bedeutet. Es kann nicht nur „Strings hinzugefügt“ sein. Eine praktische Definition von fertig umfasst normalerweise: Keys folgen Benennungsregeln, Locales bauen ohne Missing‑Key‑Warnungen, Plurale und Variablen rendern mit realen Daten korrekt, mindestens eine Nicht‑Default‑Locale wurde geprüft, und Textänderungen werden nachverfolgt, damit alte Keys nicht hängen bleiben.
Bei 500+ Keys gewinnst du, wenn du Lokalisierung wie einen Release‑Prozess behandelst, nicht als Last‑Minute‑Dateiedit.
Nach ein paar hundert Strings ist Übersetzungsarbeit nicht mehr das Unordentliche — Konsistenz ist es. Eine kleine Menge Regeln macht deinen Vue 3 i18n‑Workflow vorhersehbar, selbst wenn jede Woche mehrere Personen an Text arbeiten.
Beginne damit, zu entscheiden, was ein „Konzept“ ist, und eine einzige Quelle der Wahrheit dafür zu behalten. Wenn dieselbe UI‑Idee an fünf Stellen erscheint (z. B. „Änderungen speichern“), willst du einen Key, nicht fünf Variationen wie save, saveChanges, save_update und saveBtn. Duplizierte Keys driften mit der Zeit in der Bedeutung, und Nutzer spüren diese Inkonsistenz.
Als Nächstes entscheide, wo Formatierung stattfindet. Teams teilen das oft unabsichtlich auf: manche Messages enthalten Interpunktion und Großschreibung, andere verlassen sich auf den Code, um das hinzuzufügen. Wähle einen Ansatz und bleibe dabei.
Eine praktische Default‑Regel:
Dann definiere Ownership. Entscheide, wer neue Keys hinzufügen darf, wer die Basissprache überprüft und wer andere Locales abnimmt. Ohne das werden Strings schnell hinzugefügt und nie geprüft.
Schließlich wähle und dokumentiere eine Fallback‑Strategie. Wenn ein Key fehlt, was sollen Nutzer sehen: den Key‑Namen, den Text der Default‑Locale oder eine sichere generische Nachricht? In Produktion bevorzugen viele Teams das Fallback zur Default‑Locale plus Logging, damit Nutzer nicht blockiert werden, während ihr trotzdem ein Signal bekommt, dass etwas nicht stimmt.
Wenn du Vue 3 Apps mit einem Generator wie AppMaster (Vue3 web UI plus echter Backend‑Code) baust, gelten diese Regeln weiterhin. Behandle Übersetzungen wie Produkt‑Content, nicht „nur Dev‑Text“, und du vermeidest die meisten späten Überraschungen.
Ab ein paar hundert Strings ist Konsistenz der größte Multiplikator. Wähle einen Key‑Stil (die meisten Teams nutzen Punktpfade wie billing.invoice.title) und mache ihn zur Regel. Das Mischen von Punkten, Slashes, snake_case und zufälliger Groß-/Kleinschreibung macht Suche und Reviews langsam.
Nutze stabile Keys, die Copy‑Änderungen überleben. Ein Key wie „Please enter your email“ bricht, sobald Marketing den Satz anpasst. Bevorzuge intent‑basierte Namen wie auth.email.required oder auth.email.invalid.
Gruppiere Keys zuerst nach Produktbereich oder UI‑Surface, dann nach Zweck. Denk in denselben Buckets, die deine App schon hat: auth, billing, settings, support, dashboard. Das macht Locale‑Dateien leichter durchsuchbar und reduziert Duplikate, wenn zwei Screens dieselbe Idee benötigen.
Innerhalb jedes Bereichs halte ein kleines Set an Mustern für gängige UI‑Teile:
*.actions.save, *.actions.cancel*.fields.email.label, *.fields.password.label*.fields.email.hint*.errors.required, *.errors.invalidFormat*.notices.saved, *.notices.failedDynamische Messages sollten sagen, was sich ändert, nicht wie. Benenne die Message nach der Absicht und nutze Parameter für die variablen Teile. Beispiel: billing.invoice.dueInDays mit {days} ist klarer als billing.invoice.dueIn3Days.
Beispiel (funktioniert gut in einem Vue 3 i18n‑Workflow): orders.summary.itemsCount mit {count} für die Anzahl und orders.summary.total mit {amount} für Geld. Wenn jemand den Key im Code liest, sollte er wissen, wo er hingehört und warum er existiert, auch wenn der finale Text später geändert wird.
Plurale brechen still, wenn du jede Sprache wie Englisch behandelst. Entscheide früh, wann du ICU‑Message‑Syntax nutzt und wann ein einfacher Platzhalter ausreicht.
Verwende einfache Ersetzungen für Labels und kurze UI‑Texte, die sich nie durch die Zahl ändern (z. B. Welcome, {name}). Wechsle zu ICU für alles Zähler‑basierte, weil es alle Formen an einem Ort hält und die Regeln explizit macht.
{
"notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}
Formuliere Zähl‑Messages so, dass sie leicht zu übersetzen sind. Bevorzuge einen vollständigen Satz und halte den Zahlenplatzhalter (#) nahe beim Substantiv. Vermeide clevere Abkürzungen wie denselben Key für „1 item“ und „2 items“ zu nutzen. Übersetzer müssen die ganze Message sehen, nicht raten, wie sie zusammengesetzt wird.
Plane mindestens =0, one und other ein und dokumentiere, was du für 0 erwartest. Manche Produkte wollen „0 items“, andere „Keine Einträge“. Wähle einen Stil und bleib dabei, damit sich die UI konsistent anfühlt.
Achte außerdem auf Sprachen mit mehr Plural‑Kategorien als du erwartest. Viele Sprachen folgen nicht einfach „one vs many“. Wenn du später eine neue Locale hinzufügst, kann eine Message mit nur one und other grammatikalisch falsch sein, auch wenn sie technisch rendert.
Teste Plurale vor dem Shipping mit realen Counts in der UI und nicht nur durch das Ansehen von JSON. Ein schneller Check, der die meisten Probleme auffängt, ist 0, 1, 2, 5 und 21.
Wenn du eine Vue3 Web‑App baust (zum Beispiel mit AppMaster), mache diesen Test auf dem tatsächlichen Bildschirm, wo der Text erscheint. Layout‑Probleme, abgeschnittene Texte und unglückliche Formulierungen treten dort zuerst auf.
Nach ein paar hundert Strings wird aus einer großen en.json schnell ein Flaschenhals. Viele Leute bearbeiten dieselbe Datei, Merge‑Konflikte wachsen und du verlierst den Überblick, wo Copy liegt. Eine gute Struktur hält deinen Vue 3 i18n‑Workflow stabil, auch wenn das Produkt sich weiterentwickelt.
Für 2 bis 5 Locales reicht meist eine Aufteilung nach Feature. Behalte das gleiche Dateilayout in jeder Locale, damit das Hinzufügen eines Keys eine vorhersehbare Änderung ist.
locales/en/common.json, locales/en/auth.json, locales/en/billing.jsonlocales/es/common.json, locales/es/auth.json, locales/es/billing.jsonlocales/index.ts (lädt und merged die Messages)Für 20+ Locales skaliere dieselbe Idee, mache es aber schwerer, dass Dinge auseinanderdriften. Behandle Englisch als Quelle der Wahrheit und sorge dafür, dass jede Locale dieselben Ordner‑ und Dateinamen hat. Wenn eine neue Domain auftaucht (z. B. notifications), sollte sie in jeder Locale existieren, selbst wenn der Text vorübergehend ist.
Das Aufteilen nach Domain reduziert Merge‑Konflikte, weil zwei Leute Strings in verschiedenen Dateien hinzufügen können, ohne sich in die Quere zu kommen. Domains sollten dem entsprechen, wie deine App gebaut ist: common, navigation, errors, settings, reports, plus Feature‑Ordner für größere Bereiche.
Innerhalb jeder Datei behalte dieselbe Key‑Form über alle Locales: gleiche Verschachtelung, gleiche Key‑Namen, anderer Text. Vermeide „kreative“ Keys pro Sprache, selbst wenn eine Phrase schwer zu übersetzen ist. Wenn Englisch billing.invoice.status.paid braucht, muss jede Locale genau diesen Key haben.
Zentralisiere nur, was wirklich überall wiederholt wird: Button‑Labels, generische Validierungsfehler und globale Navigation. Halte Feature‑spezifische Copy nahe bei der Feature‑Domain, auch wenn sie wiederverwendbar erscheint. „Speichern“ gehört in common. „Zahlungsmethode speichern“ gehört in billing.
Lange Hilfetexte, Onboarding‑Schritte und E‑Mail‑Templates werden schnell unübersichtlich. Ein paar Regeln helfen:
help oder onboarding) und vermeide tiefe Verschachtelung.Dieses Setup erleichtert das Review von Änderungen, das Übersetzen und verhindert überraschende Lücken kurz vor dem Release.
Ein stabiler Vue 3 i18n‑Workflow dreht sich weniger um Tools und mehr darum, dieselben kleinen Schritte jedes Mal zu wiederholen. Neuer UI‑Text sollte nicht ohne Key, Default‑Message und klaren Übersetzungsstatus in Produktion gelangen.
Beginne damit, den Key in deiner Basis‑Locale (oft en) hinzuzufügen. Schreibe den Default‑Text wie echte Copy, nicht als Platzhalter. Das gibt Produkt und QA etwas Lesbares zum Prüfen und verhindert "mystery strings" später.
Wenn du den Key in einer Komponente verwendest, nimm von Anfang an Parameter und Plural‑Logik auf, damit Übersetzer die volle Form der Message sehen.
// simple param
$t('billing.invoiceDue', { date: formattedDate })
// plural
$t('files.selected', count, { count })
Wenn Übersetzungen nicht bereit sind, lass Keys nicht fehlen. Füge Platzhalterübersetzungen in anderen Locales hinzu oder markiere sie konsistent als pending (z. B. mit dem Prefix TODO:). Wichtig ist, dass die App vorhersehbar rendert und Reviewer unvollständige Texte sofort erkennen.
Vor dem Mergen führe schnelle automatisierte Checks aus. Halte sie langweilig und strikt: fehlende Keys über Locales hinweg, ungenutzte Keys, Platzhalter‑Mismatch (fehlt {count}, {date} oder falsche Klammern), ungültige Pluralformen für unterstützte Sprachen und versehentliche Überschreibungen.
Mache einen kurzen UI‑Durchgang in mindestens einer Nicht‑Basis‑Locale. Wähle eine Sprache mit längeren Strings (oft Deutsch oder Französisch), um Überlauf, abgeschnittene Buttons und ungünstige Zeilenumbrüche zu erkennen. Wenn deine Vue 3 UI generiert oder neben anderen Produktteilen gepflegt wird (z. B. eine Vue3 Web‑App, die von AppMaster erzeugt wird), bleibt dieser Schritt wichtig, weil Layouts sich mit Features ändern.
Behandle diese Schritte als deine Definition von done für jedes Feature, das Text hinzufügt.
Der schnellste Weg, Lokalisierung schmerzhaft zu machen, ist, i18n‑Keys als „nur Strings“ zu behandeln. Nach ein paar hundert Keys werden aus kleinen Gewohnheiten Produktionsbugs.
Rechtschreibfehler und Unterschiede in der Groß‑/Kleinschreibung sind klassische Ursachen für fehlenden Text: checkout.title an einer Stelle, Checkout.title an einer anderen. Im Code‑Review sieht das oft ok aus, aber deine Fallback‑Sprache wird stillschweigend ausgeliefert.
Ein weiteres Problem ist, einen Key für verschiedene Bedeutungen wiederzuverwenden. „Open“ kann „Ticket öffnen“ in einem Support‑Screen und „Jetzt öffnen“ in einem Shop‑Kontext bedeuten. Wenn du denselben Key wiederverwendest, wird einer der Screens in anderen Sprachen falsch sein und Übersetzer müssen raten.
Eine einfache Regel hilft: ein Key = eine Bedeutung. Wenn sich die Bedeutung ändert, erstelle einen neuen Key, auch wenn der englische Text gleich bleibt.
Teams fügen oft Interpunktion, Abstände oder Stücke von HTML in Übersetzungen ein. Das funktioniert, bis eine Sprache andere Zeichensetzung braucht oder dein UI Markup anders escaped oder rendert. Halte Markup‑Entscheidungen in Templates und Messages auf reinen Text fokussiert.
Mobile ist der Ort, an dem Probleme sich verstecken. Ein Label, das in Englisch passt, kann in Deutsch in drei Zeilen umbrechen oder in Thailändisch überlaufen. Wenn du nur eine Bildschirmgröße testest, verpasst du das.
Achte auf typische Fehler: die englische Wortreihenfolge annehmen, wenn Variablen eingefügt werden (Namen, Zahlen, Daten), Messages durch Zusammensetzen von Teilen bauen statt durch eine einzige Message, nicht mit langen Werten testen (Produktnamen, Adressen, Fehlerdetails), mit stillem Fallback ausliefern, sodass fehlende Keys in Englisch „ok“ aussehen, und Keys copy‑pasten und nur den englischen Wert bearbeiten.
Wenn du einen Vue 3 i18n‑Workflow willst, der bei 500+ Keys ruhig bleibt, behandle Keys wie Teil deiner API: stabil, spezifisch und getestet wie alles andere.
Fehlende Übersetzungen sind leicht zu übersehen, weil die App noch „funktioniert“. Sie fällt nur auf den Key, die falsche Locale oder einen leeren String zurück. Behandle Übersetzungsabdeckung wie Tests: du willst schnelles Feedback, bevor etwas in Produktion geht.
Beginne mit Checks, die den Build fehlschlagen lassen, nicht nur Warnungen ausgeben, die niemand liest.
$t('...') und t('...') Nutzung und verifiziere, dass jeder verwendete Key in der Basis‑Locale existiert.Halte die Ausnahmeliste kurz und im Besitz des Teams, nicht „was auch immer CI bestehen lässt“.
Trotz CI brauchst du ein Netz in Staging, weil echte Nutzerpfade Strings auslösen, die du vergessen hast.
Aktiviere Missing‑Translation‑Logging in Staging und gib ausreichend Kontext an, um schnell zu beheben: Locale, Route, Komponentenname (falls verfügbar) und den fehlenden Key. Mach es laut. Wenn es leicht zu ignorieren ist, wird es ignoriert.
Füge eine Pseudo‑Locale hinzu und nutze sie für einen schnellen UI‑Check. Ein einfacher Ansatz ist, jeden String zu transformieren (länger machen und Marker hinzufügen), sodass Layout‑Probleme sofort auffallen, z. B.: [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲𝗱 !!!]. Das fängt abgeschnittene Buttons, kaputte Tabellenüberschriften und fehlende Abstände vor dem Shipping.
Mache zum Schluss eine kurze Pre‑Release‑Stichprobe deiner wichtigsten Flows in 2–3 Locales: Anmeldung, Checkout/Bezahlung, zentrale Einstellungen und das neue Feature, das du auslieferst. Dort findest du oft „wurde übersetzt, aber der Platzhalter ist falsch“‑Bugs.
Das Hinzufügen einer neuen Sprache wird chaotisch, wenn du es als „Copy‑Arbeit“ statt als kleines Produkt‑Release behandelst. Der einfachste Weg, deinen Vue 3 i18n‑Workflow stabil zu halten, ist, die App auch bei unvollständiger Locale bauen zu lassen und Lücken deutlich zu machen, bevor Benutzer sie sehen.
Wenn du eine neue Locale anlegst, starte damit, dieselbe Dateistruktur wie die Quell‑Locale (oft en) zu generieren. Übersetze nicht zuerst, strukturiere zuerst.
Übersetzungen kommen oft zu spät, also entscheide im Voraus, was „teilweise“ für dein Produkt bedeutet. Wenn ein Feature kundenorientiert ist, erwäge ein Feature‑Flag, sodass Feature und Strings zusammen ausgerollt werden. Wenn du ohne vollständige Übersetzungen ausrollen musst, bevorzuge ein klares Fallback (z. B. Englisch) statt leerer Labels, aber mache das in Staging deutlich.
Textänderungen sind der Punkt, an dem Teams Keys brechen. Wenn du die Formulierung änderst, behalte den Key stabil. Keys sollten die Absicht beschreiben, nicht den exakten Satz. Eine Key‑Umbenennung spare für den Fall auf, dass sich die Bedeutung ändert, und führe sie dann mit einer kontrollierten Migration durch.
Um „Zombie‑Strings" zu vermeiden, depreziere Keys absichtlich: markiere sie mit einem Datum und Ersatz, behalte sie für einen Release‑Zyklus und entferne sie erst, nachdem du bestätigt hast, dass es keine Referenzen mehr gibt.
Halte Übersetzungsnotizen nahe beim Key. Wenn dein JSON‑Format keine Kommentare zulässt, speichere Notizen in einem kleinen Begleitdokument oder einer angrenzenden Metadatei (z. B. „verwendet auf Checkout Success Screen"). Das ist besonders hilfreich, wenn deine Vue3 Web‑App mit einem Tool wie AppMaster generiert wird und mehrere Personen an Copy und UI arbeiten.
In einem Sprint liefert dein Team drei Dinge gleichzeitig: eine neue Einstellungen‑Seite, eine Billing‑Ansicht und drei E‑Mail‑Templates (Beleg, Zahlung fehlgeschlagen, Probezeit endet). Das sind etwa 60 neue Strings und genau dort beginnt i18n meist chaotisch zu werden.
Das Team stimmt zu, Keys nach Feature und dann nach Oberfläche zu gruppieren. Für jedes Feature wird eine neue Datei erstellt und Keys folgen überall demselben Muster: feature.area.element.
// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",
// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",
// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"
Bevor die Übersetzungsarbeit beginnt, werden Plural‑Strings mit echten Werten getestet, nicht geraten. Für billing.invoice.count prüft QA 0, 1, 2 und 5 mit Testdaten oder einem einfachen Dev‑Toggle. Das fängt frühe Probleme wie „0 invoice“ ab.
QA führt dann einen fokussierten Flow durch, der gerne fehlende Keys aufdeckt: Einstellungen und Billing öffnen und jeden Tab einmal anklicken, jedes E‑Mail‑Template in Staging mit Testkonten auslösen, die App mit einer Nicht‑Standard‑Locale laufen lassen und den Build fehlschlagen lassen, wenn Missing‑Translation‑Warnungen im Log auftauchen.
In diesem Sprint findet QA zwei fehlende Keys: ein Label auf dem Billing‑Screen und ein E‑Mail‑Subject. Das Team behebt sie vor dem Release.
Bei der Entscheidung, ob der Release blockiert wird oder Fallback erlaubt ist, nutzen sie eine einfache Regel: Kundensichtige Screens und transaktionale E‑Mails blockieren den Release; risikoarme Admin‑Texte können vorübergehend auf die Default‑Sprache zurückfallen, aber nur mit einem Ticket und einer klaren Deadline.
Ein Vue 3 i18n‑Workflow bleibt stabil, wenn du Übersetzungen wie Code behandelst: füge sie immer gleich hinzu, teste sie und halte Notizen.
Wähle ein paar einfache Kennzahlen und überprüfe sie regelmäßig: Fehlende‑Key‑Rate in deinem Testlauf, Anzahl unübersetzter Strings in Nicht‑Default‑Locales und Anzahl ungenutzter Keys (Strings, die nicht mehr verwendet werden). Verfolge sie pro Release, wenn möglich, damit du Trends statt Einzelereignisse siehst.
Schreibe die genauen Schritte für das Hinzufügen eines Strings, das Aktualisieren von Übersetzungen und das Verifizieren nieder. Halte es kurz und füge Beispiele für Key‑Namen und Pluralnutzung bei. Neue Mitwirkende sollten es ohne Fragen befolgen können.
Wenn du interne Tools baust, kann AppMaster (appmaster.io) ein praktischer Weg sein, UI‑Copy und Übersetzungskeys konsistent über eine Vue3 Web‑App und zugehörige Mobile‑Apps zu halten, weil alles an einem Ort verwaltet wird.
Plane in jedem Sprint eine kleine i18n‑Health‑Aufgabe: tote Keys löschen, inkonsistente Platzhalter korrigieren und kürzliche Fails reviewen. Kleine Aufräumarbeiten schlagen Notfall‑Übersetzungsjagden in Produktion.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
