-
Notifications
You must be signed in to change notification settings - Fork 29.4k
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
Workaround to prevent ICU trouble #30544
Comments
I transferred this issue from the Release working group to the core one. I believe this issue is best discussed here. |
BridgeAR
added
i18n-api
Issues and PRs related to the i18n implementation.
wasm
Issues and PRs related to WebAssembly.
labels
Nov 19, 2019
I'm confused about what this is asking. Is there something extra this wasm build is providing you? |
@mabels the full ICU support landed in #29522 also see https://github.com/unicode-org/omnicu |
I believe there's nothing actionable here. Closing. We can reopen if necessary |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My current workaround is to build and run the icu packages with wasm “https://www.npmjs.com/package/wasm-intl” which gives the application developer full control of this ICU back. But raises the question if ICU should shipped with node in future version as native or wasm compilation which enables that node could use architecture independent translation sets that give the application dev controllback and not raises these kind of problems at all.
I knew that future version of node will ship the full-icu in standard configuration. But why not use this case to explore wasm in node core.
The text was updated successfully, but these errors were encountered: