Dream Factory by TruBridge Ideas Portal
Competing with software in international markets is a challenge. To support a solid Internationalization (i18n), applications must be adaptable to various languages and regions without engineering changes.
Date and time is the most common format addressed in our software, although it is forced from code to a specific region. This tool should provide knowledge and guidance on adapting our software to be tolerant to localization and handle formats according to the user and not to server settings.
Beyond date time format, it should provide information about how to safely deal with measurement systems to consolidate them and give the user precise information regarding US customary, Imperial, and metric values.
Translations can potentially be adapted by region, not limited to languages. A tool should provide an easy way to translate the UI and messages remotely from native speakers.
Paper sizes as US-letter and ISO standards should be considered for formal documents in the PDF building process.
Numeric format systems can become a significant economic issue if they are not well presented. Applications must be able to mitigate the confusion between decimal separators and thousands separators (dot or comma, in both cases).
Time zones are a problem not only related to geography but political decisions. This software tool should also provide information about how to determine an exact moment in time using standard time zone databases.
i18n (and a11y) should be foundational requirements
This topic has come up during some of our past tech/engineer "summits" (and many other times). IIRC, GRH probably has the highest maturity level around some of these concepts and I believe they have a contractor relationship that helps them create i18n strings and phrases.
A good starting point for us would be to collect user-setting to correspond to OIDC.locale and to include this assertion within userinfo and id_tokens - https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
We have problems in the areas mentioned by Marcelo, but also in perhaps unobvious areas - like storing/capturing HumanNames in a way that does not lend itself to i18n - https://www.w3.org/International/questions/qa-personal-names
Many of our problems stem from foundational problems in how the data is stored. We need strict adherence - by all teams, features and products - to some set of principles... just as examples:
Always store values with units
Always store dates/times/timestamps w/ timezone OR at UTC (see above)
Services: support Accept-Language and Content-Language
Support OIDC.locale
Use window.Intl
Support OIDC.locale
Use i18n strings files
Support / monitor changes to lang eg: ing-bank/lion/localize
Support / monitor changes to dir (rtl/ltr/auto)
It can be quite an overwhelming and broad topic, we need to find a way to approach it in digestible chunks and in a way that is actionable by different teams / tech stacks