ICU4N icon indicating copy to clipboard operation
ICU4N copied to clipboard

Complete UCultureInfo Implementation

Open NightOwl888 opened this issue 4 years ago • 0 comments

In #3, a UCutureInfo type was created to replace the ICU4J ULocale type. The main goals for doing this are:

  1. To provide a similar API as the CultureInfo class
  2. To provide a way to set the culture/default culture of the current thread
  3. To fill gaps in behavior between ICU and the .NET platform

We managed to get a prototype in place, but there are still some remaining tasks and research to complete.

Known Issues

  • [ ] TwoLetterISOLanguageName/GetTwoLetterISOLanguageName returns null for invariant culture, which is different than the documented behavior of ICU4J (at least for the 3 letter language), which is to return empty string. In .NET, the behavior is to return the string "iv".
  • [ ] The Parent property behaves differently in than the .NET platform. In ICU, the script tag is not considered as part of the fallback behavior, but in .NET it is (i.e. uz_Cyrl_UZ falls back to uz_Cyrl in .NET, but in ICU it falls back to uz). The AcceptLanguage overloads of UCultureInfo depend on the current behavior for the tests to pass. For now, Parent has been marked internal until this can be addressed.
  • [ ] The default behavior of CurrentCulture and CurrentUICulture when not explicitly set is to track the properties of the CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture. So, when either of the latter changes, the former are automatically updated to the nearest corresponding culture. If set explicitly, this tracking stops and the culture that is set is used instead. However, once set there is currently no way to "unset" UCultureInfo.CurrentCulture or UCultureInfo.CurrentUICulture to get back to the original tracking behavior.
  • [ ] The ULocale class in ICU4J was immutable and its Clone method simply returned itself. However, in .NET UCultureInfo was designed to be mutable unless it is wrapped using the ReadOnly method. For now, UCultureInfo is immutable and marked sealed so the behavior cannot be changed.
  • [ ] Since LCID is not available in the CLDR data and is deprecated, the property has been commented out and none of the method overloads or constructors that utilize it have been added.
  • [ ] The Name property effectively returns the base name in ICU4J. They are similar, however, in .NET they are typically delimited by hyphen and in ICU they are delimited by underscore. Through some limited testing, it appears both UCultureInfo and CultureInfo accept either format. More research is required to determine whether changing to the .NET convention makes sense.
  • [ ] Lack of caching. In ICU4J, static properties for the most commonly used cultures (to match the JDK). In .NET, there are no such properties, but there are methods available to provide read-only cached cultures.

Missing Members of CultureInfo

The following members of CultureInfo are not yet present in UCultureInfo.

Properties

Methods

Missing Members of ULocale

Properties

  • [ ] CharacterOrientation - Marked internal, since the logical place to put it would be on TextInfo
  • [ ] LineOrientation - Marked internal, since the logical place to put it would be on TextInfo
  • [ ] IsRightToLeft - Marked internal, since the logical place to put it would be on TextInfo

API Documentation

  • [ ] Some of the JavaDocs have yet to be converted and other members (including the main class header) have not yet been documented.

UCultureInfoBuilder

  • [ ] UCultureInfoBuilder

ICU4J's ULocale class has a nested Builder class that has been de-nested and marked internal. Its purpose is to safely build a locale object while validating the inputs, as the UCultureInfo class provides no such validation. The CultureInfo class also doesn't provide validation upon creation, but will throw an exception if the requested culture doesn't exist on the platform.

More research is needed to determine if a similar function exists on the .NET platform so we can correctly map this functionality (which does exist on the Java platform) or whether it makes sense to keep it as is and add it to the public API.

NightOwl888 avatar Jun 26 '20 07:06 NightOwl888