A localization system built for teams

Localization is part of content design

A translated string is only one part of a localized experience. Navigation, slugs, metadata, image descriptions, references, dates, and editorial tone all need deliberate treatment. We model English and French together so each document exposes its translation status and every language receives the context needed for an accurate result.

The people responsible are listed on our team page, and language decisions are included in our design approach. Our baseline also draws on the W3C Internationalization resources for durable guidance on language, direction, locale-aware formats, and web architecture.

Preserve meaning and context

Translators receive the full document, intended audience, character constraints, and a preview instead of isolated strings. Reference fields connect equivalent destinations across languages. Localized slugs remain readable, while stable document identifiers let applications relate the same concept without relying on a translated label.

• Treat metadata, alternative text, labels, validation messages, and URLs as first-class translated content.
• Avoid joining sentence fragments in components; grammar and word order vary between languages.
• Review each locale in context and allow deliberate adaptation when a direct translation would be unclear.

Language parity means equal care and capability, not forcing every locale into identical wording.

Make completeness visible

Dashboards can show missing fields, stale translations, and references that lead to the wrong locale. That visibility helps teams plan work before a release instead of discovering gaps after publication. A documented fallback policy handles genuine exceptions without hiding unfinished localization from reviewers.