-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avoid locale-dependent string comparisons #3
Conversation
Hey! The build was failing due to a dev-dependency, I fixed that, and merged with you. The idea looks good, but can you fix the coverage? And, the style is off compared to the rest of the project, e.g., semicolons and early exits. Something like: if (left.singleton > right.singleton) {
return 1
}
if (left.singleton < right.singleton) {
return -1
}
return 0 |
4297991
to
6efe7a2
Compare
Thanks. I hadn't managed to get the test coverage check to run locally, but it works now with the dependency updates. The missing bit of test coverage was for when there are multiple extensions with the same singleton. e.g. Rather than add a test which will fail if |
It doesn't seem appropriate to use locale dependent ordering to sort the variants and extensions for normalization. The result of normalization should be consistent. The Unicode CLDR specficiation is not specific about how these tags are sorted, it just says that they should be in "alphabetical order". They only contain a-z (lower case) and 0-9, so for most locales alphabetical order is the same as the code point order we are now using. This commit removes a dependency on the ECMAScript internationalization API. This API is not available everywhere, particularly on embedded devices like TVs where storage space for internationalization data is limited. This is important as bcp-47-normalize is now used by dash.js which in turn is used by many HbbTV applications. The new test case isn't strictly valid - there should not be more than one extension with the same singleton.
Argh, now it's failing some other check. At this point I'm really not sure what the "right" thing to do is. Options I can see are:
The first of these options seems the least bad to me, so I've now pushed code which does that. |
6efe7a2
to
ff84b77
Compare
yep, 1 is fine |
see also wooorm/bcp-47#23 |
Thanks, released in 2.3.0! |
It doesn't seem appropriate to use locale dependent ordering to sort the variants and extensions for normalization. The result of normalization should be consistent.
The Unicode CLDR specficiation is not specific about how these tags are sorted, it just says that they should be in "alphabetical order". They only contain a-z (lower case) and 0-9, so for most locales alphabetical order is the same as the code point order we are now using.
This commit removes a dependency on the ECMAScript internationalization API. This API is not available everywhere, particularly on embedded devices like TVs where storage space for internationalization data is limited. This is important as bcp-47-normalize is now used by dash.js which in turn is used by many HbbTV applications.