Meeting notes, i18n JS 5/21
cira at google.com
Wed May 23 14:21:03 PDT 2012
Moving content of the doc to email - it's almost the same as the initial
email except for couple of lines at the end.
- We need to get royalty free agreement for Ecma standard at this
meeting or Wednesday
- Discussion/forms on TC39 site
- Introduction of the spec (goals, constraints)
- Locale negotiation, collation, number formatting, date formatting
- More was considered but we had to drop some
- Showing examples on how to use the functionality
- Mentioning JS buitins that use the i18n API (toLocaleString...)
- Negotiation of having Unicode extensions and options
- Options take precedence oved Unicode extensions
- resolvedOptions give you what was resolved in the end
- Implementation dependencies
- Set of supported locales
- Set of supported features per locale
- Collation rules
- Calendars and time zones
- Various formats for numbers and dates
- Allowing for best-fit algorithms where implementations are free to
provide better than default algorithms
- Extensions to the spec are allowed if prefixed by vendor tag
- Testing is hard because of variations in the data and implementations
- Discussion about default behaviours
- Single data source?
- More examples in the spec to make developers life easier
- Allan - 262 doesn’t specify everyting so there is a precedent
- jQuery representative - example of navigator.language across
browsers not being the same (en, en-US, en-us)
- Ritchard - should we focus on each area and see if we can tighten up
- Locale lookup
- Explanation about de-DE vs. de
- Even simple lookup algo. won’t give the same results
- Determinism is an issue en->en-US or en->GB
- Keep the best-fit algorithm as default.
- Loomis: Make it clear in the spec (14.3.1,2,3) that the respecified
functions behave as if the constructors were called with blank locale list
and options (old behaviour is gone).
- Loomis: Add references to third-party implementations to use CLDR or
UCA if don’t have other options.
- Covered spec. update (collation keys removed, using internal Object
- Add v8toLocaleString to v8?
- Remove v8 prefix from the implementation because there is no
- Put it behind a flag?
- Microsoft is continuing in the labs, updated to the current spec,
couple of known limitations, but minor. They are shiming toLocaleString.
TBD for when is it going to be in the browser. No vendor prefix.
- Test suite
- Microsoft medium to long term would add tests
- Google added 35 tests
- Community feedback
- Passing around locale list - default is a problem - where to put it
as a global - spec doesn’t say that default locale can’t change
- Pattern string for date format - postponed for version 2.0
- Allen: should there be a global default at all?
- Intl taking locale list as a parameter? That list would become
default. But constructors are not frequent in the code, format(), compare()
are. And in toLocaleString() is a convenience method, so we don’t worry
much. No need to change the spec.
- ErikMS: List of default locales. Long discussion about merging lists,
what if each service picks different locales? What if locales are not
supported at all? 10.1. could be changed to say it could have 1+ instead of
1 iteam? Should new LocaleList() return empty list? A defaultLocale()
method/static that returns system default list?
- Skeleton string for dates
- Skeleton property maybe? (LDML) - v2.0 with agreement
- Style property (short, long, medium)? - v2.0 with agreement
- Pattern for dates maybe don’t have place in the Intl?
- Moment.js for date formatting (lang files) - http://momentjs.com/
- Date formatting - take a look at the other libraries
- Move numbering system information wrt BCP47/ (move from
supplemental/)? Clarify the status within LDML spec. Leave couple rows in
the table, and point to LDML spec.
- Collator variant name change? Probably good enough.
- List of default locales? Why not have LocaleList() return a list from
- Async issue - not an issue since we have at most 9MB of data total,
which is mostly trimmed down to 1MB, so it won’t block long. Can be
preloaded on server to avoid locale switching.
- Support for most likely subtags - v2.0, covered.
- Options in the resolved locale tag - return information being
supported (and if was asked for). Drop other extensions. If user passes
th only Eric says that we get back -u-nu-thai in addition (a bug).
- Bound format methods - compare is bound others are not. Make format
- resolvedOptions - should we create a new object or allow for cached
value to be returned? Should the object be mutable? Should resolvedOptions
become a method to lower the confusion? Make it a function that returns
a mutable object.
- Lookup algorithm spec change - NOTE -> MUST for zh-TW problem. Make it
a normative must.
- Luke: editorial comment - left for later/es-discuss.
- Alex/Allen: remove LocaleList object and use plain Array.
- 2. Conformance
- What about already defined properties? Can we add new,
implementation specific values, like v8Identical for collator sensitivity?
- We should throw if we don’t recognise the value. You may recognise
additional property values.
- Talk to Patrick to check if the format is conformant to the Ecma
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss