There are different approaches to a localization workflow. However these five steps are common:
- Uploading the main language file
- Reviewing (sometimes not needed)
- Downloading all languages files
- Publishing to end-users
A localization process usually involves 4 types of collaborators:
- Software developers
- Product managers, product owners, project managers, localization managers
- Translators, copywriters, marketers
- Reviewers, quality assurance (QA) members
The process usually starts with developers, as they add string keys to the code while programming the screens shown to end-users. Each text on the screens is identified by its key, which helps developers to select the proper text.
Localization files contain the keys & translated text pairs. So depending on the localization file format used, it usually ends up with one file per language for end-user.
There are many localization file formats: Apple Strings or Stringsdict for iOS, XML for Android, JSON/YAML for Web, etc. Since these files are structured and intended to be used by machine/software it is hard to understand their structure for a non-technical person.
1. Uploading the main language file
It starts with the main language content provided to a team of translators.
In most cases, there are already some localization files (in just the main language or in multiple languages that are partially or fully translated). It’s a good idea to do the initial project set up using Localizely web app, and when you get familiar you will be able to automate the upload process via Localizely REST API.
Once you create a project, simply upload your file(s) via Upload page for your project.
With turned on branching for a project (via Project Settings page), you can handle localization content for different versions of your software. For example, if you released version 1.2 of your app, and you actively work on version 2.0, you would like to use 2 branches in Localizely for them. In case you need to make minor localization changes for 1.2 but you don’t want that change for 2.0. You will be able to see exactly what is changed between branches.
You can invite a team of in-house translators or invite a third party translation agency.
Besides helping with the automation of localization process, Localizely has a collaborative editor that is easy to use, and reminds of Excel files that teams initially tend to use for persisting translations.
Assuming you’ve set up a team of translators and there are new strings uploaded, it’s time to set up a Task.
Tasks help managers to clearly define what keys need to be translated, to which languages and who are assignees.
Tasks can be set up by the project admin role only. Each assignee gets a notification over e-mail as well as in personal My tasks section.
When translation work for a language is done, the translator can mark it as completed, and the admin will notice that.
Collaboration via comments
Besides the contextual information like descriptions and screenshots that project admins may provide for keys, Localizely has a built-in chat with Slack-like @mentions so translators and admins can discuss the potential translation change or exchange ideas.
After translation work is done by translators, often you want to review if everything is ok and if it is ready for integration back into your app. There is a reviewed flag for each translation.
4. Downloading all language files
Once the translation tasks are complete you need to download the content and publish it to end-users.
Besides simply downloading the files using the web UI you can use REST API to automate it via bash-like scripts or via CI tools.
5. Publishing to end-users
After all localization content is up to date in your source code repository, you can build a new app version and publish it to your end-users.
Read next: Supported file formats