JDK-5013088 : Restructure java.text and java.util locale data
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-03-13
  • Updated: 2005-04-11
  • Resolved: 2005-04-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b32Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description

Name: nl37777			Date: 03/12/2004

The locale data in the sun.text.resources package contains 
simple translatable strings (the names of languages, countries, and 
time zones) as well as highly structured data (lists of symbols, format 
patterns, localized pattern characters). This has repeatedly caused 
bugs because translators don't know which strings to translate and 
which to leave alone.

To simplify translation, the translatable strings should be moved into 
separate resource bundles that are properties files or simple list 
resource bundles, and the remaining information consolidated into 
LocaleElements. Information about aliases and sort order of time zones 
should be in LocaleElements, not in the bundle containing time zone 
names.

Having the names in flat resource bundles also allows the 
simplification of the name lookup in the Locale class.
======================================================================

Comments
EVALUATION Name: nl37777 Date: 03/12/2004 To be considered for a future release. ====================================================================== The actual implementation went a bit further and restructured the entire java.util and java.text locale data in a more logical fashion. Here's the mapping: Old bundle names: * str.DFZD: sun.text.resources.DateFormatZoneData * str.LE: sun.text.resources.LocaleElements New bundle names: * sur.CD: sun.util.resources.CalendarData * sur.CN: sun.util.resources.CurrencyNames * sur.LN: sun.util.resources.LocaleNames * sur.TZN: sun.util.resources.TimeZoneNames * str.CD: sun.text.resources.CollationData * str.FD: sun.text.resources.FormatData Element mapping: bundle/key[/subKeyOrIndex] -> bundle/key str.DFZD/TimeZoneID -> sur.TZN/TimeZoneID str.DFZD/localPatternChars -> str.FD/DateTimePatternChars str.LE/Languages/iso639Code -> sur.LN/iso639Code str.LE/Countries/iso3166Code -> sur.LN/iso3166Code str.LE/%%EURO -> sur.LN/%%EURO str.LE/%%B -> sur.LN/%%B str.LE/%%NY -> sur.LN/%%NY str.LE/LocaleNamePatterns/0 -> sur.LN/DisplayNamePattern str.LE/LocaleNamePatterns/1 -> sur.LN/ListPattern str.LE/LocaleNamePatterns/2 -> sur.LN/ListCompositionPattern str.LE/MonthNames -> str.FD/MonthNames str.LE/MonthAbbreviations -> str.FD/MonthAbbreviations str.LE/DayNames -> str.FD/DayNames str.LE/DayAbbreviations -> str.FD/DayAbbreviations str.LE/AmPmMarkers -> str.FD/AmPmMarkers str.LE/Eras -> str.FD/Eras str.LE/NumberPatterns -> str.FD/NumberPatterns str.LE/NumberElements -> str.FD/NumberElements str.LE/CurrencySymbols/iso4217Code -> sur.CN/iso4217Code str.LE/DateTimePatterns -> str.FD/DateTimePatterns str.LE/DateTimeElements/0 -> sur.CD/firstDayOfWeek str.LE/DateTimeElements/1 -> sur.CD/minimalDaysInFirstWeek str.LE/CollationElements -> str.CD/Rule ###@###.### 2005-03-31 19:58:01 GMT
31-03-2005