Re: [icu-design] getLocalPatternChars change

[George R. <gr...@us...>]

Just so people know the scope of the proposal...

This also means that DateFormat::applyLocalizedPattern() and=20
DateFormat::toLocalizedPattern() in ICU4C and ICU4J will now only use the=20
unlocalized format.  This means that ICU will be diverging from Java's=20
current behavior.  If this concerns you, you should speak up now.

So here is existing behavior of a few example locales.

de=5FDE   t. MMMM jjjj
fr=5FFR   j MMMM aaaa
es=5FES   t' de 'MMMM' de 'uuuu

Those date patterns for applyLocalizedPattern and toLocalizedPattern would =

no longer work, and the following patterns would have to be used instead.=20
If you've hard coded something like the above localized patterns into your =

code or resource bundles, they wouldn't work anymore.

de=5FDE   d. MMMM yyyy
fr=5FFR   d MMMM yyyy
es=5FES   d' de 'MMMM' de 'yyyy

George Rhoten
IBM Globalization Center of Competency/ICU  San Jos=E9, CA, USA
http://www.icu-project.org/
http://icu.sourceforge.net/



"Steven R. Loomis" <sr...@ic...>=20
Sent by: icu...@li...
02/08/2007 03:00 PM
Please respond to
icu...@li...


To
icu...@li...
cc

Subject
[icu-design] getLocalPatternChars change






This proposal expires February 22nd, 2007.

Background:

The localized pattern chars  ( such as "j" for year instead of "y" )=20
are being deprecated in CLDR.  The current proposal in CLDR is to=20
remove the localized data from all locales except for root.

Proposal:

DateFormatSymbols::getLocalPatternChars() and=20
DateFormatSymbols.getLocalPatternChars()   [ C++ and Java,=20
respectively ] will no longer load anythiing from resource bundles,=20
but will just return a static string "GyMdkHmsSEDFwWahKzYeugAZvcL..."=20
by default.

( setLocalPatternChars will still function the same way. )