Internationalization proposal: some comments...

Nebojša Ćirić cira at
Thu Jul 22 15:14:25 PDT 2010

> 1. 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.

> 2. Should there be a Locale.getDefault?
> 3. Should there be a TimeZone.getDefault()?

I'll add them to the proposal.

> 4. 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

5. 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

So we could add simple placeholder replacement method to the API, but
without plural handling.

> I hope to see progress on this work in the future.
> Regards,
> Addison
> [1]
> [2]
> [3]
> Addison Phillips
> Internationalization is not a feature.
> It is an architecture.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list