On Tue, Aug 16, 2011 at 7:57 PM, Norbert Lindenberg < [email protected]> wrote:
> The current specs for the NumberFormat and DateTimeFormat constructors in > the ECMAScript internationalization API provide for 3 (NumberFormat) or 2 > (DateTimeFormat) different ways to specify the desired formats: using style > properties, using skeleton properties, and (for NumberFormat) using > patterns. Skeletons for NumberFormat are awaiting clarification, and Eric > (Microsoft) has proposed an alternative for DateTimeFormat skeletons. > > I've been thinking about how this can be streamlined, and would like to > propose: > > 1) Remove patterns from NumberFormat. I can imagine a few clients for which > patterns would be useful, such as spreadsheet-type applications or > value-added internationalization libraries. However, they require clients to > provide localized patterns, and the number of applications for which this is > both necessary and reasonable is fairly small. Most applications are better > off using styles or skeletons, which let the implementation of the > internationalization API fully take care of localization. (Patterns would > actually be more useful for DateTimeFormat, where the limited number of > supported skeletons will force more clients to roll their own, but there we > don't offer them.) > Maybe we are calling different things patterns, but if I pass in "#,###.00" as the pattern to ICU4J's DecimalFormat, then that will get localized to the proper grouping separator, number of grouping digits, and decimal separator -- the caller doesn't have to localize it at all. I think more applications than you think will want some control over the format pattern -- for example, if I am showing a table of currencies, I probably don't want to include the currency symbol in every cell in the table, but I still want them formatted appropriately for the currency (right number of decimal positions, round to multiple of .05 for CHF, etc). I would argue that patterns are actually less useful in DateTimeFormat, as it encourages developers to do the wrong thing. Ie, if I use "MM/dd/yyyy" as the pattern for DateTimeFormat, then the result will be misleading in locales where such a date would be formatted as "dd/MM/yyyy". I think it would be better to support skeleton patterns instead, where the app asks for a pattern containing numeric days, months and a 4-digit year, and then it gets the proper localized pattern that matches that. The one case where specifying patterns explicitly is useful is compliance with specs - for example, RFC2822 or ISO8601 dates (which also need to force English names in the cae of RFC2822). -- John A. Tamplin Software Engineer (GWT), Google
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
