i18n Done Right for DACH Products: What Most SaaS Gets Wrong About German

A well-known US collaboration tool shipped "Du bist jetzt eingeloggt!" to every enterprise buyer in Germany — a chirpy "you're in!" aimed at Mittelstand controllers who still sign printed invoices. A bank IT lead quoted that exact string as the reason he killed the rollout: "Die duzen mich in meinem eigenen System."

That is what a bad German translation looks like in B2B: not misspellings, but a tone decision that reads as amateurism. "We support German" usually means "we ran strings through an LLM and a contractor cleaned them up once." This post is the patterns we apply at Teknora — across ZahlFlow, Commersio, BookMe and the rest — to ship German that a native reader does not notice.

Why "Google Translate plus a review pass" is not enough

German is domain-sensitive in ways that flatten in translation. "Cancel" is the classic example: Stornieren for a booking, Kündigen for a subscription, Abbrechen for interrupting an in-progress action. The wrong one changes what the button is promising legally.

Register is the second problem. Given "Welcome back, Anna!", a machine translator has no idea whether to produce neutral "Willkommen zurück, Anna!", the du form ("Schön, dich wiederzusehen!" — wrong for a bank portal), or the Sie form (correct for Mittelstand B2B). The LLM picks one on training-set vibes, and that choice is now baked into your product.

Third is compounding. German welds concepts together — Rückerstattungsanspruch, Kundenregistrierungsbestätigung — and idiomatic phrasing often splits or rewrites them entirely. That level of taste is where almost every US SaaS visibly stops.

Sie vs du is a decision, not a preference

Pronoun choice is a positioning decision: made once, documented, enforced at review time. German B2B still leans Sie by default (opens in new tab), and imposing du is actively rude in professional settings (opens in new tab). XING tried to flip its user base to du overnight and rolled it back under protest.

Our rule of thumb for Mittelstand:

• Default to Sie for finance, law, HR, healthcare, public sector, or executive-level buyers.
• Du is legitimate for developer-tooling or startup-audience products. If your product competes with SAP or DATEV, du is probably fatal.
• Never mix within a single locale — readers notice immediately.
• Do not offer a toggle unless you will maintain two full translation sets forever.

The variable-pronoun problem is not solvable with a library. It is solvable with a checklist.

Word length and layout: designing for Kundenregistrierungsbestätigung

German text runs 30-40% longer than English on average, with individual words up to 200% longer (opens in new tab). Real compound nouns blow out buttons, table headers, and nav items designed in English.

Three layout rules that save us real work:

1. Never fix the width of a control to the English string. In Tailwind, reach for min-w-[...] not w-[...].
2. Reserve vertical space for two-line labels. A one-line English CTA wraps in German ~20% of the time.
3. Audit with a pseudo-locale that adds 40% to every string before any translation lands. Microsoft and Phrase both document this pattern (opens in new tab).

Never text-ellipsis German labels that carry meaning — truncating turns a real word into a guess.

DIN formats: dates, numbers, currency, phone, address

The highest-leverage thing a US team can do for German credibility is stop hardcoding formats. DIN 5008 — most recently revised in 2020 (opens in new tab) — is what every German back-office system expects.

The non-negotiables:

• Dates: TT.MM.JJJJ — 04.04.2026, not 4/4/2026. ISO 8601 is fine inside APIs; DIN 5008 is what users see.
• Times: 24-hour with colon, 14:30.
• Numbers: decimal comma, thousands with a thin space or a dot — 1.234,56.
• Currency: 1.234,56 € with the symbol after the amount and a non-breaking space. Never €1,234.56.
• Phone: DIN 5008 dropped the bracketed-zero style in 2020. Use +49 30 12345678.
• Addresses: postal code precedes the city (10115 Berlin); country on its own line in all caps for cross-border mail.

Use Intl.DateTimeFormat('de-DE') and Intl.NumberFormat('de-DE'), and gate currency per-tenant so Swiss customers get their apostrophe thousands separator (1'234.56) without a code change.

Architecture: keys, namespacing, plurals, server vs client

At Teknora we run a dual setup — a server-side resolver in src/lib/i18n-server.ts and a client-side provider in src/lib/i18n-client.tsx, both producing the same t() signature from the same store. Server components get static-time resolution; client components get reactive language switching.

Key decisions:

• Dot-notation keys, one file per product. t('zahlflow.onboarding.kycStep.helpText') beats deeply nested JSON for review-ability. Product strings under src/lib/i18n/products/{ProductName}.tsx, globals in src/lib/i18n-translations.ts.
• ICU MessageFormat from day one. MessageFormat 2.0 reached stable status in Unicode CLDR 47 in March 2025 (opens in new tab), integrated into ICU 77 (opens in new tab), with a JS polyfill via messageformat@4 (opens in new tab). Write MF2 now.
• Type-safe keys. Missing keys must be a TypeScript error, not a runtime fallback to English. next-intl (opens in new tab) does this out of the box.
• Keep translations in the repo. The source of truth that blocks a release is the file in Git.

For new Next.js App Router projects, next-intl is the one we reach for (opens in new tab): RSC-first, ICU plurals, no client provider in server components. Lingui (opens in new tab) and react-intl (opens in new tab) remain options; see the BuildPilot 2026 comparison (opens in new tab).

SEO for bilingual sites: hreflang, self-canonicals, and not being a duplicate

The number-one mistake is pointing the canonical of /de/produkt/zahlflow at /produkt/zahlflow. That tells Google "the German version is a copy," and it quietly de-prioritizes the page. Google's guidance (opens in new tab) is explicit: every localized version must self-canonicalize and hreflang-link bidirectionally to all siblings, including itself.

Minimum viable setup per page:

• <link rel="canonical" href="https://teknora.com/de/produkte/zahlflow" /> — points to itself.
• <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" />

Three traps we have walked into:

1. Region codes without language codes. hreflang="be" is Belarusian, not Belgium. Use de-CH for Switzerland.
2. Non-absolute URLs. Relative hrefs in hreflang silently fail in some crawler configurations.
3. Inconsistent Schema.org inLanguage. Set it at the layout level from the same locale source that drives hreflang.

A German page that is just a machine translation is, to Google, a weak duplicate. hreflang cannot rescue content that is not real.

Translation workflow that does not collapse at scale

The hardest problem in i18n is the operating model. Six months after launch, English placeholders are leaking into German builds and glossary decisions have drifted because nobody enforced them.

The operating model we use:

• English is the source of truth, owned by the product team. If a translator thinks English wording is wrong, they open an issue.
• Every new key lands in the same PR as the feature — English and German draft, both. LLM-assisted is fine, but a named human reviews before merge. TypeScript build fails on missing German.
• Glossary lives in Git, reviewed like code. A GLOSSARY.de.md with the 80-100 decisions that matter: register, product-noun choices, what Cancel becomes in each context.
• TMS is a collaboration layer, not source of truth. We have used Crowdin (opens in new tab) and Tolgee (opens in new tab) and evaluated Lokalise (opens in new tab) and Phrase (opens in new tab). Tolgee's in-context editing has cut our review burden more than any other feature, and it is open source. For a four-locale product, Tolgee or Crowdin is what we recommend.
• AT and CH get glossaries, not full re-translations. Delta file only: Januar → Jänner in Austrian; ß → ss globally in Swiss (orthography permits it (opens in new tab)). One file plus two overlays.

What this buys you

A Mittelstand IT lead evaluating German SaaS in 2026 has seen a dozen US tools that "support German." The ones that win are not those with the cleanest English copy — they are those where the German reads like it was written for Germans: Sie where Sie was expected, 04.04.2026 where the invoice demanded it, Rückerstattungsanspruch that did not clip the button.

None of this is rocket science. What makes it hard is that no single metric screams "your German is bad" — product works, tests pass, translator signed off — so teams drift into shipping strings that are not wrong, but wrong for the audience. The fix is treating localization as a product discipline with owners, style guides, and review gates.

Further reading

• Unicode CLDR 47 release note: MessageFormat 2.0 is stable (opens in new tab)
• Google Search Central — Localized versions of your pages (hreflang guidance) (opens in new tab)
• next-intl — Design principles (opens in new tab)
• DIN 5008 — Wikipedia (German business-writing standard, 2020 revision) (opens in new tab)
• Lingui vs react-intl — official comparison (opens in new tab)
• Tolgee vs Crowdin — open-source alternative overview (opens in new tab)