Wir haben Japanisch und brasilianisches Portugiesisch für die gesamte Website hinzugefügt – für 31 €

Am 29. September haben wir globalize.now auf Japanisch und brasilianisches Portugiesisch ausgerollt. Jede Seite, jede Preistabelle und alle 61 Blogartikel. Die Übersetzung selbst dauerte acht Minuten, und die App hat rund 31 € abgerechnet. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, und so sah es aus, als wir sie auf unserer eigenen Site eingesetzt haben – mit jeder Zahl direkt von der Job-Seite und aus der Git-History, nicht aus dem Gedächtnis.

Unser Beitrag darüber, was das Localization-Growth-Playbook 2017 gekostet hat, endet mit der Aussage, dass wir unsere eigenen Zahlen noch nicht veröffentlichen. Das hier ist die erste. Es ist eine Kostenzahl, keine Wachstumszahl: Niemand hatte bisher Zeit, /ja/ zu besuchen.

Was genau haben wir übersetzt?

Die ganze Site, zweimal. Hier ist die Inventur, gezählt direkt aus dem Repository:

• Interface: 1.782 englische Strings über fünf Message-Kataloge hinweg (die Core-Site, Pricing, Vergleichsseiten, Integrationen und Übersetzungsbeispiele), etwa 21.000 Wörter.
• Blog: 61 Beiträge, etwa 110.000 Wörter.
• Zielsprachen: Japanisch (ja) und brasilianisches Portugiesisch (pt-BR).

Das sind rund 130.000 Quellwörter, die in zwei Sprachen fließen. Der Pull Request betraf 170 Dateien und fügte 34.681 Zeilen hinzu. Nach dem Merge listet die Sitemap 811 URLs über 11 Locales, und die Site baut 962 statische Seiten.

Wie lange hat es gedauert?

Acht Minuten Übersetzung, dann ein längerer Qualitätsdurchlauf. Arturs, unser CTO, hat die beiden Sprachen zum Projekt hinzugefügt, und der Job startete am main um 08:56 UTC. Die Job-Seite schlüsselt das so auf:

Der Commit mit beiden Sprachen landete um 09:29 UTC. Die übrigen 45.106 Strings im Job kamen aus der Translation Memory, da sich die acht bestehenden Sprachen nicht geändert hatten.

Arturs schätzte zehn Minuten, als er es in unserem Team-Chat erwähnte. Mit der Übersetzung lag er richtig, beim gesamten Job war er optimistisch – die Differenz macht der QA-Durchlauf aus. Wir verbringen lieber 27 Minuten Maschinenzeit mit Prüfen, als sie zu überspringen.

Was hat die automatisierte QA gefunden?

72 Anmerkungen bei 11.264 neuen Strings, alle als geringfügig eingestuft. 11.192 liefen ohne Beanstandung durch, und die QA hat dabei 182 automatische Korrekturen vorgenommen.

Die Anmerkungen, die wir gesichtet haben, waren größtenteils die Längenprüfung, die bei Japanisch vorsichtig reagiert. „Pricing“ wird zu 料金, zwei Zeichen, und ein Längenverhältnis von 0,29 liegt knapp unter der Schwelle von 0,3. Das ist eine korrekte Übersetzung, die eine für alphabetische Sprachen gebaute Heuristik auslöst, kein Fehler. Wir lassen die Anmerkungen trotzdem sichtbar: eine Prüfung, die nie anschlägt, ist keine Prüfung.

Was hat es gekostet?

Rund 31 €: Die Kosten-pro-Sprache-Ansicht des Projekts zeigt 15,72 € für Japanisch und 16,15 € für brasilianisches Portugiesisch. Das ist es, was die App berechnet – derselbe Betrag, den auch ein Kunde für dasselbe Volumen sehen würde. Das ist nicht unser interner Modell-Kostenwert und kein Rabatt.

Bei rund 260.000 übersetzten Wörtern sind das etwa 12 Cent pro 1.000. Sonst wurde nichts zusätzlich abgerechnet. Es gibt keine Gebühr pro Sprache und keine Gebühr pro Sitzplatz – die zwölfte Sprache hinzuzufügen kostet also genauso viel wie die dritte. Die aktuellen Pläne findest du auf der Preise-Seite.

Was hat das Engineering tatsächlich umfasst?

Ein Pull Request, noch am selben Nachmittag gemergt, und keiner der Schritte darin war Übersetzung. Als er geöffnet wurde, lief der Übersetzungsjob erneut darüber und holte 56.370 von 56.390 Strings direkt aus der Translation Memory, sodass die bereits übersetzten Kataloge in sieben Minuten in den neuen Dateien landeten. Übersetzung ist der Teil, der automatisiert wurde. Eine neue Locale in einer Next.js-Site zu registrieren, ist weiterhin dein Code – und es lohnt sich zu wissen, was „dein Code“ bedeutet, bevor du planst.

Ein Locale zu next-intl hinzuzufügen, ist eine Zeile in der Routing-Konfiguration. Alles, was eine URL baut, ein Locale liest oder deine Locales auflistet, ist der Rest des Diffs:

• Routing: die Locale-Liste, plus ein URL-Präfix-Override für pt-BR (nächster Abschnitt).
• SEO-Metadaten: hreflang-Cluster, Canonicals, og:locale (ja_JP, pt_BR) und die Locale-Liste, über die die Metadaten-Helfer iterieren.
• Formatierung: Intl-Tags ja-JP und pt-BR, damit Daten und Zahlen korrekt gerendert werden.
• Sprachumschalter: Er verlinkt auf jedes Locale mit einem echten <a href hreflang>, damit Crawler ihm folgen können.
• Sitemap und Checks: Der Sitemap-Generator, der Lastmod-Check, der interne Link-Check und der Translation-Verifier mussten alle die beiden neuen Codes lernen.
• Kataloge: leere, nur mit Header versehene .po-Dateien für die beiden Locales, im selben Pull Request aus der Translation Memory befüllt.

