Multilingual Localisation Platform Development

We generate hreflang annotations programmatically from the content graph -- every page knows its locale variants at build time, so there's no manual maintenance, ever. Our CI/CD pipeline runs automated validation on every single deploy, checking for orphaned tags, missing reciprocals, and conflicting canonicals. This catches errors before they reach production, which genuinely matters. A single hreflang mistake can cause Google to ignore the entire tag set for a page -- not just the broken one, the whole set. We've cleaned up enough post-launch SEO disasters to build that validation in from day one.

First-pass AI accuracy varies by language pair -- European languages like French, German, and Spanish typically hit 80-85% immediately, while CJK languages land around 70-75% out of the gate. But after three months of translation memory accumulation and model fine-tuning on your specific brand voice, most content types reach 85-90% accuracy regardless of language. At that point, human review shifts from full rewrite mode to spot-check mode -- and that shift cuts review time by 40-60%. It's not magic, it's just the model learning your terminology through repetition.

We use three signals in combination: GeoIP identifies the country, the Accept-Language header shows what the browser actually prefers, and a cookie stores whatever the user explicitly chose. Take Switzerland -- GeoIP returns CH, then we check the browser language header to distinguish de-CH, fr-CH, or it-CH. Users can always override via a language selector, and that preference persists across sessions through the cookie and, optionally, database storage for logged-in users. No guessing, no defaulting everyone to English because the detection logic gave up.

Yes -- and honestly, that's the core architectural advantage here. Adding a new locale means creating the locale config in the CMS, activating the translation pipeline for that language pair, and deploying. Hreflang generation, URL routing, sitemap creation -- it all adapts automatically. We've built this for 30 languages from day one, but the system handles 50+ without any architectural changes. In practice, a new language takes about 2-3 days of configuration work. Not a project. Not a sprint. Two or three days.

Our frontend uses logical CSS properties throughout -- `margin-inline-start` instead of `margin-left`, that kind of thing -- with `dir` attributes set at the HTML level. The CMS content model flags RTL locales, and the rendering layer handles layout direction, text alignment, and navigation order automatically from there. But here's the thing: we test every component in both LTR and RTL directions during development. RTL support isn't a post-launch patch we apply to Arabic and Hebrew after the fact -- it's baked into the design system from the first component.

A full 30-language platform -- translation pipelines, hreflang infrastructure, edge routing, the works -- typically runs 10-14 weeks and falls somewhere in the $80,000-$200,000 range. The spread depends on content volume, CMS complexity, and how custom your editorial workflow needs to be. Ongoing retainer support for translation pipeline management and locale expansion runs $3,000-$8,000 per month. For context, that's often less than what teams are spending on manual translation for just 3-4 languages.