Localization at SafetyCulture

https://unsplash.com/photos/ZEZLu8xPpv4

In 2021, SafetyCulture had an initiative to enhance our platform so that all parts of the iAuditor product can be localized. This would allow us to tailor the product experience locally to a country or region, which is beneficial especially to our non-English speaking users. Up to this point, only our mobile application was localized, which caused a disconnect as we also have a web application which users also rely on.

As an engineer in the localization team, I will talk about some important topics, as well as the challenges and lessons learnt on our localization journey.

What needs to be localized?

The first question to ask is what needs to be localized? The short answer to this question is: anything the user sees. This includes:

1. Mobile (iOS and Android) applications, including push and SMS notifications.
2. Web application.
3. Product emails that are sent to the user, such as emails to confirm your registration.
4. Invoices, including the support of multiple currencies.

It is important to note that when it comes to localization, there are also non-engineering tasks that need to be in sync with engineering. For example, do you need to also localize your company website and knowledge base articles? Do you need to hire marketing and support personnel who speak the languages of the markets you are entering?

How is localization done?

The next question is how do we localize our applications? Let’s have a closer look at how localization is done on our web application, which is written in React. We use the linguiJS framework for translations.

1. All strings in our web application are wrapped in translation tags (e.g. <Trans>).
2. These strings are extracted into language specific JSON files, called catalogs.
3. Our web application’s GitHub repository is integrated with the Crowdin translation platform, so that as soon as new strings are added to the catalogs, they appear on Crowdin.
4. Human translators translate our strings on Crowdin.
5. Once translations are complete, Crowdin creates an automatic pull request to merge translations into the language specific catalogs.

Challenges and lessons

We’ve faced many challenges in our localization journey, and have learnt many lessons. Here are some of them.

Providing context

Providing enough context to the translators is one of the most challenging aspects of localization. Consider the word Open without any context to a Spanish translator.

As you can see from the above table, providing context is critical in order to get the correct translations. To prevent incorrect translations and the constant back and forth with translators, it is important to ask engineers to add context to all strings. Context can be part of your string catalogs and should be accompanied by screenshots. It can be difficult to get other teams onboard with this process, hence the next point…

Socialising best practices for localization

At SafetyCulture, localization cannot be done by one team due to all the different stacks and the size of the applications. All teams, including engineers, product managers and designers need to do their bit. This means the localization team actively talks to other teams on best localization practices.

Examples of how this is done are:

• Speaking at our frontend and technical leader communities about best localization practices, with accompanying confluence guides to use as references.
• Asking localization related questions at engineering design and architectural reviews. E.g. does this new product feature contain any customer facing text, and is that text localizable?
• Speaking at engineering new starter onboarding to inform new engineers about localization. There is a good chance that a high percentage of engineers have never thought about localization. If they have, then great, you can ask that person for advice if you have a difficult localization problem.
• Present at lunch & learn presentations to inform the wider engineering group of best localization practices.

Date and time formats

Before the localization initiative, dates and times across our web application was very inconsistent. We had 3 separate date time libraries to format our dates and times, each with small differences. Our first step was to standardise and use 1 library, and also to use a consistent date and time format.

As we added support for more languages, we soon realised that there was no “one size fits all” format for dates and times that could satisfy all users. To illustrate this, consider this date and time format: 01/12/2021 3:30 PM.

Did you know:

• US dates have the month first, like 12/01/2021.
• The French do not use AM/PM in their times and always use 24 hour time.
• Germans prefer dots instead of slashes in their dates, like 01.12.2021.

At SafetyCulture, we could not find a once size fits all format for dates and times, so we provide several formats and allow the user to choose.

UI challenges

Whenever a new language was added, we found that certain UI elements in our web app was designed with a bias towards English. For example, see the Commencer l’inspection button in the table below. Note that a language like Chinese will have the opposite effect of shorter text lengths. It is important that your UI elements are not biased towards English, and that they adjust depending on the text length.

Avoid string concatenation

Medium priority translates to Prioridad media in Spanish. Notice the ordering of the words have changed. This means we cannot assume the order of words in a sentence based on English, and hence we need to avoid string concatenation in our code.

For example, do not do this:

const priority = "Medium"; // or High | Low
const priorityLabel = priority + " priority";

Instead, do this:

let priorityLabel = "";
switch (priority) {
  case "Low":
    priorityLabel = "Low priority";
  case "Medium":
    priorityLabel = "Medium priority";
  case "High":
    priorityLabel = "High priority";
}

This way, the translator has the complete string to work with. It is often an inconvenience for engineers as it can cause code to get bloated and less readable. However, the upside of avoiding string concatenation is that your text will be translatable.

The little things add up

Quite often, we found that we have missed little details when localizing part of our stack. For example, after localizing our web application, we found that images (including our logo) have English text, and sample pre-filled data aimed at onboarding the customer is in English.

Another example is after localizing our emails, we discovered that while the content of the email was now localized, we missed localizing:

• the email subject, which is not part of the email body
• the email From field which said “iAuditor by SafetyCulture” (the word “by” needs to be localized)
• images/logos containing text

Paying attention to detail from the start to the little things will help you plan better and make better estimations.

Final thoughts

Localization is more than just making your applications translatable. Strong processes need to be developed that are also easy to follow. These processes also need to be well documented, updated, and continuously communicated to the wider engineering group.

I have definitely not covered all the important topics and challenges around localization, but I hope I have raised enough important ones that gives you something to think about as you start your localization journey.