In part one of this series, we covered the basics of the i18n process. This post will cover more of the differences between languages and how to handle them in your code. Any time you see text or numbers that are user-facing, you should ask yourself: will every culture in the world handle and format this text or these numbers in the exact same way? The answer is most likely no, so you can either use external libraries or write your own methods to deal with these formatting differences in your code. Accounting for differences between languages will allow you to maintain a high-quality product for users in every language you offer.
Numbers
Numbers and symbols are part of every language. For example, “one thousand” may look like “1,000.00” in the US and “1.000,00” in other countries. Even with basic numbers, formatting conventions that may seem minor can actually have a huge impact. Take a look at a few instances where number formatting matters.
Dates
Even before you internationalize your product, all references to dates should access a central date file, rather than having date code scattered throughout your product. To make things easy from the beginning, don’t hardcode your own dates. There are libraries like moment.js that can take care of internationalization for you. While we may write, “March 4, 2020” in English, in other languages that would be really weird, and may look like “4. März 2020” or “4 de marzo de 2020” instead. Some languages don’t capitalize months. You probably won’t want to account for different conventions on your own in other languages, as it will take engineering and quality assurance resources every time a new language is added, and it will become a lot to maintain. So existing libraries can be very helpful.
Currencies
With currencies, it’s also important to realize that the same symbols are used for multiple currencies. For example, a “$” could indicate a US dollar or a Mexican peso, as well as being used to indicate other currencies, like the Hong Kong dollar, which is generally designated “HK$.” Make sure to properly format currency symbols so it’s clear whether you are offering the product in US dollars or in local currency.
Units of measurement
Your product won’t really seem German if your measurements are in feet and inches, so you need to account for different measurement systems. Just translating words without making unit conversions or understanding cultural differences could result in an awkward, unprofessional product in other languages, which impacts your company’s overall image. Also, while feet and inches may be most common in the US, people using your product in English may still need or want to use centimeters. So, choose smart defaults for your users, but also allow users to set their own options. Having measurement calculations in their own file in your code, and having all references to measurements access that file will simplify transformations between different unit types.
Text differences
Text direction
The direction that languages are written is a significant factor to consider. While English is written from left to right, Hebrew and many other languages are written from right to left, and several Asian languages can be written in multiple directions, including vertically. Arabic letters are written from right to left, but numbers in Arabic are written from left to right. In ancient Greek, lines would alternate between left to right and right to left. And Egyptian hieroglyphs could be written top-down, left to right, or right to left! You probably won’t be translating your product into Ancient Egyptian, but the point is that your layout may need to be flexible to accommodate other writing directions. If you haven’t translated anything into another direction before, your designers and engineers may need to work together to make things look right (or normal) for a variety of languages and text directions.Me with some hieroglyphs, in Medinet Habu, Luxor, Egypt
Text length
Text will be longer in some languages than others. So, when you first start your internationalization process, you will probably need to make UI changes to accommodate text length variation. For example, maybe some text should be moved to tooltips. Maybe some of the UI should be totally changed. Or maybe you just need to make some minor changes in your styling. In any case, it’s important to realize that you will need to dedicate some design and engineering time and resources to UI considerations once translations come in. It may be worthwhile to originally translate everything into a language you know tends to be longer than others, so you find more of the places where UI changes will be needed early on and can minimize the changes you’ll need to make after your initial i18n effort.Images that contain text will also need to be changed. In some cases, you may decide to separate the image from the text, or not use the image at all. You could also make different images for every language, which would allow for more localization options (for instance, having people in the images who look like people in the region where the language is spoken), but could also take more work and maintenance as you add more languages.
Plurality
In English, plurality is relatively simple: each word has a singular form and a plural form. Not all languages are like that though. Russian has different plural forms if the number of something ends in 1, 2-4, and 5-0. For example, the Russian word for ‘friend’ is ‘друг’
Quantity
"Friends"
1, 21, 51, 101
друг
2, 32, 52, 1002
друга
7, 37, 87, 4897
друзей
Russian is not unique in having more than two plural forms. This means that in cases where in English you may have two options--a single form and a plural form--you may need more options in other languages. So, when you pass a number as a variable into an i18n string, you should have a way to designate the singular and plural in English, but also let the translators tell you how many forms will be needed in other languages, and have a system that gives you the correct translation based on the number that is passed in.
Gender
In English we don’t change adjective endings to account for gender, but Spanish, Russian, German, and many other languages do. Every noun has a more or less arbitrary gender (in Russian, ‘book’ is feminine, while ‘window’ is neuter), and there are different forms of adjective to use depending on the gender of the noun they modify. If you give your translators phrases in context, this is generally not an issue. However, there may be other unexpected instances when gender matters. For example, in Russian, the past tense verbs that a person uses are different depending on the speaker’s gender. For example, I went (by foot, one way) in Russian would be:
Woman
Man
Russian Word
Пошла
Пошёл
English Transcription
Pashla
Pashol
On the other end of the spectrum, Finnish (and other languages like spoken Mandarin) uses the same word for ‘he’ and ‘she'.This is just another illustration of how languages are different from each other, and you may need to account for those differences in places you might not expect that may impact your internationalization process. The third and final piece of this blog series will have some final tips and insights for internationalizing your product—stay tuned!
About Lucid
Lucid Software is a pioneer and leader in visual collaboration dedicated to helping teams build the future. With its products—Lucidchart, Lucidspark, and Lucidscale—teams are supported from ideation to execution and are empowered to align around a shared vision, clarify complexity, and collaborate visually, no matter where they are. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit lucid.co.
