Simplified localization management in applications

At Axon, we develop complex web and mobile applications supporting multiple languages of the interface. In this blog post we are going to tell you how to simplify the localization process in your application.

Why do you need simplified localization management?

We always strive for superior quality of every software product we are working on. It's a common case when a quality custom product requires a multilingual UI in order to bring value for users around the globe. The more languages it supports, the more people will use.

Before we go further, let's clarify that when we start to develop an application, it has initially only one language. At this stage we need to perform some actions to make our app multilingual.

• Internationalization - The process of designing a software application so that it can be adapted to various languages and regions without drastic engineering changes;
• Localization - is the process of adapting internationalized software for a specific region or language by adding localization strings files.
  

Localization string files consist of key and value:

• Key - used in application as a reference;
• Value - translation that appears on the screen.

An example of key and value could be “txt_email” as a key and “Email” as a value.

But what is exactly so complicated here? Going forward and more in depth we will also mention common issues related to localization. 

Localization issues

Different files across platforms

There are many types of applications (iOS, Android, Web) and each of them uses special localization string files. In this blog post, we will talk about the common ones:

Because of the differences in the types of files, it is impossible to work with just one single file with translations. This is a major reason why engineers should edit these files manually.

Let's avoid such impractical actions like sending Excel files by email or messenger. Instead of it we will utilize Google Sheets as a primary solution.

However, if localization files are edited manually, there may be the following situations:

1. When editing an initial string (English for example) it’s possible to forget to add a translation to another language. If there is no translation, system will use a key instead of the translation (for example: “txt_done”) or original English translation depending on implemented internationalization logic;
2. When editing a translation file, it’s possible to potentially miss some characters or even assign a translation to another string that is unrelated to this translation. 
   

After we copied the translation from the Google Sheets file, we need to be sure that the translations are correct.

If these translations are left without changes, we may get this result: 

Different application types include the common localization string files. If we will reuse and automate the entire localization process for them, it could save the project budget and allow engineers to focus on the development instead of routine actions.

Our approach to the localization management

At Axon, we use an LMS (localization management system) called Loco. This service has a rich functionality and REST API. 

REST API is REpresentational State Transfer Application Programming Interface or REST API. It means when a RESTful API is called, the server will transfer a representation of the requested resource’s state to the client system.

With the help of Loco, the localization takes the following form:

We can create a solution that uses REST API and downloads files with strings translations for each language and application type, then puts string files into the appropriate project’s folder. Localization is platform agnostic, so it supports many formats including files with plural forms. And we used the Ruby language.

require './Classes'

## Step 1: Set Platform. 
## Examples: 
### MyPlatform::IOS
### MyPlatform::ANDROID
### MyPlatform::BACKEND
### MyPlatform::WEB
myPlatform = MyPlatform::IOS

## Step 2: Set Path for localizable file(s).
### IOS Explanation: "../ProjectFolder/../Folder with lproj files"
### IOS Example: "../Demo/Resources/Strings"
### ANDROID Example: "../app/src/main/res/values"
filesPath = "../Demo/Resources/Strings"

## Step 3: Set TOKEN from localise.biz
apiToken = "XXXXXXXXXXXXXXXXXX"

## Step 4: Create a Configuration
configuration = ApiConfiguration.new(myPlatform, apiToken)

## Step 4.1: Set a variable with an array of localizable files
### Param 1: Name of localizable file. 
### Example: "Localizable.strings", "InfoPlist.strings"
### Param 2: Tag for the file. 
### Example: "ios-localizable", "ios-infoplist"
### Param 3: Path for localizable file
### Param 4: Api configuration
### Param 5: File Extension type
### Options: IOS_STRINGS, IOS_STRINGS_DICT, ANDROID_XML, WEB_JSON
arrayWithLocalizableFiles = [
LocalizableFile.new("Localizable.strings", "ios-localizable", filesPath, configuration, FileExtension::IOS_STRINGS)
      LocalizableFile.new("InfoPlist.strings", "ios-infoplist", filesPath, configuration, FileExtension::IOS_STRINGS_DICT)
]
## Step 5: Iterate through files
arrayWithLocalizableFiles.each do | file |

## Step 5.1 Define below downloading of new languages for the file
### Example: file.downloadFileWith("en", "English", "ios")
### Example: file.downloadFileWith("ru", "Russian", "ios")

file.downloadFileWith("en", "English", "ios")
file.downloadFileWith("nb", "Norvegian", "ios")

end

In an LMS we usually have three projects: Mobile, Backend and Web.

“Mobile” is mainly used for iOS and Android because these platforms share a lot of common strings, as other platforms use separate projects.

When we need a new string we create them in LMS. In this diagram, we have created a string “Email” for the login screen with key “txt_email”. The “Asset ID” here is a unique identifier in an LMS and initially intended to serve as a key for this string. Optionally, if the keys are different for iOS and Android, we can specify different keys for iOS and Android as the need arises.

After creating strings in an LMS, they have a status of “Untranslated”. We will then send a link which opens a view of the translation to the client . Besides, the LMS also allows you to invite multiple users that could also be translators. Clients can delegate this to either translators or engineers as needed.

Depending on the situation of a project or its workflow, we may simply upload strings before each build or upon client request after the translations are ready. 

Thus, the process is automated and the development team can devote minimal amounts of time to routine work with very little mistakes attributed to the localization process.

Once the Ruby “Configuration file” has been configured for each application type, it works using a single command and loads the appropriate translation files to the appropriate destination folders.

Different localization options may cause different software development costs, regarding on the initial request and requirements.

Other LMS options

There are a lot of LMS options throughout the Internet, if you have any special needs you can look at these options:

• poeditor.com 
• lokalise.com 
• localise.biz 
• phrase.com  
• lingohub.com   ‍
• weblate.org

Conclusion

At Axon, we know localization management could help your digital products significantly extend by covering the target world wide audiences that speak different languages. The primary challenge is to perform a localization management in the right way from a technical perspective. 

Our software engineers have developed a set of best practices that is able to automate this process efficiently. By applying these techniques we have striven not only to simplify the localization management on the current development stage of products, but also to create a basis for their future seamless growth. 

In the next blog post from the custom software development series, we are going to tell you about the software development projects Axon engineers have been working on recently.