Localization Workflow

1. Upload your localization files

The workflow starts with content in your main language. Most teams already have localization files, sometimes with a few languages partially translated, so the first step is to bring those into Localizely. Create a project, open the Upload page, and import your files. Localizely picks up the keys and any existing translations.

For the initial setup, the web app is the simplest route. As your project matures, you can automate uploads with the CLI, the REST API, or the GitHub, GitLab, and Bitbucket integrations, so new keys reach your translators as soon as they land in the repository.

Versioning with branches

If you maintain more than one version of your software, turn on branching in the project settings. Say version 1.2 is live while your team works on 2.0. With a branch for each, you can fix a string in 1.2 without touching 2.0, and see exactly what differs between the two before you merge.

2. Translate

Translation happens in the translation editor, a collaborative workspace that feels familiar to teams coming from spreadsheets but is built for localization. Invite your in-house translators or an agency as project contributors, or order professional translation and let vetted linguists handle the work.

A large share of the work can be automated. Use AI translation to generate a first draft, let translation memory fill in strings you have translated before, and keep terminology consistent with a glossary. Your translators then focus on refining rather than starting from zero.

Assigning work with tasks

When new strings arrive, create a task to define which keys need translating, into which languages, and by whom. Tasks are created by the project owner or a project admin and can be assigned to anyone on the project, including other admins and translators.

Each assignee is notified by email and sees the work in their My active tasks tab. When a translator finishes a language, they mark it as completed, and the project owner and admins can see progress at a glance.

Context and collaboration

Good translations depend on context. Project admins can add descriptions and screenshots to keys so translators see where each string appears. For anything that needs discussion, every key has a comment thread with @mentions, so questions and decisions stay next to the string they concern.

3. Review

Before translations go back into your app, you will usually want a second pair of eyes on them. Each translation carries a reviewed flag, so reviewers can work through a language and mark what has been approved. Whether a contributor can review is a permission you control per person. The project owner always has it, and you can grant or withhold it for invited admins and translators.

Alongside human review, QA checks automatically flag common problems such as missing placeholders, broken HTML tags, or translations that run too long. The two work together: QA checks catch mechanical issues, and reviewers judge the quality of the translation itself.

4. Download the translated files

Once translations are complete and reviewed, export them in the format your app expects from the Download page. As with uploads, you can automate this step with the CLI, the REST API, or the git integrations, which can open a pull request with the updated files in your repository.

5. Publish to your users

With the translated files in your source code, build and release a new version as you normally would. For Flutter apps, you can skip the release entirely and push updated translations over the air, so users see new translations without waiting for an app store update.