Nov 16 meeting notes

Nebojša Ćirić cira at
Thu Nov 17 11:41:03 PST 2011

> > Internationalization presentation.
> >
> > Allen:  Can a web developer reasonably depend on his webapp working the
> same in a given locale on any conforming browser?
> > Answer: No.
> > MarkM: Are there specific areas where it's possible to pin
> implementations down more?
> >
> > Alex:  Wants a way to globally set a default localeList based on
> application-specific data.
> > Long debate.  Not possible as defined currently.  Have the Globalization
> object default to getting a localeList from one of its user-settable
> properties if not provided in a function call?
> > MarkM:  Doesn't want mutable globals (other than ones that are set up
> once and then frozen).
> > Alex:  If you don't allow mutating the default, applications will still
> store the locale in a global and just pass the value of the global to every
> method that takes a locale, resulting in a more wordy program.
> > Waldemar:  Sometimes users will want to change their locale from within
> the application.
> > Waldemar:  While having either a mutable default locale or having no
> default locale would be ok, having a default immutable and
> implementation-dependent locale would be a problem, as it would be hard to
> usefully rely on such a thing.
> >
> > Brendan: Looks like the identifier "Globalization" is used in existing
> JS libraries.  Not sure in what capacity yet.
> I was looking a jquery-ui, whre Globalization appears to be a local var
> name. But there are other hits via to consider.
> I also objected to gunning for early standardization with
> under-specification. ECMA-262 tends to specify for interoperation because
> web content can't choose the browsers it runs in, and fallback is not
> always graceful or even possible.
> Maybe we can get two distinct (not both based on ICU) implementations done
> enough to interop-test by next March. I'm skeptical, and we should commit
> to doing the testing and removing under-specification that will bite
> developers and browser implementors, even if that takes us past next
> Spring's GA.
> The issue of the G11N API being too Java-esque came up. We agreed to
> address it on es-discuss, with TC39ers beyond Allen participating.
I've started two threads on es-discuss, one about the namespace the other
about the API concerns. Thanks for the input.

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

More information about the es-discuss mailing list