A few months ago we discussed how Agile development became increasingly useful in getting products to market quickly in the programming world using the Scrum development framework. In an increasingly connected digital world where software development never stops – even when a version is released – users in multiple countries increasingly demand the latest software at the same time, in their own language.
Historically, the process of localisation for development teams used the traditional waterfall approach and involved the coding of a product in regular cycles leading to large portions of the code being sent to be translated in batches.
In the event of a product update, coding had to stop and content would be sent to a translation agency in multiple parts. The localised content was then uploaded into the system and released.
Developers would often have to wait days or even weeks for translations to be returned and in some cases, cheap, poor-quality translations resulted in quality issues and further delays. Sometimes products were released in local markets with sections of content in its original source language – usually English. To the end user, not only did this look unprofessional, but it often left users in local markets using an out-of-date product in a language they didn’t understand.
A new way
Businesses are beginning to recognise the issues with existing approaches and are starting to use continuous localisation so that users in different regions speaking different languages can get their hands on their same software at the same time.
For developers, continuous localisation has the capacity to work at the same pace as their agile development processes. Most commonly used in mobile apps – which require constant updates to keep them fully functional – continuous localisation works by localising content in more frequent smaller bundles alongside agile development sprints, as opposed to in larger batches of content less frequently.
Essentially, continuous localisation offers a light, fast and effective localisation process while being able to manage the formats most commonly used by developers.
Continuous delivery also eliminates potential barriers to release one would usually experience during a traditional batch-based localisation process such as lengthy reviews by QA editors. The main advantage of this streamlined form of translation is that development teams can focus on programming while never needing to halt the development process.
Key to success
While localised versions of a product are always slightly behind the original source version, it’s likely that lines of code in the original source language could still appear in localised versions that have yet to be translated. Success lies in minimising as many touch points as possible and establishing a consistent method of file transfer.
By integrating a localisation automation platform within an agile development framework, developers can create custom workflows for each project, push content strings to be translated, acquire the translation and import these back into the product – achieving faster turnaround times, saving money and receiving higher quality translations.
Whether it’s an in-house translation team or reputable language service provider accustomed to localising applications, it’s crucial that developers partner with linguists that understand the importance of urgency when localising content through this robust, streamlined process.
A delay could mean a significant push back on an update of a product in its target market. Therefore development teams working on mission-critical systems should err on the side of caution and partner with a language service provider.
Managing relationships
Time restraints are a common issue for agile developers and in order for projects to be released on time without a hitch, tech companies will usually employ specialist in-house project managers and reviewers to oversee the localisation process in order for developers to focus on building projects.
This also includes ensuring that the integrated localisation automation platform is running smoothly, jobs are assigned to linguists and reviews are fed back to the product in a timely manner.
A proactive localisation project manager should also encourage a focus on educating wider teams within the company about the complexities of continuous delivery, especially to development teams who have had negative experiences working with localisation experts on previous projects.
Development teams that work with language service providers are encouraged to invite linguists to work in-house on tasks that require a specific skillset, for instance, bringing in a linguist who’s skilled at translating bidirectional languages. Arabic has proven difficult to test using tools that look at its code in its static form, as a source code. Having an experienced bidirectional language expert to look at the code in order to get it to run would be the most effective approach.
Flexible workflows are essential for a continuous localisation process to be successful. In fact, a Cisco Systems Internationalisation Architect, Gary Lefman explains that “there is no set way we do things” and that workflows for the California-based tech giant are adapted to each development teams style of working.
For companies that are new to continuous localisation, it’s important for development teams to take the time to establish an effective workflow to identify when content strings should be sent to linguists and a product should be released. But experts believe that the more time spent on identifying the right workflow for individual development teams, the better the results.
While the process of continuous localisation will result in higher localisation costs, an effective continuous delivery strategy will inevitably allow developers to get their products to market quicker in order for their users to experience the most up-to-date content in the native language. A win for both development teams and the end user.
With mobile apps and large technology companies including Cisco and Evernote driving the growth of continuous localisation in its early stage, it safe that this approach could become the de facto standard for agile development teams in the future.
