The Lean Localization Process delivers ongoing localized software development that’s integrated into each sprint for development, testing, review and release. Using several Lingoport products in concert, the process delivers speed and quality results that remove developer burdens and delays, gives the localization team an opportunity to deliver in synchronization, and saves time and budget overall. The process is enabled via continuous integration systems, and recommended use of high quality machine translation engines. A final critical aspect is the ability to instantly review and update translations within application context, without creating new linguistic update bug fixing hassles for the development team.
The status quo using human driven localization processes outside the development path, and adding steps or proxies outside of the sprint cycle will always create a gap between development and localization. The Lean Localization process is designed to make localization truly continuous and visible, and not delayed by days, weeks or more.
The TL/DR (too long/didn’t read) version is:
- Internationalize during development with Globalyzer
- Automate translations with Resource Manager
- Integrated Machine Translation gives immediate results, with no minimums or waiting late in a sprint for string rewrites
- Review and adapt automated translations in your software with InContext QA within test and review cycles
- Release sprints with localization built in!
How the Lean Localization Process Works:
1. Globalyzer for Internationalization (i18n): The first step is to make sure that as code is created, that i18n is included in requirements. Software must be internationalized to support languages and locale formatting properly. During development, Globalyzer is used to automatically check for i18n issues either from within a developers IDE or during pull requests and commits. Any issues are automatically delivered to the developer, including where they occur, with help on many fixes. This is a non-invasive method to deliver i18n quality feedback that makes fixing much faster and easier than later during QA or post release when it’s much more expensive.
2. Lingoport Resource Manager (LRM): As developers create new interface elements, LRM automatically analyzes and verifies resource files containing the strings/messages, transforms as necessary, and sends for translation. This is a no-touch system that takes all manual developer burden away from string resource management.
3. Translation: Machine Translation, or optionally human translation, is queued up and delivered next via LRM. Completed translation files are automatically checked for correctness and pushed back into their respective development repositories for testing. Our Lean Localization process recommends machine translation. Machine translation quality has improved considerably over the past few years.
Using Machine translation, there’s no concern about minimum charges, or the time it takes to retranslate a string as it may change later in the sprint and translations are returned in seconds rather than hours to days. Localization becomes truly continuous, and easy review via InContext QA provides accuracy. Using machine translation also lets teams instantly see translated results. When teams can see language impacts in a matter of seconds, the feedback loop for correction is shortened. LRM supports connectivity to multiple machine translation engines.
4. InContext QA: Traditional linguistic review is an important step to make sure translation accurately supports end users, but past methods make that a slow process that piles on bugs that usually trail releases. In the Lean Localization Process, we use our InContext QA automation and file instrumentation to bring linguistic reviews (post-translation editing) into the same timeframe as other sprint functional reviews. A linguistic reviewer navigates to the new sprint functionality within the application and literally can click on a word or message they want to change, enter the re-translation via the InContext extension and it is pushed back to the repository, with an update to the translation memory or machine translation corpus.
Time consuming localization QA tasks are eliminated, such as gathering screenshots, filing bugs that pile up, tracking down linguistic bugs in code and files, and manual file updates. The InContext QA review method also lets in-country stakeholders have input in the quality of the new release translation deliverables. The speed and ease of post editing during the review phase further justifies a machine translation approach, because if a human can review and update the results quickly and in the context of the application, an initial human translation effort is redundant. LRM has the capability of delivering context into several translation management systems, however the advances in machine translation quality, the speed and nearly free processing costs make machine translation a better fit for software development.
5. Release Localization at Scale: From a localization perspective, your software is always release-ready with a high degree of quality. Lingoport Suite dashboards give management status overview and drill-down issue visibility across an organization. The Lean Localization process scales exceptionally well to agile teams using many repositories over multiple products and microservices teams, supporting diverse worldwide user locale requirements.
The number one complaint we have heard in all of our software localization industry surveys from software providers is that localization is not well synchronized and understood creating gaps between localization teams and developers. The lean localization process brings localization into continuous engineering and agile principles for fast and efficient delivery.
For presentation of the process, click here:
To discuss how the Lean Localization process might help you, click here:
