Project branching

For some multi-lingual projects it is not enough just to have a list of translations per language. Sometimes we need to handle translations per app version, per environment, or per client (for white-label products). In this article, we will explain how to use branching in Localizely, so it manages all that work for you.

You can use branching in Localizely however you want, but we suggest using the minimal amount of branches so you keep it clean for your team.

Typical branching use-cases

Branch per app version

Use-case: Let’s say you just released app version 1.0, and now you are working on app version 2.0. While working on v2.0 you might need to change some UI elements and hence change the respective translations. However, your development of v2.0 might take time, and in the meantime, you need to maintain or even extend v1.0 and its translation.

It becomes especially important to maintain translations per app version if you use Over-the-air translation updates to skip App Store or Play Store approvals.

Solution: Once you start working on version 2.0 of your app, you just create a branch Version_2.0 in Localizely, from Version_1.0 as a source branch. If needed, you can later get back to the Version_1.0 branch for maintenance work or some extensions. This approach keeps translations safe per app version.

Later, when you discontinue maintenance for 1.0, you can delete that branch to keep it clean.

Branch per environment

Use-case: Let’s say you just want to manage translations Over-the-air for each environment separately (i.e. “Development”, “Stage”, “Production”). This is a more common case for web applications since the browser always loads the latest version.

In that case, translation changes are mainly made on the Development environment, and later need to be copied to Stage and then to the Production environment.

Solution: You can use one branch per each environment. When you need to copy changes from one environment to another, you just merge the first environment branch into the second.

You can even make quick changes on the Production branch, and then later merge them back into other (left) environments in order to keep them in sync.

At any time, you will be able to compare environments and see if there are any changes that differ among them.

Branch per white-label client

Use-case: In white-label product development, we usually develop the core product on the main git-branch, and then merge the main source code into client git-branches.

That means the same should be applied to translations that are contained in the cloud.

Solution: You can use the main branch in Localizely for core product translations, and separate branches for each client. You add new feature translations into the core product branch. When releasing for the client, you just merge it into the client branch and build the app.

You are not limited to use branching in exclusively just one of the mentioned ways. You can mix them up together. For instance, use branching per version and per white-label client. Just don’t forget to keep the number of branches at a minimum, for simplicity.

How to use branching

Make sure branching is enabled for your project

On the top of the page, next to project selection, you can select the branch you want to work on.

In the project’s menu you will find “Branches” item. It leads you to the page where you can create new branches, delete existing, or make a comparison between two branches.

The comparison page shows you what changes were made between the selected 2 branches.

Note that results depend on the selected comparison direction. So comparing branch Version_2.0 with branch Version_1.0 shows what will happen on branch Version_1.0 if you merge branch Version_2.0 into it.