Die erste Produktversion hat eine dringlichere Aufgabe: beweisen, dass das Produkt funktioniert, Nutzer gewinnen und eine Grundlage schaffen, auf der sich etwas verkaufen, vorführen oder Kapital einwerben lässt. Das ist eine vernünftige Priorität. Niemand möchte sechs Monate damit verbringen, ein Produkt für Märkte vorzubereiten, die vielleicht nie erschlossen werden.
Das Problem entsteht, wenn aus dem ersten Prototypen still und leise das eigentliche Produkt wird.
Ein Kunde fragt, ob die Software auf Französisch verfügbar ist. Ein Partner möchte eine spanische Version für einen Wiederverkäuferkanal. Ein potenzieller Investor fragt nach der globalen Expansion. Jemand schlägt vor, „einfach mal die Benutzeroberfläche zu übersetzen", und plötzlich offenbart das Produkt technische Vorannahmen, die auf Deutsch nie sichtbar waren.
Der Text ist fest im Quellcode verankert. Die Benutzeroberfläche funktioniert nur mit deutschen Akronymen. Datumsformate folgen einem einzigen Gebietsschema. Der Kalender ist auf einen einzigen Markt ausgelegt. Das Übersetzungsmanagementsystem kann die Hälfte der Strings nicht verarbeiten.
Genau hier kommt die Software-Internationalisierung ins Spiel.
Oft als i18n abgekürzt, bezeichnet sie die Arbeit, die Software lokalisierungsbereit macht. Das bedeutet nicht, das Produkt vom ersten Tag an in jede Sprache zu übersetzen. Aber es bedeutet, ein Produkt so aufzubauen, dass Übersetzung, Lokalisierung und Marktanpassung später keine aufwendige technische Nacharbeit erfordern.
Internationalisierung und Lokalisierung: zwei grundverschiedene Aufgaben
Übersetzung, Lokalisierung, Internationalisierung und Globalisierung sind vier verschiedene Dinge. In Produktgesprächen werden sie jedoch alle in dieselbe Schublade gesteckt: „Wir gehen international."
Das führt zu Verwirrung.
Übersetzung überträgt Wörter. Lokalisierung passt sie an einen bestimmten Markt, eine Sprache und eine Zielgruppe an. Internationalisierung bereitet das Produkt so vor, dass Lokalisierung möglich wird, ohne die halbe Anwendung umzuschreiben. Und Globalisierung ist die übergeordnete Geschäftsentscheidung, Kunden in mehreren Märkten zu bedienen.
Diese Unterschiede sind wichtig, weil eine übersetzte Benutzeroberfläche noch lange kein gutes Nutzererlebnis liefert.
Das sieht man in vielen Software- und Webprojekten: Die Wörter stehen zwar in einer anderen Sprache, aber das Produkt fühlt sich trotzdem fremd an. Satzfragmente passen nicht zusammen. Platzhalter ergeben keinen Sinn. Formatierungen wirken seltsam. Die Oberfläche fühlt sich beengt an. Hilfetexte erscheinen in einer Sprache, Systemmeldungen in einer anderen.
All das sind Internationalisierungsprobleme.
Fest codierter Text rächt sich später
Fest codierter Text ist in frühen Prototypen gang und gäbe. Nicht schön, aber verständlich, vor allem wenn die Entwicklung schnell vorangeht.
Steckt der sichtbare Text aber im Quellcode, hängt jede Sprachänderung an den Entwicklern. Übersetzer können nicht sauber arbeiten, weil sie die Lokalisierungsentwickler ständig nach einzelnen Strings fragen müssen. Produktmanager verlieren den Überblick darüber, was bereits übersetzt wurde. Der gesamte Lokalisierungsprozess stockt, bevor er richtig begonnen hat.
Der bessere Ansatz trennt übersetzbaren Text vom Code. Strings liegen in Ressourcendateien oder einem Lokalisierungsmanagementsystem, aus dem sie exportiert, übersetzt, geprüft und aktualisiert werden können. Je nach Technologie-Stack kommen dabei Formate wie JSON, YAML, PO, XLIFF oder andere zum Einsatz.
Das genaue Dateiformat ist weniger entscheidend als das Prinzip dahinter: Text, den Nutzer sehen, muss für alle zugänglich sein, die ihn übersetzen und prüfen müssen.
Das ist eine der einfachsten i18n-Entscheidungen, die man früh treffen kann. Und eine der mühsamsten, wenn man sie später nachholen muss.
Platzhalter und Satzfragmente ruinieren Übersetzungen
Platzhalter wirken harmlos, bis sie auf eine andere Sprache treffen.
Ein String wie „Hallo, {name}" ist noch einfach. „Ihr {plan} verlängert sich am {date}" erfordert schon mehr Sorgfalt. Ein String, der aus Fragmenten zusammengesetzt wird, also „Ihr" + Planname + „verlängert sich am" + Datum, kann schnell zum Problem werden.
Englisch verzeiht schludrigen Umgang mit Strings. Andere Sprachen nicht.
Wortstellung ändert sich. Grammatik ändert sich. Pluralformen ändern sich. Übersetzer müssen Platzhalter manchmal an eine andere Stelle setzen. Manche Sprachen verlangen unterschiedliche Formen je nach Zahl, Genus, Kasus oder Kontext.
Stringverkettung ist eine der häufigsten Lokalisierungsfallen. Der Quellcode sieht damit ordentlich aus, das übersetzte Produkt wirkt amateurhaft.
Die praktische Regel ist einfach: Nutzerseitige Meldungen gehören als vollständige, übersetzbare Einheiten zusammen. Platzhalter sind in Ordnung, aber Übersetzer brauchen genug Kontext, um zu verstehen, wofür jeder Platzhalter steht.
UX und das Produkterlebnis
Formate wirken wie Kleinkram, bis sie im falschen Markt auftauchen.
Datum und Uhrzeit, Zahlen, Währungen, Kalender, Adressen und Telefonnummern entscheiden darüber, ob Software vertrauenswürdig wirkt. Kein Nutzer sollte rätseln müssen, ob 03/04 der 3. April oder der 4. März ist. Eine Abrechnungsseite sollte nicht aussehen, als wäre sie für ein Land gebaut und für alle anderen nur oberflächlich angepasst worden.
Ich habe über gebietsschemagerechte Formatierung in anderen Beiträgen geschrieben, und sie ist ein zentraler Bestandteil der Software-Internationalisierung. Apps müssen quasi wissen, welche Konventionen zu welchem Markt gehören. Dasselbe Produkt braucht wahrscheinlich unterschiedliche Anzeigelogik für Englisch und Japanisch, Deutsch und amerikanisches Englisch oder Arabisch und Französisch.
Das ist keine Enterprise-Finesse, sondern grundlegende Produkthygiene, denn diese Details tauchen genau dort auf, wo Nutzer am wenigsten Nachsicht zeigen: beim Onboarding, an der Kasse, in den Kontoeinstellungen, auf Rechnungen, in Benachrichtigungen und Dashboards.
Längere Wörter, andere Schriftsysteme: die Benutzeroberfläche muss mithalten
Kurz gesagt: Schwache Internationalisierung zeigt sich zuerst in der Benutzeroberfläche.
Englische Bezeichnungen sind meist kurz. Deutsch ist bekanntlich länger. Auch Französisch braucht oft mehr Platz. Japanisch kommt mit weniger Zeichen aus, erwartet aber tlw. ganz andere Layoutmuster. Unicode ist sowieso Pflicht. Urdu, Farsi, Hebräisch und Arabisch erfordern Rechts-nach-links-Unterstützung. Gemischte Leserichtungen können zu Darstellungsproblemen führen, besonders wenn Zahlen, Markennamen oder Code-Schnipsel im selben Satz auftauchen.
Ein frühes Produkt muss nicht vom ersten Tag an jedes Schriftsystem unterstützen. Aber es sollte keine UI-Entscheidungen treffen, die spätere Lokalisierung unnötig erschweren.
Fest definierte Buttonbreiten, enge Navigation, kleine Karten, starre Tabellen und in Bilder eingebettete Beschriftungen bereiten ebenfalls Probleme. Ein Design, das nur auf einer Sprache funktioniert, ist für einen globalen Markt schlicht nicht geeignet.
Internationalisierung gehört in die Produktplanung
Damit wird deutlich: Software-Internationalisierung als rein technisches Thema zu behandeln, greift zu kurz.
Sie beeinflusst Produktentscheidungen, Designentscheidungen und den Entwicklungsprozess an sich:
- Gründer müssen die Abwägungen kennen.
- Produktmanager müssen erkennen, wann ein Feature Lokalisierungsschulden erzeugt.
- Designer müssen unterschiedliche Sprachen und kulturelle Erwartungen einplanen.
- Entwickler müssen fest codierten Text, fehlerhafte Kodierungsannahmen und fragile String-Logik vermeiden.
- Übersetzer brauchen Kontext.
- Lokalisierungsentwickler brauchen einen Workflow, der ohne Notfalllösungen auskommt.
Das alles erfordert kein aufwendiges Lokalisierungsprogramm. Kein junges Unternehmen braucht enterprise-typische Prozesse, bevor es einen funktionierenden Markt gefunden hat. Aber die Grundlagen sollten vorhanden sein, bevor internationales Wachstum zum Thema wird.
Maschinelle Übersetzung löst keine i18n-Schulden
Künstliche Intelligenz und maschinelle Übersetzung haben den Lokalisierungsprozess beschleunigt, den Bedarf an Internationalisierung haben sie aber nicht beseitigt.
Maschinelle Übersetzung kann einen String übersetzen, aber keinen defekten Platzhalter reparieren. Sie kann eine beengte Benutzeroberfläche nicht flexibler machen, fest codierten Text nicht aus dem Quellcode lösen, nicht entscheiden, ob ein Datumsformat für einen bestimmten Markt passt, und aus Satzfragmenten keinen sauberen Lokalisierungsworkflow machen.
Genau hier können sich kleine, eigenfinanzierte SaaS-Unternehmen und gründergeführte Teams verschätzen. Übersetzung wirkt wie der teure Teil, also scheint Automatisierung die naheliegendste Lösung. Bei Webanwendungen und Software liegen die eigentlichen Kosten aber oft woanders: in Engineering-Korrekturen, unübersichtlichen QA-Zyklen, kaputten Layouts, fehlenden Strings, fehlendem Kontext und Nachbesserungen auf der Design- und Entwicklungsseite.
Ein gutes Übersetzungsmanagementsystem hilft zweifellos. Maschinelle und professionelle Übersetzung auch. Aber keines dieser Werkzeuge ersetzt eine saubere Internationalisierung.
Wer früh internationalisiert, spart sich spätere Nachbesserungen
Internationale Expansion verläuft selten so geordnet, wie es Präsentationen gerne darstellen.
Ein Kunde taucht in einem Markt auf. Eine Verkaufschance in einem anderen. Ein Partner möchte das Produkt in zwei Sprachen. Ein Gründer braucht eine Demo für eine Region, die sechs Monate zuvor niemand auf dem Zettel hatte.
Eine Internationalisierungsstrategie als Ausgangspunkt schafft in all diesen Situationen mehr Handlungsspielraum. Jeder neue Markt erfordert weiterhin Produkturteil, sprachliche Qualität und lokales Wissen. Aber mit einer sauberen Internationalisierung lässt sich das Produkt anpassen, ohne dass jede neue Sprache zum Reengineering-Projekt wird.
Grundsätzlich ist das alles keine glamouröse Arbeit. Nutzer werden weder die Ressourcendateien loben noch bemerken, ob Platzhalter sinnvoll benannt oder Oberflächen für arabischen Text ausgelegt sind. Sie werden es jedoch bemerken, wenn etwas fehlt.
