i18n considerations

[jgindin]

There should be some mechanism to ensure that the UI which is rendered for the user respects their language and specific locale settings.

This should extend to handle (at least, there's probably other things I've forgotten):

• All strings returned for display (including pluralization)
• Right-to-left languages (e.g., Hebrew and Arabic)
• Date and number formatting
• Ensuring layouts scale properly (e.g., for languages such as German which tend to have much longer words)
• Icons and images may have to be modified to convey the intended meaning based on region and/or locale
• Colors may need to be changed based on region/location
• Validations (phone number, address/zip code) may have to be different based on region/location

See https://share.google/aimode/Ki79Osf7BI3JcXl1q

[jgindin]

For web-based transports, some data ought to be available from the HTTP headers. However it would be best to be explicit about how this data will be communicated.

[shuklatul1021]

@jgindin
this is a really important point. i agree that localization should be treated as more than just string translation it needs to respect the user’s full locale context (language, direction, formatting, layout, and regional expectations)
relying on HTTP headers can be a good starting point, but I think having an explicit and well-defined way to communicate and override locale information would make the system more predictable and flexible. Making this a first-class concern early on will help avoid UI inconsistencies and technical debt later.