Host specific locale behavior

This RFE has been there for long time and I still think this is important item. We did some efforts to synchronize locale with platform - for example, Windows native date format support in ICU4C, but we need more comprehensive locale synchronization support. We need to figure out how we can achieve this goal and estimate required tasks. [yoshito - Nov 9, 2006]

• This RFE has been there for long time and I still think this is importnat item. We did some efforts to synchronize locale with platform - for example, Windows native date format support in ICU4C, but we need more comprehensive locale synchronization support. We need to figure out how we can achieve this goal and estimate required tasks. [yoshito - Nov 9, 2006]",
• Mon Nov 13 23:36:02 2006 srl changed notes2: assign: "ram" to "yoshito,ram",
• Tue Nov 14 00:03:47 2006 grhoten changed notes2: target: "3.8 candidate" to "3.8", comments: "returned 2224
• This RFE has been there for long time and I still think this is importnat item.
• We did some efforts to synchronize locale with platform - for example, Windows
• native date format support in ICU4C, but we need more comprehensive locale
• synchronization support. We need to figure out how we can achieve this goal and
• estimate required tasks. [yoshito - Nov 9, 2006]" to "returned 2224
• This RFE has been there for long time and I still think this is important item.
• We did some efforts to synchronize locale with platform - for example, Windows
• native date format support in ICU4C, but we need more comprehensive locale
• synchronization support. We need to figure out how we can achieve this goal and
• estimate required tasks. [yoshito - Nov 9, 2006]",

Markus submitted bug 473 which should be merged with this one.

---

Date: Tue, 27 Jun 2000 14:03:51 -0400 From: markus.scherer@jtcsv.com To: icu-bugs@www10.software.ibm.com Subject: feature: use platform locale data even if modified by user

Full_Name: Markus Scherer Version: 150 OS: win32 ICU_Component: data Submission from: (NULL) (198.4.83.37) Submitted by: schererm

icu only gets the (default) locale id ("de_AT") from the platform and supplies its own locale data like date/time patterns. this is good for consistency among platforms because all icu applications anywhere will format the same way for the same locale id. it is great for server applications.

however, for client applications, it is (potentially/often) inconsistent with the locale data that other applications on the same platform use. in addition to platform-specific locale data, a user can modify date/time/number/currency patterns etc. - especially on windows - and will expect all applications on his machine to use his patterns.

* this is actually required for windows logo programs!

icu should provide the means to get locale data from the platform, including user modifications.

ideas for implementation: - we probably want to construct a ResourceBundle from the platform data - we will need to convert from platform data to icu patterns - we could have a special locale id "user"? - we might want a static Locale class method like

ResourceBundle Locale::getUserLocaleData();

rather than put special code into ResourceBundle constructors

Discussion. This wants to support sample code as in bug 3172.

In particular, there should be a way to build a service based on whatever the host locale, timezone, and currency (e.g. 'global' settings) are.

Ideas: Have a special locale called "host". When a service is created with this locale, the host settings are queried and used. Note: if the host default locale is customized, such as with Control Panel settings, then a new service (e.g. date formatter) may need to be registered.

Timing Issue: If the host locale changes in between invocations of different services, this may result in inconsistent services. Maybe we want to create an object at a given time that encapsulates a set of ICU services that correspond to host services at that point in time. That object could then be used for service creation for consistency. But this might be overkill.

We're still interested in this, but no immediate plan. Revisit this after 4.2.