• Documentation
  • FAQ
  • Managing projects

Managing projects

This topic is a matter of preference, but we suggest keeping the following in mind:

Most software products are distributed incrementally in releases, with release dates and upcoming features announced in advance. Before the release, developers make sure the product is bug-free and well documented. And if the product is to be offered in other languages, teams will announce a ‘string freeze' on the product.

For developers, this means they can no longer change the code in a way that affects the source strings (bug fixes and improvements, however, are acceptable). For translators, the string freeze provides them adequate time to work.

When the release day arrives, developers get the translations for their target languages, compile them into the product and release it.

Effectively using branches

  1. Let's say you have a new feature that is under development in a separate branch. When it's ready, it is merged with the master branch and deployed. After the launch, you can push your resources to Transifex and when the translations are completed, pull them and deploy. That way, you'll only need to use a single resource for that feature in Transifex.
  2. If you want to deploy a new feature with completed translations, you should push all resources to Transifex. When the development is done and the translations are 100% completed, you can pull them from Transifex, merge both the code and translations into your master branch and go live!

You may also find this integration guide with GitHub quite helpful.

If these microservices have the same or similar content of strings then you can have all the content stored under the same project. For each microservice, you can have a different resource and create categories for each one of them based on the microservices they belong to. More information about the categories feature can be found in our documentation guide here.

However, if you would like to keep the content in different projects (you can create an unlimited number of projects), you can still do that. This would be a better option if:

  • The content of each microservice will be translated into different languages (e.g. Microservice A will be translated into French and Spanish, Microservice B will be translated into Turkish and Greek)
  • The content of each microservice should be localized based on a different localization workflow (e.g. Microservice A will be translated using Machine translation while Microservice B will be translated using a vendor, Microservice A will be translated using GitHub Integration while Microservice B will be translated using Zendesk integration, etc.)
  • For each microservice, you have defined a different voice, tone, direction, and style which means that you might need a different glossary, style guide with instructions, etc.

If you decide to move on with different projects for any of the above reasons, but you still want these projects to share the same translation memory suggestions, then you can use TM groups. That way, you can ensure that previously translated content of a localization work that has already been done for one project will be used in any other project of the same group.


Transifex identifies more than 290+ languages and many more associated with a locale code. These languages adhere to the ISO 639-1 standard of language names and locales. You might fallback to 639-2 or 639-3 if your language is not covered in 639-1. For a full list of supported languages, please refer to our Languages page.

If your language isn't in the Languages page and your files appear in a shortened version like ‘xx_YY', then you can help us providing the necessary information in order to add your language into Transifex.


Check the Unicode standard for Language Plural Rules and check that the rules for your language are correct. If so, let us know. Otherwise, try to find an authoritative source for the correct data and point us to that.


For every language Transifex supports, there's a set of information or rules that's followed by the system. Let's take for example Brazilian Portuguese:

  • name: Portuguese (Brazillian)
  • code: pt_BR
  • code_aliases: pt-br pt-BR
  • nplurals: 2
  • pluralequation: (n > 1)
  • rule_zero: -
  • rule_one: n is one
  • rule_two: -
  • rule_few: -
  • rule_many: -
  • rule_other: -

In detail:

  • name is the language name in the 'Language (Nationality)' format. You can omit the nationality for general languages like 'pt'.
  • code is ISO 639-1 language code. You might fallback to 639-2 or 639-3 if your language is not covered in 639-1.
  • code_aliases are aliases separated with spaces (e.g pt-br pt-BR).
  • nplurals is the number of plurals allowed by the language. These are quite common in .po files.
  • pluralequation is an equation to distinguish the plural rules for the available nplurals. These are also quite common in .po files, too.

The rule fields MUST reflect the exact number of nplural set to the language. This means that if your language has nplural = 2, then only 2 of the rule fields must be filled in.

The rule_other is considered the general rule. All languages must this rule — even those that do not have plurals (such as Japanese). The rule_other is considered a general fallback, like an ‘else' statement for all other possible rules. If there is a case that doesn't fit into the pluralequation, rule_other will be used.

Examples can be found here. We usually get rule information from

When we add support for a language we follow the BCP47 standard. The multiple language locales are based on region subtags.

