Advanced Branching

Lingoport provides an elegant means to handle translation inside a feature branch.

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.

Here is an example of an resources_en.properties file with the following key/value pairs.

# SOURCE_FILE C:/Users/<pathToCode>/HazardDTO.java
HAZA_HAZARD_12=hazard
HAZA_HEADLIN_13=headline
HAZA_PHENOME_14=phenomena
HAZA_SIGNIFI_15=significance

Where the key/value pairs will be used in the used in the code. When the locale is switched to French, the values from resources_fr.properties will be used in the code.

public class HazardDTO {
	public static final String NodeName = getString("HAZA_HAZARD_12");
	public static final String HeadlineAttribute = getString("HAZA_HEADLIN_13");
	public static final String HazardCodeAttribute = "hazardCode";
	public static final String PhenomenaAttribute = getString("HAZA_PHENOME_14");
        public static final String SignificanceAttribute = getString("HAZA_SIGNIFI_15");
        ...

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 organizations. Localyzer, formerly known as Lingoport Resource Manager (LRM), the Lingoport product, seamlessly automates the checking, sending, and receiving of resource files.

Localyzer 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 on-board Localyzer projects is to dedicate one branch to translation. Localyzer can rebase so that the translation branch also gets the commits from master or a deploy branch, keeping it up to date with the overall source code development. This makes for an easy Localyzer 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 the translation branch will be affected by Localyzer. The drawback is that localization happens after all the development is done in a branch separate from everything else.

Feature Branching

Git has made branching a lot easier and 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 which works within collaborative environments such as Slack or MS Teams. The user issues commands that the chatbot passes along to Localyzer. 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 where 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. In this case, he sees that German (de) is 88% translated, but there are still 7 files to be translated that have 186 keys and 871 words to be translated.

At some point, when the development team is ready, the files need to be sent for translation. Instead of hand-picking 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 a spreadsheet, 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 (translate) to tell LingoBot to send whatever is needed to be translated:

When the translation is done and sent back to the repository automatically by Localyzer, 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 Localyzer Dashboard.

LingoBot and I18n

Another use 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 code base 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.

LingoBot scanned the Myster branch of the CET.LiteDemo project using the ruleset for Java. It found no scan differences between the main branch and the code changes in the Mystero branch and reported it.

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 the automation takes over. This fits in with the way software development is done in most modern companies.