Software Development Branching
Before writing code, developers will first create a branch, typically from the main repository branch, such as master or develop. A branch works like a copy of the entire repository. This allows a team of developers to work in isolation and write code in an environment under their control. Once the code is written, the branch is merged and becomes part of the main branch.
Translation for Repositories?
Resource files are files to be translated: .properties files, .resx files, .json files are de facto standards. For example, a file ‘messages_en.json’ may contain key/value pairs, where the value is displayed in the UI of an application. When the locale is switched to French, the values from ‘messages_fr.json’ are used to display the French strings for the same keys.
Keeping track of what has been translated, what has been sent to translation, what is being returned from translation, in what order, for what locale, while passing validating checks on the resource files is time consuming and a pain point for most development organization. Lingoport Resource Manager, or LRM, the Lingoport product seamlessly automates the checking, sending, and receiving of resource files.
LRM needs a branch from which to find the resource files to be translated and to which to push the translated files. A straightforward way to onboard the LRM project is to dedicate one branch to translation. LRM can rebase so that the translation branch also gets the commits from the master or a deploy branch, keeping it up to date with the overall source code development. This makes for an easy LRM project, where files are picked up from the translation branch and pushed back to the translation branch exclusively.
The benefit with this approach is the simplicity of the on-boarding and knowing only that branch will be affected by LRM. The drawback is that localization happens after all the development is done in a branch separate from everything else. Learn more about what pseudo-localization is here.
Advanced Branching
Git has made branching a lot easier and more flexible. Developers routinely create a branch for a feature or a bug fix. Resource files are part of the artifacts created during development.
For one application, you may have one repository, or you may have hundreds of repositories. You may have a couple of resource files to be translated into three locales or hundreds of files to be translated into tens of locales. Many development organizations would like to include the translation of resource files as part of the regular activities of development inside the feature branches directly as opposed to a specific translation-only branch. To do so, we recommend using LingoBot.
Lingoport Advanced Branching
LingoBot is a Chatbot that works within collaborative environments such as Slack or MS Teams. The user issues commands that the Chatbot passes along to LRM. Here is an example of a session of LingoBot in Slack:
Here the user “Andrew Wong” wanted to check the translation status of a branch, F1404-desktop-group-delivery, for a repository called ‘SSTO.webapp’. There may be lots of different branches on this repository. The one that Andrew Wong is interested in is only the “F1404-desktop-group-delivery” branch. That’s were the feature is being developed.
The system gives an overview of the status and a link to go to the Dashboard to see more information.
At some point, when the development team is ready, the files need to be sent for translation. Instead of handpicking the files from the right repository, the right directories, the right branch, verifying the correctness of the files to be sent, how many to send, tracking the files in some XL sheet, sending an email with attached files, having the attached files downloaded on the translation side, checking the files, on-board a new TMS project, it’s simply a command to tell LingoBot to send whatever is needed to be translated:
When the translation is done and sent back to the repository automatically by LRM, a Slack notification will let that room know:
Note: It also provides a link to GitHub, in this instance to the repository where the files were pushed, and another link to the LRM Dashboard.
LingoBot and I18n
Another usage of LingoBot is to ask for the i18n issues for the files which were modified in that branch. A team of developers may modify a few files during a sprint. The overall codebase may have a huge amount of files. To make sure the new code does not have more i18n issues, the command is ‘i18n scan’. It will use the Globalyzer configuration for that project to scan only those files which were modified in that branch.
Conclusion
Lingoport provides an elegant solution to complex branching and all the resource files, which works from collaborative environments that developers and other team members are already familiar with. They only need to know a few simple commands, and automation takes over. This fits in with the way software development is done in most modern companies.
