Help

Management
Translation
Integration
API

i18n Workflows - How to develop localized software

Translating software is a 2-way step. The first step is to internationalize your software. The second step is to localize your software.

Software Internationalization (i18n)

Software Internationalization means extracting the translatable text from your views into a language file. It typically means replacing the text by a function referencing the text you just extracted out in your language file so that:

  1. the text is displayed as usual when using the software in the source language,
  2. and the text is translated when using the software in a target language.

This is typically a task done by a software developer, as the task involves changing a lot of code, and can be complex at times.

Software internationalization also means adapting your software to other cultural differencies, such as or geographic areas, laws, currencies, … For instance distances in British English or American English are typically measured in miles, while they are measured in kilometers in other countries.

Once you are done internationalizing your software, you can start time to localize it, and this is where WebTranslateIt comes to help.

Software Localization (l10n)

Software Localization means translating the language file into different languages. It a simple process which fundamentally is just replacing the source text in the language file by its translation, but it can become unmanageable at scale. Here is a list of problems you can encounter when localizing a software without any software localization management tool.

  • Translating a software into n languages means dealing with at least n different translators,
  • Without a proper communication medium in place, a text unclear without context often leads to receiving n times the same question,
  • Software is a repetitive, iterative process and language files are iteratively updated as well, which is difficult to manage and keep in sync manually.
  • Translation tools are often not able to open technical language files (like JSON, YAML),
  • The translators dealing with the language files don’t have access to your code to understand the context,
  • For managers, sending and receiving the updated language files means sending and receiving e-mails, or using a file sharing app (dropbox, etc),
  • Testing and verifying work is also complex (how long does it take to answer the question: “has this segment with a character constraint been translated in less than 20 characters in all languages?”),
  • While your software is ready to release and pending translations, the translation team needs some time to actually translate and test your localized application.

WebTranslateIt helps with some of the pains of Software Localization, and defining a proper process that fits your team helps with the rest of them.

Streamlining your translation process

  1. Set up the languages: Add the source language and the target languages.

  2. Upload the language files you want to translate to WebTranslateIt. Having them online will allow you to work collaboratively. We developed a Command-Line-Interface tool called wti which makes it easy to synchronizing your language files with WebTranslateIt.

  3. All the strings in the language file are extracted out and statistics are generated. Translators can see exactly what needs to be worked on. If they have questions, the built-in commenting feature lets them ask a question that will be visible to the rest of the translation team, so the same question won’t be asked twice. Since translators are no longer working on one file, but on a database of strings, more than one translator can work on translating a file at the same time, which speeds up the process.

  4. Software development is a iterative process. So when you have a new feature is ready for translation, you update the source language file and the strings that have been removed from your file are automatically removed from the translation interface and the target language files, and the new segments to translate are automatically added to the target language files.

  5. When the whole project has been translated (or whenever you decide), you download the language files back onto your app. On the next version of your app, you repeat the steps 2, 3, 4 and 5.

Continuous Localization or Agile Localization?

First, let’s define what Continuous Localization and Agile Localization processes are.

Continuous Localization is the idea that the translation process is never ending and your content must continuously be ready for a release. It means that you will end up with untranslated segments on your app from time to time. But because you’re continuously releasing updates, the missing translations will be released almost as soon as they are translated.

Agile Localization is a process composed of 3 phases that repeat themselves: development mini-sprint, release in source language parallel to the mini-sprint of translation to target languages, release in target languages — then back to development mini-sprint and so on.

WebTranslateIt works with both a Continuous Localization or Agile Localization process.

Working with Feature Branches

Maybe your team works with feature branches and wants them translated. Feature Branch A is ready and the developer uploads the updated language files to WebTranslateIt. When the Feature Branch B is ready, the developer also uploads the language files to WebTranslateIt. By doing to, he overwrites the file push done by the other developer and removes the text to translate from feature branch A.

WebTranslateIt currently doesn’t support working on branches, so you need to define a i18n process that doesn’t rely on branches. The solution is to set up an integration branch for i18n.

Solution 1: You can decide that every Friday all the features that are ready to release into a i18n branch. When everything is integrated and stable, push the language files from the i18n branch to WebTranslateIt and let the translation team work. The following Wednesday the translation team might have finished its translations. Integrate these translations and release the changes. This is the workflow that you need to adopt if it isn’t acceptable to have untranslated content on your app.

Solution 2: Merge the feature branches as soon as they are ready on the main branch and upload the language files to WebTranslateIt from the main branch. You will do another release with the updated language files when they are ready.

Next Up: Supported File Formats. WebTranslateIt supports over 80 different linguistic files… »