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: http://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. -Andrew
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
