Locale Aware Formatting
Rendering dates, numbers, currencies and names according to the user's locale rather than the developer's, using the platform rather than hand-written logic.
Internationalisation is routinely scoped as translation, and translation is the easier half. The harder half is that data has locale-dependent presentation, and getting it wrong produces errors that are confidently wrong rather than obviously broken.
The recurring hazards: date order, where 03/04 is two different days depending on locale and neither rendering announces itself as ambiguous; decimal and thousands separators, which are inverted between conventions; currency, where the symbol, its position and the number of decimal places all vary and where the currency is a property of the transaction rather than of the viewer; and sorting, which is not codepoint order in most languages.
The rule that avoids most of it is to store canonically and format at the edge: timestamps in UTC with an offset, amounts as integer minor units with an explicit currency code, and formatting performed by the platform's internationalisation API with the user's locale.
The structural half is layout. Translated text expands substantially — German and Finnish commonly run a third longer than English — and right-to-left languages mirror the entire interface. A design that fits English exactly will break, and a layout built on logical properties rather than fixed left and right will not.