-
Notifications
You must be signed in to change notification settings - Fork 599
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
Implement getCanonicalLocales
in non apple/android environments
#1361
Implement getCanonicalLocales
in non apple/android environments
#1361
Conversation
Versions before 67 had a bug with defaults, where they were adding the `yes` and `true` defaults to Language Tags. See unicode-org/icu#952 for their fix.
@neildhar looks like the base images used for android and emscripten only have ICU 66, but I expected them to skip the ICU library from Lines 515 to 519 in d62b96e
|
9436ab1
to
a2543e0
Compare
Hey @manuelpuyol, thanks for putting this together! The main high level suggestion I have here is to use the existing unicode tag parsing and canonicalisation functionality we use for the Apple Intl implementation. In particular, take a look at That should also solve the ICU issue you shared, since all the tag parsing and canonicalisation will be done by us. |
hey @neildhar! I used Apple's implementation and reverted the ICU change. |
getCanonicalLocales
with ICUgetCanonicalLocales
in non apple/android environments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM apart from the minor build change, looking at your other diff, it looks like getCanonicalLocales
might belong in PlatformIntlShared.cpp
, but I'll leave it up to you.
Regarding the test failure, I suspect something just broke in RN mainline, it will probably clear up once it is fixed.
add_hermes_library(hermesPlatformIntl STATIC PlatformIntlICU.cpp | ||
LINK_LIBS | ||
hermesBCP47Parser | ||
hermesPublic | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to make sure we link against ICU
add_hermes_library(hermesPlatformIntl STATIC PlatformIntlICU.cpp | |
LINK_LIBS | |
hermesBCP47Parser | |
hermesPublic | |
) | |
add_hermes_library(hermesPlatformIntl STATIC PlatformIntlICU.cpp | |
LINK_LIBS | |
hermesBCP47Parser | |
hermesPublic | |
) | |
hermes_link_icu(hermesPlatformIntl) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we aren't using anything from ICU in this implementation, should we still link it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose not in this particular PR. If you'd prefer to do it in the next PR once ICU is being used, we can just do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, I'm linking it in the DateTimeFormat PR so we should be good :)
@neildhar has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Co-authored-by: neildhar <neildhar@users.noreply.github.com>
@manuelpuyol has updated the pull request. You must reimport the pull request before landing. |
Summary: Related to #1350 and #1211 Follow up of #1361 I'd like to expand non iOS/android support of `Intl`. In this case, I'm implementing both `DateTimeFormat.prototype.resolvedOptions` and `DateTimeFormat.prototype.format`. The implementation is a mix from the Apple and hermes-windows' implementations. - created `PlatformIntlShared` with helper functions that are exactly the same between Apple and ICU - Implemented `DateTimeFormatICU` based on `DateTimeFormatApple` - Used an ICU equivalent whenever NS was used for Apple Pull Request resolved: #1362 Test Plan: Testing against `test262/test/intl402/DateTimeFormat` Reviewed By: tmikov Differential Revision: D55893825 Pulled By: neildhar fbshipit-source-id: 03eef39721915ef03ebf6859980c374e10d337e9
Related to #1350 and #1211
Summary
As an initial step for
Intl
backed by ICU, I'm implementing thegetCanonicalLocales
function using BCP47Parser. The implementation is exactly the same as Apple's implementationTest Plan
This change should be covered by the
get-canonical-locales.js
test.