Skip to content
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

Closed

Conversation

manuelpuyol
Copy link
Contributor

@manuelpuyol manuelpuyol commented Mar 22, 2024

Related to #1350 and #1211

Summary

As an initial step for Intl backed by ICU, I'm implementing the getCanonicalLocales function using BCP47Parser. The implementation is exactly the same as Apple's implementation

Test Plan

This change should be covered by the get-canonical-locales.js test.

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.
@facebook-github-bot facebook-github-bot added the CLA Signed Do not delete this pull request or issue due to inactivity. label Mar 22, 2024
@tmikov tmikov requested a review from neildhar March 22, 2024 05:02
@manuelpuyol
Copy link
Contributor Author

@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

hermes/CMakeLists.txt

Lines 515 to 519 in d62b96e

# Attempt to use system ICU first, if none specified.
# Don't need ICU on Apple, Emscripten, and Android.
if (APPLE OR EMSCRIPTEN OR HERMES_IS_ANDROID)
set(ICU_FOUND 1)
endif()

@manuelpuyol manuelpuyol force-pushed the mp/icu-intl-get-canonical-locales branch from 9436ab1 to a2543e0 Compare March 22, 2024 17:02
@neildhar
Copy link
Contributor

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 BCP47Parser.cpp, and how it is used in our existing Apple implementation in PlatformIntlApple.mm. You may be able to just copy the implementation over from the Apple platform. (we're planning to unify these in the longer term)

That should also solve the ICU issue you shared, since all the tag parsing and canonicalisation will be done by us.

@manuelpuyol manuelpuyol marked this pull request as ready for review March 27, 2024 16:06
@manuelpuyol
Copy link
Contributor Author

hey @neildhar! I used Apple's implementation and reverted the ICU change.
I'm not sure what is going on with test-e2e though, compileReleaseKotlin is failing but doesn't look related to my changes and I see it failing on other PRs

@manuelpuyol manuelpuyol changed the title Implement getCanonicalLocales with ICU Implement getCanonicalLocales in non apple/android environments Mar 27, 2024
Copy link
Contributor

@neildhar neildhar left a 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.

Comment on lines +25 to +29
add_hermes_library(hermesPlatformIntl STATIC PlatformIntlICU.cpp
LINK_LIBS
hermesBCP47Parser
hermesPublic
)
Copy link
Contributor

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

Suggested change
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)

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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 :)

@facebook-github-bot
Copy link
Contributor

@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>
@facebook-github-bot
Copy link
Contributor

@manuelpuyol has updated the pull request. You must reimport the pull request before landing.

@facebook-github-bot
Copy link
Contributor

@neildhar merged this pull request in ef5fa1a.

facebook-github-bot pushed a commit that referenced this pull request Apr 11, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Do not delete this pull request or issue due to inactivity. Merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants