> Support for the normalization property in options and the kk key would become mandatory.
The options that ICU offers are to observe full canonical equivalence: 1. For all locales - kk=true 2. For key locales (where it is necessary); otherwise partial (FCD) - kk=<not present> 3. For no locales; always partial (FCD) - kk=false Your proposal looks reasonable, except I'm not sure how someone would use the kk value to get #2. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Fri, Aug 31, 2012 at 3:30 PM, Norbert Lindenberg < ecmascr...@norbertlindenberg.com> wrote: > I think #2 is far more common for ECMAScript - typical use would be to > re-sort a list of a few dozen or at most a few hundred entries and then > redisplay that list. #1 might become more common though as JavaScript use > on the server progresses. > > So here's an alternative spec approach: > > - Leave the specification of String.prototype.localeCompare as is. That > is, if it's not based on Collator, canonical equivalence -> 0 is required. > > - For Collator.prototype.compare, require that canonical equivalence -> 0 > unless the client explicitly turns off normalization (i.e., normalization > is on by default, independent of locale). Support for the normalization > property in options and the kk key would become mandatory. > > Norbert > > > On Aug 31, 2012, at 10:12 , Mark Davis ☕ wrote: > > > I think we could go either way. It depends on the usage mode. > > • The case where performance is crucial is where you are comparing > gazillions of strings, such as records in a database. > > • If the number of strings to be compared is relatively small, > and/or there is enough overhead anyway, the performance win by turning off > full normalization would be lost in the noise. > > So if #2 is the expected use case, we could require full normalization. > > > > > > Mark > > > > — Il meglio è l’inimico del bene — > > > > > > > > On Fri, Aug 31, 2012 at 9:56 AM, Norbert Lindenberg < > ecmascr...@norbertlindenberg.com> wrote: > > The question for ECMAScript then is whether we should stick with "must > do" (the current state of the specifications) or change to "must be able to > do". > > > > The changes for "must be able to do" would be: > > > > - In the Language specification, remove the description of > String.prototype.localeCompare, and require implementations to follow the > Internationalization API specification at least for this method, or better > provide the complete Internationalization API. That way, localeCompare > acquires support for the normalization property in options, and the -kk- > key in the Unicode locale extensions. > > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss