Share this post:
IBM Globalization Pipeline for Bluemix is a Devops service that enables application developers to globalize their content fast using cloud based machine translation, combined with professional translation review and editing. In this blog, we’ll review how to integrate Globalization Pipeline into DevOps to rapidly translate application content without stepping outside Bluemix and having to manage tedious manual translation operations which disrupt Continuous Delivery.
Globalization Pipeline as a stage in Delivery Pipeline
Globalization Pipeline is at its most powerful and brings the most value when it is integrated into DevOps. Globalization Pipeline can be integrated with Bluemix Continuous Delivery/Delivery Pipeline, services which enable users to select, configure, and interoperate/coordinate different Bluemix services. Globalization Pipeline is configurable as a build stage within Delivery Pipeline.
To use Globalization Pipeline from Delivery Pipeline the first step is to make sure an instance of Globalization Pipeline exists. Then follow the steps below.
First, create an instance of Continuous Delivery using the Bluemix Catalog.
Continuous Delivery Service
Within the instance, the user can opt to create a toolchain. In most cases, the user starts by creating a simple toolchain which includes Git (for repo and issue tracking), a Web IDE to make changes to the code, and a Delivery Pipeline to build/deploy the code hosted in the git repo.
Simple Cloud Foundry Toolchain(v2)
The user can then configure the git repo within toolchain by providing a link to or cloning an existing repo and branch, or by creating a new repository altogether. When viewing the toolchain, the user can view all the services that are part of the toolchain.
Services configured on toolchain
By clicking on Delivery Pipeline, the user can manually add multiple stages which perform specific configurable jobs like builds, tests, or deployment.
Add stage in Delivery Pipeline
To add/configure a stage in Delivery Pipeline, the user first specifies the input. In the context of Globalization Pipeline, the user input may specify the git repository and the branch. The trigger for the stage could be a git commit. This means that the Delivery Pipeline would trigger the stage at every commit to the git repo. Next, the user would configure a job to use Globalization Pipeline.
Configuring delivery pipeline input
Within Delivery Pipeline stage, the user can opt to build, deploy, and test jobs. Globalization Pipeline is available as a build job. By selecting Globalization Pipeline from the Builder type dropdown (as shown in the image above), the user would be prompted to configure the target api endpoint, Bluemix organization, and space. In addition, the following needs to be specified:
Source file name: This name specifies the file pattern that the build job should search for within the files/paths of the git repo/branch whenever a commit happens in the git branch. Typically the pattern expected is of the form : <prefix>_<language>.<extension>. Post git commit trigger, the Globalization Pipeline build job is activated which searches for the source file pattern name among all committed files/folders. <language> would be considered as the source language for the input resource bundle file.
Target Languages: This comma separated value specifies the target languages in which the source file(s) need to be translated to using the Globalization Pipeline Machine Translation service. The values supported are es (Spanish), de (German), it (Italian), ja (Japanese), ko ( Korean), pt-Br (Brazilian Portuguese), fr (french), zh-Hans (Simplified Chinese), zh-Hant (Traditional Chinese). Currently machine translation is supported only from the source language of English (en) to the above mentioned languages.
Globalization bundle prefix: This value specifies the prefix that needs to be associated with the bundles where all the translated content will be stored in the Globalization Pipeline instance. If not specified then the default prefix of ‘DefaultBundle’ is used.
Globalization Pipeline build job
In addition the user can also specify the Environment Properties for notification purpose. By providing property value for SLACK_WEBHOOK_PATH ( value provided will be the hook URL for Slack integration) within environment properties, the user will be notified of machine translation completion through slack.
optional properties for notification
Assume, source file name is test_en.properties and target languages are es,ja,ko and bundle prefix is demo
During a git commit assume following files are found in the commit payload:
When the commit trigger is recognized, the Delivery Pipeline will automatically trigger the build job. Since, Globalization Pipeline is configured as first build stage here, then using the Globalization Pipeline instance created earlier, first the source files of test_en.properties, com/test/module1/test_en.properties, and com/test/module2/test_en.properties are identified and each of them is uploaded to the Globalization Pipeline instance. Since a bundle prefix of demo was used, following bundles will be created in the Globalization Pipeline instance:
- English (key, value pairs from test_en.properties)
- English (key, value pairs from com/test/module1/test_en.properties)
- English (key, value pairs from com/test/module2/test_en.properties)
For each bundle, machine translation will be triggered and within each bundle the key-value pairs will be translated to Spanish, Japanese, and Korean. If the user had specified the SLACK_WEBHOOK_PATH property in the environment vars, then post machine translation completion of all the bundles, a notification would be automatically sent to the configured slack channel.
example of slack notification
Based on the status of the build operation, the Delivery Pipeline processes the downstream stages of build/deploy. In a typical case, if the build stage consists only of Globalization Pipeline, then the user might choose to create a test stage which would use the latest machine translated strings to perform functional/unit tests. The user might also choose to create a deploy stage that would immediately make the new translations available along with the updated application. In case there is any failure during the build stage of Globalization pipeline then the downstream stages would not be triggered. The user has the ability to view the build logs within delivery pipeline to determine the reason for the failure, act accordingly and re-run the job manually if required.
Thus Globalization Pipeline through Delivery Pipeline as part of Continuous Delivery provides users with a truly automated mechanism for delivery translations and reaching users in the languages in which they work and engage.