Wie du eine KI-generierte App lokalisierst

Dieser Guide erklärt, wie du eine KI-generierte App zuerst internationalisierst und dann lokalisierst: Keys, Übersetzungsdateien, Extraktion, Glossare und Automatisierung, die schnelle UI-Änderungen überlebt. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die diese Kataloge bei jedem Push mit Git synchron hält — einmal einrichten, bei jedem Push automatisch synchronisieren, keine manuellen Datei-Roundtrips mehr. Warum KI-first-Codebases die i18n-Ebene oft überspringen, liest du in KI-Code hat Lokalisierung kaputt gemacht — und niemand hat es behoben. Für den Branchenkontext über verschiedene Tooling-Ären hinweg siehe 3 Phasen der Lokalisierungsentwicklung (und warum KI alles verändert). Für die richtige Reihenfolge bei Anbietern, wenn Repos noch chaotisch sind, lies globalize.now vs. Lokalise vs. Crowdin und die praktische Globalisierungs-Anleitung in So globalisierst du deine App mit globalize.now.

---

Was bedeutet „eine KI-generierte App lokalisieren“ eigentlich?

Lokalisierung (l10n) ist das, was Nutzer sehen: korrekte Sprache, Plurale, Datumsangaben, Währung und Layout für ihr Locale.

Internationalisierung (i18n) ist das, was Engineers zuerst erledigen: nutzersichtbaren Text adressierbar, wiederholbar und sicher übersetzbar im großen Maßstab machen.

Die meisten „wir können noch nicht lokalisieren“-Blocker sind eigentlich i18n-Blocker. Behebe die Architektur einmal, und Lokalisierung wird zum operativen Thema statt zum Archäologie-Projekt.

---

Was gehört auf eine i18n-Architektur-Checkliste, bevor du Tools auswählst?

Bevor du Software für die Übersetzungskoordination oder einen Übersetzungsanbieter auswählst, stelle sicher, dass diese Bausteine existieren — oder plane, sie in dieser Reihenfolge einzuführen:

• Runtime-i18n-Bibliothek, passend zu deinem Stack (React, Next.js, Rails usw.), mit einem einzigen unterstützten Muster für UI-Strings.
• Stabile Übersetzungsschlüssel (mit Namespace, hierarchisch) statt englischer Sätze als IDs.
• Locale-Ressourcendateien (JSON, PO, YAML), die ins Repo eingecheckt oder in der CI generiert werden.
• ICU-artige Plurale und Variablen für dynamische Phrasen wie "{count} items", damit Übersetzer:innen die Grammatik sicher umstellen können.
• Eine String-Extraktions-Pipeline, damit neue UI nicht stillschweigend am Katalog vorbeigeht.

---

Wie extrahierst du Strings, ohne Tempo zu verlieren?

KI-generierte Repos wiederholen oft dieselben Labels („Speichern“, „Abbrechen“, „Mehr erfahren“) in Dutzenden von Dateien. Dein Extraktions-Durchgang sollte:

1. Nutzersichtbare Literale erkennen in Komponenten, Routen und gemeinsamen UI-Primitiven — technische Strings dagegen ignorieren (CSS-Klassen, Analytics-IDs, URLs, außer sie sind nutzersichtbar).
2. Duplikate normalisieren zu einem Key mit Referenzen, damit Übersetzer:innen eine einzige Sinneinheit sehen.
3. Ein Quell-Locale ausgeben (meist Englisch) als kanonischen Wert für jeden neuen Key.
4. Aufrufstellen umschreiben, um die i18n-API zu verwenden, auf die sich dein Team geeinigt hat — mechanisch, damit der Diff überprüfbar bleibt.

Ein minimales Vorher/Nachher in React-artigem Code sieht so aus:

<button>Submit order</button>

Nach Extraktion und Verschlüsselung:

<button>{t("checkout.submit_order")}</button>

// locales/en.json
{
  "checkout.submit_order": "Submit order"
}

---

Warum sind Glossare und Styleguides wichtig, bevor du auf mehr Sprachen skalierst?

