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