Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Intl flavor #6

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

Merged
kmagiera merged 1 commit into master from intlFlavor
Jul 12, 2017
Merged

Intl flavor #6

kmagiera merged 1 commit into master from intlFlavor
Jul 12, 2017

Conversation

@kmagiera
Copy link
Member

@kmagiera kmagiera commented Jul 12, 2017

No description provided.

Copy link
Member Author

💯

@kmagiera kmagiera merged commit e961088 into master Jul 12, 2017
@kmagiera kmagiera deleted the intlFlavor branch July 12, 2017 09:28
Copy link

This looks great. If we use the 'Default Variant', will Intl.DateTimeFormat and Intl.NumberFormat work properly for formatting dates and numbers in US English?

Copy link
Member Author

Intl will not be available in default variant (similarly as with the old JSc used by React Native). You could use Date.toLocaleString or Number.toLocaleString though, which have "fallback" implementation that does not necessarily match "en-US" implementation from ICU (specifically for dates)

e.g:
with intl Date.toLocaleString will return the following format for en-US: 7/12/2017, 4:27:45 PM
w/o intl Date.toLocaleString will return sth like Wed Jul 12 16:24:54 2017
when you call Date.toString you will get Wed Jul 12 2017 16:24:54 GMT+0200 (CEST)

We recommend that for number/date formatting you use an external library if you opt out from using intl variant.
The biggest difference for the intl variant is that it supports collation (that is proper comparison of non-english letters). By default strings are sorted using UTF-8 codes of subsequent characters, which is not the way it works with languages that have non-english letters.

Copy link

Good to know, thanks. I'll take a look at using the Intl polyfill (https://github.com/andyearnshaw/Intl.js/); I'd like to use the standard APIs since they'll work well on iOS too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /