Planen Sie eine Web-App zur Verwaltung von Übersetzungs-Workflows, Locale-Daten, Reviews, QA-Prüfungen und Releases. Enthält Datenmodell, UX und Integrationen.
Lokalisierungsmanagement ist die tägliche Arbeit, die Texte Ihres Produkts (und manchmal Bilder, Datums-, Währungs- und Formatierungsregeln) zu übersetzen, zu prüfen, freizugeben und auszuliefern — ohne den Build zu zerstören oder Nutzer zu verwirren.
Für ein Produktteam ist das Ziel nicht „alles übersetzen“. Es geht darum, jede Sprachversion korrekt, konsistent und aktuell zu halten, während sich das Produkt ändert.
Die meisten Teams starten mit guten Absichten und enden im Chaos:
Eine nützliche Lokalisierungsmanagement-Web-App unterstützt mehrere Rollen:
Sie bauen ein MVP, das Strings zentralisiert, den Status pro Locale verfolgt und grundlegende Review- und Exportfunktionen unterstützt. Ein vollständigeres System ergänzt Automatisierung (Sync, QA-Checks), reichhaltigeren Kontext und Tools wie Glossar und Translation Memory.
Bevor Sie Tabellen oder Bildschirme entwerfen, entscheiden Sie, wofür Ihre Lokalisierungsmanagement-Web-App tatsächlich verantwortlich ist. Ein enger Scope macht die erste Version nutzbar — und verhindert, dass Sie später viel neu bauen müssen.
Übersetzungen leben selten an einem Ort. Schreiben Sie auf, was Sie von Tag 1 unterstützen müssen:
Diese Liste hilft Ihnen, „ein Workflow für alles“ zu vermeiden. Marketing-Texte brauchen z. B. oft Freigaben, während UI-Strings schnelle Iteration erfordern.
Wählen Sie 1–2 Formate fürs MVP und erweitern Sie später. Gängige Optionen sind JSON, YAML, PO und CSV. Eine praktische MVP-Wahl sind JSON oder YAML (für App-Strings) und ggf. CSV, wenn Sie bereits Tabellen-Importe nutzen.
Seien Sie explizit bei Anforderungen wie Pluralformen, verschachtelten Keys und Kommentaren. Diese Details beeinflussen Ihr Locale-File-Management und die Zuverlässigkeit von Import/Export.
Definieren Sie eine Quellsprache (oft en) und legen Sie Fallback-Verhalten fest:
Entscheiden Sie außerdem, was „fertig“ pro Locale bedeutet: 100 % übersetzt, geprüft oder ausgeliefert.
Für das MVP konzentrieren Sie sich auf den Übersetzungs-Review-Prozess und den grundlegenden i18n-Workflow: Strings anlegen/bearbeiten, Arbeit zuweisen, reviewen und exportieren.
Planen Sie spätere Ergänzungen — Screenshots/Kontext, Glossar, Translation Memory, und Integration von MT — bauen Sie diese aber erst, nachdem Sie Ihren Kern-Workflow mit echtem Content validiert haben.
Eine Übersetzungs-App lebt oder stirbt am Datenmodell. Wenn Entitäten und Felder klar sind, wird alles andere — UI, Workflow, Integrationen — einfacher.
Die meisten Teams decken 80 % ihres Bedarfs mit wenigen Tabellen/Collections:
en, en-GB, pt-BR).checkout.pay_button).Modellieren Sie die Beziehungen explizit: ein Project hat viele Locales; ein Key gehört zu einem Project; eine Translation gehört zu einem Key und einem Locale.
Fügen Sie jedem Translation-Eintrag einen Status hinzu, damit das System Menschen führen kann:
draft → in_review → approvedblocked für Strings, die noch nicht ausgeliefert werden dürfen (rechtliche Prüfung, fehlender Kontext etc.)Bewahren Sie Statusänderungen als Events (oder in einer History-Tabelle) auf, damit Sie später beantworten können: „Wer hat das wann freigegeben?"
Übersetzungen brauchen mehr als reinen Text. Erfassen Sie:
{name}, %d) und ob diese mit der Quelle übereinstimmen müssenMindestens sollten Sie persistieren: created_by, updated_by, Zeitstempel und einen kurzen change_reason. Das beschleunigt Reviews und schafft Vertrauen, wenn Teams vergleichen, was in der App vs. im Produktions-Build ist.
Ihre Speicherentscheidungen prägen alles: Editier-UX, Import/Export-Geschwindigkeit, Diffing und wie sicher Sie ausliefern können.
Zeile-pro-Key (eine DB-Zeile pro String-Key pro Locale) ist ideal für Dashboards und Workflows. Sie können leicht filtern: „fehlendes Französisch“ oder „braucht Review“. Nachteil: Locale-Dateien für den Export müssen gruppiert und geordnet werden; Sie brauchen zusätzliche Felder für Dateipfade und Namespaces.
Dokument-pro-Datei (jede Locale-Datei als JSON/YAML-Dokument speichern) bildet die Repo-Struktur gut ab. Export ist schneller und Formatierung bleibt erhalten. Suche und Filter werden jedoch schwieriger, sofern Sie nicht zusätzlich einen Index von Keys, Status und Metadaten pflegen.
Viele Teams nutzen einen Hybrid-Ansatz: Row-per-key als Quelle der Wahrheit plus generierte Datei-Snapshots für Exporte.
Behalten Sie Revisions-Historie auf Translation-Ebene (Key + Locale). Jede Änderung sollte festhalten: vorheriger Wert, neuer Wert, Autor, Zeitstempel und Kommentar. Das macht Review und Rollback einfach.
Separat verfolgen Sie Release-Snapshots: „Was genau wurde in v1.8 ausgeliefert?“ Ein Snapshot kann ein Tag sein, das auf einen konsistenten Satz genehmigter Revisionen über Locales hinweg zeigt. So verhindern Sie, dass späte Änderungen ein bereits ausgeliefertes Build still verändern.
Behandeln Sie „Plural“ nicht als bloßes Boolean. Verwenden Sie ICU MessageFormat oder CLDR-Kategorien (z. B. one, few, many, other), damit Sprachen wie Polnisch oder Arabisch nicht an englische Regeln angepasst werden müssen.
Für Gender und andere Variationen modellieren Sie diese als Varianten derselben Message/Keys statt als separate Ad-hoc-Keys, sodass Übersetzer den gesamten Kontext sehen.
Implementieren Sie Volltextsuche über Key, Source-Text, Translation und Entwickler-Notizen. Kombinieren Sie das mit Filtern, die echte Arbeit abbilden: Status (neu/übersetzt/geprüft), Tags, Datei/Namespace und fehlend/leer.
Indizieren Sie diese Felder früh — Suche ist das Feature, das Menschen hunderte Male am Tag nutzen.
Eine Lokalisierungsmanagement-Web-App startet oft simpel — Datei hochladen, Strings editieren, Datei herunterladen. Komplex wird es bei mehreren Produkten, vielen Locales, häufigen Releases und stetiger Automatisierung (Sync, QA, MT, Reviews).
Am einfachsten bleiben Sie flexibel, wenn Sie Verantwortlichkeiten früh trennen.
Eine gängige, skalierbare Struktur ist API + Web-UI + Background-Jobs + Datenbank:
Diese Trennung hilft, bei schweren Aufgaben einfach mehr Worker hinzuzufügen, ohne die gesamte App umzubauen.
Wenn Sie beim ersten lauffähigen Prototyp schneller vorankommen wollen, kann eine Rapid-Scaffolding-Plattform wie Koder.ai helfen, das Web-UI (React), die API (Go) und das PostgreSQL-Schema aus einem strukturierten Spec und ein paar Chat-Iterationen zu generieren — anschließend exportieren Sie den Quellcode, wenn Sie bereit sind, das Repo und Deployment zu übernehmen.
Konzentrieren Sie Ihre API auf wenige Kern-Ressourcen:
checkout.button.pay).Gestalten Sie Endpunkte so, dass sie sowohl manuellen Editierbedarf als auch Automatisierung unterstützen. Beispielsweise sollte das Auflisten von Keys Filter wie „fehlend in Locale“, „geändert seit“ oder „braucht Review“ akzeptieren.
Behandeln Sie Automatisierung als asynchrone Arbeit. Eine Queue kümmert sich typischerweise um:
Machen Sie Jobs idempotent (sicher wiederholbar) und protokollieren Sie Job-Logs pro Projekt, damit Teams Fehler selbst diagnostizieren können.
Auch kleine Teams können große Datensätze erzeugen. Fügen Sie Pagination für Listen (Keys, Historie, Jobs) hinzu, cachen Sie häufige Leseanfragen (Projekt-Locale-Statistiken) und setzen Sie Rate-Limits für Import/Export-Endpunkte und öffentliche Tokens.
Das sind langweilige Details, die verhindern, dass Ihr System verlangsamt, sobald die Nutzung steigt.
Wenn Ihre App Quelltexte und Übersetzungshistorie speichert, ist Zugriffskontrolle kein Nice-to-have — sie verhindert versehentliche Änderungen und macht Entscheidungen nachvollziehbar.
Ein einfacher Satz an Rollen deckt die meisten Teams ab:
Behandeln Sie jede Aktion als eigene Berechtigung, damit Sie später flexibel erweitern können. Übliche Regeln:
Wenn Ihre Firma bereits Google Workspace, Azure AD oder Okta nutzt, reduziert SSO Passwort-Risiken und macht Offboarding sofort wirksam. E-Mail/Passwort reicht für kleine Teams — verlangen Sie starke Passwörter und einen Reset-Flow.
Nutzen Sie sichere, kurzlebige Sessions (HTTP-only Cookies), CSRF-Schutz, Rate-Limits und 2FA, wo möglich.
Protokollieren Sie, wer was wann geändert hat: Edits, Freigaben, Locale-Änderungen, Exporte und Berechtigungs-Updates. Kombinieren Sie das mit „Undo“ über Versionshistorie, sodass Rollbacks sicher und schnell möglich sind (siehe /blog/plan-storage-and-versioning).
Ihre UI ist der Ort, an dem Lokalisierungsarbeit stattfindet — priorisieren Sie also Bildschirme, die Rückfragen reduzieren und Status auf einen Blick deutlich machen.
Starten Sie mit einem Dashboard, das drei Fragen schnell beantwortet: Was ist erledigt, was fehlt, und was ist blockiert.
Zeigen Sie Fortschritt pro Locale (Prozent übersetzt, Prozent geprüft) sowie eine klare Anzahl fehlender Strings. Fügen Sie ein Review-Queue-Widget hinzu, das auf Elemente hinweist, die auf Freigabe warten, und einen Feed „kürzlich geändert“, damit Reviewer riskante Edits erkennen.
Filter sind wichtiger als Charts: Locale, Produktbereich, Status, Zuständiger und „geändert seit letztem Release".
Ein guter Editor ist side-by-side: Quelle links, Ziel rechts, mit stets sichtbarem Kontext.
Kontext kann Key, Screenshot-Text (falls vorhanden), Zeichenlimits und Platzhalter (z. B. {name}, %d) umfassen. Integrieren Sie Historie und Kommentare in derselben Ansicht, damit Übersetzer keinen separaten „Diskussions“-Screen brauchen.
Machen Sie den Statuswechsel mit einem Klick möglich: Draft → In review → Approved.
Lokalisierungsarbeit besteht oft aus „vielen kleinen Änderungen“. Fügen Sie Bulk-Select mit Aktionen hinzu wie Zuweisen an Nutzer/Team, Status ändern und Export/Import für ein Locale oder Modul.
Geben Sie Bulk-Aktionen rollenbasiert frei (siehe /blog/roles-permissions-for-translators).
Power-Übersetzer verbringen Stunden im Editor. Unterstützen Sie vollständige Tastaturnavigation, sichtbare Focus-Zustände und Shortcuts wie:
Unterstützen Sie außerdem Screenreader und High-Contrast-Modus — Zugänglichkeit erhöht die Geschwindigkeit für alle.
Eine Lokalisierungsmanagement-App gewinnt oder verliert an ihrem Workflow. Wenn Menschen nicht wissen, was als Nächstes zu tun ist, wer eine Entscheidung getroffen hat oder warum ein String blockiert ist, entstehen Verzögerungen und Qualitätsprobleme.
Beginnen Sie mit einer klaren Arbeitseinheit: ein Satz Keys für ein Locale in einer bestimmten Version. Ermöglichen Sie PMs (oder Leads), Arbeit nach Locale, Datei/Modul und Priorität zuzuweisen, mit optionalem Fälligkeitsdatum.
Machen Sie Zuweisungen in einem „Meine Arbeit“-Postfach sichtbar, das beantwortet: was ist zugewiesen, was ist überfällig und was wartet auf andere. Für größere Teams fügen Sie Workload-Signale hinzu (Anzahl Items, Wortschätzung, letzte Aktivität), damit Zuweisungen fair sind.
Bauen Sie eine einfache Status-Pipeline, z. B.: Untranslated → In progress → Ready for review → Approved.
Review sollte mehr als ein binärer Check sein. Unterstützen Sie Inline-Kommentare, Vorschläge und Approve/Reject mit Begründung. Wenn Reviewer ablehnen, behalten Sie die Historie — überschreiben Sie nicht.
Das macht den Review-Prozess auditierbar und reduziert wiederkehrende Fehler.
Der Source-Text ändert sich. Wenn das passiert, markieren Sie bestehende Übersetzungen als Needs update und zeigen einen Diff- oder „Was hat sich geändert“-Zusammenfassung an. Bewahren Sie die ältere Übersetzung als Referenz auf, aber verhindern Sie eine erneute Freigabe ohne explizite Entscheidung.
Benachrichtigen Sie bei Ereignissen, die den Fortschritt blockieren: neue Zuweisung, Review-Anfrage, Ablehnung, bevorstehendes Fälligkeitsdatum und Source-Change, der genehmigte Strings betrifft.
Halten Sie Benachrichtigungen handlungsfähig mit Deep-Links wie /projects/{id}/locales/{locale}/tasks, sodass Nutzer Probleme mit einem Klick lösen können.
Manuelles Dateimanagement ist der Punkt, an dem Lokalisierungsprojekte aus dem Tritt geraten: Übersetzer arbeiten mit veralteten Strings, Entwickler vergessen Updates zu ziehen, und Releases werden mit halb fertigen Locales ausgeliefert.
Eine gute Lokalisierungsmanagement-App behandelt Import/Export als wiederholbare Pipeline, nicht als Einmal-Task.
Unterstützen Sie die Wege, die Teams tatsächlich nutzen:
Beim Export erlauben Sie Filter nach Project, Branch, Locale und Status (z. B. „nur approved“), damit teilweise geprüfte Strings nicht in Produktion gelangen.
Sync funktioniert nur, wenn Keys konsistent bleiben. Entscheiden Sie früh, wie Strings erzeugt werden:
checkout.button.pay_now) schützen Sie sie vor versehentlichem Umbenennen.Ihre App sollte erkennen, wenn sich ein Source-String geändert hat, der Key aber gleich blieb, und Übersetzungen als needs review markieren, statt sie zu überschreiben.
Fügen Sie Webhooks hinzu, damit Sync automatisch läuft:
main → importiere aktualisierte Source-Strings.Webhooks sollten idempotent sein (sicher wiederholbar) und klare Logs erzeugen: was geändert wurde, was übersprungen wurde und warum.
Wenn Sie das implementieren, dokumentieren Sie die einfachste End-to-End-Konfiguration (Repo-Zugriff + Webhook + PR-Export) und verlinken Sie sie von der UI, z. B. /docs/integrations.
Lokalisierungs-QA ist der Punkt, an dem eine Übersetzungs-App von einem simplen Editor zu einem System wird, das Produktionsfehler verhindert.
Das Ziel ist, Probleme vor dem Shipping zu erkennen — besonders solche, die nur in einer bestimmten Locale-Datei auftreten.
Starten Sie mit Prüfungen, die die UI zerstören oder Formatierungen crashen lassen können:
{count} in Englisch vorhanden, aber nicht in Französisch, oder inkonsistente Pluralformen).% in printf-Strings, fehlerhafte ICU-Messages).Behandeln Sie diese standardmäßig als „Release blockierend“, mit klarer Fehlermeldung und Zeiger auf exakten Key und Locale.
Diese brechen die App nicht, schaden aber Qualität und Marke:
Text kann korrekt sein und trotzdem falsch wirken. Bieten Sie die Möglichkeit, pro Key einen Screenshot-Kontext anzufordern oder einen Screenshot an einen Key anzuhängen, damit Reviewer Trunkierungen, Zeilenumbrüche und Ton im echten UI prüfen können.
Vor jedem Release erzeugen Sie eine QA-Zusammenfassung pro Locale: Errors, Warnings, nicht übersetzte Strings und Top-Offender.
Ermöglichen Sie einfachen Export oder Link-Teilen (z. B. /releases/123/qa), sodass das Team eine einzige Go/No-Go-Ansicht hat.
Glossar, Translation Memory (TM) und Machine Translation (MT) können die Lokalisierung stark beschleunigen — vorausgesetzt, Ihre App behandelt sie als Hilfsmittel und Automatisierung, nicht als „sofort produktionsreife" Ausgabe.
Ein Glossar ist eine kuratierte Liste von Begriffen mit genehmigten Übersetzungen pro Locale (Produktnamen, UI-Konzepte, rechtliche Phrasen).
Speichern Sie Einträge als Begriff + Locale + genehmigte Übersetzung + Notizen + Status.
Umsetzungsideen im Editor:
TM wiederverwendet zuvor genehmigte Übersetzungen. Halten Sie es einfach:
Behandeln Sie TM als Vorschlagsystem: Nutzer können Matches annehmen, bearbeiten oder ablehnen; nur angenommene Übersetzungen fließen zurück in das TM.
MT ist nützlich für Drafts und Backlogs, aber nicht als standardmäßiges finales Output.
Machen Sie MT opt-in pro Projekt und Job und leiten Sie MT-gefüllte Strings durch den normalen Review-Prozess.
Verschiedene Teams haben unterschiedliche Anforderungen. Erlauben Sie Admins, Anbieter auszuwählen (oder MT komplett zu deaktivieren), Nutzungslimits zu setzen und zu wählen, welche Daten gesendet werden (z. B. sensible Keys ausschließen).
Protokollieren Sie Anfragen für Kosten- und Audit-Zwecke und dokumentieren Sie Optionen in /settings/integrations.
Eine Lokalisierungs-App sollte nicht nur „Übersetzungen speichern“ — sie sollte helfen, sie sicher auszuliefern.
Die Kernidee ist ein Release: ein eingefrorenes Snapshot genehmigter Strings für einen bestimmten Build, sodass das, was deployed wird, vorhersehbar und reproduzierbar ist.
Behandeln Sie ein Release als unveränderliches Bundle:
So können Sie beantworten: „Was haben wir in v2.8.1 für fr-FR ausgeliefert?“ ohne zu raten.
Die meisten Teams möchten Übersetzungen prüfen, bevor Nutzer sie sehen. Modellieren Sie Exporte nach Environment:
Machen Sie den Export-Endpoint explizit (z. B. /api/exports/production?release=123), um das versehentliche Leaken unreviewter Texte zu vermeiden.
Rollback ist am einfachsten, wenn Releases unveränderlich sind. Wenn ein Release Probleme bringt (kaputte Platzhalter, falsche Terminologie), sollten Sie in der Lage sein:
Vermeiden Sie „in-place Produktion bearbeiten“ — das bricht Audit-Trails und erschwert Incident-Analysen.
Bemerkenswert: Dieses Snapshot+Rollback-Mindset passt gut zu modernen Build-Plattformen. Koder.ai z. B. bietet Snapshots und Rollback als First-Class-Workflow für generierte und gehostete Anwendungen — ein nützliches Denkmodell beim Entwerfen unveränderlicher Lokalisierungs-Releases.
Nach dem Deployment führen Sie eine kleine operative Checkliste aus:
Wenn Sie Release-Historie im UI zeigen, fügen Sie eine einfache „Diff vs. vorherigem Release“-Ansicht hinzu, damit Teams riskante Änderungen schnell erkennen.
Sicherheit und Sichtbarkeit sind der Unterschied zwischen einem nützlichen Lokalisierungs-Tool und einem, dem Teams vertrauen. Sobald Ihr Workflow läuft, härten Sie ihn ab und beginnen mit Messungen.
Folgen Sie dem Prinzip der geringsten Privilegien: Übersetzer sollten keine Projekteinstellungen ändern können, Reviewer keinen Zugriff auf Billing oder Admin-exklusive Exporte haben. Machen Sie Rollen explizit und auditierbar.
Speichern Sie Secrets sicher. Bewahren Sie Datenbankzugänge, Webhook-Signing-Keys und Drittanbieter-Tokens in einem Secrets-Manager oder verschlüsselten Umgebungsvariablen auf — nie im Repo. Rotieren Sie Keys regelmäßig und beim Offboarding.
Backups sind Pflicht. Erstellen Sie automatisierte Backups der Datenbank und des Objekt-Speichers (Locale-Dateien, Anhänge), testen Sie Restores und definieren Sie Retention. Ein „Backup, das sich nicht wiederherstellen lässt“ ist nur zusätzlicher Speicher.
Wenn Strings Nutzerdaten enthalten könnten (Support-Tickets, Namen, Adressen), vermeiden Sie deren Speicherung im Übersetzungssystem. Verwenden Sie Platzhalter oder Referenzen und entfernen Sie sensible Werte aus Logs.
Müssen Sie solche Texte verarbeiten, legen Sie Aufbewahrungsregeln und Zugriffsbeschränkungen fest.
Messen Sie einige Metriken, die den Gesundheitszustand des Workflows widerspiegeln:
Ein einfaches Dashboard plus CSV-Export reicht am Anfang.
Wenn die Basis steht, denken Sie über:
Wenn Sie das als Produkt anbieten wollen, fügen Sie einen klaren Upgrade-Pfad und Call-to-Action hinzu (siehe /pricing).
Falls Ihr unmittelbares Ziel ist, den Workflow schnell mit echten Nutzern zu validieren, können Sie das MVP auch auf Koder.ai prototypen: beschreiben Sie Rollen, Status-Flow und Import/Export-Formate im Planning-Modus, iterieren Sie UI (React) und API (Go) via Chat und exportieren Sie dann den Code, wenn Sie bereit sind, ihn für die Produktion zu härten.
Eine Web-App zur Verwaltung von Lokalisierung zentralisiert Ihre Strings und steuert den Workflow darum herum — Übersetzung, Review, Freigaben und Export — sodass Teams Updates ausliefern können, ohne dass Schlüssel fehlen, Platzhalter kaputtgehen oder der Status unklar ist.
Beginnen Sie mit der Festlegung von:
pt-BR → pt → en)Ein enger Scope verhindert „ein Workflow passt für alles“-Fehler und hält das MVP brauchbar.
Die meisten Teams decken den Kern-Workflow mit:
Speichern Sie Metadaten, die Produktionsfehler und Review-Aufwand verhindern:
Das hängt davon ab, worauf Sie optimieren:
Eine übliche Lösung ist hybrid: Row-per-key als Quelle der Wahrheit plus generierte Datei-Snapshots für Exporte.
Nutzen Sie zwei Ebenen:
So verhindern Sie, dass „stille Änderungen“ bereits Ausgeliefertes verändern, und machen Vorfälle einfacher untersuchbar.
Starten Sie mit Rollen, die reale Arbeit abbilden:
Konzentrieren Sie die API auf wenige Ressourcen:
Projects, Locales, Keys, TranslationsMachen Sie List-Endpunkte filterbar für reale Aufgaben, z. B.:
Führen Sie lange Arbeiten asynchron aus:
Machen Sie Jobs idempotent (sicheres Wiederholen) und speichern Sie Logs pro Projekt, damit Teams Fehler selbst diagnostizieren können ohne Server-Logs zu durchsuchen.
Priorisieren Sie Prüfungen, die eine kaputte UI verhindern:
{count}, %d) und Plural-AbdeckungBehandeln Sie diese standardmäßig als release-blocking und fügen Sie weichere Warnungen für Glossar-Konsistenz und Whitespace/Casing hinzu, damit Teams die Qualität verbessern können ohne alles zu blockieren.
draft → in_review → approved)Sind diese Entitäten klar, werden UI, Berechtigungen und Integrationen viel einfacher zu bauen und zu warten.
created_by, updated_by, Zeitstempel, Änderungsgrund)Das ist der Unterschied zwischen „einem Texteditor“ und einem System, dem Teams vertrauen können.
Definieren Sie Berechtigungen pro Aktion (Source bearbeiten, freigeben, exportieren, Locales verwalten), damit sich das System später weiterentwickeln lässt ohne Workflows zu brechen.
So unterstützen Sie sowohl manuelle Bearbeitung im UI als auch Automatisierung per CLI/CI.