Community
Participate
Working Groups
Overview --------- Operating systems allow user to select calendar type to be used for interpreting / configuring and manipulating dates in applications. For example, when default locale is set to Hebrew user is capable to select either Gregorian or Hebrew national calendar. As opposed to operating systems Eclipse does not have a similar mechanism. Consequently user can't choose which calendar will be used in Eclipse for interpreting and manipulating with dates. How calendars are currently addressed in Eclipse ------------------------------------------------- Calendars support in Eclipse is limited by default configuration provided by appropriate Java/ICU4J classes. In those classes calendar type is tightly connected with locale. In other words, there is one-to-one correspondence between Eclipse default locale and the calendar type used. Here are a couple of examples borrowed from bug 224794: 1. PropertiesDialog & Properties view In those cases com.ibm.icu.text.DateFormat.getDateTimeInstance(int, int) is used to format the Last Modified Time property. 2. LogEntry, LogViewLabelProvider The error log view doesn't use ICU, instead it uses java.text.SimpleDateFormat with a fixed format. In both cases by default Gregorian calendar is associated with default Bidi locales (Arabic/Hebrew). What is the problem ? --------------------- The problem is however not in "incorrect" default association between default locale and calendar type but in lack of support to configure this association. Please notice that both Java/ICU4J allows configuration of calendar type in DateFormat/SimpleDateFormat classes. This can be done via setCalendar function. In addition, ICU4J do support Hebrew and Islamic-Hijri calendars. The only missing piece is to provide a similar to OS level calendar configuration in Eclipse and use it during manipulations with dates via DateFormat/SimpleDateFormat classes. Moreover, lack of such configuration on the Eclipse level forces Eclipse based products to provide such configuration as part of those products. This of course might lead to inconsistency. Translated date vs. calendar type ---------------------------------- Please notice that translated calendar is something different from calendar type. Gregorian calendar is translated to Arabic/Hebrew (and I guess to many other languages). Translation is usually associated with locale. For example, with default English locale and Gregorian calendar in use the date will be represented as: 05 august 2008 While, with default Hebrew locale and Gregorian calendar in use the date will be represented as: 05 TSUGUA 2008 Capital Latin characters stay for Bidi letters. Calendar type refer to different from Gregorian calendar type. For example, Hebrew national calendar, Islamic Hijri calendar etc. All those calendars are supported by ICU4J. Please notice that similarly to Gregorian calendar other calendars (i.e. Hebrew, Hijri etc.) can be translated as well. For example with default English locale and Hebrew national calendar in use the date will be represented as: 04 tishrei 5768 While, with default Hebrew locale and Hebrew national calendar in use the date will be represented as: H"ASHSAT IERHSIT D Capital letters stay for Bidi characters. Please notice that in this case even digits are replaced with letters since according to Hebrew national calendar numbers(digits) are represented by Hebrew numerals(letters). Proposed approach to solution ------------------------------ Calendar configuration can be provided via both: a. Command line parameter (i.e. -cal [hijri, hebrew ...]) and b. Eclipse Preferences This configuration can be further used by various components to set appropriate calendar instance in DateFormat/SimpleDateFormat classes.
Another approach for calendar specification -------------------------------------------- Another suggestion for possible configuration which does not require introduction of additional parameter (e.g. command line parameter). It appears that ICU4J supports specification of calendar as part of locale initialization parameter using calendar keyword. According to http://icu-project.org/userguide/locale.html ULocale (ICU4J alternative to Java Locale) can be initialized as follows: ULocale mylocale = new ULocale("fr@collation=phonebook;calendar=islamic-civil"); For valid values for "calendar" keyword please see the Key/Type Definitions table in the LDML (Locale Data Markup Language) at http://www.unicode.org/reports/tr35/ According to http://icu-project.org/apiref/icu4j/com/ibm/icu/util/Calendar.html currently recognized values for calendar keyword are: "buddhist", "chinese", "coptic", "ethiopic", "gregorian", "hebrew", "islamic", "islamic-civil", "japanese", and "roc". Calendar instance can be created based on such specification of calendar as follows: import com.ibm.icu.util.Calendar Calendar cal = Calendar.getInstance(new ULocale("en_US@calendar=japanese")); In this case com.ibm.icu.util.JapaneseCalendar instance will be created. What need to be added in Eclipse to support this approach ? ------------------------------------------------------------ Specification of calendar can be provided as part of specification of value for -nl command line parameter. For example: eclipse.exe -nl en_US@calendar=japanese Currently Eclipse does not relate to keywords specified after @ sign. Consequently parsing of nl command line argument should be enhanced in org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo in function setupSystemContext. In addition the calendar info (either as string or as com.ibm.icu.util.Calendar object initialized as was shown above) need to be stored in EclipseEnvironmentInfo and be available via new getCalendar method.
I've sent this on to Equinox, since the locale would need to be initialized with this information from the -nl parameter (it must be set when the locale is set). PW
An alternative solution would be for someone to query the OS to determine the calendar set by the user at the OS level. That would allow the user to use their preferred calendar type without duplicating the OS-level preference in Eclipse. I don't think this will be addressed at the Equinox level since we have no dependency on or knowledge of ICU4J. However, I will leave this here until we find a better home for it.
Also, does anyone know if ICU4J allows you to set the default calendar type via system property? I.e., could you pass a system property on the command line to configure the desired calendar type?
(In reply to comment #3) > An alternative solution would be for someone to query the OS to determine the > calendar set by the user at the OS level. That would allow the user to use > their preferred calendar type without duplicating the OS-level preference in > Eclipse. > > I don't think this will be addressed at the Equinox level since we have no > dependency on or knowledge of ICU4J. However, I will leave this here until we > find a better home for it. > I agree this should not be solved at the equinox level. A command line solution does not mean it has to live in Equinox. The workbench can also read command line options and set the calendar appropriately. Hopefully the OS can be queried instead of inventing a duplicate option.
The OS cannot be queried (at least not without native code). I would expect we would set the Calendar at the same place we set the Locale (Platform/Runtime, maybe?). A command line option would mean that it could be configured in the eclipse.ini (but not programmatically). A preference would mean potentially runtime configurability (I assume these things can be swapped out at runtime) but that overriding the default behaviour would mean something along the lines of plugin_customization.ini. At least one open question: Is setting a Calendar for a specific locale only supported in ICU4J? That would make this much more problematic. I'll endevour to find that information. PW
In response to question: "Is setting a Calendar for a specific locale only supported in ICU4J?" No. Java allows this specification as well. The method getInstance mentioned earlier which retrieves an instance of a Calendar for specific locale is available in both Java and ICU4J. In ICU4J you have following 2 methods: * public static com.ibm.icu.util.Calendar getInstance(Locale aLocale) * public static com.ibm.icu.util.Calendar getInstance(ULocale locale) In Java you have following method: * public static java.util.Calendar.Calendar getInstance(Locale aLocale) In response to comment: "An alternative solution would be for someone to query the OS to determine the calendar set by the user at the OS level. That would allow the user to use their preferred calendar type without duplicating the OS-level preference in Eclipse." I must misunderstand something, but it seems that the language option is also duplicated. Eclipse can inherit it from OS and it also supports explicit specification via -nl command line option.
(In reply to comment #7) > No. Java allows this specification as well. The method getInstance mentioned > earlier which retrieves an instance of a Calendar for specific locale is > available in both Java and ICU4J. > In ICU4J you have following 2 methods: > * public static com.ibm.icu.util.Calendar getInstance(Locale aLocale) > * public static com.ibm.icu.util.Calendar getInstance(ULocale locale) So that means that Locale supports the same specification? Locale mylocale = new Locale("fr@collation=phonebook;calendar=islamic-civil"); > I must misunderstand something, but it seems that the language option is also > duplicated. Eclipse can inherit it from OS and it also supports explicit > specification via -nl command line option. Both of those work for locale because it is information that is available from both the JVM and via the command line. Overriding the locale calendar on the command line seems feasible if we can do it so that it doesn't break the RCP case that doesn't use ICU4J. But there's no OS way to specify "override the locale calendar" that the JVM can see (without writing native code), and John is saying it's still a potential problem to be solved, but Equinox will not be solving it. PW
Constructors of Locale in Java and ULocale in ICU4J accepting one parameter of type String are different in the sense that they expect different strings: public java.util.Locale(String language) language is a lowercase two-letter ISO-639 code. public com.ibm.icu.util.ULocale(String localeID) Construct a ULocale from a RFC 3066 locale ID. In other words, Locale mylocale = new Locale("fr@collation=phonebook;calendar=islamic-civil"); will not work. Please notice that Java does not support any calendar except for Gregorian calendar (java.util.GregorianCalendar). Consequently there is no sense to support RFC 3066 locale ID in Java Locale class. I think I understand your concern regarding RCP. However, please notice that not only RCP does not use ICU4J but also not all core Eclipse components are making use of ICU4J (in the context of locale/calendar/date formatting). For example, while PropertiesDialog & Properties view use ICU4J, LogEntry & LogViewLabelProvider don't use it. Thus I believe the solution for this defect should be realized only in the storage of calendar related information in Eclipse. This information can be later on utilized by those Eclipse components which do make use of ICU4J. In other words, there is no need to initialize any objects (like new ULocale("fr@c ...")) based on the calendar info, since not all components will be able to use them (because they don't use ICU4J and thus can't use ULocale). It seems that in light of concerns for backward/RCP compatibility we have 2 options: 1. Provide additional command line parameter specific for calendars 2. Develop native code (specific for each platform) which would retrieve calendar information from OS level. In both cases the retrieved information can be normalized to the way ICU4J understands it (RFC 3066 locale ID) and stored as a string. Can you please let me know which direction you believe is more promising one for resolution of this defect ?
(In reply to comment #9) > Constructors of Locale in Java and ULocale in ICU4J accepting one parameter of > type String are different in the sense that they expect different strings: > public java.util.Locale(String language) > language is a lowercase two-letter ISO-639 code. > public com.ibm.icu.util.ULocale(String localeID) > Construct a ULocale from a RFC 3066 locale ID. > In other words, > Locale mylocale = new > Locale("fr@collation=phonebook;calendar=islamic-civil"); > will not work. This is correct. > Please notice that Java does not support any calendar except for > Gregorian calendar (java.util.GregorianCalendar). This is not true. Java supports Thai Buddhist Calendar and Japanese Calendar. When you use Thai locale (new Locale("th", "TH")), Calendar#getInstance returns a Buddhist calendar. Also for Japanese locale with a variant "JP" (new Locale("ja", "JP", "JP") returns a Japanese calendar instance. > Consequently there is no > sense to support RFC 3066 locale ID in Java Locale class. Java Locale is based on the old language tag standard - RFC3066. @collation=phonebook is used by Unicode Locale Identifier (CLDR/LDML) and not supported by Java Locale (at least for now). > I think I understand your concern regarding RCP. However, please notice that > not only RCP does not use ICU4J but also not all core Eclipse components are > making use of ICU4J (in the context of locale/calendar/date formatting). For > example, while PropertiesDialog & Properties view use ICU4J, LogEntry & > LogViewLabelProvider don't use it. > Thus I believe the solution for this defect should be realized only in the > storage of calendar related information in Eclipse. This information can be > later on utilized by those Eclipse components which do make use of ICU4J. > In other words, there is no need to initialize any objects (like > new ULocale("fr@c ...")) based on the calendar info, since not all components > will be able to use them (because they don't use ICU4J and thus can't use > ULocale). > It seems that in light of concerns for backward/RCP compatibility we have 2 > options: > 1. Provide additional command line parameter specific for calendars > 2. Develop native code (specific for each platform) which would retrieve > calendar information from OS level. > In both cases the retrieved information can be normalized to the way ICU4J > understands it (RFC 3066 locale ID) and stored as a string. > Can you please let me know which direction you believe is more promising one > for resolution of this defect ? ICU4J supports 12 calendar types in the latest release, but it does not support all calendar types supported by the latest Microsoft Windows version. Also, another possible approach is to use com.ibm.icu.util.GlobalizationPreference. This class itself does nothing much. It just define a framework which can be used for supporting system/user specific globalization preferences. If i18n service class consumers are creating an i18n service object (such as DateFormat, Collator, Calendar...) through this framework, you can provide consistent globalization support across components.
Since command line option does not seem to be the best way to go (since it would duplicate OS-level preference in Eclipses), the only option we have is to retrieve calendar preference info from OS level. I opened a separate bug 255527 for API which would allow Eclipse developers retrieve user calendar preference from OS. This defect can be used for discussion on how this (retrieved user calendar preference) information can be used in most general way inside Eclipse itself (i.e. via com.ibm.icu.util.GlobalizationPreference).
Assuming an API for retrieving user calendar preference from OS level is provided via bug 25527 (i.e. getUserCalendarPreference), it can be used as follows: ULocale myLocale = ULocale.forLocale(Locale.getDefault()); myLocale = myLocale.setKeywordValue("calendar", getUserCalendarPreference()); com.ibm.icu.util.Calendar myCal = com.ibm.icu.util.Calendar.getInstance(myLocale); GlobalizationPreferences myPreferences = new GlobalizationPreferences(); myPreferences.setLocale(myLocale); myPreferences.setCalendar(myCal); This code assumes that getUserCalendarPreference function returns user calendar preference in the format of ICU4J calendar keyword (i.e. "buddhist", "chinese", "coptic", "ethiopic", "gregorian", "hebrew", "islamic", "islamic-civil", "japanese", and "roc"). Later on, the GlobalizationPreferences object can be used for formatting dates using a code similar to the following one: com.ibm.icu.text.SimpleDateFormat SDF = new com.ibm.icu.text.SimpleDateFormat( "EEEE dd MMMM YYYY" , myLocale); System.out.println(SDF.format((myPreferences.getCalendar()).getTime())); The produced output will be affected by the OS level user calendar preference.
According to comment #1 calendar information can be passed to ICU4J via argument of ULocale class: ULocale mylocale = new ULocale("fr@collation=phonebook;calendar=islamic-civil"); Can we simply extend the range of valid values for -nl command line parameter by covering format understandable by ICU4J ? We don't need to initialize any ICU4J classes (this is even not possible for RCP which don't use ICU4J). Instead we can simply store all parameters coming after @ (i.e. collation=phonebook;calendar=islamic-civil") as a String (without interpreting them or initializing any ICU4J classes). When a component making use of ICU4J wishes to format a date, it can use those additional configuration parameters (i.e. via initialization of appropriate ICU4J classes). What I suggest is as follows: 1. Support extended range of values for -nl command line parameter: eclipse.exe -nl en_US@calendar=japanese 2. Enhance parsing of command line parameter and store the portion of -nl parameter value which appears after @. This portion is stored as String. 3. Each component using ICU4J may take advantage of those additional configuration parameters (which appear after @) for date formatting. Do you believe the suggested approach is acceptable ?
(In reply to comment #13) > > Do you believe the suggested approach is acceptable ? That sounds in line with what we could get in in 3.5, if contributed. It looks like org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo.setupSystemContext() is our starting point for getting -nl information into the Locale (parsed in org.eclipse.core.runtime.adaptor.EclipseStarter.processCommandLine(String[])) Probably using ULocale to set the default locale (which would allow the ULocale to have the specified calendar information, although Locale would not) would provide that information to ICU aware methods. PW
(In reply to comment #14) > (In reply to comment #13) > > > > Do you believe the suggested approach is acceptable ? > > That sounds in line with what we could get in in 3.5, if contributed. It looks > like > org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo.setupSystemContext() > is our starting point for getting -nl information into the Locale (parsed in > org.eclipse.core.runtime.adaptor.EclipseStarter.processCommandLine(String[])) > > Probably using ULocale to set the default locale (which would allow the ULocale > to have the specified calendar information, although Locale would not) would > provide that information to ICU aware methods. > > PW > I'm willing to add parsing to EclipseEnvironmentInfo.setupSystemContext() (contributions welcome). But what would the framework actually do with the information. The Framework (org.eclise.osgi) cannot depend on ICU. If all we are doing is parsing it and storing it into another configuration property (e.g osgi.calendar) then it seems like a separate command line parameter would be better (e.g -cal ) (In reply to comment #13) > What I suggest is as follows: > 1. Support extended range of values for -nl command line parameter: > eclipse.exe -nl en_US@calendar=japanese > 2. Enhance parsing of command line parameter and store the portion of -nl > parameter value which appears after @. This portion is stored as String. Where is this String stored? As a configuration property? > 3. Each component using ICU4J may take advantage of those additional > configuration parameters (which appear after @) for date formatting. This sounds far reaching. How many places would have to be changed to understand the new calendar configuration?
(In reply to comment #15) > I'm willing to add parsing to EclipseEnvironmentInfo.setupSystemContext() > (contributions welcome). But what would the framework actually do with the > information. The Framework (org.eclise.osgi) cannot depend on ICU. If all we > are doing is parsing it and storing it into another configuration property (e.g > osgi.calendar) then it seems like a separate command line parameter would be > better (e.g -cal ) That might be a better option than enhancing -nl: -icu collation=phonebook;calendar=islamic-civil This information can be used by anybody that needs to call ULocale.setDefault(*). So if it is a completely separate argument, there wouldn't be anything that said it *had* to be done in EclipseEnvironmentInfo (although if that's what it takes to make it available to all RCP apps then it would probably be a good idea). What would be important is the time between EclipseEnvironmentInfo and the code that sets the ULocale should be very small. PW
In reply to comment #15: " ... If all we are doing is parsing it and storing it into another configuration property ..." - Yes, this is all what is planned to be done. "... This sounds far reaching. How many places would have to be changed to understand the new calendar configuration? ..." - This really depends on the functionality / needs of specific component/plugin. If a culturally sensitive date formatting is required for certain component/plugin, this information would be very helpfull. I am aware of at least one Eclipse based component which for sure requires it - BIRT.
Here is the list of suggested code changes: 1) An additional optional parameter - "-icu" - should be allowed in the: * eclipse.ini * command line This additional optional parameter accepts an optional list of ULocale's keywords together with their values as described in http://icu-project.org/userguide/locale.html article (see sections "Keywords" and "Examples"). For example: -icu collation=phonebook;calendar=islamic-civil;currency=USD 2) Introduce into config.ini optional property "eclipse.icu" accepting the same range of values (as described above). The value of "eclipse.icu" property may be used as user's default instead of system's default and should have priority lower, than that of command line parameter. 3) Change method EclipseEvironmentInfo.setAllArgs() as follow: public static void setAllArgs(String[] allArgs) { if (EclipseEnvironmentInfo.allArgs == null) { EclipseEnvironmentInfo.allArgs = allArgs; for (int i=0; i<allArgs.length-1; i++) { if (allArgs[i].equals("-icu")) { FrameworkProperties.setProperty("eclipse.icu", allArgs[i+1]); return; } } } } 4) Add the new method to Platform as follows: public static String getIcuParameters() { String icuParams = PlatformActivator.getContext().getProperty("eclipse.icu"); if (icuParams == null) return null; return getNL() + "@" + icuParams; } Please notice following points: a. The value returned by getIcuParameters can be used for initialization of ULocale class. b. There is no need to parse the value of new property, since it is meant to be used as-is for direct initialization of ULocale class (which will do internal parsing and validation itself). c. In the suggested code above no ICU objects are created / initialized using new property. Thus the code above is safe to be part of those Eclipse based applications which don't come with ICU4J.
In the code snipped below we illustrate how potentially a component interested in date formatting sensitive to national preferences can take advantage of the change suggested in comment #18. Below is the code from method IDEResourceInfoUtils.getDateStringValue(), where suggested changes may be used (supposing that com.ibm.icu.util.ULocale is additionally imported): ... import com.ibm.icu.text.DateFormat; import com.ibm.icu.util.ULocale; ... if (info.exists()) { String icuParams = Platform.getIcuParameters(); DateFormat format = icuParams == null? DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.MEDIUM) : DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.MEDIUM, new ULocale(icuParams)); return format.format(new Date(info.getLastModified())); } ... Please notice that we don't allude that this specific component which was used here for illustrative purposes must take advantage of the new feature. It was selected simply because it already uses ICU4J for date formatting and since it was relatively easy to demostrate the new feature in it's context. PS. The code above originally looked as follows: ... import com.ibm.icu.text.DateFormat; ... if (info.exists()) { DateFormat format = DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.MEDIUM); return format.format(new Date(info.getLastModified())); } ...
Created attachment 121280 [details] Last modified date of file formatted using Hebrew national calendar As a result of these changes and using "–icu calendar=hebrew" in the command line or "eclipse.icu= calendar=hebrew" in the config.ini file we can see in the properties view the following info about some selected file.
Created attachment 121281 [details] Last modified date of file formatted using Islamic calendar As a result of these changes and using "–icu calendar=islamic" in the command line or "eclipse.icu= calendar=islamic" in the config.ini file we can see in the properties view the following info about some selected file.
Created attachment 121282 [details] Last modified date of file formatted using default (Gregorian for English locale) calendar As a result of these changes and without any additional parameters we can see in the properties view the following info about some selected file.
(In reply to comment #18) > Here is the list of suggested code changes: > Could you attach a patch? > 1) An additional optional parameter - "-icu" - should be allowed in the: > * eclipse.ini > * command line > This additional optional parameter accepts an optional list of ULocale's > keywords together with their values as described in > http://icu-project.org/userguide/locale.html article (see sections "Keywords" > and "Examples"). > For example: -icu collation=phonebook;calendar=islamic-civil;currency=USD > Should we make the parameter more specific than simply -icu? Would it be better to call the optional parameter -nlKeywords instead of -icu > 2) Introduce into config.ini optional property "eclipse.icu" accepting the same > range of values (as described above). The value of "eclipse.icu" property may > be used as user's default instead of system's default and should have priority > lower, than that of command line parameter. Same comment as above. I think this property should have a relationship with the "osgi.nl" property. Perhaps "osgi.nl.keywords" > > 3) Change method EclipseEvironmentInfo.setAllArgs() as follow: > > public static void setAllArgs(String[] allArgs) { > if (EclipseEnvironmentInfo.allArgs == null) { > EclipseEnvironmentInfo.allArgs = allArgs; > > for (int i=0; i<allArgs.length-1; i++) { > if (allArgs[i].equals("-icu")) { > FrameworkProperties.setProperty("eclipse.icu", allArgs[i+1]); > return; > } > } > } > } This should likely be done in: org.eclipse.core.runtime.adaptor.EclipseStarter.processCommandLine(String[]) And it should likely consume the -nlKeywords (or -icu) argument so it is not included in the application arguments. This is similar to the -nl option. > > 4) Add the new method to Platform as follows: > > public static String getIcuParameters() { > String icuParams = > PlatformActivator.getContext().getProperty("eclipse.icu"); > if (icuParams == null) > return null; > return getNL() + "@" + icuParams; > } method should be something like "getNLKeywords()". I'm not sure if we should concat getNL with the keywords for the caller. Perhaps there is a need to only get the keywords? > > Please notice following points: > > a. The value returned by getIcuParameters can be used for initialization of > ULocale class. If getNLKeywords only returned the keywords then the callers would have to do the concatenation themselves. > b. There is no need to parse the value of new property, since it is meant to be > used as-is for direct initialization of ULocale class (which will do internal > parsing and validation itself). > c. In the suggested code above no ICU objects are created / initialized using > new property. Thus the code above is safe to be part of those Eclipse based > applications which don't come with ICU4J. > Browsing RFC 3066 I don't see any mention of the keywords syntax. The ULocale javadoc mentions that it parses RFC 3066 language identifiers but it seems to also support its own enhanced format for keywords. We need to be able to document this option clearly. It would be nice if we could simply state that the -nlKeywords use the RFC 3066 syntax for specifying keywords form language identifiers. Unfortunately I don't think this is true. We will have to mention ICU in the documentation of this command option and point to some ICU documentation to explain it.
(In reply to comment #23) > Browsing RFC 3066 I don't see any mention of the keywords syntax. The ULocale > javadoc mentions that it parses RFC 3066 language identifiers but it seems to > also support its own enhanced format for keywords. We need to be able to > document this option clearly. It would be nice if we could simply state that > the -nlKeywords use the RFC 3066 syntax for specifying keywords form language > identifiers. Unfortunately I don't think this is true. We will have to > mention ICU in the documentation of this command option and point to some ICU > documentation to explain it. The syntax used by ULocale is equivalent to "Unicode Locale Identifier" defined by Unicode TR#35 - http://www.unicode.org/reports/tr35/ RFC3066 is out of date and updated by RFC4646 (a part of BCP47). Unicode TR#35 defines the mapping between Unicode Locale Identifier and BCP47 language tag. Unicode CLDR working group is planning to register a letter for language tag extension representing keyword values in Unicode Locale Identifier. For your purpose, I would suggest you to simply refer "Unicode Locale Identifier" in TR#35. ICU development team is currently working with Unicode CLDR working group to clean up some terminology, definition of mappings. At the same time, we'll clean up some documentations in ICU.
We will rework the code and provide the patch based on the suggestions in comment #23. In addition, I would like to clarify a little bit more what we probably need to mention in the documentation. The discussion on this started in comment #23 and continued in comment #24. According to http://www.unicode.org/reports/tr35/: "...A Unicode locale identifier is composed of a Unicode language identifier plus (optional) locale extensions...". unicode_locale_id := unicode_language_id (unicode_locale_extensions)? Via -nlKeywords argument/property we plan to pass only Unicode locale extensions (unicode_locale_extensions). According to http://www.unicode.org/reports/tr35/ Unicode locale extensions (unicode_locale_extensions) have following syntax: unicode_locale_extensions := "@" key "=" type (";" key "=" type )* Possible values for "key" and "type" appear in Section 3 (Unicode Language and Locale Identifiers), in table "Key/Type Definitions" at: http://www.unicode.org/reports/tr35/. So, strictly speaking we would refer potential user in the documentation to "Unicode locale extensions of Unicode locale identifier" (instead of Unicode locale identifier). PS. Please notice that Unicode locale identifier includes Unicode language identifier and optional Unicode locale extensions. unicode_locale_id := unicode_language_id (unicode_locale_extensions)? Since Unicode language identifier can be provided via -nl argument/property it does not make sense to duplicate it's specification via -nlKeywords argument/property. Consequently via -nlKeywords argument/property we pass only Unicode locale extensions (without Unicode language identifier). This is the reason why we need to concatenate values of both arguments/properties (i.e. getNL() + "@" + getNLKeywords()) for initialization of ULocale.
(In reply to comment #25) OK, this makes sense to me. Please push back if the configuration options/properties/method names do not make sense (-nlKeywords osgi.nl.keywords getNLKeywords() etc.). You all are the experts WRT the various RFCs and Unicode CLDR working group. I think it would be best to keep icu out of the names.
(In reply to comment #25) > According to http://www.unicode.org/reports/tr35/: "...A Unicode locale > identifier is composed of a Unicode language identifier plus (optional) locale > extensions...". > unicode_locale_id := unicode_language_id (unicode_locale_extensions)? > > Via -nlKeywords argument/property we plan to pass only Unicode locale > extensions (unicode_locale_extensions). > > According to http://www.unicode.org/reports/tr35/ Unicode locale extensions > (unicode_locale_extensions) have following syntax: > unicode_locale_extensions := "@" key "=" type (";" key "=" type )* > Possible values for "key" and "type" appear in Section 3 (Unicode Language and > Locale Identifiers), in table "Key/Type Definitions" at: > http://www.unicode.org/reports/tr35/. > Thinking a bit more on this. Perhaps the names should be -nlExtensions, osgi.nl.extensions and getNLExtensions(). Also we should consider documenting the format of the option to include the preceding "@" just like the syntax for unicode_locale_extensions above. We could do a sanity check to make sure the value starts with a "@". For example: eclipse -nl en_US -nlExtensions "@collation=phonebook;calendar=islamic-civil;currency=USD" This way callers don't need to worry about the extension delimiter (i.e getNL() + getNLKeywords()). I also think that getNLExtensions() should return empty string when no option is specified. This way the code in comment 19 could look like this ... import com.ibm.icu.text.DateFormat; import com.ibm.icu.util.ULocale; ... if (info.exists()) { DateFormat format = DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.MEDIUM, new ULocale(Platform.getNL() + Platform.getNLExtensions)); return format.format(new Date(info.getLastModified())); }
Created attachment 121481 [details] Compressed file including patches for relevant source files In the attachment to this note (patches.zip file) you will find patches for EclipseStarter.java and Platform.java, containing suggested changes. It also includes patch for org.eclipse.ui.ide, needed to demonstrate these changes in the resource info. The code in the patches reflects the changes suggested in comment #23 and in comment #27. Here is the summary of suggested changes: 1. Introduce new command line property -nlExtensions 2. Introduce into config.ini optional property osgi.nl.extensions 3. The initialization is done in: org.eclipse.core.runtime.adaptor.EclipseStarter similarly to the -nl option. 4. Create a new method getNLExtensions() which returns the value of new property. It returns only actual value provided via -nlExtensions or/and via osgi.nl.extensions. In case user does not specify any value it returns an empty string. It also checks if actual value starts with "@", and prepend it with "@", if needed. 5. The usage is exactly as described in comment #27
Created attachment 121551 [details] Workbench sets locale v01 What about setting the ULocale with the extension in the createAndRunWorkbench(*) method, instead of trying to modify users of the ICU API. That way all plugins using the ICU text methods will pick up the extension for free, and it won't effect anybody not using ICU. This only works with a slight mod to ULocale#setDefault(ULocale): public static synchronized void setDefault(ULocale newLocale){ Locale.setDefault(newLocale.toLocale()); defaultLocale = newLocale.toLocale(); defaultULocale = newLocale; } PW
(In reply to comment #29) > Created an attachment (id=121551) [details] > Workbench sets locale v01 > What about setting the ULocale with the extension in the > createAndRunWorkbench(*) method, instead of trying to modify users of the ICU > API. That way all plugins using the ICU text methods will pick up the > extension for free, and it won't effect anybody not using ICU. > This only works with a slight mod to ULocale#setDefault(ULocale): > public static synchronized void setDefault(ULocale newLocale){ > Locale.setDefault(newLocale.toLocale()); > defaultLocale = newLocale.toLocale(); > defaultULocale = newLocale; > } > PW Paul contacted me that ULocale returned by ULocale#getDefault() is missing keywords even they are supplied in ULocale#setDefault(ULocale). This is a bug in ICU 3.8/4.0 - http://bugs.icu-project.org/trac/ticket/6672 I'll fix the problem in 4.0 maintenance stream and will be included in the ICU4J 4.0.1 Eclipse plug-in version.
Comment on attachment 121481 [details] Compressed file including patches for relevant source files I released the EclipseStarter portion of this patch to org.eclipse.osgi.
Created attachment 122573 [details] Cleaned up platform portion of above patch I have cleaned up the patch on Platform a bit: - Moved implementation to InternalPlatform to be consistent with other methods - Added some doc about what this means (referenced Unicode standard doc)
Generalizing the title a bit, since this bug is no longer just about calendar support, but a general enhancement for passing through Unicode locale extension attributes.
Released the org.eclipse.core.runtime portion of these changes to HEAD. Paul, the remaining two pieces are yours. Make sure you update the version range for org.eclipse.core.runtime on your side because of the dependency on the new API.
Created attachment 122878 [details] Workbench sets locale v02 Patch updated to use org.eclipse.core.runtime 3.5.0 This won't work quite right in M5 until the fix for http://bugs.icu-project.org/trac/ticket/6672 in ICU 4.0.1 (targeted for M6), but I've confirmed that it works with the fix. PW
(In reply to comment #35) > Created an attachment (id=122878) [details] > Workbench sets locale v02 > Released to HEAD >20090118 PW
(In reply to comment #35) > Created an attachment (id=122878) [details] > Workbench sets locale v02 > > Patch updated to use org.eclipse.core.runtime 3.5.0 > > This won't work quite right in M5 until the fix for > http://bugs.icu-project.org/trac/ticket/6672 in ICU 4.0.1 (targeted for M6), > but I've confirmed that it works with the fix. > > PW > What is the orbit bug we can depend for upgrading to ICU 4.0.1?
(In reply to comment #37) > What is the orbit bug we can depend for upgrading to ICU 4.0.1? > I don't have an eclipse bug, yet, just the CQ ... http://dev.eclipse.org/ipzilla/show_bug.cgi?id=2970 PW
Removing the dependancy on bug 255527 since and explicit configuration option is provided via resolution of this bug (and thus we don't need an implicit inheritance from OS level suggested in bug 255527).
I think we have released all the code in eclipse to handle this. Just leaving open to track when the new ICU4J drops since that is required to get this working.
*** Bug 263143 has been marked as a duplicate of this bug. ***
Fixed in I20090211-0900 PW
Created attachment 125735 [details] Works fine with N20090214-20000 build
Created attachment 125736 [details] Date formatted with Islamic calendar in Arabic locale The results when following command line parameters were used: -nl ar -dir ltr -nlExtensions calendar=islamic
Created attachment 125737 [details] Date formatted with Islamic calendar in Hebrew locale The results when following command line parameters were used: -nl he -dir ltr -nlExtensions calendar=islamic
Created attachment 125739 [details] Date formatted with Islamic calendar in Russian locale The results when following command line parameters were used: -nl ru -dir ltr -nlExtensions calendar=islamic
Created attachment 125740 [details] Date formatted with Hebrew calendar in Russian locale The results when following command line parameters were used: -nl ru -dir ltr -nlExtensions calendar=hebrew
Closing.
Created attachment 125927 [details] Works fine with N20090214-2000 version
Created attachment 126001 [details] Date formatted using Islamic calendar in Arabic locale Result of date formatting when following command line parameters were used: -nl ar -dir ltr -nlExtensions calendar=islamic
Created attachment 126002 [details] Date formatted using Islamic calendar in Hebrew locale Result of date formatting when following command line parameters were used: -nl he -dir ltr -nlExtensions calendar=islamic
Created attachment 126003 [details] Date formatted using Islamic calendar in Russian locale Result of date formatting when following command line parameters were used: -nl ru -dir ltr -nlExtensions calendar=islamic
Created attachment 126005 [details] Date formatted using Hebrew calendar in Russian locale Result of date formatting when following command line parameters were used: -nl ru -dir ltr -nlExtensions calendar=hebrew
Works fine with N20090214-2000 version
