i18n for Research Platforms Is a Data Problem, Not a String Problem

Most i18n conversations I have with CTOs start with UI strings and translation files. For research and scientific software, that's the easy 20%. The harder reality is that internationalization touches the data itself. Researchers work across locales with different decimal separators, date formats, units, and number notations — and in data-heavy tools, getting that wrong isn't a cosmetic glitch, it's a corrupted dataset. So I treat i18n as an architectural concern from the start. Locale-aware formatting has to live in a single layer, not scattered across components where a virtualized table might render thousands of values inconsistently. I push engineering teams to separate display formatting from stored canonical values, so a German researcher's comma-decimal and an American colleague's period-decimal describe the same underlying number. Right-to-left support, text expansion in dense filter panels, and sortable columns under different collation rules all need to be designed in, not retrofitted. For expert international teams collaborating asynchronously, locale mismatches silently erode trust in the data. My guidance to R&D leaders is to budget i18n as core infrastructure that protects data integrity — because for scientists, that integrity is the entire product.