Comments (11)
For example see step 5 in Intl.Locale.prototype.language:
- Return the substring of locale corresponding to the unicode_language_subtag production.
The locale id "en-t-en" contains two unicode_language_subtag
productions, which makes step 5 ambiguous.
from proposal-intl-locale.
We did just discuss what "editorial" means the other day, so I should remember quite clearly what it was...but even without remembering the exact meaning, this does not seem editorial.
Perhaps most notably given the call yesterday, newer TR35 (or at least what we referenced in it) removed (or, moved) a requirement to do alias/preferred replacement in Unicode locale extensions when canonicalizing. That removal was what led me to no longer have concerns about advancing Intl.Locale
. (Although on a closer look, I see that under that understanding Intl.Locale
will still deduplicate attributes and keywords, where CanonicalizeLanguageTag
will not, so there is a distinction -- but a simpler one to explain than a replacements-based distinction, and one that probably should be fixed by changing CanonicalizeLanguageTag
to trim duplicates.)
But if #43 is correct, we specifically chose to do replacements. So if TR35 updating changed that, we would also need to change to do replacements again. And that's a significant change in how Intl.Locale
operates. And sadly, it would end up resurrecting my concern about the differentiation between Intl.Locale
and CanonicalizeLanguageTag
. 😧
Given that this proposal modifies CanonicalizeLocaleList
, I think we need also to modify CanonicalizeLanguageTag
too here. At least, if we're going to return to the position that was seemingly deliberately adopted previously. If I can figure out how to build a modified proposal myself (and verify it'll merge into the main spec correctly, not just render standalone correctly), I'll see if I can figure out how to do that.
from proposal-intl-locale.
So, looking closely at this, it seems like the only way to invoke replacements any more is to invoke TR35's new "canonical form" setup. We could hand-roll our own version of this to perform replacements, of course, but that seems best avoided.
So...probably we want to invoke canonical form in Intl.Locale
.
from proposal-intl-locale.
Note that BCP 47 Language Tag to Unicode BCP 47 Locale Identifier, that is the operation currently performed by CanonicalizeLanguageTag
, alleges that "The result [of this operation] is a Unicode BCP 47 locale identifier, in canonical form." That...seems false? That algorithm first dials up canonical syntax, then it does language/region replacement, but canonical form also does variant replacement/replacement within 'u' and 't' extensions/replacement in 'sd' and 'rg' keys.
@anba Am I dumb, or is this just TR35 bug? (Which would raise the question of whether this algorithm in TR35 should change, and if it did change -- and ideally deduplicated -- we'd only have duplicates to deal with at all in this spec.)
from proposal-intl-locale.
@anba Am I dumb, or is this just TR35 bug?
Yes, this is a TR35 bug. When TR35 was changed to differentiate between "canonical syntax" and "canonical form" (in version 36), that sentence wasn't updated to use "canonical syntax".
from proposal-intl-locale.
I ended up making us invoke canonical form in CanonicalizeLanguageTag
in #83. It happens that every path through Intl.Locale
is a result of that function (see #83 (comment) for the details laid out), so just changing that function will get everyone on the same page about canonical form everywhere.
from proposal-intl-locale.
@jswalden - does it mean that #83 will solve #82 and this issue?
from proposal-intl-locale.
@zbraniecki #83 will solve one aspect of this issue, namely responding to the canonical form/syntax split introduced in UTS35 v35. I can't say with confidence that that is definitely the only problem this issue covers -- merely the most serious one from my point of view. @anba could say more, more quickly, than I could here, I think.
from proposal-intl-locale.
@anba - anything left here from your POV since #83 has landed?
from proposal-intl-locale.
This indeed was not an editorial issue. I'll wait for @anba to verify if there's anything left now and if what's left is editorial :)
from proposal-intl-locale.
Thank you! That's a good catch. I clarified that in the PR. Lmk if there's anything else you noticed.
from proposal-intl-locale.
Related Issues (20)
- Modified CanonicalizeLocaleList does not accept Intl.Locale instances when provided as the only argument HOT 1
- Using Unicode locale ID vs BCP 47 in our spec HOT 51
- Resolved value for Unicode extension values when "true" is removed? HOT 4
- Simplified the change to 2.1 CanonicalizeLocaleList HOT 3
- Docs(MDN) Documentation for Intl.Locale HOT 17
- Does hourCycle exist unconditionally? HOT 3
- Not all RFC 5646 production names updated HOT 3
- Move "get caseFirst" after "get calendar"
- Use `type` production from UTS35
- Directly use unicode_language_id in "get baseName"
- Need to test for SameValue(r.[[kn]], "") in addition to SameValue(r.[[kn]], "true")
- no validation of value of extensions in tag? HOT 8
- CanonicalizeLanguageTag should remove duplicate attributes/keywords in a Unicode extension, consistent with Intl.Locale HOT 6
- Getting the default locale HOT 10
- Drop this proposal in favor of a more general user settings object HOT 6
- Spec is vague regarding internal data structure representation HOT 12
- Canonicalise Unicode extensions options added through ResolveLocale HOT 8
- CanonicalizeUnicodeLocaleId should only perform step 1 of "BCP 47 Language Tag to Unicode BCP 47 Locale Identifier" HOT 3
- Archive repository, redirect draft to ecma402 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-intl-locale.