i18n Is an Architecture Decision, Not a Translation Task

Every CTO I work with in the public sector eventually hits the same wall: i18n was treated as a translation pass at the end, and now half the UI breaks in the second language. In govtech this isn't optional polish — serving citizens in every language they speak is often a legal and civic obligation, so I push to make i18n a load-bearing architecture decision from the first commit. That means no concatenated strings, no text baked into images, layouts that survive a label growing noticeably longer, and proper RTL support designed in rather than patched on. It also means the content layer is treated as data, with a real pipeline for translators who aren't engineers. The harder part is the interaction between i18n and accessibility: language attributes have to be correct for screen readers, and the reading order has to hold across scripts. The thing I emphasize to R&D is that i18n done right is mostly invisible and cheap to maintain; done late, it's a permanent tax on every feature you ship afterward. Design the seams now — locale-aware formatting, externalized content, flexible layout primitives — and adding the fourth language costs almost nothing. Retrofitting the first one costs everything.