DateTimeFormat property values

Andrew Paprocki andrew at ishiboo.com
Fri Mar 1 06:39:08 PST 2013


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 <andrew at ishiboo.com> 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                        <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130301/523c8f92/attachment.html>


More information about the es-discuss mailing list