No, this isn't supported. If you need to change your source language, create a new project with the desired source language.

Before you can delete a project, you'll need to set a password for your account. You can do this by clicking the Forgot password link on the Signin page and completing the password reset, or by contacting us.

You can edit source strings directly in Transifex for file formats that contain key/value pairs. More information can be found here.

For file formats that do not contain key/value pairs, you can add a new target language as an intermediary and make your edits in that language. For example, if your source language is English (en), add English (United Kingdom) (en_GB), then use your edited strings as the "translation" for English (UK). When you're done with the edits, download/pull the "translations" from Transifex, delete the existing online content and upload/push the "translations" back to Transifex as English (en). From there, you can translate the strings to your target languages.

We recommend separating these two processes out. It's really a good practice since it'll make it clear to your translators and the Translation Memory can be separated out too, increasing its quality.

So, let's assume that your source text is in English and you want to adapt it to Chinese and Arabic and then translate it into other target languages.

You'll need to have the following projects:

  1. One project will be dedicated to the adaptation (eg. named "Adaptation").
  2. A set of projects will be dedicated to the translations of the adapted text.

You have two choices on how to handle the work regarding languages:

  • Adapt and Translate in one step.

-- Create the "Adaptation" project defining English as source language.

-- Upload your English source file

-- Add Chinese & Arabic as project's target languages

-- Translate the source text into Chinese and Arabic while adapting it so as to accommodate regional differences too.

-- Export the Chinese & Arabic translation files from Transifex and upload them as source files to different projects.

Note: The Chinese file will be uploaded to a project with Chinese source language and the Arabic file will be uploaded to a different project with Arabic source language. Both projects will be translated from their own source languages to the desired target languages.

  • Use the same source language everywhere.

-- Create the "Adaptation" project defining English as source language.

-- Upload your English source file

-- Add Chinese & Arabic as project's "target" languages

-- Adapt your source text depending on the region without translating it.

-- Export the Chinese & Arabic "translation" files from Transifex and upload them as source files to a new project.

Note: Both files will be adapted but their content will still be in English. They will be both hosted under the same project where English source language will have been defined. Then you can translate the content of each source file into the desired target languages.

You have a master source file which you want to translate into multiple languages. However you also want to create a new form of English (based on the tone or the different levels of formality) that is not currently available. So, you want to create a new source file, based on the master one, using just Transifex.

All you need to do is to follow the steps below:

  1. Upload your master source file on Transifex.
  2. Add all the desired translation languages to your project in order to translate your content.
  3. Use one of the supported English language codes (en_US or en_GB or en_GR etc..) as a target language by simply adding this to your project as well. Note that this language code will be related to the new form of English regardless geographical, political, or cultural criteria.
  4. Use Transifex to "translate" the master source file to your new version of English.
  5. When the above "translations" are completed, download the "translation" file from Transifex.
  6. Create a new project and under this, upload the new English file as a source file.

You can use API or client in order to automate the above process.

With .pot files, translators will see the msgid values in the editor. Thus msgid must contain the string in the source language.

If you need to preserve the key defined by your developers for each entry, you can use .po files as your source file format. You'll need to generate the .po file from the .pot file in the source language of your project. Translators will see the msgstr value in the editor, so msgstr should contain the string in the source language. The msgid can be the the key of the entry.

Yes. You can lock an entire resource or certain strings. On a string level, you can lock certain strings and prevent them from being translated into all languages, or you can lock certain strings on a language level only.

Kindly see more information here.

As a final thing to note, whenever a translation is marked as reviewed, translators won't be able to edit the translation.

The answer depends on how your content is hosted at Transifex.

#1: Localized content is hosted at different TX projects. In this case, API is recommended.

Specifically, you can assign tags to your projects (through the project’s settings page or API) and then get the details for each project via API - project’s tags will be included in the response. This information will allow you to group your projects based on the assigned tags. More information about this can be found in our documentation guide here. In case you would like to try our API V3 (preview), you can take a look at the API endpoint here

#2: Localized content is hosted at a single project. In this case, you can group the resources instead via Web Interface.

Specifically, you can assign categories to your resources as it is described in our documentation guide here and use the available filters to get only the resources that belong to a specific category