i18n für Startups: Wann man internationalisieren sollte (und wie man das Neuschreiben vermeidet)

Es gibt ein Gespräch, das in fast jedem Startup rund um Series A stattfindet. Jemand schaut sich die Analysen an und bemerkt, dass 30% der Anmeldungen aus nicht-englischsprachigen Ländern kommen. Das Produkt ist nur auf Englisch. Die Abwanderung aus diesen Kohorten ist brutal. Der Engineering-Lead sagt: „Wir müssen internationalisieren."

Dann kommt die Schätzung zurück: mindestens sechs Monate.

Diese Schätzung ist fast immer zutreffend und fast immer vermeidbar.

Die tatsächlichen Kosten der nachträglichen i18n-Integration

Laut CSA Research kaufen 87% der Verbraucher nicht von einem englischsprachigen Produkt, wenn Alternativen in ihrer Sprache existieren. Der Lokalisierungsmarkt erreichte 2023 6,27 Milliarden Dollar und wächst weiter. Das sind keine Nischenzahlen — sie stellen eine Deckelung Ihres adressierbaren Markts dar, die Sie still und leise in Ihrer Codebasis installiert haben.

Der Grund, warum die nachträgliche Integration teuer ist, liegt nicht daran, dass Internationalisierung technisch schwierig wäre. Es liegt daran, wie Anwendungen ohne i18n im Blick gebaut werden:

• String-Literale über 200 Komponenten verteilt
• Datums- und Zahlenformatierung fest auf US-Konventionen kodiert
• Datenbankspalten für englischen Text dimensioniert
• Rechts-nach-links-Layout nie bedacht
• Inhalte um englische Grammatikannahmen herum strukturiert
• Zeitzonenbehandlung an eine einzelne Region gebunden

Jedes davon ist billig, es von Anfang an richtig zu machen. Jedes davon ist schmerzhaft, es in Monat 18 zu entwirren, wenn die Codebasis 40.000 Zeilen hat und vier Ingenieure, die jeweils auf den ursprünglichen Annahmen aufgebaut haben.

Die Sechs-Monats-Schätzung gilt nicht für das Hinzufügen von Übersetzungen. Sie gilt für die Prüfung und das Neuschreiben der Teile Ihrer Anwendung, die ohne i18n im Blick gebaut wurden. Die Übersetzung macht 20% der Arbeit aus. Die anderen 80% sind Archäologie.

Wann sollten Sie tatsächlich internationalisieren?

Diese Frage hat zwei Teile: wann Sie Ihre Architektur i18n-bereit machen und wann Sie tatsächlich mehrere Sprachen ausliefern.

Architektur: Immer am ersten Tag.

Die Kosten für den Aufbau von Anfang an mit i18n-Bereitschaft betragen etwa zwei Stunden Einrichtungsaufwand. Sie übersetzen nichts. Sie stellen keine Übersetzer ein. Sie treffen einfach Entscheidungen, die keine Türen verschließen.

• Lagern Sie Ihre Strings in Ressourcendateien aus, anstatt sie fest zu kodieren
• Verwenden Sie eine gebietsschemabewusste Datums-/Uhrzeitbibliothek (Luxon, date-fns mit Gebietsschema-Unterstützung, Temporal)
• Wählen Sie einen Zahlenformatierungsansatz, der Intl.NumberFormat umhüllt
• Lassen Sie in Ihrer Benutzeroberfläche Raum für Texterweiterung (Deutsch kann 30% länger als Englisch sein)
• Speichern Sie das Gebietsschema von Anfang an als Benutzerpräferenz

Das ist keine voreilige Optimierung. Es ist kein Gold-Plating. Es ist derselbe Grund, warum Sie Umgebungsvariablen für Konfigurationswerte verwenden, die Sie möglicherweise ändern möchten — Sie antizipieren keinen spezifischen Bedarf, Sie vermeiden eine spezifische Falle.

Übersetzungen ausliefern: Nachdem Sie ein Signal haben.

Sie müssen nicht am ersten Tag Französisch ausliefern. Sie müssen bereit sein dazu. Die Entscheidung, tatsächlich in eine zweite Sprache zu investieren, sollte datengetrieben sein:

• Sie sehen organische Anmeldungen aus einem Zielmarkt
• Ein Verkaufsgespräch erfordert es zum Abschluss eines Deals
• Sie betreten einen Markt, in dem die Englisch-Durchdringung gering ist
• Eine Kundenkohorte mit einer bestimmten Sprache wandert zu einem höheren Satz ab

Wenn dieses Signal erscheint, bedeutet „i18n-bereit", dass Sie eine zweite Sprache in einer Woche ausliefern können, nicht in sechs Monaten.

Die 3-Monats-Zeitplan-Falle

So werden Teams erwischt: Sie wissen, dass sie i18n brauchen, sie wollen es nicht falsch machen, also planen sie ein „richtiges i18n-Projekt". Sie schätzen es auf drei Monate. Diese Schätzung umfasst:

• Prüfung vorhandener Strings
• Aufbau einer Übersetzungspipeline
• Integration eines Translation-Management-Systems
• Koordination mit einem Übersetzungsanbieter
• QA über alle Gebietsschemata

Während das Projekt in der Planung ist, bewegt sich die Roadmap weiter. Das Drei-Monats-Projekt wird immer wieder zurückgestellt, weil es keine Features liefert. Bis es schließlich priorisiert wird, ist es ein Fünf-Monats-Projekt, weil die Codebasis gewachsen ist.

Die Falle ist, i18n als eine große-Bang-Migration zu behandeln. Die Alternative ist, es als ein Fundament zu behandeln, das Sie schrittweise legen, beginnend mit der Architektur.

Das minimale funktionsfähige i18n-Setup

So sieht „i18n-bereit" in der Praxis für eine React- oder Next.js-App in der Seed-Phase aus. Es kostet zwei Stunden zur Einrichtung und hat null laufenden Overhead, bis Sie bereit sind zu übersetzen.

Schritt 1: Wählen Sie einen String-Auslagerungsansatz.

Kodieren Sie Anzeigestrings nicht fest. Legen Sie sie mindestens in JSON-Dateien. Besser: Verwenden Sie von Anfang an eine typisierte Lösung.

// Schlecht — fest kodierter String
<button>Get started for free</button>

// Besser — ausgelagert, auch wenn es vorerst nur Englisch ist
// messages/en.json
{
  "cta.getStarted": "Get started for free"
}

// Komponente
const t = useTranslations();
<button>{t('cta.getStarted')}</button>

Sie brauchen noch keine Übersetzungsplattform. Eine JSON-Datei pro Gebietsschema, auch wenn es nur Englisch ist, reicht aus. Die Gewohnheit, t() anstelle von Inline-Strings zu verwenden, ist das Entscheidende.

Schritt 2: Gebietsschemabewusste Formatierung von Tag eins.

// Schlecht — fest kodierte US-Formatierung
const formatted = `$${price.toFixed(2)}`;
const date = new Date(ts).toLocaleDateString('en-US');

// Gut — gebietsschemabewusst
const formatted = new Intl.NumberFormat(locale, {
  style: 'currency',
  currency: 'USD'
}).format(price);

const date = new Intl.DateTimeFormat(locale, {
  dateStyle: 'medium'
}).format(new Date(ts));

Wenn Sie später ein zweites Gebietsschema hinzufügen, funktioniert die Formatierung einfach. Kein Suchen-und-Ersetzen über 80 Dateien.

Schritt 3: Gestalten Sie mit Texterweiterung im Blick.

Lassen Sie Raum in Ihrer Benutzeroberfläche. Verwenden Sie CSS, das elegant abbaut, wenn Text lang wird. Vermeiden Sie pixelfixierte Breiten bei Textcontainern. Das kostet im Design nichts, spart aber echtes Geld bei der QA, wenn Sie Deutsch ausliefern.

Schritt 4: Speichern Sie das Gebietsschema als erstklassiges Benutzerattribut.

Auch wenn Sie eine Sprache ausliefern, speichern Sie preferred_locale in Ihrem Benutzermodell. Wenn Sie eine zweite Sprache hinzufügen, haben Ihre bestehenden Benutzer bereits eine gespeicherte Gebietsschemapräferenz. Sie migrieren kein Schema unter Live-Daten.

Häufige Startup-Fehler

„Wir fügen i18n hinzu, wenn wir es brauchen." Der Moment, in dem Sie es brauchen, ist der Moment, in dem Sie keine Zeit haben, es richtig zu machen. Das Signal, das die Entscheidung auslöst — ein großer Kunde, der Französisch benötigt, eine regionale Go-to-Market-Initiative — kommt immer mit Dringlichkeit verbunden.

Aufbau einer maßgeschneiderten Übersetzungspipeline. Übersetzungsmanagement ist ein gelöstes Problem. Eine maßgeschneiderte Lösung kostet Wochen zu bauen und Monate zu warten. Verwenden Sie bereits vorhandene Tools.

Lokalisierung nur als Übersetzung behandeln. Sprache macht 20% der Lokalisierung aus. Währung, Datumsformate, Adressformate, rechtliche Anforderungen, RTL-Unterstützung, gebietsschemaspezifische UX-Konventionen — das sind die anderen 80%. Ein übersetzter String in einem kaputten Layout ist immer noch eine kaputte Erfahrung.

Übersetzern direkten Zugriff auf JSON-Dateien geben. Menschliche Übersetzer sollten JSON niemals manuell bearbeiten. Die Fehlerrate ist hoch und der Feedback-Zyklus ist langsam. Sie brauchen eine Benutzeroberfläche, die für Übersetzungsarbeit gebaut ist, mit Kontext, Zeichenbegrenzungen und Terminologiekonsistenz-Durchsetzung.

Annehmen, dass englische Wortstellung verallgemeinert. Das Verketten übersetzter Strings mit JavaScript-String-Interpolation bricht in Sprachen mit unterschiedlichen Grammatikstrukturen. Verwenden Sie das ICU-Nachrichtenformat für alles mit Variablen.

// Schlecht — nimmt englische Wortstellung an
t('welcome') + ' ' + userName + '!'

// Gut — ICU-Format, Gebietsschema kann Token neu anordnen
t('welcome', { name: userName })
// en: "Welcome, {name}!"
// ja: "{name}さん、ようこそ！"

Ein Entscheidungsrahmen

Verwenden Sie dies, um zu entscheiden, wo Sie sich befinden und was zu tun ist:

Die wichtigste Erkenntnis: die Architekturentscheidung und die Übersetzungsentscheidung sind unabhängig. Treffen Sie die Architekturentscheidung jetzt. Treffen Sie die Übersetzungsentscheidung, wenn die Daten es Ihnen sagen.

Die praktische Checkliste

Bevor Sie eine weitere Komponente schreiben, gehen Sie diese durch:

• Strings sind ausgelagert (nicht fest in JSX/Templates kodiert)
• Datumsformatierung verwendet gebietsschemabewusste APIs
• Zahlen- und Währungsformatierung verwendet Intl.NumberFormat
• Benutzermodell hat ein locale-Feld
• UI-Layouts mit 30% längerem Text getestet
• Keine String-Verkettung mit übersetzbaren Teilen
• ICU-Nachrichtenformat für Strings mit Variablen verwendet
• Pluralisierung korrekt behandelt (nicht nur „s" anhängen)

Alles davon abzuhaken dauert zwei Stunden. Eines davon im großen Maßstab zu verpassen kostet Wochen.

Wie das in der Praxis aussieht

Wenn Sie bereit sind, tatsächlich mehrere Sprachen auszuliefern, ändert sich der Workflow von „archäologischer Ausgrabung" zu „Übersetzungsprojekt". Sie brauchen:

1. Eine Möglichkeit, Quellstrings an Übersetzer zu exportieren
2. Einen Review-Prozess für Übersetzungen
3. Eine Deployment-Pipeline, die Strings ohne Code-Deployment aktualisiert
4. Laufzeitlieferung des richtigen Gebietsschemas an jeden Benutzer

Bei Better i18n haben wir eine Plattform rund um dieses spezifische Problem gebaut — typsichere SDKs für React, Next.js, Vue und Svelte, Git-basierte Übersetzungsworkflows, damit Übersetzungen wie Code durch Review gehen, und CDN-Lieferung, damit Sie Übersetzungen ohne Redeployment aktualisieren können. Der kostenlose Tarif auf unserer Preisseite ist für frühe Teams konzipiert, die das Fundament ohne Budgetverpflichtung aufbauen möchten. Wenn Sie sehen möchten, wie die technischen Teile zusammenpassen, hat die Seite für Entwickler das vollständige Bild.

Das Sechs-Monats-Neuschreiben ist nicht unvermeidlich. Es ist das Ergebnis einer Zwei-Stunden-Entscheidung, die zu lange aufgeschoben wurde.