This feature is currently only available for Enterprise plans. The number of Project Branches / Versions you can create is determined by the account license. Please reach out to the support team for further details.
The Branching feature opens the door to better align your software development and release processes with your Applanga setup. If you want to switch from the legacy setup with Draft and Target values to a Branching setup, you can easily migrate your project. This change will not break your existing integration(s) and most of the current dashboard features will still be supported, but there are some major differences between legacy and Branching projects that you need to take into account. This blog post walks you through these differences. We also included some migration considerations and recommendations.
Since the inception of Applanga, all the strings in a project could have a Target or Draft value. That allowed for a straightforward system of proposed translation (Draft) versus published translation (Target). As well as acting as a built-in review step, this system allowed team owners to control who could make changes to Production content or publish new translations. With Branching, these principles still exist, but instead of baking everything into the same version of your content, certain localization steps can be relegated to a specific Branch (that can be later merged into another). All the previous flows still work, however, with Branches, workflows can be more granular and separated. When you migrate an existing Project with Draft and Target values to a Branching configuration, your content will be split into 2 Branches. Draft strings will be moved to your “Draft” Branch and will be converted into Target strings on that Branch, while all Target strings will be moved to the "Main" branch. In your Draft branch, users with the Translator/Reviewer role can perform their linguistic work, your translation orders can be delivered to either Branch, and, instead of publishing Drafts, you can simply merge the “Draft” Branch into the “Main” one.
The main limitation of the Translator/Reviewer role was that they were not able to publish Drafts, add Target translations, or edit Target translations. They could only add or edit Drafts; this meant that someone with a higher-level user role had to publish the drafts. In projects with Branching, we can limit the access of Translator/Reviewer users to adding or editing translations in specific Branches. In the future, we will refine access and edit rights for Branches to an even more granular level. For example, if you have a “Development”, “Staging” and “Production” Branch in your Applanga project, you can limit the editing rights of users with the Translator/Reviewer role to the “Staging” Branch only.
All integrations can be configured to point to a specific Branch in your project for either upload, download, or both. For example, this can be configured inside the Settingsfile if you are using our SDK integration or inside the config JSON file if you are using our CLI. If no Branch is defined, the integration will automatically connect to the "main" Branch.
Without Draft translations, the original purpose for Draft Mode - to preview Drafts inside your mobile app - no longer exists. However, there is still the use case for on-device testing that we continue to support. Now, when activating the Draft Mode for a project with Branching, you can select a Branch to connect to and download from. Instead of previewing just Drafts, you can instead preview a completely different Branch than the one you use for the release version of the app. For example, say you have a “Development”, “Staging” and “Production” Branch in your Applanga project. The SDK points by default to the “Production” Branch. Via the Draft Mode, you can now choose to connect to the “Development” or “Staging” Branches instead. Once the Branching feature is more widely used by the Applanga user base, we may consider renaming features like Draft Mode so the name is more generally applicable in either configuration.
If your license includes Branching, when creating a new project you will be able to choose between 2 types: the Draft/Target type or the Branching type. If you choose the latter, your Project will be created with a single Branch and without Drafts.
In order to migrate your Project to Branching, only 2 prerequisites must be fulfilled:
All your existing integrations, if not further customized, will continue to work, but now point to the "main" Branch in your Project. Alternatively, you can configure your integration to point to specific Branches, but be aware that this requires an update and release of your application. If you are using the SDK integration, bear in mind that your users will have to install the latest version of your mobile app that includes an updated SDK configuration to point to a specific Branch in your project. We recommend testing the migration process with a copy of your current Project first. Simply create a new Project and in its Project Settings, use the “Sync With” feature to copy the content of your production Project into this new one. Now you can migrate the new Project to Branching (also via the Project Settings page) and test this configuration both in the dashboard and with the integrations. If everything works as expected, you can then migrate your actual production Project. Have more questions or need help migrating your projects to Branching? Feel free to reach out to us at email@example.com.
Learn the ins and outs of our design tool plugin and how it interacts with your design file.Read the Full Article