![](https://corporate-assets.lucid.co/co/7c6fd082-22f3-4acf-ac27-a373bf635b6d.png?v=1712437569187)
Internationalizing Your Software Part One: The Process
Elayne Petterson
Reading time: about 8 min
Topics:
Plan on i18n from the beginning
Even if you are initially only releasing your software in a single language, if there is any chance you’ll want it translated in the future, start thinking about i18n as soon as possible. Plan for the future by putting all user-facing phrases in a centralized location. That way, when you decide to translate them they are easy to find and work with. If you don’t start this way, it will be much harder later on to dig through your code searching for phrases, which may result in missing critical phrases that should be translated. Even if the process you begin with is not your final solution, it is a good idea to have some method for dealing with user-facing strings and referencing them in your files rather than hard-coding words everywhere. Your engineering teams will be grateful in the future, trust me.Create a scalable system
An established system with centralized, easily accessible strings is vital to internationalization efforts. It should require minimal effort and negligible time to adhere to the process; after all, an engineering team’s primary goal is creating and improving quality features, and i18n shouldn’t be a barrier to that goal. The system you create for i18n should accomplish the following things:- Make it easy for engineers to add strings
- Make it easy for the strings to be sent to professional translators
- Make it easy for engineers and quality assurance to test the software in different languages
- Be well documented and consistently used
- How and where will you store strings?
- Will you need to use different methods for your application’s frontend and backend?
- How will you organize strings (alphabetically, by feature, etc.)?
- How will you handle in-phrase variables such as names and numbers?
- How will you handle embedded HTML or similar UX requirements in your strings?
- What tools will you use for formatting numbers, dates, currency, etc?
- Who are your translators, and how will you send them new strings to translate?
- How will you ensure your translations are complete before the code is released?
- How will you make it easy to test the UI in different languages?
![i18n Process](https://corporate-assets.lucid.co/co/66be5ef6-684d-483f-8bf5-539fcda99244.png?height=660&width=735)
Translate entire phrases
Translating words individually will result in weird and awkward language. It’s better to always provide the translators with the entire phrase and let them rearrange the words and variables to match a given language’s structure. The following examples illustrate a few of the reasons why giving translators bits of phrases is problematic: Let’s say we have a translate function which takes in a string and returns its translation:const translatedString = getTranslation(“translate me”);
Seems simple enough, right? But what if the string we want to translate contains a variable?
The wrong thing to do would be this:
const agePhrase = bob + getTranslation(“ is ”) + age + getTranslation(“ years old”);
In fact, don’t do this either:
const nameLabel = getTranslation(“Name: ”) + name;
Or even:
const name = firstName + “ ” + lastName;
But, why?
In Spanish, the normal way to translate agePhrase is:
bob + “ tiene ” + age + “ años.”
bob + “ has ” + age + “ years.”
In Russian, it would be translated:
bob + “ ” + age + “ год/года/лет.”
“To ” + bob + “ ” + age + “ years.”
For context, in Russian, the name itself would be changed to the dative case to mean “To Bob.” Russian doesn’t use the verb “to be” in the present tense. And the word “years” would be different depending on if the number ended in 1, 2-4, or 3-0.
When considering other languages (and the examples above), have you thought about what to do if you need to translate into a language that isn’t written from left to right? Or if a language doesn’t use punctuation or connect names the same way you do? Language structures are complex and can differ greatly from what you might expect. Just because a word and phrase combination makes sense in one language, doesn't mean it will make sense in another—in fact, it probably won't. A good engineering solution will take that into account.
So, for the agePhrase example, a better approach would be to provide a whole string with placeholders for your translator to handle. Then you can find a graceful approach to substitute the placeholders:
const agePhrase = getTranslation(“User {name} is {age} years old”, {‘name’:bob, ‘age’:age});
An approach like this allows translators to properly translate the entire phrase so that the text of your product can read well in any language. In this three-part blog series, part two will cover more language differences and include suggestions for handling them.
Hire professional translators
Machine translations may seem attractive but are not a high-quality long term translation solution. While machine translation is definitely improving, it has a long way to go before it can understand and analyze language the same way a professional human translator can.![Google translation of a Spanish idiom](https://corporate-assets.lucid.co/co/fd4bb197-9489-4740-895d-74485521262b.png?height=387&width=584)
- A word in language A has multiple equivalents in language B or has different meanings depending on context.
- Language A has different syntax (word order) than language B.
- More information is required in the target language than in the source language. For example, to translate the word “sister” into Chinese, I need to know if it is an older sister or a younger sister. To translate “I went” into Russian, I need to know if the person speaking is male or female, and if they went by foot, by car, by plane, or by boat, etc.
- Language A uses different idioms and metaphors than language B.
- A phrase that is perfectly normal in language A is culturally inappropriate and insulting in language B (or there are other sociolinguistic differences between the languages).
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.