Localization goes beyond mere translation. Sometimes, you might need different versions of the same language for certain regions, clients, or audiences. Here are some best practices for tackling this challenge with Phrase.
Your product, website, or app is probably going to be translated into many different languages. In some cases, localization doesn't end there. Here are a couple of scenarios where further distinction is required:
- Your product might have a different branding in regions where the same language is spoken
- Your product is used by different clients who want use your white label solution
- You want to offer language variants such as simple, formal or informal
There are two general ways to approach this with Phrase. The choice depends on whether or not your product is rather static or continuously updated
Localizing a rather static product
If your product is fully developed and rarely updated it might make sense to create a different version of your Phrase project. There are two ways to go about this.
If this is a one-off and rather short-term project, it might be enough to create a branch
(making use of our branching feature
), work exclusively on that branch for the duration of the project, and delete it afterwards.
If it is a long-term project, then a duplicate of the existing project might be the best idea. This would allow you to have a completely separate entity of your project. This also allows you to invite and work with your clients in the same account by only providing them access to their project(s), leaving your other projects hidden for them. Please see our articles on user and language management to learn about the available roles and permissions that allow you to tackle several scenarios of working in the same account with separate teams.
Localizing a project with continuous updates
If your product is constantly updated with new content (keys), applying those updates to multiple projects and keeping them synchronized might not be feasible. For those scenarios, we recommend using dedicated languages
within a project.
In Phrase, we work with language codes and language names. Language codes following the ISO standard (e.g. en-US) don't have to be unique, so you can create as many versions of the same language as you like. You can distinguish between regions, clients, or audiences by making use of the language name (which has to be unique). So if you go with that your Languages tab could look like this:
With that setup, any newly introduced key in the default locale would show up as untranslated in the other languages and localized accordingly. If you are working with a client and they bring their own translator(s), you can specifically assign them to only be able to edit their language versions by updating their language access in their user profile
or the project user management
With features like Jobs
and our review workflows (simple
), you can set up parallel localization processes within the same project. This flexibility of course also extends to uploading and downloading language files or automated processes using our API