I’d like to have a hierarchy of settings so you can be as granular as you want:

Is there anything set at user level? > Yes, use that.
Is there anything set at user group level? > Yes, use that.
Is there anything set at GUI application level? > Yes, use that.
Is there anything set at model level? > Yes, use that.
If nothing is set, use browse locale.

Totally agree.

I think it would be an idea to solve this in the same way as the UP configuration in IAM.
For example, by allowing the application administrator/IAM administrator to create a set of settings in which the following aspects can be specified:

• Date/time formats
• Thousand separator (dot or comma)
• The first day of the week

These sets can then be assigned to users.
In this way, an administrator can create one or more sets, and users can choose from these options without having to assemble exotic combinations themselves.

There could also be an option to keep it as it is now (i.e., localization settings based on the primary language of the browser).

​@Anne Buit is working out a design and will share some thoughts on the scope and implementation of this Idea. He’s kinda going nuts at the moment, given the challenges: Internationalis(z)ing Code - Computerphile (not all of this is in scope, I can tell you)!

Nice video, although this shouldn't of course be an issue for ​@Anne Buit :) .. we would of course like to see the gender support..  the Indian numbering system you can put on the backlog! 

Hi all,

As Arie mentioned, we’ve delved into the depths on localization, and we’ve come up with the following implementation direction (broad strokes!):

By default, OS/browser

By default, a user will use their operating system or browser locale. This will apply to all current and future localizable content, such as application language, date/time formatting and number formatting.

User-specific overrides

The user may use user-preferences to choose a different locale to diverge from the operating system or browser settings. 

User administrators will be able to either grant or revoke this capability. In addition, administrators will be able to forcibly set a different locale for users or even set a default locale for all new users of a tenant.

Further specific overrides

The users will still be able to pick a different application language than their (OS/Browser or user-specific) locale indicates.

As such, the users are able to have Dutch locale (affecting date-and-time notations, numeric notations and such) but still use English translations.

Except for the application language, we are not planning on allowing overrides for other specific locale settings to deviate further from the configured (OS/Browser or user-specific) locale.

Additional details

All of the above will only affect Indicium and mostly, Universal.

We will use the BCP 47 standard to indicate the chosen locale. For instance, en-GB, nl-NL. This aligns with operating systems, browser and the various components we use. Naturally, the UX around picking the right locale for a user will be focused more on the effect (date/time format, numeric format).

The user language will become optional as it can automatically be chosen based on the user-specific or OS/Browser locale. This requires application languages to also adhere to the BCP 47 standard. This will be part of the upgrade to a Thinkwise Platform version that supports this.

We are focusing on date-and-time formats and number formats. First-day-of-week and first-week-of-year settings will still be ISO-oriented but may be included in the future.

Generated reports may also perform locale-specific formatting. For now, these will not use the user locale and will keep working as-is.

Likewise, CSV imports and exports may also perform locale-specific formatting. For now, these will not use the user locale and will keep working as-is.