Today, I’d like to talk to you about internationalisation in React Native apps and especially about ambushes that we found on an app we are working on (and shipping it in 20 languages). On one particular occasion, I had to implement Arabic and Hebrew languages and everything was going smoothly. We had that really nice dynamic questionnaire in an horizontal FlatList that was building itself gradually with the user’s answers, adding the needed questions to a list after each answer. And on Android, the app was adding the questions to the right side of the list instead of the left side where they were supposed to be… but why!? I’ll tell you what happened further in this article.
Internationalisation, or more often seen as i18n for short, is everything that lets a user experience and understand the apps we’re making, regarding their “usual usage”. It concerns obviously translations in another language, but also timezones or UX.
This stands for Left-To-Right and Right-To-Left. Majority of languages is LTR but there’s also some RTL languages and they should not be neglected, especially if we want our app to be worldwide. There are around 600 millions people speaking a RTL language in the world, that’s a lot! Some examples are Arabic, Hebrew, or Persian.
Depending on the OS, handling internationalisation is already automatic and provides relatively good results (languages are already tagged as LTR or RTL in the OS for example). There are a lot of differences on how it is handled between iOS and Android though as we’ll see a glimpse of this a bit later.
There’s also several libraries for React Native that do the job like Luxon for everything date and timezone related for example, or i18n-js, react-intl and i18n-next for translations.
The main internationalisation points, linked to languages, that we can think of from the beginning are often these ones:
👉 View components’ designs to handle RTL and LTR
👉 UX (Horizontal scrolling direction, etc) in case of RTL languages → It has to be reversed
And seeing all the troubles I encountered on this topic, I was thinking that issues that can impact up to 600 million app users in the world surely would have been searched and solved by other developers. Right…?
Now we know all what we have to know, back to my dynamic questionnaire in an horizontal FlatList in Arabic and Hebrew and the Android version adding questions to the wrong side of the list. You can see the different behaviours below:
On Android, after selecting an answer, we go back to the beginning - to the right
On iOS, we have a normal behavior: after selecting an answer, we have a newly added question and we go on it - to the left
While I was struggling with my left and my right, I inspected everything but the conclusion was still the same: why on Android the list behavior was that different?Well, even the Internet didn’t know about this. I had to roll my sleeves up and ended up in the source code of RN’s FlatList to finally understand why…
I noticed that there’s a lot of small troubles on internationalisation that can be unknown unless you’ve faced them, because there’s not a lot of documented answers, including libraries issues and even React Native ones! Here’s an example that I have encountered and how I avoided it with my small experience on the subject:
👉 Solution: Indicate a special character at the beginning of the string when it’s needed!
👉 i18n only checks the first character of a string to decide if it’s a LTR or RTL string. This can lead to misunderstandings in reading directions, for example if a RTL string has a LTR name at the beginning (like your app name for example!)
👉 There’s 2 ways to specify reading direction:
Phew! I hope you learnt how to dodge some bullets here! The key point to handle a perfect internationalisation is: be careful of how Android handles it! This OS supports less features provided from tools and libraries that React Native can use, whereas on iOS everything seems to be natively supported. We also learnt that, despite having several alternatives to the “same thing”, libraries don’t always offer RTL support for what they bring. If you’re planning to make an app that will handle these languages, keep in mind that not all your libraries do! Finally, we learnt that, even if there’s a lot of users who speak a RTL language, there’s sadly not much information on RTL issues on the Internet. So I hoped this small article helped you a bit or made you curious on the subject!
And you? Did you encounter other issues linked to internationalisation in your apps? Feel free to share your problems (and your solutions too!) through my contact info below!