To ensure that all strings are captured correctly for translation, we recommend connecting to a branch where features or other branches are merged. For most users, the dev and main branches are the common choices. However, to prevent any localization issues from affecting the main branch, it's recommended to create an additional branch, such as a dev branch, for Smartling to return translations to before updating the main branch.
If you already have a process where localization happens in a separate branch, you can choose that branch instead. This will help ensure that the localization process is streamlined and that all translated content is accurately integrated into the final product.
Prerequisites
Do not use "Smartling" in your chosen branch naming convention. The Connector interprets branches starting with "smartling—" as self-created ones with translations and will not monitor changes in them.
Watchable Branches
The following details each of the watchable branches and some best practices for each.
Feature Branch
Pros:
- Focused i18n effort because you are essentially translating content as early as possible (i.e. as soon as it is added to the feature)
- Your translators have the longest time for translation because the content is isolated from the main branch
Cons:
- Source could change before release
- The branch may not include all content
- The lifespan of a branch may be shorter than a translation Job. This may be an issue if using Pull Request mode, as the branch needs to remain open
Dev / Team Branch
Pros:
- More likely to include all content for translation
- Content is translated before it meets the main branch, and therefore has more time to ensure quality
Cons:
- Source could change before release
- The lifespan of a branch may be shorter than a translation Job. This may be an issue if using Pull Request mode, as the branch needs to remain open
Main Branch
Pros:
- Inclusion of all content: It is likely to contain the "final copy" content file in your repository and therefore the content is unlikely to change
- Stability: the file is less prone to updates or changes of any kind
Cons:
- Merge frequency: it is unlikely you are merging daily (important to remember merge frequency triggers jobs)
- Time to release: there is not that much time for translation or testing before release
Considerations
Maintaining an appropriate merge frequency is crucial for ensuring the stability of the localization process. The overall quality of the localized content may be impacted by either too little or too much content being sent for translation. While pull requests with translated content are created frequently, it's important to ensure that the translation process is completed before merging to avoid delays in release time.
However, it's worth noting that translated content is typically added to the production/main branch. If this is of concern, consider setting up a separate branch specifically for translated content to avoid any potential conflicts. This will help ensure that the localized content is properly integrated into the final product, without compromising the stability of the localization process.
When planning localization efforts, it's essential to consider the lifespan of the branch. If a developer merges the feature/test/dev branch before the translation is completed, the localized content may be out of date or not applicable to the final product. This can cause issues as Smartling may not have a place to send the translated files.
To avoid such issues, it's crucial to ensure that all content is translated accurately and that the target branch remains active until the translation process is completed. This will help ensure that the localized content is relevant and up-to-date, and that the final product meets the desired quality standards.