i18n richtig gemacht für DACH-Produkte: Was die meisten SaaS-Anbieter bei Deutsch falsch machen

Ein bekanntes US-Kollaborationstool hat jedem Enterprise-Einkäufer in Deutschland die Zeile „Du bist jetzt eingeloggt!" ausgeliefert — ein flapsiges „du bist drin!", adressiert an Mittelstandscontroller, die ihre Rechnungen noch ausgedruckt unterschreiben. Ein Bank-IT-Leiter hat genau diesen String als Grund genannt, warum er den Rollout gestoppt hat: „Die duzen mich in meinem eigenen System."

So sieht eine schlechte deutsche Übersetzung im B2B aus: keine Rechtschreibfehler, sondern eine Tonentscheidung, die als Amateurhaftigkeit ankommt. „Wir unterstützen Deutsch" heißt meist „Wir haben die Strings einmal durch ein LLM gejagt, und ein Contractor hat sie einmalig überarbeitet." Dieser Beitrag ist die Sammlung von Mustern, die wir bei Teknora anwenden — über ZahlFlow, Commersio, BookMe und den Rest — um Deutsch auszuliefern, das ein Muttersprachler nicht bemerkt.

Warum „Google Translate plus eine Review-Runde" nicht reicht

Deutsch ist auf eine Art domänensensitiv, die beim Übersetzen verloren geht. „Cancel" ist das Paradebeispiel: Stornieren für eine Buchung, Kündigen für ein Abonnement, Abbrechen für das Unterbrechen einer laufenden Aktion. Das falsche Wort verändert, was der Button rechtlich verspricht.

Das Register ist das zweite Problem. Bei „Welcome back, Anna!" weiß ein Maschinenübersetzer nicht, ob er neutral „Willkommen zurück, Anna!", die du-Form („Schön, dich wiederzusehen!" — falsch für ein Bankportal) oder die Sie-Form (korrekt für Mittelstands-B2B) produzieren soll. Das LLM wählt nach Trainingsdatengefühl, und diese Wahl ist dann fest in Ihr Produkt eingebrannt.

Das dritte Problem ist die Komposition. Deutsch schweißt Begriffe zusammen — Rückerstattungsanspruch, Kundenregistrierungsbestätigung —, und idiomatische Formulierungen spalten oder umschreiben sie häufig komplett. Auf diesem Niveau an Sprachgefühl hört fast jeder US-SaaS sichtbar auf.

Sie vs. du ist eine Entscheidung, keine Vorliebe

Die Pronomenwahl ist eine Positionierungsentscheidung: einmal getroffen, dokumentiert, im Review durchgesetzt. Die B2B-Konvention im DACH-Raum tendiert per Default weiterhin zum Sie (opens in new tab), und einem Nutzer das du aufzudrängen, gilt im professionellen Umfeld als aktiv unhöflich (opens in new tab). XING hat versucht, seine Nutzerbasis über Nacht auf du umzustellen, und musste es nach Protest zurückrollen.

Unsere Faustregel für Mittelstandsfokus:

• Im Zweifel Sie für Finanzwesen, Recht, HR, Gesundheit, öffentlichen Sektor oder Einkäufer auf C-Level.
• Du ist legitim für Developer-Tools oder Startup-Zielgruppen. Konkurriert Ihr Produkt mit SAP oder DATEV, ist du vermutlich tödlich.
• Niemals mischen innerhalb eines Locales — Lesern fällt das sofort auf.
• Kein Toggle anbieten, es sei denn, Sie pflegen zwei vollständige Übersetzungssätze auf Dauer.

Das Pronomenproblem lässt sich nicht mit einer Library lösen. Es lässt sich mit einer Checkliste lösen.

Wortlänge und Layout: Entwerfen für Kundenregistrierungsbestätigung

Deutscher Text ist im Durchschnitt 30 bis 40 % länger als Englisch, einzelne Wörter bis zu 200 % länger (opens in new tab). Echte Komposita sprengen Buttons, Tabellen-Header und Nav-Items, die für Englisch entworfen wurden.

Drei Layout-Regeln, die uns spürbar Arbeit sparen:

1. Niemals die Breite eines Controls auf den englischen String fixieren. In Tailwind greifen Sie zu min-w-[...] statt w-[...].
2. Vertikalen Platz für zweizeilige Labels reservieren. Ein einzeiliges englisches CTA bricht in etwa 20 % der Fälle auf Deutsch um.
3. Mit einem Pseudo-Locale auditieren, das jedem String 40 % hinzufügt, bevor irgendeine Übersetzung live geht. Microsoft und Phrase dokumentieren dieses Vorgehen (opens in new tab).

Niemals text-ellipsis auf deutschen Labels, die Bedeutung tragen — das Kürzen macht aus einem echten Wort eine Rateaufgabe.

DIN-Formate: Datum, Zahlen, Währung, Telefon, Adresse

Das wirkungsvollste, was ein US-Team für deutsche Glaubwürdigkeit tun kann, ist: hart codierte Formate abschaffen. DIN 5008 — zuletzt 2020 überarbeitet (opens in new tab) — ist der Erwartungsstandard jedes deutschen Back-Office-Systems.

Die nicht verhandelbaren Punkte:

• Datum: TT.MM.JJJJ — 04.04.2026, nicht 4/4/2026. ISO 8601 ist in APIs in Ordnung; DIN 5008 ist, was Nutzer sehen.
• Uhrzeiten: 24-Stunden-Format mit Doppelpunkt, 14:30.
• Zahlen: Dezimalkomma, Tausender mit schmalem Leerzeichen oder Punkt — 1.234,56.
• Währung: 1.234,56 € mit Symbol nach dem Betrag und einem geschützten Leerzeichen. Niemals €1,234.56.
• Telefon: DIN 5008 hat 2020 die alte Klammer-Null-Schreibweise abgeschafft. Verwenden Sie +49 30 12345678.
• Adressen: Postleitzahl vor dem Ort (10115 Berlin); Land bei Auslandspost in eigener Zeile in Großbuchstaben.

Verwenden Sie Intl.DateTimeFormat('de-DE') und Intl.NumberFormat('de-DE'), und machen Sie die Währungsdarstellung pro Mandant konfigurierbar, damit Schweizer Kunden ohne Code-Änderung ihren Apostroph als Tausendertrennzeichen (1'234.56) bekommen.

Architektur: Keys, Namespacing, Plurale, Server vs. Client

Bei Teknora fahren wir ein Dual-Setup — einen serverseitigen Resolver in src/lib/i18n-server.ts und einen clientseitigen Provider in src/lib/i18n-client.tsx, beide mit derselben t()-Signatur aus demselben Store. Server-Komponenten bekommen statische Auflösung zur Build-Zeit; Client-Komponenten bekommen reaktives Sprachumschalten.

Schlüsselentscheidungen:

• Punkt-notierte Keys, eine Datei pro Produkt. t('zahlflow.onboarding.kycStep.helpText') schlägt tief verschachteltes JSON in der Review-Freundlichkeit. Produkt-Strings unter src/lib/i18n/products/{ProductName}.tsx, globale Strings in src/lib/i18n-translations.ts.
• ICU MessageFormat von Tag eins. MessageFormat 2.0 hat im März 2025 mit Unicode CLDR 47 den Stable-Status erreicht (opens in new tab), ist in ICU 77 (opens in new tab) integriert, mit einem JS-Polyfill via messageformat@4 (opens in new tab). Schreiben Sie MF2 jetzt.
• Typsichere Keys. Fehlende Keys müssen ein TypeScript-Fehler sein, kein Runtime-Fallback auf Englisch. next-intl (opens in new tab) macht das ab Werk.
• Übersetzungen im Repo halten. Die Quelle der Wahrheit, die ein Release blockiert, ist die Datei in Git.

Für neue Next.js-App-Router-Projekte greifen wir zu next-intl (opens in new tab): RSC-first, ICU-Plurale, kein Client-Provider in Server-Komponenten. Lingui (opens in new tab) und react-intl (opens in new tab) bleiben Optionen; siehe den BuildPilot-2026-Vergleich (opens in new tab).

SEO für zweisprachige Sites: hreflang, Self-Canonicals und kein Duplicate sein

Der häufigste Fehler ist, das Canonical von /de/produkt/zahlflow auf /produkt/zahlflow zu zeigen. Das sagt Google „die deutsche Version ist eine Kopie", und die Seite wird stillschweigend depriorisiert. Googles Empfehlung (opens in new tab) ist eindeutig: Jede lokalisierte Version muss sich selbst canonicalisieren und per hreflang bidirektional auf alle Geschwister verweisen, inklusive sich selbst.

Minimal sinnvolles Setup pro Seite:

• <link rel="canonical" href="https://teknora.com/de/produkte/zahlflow" /> — zeigt auf sich selbst.
• <link rel="alternate" hreflang="de" href="https://teknora.com/de/produkte/zahlflow" />
• <link rel="alternate" hreflang="en" href="https://teknora.com/en/produkte/zahlflow" />
• <link rel="alternate" hreflang="x-default" href="https://teknora.com/en/produkte/zahlflow" />

Drei Fallen, in die wir gelaufen sind:

1. Regionscodes ohne Sprachcode. hreflang="be" ist Belarussisch, nicht Belgien. Verwenden Sie de-CH für die Schweiz.
2. Nicht-absolute URLs. Relative hrefs in hreflang-Tags scheitern in manchen Crawler-Konfigurationen stillschweigend.
3. Inkonsistentes Schema.org-inLanguage. Setzen Sie es auf Layout-Ebene aus derselben Locale-Quelle, die auch hreflang steuert.

Eine deutsche Seite, die nur eine Maschinenübersetzung ist, ist aus Googles Sicht ein schwaches Duplicate. hreflang kann Inhalt nicht retten, der nicht real ist.

Übersetzungs-Workflow, der unter Skalierung nicht zusammenbricht

Das schwerste Problem in i18n ist das Betriebsmodell. Sechs Monate nach dem Launch tauchen englische Platzhalter in deutschen Builds auf, und Glossar-Entscheidungen sind aufgeweicht, weil niemand sie durchgesetzt hat.

Das Betriebsmodell, das wir nutzen:

• Englisch ist die Quelle der Wahrheit, Ownership beim Produktteam. Hält ein Übersetzer die englische Formulierung für falsch, öffnet er ein Issue.
• Jeder neue Key landet im selben PR wie das Feature — Englisch und deutscher Draft, beides. LLM-unterstützt ist okay, aber ein namentlich genannter Mensch reviewt vor dem Merge. Der TypeScript-Build scheitert bei fehlendem Deutsch.
• Das Glossar lebt in Git und wird wie Code reviewt. Ein GLOSSARY.de.md mit den 80 bis 100 Entscheidungen, die zählen: Register, Produkt-Substantiv-Wahl, wie Cancel in welchem Kontext heißt.
• Das TMS ist eine Kollaborationsschicht, nicht die Quelle der Wahrheit. Wir haben Crowdin (opens in new tab) und Tolgee (opens in new tab) im Einsatz gehabt und Lokalise (opens in new tab) sowie Phrase (opens in new tab) evaluiert. Tolgees In-Context-Editing hat unseren Review-Aufwand stärker reduziert als jedes andere Einzelfeature, und es ist Open Source. Für ein Produkt mit vier Locales empfehlen wir Tolgee oder Crowdin.
• AT und CH bekommen Glossare, keine vollständigen Neuübersetzungen. Nur eine Delta-Datei: Januar → Jänner im Österreichischen; ß → ss durchgängig im Schweizer Deutsch (die Orthographie erlaubt es (opens in new tab)). Eine Datei plus zwei Overlays.

Was Ihnen das bringt

Ein Mittelstands-IT-Leiter, der 2026 deutschsprachige SaaS evaluiert, hat ein Dutzend US-Tools gesehen, die „Deutsch unterstützen". Die Produkte, die gewinnen, sind nicht die mit dem saubersten englischen Copy — es sind die, bei denen sich das Deutsche so liest, als wäre es für Deutsche geschrieben worden: Sie, wo Sie erwartet wurde, 04.04.2026, wo die Rechnung es verlangt, Rückerstattungsanspruch, das den Button nicht abschneidet.

Nichts davon ist Raketenwissenschaft. Was es schwer macht: Keine einzige Metrik schreit „Ihr Deutsch ist schlecht" — das Produkt funktioniert, Tests sind grün, der Übersetzer hat abgenommen — und so driften Teams in den Fehlerzustand, Strings auszuliefern, die nicht falsch sind, aber für die Zielgruppe falsch. Die Lösung ist, Lokalisierung als Produktdisziplin zu behandeln, mit Ownern, Style Guides und Review-Gates.

Weiterführende Literatur

• Release Note zu Unicode CLDR 47: MessageFormat 2.0 ist stabil (opens in new tab)
• Google Search Central — Lokalisierte Seitenversionen (hreflang-Guidance) (opens in new tab)
• next-intl — Design Principles (opens in new tab)
• DIN 5008 — Wikipedia (deutscher Geschäftskorrespondenz-Standard, Revision 2020) (opens in new tab)
• Lingui vs. react-intl — offizieller Vergleich (opens in new tab)
• Tolgee vs. Crowdin — Überblick zur Open-Source-Alternative (opens in new tab)