1.0 PRD and Roadmap documents #665
Conversation
Pull Request Test Coverage Report for Build 00beb40611d4fa8e3592af19d59bc6ecfb7a41fb-PR-665
💛 - Coveralls |
docs/process/roadmap.md
Outdated
| * [x] Unicode Set | ||
| * [x] L3a | ||
| * [ ] March/April | ||
| * [ ] FFI/WASM exploration |
There was a problem hiding this comment.
I think this got moved to May (0.3)
There was a problem hiding this comment.
I assume it spans both since Manish and Shane are working on it in April, so I added it to both :)
| - [Intl.PluralRules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/PluralRules) | ||
| - [Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) | ||
|
|
||
| The former two should be able to pass the full test scope. |
There was a problem hiding this comment.
The 262 test suite has lots of JS specific elements, like is returned value an Object/Array etc. I assume we are not interested in fulfilling those.
There was a problem hiding this comment.
We are not, but I assume we want sticking ICU4X into a JS implementation (SpiderMonkey, Deno, V8 etc.) ergonomic so that they only have to care about Object/Array etc.
Do you think it should be stated explicitly here? If so, do you have a suggestion how to phrase it?
There was a problem hiding this comment.
I think you should commit it as is, and I'll edit (with your review) afterwards?
|
|
||
| ### Fuchsia | ||
|
|
||
| Fuchsia maintains [a thin wrapper around ICU4C](https://crates.io/crates/rust_icu) exposed to Rust and would like to replace that with ICU4X. In case of a successful test262 April test, we’ll be in a good position to offer Fuchsia the ability to test a replacement of the same subset of APIs backed by ICU4C to ICU4X. |
There was a problem hiding this comment.
related to 262 full compatibility requirement above.
There was a problem hiding this comment.
Hmm, I'm confused. Are you concerned that a reader may interpret "full test262 compatibility" as "producing JS objects" rather than "performing i18n operations that are in scope of ecma402 and tested by test262"?
Do you have a suggestion on how we should communicate that intent?
There was a problem hiding this comment.
Please commit as is, I'll edit after.
|
|
||
| ### Collator | ||
|
|
||
| Collation is one of the core [ECMA-402 components](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Collator), and builds on top of the Unicode Properties API which we’re investing in. |
There was a problem hiding this comment.
question (non-blocking): Doesn't collation also depend on normalization? If so, it would be worth mentioning, and that would also be another reason why collation isn't a quick/easy thing.
There was a problem hiding this comment.
@sffc ^ do you know? I have never worked on collation impl.
There was a problem hiding this comment.
I don't feel authoritative answering this question since I have not worked extensively with collation.
zbraniecki
dismissed stale reviews from sffc, dminor, nciric, echeran, and Manishearth
via
d828276
Extracted the doc we aligned on into markdown.
I decided to separate PRD from Roadmap to make the roadmap easier to check quickly, while the PRD is more of a whitepaper behind it and will likely be read and updated less often and maybe even by a different audience.