Intl Support

[danilobuerger]

In https://github.com/facebook/hermes/blob/master/doc/Features.md Intl is listed as Excluded From Support. With

Hermes plans to target ECMAScript 2015 (ES6), with some carefully considered exceptions.

What are those considerations regarding Intl? (If its about size, why not have a variant like jsc does?)
How should i18n look like with Hermes?

[fbartho]

Intl is super important for us, and unfortunately, it's a blocker for my team. The Polyfills we tried before switching to jsc-intl weren't complete (they allowed compilation/basic testing, but didn't work in actual localized environments).

Is there a plan for when Intl might be discussed again for the Hermes Engine?

[dulinriley]

It will help us prioritize work on Intl if we know the following things:

• Its main use cases (most popular function it has) to the RN community
• Any important libraries that depend on it
• What alternatives exist (is there a JS-only way to implement it?)

I don't remember the exact conversation we had about Intl, but I think it was related to ICU's binary size, and that it is not part of the normal EcmaScript JS spec.

@avp or @ridiculousfish have more context on this

[danilobuerger]

Its main use cases (most popular function it has) to the RN community

Enabling I18n for apps regarding:

• Date / Time Formats
• Relative Time Formats
• List Formats
• Number (also Currency) Formats
• Plural Rules

Any important libraries that depend on it

https://github.com/formatjs/react-intl (> 10K Stars)
https://github.com/moment/luxon (> 8K Stars)

What alternatives exist (is there a JS-only way to implement it?)

As pointed out by @fbartho, polyfilling doesn't work properly. Every other solution is incomplete at least regarding locale rules around the world.

but I think it was related to ICU's binary size

If it is just about binary size, it could be done like JSC: a variant with Intl.
See https://github.com/react-native-community/jsc-android-buildscripts/#international-variant

and that it is not part of the normal EcmaScript JS spec

However, lots of functions that are part of the ECMAScript 2015, are dependent on Intl to function "properly", or at least need a locale aware implementation anyway. For example:

20.3.4.39 Date.prototype.toLocaleString ( [ reserved1 [ , reserved2 ] ] )
An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the Date.prototype.toLocaleString method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the toLocaleString method is used.

This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment’s current locale.

[TheTimeWalker]

One thing to add: Intl works perfectly out of box on iOS as it has to use its V8 (oops!) JavaScriptCore engine which already integrates this. So I find it strange why we're trying to back off from Intl support as this would just confuse RN developers with the iOS and Android feature gap.

[fbartho]

That's a great point @TheTimeWalker -- this is a "platform compatibility issue" where iOS & Android's JavaScript engines differ. (Nit: iOS uses the JavaScriptCore engine rather than the V8 engine, but your point is the same).

I guess the key question is: What is this project's driving mandate with regards to differences between iOS & Android? -- Presumably the expectation is that there shouldn't be significant framework-level differences? Especially not in things that can't be polyfilled-well.

Unfortunately, the existing Polyfills in this case are insufficient. React-Native developers targeting more than one language will be stuck on jsc-intl unless this feature is provided by Hermes!

[gmaclennan]

As @danilobuerger clearly states, there is no complete and reliable JS-only solution to this. For I18n apps Intl is needed. It adds to binary size, but as I understand it that's because I18n is so darn complicated with so many edge-cases.

[wyzzy]

Strong +1 for including Intl support out-of-the-box in Hermes, having just encountered this limitation ourselves!

At the moment the lack of Intl support on Android RN is a major source of inconsistency in behaviour between iOS and Android. On iOS Intl 'just works' as expected, but not so on Android, where you're stuck trying to find some workable solution to restore parity in behaviour on the two platforms. On iOS, Number.prototype.toLocaleString() for formatting numbers and currency values all work as expected, as does Date.prototype.toLocaleString() for dates, and all the Intl API...

The lack of Intl support on Android's out-of-the-box JSC was one significant hurdle we encountered in enabling our iOS-first RN app for Android. As many folks have said, the pollyfills just don't work well enough and feel like an unsatisfactory hack.

For our investment app, date/time and currency formatting are the primary drivers, though relative time rules, plural rules, and list formats would all undeniably help offer a more polished user experience.

Needing to include a custom JSC build on Android is non-trivial and really shouldn't be necessary for such a fundamental piece of functionality!

If Hermes is worried about size, some RN config to optionally exclude Intl support for those (rare?) apps that don't need it might be a way forward. Surely these days most commercial quality apps need to reliably present localised time & date or numeric/currency values?

If Hermes did fully support Intl, switching from the existing JSC would be a no-brainer for us. On the other hand, no support means we would perhaps be better off with a JSC build that does support it?? Feels like a problem that Hermes needs an answer to, one way or the other.

I18n certainly is darn complicated, which is precisely why it's so important that the platform itself offers first-class support for Intl out of the box! Even on Android.

[jcurtis]

Intl is a major concern for all the apps I have ever worked on. Today we're using react-intl which is one of the most popular React libraries for handling intl. As stated before, there are no polyfills that work properly on Android right now.

I'd be curious if someone could tell us what Facebook uses to handle intl in their React Native apps? Specifically for number and date formatting.

[gpawlik]

@dulinriley is there any more information that you need in order to prioritise this issue?

[feruzm]

Big thanks to this thread, Hermes is great but we need support for Intl which most fundamental part of any app.

[OtacilioN]

Hey folks,

Is that any workaround suggested for Number.prototype.toLocaleString() while they don't implement Intl ?

We broke our minds for some weeks with this bug because when we were using the debug mode in React Native, the Number.prototype.toLocaleString() works, I think because it uses my browser engine to run JavaScript, but as soon we assemble the app or turnOff the debug mode, Number.prototype.toLocaleString() starts to no work.

[fbartho]

@OtacilioN -- On my team we're still using org.webkit:android-jsc-intl:r245459 until Hermes supports Intl (we would love to use Hermes for Android Performance reasons!!) Not to give you useless advice, but that's what I recommend.

And I ran into exactly the same debug-time issues with some other features including Proxy (also missing in Hermes, #33), before that was updated to be available on android-jsc. I feel your pain!

[patrickkempff]

How does facebook handle Intl in their apps when using Hermes?

[tmikov]

Sorry about the delayed response here. Internally at Facebook we use fbt, with its own specific translation assets handling, and translation dictionary shipped with the app binary. fbt was open sourced a while back, and fortunately we have RN android variant in OSS now.

See:
https://github.com/facebookincubator/fbt
https://github.com/facebookincubator/fbt/tree/master/packages/fbt-rn-android-native
https://github.com/facebookincubator/fbt/tree/rn-demo-app

The published version currently builds for Android but AFAIK there is nothing preventing porting to iOS.

On the subject of Intl support: we would like to have it in Hermes, but it isn't our top priority, since, as described above, we don't use it internally. We welcome help from the community in implementing it.

[TheSavior]

EDIT: I found that Chrome Status shares data publicly on the usage of these APIs. I have gathered and ordered that data for the Intl APIs in this comment.

Additional anecdotal data is probably not as helpful now.

---

We are revisiting Intl support on Hermes and need your help figuring out which functions to prioritize. There are a ton of Intl APIs and I'd bet that only a handful of them are the most critical functions blocking Hermes adoption.

Please help us understand the particular function calls that are blocking your ability to use Hermes. For example, I've seen Number.prototype.toLocaleString() mentioned twice in this thread. That's the kind of specific example I'm looking for. "Relative Time Formats" is too vague. I'm sure there are many more functions that would be really nice to have but aren't as critical. Please mention them, but separately so I can track that.

Intl functions blocking usage of Hermes:

• Number.prototype.toLocaleString()
• Date.prototype.toLocaleString
• Date.prototype.toLocaleTimeString
• Intl.DateTimeFormat().resolvedOptions
• Intl.DateTimeFormat().format() (specific options)
• Intl.NumberFormat().format() (specific options)
• Intl.RelativeTimeFormat().format()
• String.prototype.localeCompare

---

Also, I saw a mention of the react-intl project. Can someone go through that and identify what Intl functions it uses and share those here?

Thanks!

[fbartho]

I'm not entirely sure how to search react-intl for "particular function calls" that need to be supported. I'm trying to join their slack to figure that out.

In addition to react-intl, a super popular library is MomentJS -- https://momentjs.com & its sub library moment-timezone https://momentjs.com/timezone/

Moment has a CI testing various browsers/environments, so maybe you can add hermes to that list, and then get an enumeration of the methods that are missing / fail tests?

[dlebedynskyi]

@TheSavior
I believe we are specifically interested in DateTime and TimeZone related ones such as

• Date.prototype.toLocaleString
• Date.prototype.toLocaleTimeString
• Intl.DateTimeFormat().resolvedOptions
• rest of timezone related things

For react-intl it is probably better to start with intl-messageformat as it is most used one.

@fbartho
I believe moment is not actually using Intl.

[fbartho]

Our codebase also directly uses

• String.prototype.localeCompare

[janicduplessis]

I'm currently using the following polyfills for Hermes:

• intl (https://github.com/andyearnshaw/Intl.js)
• @formatjs/intl-pluralrules (https://github.com/formatjs/formatjs/tree/master/packages/intl-pluralrules)
• @formatjs/intl-relativetimeformat (https://github.com/formatjs/formatjs/tree/master/packages/intl-relativetimeformat)

I'm using https://lingui.js.org/ as a higher level abstraction over intl apis.

I don't have anything blocking usage of hermes since it works fine with these polyfills. First thing would be to try and remove usage of the intl polyfill, this one actually implements a lot of apis, the list is available here https://github.com/andyearnshaw/Intl.js#implemented.

Here are some Intl apis I use either directly or through lingui-js:

• Intl.NumberFormat for currency formatting.
• Intl.DateTimeFormat for date formatting.
• Intl.RelativeTimeFormat for relative date formatting (x days ago).

[TheSavior]

@dlebedynskyi thanks, from my quick searching it looks like IntlMessageFormat isn't part of a finalized spec. Am I looking in the wrong place?

[TheSavior]

@janicduplessis, it looks like the Intl APIs you list are a collection of multiple functions. Do you know which functions in those APIs you use? The more specific the better here :)

[andreialecu]

Hermes 0.10.0 finally fixes all outstanding Android Intl issues. (ref: 9238467)

I've been able to use yarn resolutions to force Hermes to version 0.10.0 even on RN 0.66 via:

  "resolutions": {
    "hermes-engine": "0.10.0"
  }

This allowed us to finally drop the polyfills and there's an amazing performance boost on Android as a result in our app. 🎊

[mattijsf]

Hermes 0.10.0 finally fixes all outstanding Android Intl issues. (ref: 9238467)

I've been able to use yarn resolutions to force Hermes to version 0.10.0 even on RN 0.66 via:

  "resolutions": {
    "hermes-engine": "0.10.0"
  }

This allowed us to finally drop the polyfills and there's an amazing performance boost on Android as a result in our app. 🎊

Until you need timezone conversion support though 👀

[andreialecu]

Until you need timezone conversion support though 👀

The commit I linked specifically fixes the bug in timezone conversion support that was present in 0.9.0.

[mattijsf]

Until you need timezone conversion support though 👀

The commit I linked specifically fixes the bug in timezone conversion support that was present in 0.9.0.

Thanks I was too quick with my comment sorry. Unfortunately polyfills are still necessary on iOS to be able to do the timezone conversion (when using Hermes). I read above that this is being worked on 🤞

[billnbell]

Question with hermes in v0.67.1 react-native enabled do I need this?

if (global.HermesInternal) {
  if (Platform.OS === 'ios') {
    // Polyfills required to use Intl with Hermes engine
    require('@formatjs/intl-getcanonicallocales/polyfill').default;
    require('@formatjs/intl-locale/polyfill').default;
    require('@formatjs/intl-pluralrules/polyfill').default;
    require('@formatjs/intl-pluralrules/locale-data/en').default;
    require('@formatjs/intl-numberformat/polyfill').default;
    require('@formatjs/intl-numberformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/polyfill').default;
    require('@formatjs/intl-datetimeformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/add-all-tz').default;
  } else {
    require('@formatjs/intl-getcanonicallocales/polyfill');
    require('@formatjs/intl-locale/polyfill');
    require('@formatjs/intl-datetimeformat/polyfill');
    require('@formatjs/intl-datetimeformat/locale-data/en');
    require('@formatjs/intl-datetimeformat/add-all-tz');
  }
}

[cristianoccazinsp]

What is the progress on this? INTL support is the only release blocker for us to move to Hermes on iOS. The polyfills are way too slow and incorrect.

[tranducduong1994]

Any update on IOS Intl support?

[pke]

@andreialecu

Hermes 0.10.0 finally fixes all outstanding Android Intl issues. (ref: 9238467)

I've been able to use yarn resolutions to force Hermes to version 0.10.0 even on RN 0.66 via:

  "resolutions": {
    "hermes-engine": "0.10.0"
  }

Does this make this obsolete?

 if (typeof Intl === "undefined") {
    require("intl")
    require("intl/locale-data/jsonp/nl") // may be different for you
  }

[andreialecu]

@pke: Most polyfills should no longer be required with the updated Hermes. So yes, those two should be obsolete.

You should check however if things work properly after removing them. I think RelativeTimeFormat was not implemented by Hermes yet, for example.

[pke]

@andreialecu how do I know which Hermes engine is currently bundled with my RN project?
And is there a List of not yet implemented functions like RelativeTimeFormat (which we do not use atm)?

[mrousavy]

how do I know which Hermes engine is currently bundled with my RN project?

You can check yarn.lock and search for hermes-engine.

[francois-pasquier]

is iOS still needing polyfills with latest hermes?

[nandorojo]

how do I know which Hermes engine is currently bundled with my RN project?

You can check yarn.lock and search for hermes-engine.

yarn why hermes-engine

[neildhar]

is iOS still needing polyfills with latest hermes?

As of now, yes, although we are actively working on Intl support. Support for the upper/lowercase conversion functions, getCanonicalLocales, and Collator has already been merged in trunk.

[zhiqingchen]

Same issue, Using
new Date().toLocaleTimeString()

will cause

Error: RangeError: java.lang.ClassNotFoundException: Didn't find class "com.facebook.hermes.intl.DateTimeFormat"

[gavinaboulhosn]

Same issue, Using new Date().toLocaleTimeString()

will cause

Error: RangeError: java.lang.ClassNotFoundException: Didn't find class "com.facebook.hermes.intl.DateTimeFormat"

@zhiqingchen Make sure you're including the Hermes android artifacts on the classpath. If you're using Proguard, you may need to create a rule to avoid stripping Hermes classes. e.g. -keep class com.facebook.hermes.** { *; }

[billnbell]

Question with hermes in v0.67.1 react-native enabled do I need this?

if (global.HermesInternal) {
  if (Platform.OS === 'ios') {
    // Polyfills required to use Intl with Hermes engine
    require('@formatjs/intl-getcanonicallocales/polyfill').default;
    require('@formatjs/intl-locale/polyfill').default;
    require('@formatjs/intl-pluralrules/polyfill').default;
    require('@formatjs/intl-pluralrules/locale-data/en').default;
    require('@formatjs/intl-numberformat/polyfill').default;
    require('@formatjs/intl-numberformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/polyfill').default;
    require('@formatjs/intl-datetimeformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/add-all-tz').default;
  } else {
    require('@formatjs/intl-getcanonicallocales/polyfill');
    require('@formatjs/intl-locale/polyfill');
    require('@formatjs/intl-datetimeformat/polyfill');
    require('@formatjs/intl-datetimeformat/locale-data/en');
    require('@formatjs/intl-datetimeformat/add-all-tz');
  }
}

OK, with 0.68.1 which of these can I drop?

[mattijsf]

@billnbell For me it's also unclear to what extent Intl is supported on both platforms. I would love to see some official support matrix of Hermes (sub)features for each platform per Hermes version.

[Jackman3005]

@mattijsf They have a Intl APIs page that covers what is supported/not yet supported and limitations of different versions of Android. But I believe there is still no iOS support for Intl in hermes.

I'm using a time zone library for displaying a list of time zones and it has a reasonable usage of Intl that is currently causing zero timezones to be retrieved in iOS due to the lack of support for Intl. Looks like I'll need to polyfill for iOS until this is supported with hermes. I will try something along the lines of what @billnbell has done.

Thanks for all the hard work on Hermes so far, you folks rock. I'm looking forward to when (soon?) Intl support is solid for both platforms.

[zbraniecki]

hi all. I'm one of the founders of the ICU4X project which is a Rust implementation of ICU targeting many programming environments and aiming for the ECMA-402 scope.

One of the interesting features of ICU4X is that one can pull small modules that provide necessary components without paying for the whole monolithic codebase, and compile those components to WASM or JS.

We are planning to release 1.0 quite soon and I'm wondering if Hermes would be interested in evaluating ICU4X for your needs.

[jkester1986]

We just turned off Hermes in our iOS app after recently turning it on due to discovering lack of intl support for dates/times. Do we have any ETA on when this will be supported on the iOS side?

[jpporto]

Hi @jkester1986,

The Hermes iOS Intl support (for date and time) is already implemented, but some wiring is needed on RN to surface it. We expect the next RN version (i.e., 0.70) to have that plumbing done, and full feature parity with Hermes on Android for RN 0.71

[billnbell]

Hi @jpporto - what is status os IOS support for Intl ?

[jpporto]

Hi @billnbell,

Hermes' iOS Intl support is defined here. It seems currently, Number, DateTime, and Collator are implemented. Other missing features are being actively implemented.

[datanaman]

Hi Team , we are facing the issue only on IOS after enabling Hermes :
Issue :
ReferenceError: Property 'Intl' doesn't exist, js engine: hermes
ERROR Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). A frequent cause of the error is that the application entry file path is incorrect.

Version : "react-native": "0.68.2"

Tried the below workaround in our index.ts - but doesn't seem to work.

import { AppRegistry, Platform } from 'react-native';
// eslint-disable-next-line no-undef
const usingHermes = typeof HermesInternal === 'object' && HermesInternal !== null;
if (usingHermes && Platform.OS === 'ios') {
// Polyfills required to use Intl with Hermes engine
require('@formatjs/intl-getcanonicallocales/polyfill');
require('@formatjs/intl-locale/polyfill');
require('@formatjs/intl-pluralrules/polyfill');
require('@formatjs/intl-pluralrules/locale-data/en');
require('@formatjs/intl-numberformat/polyfill');
require('@formatjs/intl-numberformat/locale-data/en');
require('@formatjs/intl-datetimeformat/polyfill');
require('@formatjs/intl-datetimeformat/locale-data/en');
require('@formatjs/intl-datetimeformat/add-golden-tz');

//require('intl'); // import intl object
}

import App from './src/App';
import { name as appName } from './app.json';

AppRegistry.registerComponent(appName, () => App);

Any other Workaround or something which we are missing ?

[billnbell]

You are not putting it in right spot. Put in index.js:

/* eslint-disable no-unused-expressions */
/* eslint-disable @typescript-eslint/no-var-requires */
/* eslint-disable global-require */
import React from 'react';
import { AppRegistry, Platform } from 'react-native';

import { expo } from './app.json';
import App from './src/App';
import AppFake from './src/AppFake';
import { configureCalendarLocale } from './src/components/member/explore/property-screen/dateHelpers';
import { setBackgroundMessageHandler } from './src/utils/notificationHandler';

const { name: appName } = expo;

if (global.HermesInternal) {
  if (Platform.OS === 'ios') {
    // Polyfills required to use Intl with Hermes engine
    require('@formatjs/intl-getcanonicallocales/polyfill').default;
    require('@formatjs/intl-locale/polyfill').default;
    require('@formatjs/intl-pluralrules/polyfill').default;
    require('@formatjs/intl-pluralrules/locale-data/en').default;
    require('@formatjs/intl-numberformat/polyfill').default;
    require('@formatjs/intl-numberformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/polyfill').default;
    require('@formatjs/intl-datetimeformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/add-all-tz').default;
  } else {
    require('@formatjs/intl-getcanonicallocales/polyfill');
    require('@formatjs/intl-locale/polyfill');
    require('@formatjs/intl-datetimeformat/polyfill');
    require('@formatjs/intl-datetimeformat/locale-data/en');
    require('@formatjs/intl-datetimeformat/add-all-tz');
  }
}
configureCalendarLocale();
try {
  setBackgroundMessageHandler();
} catch (err) {
  console.log('index.js setBackgroundMessageHandler', err);
}
const HeadlessCheck = (props) => {
  // eslint-disable-next-line react/prop-types
  const { isHeadless } = props;
  if (Platform.OS === 'ios' && isHeadless) {
    return <AppFake />;
  }
  // eslint-disable-next-line react/jsx-props-no-spreading
  return <App {...props} />;
};

AppRegistry.registerComponent(appName, () => HeadlessCheck);