DateTimeFormat property values
I found this note later in the spec:
"NOTE It is recommended that implementations use the locale and calendar dependent strings provided by the Common Locale Data Repository (available at cldr.unicode.org), and use CLDR “abbreviated” strings for DateTimeFormat “short” strings, and CLDR “wide” strings for DateTimeFormat “long” strings."
If this is being defined now and doesn't have the burden of breaking existing callers, why change the names in the first place?
On Mar 1, 2013, at 6:39 , Andrew Paprocki wrote:
I found this note later in the spec:
"NOTE It is recommended that implementations use the locale and calendar dependent strings provided by the Common Locale Data Repository (available at cldr.unicode.org), and use CLDR “abbreviated” strings for DateTimeFormat “short” strings, and CLDR “wide” strings for DateTimeFormat “long” strings."
If this is being defined now and doesn't have the burden of breaking existing callers, why change the names in the first place?
We started using narrow/short/long in August 2011, based purely on what makes a good API. TC 39 discussed the alignment with the CLDR keywords in July last year (John Emmons raised the issue at the time), but decided to stick with the current names because CLDR is just an implementation option. As an implementer I found it's not an issue at all because I use CLDR through ICU, so I work with ICU date format skeletons.
Related -- Properties such as "day" only contains values for "2-digit" and "numeric", but CLDR data also provides "abbreviated", "short", and "wide" in the format context:
1372 <dayWidth type="abbreviated"> 1373 <day type="sun">dom</day> .. 1381 <dayWidth type="short"> 1382 <day type="sun" draft="contributed">D</day> .. 1390 <dayWidth type="wide"> 1391 <day type="sun">domingo</day>
The CLDR "day" element corresponds to the ECMA-402 "weekday" component, which does have narrow/short/long.
Curious to hear if there is a reason to stray from the CLDR specification since it appears to be pretty complete for almost any need.
The goal for the API was not to provide direct access to all of CLDR, it was to provide a good API for common internationalization needs. It also had to be implementable on top of different underlying internationalization libraries, not all of which are based on CLDR.
Norbert
Looking at the Internationalization API, I noticed that DateTimeFormat property values don't appear to align with the names that Unicode CLDR data uses. The Unicode CLDR data specifies what format pieces actually look like in every locale, so it would make sense to me to use their names and rely on their data rather than re-inventing the wheel.
For example, in the context of "format" (as opposed to "standalone") month representations in locale "es", this is specified:
unicode.org/cldr/trac/browser/tags/release-22-1/common/main/es.xml
1307 <calendar type="gregorian">
1308 <months>
1309 <monthContext type="format">
1310 <monthWidth type="abbreviated">
1311 <month type="1">ene</month>
1312 <month type="2">feb</month> ... 1324 <monthWidth type="wide">
1325 <month type="1">enero</month>
1326 <month type="2">febrero</month>
Is "abbreviated" in CLDR equivalent to "narrow" or "short" in this spec? It would make more sense to me to adopt the CLDR naming conventions so that implementations can build the Internationalization support on top of the Unicode data.
Related -- Properties such as "day" only contains values for "2-digit" and "numeric", but CLDR data also provides "abbreviated", "short", and "wide" in the format context:
1372 <dayWidth type="abbreviated">
1373 <day type="sun">dom</day> .. 1381 <dayWidth type="short">
1382 <day type="sun" draft="contributed">D</day> .. 1390 <dayWidth type="wide">
1391 <day type="sun">domingo</day>
Curious to hear if there is a reason to stray from the CLDR specification since it appears to be pretty complete for almost any need.