Globalization API - Sample Use Cases
I agree that object literals are more verbose, but they are also more readable. I did hear some complains about formatting strings missing from the latest spec (we had them before), and mostly from people that know how to use them (I still need to look up CLDR docs to write a semi complex one).
The easy solution to that is to add 2 more fields to the options (or have them as separate parameter):
- pattern - as is, I know what I want - MM/yy always generates 9/74 no matter the locale.
- skeleton - MM/yy will get you closest matching pattern for a given locale.
If pattern or skeleton fields are specified, we ignore the rest of the options object.
We had this approach before and removed it from the spec to simplify the API, but it shouldn't be hard to get it back in.
- децембар 2011. 13.28, Nicholas C. Zakas <standards at nczconsulting.com>је написао/ла:
On 12/2/2011 1:35 PM, Nebojša Ćirić wrote:
I agree that object literals are more verbose, but they are also more readable. I did hear some complains about formatting strings missing from the latest spec (we had them before), and mostly from people that know how to use them (I still need to look up CLDR docs to write a semi complex one).
I agree that object literals are more readable. The price you pay for that readability is opacity and many, many characters to get the correct behavior. Also, as mentioned before, it makes externalizing internationalized settings into a configuration file much more complicated.
The easy solution to that is to add 2 more fields to the options (or have them as separate parameter):
- pattern - as is, I know what I want - MM/yy always generates 9/74 no matter the locale.
- skeleton - MM/yy will get you closest matching pattern for a given locale.
If pattern or skeleton fields are specified, we ignore the rest of the options object.
We had this approach before and removed it from the spec to simplify the API, but it shouldn't be hard to get it back in.
I like it. I'd even go one step further to suggest that the first argument be allowed as either a string or an object. If a string, then treat as a pattern, otherwise, treat as an options object.
The easy solution to that is to add 2 more fields to the options (or have them as separate parameter):
- pattern - as is, I know what I want - MM/yy always generates 9/74 no matter the locale.
- skeleton - MM/yy will get you closest matching pattern for a given locale.
If pattern or skeleton fields are specified, we ignore the rest of the options object.
We had this approach before and removed it from the spec to simplify the API, but it shouldn't be hard to get it back in.
I like it. I'd even go one step further to suggest that the first argument be allowed as either a string or an object. If a string, then treat as a pattern, otherwise, treat as an options object.
-N
So treat object as a skeleton*, and string as a plain pattern**? That may be less confusing, and simple in simple case.
-
- implementation picks best appropriate match, uses locale specific delimiters, grouping separators... ** - provide formatting as is (as specified by LDML pattern). No locale data is used (except some delimiters, say . and , for decimal separation).
On 12/6/2011 12:48 PM, Nebojša Ćirić wrote:
The easy solution to that is to add 2 more fields to the options (or have them as separate parameter): 1. pattern - as is, I know what I want - MM/yy always generates 9/74 no matter the locale. 2. skeleton - MM/yy will get you closest matching pattern for a given locale. If pattern or skeleton fields are specified, we ignore the rest of the options object. We had this approach before and removed it from the spec to simplify the API, but it shouldn't be hard to get it back in.I like it. I'd even go one step further to suggest that the first argument be allowed as either a string or an object. If a string, then treat as a pattern, otherwise, treat as an options object. -NSo treat object as a skeleton*, and string as a plain pattern**? That may be less confusing, and simple in simple case.
- implementation picks best appropriate match, uses locale specific delimiters, grouping separators... ** - provide formatting as is (as specified by LDML pattern). No locale data is used (except some delimiters, say . and , for decimal separation).
Precisely.
I don't think a standalone pattern string is sufficient - the pattern doesn't encode all information that the DateTimeFormat needs. In this version of the API, we need at least the timeZone option, in a later version probably also a calendar option.
Norbert
Instead of continuing with the previous thread, I figured it would be easier to start a new one.
One of my main points about the current Globalization API is that the API seems to be designed around complex use cases vs. simple use cases. Whether intentional or unintentional the Globalization API fills two gaps in ECMAScript: number formatting and date formatting. Setting aside the ability to internationalize currencies and dates, this is a capability that has long been missing from ECMAScript and developers will rejoice if/when it arrives.
That being said, I think there's a strong possibility that simple date/number formatting will end up being a popular use case of the API as opposed to those who are actively looking for locale-specific changes due to an internationalized product. I'd venture a guess to say that the common uses would end up being:
I would love it if the ability to format numbers and dates were simpler than currently spec'ed, more specifically, if the object literals could be done away with in favor of formatting strings. Yes, I know formatting strings have some limitations, however the way I have created internationalized applications in the past has been by abstracting out the internationalized parts into configuration files (such as a Java properties file). The data from that could then be passed into a JS API that Did The Right Thing. Formatting strings make this trivial, needing to code up an object literal makes this trickier (JSON is not a great format for config files).
Just a few extra cents.