The development process often requires working on multiple branches. Lokalise supports branching similar to GitHub, with some limitations (see below).

In simple terms, think of a branch as a different version of your translation project. When you use the branching feature, your project can have many separate versions. You can move between these versions, get rid of them, or take changes from one version and add them to another.

For instance, imagine your project has a welcome key with the "Welcome to the app!" translation value, and you turn on branching. You create two branches: master and develop. Initially the welcome key has identical translations in both branches. But then, you can switch to the develop branch and modify the key's value to "Welcome to our app". This change will not affect the translation value stored in the master branch (it will still contain "Welcome to the app!" text).

Now, you can choose which version you like more. If you like the original master version, just delete the develop branch. But if you prefer the new develop version, you can merge it into the master branch. Branching is great because it lets you try out different things with your translations without worrying about affecting the main version of your project.

Please be aware that certain project elements are global (in other words, do not support branching), which is explained more in the How branching affects your project section.

If the branching feature is included in your subscription plan, you can enable it by proceeding to More > Settings:

Tick the Branching checkbox under the General tab, Miscellaneous section. Don't forget to click Save changes in the bottom afterwards:

Once enabled, the Branches tab will appear in the project settings. You can add, delete, and merge branches there.

By default, a single branch called master will be created for you. You can create additional branches either under the Branches tab in the project settings, or directly from the branch selection dropdown (in the Editor or at the projects dashboard):

Every new branch you create is always based on the master branch.

If you need to create a separate branch but copy content from another non-master branch, follow these steps:

Once you are done working on a branch and would like to merge it (incorporate changes from this branch into another one), there are several things you should consider:

To start the merging process, go to Settings > Branches. We'll check for any conflicts beforehand.

A conflict means that a certain element (e.g., a translation key) was modified in both branches. You have to decide which version of this element should be kept.

You can resolve conflicts in favor of one of the branches by clicking Resolve all using... or by clicking Show next to the conflict. When the Show button is clicked, you'll see a similar interface:

Now simply choose what version to preserve.

In some cases you might see a checkbox I understand, no claims can be done further on TOs in this branch:

You'll see this checkbox if you have an active professional translation order created on the source branch, and this order is still in progress. Be aware that if the source branch is merged into the target branch, the order is not moved to the target branch. It remains valid for the source branch only.

This checkbox serves as a reminder that you won’t be able to request corrections on the source branch order because the translation history is lost.

It is vital to understand how the merging process works, so let's take a look at some examples.

Suppose you have a branch named master. Then you create a new branch named develop which is based on master. Initially, these two branches are equal (meaning that the translation data, language settings, and other content is identical in both branches). Let's also suppose we have a key called welcome with the English translation "Welcome to the app!".

Perform changes in develop only and merge into master.

In develop branch we change "Welcome to the app!" to "Welcome to our application!". The master branch has no changes. Then we merge develop into master. As a result, the master branch will now also contain the "Welcome to our application!" translation for the welcome key.

Here's a similar scenario but with plurals. Suppose that in develop branch we change the singular key to a plural key. The master branch has no changes. Then we merge develop into master. As a result, the master branch will now also contain the plural key.

Perform changes in master only and merge into develop.

This scenario is very similar to the first one. If you change the translation for the welcome key to "Welcome to our application!" in master and then merge this branch into develop, then this new version will appear in the develop branch as well.

The same applies to converting regular keys into plural ones. If you change the key form from singular to plural in master and then merge this branch into develop, then this new version will appear in the develop branch as well.

Change the same translation both in master and develop and perform merge.

Now suppose we have modified the English translation for our welcome key in both branches:

In this case if you try to merge develop into master, or master into develop, a conflict will be detected. You will need to manually pick the version to keep. The other version will be erased during the merge.

The same applies to converting regular keys into plural ones. Suppose you change the singular key into the plural key in the develop branch. The master branch, however, has no changes and contains the key in a singular form. If you merge master into develop, then the plural key form will be used as a result.

Perform changes in develop and merge master into develop.

This scenario is less obvious. Suppose you change the welcome translation to "Welcome to our application!" in the develop branch. The master branch, however, has no changes and contains the old translation value "Welcome to the app!". If you merge master into develop, then the "Welcome to our application!" translation will be used as a result.

Effectively, that means you cannot "restore" translations that were modified in the develop using the old master versions. Why? As long as the translation in develop was modified since the branch creation, while the translation in master was left intact, we consider the develop version to be the newest. The older version cannot overwrite the newer one, therefore in this scenario you'll get "Welcome to our application!" translation as a result. If, however, you change the same translation in both master and develop then there will be a conflict as described in scenario #3.

Delete the welcome key in master, update the same key in develop, and then perform merge.

In this case the result will depend on the target and the source branches that you choose:

Delete the welcome key in develop and merge into master.

Suppose, we delete the welcome key in the develop branch. The master branch has no changes. Then we merge develop into master. As a result, the master branch will now also get the changes for the welcome key, which means that the welcome key gets deleted on master.

Once you enable branching, the current version of the project becomes the master (main) branch.

Different areas/functions of the project are now either global or branch-specific: