| 19:02 | <hsivonen> | sffc: Does Chromium make good use of what better than prefix only should enable relative to Firefox and Safari? For example, is it better for yue? |
| 19:04 | <hsivonen> | Is there a good reason why Chrome unshipped zh-u-co-unihan but keeps ja-u-co-unihan and ko-u-co-unihan? Or is this just a case of someone having looked at unshipping Chinese collations (unihan getting unshipped together with big5han and gb2312) instead of looking at more things at the same time? |
| 19:05 | <hsivonen> | The way Firefox deals with prefix-only, Hans, and Hant is ensuring the common triplets are in the the available locales list. |
| 19:06 | <hsivonen> | Common triplets starting with zh, that is. We don't have yue on the list. |
| 19:06 | <sffc> | There's a big mismatch between what the spec says and how i18n libraries actually work. Even if you implement the spec as written, as soon as you start asking ICU to do things, you are implicitly getting the best fit behavior. |
| 19:07 | <sffc> | The whole concept of "available locales" just simply doesn't exist |
| 19:07 | <hsivonen> | sffc: We run the spec algorithm first. Passing its outcome to either ICU4C or ICU4X gives the expected result. That is, they don't do anything strange enough to break the outcome of the specced algorithm. |
| 19:08 | <hsivonen> | It concretely exists in all of SpiderMonkey, JSC, and V8. |
| 19:08 | <sffc> | What does exist is "class of locales that are vetted" and "class of locales that are not vetted", where the union of those classes is the space of all locales, which is a virtually unbounded set |
| 19:09 | <sffc> | The spec is inventing a concept that no ICU has ever really implemented |
| 19:09 | <hsivonen> | sffc: SpiderMonkey and V8 at least get the list from ICU4C today, so evidently ICU4C implemented something close enough to it. |
| 19:10 | <hsivonen> | sffc: I understand why you think the list is a bad idea, but it really does exist in implementations. |
| 19:11 | <sffc> | It's not that the list is a bad idea |
| 19:11 | <hsivonen> | sffc: Do you have any insight into the unihan situation in Chrome? |
| 19:12 | <sffc> | It's that the list is a list that doesn't exist; it's asking for a thing that is not real |
| 19:14 | <sffc> | I don't remember exactly why Chrome does what it does with unihan collations |
| 19:14 | <sffc> | hi-Latn is another example where best fit matching works but prefix matching not |
| 19:16 | <sffc> | I have thoughts on how engines using ICU4X can implement the spec concept of available locales, which I've previously posted in issue 58 but never did a formal write up or docs page |
| 19:22 | <hsivonen> | I wonder if anyone has bothered to do telemetry for traditional collations. For es, the traditional one is famous, but do people still want it? For fi and sv, it's not useful to ship traditional. Do people care about traditional for Vietnamese, Kannada, and Bengali? |
| 19:58 | <sffc> | I have thoughts on how engines using ICU4X can implement the spec concept of available locales, which I've previously posted in issue 58 but never did a formal write up or docs page |
| 20:00 | <Jedel> | This would be nice! In Boa we kinda do very weird things to implement the concept of available locales, so it would be reassuring having an "official" way of implementing it using ICU4X |