Vier Sprachen, ein CMS: wie wir i18n nicht-nervig machen

Niederländische Kunden, die spanische Interessenten erreichen wollen, deutsche B2B-Firmen, die den Benelux-Markt öffnen wollen: wir sehen dieselbe Frage in verschiedenen Formen. Die Antwort lautet meistens "drei oder vier Sprachen". Die Antwort lautet selten "wie halten wir das für den Content-Redakteur erträglich".

Drei Prinzipien halten viersprachige Sites lebbar. Erstens: ein Satz Keys, nicht ein Satz Dateien pro Sprache, der aus dem Takt gerät. Die JSON-Dateien von next-intl pro Locale mit identischer Key-Struktur geben ein diff-bares Validierungsziel. Wir prüfen automatisch in der CI, dass alle Keys in allen Sprachen vorhanden sind.

Zweitens: Content im CMS, nicht im Code. Für Frosthaven.co selbst nutzen wir JSON-Dateien, weil es eine kleine Site mit stabiler Copy ist. Für Kundensites mit ~100 Seiten wird Storyblok zur Single Source of Truth. Nicht wegen der Funktionalität (die können auch Sanity/Payload), sondern wegen der mehrsprachig-by-design-Oberfläche, die Redakteure sofort verstehen.

Drittens: Validierung der Übersetzungs-Vollständigkeit. Ein spanischer Absatz, der fehlt, macht eine halbe Seite kaputt. Wir nutzen einen Pre-Deploy-Check, der fehlschlägt, wenn eine Sprache unvollständig ist, und die Produktions-URL fällt mit einer Warnung auf die Default-Locale zurück.

SEO: hreflang-Tags pro Locale-Paar, Canonicals pro Locale und sitemap.xml mit xhtml:link-Alternates. Google honoriert das erst nach einigen Wochen Crawling, plane es vor dem Launch, nicht danach.

Der schwierigste Teil bleibt eine Sache: Tone-of-Voice pro Sprache. Eine wörtlich übersetzte Website fühlt sich algorithmisch an. Für Frosthaven schreiben wir die englische Copy am direktesten, das Spanische etwas wärmer, das Deutsche formeller und das Niederländische schärfer. Man hört es am Rhythmus.