On Nov 16, 2011, at 5:19 PM, Waldemar Horwat wrote: > 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 codesearch.google.com 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. > Argument over whether Map.prototype is a Map. We want to avoid the mess > caused by Date.prototype being a Date (MarkM: It provides a hidden > communication channel that cannot be frozen). The ES.next plan is to expose Date's internal [[PrimitiveValue]] property by a private-name-object key, so it can be prototype-delegated. This enables Mark's SES to freeze the @primitiveVaueKey directly via Object.defineProperty, even though Object.freeze skips private properties (per last TC39 meeting). This approach can be used for other built-in constructor prototypes with mutable internal properties. > DaveH: Use === or egal? Distinguishing ±0 as separate slots in a Map or Set > will confuse users. > MarkM: What about defineOwnProperty? Same problem would appear there. I suggested making a parameter (with a sane default value) to the Map and Set constructors by which the user could customize the e.r. used to partition mapped keys or values into equivalence classes. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