Maschinelle Übersetzung ist schnell. Sie macht es aber auch leicht, dass jeder Screen wie ein anderes Produkt klingt, wenn du keine Vorgaben definierst. Bevor du auf viele Sprachen skalierst, halte fest:

• Markenbegriffe, die nicht übersetzt werden dürfen (Produktname, Feature-Namen).
• Bevorzugte Übersetzungen für risikoreiche Wörter („Kontakt“, „Testphase“, „Abrechnung“, „Workspace“).
• Ton: formell vs. locker, sowie Duzen vs. neutrale Ansprache.

Speise dieses Glossar in deinen Koordinations-Stack oder dein MT-Profil ein, damit automatisierte Entwürfe mit den Entscheidungen deines Teams übereinstimmen.

---

Wie sollten automatisierte Checks den Übersetzungs-QA-Loop verankern?

Sobald Keys in Übersetzungsdateien fließen, sieht der moderne Loop so aus: MT-Entwurf → Linter-Checks (Länge, Platzhalter, verbotene Begriffe) → automatisierte Regressionstests auf wichtigen Oberflächen → Release → Messung. Die Automatisierung spart Zeit; der Linter bewahrt dich davor, kaputte Platzhalter zu releasen.

CLI-artiges Tooling kann dir schnelles Feedback geben, wie viel Arbeit im Repo noch übrig ist, etwa so:

✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json

Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1

---

Welche Agent-Prompts halten Lokalisierungs-Refactorings überprüfbar?

Diese Prompts setzen voraus, dass du in einem Repo mit Tests und Code-Review arbeitest. Sie sind darauf ausgelegt, Diffs zu erzeugen, denen du vertrauen kannst — keine stillen, breit angelegten Refactorings.

Wie erstellst du ein Inventar der UI-Strings, bevor du refaktorierst?

You are analyzing a TypeScript React codebase for localization readiness.

Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.

Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).

Wie führst du eine minimale, typisierte t()-API sicher ein?

Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.

Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key

Show the file tree you created and example usage in two existing components.

Wie extrahierst du Literale mechanisch in Keys mit Namespace?

Refactor the following files to replace user-visible string literals with t("…") keys.

Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor

After edits, print a JSON object mapping each new key to its English source string for translators.

Wie solltest du eine Glossar-CSV entwerfen, der Übersetzer:innen vertrauen können?

From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.

Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").

Welche CI-Absicherung verhindert, dass neues hartcodiertes Englisch einfließt?

Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.

Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure

Include README notes for how engineers should add exceptions responsibly.

---

Musst du diese Prompts immer noch von Hand einfügen?

Zunehmend nicht mehr. Als dieser Guide erstmals geschrieben wurde, war Copy-Paste von Prompts in deinen Agent der praktische Weg, den Loop zu fahren. Seitdem ist das Tooling in den Agent selbst gewandert: Coding-Agents können Lokalisierung inzwischen direkt über einen MCP-Server aufrufen — Extraktion, Keying und Übersetzungssync werden so zu Tool-Calls, die der Agent selbst macht, statt zu Prompts, die du einfügst. Das Setup findest du in Der globalize.now-MCP im Überblick, und warum diese Verschiebung architektonisch wichtig ist, in Lokalisierung wird zum Agent-Skill, nicht zum SDK.

Die oben genannten Prompts bleiben als Review-Checklisten nützlich — sie beschreiben, was ein gutes, agent-getriebenes i18n-Refactoring leisten muss, egal ob ein Mensch sie einfügt oder ein Agent-Skill sie kodiert. Bewerte jedes automatisierte Refactoring am selben Maßstab: überprüfbare Diffs, stabile Keys, ICU-sichere Interpolation und eine CI-Absicherung, die Regressionen stoppt.

---

Welche langfristige Einschränkung solltest du beim Lokalisieren KI-gebauter Produkte im Blick behalten?

Lokalisierung ist kein einmaliger Sprint — sie ist ein Vertrag mit deinem zukünftigen Ich. Investierst du einmal in Keys, Kataloge und Automatisierung, wird jeder neue KI-generierte Screen günstiger, um ihn weltweit zu releasen.