:quality(90))
Implementing bilingual or multilingual support in software comes with its own set of challenges. It’s not always possible to do a simple 1-to-1 translation, as text impacts a surprisingly high number of features and teams – from development to design. This is especially true when the languages in question have distinct orientations, writing systems, and grammar.
In this blog post, we’ll discuss how to navigate these challenges. As an example, we’ll share our own experience in creating bilingual apps – in particular two that support both English and Arabic.
While we have created a wide number of multilingual apps, this particular combination of languages provided us with very interesting challenges and insights. We will look at tips and lessons learned from the development team for successfully supporting multilanguage.
Why Make a Bilingual or Multilingual App?
This is a legitimate question. If adding another language could end up being that complex, why do it?
The answer lies in the most important part of the application: the user base.
Depending on where your user base is located, restricting the app to one language might result in alienating a huge group of users.
Using one of our experiences as an example: for our Bilingual Fintech Mobile Application released on the UAE market, it was essential to have both English and Arabic (even in the MVP stage, as these are the languages spoken by most of the user base).
And there are regions that directly demand the app to be translated into national languages (we had that experience in Canada).
So the benefit of one multilingual app is clear. But if we go all the other way, why not have one app for each language or region?
That might be necessary due to many reasons, such as different countries imposing different regulations for the application (for instance, China), making it impossible to have a single all-encompassing release.
But it’s important to note: as a rule of thumb, developing multiple applications increases the complexity factor of the project – from project management to marketing and beyond – even if the versions have the same or very similar features.
General Challenges of Developing Bilingual Mobile Applications
Some interesting challenges we faced are true to any development process of an application with multiple languages.
Choosing the language stack matters
From Python to JavasScript and everything in between, each computer language has its own level of support (or lack thereof) for multilanguage.
One example: “Flutter really supported most of the edge cases we encountered and provided a huge amount of comfortable tools,” says Ruslan Zaripov, the developer who was responsible for the bilingual implementation of the Arab-English Fintech Mobile Application.
But it was not perfect: while using Flutter, we faced a very specific bug related to characters in obscured fields (such as passwords, which are obscured with **** symbols). It’s a documented Flutter issue with no official fix. Luckily that was an exception.
On the other hand, “React Native is not friendly with bilingual with different layout directions,” says Alex Vytiahlovska, the JavaScript developer responsible for the bilingual implementation of our other Arabic-English mobile application. The issue is purely around switching layout direction and React Native works perfectly fine with, for example, EN-FR translations.
We were able to develop a useful and stable application, but the changing language feature is slightly limited by the stack.
“The device detects the language when the app loads and, in React Native, there’s no way to switch layout directions in a user-friendly way. So, to change languages, the switch button restarts the application, which is not ideal for user experience,” she explains.
To make matters even more complex, operating systems are also a factor. “Working with Android and iOS was very different, as iOS reacts to text switches in a bit of a different way,” Alex remembers.
So does that mean that React Native is a bad decision? Not necessarily. Multilanguage support should be a factor when it comes to deciding on developing or refactoring an application – not necessarily the most important factor, as it all depends on the project.
Experienced developers and architects will take everything into account when starting their work.
Deciding early on and planning with the team is essential
Creating a bilingual or multilingual solution goes beyond adding a “Second Language” column to a spreadsheet and then pasting text to the code.
Adding a language impacts different teams. Some sample questions they will face (this list is very simple and far from exhaustive):
- Project Manager– How to integrate translations into milestones? Who are the owners?
- Development –How to store and display different versions of the text? How to best communicate with translators to avoid misunderstandings?
- Design – How will translations affect the interface and customer journey? Will it impact only textboxes or also images?
- …and even legal! – What changes to the privacy policy are necessary?
All that is to say: the decision of supporting more than one language is huge and should be made well before the project starts.
Having speakers of both languages onboard is valuable
No matter the languages involved, it’s very beneficial to have fluent speakers available.
At a minimum, proficient readers can find typos and errors before the software goes into production. These can seem minor but can very quickly undermine the professional image most companies want to project.
Even better, fluent speakers should be integrated as soon as possible and involved in key moments. With our projects, we noticed that these stakeholders could go beyond language and act as cultural advisors, pointing out aspects of text, interface, and visuals that can be tuned to seem more natural and organic to specific audiences.
Since this input can affect every aspect of the development process, it’s good to have it ready as soon as possible. Example: finding out at the last minute that the main app image includes a person with a hand gesture that translates into a curse in another culture (fortunately, this didn’t happen to us).
This reviewer role doesn’t have to be carried out by specific people, but ideally, it should. The development and design teams are focused on narrow tasks. Even if they speak one language the app is in (say, English), time spent thinking about the text means less time spent working on their activities.
Documentation is not always good, so expertise matters a lot
Not only multilanguage support varies wildly between each computer language, but the amount and depth of available documentation also fluctuates.
“When we were developing, the relevant React Native documentation was limited to one article from 2016, aimed at multilanguage for developers, not for end users,” remembers Alex.
Poorer documentation means more time necessary for hands-on testing. Monterail benefits from having a large team of developers with different backgrounds and seniorities – so Alex was able to troubleshoot internally and then learn and teach about her findings.
When internal resources are not available, developers can resort to official and non-official forums, but the quality of the content depends on how mature and active these communities are.
Specific Challenges With Developing App in English and Arabic
Now to discuss some thrilling challenges we faced that were more connected to working with the English and Arabic combo.
Combining LTR and RTL has huge interface implications
Writing systems can follow different directions. This is a complex topic as even a single geographical region might use different scripts. But it is very important to consider as it can fundamentally change the interface: where will the text box begin and end? Where should the designers include the most important elements?
Simply put, the direction of written scripts is categorized:
- Horizontally: LTR (Left-to-Right) vs. RTL (Right-to-Left);
- Vertically: Top-to-Bottom vs. Bottom-to-Top.
Below is a very short list of languages and their current script orientations:
- Left-to-Right, then Top-to-Bottom – English, Spanish, French
- Right-to-Left, then Top-to-Bottom – Persian, Arabic, Hebrew
- Top-to-Bottom, then Left-to-Right – Chinese, Japanese, Korean
It's important to note that this is a simplification. For example, in Japanese, web pages are mostly LTR first. Printing, on the other side, prioritizes Top-to-Bottom.
Learn more: Languages using right-to-left scripts.
Simplified overview of the writing directions used worldwide. Source: Wikimedia Commons
With that out of the way, let’s consider the combination of English (LTR) and Arabic (RTL).
These languages have different orientations, which, to some degree, will affect every screen of a bilingual application.
Implementing translation at the last minute, without good planning and preparation, will mean a good deal of rework to designers and developers alike.
“Normally text is spread around the application, which means that adding translations will involve editing almost all the code base,” exemplifies Alex.
“So it is important to keep all the text from the app organized in a key-value form in one or a couple of files from the start as this will be required by translation tools.”
Also, you can introduce a translation tool early in the project, even before having the text of an additional language available.
“It’s important to align the design and developer teams about the supported languages as soon as possible,” sums up Alex.
Sometimes text translations cannot be a one-to-one conversion
Supporting different writing systems begins with text, of course. For starters, the Arabic script has different fonts of its own.
More importantly, the vocabulary and grammar are very different from their English counterparts.
A very common occurrence is in ordinal numbers, where English uses one gender (neutral) and Arabic uses two (male and female).
|
English (neutral) |
Arabic (male, female) |
|
first |
أوَّل (awwal); أولى (ūlá) |
|
second |
ثاني (thānī); ثانية (thānīyah) |
|
third |
ثالِث (thālith); ثالِثة (thālithah) |
One consequence is that the following English phrase:
- The first customer
Has at least two valid translations in Arabic, depending on the gender of the customer. So which one to use will depend on multiple factors.
Translating might impact text size
A related challenge is text expansion or text contraction: some translations occupy more or less screen space depending on the language.
“Texts in Arabic are generally longer than in English, which causes challenges in accommodating the text,” notes Isaac Quainoo, Product Designer at Monterail with experience in multilingual apps.
Some consequences of the difference in text length are obvious: text boxes must be smaller or bigger, font sizes must be reviewed. But some repercussions are hard to predict - for example, it might be necessary to adapt the design of input fields, where users type information. And that can be tricky when using Material Design, a popular set of ready-made styles maintained by Google.
“Since Material Design excels at streamlining and standardizing visuals, creating variations of elements such as an input field becomes an edge case”, explains Isaac.
Note the overlapping text on the top right. Similar interface issues can be caused by poorly-planned use of Material Design in a bilingual app. Source: Monterail
Once again, this is something developers and designers alike will eventually deal with – hopefully, rather sooner than later.
Ruslan emphasizes that those mismatch does not appear only when comparing English and Arabic, and different language combinations will have varying gaps and overlaps.
“So the key here is to have good communication with the client/translator and ask to provide as many neutral forms of sentences for the design as possible, especially when it comes to an MVP,” he advises.
A surprising amount of elements have to be transformed
But the language switch process involves much more than text. It’s necessary to think about every element on the screen: buttons, images, menus, icons, and so on.
“While creating the Arabic version, we had to pay attention to work even on the direction of the progress bar and tooltips. Not to mention the numbers, which are different in Arabic,” says Ruslan.
It depends on the case: some elements are simply flipped such as the arrow icons. Others have to be changed altogether – for example, stars, pentagrams, and hexagrams can be interpreted very differently depending on the user’s culture and religion.
Images are also worth mentioning and show how language and culture are intertwined. In one application we developed in Saudi Arabia, we went so far as to adopt a stock photo service from that region to provide a more meaningful connection with its users (read Our Experience Working With Partners in the Middle East).
When developing our app for the UAE market, every interface requirement was examined from the get-go, leading to streamlined planning.
“We discussed the translation process with the client before implementation, which was very helpful as we prepared a list of requirements early on. After that, developers also discussed it with the designers, who did amazing work by preparing detailed versions of small reusable UI components for the Arabic version,” Ruslan remembers.
Not all things have to be transformed into RTL
Flipping everything mindlessly doesn’t work. And some edge cases drive the point home: it’s really a case-by-case scenario.
Case in point. One of our apps with Arabic support has a verification system with OTP (one-time passwords). This includes an OTP field in which the user inputs four numbers.
In this particular screen, while most elements (such as name and send button) follow RTL, the OTP field and the telephone number have to be aligned left to right. The end result is a single screen that combines elements in different orientations.
It might seem counterintuitive at first glance, but having everything in RTL would confuse users.
We were able to spot this detail early on thanks to good communication.
Summary: Navigating the Challenges of Arabic Translation in Mobile App Development
Implementing multiple language support in mobile apps requires careful planning, attention to detail, communication with the client/translator, and flexibility in adapting to unexpected behavior.
From our conversations with developers and designers, previous experience is extremely helpful. Team members who had been involved in multilanguage projects before knew from the get-go how to choose proper tools and identify potential problems before they started.
And this is compounded when the languages are very different, as is the case of English and Arabic. But the effort can wield excellent results when you want to release a quality project that truly resonates with a diverse audience.
Contributed to this post: Alex Vytiahlovska, Isaac Quainoo, Patrycja Więcław, Ruslan Zaripov.
:quality(90))