Most companies bake English assumptions into their design patterns, another form of tech debt that gets increasingly expensive to fix over time. Here we’ll discuss a few simple things you can do to future proof your design so that if and when you do decide to launch in new languages, the amount of effort required is incremental.
The average word and sentence length varies in other languages, with German being a notorious example of long words. To future proof your application, it is a good idea to use variable size elements that will shrink or expand as needed. There are limits to this, of course, but it is a good idea to refrain from sizing elements for a specific length text. The reason for this is that sometimes it will not be possible for translators to come up with an arbitrarily short translation.
Pseudolocalization is a technique for simulating what your UI or layout will look like in a language that has shorter or longer words. You can modify the wrapper function we described in Future Proofing Your Codebase For Global Readiness to implement pseudolocalization. This will typically expand the text by 20-30% and convert regular English characters into accented versions. This does several things for you.
First, it enables you to test your UI with longer texts. So if longer words or sentences will cause a text overrun or wrapping issue, you’ll be able to spot that more easily, even before you do any translation.
Second, it enables you to spot strings that are NOT being passed through the localization wrapper function, and therefore would not be translatable.
While using unsupervised machine translation is generally not recommended for in-app content, it is very useful for previewing what your app or service will look like in other languages. Even if the translations are not 100% correct, word and sentence length will generally be similar to what a polished translation will look like. The advantage with machine translation is the results come back almost instantly, so developers can evaluate how new features look in other languages as they are being developed.
While most languages are displayed in a left-to-right orientation, a few like Arabic, Farsi, Hebrew and Urdu are displayed right-to-left. Most companies fail to support these languages until much later in their development, even after they have launched popular western and asian languages. This becomes expense to fix, much like the problem with unlocalizable strings we discussed in Future Proofing Your Codebase For Global Readiness
In general, the solution to this is to write a helper function that you use to generate HTML for page elements. There is a directive dir whose value can be ltr (default), rtl, or auto. What this helper function will do is override the default value when it sees that the element contains text from a RTL language (each of which has a specific Unicode code space for the underlying alphabet). Then, if it detects Arabic text in a block, it can add dir=rtl to it, so that text is displayed in the correct orientation.
There is some nuance to this, for example in bi-directional text that contains a mix of languages (a common occurence with Middle East users), but this general design pattern works well.
It is good idea to hire one or more engineers who speak a Middle Eastern language so they can verify that your app or service looks right in RTL or bi-directional orientation. It doesn’t have to be fully perfect until you launch RTL interface languages, but with relatively little effort you can make sure that you are not accruing tech debt that will block future releases in this region.
If your service allows users to create their own content, they may want to write in their language, even though the app itself is not yet localized. At Notion, we had a huge user community in Korea early on, even though Notion was only available in English. Users at the time were mostly startups and were able to navigate the app in English, but they would write most of their documents in Korean.
The main things you’ll need to do to unblock users are: