Date and time text is not localized in Khmer

[arky]

Currently the date and time text is not localized when you change the language of mapeo.

[ErikSin]

Hey Arky! Can you clarify what you mean here? Thanks!

[arky]

@ErikSin Do you notice the time string '15 seconds ago' is not translated. In other project this is translated using moment.js or similar libraries.

[ErikSin]

Oh I see! Thanks for putting this on our radar

[gmaclennan]

Hi @arky, these fields are supposed to be localized but it looks like they are not localized for Khmer. Do you see this problem with any other languages? The fields are translated for Spanish and Thai for example:

For localization we depend on the built-in ICU support that comes with the Javascript runtime. Currently Mapeo Mobile uses react-native-v8 as its JS runtime (e.g. the same JavaScript engine as Chrome). The fact that the date time field is not translated suggests that this data for Khmer is missing from the ICU package that is included in the react-native-v8 build that we use. I am not sure how to change this, since I don't really understand the build steps for react-native-v8 and can only see this flag for Intl support: https://github.com/Kudo/v8-android-buildscripts/blob/main/scripts/build.sh#L23

This is a tricky one to solve; I see a few potential solutions:

• Attempt to build react-native-v8 with a version of ICU that includes Khmer date-time data, however this could add significantly to the APK size.
• Switch to Hermes JS engine (which we have been planning to do anyway for lower memory usage and better performance) which uses Android built-in ICU data, however it does not yet support relative date-time formatting, and the features are limited to what ICU support that Android has, which varies a lot from version-to-version.
• Polyfill Intl.RelativeTimeFormat specifically for Khmer language (and any other language without built-in support). Ideally we would do this at runtime so we are not loading an expensive polyfill (that can slow down the app) for other languages.

I think the polyfill might be the best way to go. I think we can check for support for a language at runtime using Intl.RelativeTimeFormat.supportedLocalesOf, and then polyfill as necessary. This is going to be a hard one to prioritize, since I think it could be quite complex to solve and affects a small number of users, but if you want to try to tackle it we would definitely support you.

Dd team: as we discuss collecting metrics, it would be good to see what languages are being used in Mapeo and which languages are supported by the Intl APIs that we currently use, so we can know which languages we need to polyfill (if any, beyond Khmer).

[arky]

@gmaclennan Thanks for the detailed comprehensive response. At the moment, I don't think we have to take any additional steps until the eventual transition to more performant engine.

I have trainings scheduled with our Khmer partners in the coming weeks. Will chase down the translators, collect additional feedback and file bugs where needed.