React-native-i18n: Expose locale on navigator.language rather than NativeModule

[brentvatne]

In the same way that the geolocation API for react-native is exposed through navigator.geolocation, it would be great to have this exposed as navigator.language and possibly even upstreamed. Thoughts?

[mmazzarolo]

Hey @brentvatne, sounds cool!
I'll need some guidance for it (I'm trying to maintain this lib as @AlexanderZaytsev is not active anymore, but I'm not super skilled on iOS/ObjectiveC) though.

[zoontek]

@brentvatne The react native geolocation API is based on JS standard, that's why it make sense:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/geolocation
https://developer.mozilla.org/fr/docs/Web/API/Geolocation

Use the global scope to expose navigator.language might not be a good idea. A standard for I18n exists too: https://www.ecma-international.org/ecma-402/2.0/ and is polyfilled by formatJS. You can use it in react native with react-intl.

[brentvatne]

The react native geolocation API is based on JS standard, that's why it make sense:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/geolocation
https://developer.mozilla.org/fr/docs/Web/API/Geolocation

I am aware of this, which is why I suggested navigator.language which is documented here: https://developer.mozilla.org/en-US/docs/Web/API/NavigatorLanguage/language

Use the global scope to expose navigator.language might not be a good idea. A standard for I18n exists too: https://www.ecma-international.org/ecma-402/2.0/ and is polyfilled by formatJS. You can use it in react native with react-intl.

It's the same thing as using navigator.geolocation. I think this should be upstreamed for that reason.

[zoontek]

@brentvatne Didn't know about that. It's might be a good idea then.

[brentvatne]

As a sidenote, by upstreaming the change this library would become immediately compatible with create-react-native-app

[zoontek]

@brentvatne Would you mind submit a PR?

[brentvatne]

@mmazzarolo - if you're interested in doing this still, feel free to ping me on messenger or slack!

[brentvatne]

@zoontek - no sorry, no time :( I just wanted to make sure you guys were aware that there may be a better way than including a native dependency in this lib

[mmazzarolo]

@brentvatne I'll try to take a look at it in the next few weeks (I still have 0 experience on the subject though), but @zoontek is much more prepared than me on this lib now

on a side node: @zoontek, thank you for being super active here 👍

[zoontek]

@brentvatne After some tests for the new version, I'd rather not expose language constant because they're not reloaded after a language change on Android. I could use a Proxy with a Promise, but I'd rather not, it's hidden complexity.

[brentvatne]

@zoontek - what does the web do in this case? I think there is no need to reinvent the wheel with a custom api.

If the web doesn't support it, then you could add an additional API to DeviceEventEmitter that emits some event.

[brentvatne]

To add to the above comment, despite this being an extreme edge case, there are solutions to it that don't add more complexity.

The navigator.language constant should be stored in JS so you can access it synchronously and we can update that value whenever we like (eg: in response to DeviceEventEmitter, automatically updating it behind the scenes). More about this pattern in this talk: https://www.youtube.com/watch?v=-Izgons3mec

An alternative to using DeviceEventEmitter, for example, is that when the app is backgrounded and then foregrounded again, you can check if the value changed and update it on the JS side if so.

[zoontek]

@brentvatne I'm currently working on a PR to add this directly in the react-native project.
It'll support navigator.language, navigator.languages and Intl.addListener('languagesDidChange'). I think it's a better solution than force the devs to uses a specific translation lib 😄

[brentvatne]

awesome @zoontek! :)

[zoontek]

@brentvatne You can find it here: https://github.com/facebook/react-native/pull/14568