Wenn deine Site weniger custom ist als unsere, ist der Großteil dieser Liste reine Konfiguration. Wenn du irgendwo URLs von Hand baust – und die meisten Sites tun das irgendwo –, findest du jede einzelne Stelle beim ersten Link, der falsch herauskommt. Der Developer Guide deckt das Setup ab, und was ein KI-Lokalisierungs-Agent tatsächlich tut zeigt, wo die Trennlinie zwischen automatisiert und nicht automatisiert verläuft.

Warum liegt brasilianisches Portugiesisch unter /pt-br/ und nicht unter /pt-BR/?

Weil ein Sprach-Tag und ein URL-Segment zwei verschiedene Dinge mit unterschiedlichen Aufgaben sind.

Der korrekte Tag ist pt-BR, gemäß BCP 47. Wir verwenden ihn überall dort, wo eine Maschine die Sprache liest: Dateinamen, <html lang>, hreflang, og:locale und Intl. Nur die URL wird kleingeschrieben:

// i18n/routing.ts (trimmed)
const prefixes = {
  "pt-BR": "/pt-br",
} as const;

export const routing = defineRouting({
  locales: ["en", "it", "de", "fr", "es", "lv", "hi", "lt", "et", "ja", "pt-BR"],
  defaultLocale: "en",
  localePrefix: { mode: "always", prefixes },
});

/** The URL path segment for a locale: `pt-BR` → `pt-br`, `de` → `de`. */
export function localeUrlSegment(locale: string): string {
  const prefix = (prefixes as Record<string, string | undefined>)[locale];
  return prefix ? prefix.slice(1) : locale;
}

Pfade mit gemischter Groß-/Kleinschreibung werden falsch getippt, und eine Site, die sowohl unter /pt-BR/ als auch unter /pt-br/ antwortet, hat zwei Kopien jeder Seite, die miteinander konkurrieren. Deshalb leitet /pt-BR/ auf /pt-br/ um, und localeUrlSegment() baut jede handgemachte URL aus der Präfix-Map. Eine einzige Quelle der Wahrheit bedeutet, dass Sprachumschalter, Canonicals und Sitemap nicht auseinanderdriften können.

Warum Japanisch und brasilianisches Portugiesisch?

Es sind große Websprachen, die wir bisher nicht abgedeckt hatten. Nach der Zählung von W3Techs am Tag, an dem wir live gegangen sind, ist Japanisch die Inhaltssprache von 4,9 % aller Websites und Portugiesisch von 4,1 %.

Das Argument dafür ist älter als wir. CSA Research befragte 2020 8.709 Verbraucher in 29 Ländern, und 76 % gaben an, Produkte lieber zu kaufen, wenn Informationen in ihrer eigenen Sprache vorliegen. Das ist die Nachfrageseite. Verändert hat sich die Angebotsseite: Zwei Sprachen waren früher eine Sache für einen Dienstleister – heute kosten sie 31 €.

Unsere eigene Regel für die Sprachauswahl steht im Growth-Playbook-Beitrag. Schau, woher dein Traffic schon kommt, füge zwei Sprachen hinzu, ändere sonst nichts, und miss ein Quartal lang. Genau das machen wir jetzt mit diesen beiden.

Was haben wir noch nicht geprüft?

Die Prüfung durch Muttersprachler. Noch hat niemand, der Japanisch oder brasilianisches Portugiesisch als Muttersprache spricht, den Output durchgesehen.

Was wir geprüft haben: automatisierte QA für jeden String, der Build besteht jede Prebuild-Prüfung, und die Seiten, die wir auf Staging stichprobenweise getestet haben, liefern 200 mit korrektem lang, Canonical und Hreflang und rendern vollständig. Was ein Build nicht prüfen kann, ist, ob ein Satz klingt, als hätte ihn ein Mensch geschrieben. Das haben wir auf die harte Tour gelernt, als wir unser eigenes Deutsch und Französisch geprüft und über ganze Seiten hinweg das falsche Register gefunden haben.

Die Prüfung folgt also als Nächstes, und wir werden diesen Beitrag mit den Ergebnissen aktualisieren – inklusive allem, was falsch war.

Könntest du dasselbe auf deiner Site machen?

Wenn deine Strings schon in Katalogen liegen: ja, und der Übersetzungsteil dauert dann Minuten. Wenn sie noch hartcodiert in Komponenten stecken, kommt zuerst die Konvertierung. Die läuft einmal, im In-App-Connect-Flow, und ab dann übersetzen Push-Jobs neue Strings automatisch. Der Vibe-Coder-Guide behandelt Apps, die mit Lovable, Bolt oder Cursor gebaut wurden – dort sind hartcodierte Strings die Norm.

Die Kosten skalieren mit den Wörtern, die du übersetzt – nicht mit der Anzahl der Sprachen oder der Teamgröße. Deshalb hat sich die Antwort auf „Lohnt es sich, eine Sprache hinzuzufügen?“ verändert. Das Messen selbst ist inzwischen günstiger als das Meeting darüber.

Probier es an deinem eigenen Repository aus

Zwei Sprachen haben uns acht Minuten Übersetzung und rund 31 € gekostet. Verbinde dein Repository, wähle zwei Sprachen, auf die deine Analytics schon hinweisen, und sieh dir an, wie deine eigene Quittung aussieht.