Localization often goes beyond translating content into different languages. You might require different versions of the same language for certain regions, clients or audience. This guide provides you with best practices to tackle this 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.
1) Localizing a rather static product
If you 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.
2) 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 synchronised 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 audience 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 and advanced) 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.