00:04:22  * bttfjoined
00:05:04  * bradleymeckquit (Quit: bradleymeck)
00:11:26  <TabAtkins>Yeah, that's why we now have a completely separate minute taker; they don't need to pay attention to what's going on.
00:51:05  <dilijev>So this note taker is not a member of tc39 - just someone whose sole responsibility it is to take notes?
00:53:44  <dilijev>I want to discuss some semantics and behavior of Intl.getCanonicalLocales (CanonicalizeLocaleList) to understand whether some differences I'm seeing between V8/Chakra (ICU/WinGlob) are a violation of spec or implementation details. Anyone around? It's tough when the spec refers to RFC 5646 and ICU refers to BCP 47 (which is RFC 5646 + RFC 4647) -- hard to
00:53:44  <dilijev>tell what steps are required versus optional and what forms are considered normal.
00:54:36  <dilijev>Reading the various documents has turned into a rabbit hole and I've fallen back on experimenting and writing test cases to compare outputs.
00:57:11  <dilijev>There's also some possibly-relevant information in https://github.com/tc39/ecma402/issues/87#issuecomment-225570830
04:49:19  * jmdyckquit (Quit: Leaving.)
05:56:09  * gskachkov_joined
07:38:54  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:05  * mylesborinsquit (Quit: farewell for now)
10:25:36  * mylesborinsjoined
11:41:42  * jmdyckjoined
12:54:50  * gskachkov_quit (Quit: gskachkov_)
12:55:12  * gskachkov_joined
13:10:14  * jmdyckquit (Ping timeout: 260 seconds)
13:11:53  * jmdyckjoined
13:40:06  * brianloveswordsquit
13:40:20  * brianloveswordsjoined
13:45:23  * gskachkov_quit (Quit: gskachkov_)
15:53:11  <littledan>dilijev: I'm interested in that topic--are you talking about https://github.com/tc39/ecma402/issues/141 ?
15:53:37  <littledan>what sort of test cases do you have?
16:00:12  <littledan>FWIW the spec refers to RFC 4647 in https://tc39.github.io/ecma402/#sec-language-tags
16:01:01  <littledan>but 6.2.3 CanonicalizeLanguageTag does not reference it. Hard to tell whether that's an oversight or deliberate variability
16:02:02  <littledan>if you're only comparing against V8, though, V8 definitely does not have 100% ECMA 402 spec compliance...
16:02:18  <littledan>how does the ICU/WinGlob implementation behave differently?
16:58:59  * gskachkov_joined
17:08:52  <dilijev>I'm working in that area of the spec, hence opening that issue.
17:09:45  <dilijev>Ah I guess I forgot I saw the reference to all of the documents there. BCP 47 is obviously the whole set of relevant documents here. Not really worried about that.
17:10:03  <dilijev>so let's see, I'm sure there are other cases
17:11:01  <dilijev>but the one I'm looking at in particular is in test262\test\intl402\6.2.3.js
17:11:11  <dilijev>line 27 "ji": ["yi"],
17:11:53  <dilijev>Basically, the old Yiddish tag ("ji") should, according to this test, canonicalize to exactly (and only) the new Yiddish tag.
17:12:52  <dilijev>The problem as I see it is that in order to make that transformation you need to have that information in your database.
17:13:08  <dilijev>I'm trying to find where it says that this particular step should be taken in canonicalization.
17:14:23  <dilijev>I think the more important thing is that your i18n stack either knows about the equivalence and handles either tag, or knows how to handle the canonical tags output from Intl.getCanonicalLocales in such a way that i18n proceeds as planned.
17:15:18  <dilijev>The test begs the question, is "ji"->"yi" truly a necessary transformation for i18n to work correctly and for the tag to be considered to be in canonical form?
17:16:42  <dilijev>This also applies to the other language names which have been revised in ISO 639-1 (iw -> he, in -> id)
17:17:30  <dilijev>Chrome gives the wrong result here. Firefox gets it correct. Anything using small-icu (i.e. Node) or another database may get it wrong if that information is not in the database
17:17:47  <dilijev>Edge (WinGlob) does something weird, not sure what to make of this
17:21:02  <dilijev>er, ChakraCore with the Intl.getCanonicalLocales api implemented does something weird when running under the test262-runner anyway
17:21:08  <dilijev>It was returning yi-001
17:21:26  <dilijev>I'm trying to figure out what those number codes actually mean and whether that should be considered wrong
17:21:47  <dilijev>FWIW in the browser, Intl.DateTimeFormat.supportedLocalesOf(['ji','iw','in']) // -> ["yi", "he", "id"]
17:22:51  <dilijev>slightly different answer potentially from Intl.getCanonicalLocales() but FWIW running ch.exe directly from the console:
17:22:59  <dilijev>Intl.getCanonicalLocales(['ji','iw','in']) // -> ["yi", "he", "id"]
17:23:14  <dilijev>So I'm not really sure what I'm seeing now... I was trusting the test262-harness
17:24:47  <dilijev>But consider a database which doesn't have this information, "ji" might still be considered a tag in canonical form, the same way that "yy" is not a real language but is returned from Intl.getCanonicalLocales("yy")
17:39:21  <dilijev>Okay so I found a list of region codes on wikipedia. Numeric region subtags come from UN M.49
17:39:22  <dilijev>https://en.wikipedia.org/wiki/UN_M.49
17:39:37  <dilijev>001 = World, which granted, isn't very specific, but isn't wrong in any meaningful way for yiddish
18:13:06  * gskachkov_quit (Quit: gskachkov_)
18:23:33  * gskachkov_joined
19:26:08  * gskachkov_quit (Quit: gskachkov_)
19:34:35  * gskachkov_joined
20:49:33  * not-an-aardvarkjoined
21:34:17  * gskachkov_quit (Quit: gskachkov_)
21:34:51  * gskachkov_joined
21:36:27  * gskachkov_quit (Client Quit)
21:50:05  * tcarequit (Quit: Connection closed for inactivity)
22:52:39  <Bakkot>ljharb / littledan: as I look at it more, I'm no longer 100% convinced that allowing the `#x` shorthand for `this.#x` is actually a good idea.
23:53:40  <ljharb>Bakkot: i don't actually care whether we allow it or not; if it's allowed, i'll add a lint rule to eslint/airbnb config to forbid it, because having two ways to type something is bad news bears :-)
23:53:50  <ljharb>(unless it's required, in which case, that's fine)
23:55:34  <ljharb>Bakkot: one argument i see for disallowing it is, `this.#x === other.#x` is symmetric; `#x === other.#x` isn't
23:55:49  <ljharb>also, if i `.call` with a different this, it's not as clear to me that `#x` points to it
23:56:41  <Bakkot>mm, the fact that `#x()` would have get the `this` of the object instead of undefined would be confusing maybe
23:56:51  <Bakkot>which is an argument against
23:57:29  <ljharb>also that, sure
23:57:52  <ljharb>and `this.#x.call(other)` might be clearer than `#x.call(other)` given that `#x()` would have the receiver as "this"
23:58:10  <Bakkot>I think the argument for the shorthand is just that `other.#x` is a *lot* less common than using properties of `this`.
23:58:28  <ljharb>sure, but `this.foo` doesn't have a shorthand
23:58:34  <Bakkot>yeah.
23:58:39  <ljharb>guaranteed people will start yelling for it if `#x` is allowed :-)
23:59:08  <ljharb>(not that i know what syntax could possibly work for that)