Ein praktischer Lokalisierungs‑Workflow: Übersetzungs‑Keys organisieren, klare Verantwortlichkeiten festlegen, Pluralformen handhaben und QA durchführen, damit Web‑ und native UIs nicht kaputtgehen.
Unkontrollierte Lokalisierung scheitert meist zuerst an kleinen, lästigen Stellen und später an teuren Problemen. Ein Label, das gestern noch passte, läuft heute über. Ein fehlender Key erscheint als roher Identifier. Ein Plural, der in Englisch halbwegs korrekt klang, wird in einer anderen Sprache falsch oder sogar unhöflich.
Die meisten Teams reparieren dieselben Probleme unter Zeitdruck:
Web‑ und native Bildschirme versagen oft auf unterschiedliche Weise. Im Web können flexible Layouts Probleme verbergen, bis eine spezifische Viewport/Browser‑Kombination sie zeigt. Text kann unerwartet umbrechen, Buttons nach unten drücken oder ein Grid sprengen. In nativen Apps sind Abstände strikter. Eine lange Übersetzung kann wichtige Elemente aus dem Bildschirm schieben, mit barrierefreien Schriftgrößen kollidieren oder abgeschnitten werden, weil eine Komponente sich nicht automatisch anpasst.
Ein solider Lokalisierungs‑Workflow verhindert die meisten dieser Fälle, indem Keys stabil gemacht, Übersetzungen überprüfbar und UI‑Checks routinemäßig durchgeführt werden. Er hilft dabei, Updates mit weniger Überraschungen auszuliefern. Was er nicht repariert, ist unklare Ausgangstext. Wenn der ursprüngliche Text vage ist (wie „Open“ oder „Apply“ ohne Kontext), bleibt die Übersetzung eine Vermutung.
Eine einfache Erfolgsmessung ist nicht „alles ist übersetzt.“ Sie lautet:
Beispiel: Wenn ein Warenkorbbildschirm "{count} item(s)" anzeigt, führen unkontrollierte Strings zu ungelenken Pluralformen und gebrochenen Abständen. Ein gemanagter Ansatz erzwingt korrekte Pluralregeln und entdeckt, dass ein Button in Deutsch um 30 % wächst, bevor der Release passiert.
Ein Lokalisierungs‑Workflow bricht am schnellsten zusammen, wenn niemand eine zentrale Frage beantworten kann: „Welcher Text ist der reale?“ Wähle eine einzige Single Source of Truth für Strings und mache sie langweilig eindeutig. Das kann eine Datei im Repo, eine Übersetzungsplattform oder eine interne Tabelle sein — Hauptsache ein Ort, der jede Diskussion entscheidet.
Definiere Rollen nach Entscheidungen, nicht nach Jobtiteln. Jemand muss Bedeutung und Ton genehmigen (oft Produkt oder Marketing). Jemand muss Keys stabil und im Code nutzbar halten (oft Engineering). Jemand muss UI‑Beschränkungen schützen (oft Design), besonders wenn Web und Native sich unterschiedlich verhalten.
Eine Aufteilung, die die meisten Konflikte vermeidet:
Setze Antwortzeiten fest, damit Releases nicht blockieren. Zum Beispiel: neue Key‑Anfragen innerhalb 1 Arbeitstag bestätigen, Freigabe des Ausgangstextes innerhalb 2 Tagen, und kritische Fixes (kaputte UI, falscher Rechtstext) innerhalb von Stunden.
Konkretes Beispiel: Euer Team baut einen neuen „Passwort zurücksetzen“-Flow für Web und Mobile. Der Developer fügt Keys hinzu, der PM genehmigt den finalen englischen Text und die Übersetzer füllen die anderen Sprachen. Wenn ein Übersetzer bemerkt, dass „Reset“ besser „Change“ sein sollte, passen sie die Übersetzung an, aber der Key bleibt gleich. Wenn der PM Text über mehrere Screens wiederverwenden will, macht nur der Key‑Owner diese strukturelle Änderung, damit nichts stillschweigend kaputtgeht.
Ein guter Lokalisierungs‑Workflow beginnt mit einer Regel: Keys sind Identifikatoren, keine englischen Sätze. Behandle sie wie Teilenummern. Wenn du später die Wortwahl änderst, sollte der Key normalerweise gleich bleiben.
Erzeuge einen neuen Key, wenn die Bedeutung anders ist. Wiederverwende einen Key, wenn die Bedeutung gleich ist, selbst wenn der Screen anders ist. „Speichern“ auf einem Profil‑Screen und „Speichern“ in den Einstellungen können einen Key teilen, wenn beide „Änderungen speichern“ bedeuten. Aber „Speichern“ im Sinne von „bookmarken“ braucht einen separaten Key, weil Übersetzer ein anderes Verb brauchen könnten.
Trenne kurze UI‑Labels von längeren Inhalten. Button‑Label, Hilfetext und Fehlermeldung übersetzen sich oft unterschiedlich und haben verschiedene Längenbeschränkungen. Sie als separate Keys zu halten, macht es einfacher, Ton und Zeichensetzung anzupassen, ohne andere Screens zu brechen.
Ziele Wiederverwendung über Web und Native an, aber zwinge sie nicht, wenn Plattformen unterschiedliche Sprache brauchen. Ein nativer Berechtigungsdialog braucht oft klareren, formelleren Text als ein Web‑Tooltip. In diesem Fall behalte dasselbe Konzept, aber nutze plattform‑spezifische Keys, damit jede UI natürlich liest.
Ein praktisches Muster ist, Keys nach Feature und UI‑Typ zu gruppieren und innerhalb dieser Grenzen wiederzuverwenden:
Zum Beispiel: Die Aktion „Kunden löschen“ kann in einem Web‑Adminpanel und einer nativen Feld‑App existieren. Du kannst das Kernaktionslabel wiederverwenden, aber einen separaten Key für die native Bestätigungstext haben, wenn dort stärkere Warnungen oder kürzere Zeilen nötig sind.
Ein gutes Namensschema macht Lokalisierung auf die beste Art langweilig. Leute finden Strings schnell, Übersetzer bekommen Kontext, und Keys bleiben stabil, auch wenn der Text sich ändert.
Verwende eine lesbare Konvention, die vier Fragen beantwortet: Wo ist es, was ist es, wofür ist es und ist es eine Variante. Ein einfaches Muster, das Web und native Screens abdeckt, ist:
<product_or_domain>.<screen_or_flow>.<component>.<purpose>[.<variant>]
Zum Beispiel in einem Kundenportal: portal.login.button.submit oder portal.orders.empty_state.title. So bleiben Keys nach Screen oder Flow gruppiert und sind gleichzeitig gut per Komponente durchsuchbar.
Schlechte Keys sind entweder zu vage oder zu sehr an den aktuellen englischen Text gebunden:
portal.profile.field.email.labelemailText (kein Scope, kein Zweck)please_enter_your_email (bricht, wenn sich der Text ändert)portal.checkout.error.payment_failederror_12Varianten sollten explizit sein, nicht mit Satzzeichen oder gemischter Groß-/Kleinschreibung „gehackt“. Wenn du ein kürzeres Label für eine enge mobile Kopfzeile brauchst, füge eine Variant‑Suffix hinzu: ...title.short vs. ...title.long. Wenn du Großschreibungs‑Unterschiede brauchst, verwende separate Keys wie ...button.save und ...button.save_titlecase nur dann, wenn die Plattform die Transformation nicht sicher durchführen kann.
Platzhalter brauchen auch Regeln, damit Übersetzer nicht raten.
{user_name}, {count}, {date}"Hello " + name{count} items statt {count} + " items"{count} null sein kann)Pluralisierung ist der Punkt, an dem Workflows meist zuerst reißen. Viele Teams nehmen an, jede Sprache habe nur „ein“ und „viele“ und merken dann, dass die UI falsch klingt oder letzte Minute korrigiert werden muss.
Sprachen können mehrere Plural‑Kategorien haben. Englisch nutzt meist one und other, aber Sprachen wie Russisch, Polnisch, Arabisch oder Tschechisch haben Formen wie few, many oder spezielle zero‑Fälle. Wenn du früh ein einzelnes Muster hartkodierst, endest du damit, Strings auf Web und Native später neu schreiben zu müssen.
Wähle einen Standard für Pluralstrings und halte ihn überall ein (Web, iOS, Android, serverseitig gerenderter Text). Ein praktischer Ansatz ist, einen einzigen Key mit Pluralformen zu speichern statt separate Keys pro Form. Basier die Formensets auf CLDR‑Kategorien, damit sie den realen Sprachregeln entsprechen.
Eine Regel, die Nacharbeit verhindert: baue niemals UI‑Sätze aus Teilen wie You have + count + messages. Wortstellung kann sich ändern, und manche Sprachen brauchen unterschiedliche Endungen oder Fälle basierend auf der Zahl.
Für einen Nachrichten‑Zähler definiere einen stabilen Key und übergebe die Zahl als Parameter. Dann biete Übersetzern die Formen an, die jede Sprache braucht.
inbox.message_count)zero, one, two, few, many, other){count}) im vollständigen SatzManchmal reichen Pluralregeln nicht aus. Wenn die UI eine Person anspricht ("Welcome, Alex") oder auf Rollen verweist ("assigned to him/her"), brauchen manche Sprachen unterschiedliche Wörter je nach Geschlecht. Andere Sprachen ändern Endungen abhängig vom grammatischen Fall (z. B. nach bestimmten Präpositionen).
Wenn das passiert, erstelle separate Strings für wirklich unterschiedliche Grammatik, nicht nur für Stil. Das Ziel ist weniger Keys, aber auch weniger Überraschungen in QA, wenn eine „korrekte“ Übersetzung im Kontext trotzdem falsch liest.
Eine Übersetzung kann korrekt sein und trotzdem die UI kaputtmachen. Web und native Apps rendern Text unterschiedlich, also sollte dein Workflow Formatierungsregeln und Layout‑Checks beinhalten, nicht nur übersetzte Strings.
Standardisiere, wie Zahlen, Geldbeträge und Daten angezeigt werden. Vermeide Konstruktionen wie "$" + amount oder festcodierte Datumsformate in einem Label. Nutze locale‑gerechte Formatierung, damit Trennzeichen und Reihenfolge passen (1,000.50 vs 1 000,50; Tag‑Monat‑Jahr vs Monat‑Tag‑Jahr). Zeitzonen sind eine häufige Falle: speichere Zeitstempel in UTC, formatiere in der lokalen Zone des Nutzers und markiere klar, wenn eine Zeit in einer bestimmten Zone angegeben ist (z. B. Abholzeit eines Shops).
Textflussrichtung ist ein weiterer stiller Brecher. Wenn du RTL‑Sprachen unterstützt, plane für gespiegelt Layouts und Satzzeichen, die „wandern“. Icons mit Richtungshinweis (Pfeile, Zurück‑Buttons, Fortschritts‑Schritte) müssen oft gespiegelt werden. Mach einen schnellen RTL‑Check Teil der Review, auch wenn du RTL nicht vollständig unterstützt.
Auf Mobilgeräten können Schriftarten und Abstände stärker variieren als im Web. Ein String, der im Web passt, kann in SwiftUI oder Kotlin unglücklich umbrechen. Entscheide dich für eine sichere Mindestschriftgröße, erlaub Labels umzubrechen, wo es sinnvoll ist, und definiere Fallback‑Fonts für Schriftsätze, die deine Standardfont nicht abdeckt.
Barrierefreiheit braucht ebenfalls lokalisierte Prüfungen. Screenreader lesen Zahlen, Abkürzungen und gemischte Sprache manchmal überraschend.
Layout‑Guardrails, die die meisten Probleme verhindern:
Beispiel: Ein Label „Total: $1,234.50“ muss vielleicht zu „1 234,50 €“ werden mit dem Symbol hinter dem Wert, anderem Abstand und einem screenreader‑freundlichen Pause zwischen „Gesamt“ und dem Betrag.
Ein Lokalisierungs‑Workflow muss früher starten, als die meisten Teams denken: während der Screen noch entworfen wird. Wartest du, bis die UI „fertig“ ist, hetzt du Übersetzungen, lieferst abgeschnittenen Text oder hartcodierte Strings „nur fürs Erste“ aus.
Füge beim Design jeden Label, Button und jede Meldung als Übersetzungs‑Key hinzu. Schreibe den Standardtext in deiner Basissprache und gib kurzen Kontext, wo er erscheint und was die Aktion bewirkt. Ein Key wie checkout.pay_button ist nur nützlich, wenn Übersetzer wissen, ob es ein Verb („Pay“) oder ein Label („Payment“) ist.
Implementiere die UI mit Platzhaltern und nutze die Basissprache als Fallback. Halte Variablen explizit (wie {name} oder {count}) und vermeide das Zusammensetzen von Sätzen — das bricht Grammatik über Sprachen hinweg am schnellsten.
Wenn du Strings zur Übersetzung sendest, gib Übersetzern das, was sie brauchen: Screenshot pro Screen (oder kurzes Video, wenn Text sich ändert), Zeichengrenzen für enge Stellen (Tabs, Buttons, Badges), Hinweise zu Ton und Terminologie sowie eine Liste dynamischer Platzhalter und deren Bedeutung.
Nachdem Übersetzungen zurückkommen, merge sie früh und baue sowohl Web als auch native Versionen. Mach schnelle UI‑Checks auf den risikoreichsten Screens: Login, Onboarding, Checkout und Einstellungen. Suche nach abgeschnittenem Text, überlappenden Elementen, fehlenden Keys und falschen Pluralformen.
Zuletzt: Ausliefern und beobachten. Tracke fehlende Keys, Fallback‑Events und Screens, bei denen Text häufig überläuft.
Genauere Übersetzungen beginnen, bevor ein einziges Wort übersetzt wurde. Wenn Übersetzer nur einen Key und einen englischen Satz sehen, raten sie. So entstehen die richtigen Worte am falschen Ort und eine UI, die merkwürdig oder unhöflich wirkt.
Ein einfaches „Context‑Paket“ nimmt den größten Teil der Raterei weg. Für jeden String gib an, wo er erscheint (Screen und Komponente), was der Nutzer erreichen will und welchen Ton der Text haben soll (freundlich, formell, dringlich). Markiere außerdem, ob es ein Button‑Label, eine Fehlermeldung, ein Menüpunkt oder Hilfetext ist — diese Kategorien übersetzen sich unterschiedlich.
Wenn der Platz knapp ist, sag das gleich. Web und native Screens brechen unterschiedlich, also definiere Limits, wenn sie wichtig sind: kurze Button‑Labels, Tab‑Titel, Toast‑Meldungen und alles in festen Karten. Wenn ein String in einer Zeile bleiben muss, vermerke das. Wenn Zeilenumbrüche erlaubt sind, gib an, wo sie sicher sind.
Markiere „nicht übersetzen“‑Teile deutlich. Produktnamen, Tarifnamen, Gutscheincodes, API‑Felder und Platzhalter wie {name} müssen unverändert bleiben. Ohne Anleitung lokalisiert ein Übersetzer diese Teile möglicherweise und die App ergibt keinen Sinn mehr.
Ein praktisches Paket pro String:
{amount})Behandle Rechtstext und Support‑Inhalte als separate Streams. Rechtstexte haben oft Genehmigungsanforderungen und langsamere Aktualisierungszyklen, also halte sie getrennt und versioniert. Support‑Artikel brauchen meist längere Übersetzung und können in einem anderen System oder Dateiset leben.
Beispiel: Ein „Continue“‑Button auf Mobile braucht möglicherweise eine strengere Begrenzung als im Web. Wenn Übersetzer das wissen, wählen sie in Sprachen mit Textvergrößerung ein kürzeres Verb statt eines späten UI‑Redesigns.
UI‑Brüche durch Lokalisierung sehen selten wie ein „Bug“ aus. Sie wirken wie ein fehlendes Label, ein Button, der in zwei Zeilen umbricht, oder ein Platzhalter, der den falschen Wert zeigt. Ein guter Workflow beinhaltet QA‑Schritte, die diese Probleme vor Nutzerkontakt sichtbar machen.
Beginne mit Pseudo‑Lokalisierung in Development‑Builds. Ersetze reale Strings durch längere, akzentuierte Versionen (wie "[!!! Šéttïñĝš !!!]") und blähe die Länge um 30–50 %. Das deckt schnell Trunkierungen, Überlappungen und hartkodierte Strings auf Web und nativ auf.
Füge automatisierte Checks in jeden Build ein. Sie fangen langweilige Fehler, die Menschen beim Durchsehen Hunderter Zeilen übersehen:
"Hello, {name}" vs "Hello, {username}")Dann nutze eine klare manuelle Abnahme‑Schleife. Produkt verifiziert Bedeutung und Ton für Schlüsselscreens, QA prüft Layout und Interaktion.
Halte die Testmatrix klein, aber strikt. Test nicht alles. Test das, was zuerst kaputtgeht: Login/Signup, Passwort‑Reset, Checkout/Bezahlbestätigung, Einstellungen und Profilbearbeitung sowie alle Screens mit Tabellen, Badges oder kleinen Buttons.
Wenn du Bugs meldest, mach es den Fixern leicht durch genaue Angaben: Locale, Gerät und OS‑Version (oder Browser und Breite), erwarteter Text, aktueller Text und ein Screenshot, der den abgeschnittenen Bereich zeigt. Bei Pluralisierung oder Platzhaltern füge den exakten Key und den gerenderten String bei.
Die meisten Lokalisierungsfehler sind keine „Übersetzungsprobleme“. Es sind Workflow‑Probleme, die sich als kaputte UI, fehlender Text oder verwirrende Meldungen zeigen.
Eine Falle ist, Keys umzubenennen, wenn man nur die Formulierung ändern will. Keys sollten stabile IDs sein, nicht der Text selbst. Änderst du checkout.button.pay zu checkout.button.pay_now, sind alle alten Übersetzungen plötzlich „fehlend“ und die Historie geht verloren. Behalte den Key, aktualisiere den Basissprache‑String und füge Kontext hinzu, wenn sich die Bedeutung änderte.
Ein weiterer häufiger Fehler ist, Strings auf einer Plattform hardcodiert zu lassen. Das Web‑Team nutzt Keys, aber das Mobile‑Team klebt schnell englischen Text für einen Fix rein. Einen Monat später sehen Nutzer englische Alerts auf iOS. Mach „keine hartkodierten, nutzerseitigen Strings“ zur gemeinsamen Regel für Web und Native.
Platzhalter verursachen subtile Fehler, wenn du die Wortreihenfolge annimmst. Auf Englisch funktioniert "{count} items", aber andere Sprachen brauchen möglicherweise andere Reihenfolgen oder zusätzliche Wörter. Verwende benannte Platzhalter (keine positionalen) und halte sie plattformübergreifend konsistent.
Fehler, die du früh abfangen solltest:
Nur mit einer langen Sprache zu testen reicht nicht. Deutsch dehnt oft die UI, während Chinesisch Platzprobleme offenbart. Mach einen schnellen Check in beiden und teste Plural‑Edgecases wie 0, 1 und 2.
Stimme das Fallback‑Verhalten vor Release ab. Zum Beispiel: wenn Französisch fehlt, auf Englisch zurückfallen, fehlende Keys loggen und das Release nur blockieren, wenn kritische Screens Lücken haben.
Ein Lokalisierungs‑Workflow bleibt gesund, wenn die Checks klein und wiederholbar sind. Das Ziel ist einfach: weniger überraschende Strings, weniger kaputte Layouts, weniger hektische Übersetzungshetze.
Bevor du eine UI‑Änderung mergest, mach einen schnellen Check auf die gängigen „Ups“:
Vor dem Release führe eine kurze Release‑QA durch, fokussiert auf die Stellen, an denen Lokalisierung zuerst bricht. Zeitbox das Ganze, aber sei konsistent: Top‑User‑Flows auf jeder Plattform, ein RTL‑Spotcheck, lange Text‑Screens (Einstellungen, Rechtliches, Onboarding, Tabellen, enge Buttons) und Datums/Zahlen/Währungsformatierung in ein paar Locales.
Setze eine Cadence passend zu deinem Team. Viele Teams aktualisieren Übersetzungen wöchentlich und frieren Strings 1–2 Tage vor einem Release ein. Der Punkt ist, Last‑Minute‑Copy‑Edits nicht mit finaler QA zu vermischen.
Nächste Schritte mit schneller Rendite: Schreibe deine Konventionen auf (Key‑Naming, Platzhalter, Pluralregeln, Ownership), dann führe einen Pilot‑Screen End‑to‑End durch und passe anhand der gefundenen Probleme an.
Wenn du über Backend, Web‑UI und native Mobile in einer Plattform wie AppMaster baust, ist es einfacher, Keys und Platzhalter konsistent zu halten, weil dieselben Screens und Logiken eine Konvention teilen können. Diese Konvention stabil zu halten ist das, was Lokalisierung routiniert statt fragil macht.
Was ist der einfachste Weg, damit Lokalisierung meine UI nicht kaputt macht?Beginne mit einem stabilen Ort, an dem alle Strings liegen, einer einheitlichen Konventionsregel für Key‑Namen und der Regel, dass Keys nicht allein wegen einer Wortänderung ersetzt werden. Ergänze das durch eine kleine QA‑Routine, die fehlende Keys, Überläufe und Pluralprobleme vor dem Release findet.
Was bedeutet „Single Source of Truth“ für Übersetzungen?Wähle ein System, das im Konfliktfall immer gilt — z. B. Repo‑Übersetzungsdateien oder eine Übersetzungsplattform. Mach deutlich, dass alle Inhalte über diese Quelle gepflegt werden und der Code sie nur konsumiert.
Wer sollte Keys, Wortwahl und Übersetzungen verantworten?Treffe Entscheidungen nach Verantwortung, nicht nach Jobtitel: Eine Person genehmigt Bedeutung und Ton in der Basissprache, jemand anderes verwaltet Key‑Struktur und Deprecations, und Übersetzer ändern nur Übersetzungswerte. So werden stille Key‑Umbenennungen und kurzfristige Textänderungen verhindert.
Wann sollte ich einen Übersetzungs‑Key wiederverwenden und wann neu anlegen?Erzeuge einen neuen Key, wenn sich die Bedeutung ändert, auch wenn das englische Wort ähnlich aussieht. Verwende denselben Key wieder, wenn die Bedeutung wirklich gleich ist — das sorgt für Konsistenz und weniger Pflegeaufwand.
Wie sollte ich Übersetzungs‑Keys benennen und organisieren, damit sie stabil bleiben?Nutze Keys als Identifikatoren, nicht als englische Sätze. Baue Scope ein (Feature, Screen/Flow, Komponente, Zweck). Ein Key wie portal.checkout.button.pay bleibt nützlich, auch wenn der Button‑Text später angepasst wird.
Wie handhabt man Pluralformen richtig über verschiedene Sprachen hinweg?Pluralisierung scheitert oft, weil viele Sprachen mehr als nur Singular und Plural haben. Speichere pro Konzept einen Key mit den notwendigen Plural‑Kategorien und belasse {count} innerhalb des vollständigen Satzes, damit Übersetzer die Wortstellung anpassen können.
Wie vermeide ich Platzhalter‑Bugs wie falsche Namen oder kaputte Grammatik?Vermeide Sätze wie "Hello " + name. Verwende stattdessen konsequent benannte Platzhalter wie {user_name} und dokumentiere, was jeder Platzhalter bedeutet. So vermeidest du falsche Wortreihenfolge oder grammatische Fehler.
Wie verhindere ich abgeschnittene Buttons und überlappenden Text auf Web und Mobile?Geh davon aus, dass Text 30–50 % länger wird, und designe Komponenten so, dass sie wachsen oder umbrechen können. Teste außerdem mindestens eine Sprache mit längeren Texten und die Barrierefreiheits‑Schriftgrößen auf Web und nativ, um Abschneidungen früh zu erkennen.
Welche QA‑Schritte fangen Lokalisierungsprobleme ab, bevor Nutzer sie sehen?Pseudo‑lokalisiere im Development, um hartkodierte Strings und Layout‑Fehler aufzudecken. Ergänze Build‑Checks für fehlende Keys, ungenutzte Keys, Platzhalter‑Mismatch und ungültige Pluralformen. Konzentriere manuelle Reviews auf Flows, die zuerst brechen (Login, Checkout etc.).
Was tun, wenn kurz vor dem Release ein Übersetzungs‑Key fehlt?Falle auf die Basissprache zurück, logge fehlende Keys und behebe Lücken schnell, damit Releases nicht grundsätzlich blockiert werden. Bei kritischen Bildschirmen oder rechtlich relevanten Texten ist es jedoch oft sicherer, das Release zu blockieren, bis Übersetzungen vorhanden sind.
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.
