Workflow and configuration recommendations for release branch

We have been using crowdin + in-context in our development environment for a few months now. And everything has been awesome.

We use gitflow as our branch strategy so we have a main branch for production, develop and feature branches for development, and a release branches for testing. The main branch reflects what’s in the latest version deployed to production. The develop branch reflects the base branch for all feature branches and is the target for all feature pull requests. Our release branches are based on develop. We will cut a release branch when we are about to release, perform testing, fix bugs, and then merge that branch to the main branch when regression testing is completed.

We recently cut a new release branch in order to finalize our latest release. We continuously deploy the release branch to our staging environment and wanted translators to continue fixing translations during testing.

After reading and re-reading the Versions Management documentation

… we added the release branch to our Crowdin project

and selected the “Show within a version branch (strict detection)”

based on the recommendation from the above documentation.

Because branches are different versions of the same product feature, their localization content is usually duplicated. To help translators translate versions consistently and avoid additional translation costs, we have the Show within a version branch option that allows hiding duplicated strings only between versions. If your source files contain strings with apparent identifiers (keys), it’s better to use a strict version of this option. In other cases, feel free to use a regular one.

When this option is chosen, only the master strings first uploaded to the system should be translated. All duplicated strings will automatically gain translations from the master strings.

However, this does not appear to be working as I expected.

What we expected was for the release branch to share the same source file (master strings) as develop and allow users to continue translating for the release. When done we’d just merge the release branch into the main branch and develop and everything would be sync’d up.

What we got was a new PR from the service branch to our release branch with all new master strings. New Crowdin updates by jmiranda · Pull Request #3777 · openboxes/openboxes · GitHub

So I’m curious what I did wrong with the configuration to get here and what I can do to fix it.

Thank you in advance.


1 Like

Hello @jcm62 i’m sure it works well, just tested in my project. During the merge you may lose the unique strings ID (string ID in Crowdin, use along with your key marker) so that’s why system considers all stings as new one. Also, if you use approvals, some files not supports it to be hardcoded, and Github itself doesnt see if file is translated only, or approved. That’s why old approvals may remain even when you merge new translation.

1 Like

From what I see there’s nothing unexpected, maybe you can write down some workflow sample (like step by step) of what you have and what you need to achieve with Crowdin, so I can make some adjustments?

1 Like

Yes, +1, approved would be deployed without changes, if the master is already approved. I use hide all duplicated stings and it works just fine.

Maybe your workflow is bertter to be converted into API or Github Actions?

1 Like

Thank you @FernandoTorresinho @AnnaRockstray

My worry is that for every new release (which happens about once a quarter) we would have a new set of crowdin in-context identifiers in our pseudo-language file (

For example, in the current release, the identifiers start at 7008.

# System messages

When we merge our release branch to master, the generated identifiers will start at 14863 and will keep increasing for every new release.

# System messages

This doesn’t really impact the system since they’re all just locally unique identifiers, but it just feels wrong. And I was wondering if there was a way to configure this so it preserves the original crowdin in-context codes.

1 Like

This unique IDs are used for all tools, starting from API. They remain the same if you just keep updating same file from the same brach. I suppose merge rebuilds the file fully. Also, I know Crowdin don’t work with you files, during import they’re rebuild to match parsers and receive those IDs. Probably system just wasn’t designed for soo deep-in technical management, and if it would be possible to keep IDs developer already done that.

Or, there was no request (or not high amount of requests) in past, that’s why they keep logic the same. But for me it makes no sense because it seems to be quite usable feature and I’m totally sure someone should already investigate this and reported before.

Maybe there’ll be some improvements in the future, maybe some new id-bound system or so, but I guess it’ll be not soon because a lot of more important tasks are on the roardmap, at leat I saw few really nice in the Productboard of Crowdin.


Depends how to work with branches. Under normal conditions:

  1. Merged dev into master in Github
  2. Synch is run, master in Crowdin is updated
  3. Delete the dev branch in Github (it’ll also automatically delete it in Crowdin) or just from Crowdin files

If deleted master from Crowdin, and for example, just renamed dev to master then for sure will be another IDs. Overall, everything rely on merge option. Personally I prefer not to stuck with it and just use pre translate in automated workflow. Also duplicates should be usefellul.