{"id":16964,"date":"2026-06-25T09:49:46","date_gmt":"2026-06-25T07:49:46","guid":{"rendered":"https:\/\/modilingua.com\/?p=16964"},"modified":"2026-06-25T09:49:46","modified_gmt":"2026-06-25T07:49:46","slug":"software-internationalization","status":"publish","type":"post","link":"https:\/\/modilingua.com\/de\/l10n-und-t9n\/anwendungen\/software-internationalisierung\/","title":{"rendered":"Software-Internationalisierung kommt vor der Lokalisierung"},"content":{"rendered":"

Die erste Produktversion hat eine dringlichere Aufgabe: beweisen, dass das Produkt funktioniert, Nutzer gewinnen und eine Grundlage schaffen, auf der sich etwas verkaufen, vorf\u00fchren oder Kapital einwerben l\u00e4sst. Das ist eine vern\u00fcnftige Priorit\u00e4t. Niemand m\u00f6chte sechs Monate damit verbringen, ein Produkt f\u00fcr M\u00e4rkte vorzubereiten, die vielleicht nie erschlossen werden.<\/p>\n\n\n\n

Das Problem entsteht, wenn aus dem ersten Prototypen still und leise das eigentliche Produkt wird.<\/p>\n\n\n\n

Ein Kunde fragt, ob die Software auf Franz\u00f6sisch verf\u00fcgbar ist. Ein Partner m\u00f6chte eine spanische Version f\u00fcr einen Wiederverk\u00e4uferkanal. Ein potenzieller Investor fragt nach der globalen Expansion. Jemand schl\u00e4gt vor, \u201eeinfach mal die Benutzeroberfl\u00e4che zu \u00fcbersetzen\", und pl\u00f6tzlich offenbart das Produkt technische Vorannahmen, die auf Deutsch nie sichtbar waren.<\/p>\n\n\n\n

Der Text ist fest im Quellcode verankert. Die Benutzeroberfl\u00e4che funktioniert nur mit deutschen Akronymen. Datumsformate folgen einem einzigen Gebietsschema. Der Kalender ist auf einen einzigen Markt ausgelegt. Das \u00dcbersetzungsmanagementsystem kann die H\u00e4lfte der Strings nicht verarbeiten.<\/p>\n\n\n\n

Genau hier kommt die Software-Internationalisierung ins Spiel.<\/p>\n\n\n\n

Oft als i18n abgek\u00fcrzt, bezeichnet sie die Arbeit, die Software lokalisierungsbereit macht. Das bedeutet nicht, das Produkt vom ersten Tag an in jede Sprache zu \u00fcbersetzen. Aber es bedeutet, ein Produkt so aufzubauen, dass \u00dcbersetzung, Lokalisierung und Marktanpassung sp\u00e4ter keine aufwendige technische Nacharbeit erfordern.<\/p>\n\n\n\n

Internationalisierung und Lokalisierung: zwei grundverschiedene Aufgaben<\/span><\/h2>\n\n\n\n

\u00dcbersetzung, Lokalisierung, Internationalisierung und Globalisierung sind vier verschiedene Dinge. In Produktgespr\u00e4chen werden sie jedoch alle in dieselbe Schublade gesteckt: \u201eWir gehen international.\"<\/p>\n\n\n\n

Das f\u00fchrt zu Verwirrung.<\/p>\n\n\n\n

\u00dcbersetzung \u00fcbertr\u00e4gt W\u00f6rter. Lokalisierung passt sie an einen bestimmten Markt, eine Sprache und eine Zielgruppe an. Internationalisierung bereitet das Produkt so vor, dass Lokalisierung m\u00f6glich wird, ohne die halbe Anwendung umzuschreiben. Und Globalisierung ist die \u00fcbergeordnete Gesch\u00e4ftsentscheidung, Kunden in mehreren M\u00e4rkten zu bedienen.<\/p>\n\n\n\n

Diese Unterschiede sind wichtig, weil eine \u00fcbersetzte Benutzeroberfl\u00e4che noch lange kein gutes Nutzererlebnis liefert.<\/p>\n\n\n\n

Das sieht man in vielen Software- und Webprojekten<\/a>: Die W\u00f6rter stehen zwar in einer anderen Sprache, aber das Produkt f\u00fchlt sich trotzdem fremd an. Satzfragmente passen nicht zusammen. Platzhalter ergeben keinen Sinn. Formatierungen wirken seltsam. Die Oberfl\u00e4che f\u00fchlt sich beengt an. Hilfetexte erscheinen in einer Sprache, Systemmeldungen in einer anderen.<\/p>\n\n\n\n

All das sind Internationalisierungsprobleme.<\/p>\n\n\n\n

Fest codierter Text r\u00e4cht sich sp\u00e4ter<\/span><\/h2>\n\n\n\n

Fest codierter Text ist in fr\u00fchen Prototypen gang und g\u00e4be. Nicht sch\u00f6n, aber verst\u00e4ndlich, vor allem wenn die Entwicklung schnell vorangeht.<\/p>\n\n\n\n

Steckt der sichtbare Text aber im Quellcode, h\u00e4ngt jede Sprach\u00e4nderung an den Entwicklern. \u00dcbersetzer k\u00f6nnen nicht sauber arbeiten, weil sie die Lokalisierungsentwickler st\u00e4ndig nach einzelnen Strings fragen m\u00fcssen. Produktmanager verlieren den \u00dcberblick dar\u00fcber, was bereits \u00fcbersetzt wurde. Der gesamte Lokalisierungsprozess stockt, bevor er richtig begonnen hat.<\/p>\n\n\n\n

\"was<\/figure>\n\n\n\n

Der bessere Ansatz trennt \u00fcbersetzbaren Text vom Code. Strings liegen in Ressourcendateien oder einem Lokalisierungsmanagementsystem, aus dem sie exportiert, \u00fcbersetzt, gepr\u00fcft und aktualisiert werden k\u00f6nnen. Je nach Technologie-Stack kommen dabei Formate wie JSON, YAML, PO, XLIFF oder andere zum Einsatz.<\/p>\n\n\n\n

Das genaue Dateiformat ist weniger entscheidend als das Prinzip dahinter: Text, den Nutzer sehen, muss f\u00fcr alle zug\u00e4nglich sein, die ihn \u00fcbersetzen und pr\u00fcfen m\u00fcssen.<\/p>\n\n\n\n

Das ist eine der einfachsten i18n-Entscheidungen, die man fr\u00fch treffen kann. Und eine der m\u00fchsamsten, wenn man sie sp\u00e4ter nachholen muss.<\/p>\n\n\n\n

Platzhalter und Satzfragmente ruinieren \u00dcbersetzungen<\/span><\/h2>\n\n\n\n

Platzhalter wirken harmlos, bis sie auf eine andere Sprache treffen.<\/p>\n\n\n\n

Ein String wie \u201eHallo, {name}\" ist noch einfach. \u201eIhr {plan} verl\u00e4ngert sich am {date}\" erfordert schon mehr Sorgfalt. Ein String, der aus Fragmenten zusammengesetzt wird, also \u201eIhr\" + Planname + \u201everl\u00e4ngert sich am\" + Datum, kann schnell zum Problem werden.<\/p>\n\n\n\n

Englisch verzeiht schludrigen Umgang mit Strings. Andere Sprachen nicht.<\/p>\n\n\n\n

Wortstellung \u00e4ndert sich. Grammatik \u00e4ndert sich. Pluralformen \u00e4ndern sich. \u00dcbersetzer m\u00fcssen Platzhalter manchmal an eine andere Stelle setzen. Manche Sprachen verlangen unterschiedliche Formen je nach Zahl, Genus, Kasus oder Kontext. <\/p>\n\n\n\n

Stringverkettung ist eine der h\u00e4ufigsten Lokalisierungsfallen. Der Quellcode sieht damit ordentlich aus, das \u00fcbersetzte Produkt wirkt amateurhaft.<\/p>\n\n\n\n

Die praktische Regel ist einfach: Nutzerseitige Meldungen geh\u00f6ren als vollst\u00e4ndige, \u00fcbersetzbare Einheiten zusammen. Platzhalter sind in Ordnung, aber \u00dcbersetzer brauchen genug Kontext, um zu verstehen, wof\u00fcr jeder Platzhalter steht.<\/p>\n\n\n\n

UX und das Produkterlebnis<\/span><\/h2>\n\n\n\n

Formate wirken wie Kleinkram, bis sie im falschen Markt auftauchen.<\/p>\n\n\n\n

Datum und Uhrzeit, Zahlen, W\u00e4hrungen, Kalender, Adressen und Telefonnummern entscheiden dar\u00fcber, ob Software vertrauensw\u00fcrdig wirkt<\/a>. Kein Nutzer sollte r\u00e4tseln m\u00fcssen, ob 03\/04 der 3. April oder der 4. M\u00e4rz ist. Eine Abrechnungsseite sollte nicht aussehen, als w\u00e4re sie f\u00fcr ein Land gebaut und f\u00fcr alle anderen nur oberfl\u00e4chlich angepasst worden.<\/p>\n\n\n\n

Ich habe \u00fcber gebietsschemagerechte Formatierung<\/a> in anderen Beitr\u00e4gen geschrieben, und sie ist ein zentraler Bestandteil der Software-Internationalisierung. Apps m\u00fcssen quasi wissen, welche Konventionen zu welchem Markt geh\u00f6ren.<\/a> Dasselbe Produkt braucht wahrscheinlich unterschiedliche Anzeigelogik f\u00fcr Englisch und Japanisch, Deutsch und amerikanisches Englisch oder Arabisch und Franz\u00f6sisch.<\/p>\n\n\n\n

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<\/a>, in den Kontoeinstellungen, auf Rechnungen, in Benachrichtigungen und Dashboards.<\/p>\n\n\n\n

L\u00e4ngere W\u00f6rter, andere Schriftsysteme: die Benutzeroberfl\u00e4che muss mithalten<\/span><\/h2>\n\n\n\n
\"internationalisierung<\/figure>\n\n\n\n

Kurz gesagt: Schwache Internationalisierung zeigt sich zuerst in der Benutzeroberfl\u00e4che.<\/p>\n\n\n\n

Englische Bezeichnungen sind meist kurz. Deutsch ist bekanntlich l\u00e4nger. Auch Franz\u00f6sisch braucht oft mehr Platz. Japanisch kommt mit weniger Zeichen aus, erwartet aber tlw. ganz andere Layoutmuster. Unicode ist sowieso Pflicht. Urdu, Farsi, Hebr\u00e4isch und Arabisch erfordern Rechts-nach-links-Unterst\u00fctzung. Gemischte Leserichtungen k\u00f6nnen zu Darstellungsproblemen f\u00fchren, besonders wenn Zahlen, Markennamen oder Code-Schnipsel im selben Satz auftauchen.<\/p>\n\n\n\n

Ein fr\u00fches Produkt muss nicht vom ersten Tag an jedes Schriftsystem unterst\u00fctzen. Aber es sollte keine UI-Entscheidungen treffen, die sp\u00e4tere Lokalisierung unn\u00f6tig erschweren.<\/p>\n\n\n\n

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\u00fcr einen globalen Markt schlicht nicht geeignet.<\/p>\n\n\n\n

Internationalisierung geh\u00f6rt in die Produktplanung<\/span><\/h2>\n\n\n\n

Damit wird deutlich: Software-Internationalisierung als rein technisches Thema zu behandeln, greift zu kurz.<\/p>\n\n\n\n

Sie beeinflusst Produktentscheidungen, Designentscheidungen und den Entwicklungsprozess an sich:<\/p>\n\n\n\n