The teams we build for are rarely monolingual. A warehouse lead who grew up in Miami works alongside a Brazilian commercial manager and a Dominican buyer. All three are excellent at their jobs. Only one of them wants to work in English.
This is not an edge case. In US wholesale distribution, roughly one in four workers is foreign-born. In South Florida alone, over 70% of the population speaks a language other than English at home. The distribution workforce reflects the communities it serves — multilingual, multicultural, and completely uninterested in switching to English because a tool's developer never considered otherwise.
Translation as infrastructure Every label, every error, every toast in Quotery renders in en-US, pt-BR, or es-US. Not 'translated when we get around to it' — translated before the PR merges. The CLAUDE.md rule is explicit: partial translation is not acceptable.
This isn't a feature flag you can toggle off. It's not a 'languages' page in settings. It's a structural commitment: every user-facing string goes through the i18n pipeline, every new surface ships in three locales simultaneously, and the CI pipeline fails if a namespace has missing keys in any locale. Translation lag is treated exactly like broken tests — a blocker.
The payoff is invisible when it works and catastrophic when it doesn't. A warehouse worker who sees an error in Portuguese understands what to fix. The same worker seeing an English error message skips it, guesses, and creates an inventory discrepancy that costs hours to unravel. Translation isn't a nice-to-have — it's an accuracy control.
Caribbean Spanish We chose es-US (Miami / Caribbean Spanish) deliberately. It uses 'ustedes' not 'vosotros', 'computadora' not 'ordenador', 'carro' not 'coche'. Small vocabulary choices compound into a tool that feels native.
This matters more than it seems. A tool localized to European Spanish feels foreign to a Dominican warehouse lead — not incomprehensible, but untrustworthy. The same way a British interface ('colour', 'centre', 'despatched') signals 'not built for you' to an American user, Castilian Spanish signals the same to a Caribbean Spanish speaker. Localization at the dialect level is what separates software that's 'available in Spanish' from software that was actually built for the people using it.
Cookie + preference
The first visit reads navigator.language, writes a qf-language cookie on .quotery.io, and then every request — landing page or platform — respects the choice.
The cookie domain matters. By setting it on .quotery.io rather than a specific subdomain, the language preference follows the user from the marketing site to the platform and back. No re-selection on login, no jarring locale switch when navigating from /product to the app. The preference is sticky, explicit (the user can change it from any page footer), and consistent across the entire product surface.