The question of whether to localize has an easy answer for a platform, and the answer is always yes. A single app for a single market can sometimes get away with one language. A platform cannot, because a platform's whole point is to scale past the room it started in. Giant Context builds websites for businesses, and businesses have customers who do not all read English. The moment a French bakery or a Mexican firm wants a site, the product either speaks their language or it does not serve them. I also live in a bilingual country, where serving one language serves half of it.

On anything meant to scale beyond its immediate market, localization is a certainty deferred rather than a feature request that might come, and deferring a certainty is just choosing to pay more for it later. That is why it sits in my standard operating procedure next to role-based access control. Both are foundational, both are miserable to retrofit, and both should shape the schema before the schema has any data in it.

Two surfaces need translating and they are different problems. The interface, which is buttons and labels and menus, is fixed text the platform ships. The content, which is a customer's headings and paragraphs, is data the customer owns. Both run on the same machinery here, because the machinery already existed.

Interface strings are declared where they are used. Each package keeps its own locale files beside its code, and a generation step merges every package's declarations into one file per language that the application loads. So adding a translatable label is adding a line to the file next to the component, not finding your place in a central dictionary that every part of the codebase edits and nobody owns.

Content translation is narrower and needs to be. The system holds an explicit list of which field names carry translatable copy, and only those are ever translated. Everything else passes through byte for byte.

The reason that list is explicit rather than inferred is worth stating plainly. A translator that decides for itself what looks like prose will eventually decide wrongly, and a field that was never meant to be language-dependent, an identifier or a type name or a key some other part of the system matches on, gets rendered into a French version of itself. The failure is not a bad translation. It is a value that no longer matches what reads it.

So the list is derived from the type definitions and checked against them by a test. Add a translatable field to a type without registering its name, and the build fails until the two agree. The declaration and the behaviour cannot drift, for the same reason nothing else in this codebase drifts: one of them is generated from the other.

A localized system has a failure mode that ordinary code does not. It can be half-translated. A field can have its English value and be silently missing its French one, and nobody notices until a French visitor lands on a page with an English sentence sitting in the middle of it, which reads as broken to exactly the customer localization was supposed to win.

So translation completeness is tested, the same way everything here is tested. A check runs across the codebase, finds every string that is supposed to be translated, compares it against the generated locale files, and reports anything missing in any language and any place the languages have fallen out of parity. If a string exists in English and not in French, the check says so before the code ships, not after a customer finds the gap.

That test is the reason I can trust the feature. Localization is not one decision you make and forget. It is an obligation you have to meet on every new string forever, and the only way to meet an obligation that big is to have a machine check it on every push.

Build localization on day one, with identity and permissions, as a decision about the shape of your data rather than a feature you will get to. A platform is meant to scale, and it cannot scale without language at the core of it.