📝Note: GitHub/Bitbucket/GitLab/Azure Repos integration is available in all plans. However, the multi-branch support is available on the plans below:
Opensource: 1 branch per project.
Growth and Enterprise Plus: Unlimited branches
If you have reached the limit of branches or multi-branch support is not available on your plan, you will see an error message in the activity log explaining why the strings of a PR were not transferred to Transifex.
Transifex's integration with GitHub/Bitbucket/GitLab/Azure Repos is designed to monitor all activities in the designated repository. This means that even when multiple developers are working on different features in parallel, using different branches, any new or modified source files in these branches are automatically transferred to Transifex upon PR's creation. These files are identified based on the paths configured in the YAML file.
Working with GitHub/Bitbucket/GitLab/Azure Repos branches enables localization work to start as soon as a new feature is developed. Once a PR is created, a child resource with PR's content is created in Transifex. To enable the feature, open the GitHub/Bitbucket/GitLab/Azure Repos wizard and enable the option "Multi-branching" as shown below:
Get started with GitHub/Bitbucket/GitLab/Azure Repos branches.
The following scenario will help you understand what the entire development and localization cycle looks like in Transifex.
Initial status
Let's consider a scenario where a product has been developed and localized in two languages. The source files and their translations are stored under the main branch in the designated GitHub/Bitbucket/GitLab/Azure Repos repository. You can view the corresponding resources and their translation status on the Project → Resources page in Transifex.
Kick-off development of a new feature
The decision has been made to introduce a new feature to the product. As a result, the development team initiates the implementation process by generating a branch called feature_branch within the GitHub/Bitbucket/GitLab/Azure Repos repository. In addition to modifying the code base, the development team modifies a source file already localized in Transifex. Subsequently, they create a Pull Request for this source file to be merged into the main branch once the translations are ready.
GitHub/Bitbucket/GitLab/Azure Repos integration in action
The GitHub/Bitbucket/GitLab/Azure Repos integration synchronizes with Transifex when the Pull Request is created. It generates a child resource with the initial resource from the main branch serving as its parent. The child resource is immediately available for translation, enabling translators to start working on the newly introduced strings.
📝Note for Bitbucket: If you delete a branch through the git CLI while having an open Pull Request, the Pull Request will remain open even after the branch is deleted. Deleting the branch will not automatically remove any related resources in Transifex. Someone must manually close the Pull Request in Bitbucket to delete these resources.
After the translation of the child resource is completed, the GitHub/Bitbucket/GitLab/Azure Repos integration generates a new Pull Request (or a direct commit, depending on the GitHub/Bitbucket/GitLab/Azure Repos integration configuration) from the translation branch created by Transifex to feature_branch.
QA starts earlier
Before the production release, the new localized feature can be tested by the development team and other teams, such as the product, localization, marketing, and design teams.
The development team can merge the Pull Request created by Transifex upon translation completion (from the translation branch to feature_branch) and then deploy the feature_branch in a staging environment to initiate the QA phase.
If any translation updates occur in Transifex, subsequent Pull Requests will be initiated to the feature_branch until the entire QA process is completed successfully.
Release to production
After receiving the approval to proceed with the release, the development team can initiate the release process. The Pull Request created from the feature_branch to the main branch can be merged, and the GitHub/Bitbucket/GitLab/Azure Repos integration acknowledges this by performing the following actions:
Merges the child with the parent resource in Transifex. Check here for more details about how resources are merged when using GitHub/Bitbucket/GitLab/Azure Repos integration.
Deletes the child resource in Transifex since the localization work for the new feature is completed.
How is the merge performed in Transifex?
When a PR for a feature_branch is merged in GitHub/Bitbucket/GitLab/Azure Repos:
Child resource is merged into its parent resource in Transifex.
The source file of the parent resource is replaced by the source strings included in the child resource, which may consist of new or changes to the existing source strings.
Translations present in the child resource are transferred to the parent resource.
If there is a conflict between the parent and child resources, the system will automatically resolve it by keeping the child's source/translation for the conflicted strings. For example, suppose the parent resource has "Translation string #1.b" and "tag1.b", and the child resource has "Translation string #1.a" and "tag1.a" for the exact string. In that case, Transifex will retain "Translation string #1.a" while keeping both tags, i.e., "tag1.b" and "tag1.a", for the string in the parent resource.
Finally, once the above process is completed, the child resource will automatically be deleted from Transifex.
What will happen if the multi-branch option is disabled?
Assuming that you have previously enabled the multi-branch option if you decide to turn off this feature later on, the system will operate in the following way:
Transifex will stop monitoring new feature branches for pull requests (PRs) and only watch the branch configured in your project.
The multi-branch functionality will still be in effect for child resources created based on the previous setup (i.e. when the multi-branch option was still active). These resources will remain linked with the corresponding branches in your repository, so upon the completion of translations, Transifex will continue generating PRs in your repository for approval. If you wish to disconnect these resources from your repository, you can take the following actions:
Option #1: Complete translations in Transifex for these child resources. After the PRs are sent to your repository for approval, merge the corresponding translations and feature branches. Subsequently, the child resources will be automatically deleted. By following these steps, you can guarantee that no translation work done in Transifex will be lost.
Option #2: Manually delete the child resources from your repository.
What kind of information can I find in logs?
The direction in which the information is being exchanged between the two systems:
Detailed information about why a resource failed to be created in Transifex:
Information about the status of the syncing task (Failed, Success, In Progress)
The type of action for each logged activity:
Merge: indicates that a feature branch was merged in GitHub/Bitbucket/GitLab/Azure Repos.
Delete: indicates that a child resource was deleted in Transifex after merging the feature branch in your repository.
Upsert: refers to any of the following actions:
Resource creation
Updates to the source of an existing resource
Creation of a translation pull request on GitHub/Bitbucket/GitLab/Azure Repos
Updates to translations in Transifex in the event of an initial sync.
💡Tip
Looking for more help? Get support from our Transifex Community Forum!
Find answers or post to get help from Transifex Support and our Community.