Internationalization proposal: some comments...
Just a small correction, the strawman proposal is actually at strawman:i18n_api.
- The Locale class should have a matches() method or methods that permit locale/language negotiation to be implemented. RFC 4647 matching (either filtering or lookup) are far more common than pure equality checks.
I'll look into this. Thanks for pointing this out.
Should there be a Locale.getDefault?
Should there be a TimeZone.getDefault()?
I'll add them to the proposal.
- The Collator doesn't include rule-based collation? Is that planned for the future?
Rule based collation is available for ICU only (as far as I know). We would need to get into agreement of rule format before we would add it to the API. And I am not sure there is a high demand for it, so it can be skipped for now.
- I know that other APIs are planned for the future, but message and number
format are equally (often more) important than dates. I wouldn't want them omitted in an initial implementation.
We will add number/currency formatting, we just felt it would clutter the proposal at this stage. As for message formatting and plural handing:
- Placeholder replacement in messages is pretty simple to implement in Javascript as it doesn't require any data or complex algorithms, but it could be part of the API.
- Plural handling is a harder problem. We would need to agree on the format for the messages to be passed to the plural formatter, which may take long time.
So we could add simple placeholder replacement method to the API, but without plural handling.
- The Collator doesn't include rule-based collation? Is that planned for the future?
Rule based collation is available for ICU only (as far as I know). We would need to get into agreement of rule format before we would add it to the API. And I am not sure there is a high demand for it, so it can be skipped for now.
AP> One thing I commonly do is modify the default collation to pay attention to spaces in (for example) book titles—the default collation ignores spaces. I’ll admit that usually rule-based collator is a low-demand feature, but when you need it, it is really handy.
- I know that other APIs are planned for the future, but message and number format are equally (often more) important than dates. I wouldn't want them omitted in an initial implementation.
We will add number/currency formatting, we just felt it would clutter the proposal at this stage. As for message formatting and plural handing:
- Placeholder replacement in messages is pretty simple to implement in Javascript as it doesn't require any data or complex algorithms, but it could be part of the API.
AP> Placeholder replacement is simple. What’s more interesting is the ability to format the placed value (Object->String transition). MessageFormat in ICU (Java or C) provides a convenient way to control the formatter used when placing an object into a string, and in a detailed way without much---sometimes any---code. It isn’t MessageFormat per-se that’s the issue, it’s marshalling of the underlying formatters.
- Plural handling is a harder problem. We would need to agree on the format for the messages to be passed to the plural formatter, which may take long time.
AP> It requires some thought, yes. But it is a common problem and should be worked on. Isn’t this what strawmen are for anyway? If nobody objects, they’ll get whatever design is provided :-). I mention message and plural handling together because they are often used together. A design that does both would be nice.
Best ,
Addison
Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs)
Internationalization is not a feature. It is an architecture.
- I've added a reference to RFC 4647, and extended constructor to allow lookup. I'll try to make it more strict. 2,3. Locale.getDefault() is not necessary, since we get the default if caller passes * for locale. Same for TimeZone - if caller passes empty time zone parameter we return default zone.
I reviewed the thread at [1] and wanted to contribute a few comments on the strawman proposal at [2].
I think this effort is important. Many of us have struggled with the lack of ready internationalization support within ECMAScript and server-side or custom processing are both unsatisfying as a solution. During the W3C TPAC last year, some of us interested in this problem met with TC39 and made a number of suggestions [3] that I hope will be taken up for consideration---some of these are covered by this proposal.
WRT the strawman, I had these comments:
The Locale class should have a matches() method or methods that permit locale/language negotiation to be implemented. RFC 4647 matching (either filtering or lookup) are far more common than pure equality checks.
Should there be a Locale.getDefault?
Should there be a TimeZone.getDefault()?
The Collator doesn't include rule-based collation? Is that planned for the future?
I know that other APIs are planned for the future, but message and number format are equally (often more) important than dates. I wouldn't want them omitted in an initial implementation.
I hope to see progress on this work in the future.
,
Addison
[1] esdiscuss/2010-June/011380 [2] docs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Ro&hl=en [3] www.w3.org/International/wiki/JavaScriptInternationalization
Addison Phillips
Internationalization is not a feature. It is an architecture.