i18n for Frontline Apps Is a Field Problem, Not a String Table

When I talk i18n with CTOs on B2E products, the string table is the easy part. Frontline workforces are often the most linguistically diverse part of an enterprise — multiple languages on one shift, varying literacy levels, and RTL languages that break layouts no one tested. So I treat i18n as an architecture decision from the first screen, not a localization pass before launch. A few principles I bring to R&D: externalize every string and let layouts flow, because German runs long and Hebrew and Arabic run right-to-left and your fixed-width buttons will shatter. Lean on icons, camera, GPS, and QR over text — a mobile-first field workflow that minimizes language is inherently easier to localize and more inclusive. Watch the legacy integration boundary: payroll and HR systems often carry their own locale, date, currency, and name-format assumptions, and the mismatch surfaces as production bugs. And don't forget Offline Mode — translations and locale data have to ship in the bundle, because you can't fetch a language pack in a dead zone. Done right, i18n stops being a release-blocking scramble and becomes a property of the system. The teams that retrofit it always pay more than the teams that designed for it.