i18n (internationalization)

i18n is the numeronym for 'internationalization' (i, 18 letters, n) and it means the engineering prep, not the translating. You pull every user-visible string out of components into a catalog, stop hardcoding date order and decimal separators, let layouts stretch, and make direction, plural rules, and number formats come from a locale instead of from your assumptions about English. Currency and time zone stay separate inputs: the locale says how to write an amount, not which money it is.

Do it before you have a second language, not after. Retrofitting means touching every component twice, and the expensive parts are structural: fixed-width buttons, sentences glued together from fragments, icons that assume text flows left to right, date formatters with a hardcoded 'en-US'. Modern stacks give you most of it: Intl in the browser, CSS logical properties for layout, ICU MessageFormat for plurals.

Gotcha: teams think i18n is done when the strings are extracted. The strings are the easy half. Sorting, search, name and address fields, phone validation, uploaded filenames, and text truncation all break in languages you never tested. Run pseudo-localization early, but know what it catches: the mechanical failures, meaning hardcoded strings, text expansion, encoding, truncation, and layout that will not flip. Sorting, search, forms, and validation need real locale data and functional tests instead.