Re: DateTimeFormat property values
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 type="abbreviated"> > 1373 type="sun">dom > .. > 1381 > 1382 draft="contributed">D > .. > 1390 > 1391 type="sun">domingo 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
Re: 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 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? -Andrew On Fri, Mar 1, 2013 at 9:27 AM, Andrew Paprocki wrote: > 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 > 1308 > 1309 > 1310 type="abbreviated"> > 1311 type="1">ene > 1312 type="2">feb > ... > 1324 type="wide"> > 1325 type="1">enero > 1326 type="2">febrero > > 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 type="abbreviated"> > 1373 type="sun">dom > .. > 1381 type="short"> > 1382 type="sun" draft="contributed">D > .. > 1390 > 1391 type="sun">domingo > > 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
