Mobile App Internationalization
Over the last few months, we’ve been sharing some of our top picks for mobile app and development conferences and some insights from our favorite talks. Today, we’d like to focus on one of the talks from this year’s edition of Reach Boston, where Robin Dykema tackles the issues of mobile app internationalization (or i18n for short). To start us off, let’s take a look at the React Boston conference.
What is React Boston?
React Boston was born out of ReactJS Boston, a local react user group that hosts meetups every month. Sponsored by Wayfair Tech, the event grew to the point ReachJS Boston and Wayfair decided to launch a yearly conference. So, in 2017, this two-day conference was created. React Boston is hosted in Boston’s Back Bay neighborhood and is aimed at developers of all backgrounds, skill sets, and experience levels.
Past speakers have included Laura González from The Guardian, Robert Zhu from Facebook, and Houssein Dijirdeh from Google, among many others. The talks cover a wide range of topics related to React, such as designing a component kit, various aspects of GraphQL and piloting a drone with React. There are also plenty of opportunities to socialize. The 2019 event was held on September 21-22, with ticket prices ranging from $375 to $499 (including breakfast and lunch meals, as well as access to the closing party on Sunday). You can take a look at this year’s talks here.
The speaker
UI engineer Robin Dykema was in charge of delivering the fun and meme-filled talk called “Sacré Bleu! The Trials of Internationalizing Your ẨṔṔŁîÇåŤḯṏÑ�”. Dykema works at the Austin, TX office of Taulia, a company aimed at delivering capital solutions. With offices in five countries and a worldwide market, Taulia supports 18 different locales.
Turning back to Dykema, she is passionate about problem-solving and working with JavaScript frameworks and technologies. In the talk, she discussed what it means to truly internationalize an app and some of the common issues that may pop up. Let’s take a look.
What is internationalization and why does it matter?
Dykema started off by explaining the problems that not internationalizing a product has for users. This is something most of us have experienced when traveling to a country with a different language and running into signs or restaurant menus that are poorly translated (if at all).
So what is mobile app internationalization? And how is it different from globalization (g11) and localization (l10n)? Well, as Dykema explains, internationalization is what we generally do first when creating an app and where developers work. It’s all about designing software so it can be easily adapted to various languages and locales later on with no engineering changes. If you do it well, you only need to do it once and can add another language without any of the issues we’ll see below. Then we have localization, which is the adaptation of the content of your product to different markets. Simply put, internationalization is what goes under the surface while localization is what users actually see. Globalization, on the other hand, is a blanket term for both concepts.
Now that we have a general idea, let’s focus on why mobile app internationalization is important. As Dykema reports, over 50% of the web is available in English and most of it is translated for us, English speakers. However, English speakers make up only 25% of internet users and, as more people gain access to the internet, that percentage will shrink. This means there is a huge discrepancy between availability and need and, therefore, from a marketing point of view, it makes sense to be able to offer different languages to people that do not have access to a substantial amount of the content.
In the US alone, there are 64.2 million people that speak a foreign language very well and 25.6 million that speak English less than “very well”. As Dykema points out, even if your app is only going to be used within the US, you’d be missing out on 25 million potential customers. Not to mention that internationalization is a part of accessibility and it is our job to make sure the web and apps are accessible to everyone.
How can I set up translations using an internationalization framework (react-i18next)?
Dykema bluntly states something we should already know: Google translate is not going to cut it. The quality is poor and it can lead to terrible misunderstandings. She then goes on to explain how to set up an app in several languages with the internationalization framework react-i18next. This tool is part of a larger ecosystem, a JavaScript library with versions for Angular, Node, PHP, and many others. react-i18next provides standard features (such as plurals and interpolation) and plugins to detect user language, as well as loading and caching the translations—which is helpful if your app is really large. The tool is pretty flexible and scalable, and you can check out the video around minute 10 for a step-by-step guide on how to set it up.
What are the most common problems?
As Dykema points out, mobile app internationalization does not necessarily involve more than one language. There are cases where internationalization is necessary within the same language and Dykema used part of her talk to share some examples of issues within the same language as well as between different ones.
1.1 – Problem: dates, time, time zones, calendars, numbers, and currency. Some examples of this are how the US and the UK have different date formats (mm/dd/yyyy vs. dd/mm/yyyy) and how the calendar week starts on different dates (on Sunday for the US and Monday for the UK). Moreover, some countries follow a 12-hour format while others follow a 24-hour one. Not to mention you might also have issues with currency as there are American dollars, Canadian dollars and Australian ones, just to name a few.
1.2 – Solution: Dykema mentions there are lots of open-source libraries that can help you sort out this type of problem, such as Moment.js, date-fns, luxon and day.js (although not all of them support time zones), and there is also a JavaScript native API called Intl, which includes relative time format, currency, plurals, etc.
In addition to using these tools, you should stay consistent and keep communication open. You can store dates in UTC (Coordinated Universal Time) and numbers as integers to make things easier by allowing formatting to take place on the front-end.
FYI, if you’re wondering where all the data for localization comes from, it is provided by the Unicode CLDR (Common Locale Data Repository). This is a project by the Unicode Consortium to provide locale data, which includes translations for language names, country and territory names, currency names, time zones, calendar fields, number patterns, and more.
2.1 – Problem: non-Latin characters. It often happens that, when non-Latin characters come up and they’re not properly encoded, your software may show strange symbols, question marks or error messages. You might think this is an issue only when dealing with other languages, but this happens even within English as people’s names may contain non-Latin characters that your software may consider invalid.
2.2- Solution: Dykema advises to use Unicode when possible to encode and represent the writing system and, therefore, avoid these issues. If you decide to use non-Latin characters, she states you should take special care when sorting and be aware of what you regex are checking for.
3.1 – Problem: designing with only English-speakers in mind. Dykema states this is actually a UX issue but it is still very important. A common example is the size of buttons which limits the number of characters that can be displayed. You’ll be safe when localizing into Japanese but will run into trouble with Spanish or German.
3.2 – Solution: you should talk with the UX designer to make sure they allow for enough flexibility and space for translated text to fit into the design. A good rule of thumb is that if the English text is fewer than 10 characters, you should leave room for three times the number of characters. If the text is over 10 characters, you should leave room for 30% more characters. You shouldn’t use fixed widths and you should keep your CSS flexible.
4.1 – Problem: supporting right-to-left languages, such as Arabic or Hebrew, where everything is “mirrored”.
4.2 – Solution: you can add dir=”rtl” to your Html code and try using flexbox (which has flex-start and flex-end) instead of using float/text-align (left/right) to solve any directionality issues. Moreover, Dykema suggests you name things based on what they do and not what they look like—for example, using “previous” and “next” instead of “left” and “right” on arrows—to avoid problems when changing direction in these cases.
In addition to these specific cases, Dykema added some final advice regarding common mobile app internationalization pitfalls:
- Always add a language tag in your Html code (<html lang=“en”>). You can use react-helmet for dynamically updating the language if you want.
- Be careful with routing when dynamically naming it as it will not support all languages.
- Be careful with fonts as they don’t all support every language.
- One character can have meaning in some languages, like Chinese, so you might want to be careful if you add warnings for length on specific input fields.
- Don’t concatenate strings as grammar structure is not the same in all languages.
Final takeaways
At the end of her talk, Dykema shared some important final tips we thought were worth mentioning:
- Design your app to be language, region and culture-independent.
- Use open-source projects to help you solve problems you didn’t even know existed.
- Globalizing means bigger markets, inclusiveness and better code that is extendible and easier to manage.
Mobile App Internationalization Conclusion
Dykema showed us that mobile app internationalization is important regardless of how many languages or locales your app is intended for. Taking internationalization into account from day 1 can make a huge difference and save you time and money down the road. We hope you can put her tips to good use when developing your next project.
