Integrating internationalization in a GIT workflow
)
Several of our customers asked us to support branches (from versioning systems like GIT or SVN) in Lingohub. The reasoning behind this is, that i18n resources and their according associations often belong to one or more branches, and then you should be able to merge them (GIT-like) with others. One of my beliefs is that a good product owner must be very skeptical of "feature requests" and instead look for the problems and/or the desired benefits behind such a request. In this case, a faster release cycle including translated text was of the essence - and is in fact also very dear to Lingohub's mission. Once we narrowed that down, we focused on some of the circumstances and on common practices of the current situation determining the agility of your release cycle:
- Developers usually text themselves (in English, or their native language, or both).
- Text changes during the development of a feature, hence a final version often exists only at the very end of a development cycle.
- Different language implementations are seldom tested already during development.
- Very often, a review process for texting and other copywriting (in source and target languages) is not in place.
Based on this feedback, we started working on tool support to allow managing a faster release cycle for your translation. Basically, our main goal is to minimize the time it takes to translate text without sacrificing the quality. We already released a couple of features for that purpose: our CLI client for scripted automation, and LingoChecks for verification - but this is just the start, there will be more announcements in the upcoming weeks. However, this blog post is about a working solution for today. What's a best practice for integrating internationalization? Let me outline for you how we translate Lingohub:
For every feature, we create a feature branch named after the issue ID (we use JIRA, so in our case lwe-xx). Finished features are merged into our master branch (all specs green), from there it takes another merge into the production branch to actually get released. Some leave out the production branch, but this is a typical GIT workflow. However, our i18n branch is special. This is the branch that gets synchronized with Lingohub. Every time someone pushes something to the i18n branch, Lingohub checks for new or updated texts. Having a specific branch for internationalization allows us to specify the moment when texts are considered finished. This can be during any stage of feature development (specs can be red or the feature is just a mock up). It decouples the development cycle from the translation cycle. For every release (production branch), we then synchronize our resource files by script via Lingohub's REST API: Deployment and retrieval of the texts is one step with one shell command.
Since an image is worth a 1000 words, here is a diagram describing the workflow (without production branch since it is not necessary):
)
- Development in feature branch, merge with i18n branch once the texts are ready.
- Automatic synchronization with Lingohub (we use Github integration, but you can also use git hooks).
- Feature development is finished and merged into master (or any other 'production' branch).
- Before the release of the feature, the texts are synchronized with Lingohub.
This is the workflow we use for translating our texts. Since 'eating your own dogfood' is the best way to actually see what's working and what not, we know the strengths and weaknesses of this approach. What we really like about this workflow is how easy it can be integrated in any software development process. Nevertheless, there are still some steps and issues we think can be improved to help you: better feedback on translation texts, faster translations, communication integration and more checks.
This is just one way to use Lingohub. With our API you can use the service as you like. Please check out our developer and API documentation. Don't hesitate to contact me ([email protected]) if you are using other approaches or if you are having questions. We welcome your feedback and work especially close with our customers on identifying other areas where we can make localization an even better experience for you.