Posts

A Better Approach to Internationalizing and Localizing Software

Adapting software so that it supports multiple languages and locale formats is not trivial and it is important to your global success. A localized User Interface can have a positive impact on your customers’ satisfaction with your product. The globalization requirements span your software architecture and ongoing development practices. It is important to create ongoing processes so that internationalization (i18n) and localization (L10n) can be easily integrated into your sprints and releases.

Why Software Localization is Valuable

Companies that are looking to grow globally find that fully localized software is one of the key elements to sustained growth. You may gain some initial traction without localization, but if you want to move beyond early adopters and be more competitive, the localization process is an essential step. The localized software is easier to use and helps build long-term customer satisfaction. In addition, companies that invest in i18n and L10n often find they are at a competitive advantage in international markets which helps maintain pricing power.

But before you can effectively localize, you must internationalize your software to enable multilingual capabilities. This includes:

  • Adding locale frameworks
  • Externalizing strings
  • Refactoring string concatenations
  • Replacing locale-limiting programmatic functions/methods and patterns
  • Database internationalization
  • Managing potential 3rd party product issues

Getting Started

Internationalizing your existing application may seem daunting but the effort is typically rewarded with increased revenues. There’s a reason many companies underestimate the effort required to internationalize software. Many good programmers don’t have experience with internationalization and are therefore unfamiliar with best practices. They may regard i18n as a simple string externalization exercise – which of course is not the case. To complicate matters, without tools to keep the development teams on track, it is inevitable that i18n technical debt will creep into new features. Below are some tips and suggestions to help make your internationalization and localization efforts efficient, effective, and successful.

1. Dedicated Team

It’s not uncommon for some companies to start internationalization efforts with only one or two developers. Within a few months, they are pulled from i18n and put onto a “higher priority” project and sometime later replaced with different developers. This inconsistent approach almost always fails. After a year or more and significant resources expended, the project is still not complete, and the opportunity cost only continues to rise.

Creating a dedicated project team is the most important step in ensuring your internationalization effort will be successful. Using third-party contractors to lead the effort, combined with some of your own development resources, is one way to make sure the team persists even when internal resources are diverted. This approach has the advantage of allowing multiple internal developers to participate in the i18n process, rapidly improving the learning and socialization of internationalization techniques.

2. Software Architecture

Before diving into externalizing strings, it is important to first look at the software requirements and architecture. Is Unicode required? String externalization in the user interface is obvious, but are strings also passed through and processed in your software back end? How will you support locale selection within your application’s various programming languages? How will locale be selected and is there a fallback? What changes will need to be made within your database? Are there third-party libraries that need to be considered? Like many programming tasks, getting the approach correct up front will save many hours of wasted time doing rework. Are you choosing to use established methods for locale support or creating your own (we don’t suggest the latter)? Using standard resource file types and conventions will make automation of the translation process much easier.

3. Finding i18n Bugs

One of the more challenging aspects of internationalizing existing software is finding all of the i18n issues. Within thousands or even millions of lines of code, these can be difficult to identify and resolve. Fortunately, there are static analysis tools available, like Lingoport’s Globalyzer, to make the task of finding and fixing i18n bugs faster and easier. It is also important to put in place a method to quickly check new source code as it is being written so that internationalization becomes part of the agile process rather than addressed later in backlogs when it will cost much more in time and hassle. When developers can quickly scan their work from their IDE to find i18n issues, they are much more likely to fix the issues as they are writing the software.

4. Automation

The very nature of agile development involves rapid new feature development. For localization, this means many relatively small localization changes, performed more frequently. Traditional approaches to software localization involve many manual steps to perform a localization update. The process of finding and enumerating new strings from resource files in repositories, sending them out for translation, and returning the translations to the repo, can be tedious and error-prone. When changes are made to the source string, sequencing of the returned translations is almost always an issue. In addition, errors in the source files are multiplied across all of the locales during translation so it is important to validate the formatting prior to sending the files for translation. The good news is that this entire process can be automated so that no one needs to take on the role of “file nanny”, shuttling files back and forth to translation. For example, Lingoport’s Resource Manager handles these tasks using continuous integration along with an automated connection to your localization company or translation management system.

5. Selecting a Translation Partner

Language Service Providers (LSPs), also known as translation agencies, provide professional translation services including software and app localization.

Selecting a translation agency that has experience in and an understanding of software and app localization is key for ensuring your localized product is well received in new language markets.

Here are some things to look out for when evaluating translation agencies:

  1. Will the localization process be synced with your development process and does it fit seamlessly into your existing workflow?
  2. Do they offer integrated technology solutions to provide continuous translation and streamlining string hand-offs?
  3. Are they providing a veteran team of in-country linguists and industry tools to deliver quality translations that meet your deadlines and budget?
  4. Are they a full-service agency that can be called upon throughout the enterprise with professional translation services that include website, documentation, video and marketing content translation?
  5. Do they provide an optional Quality Assurance (QA) step that includes efficient, in-context validation of language and formatting to ensure your product looks and functions as intended?

When selecting an LSP, you are outsourcing a set of specialized and time-sensitive tasks that are closely coupled to your creative and development process. Quality should be a priority at each step in the process, from project set up through quality assurance. Working with a localization partner who can navigate both cultural and technological challenges will not only take your product across borders but also help it succeed across language markets.

The unique challenges of software demand dedicated effort to internationalization and localization. The proper tools and partnerships are required to meet your agile development workflow. Lingoport and Acclaro provide the expertise and solutions to help you meet your worldwide market goals.

Acclaro

 

Acclaro is a strategic partner of Lingoport.

 

Achieving the Happy Path: The Transformation of i18n and L10n for Agile Development

The internationalization (i18n) and localization (L10n) happy path for software development brings i18n and L10n features and requirements of a sprint or release together with no exceptional errors and no organizational friction. That is a bit of a twist on the Happy Path term used in QA, but I’m appropriating and bending as there’s no parallel concept for software globalization. The traditional agile i18n and L10n path is full of brush, rocks, and detours. There’s much we can do to clear the way.

Reasons why i18n and L10n and Agile development are traditionally not graceful pedestrian partners include: human time-delaying processes, limited understanding of i18n among developers, lack of, or ad hoc automation, delayed i18n and L10n QA, vendors and resources which are outside of the development team’s direct control and human errors that add up to blow out timelines. In Lingoport’s own industry survey, which is weighted toward localization savvy participants, only 6% felt they had a strong agile i18n/L10n process in line with their development teams.

Why It Matters:

Markets outside a company’s home country often represent some of the greatest opportunities for growth and stability. Agile development, with its focus on targeted scope and frequent product updates, has a different cadence than traditional software localization, QA, and i18n review, which historically could take weeks or months per release. The impact is that the same delight of frequent updates home users enjoy might not be presented to global customers, with only quarterly or less frequent updates.

This is a competitive weakness. But there’s more to it. If i18n and L10n fall outside of the regular cadence of development, they are by nature part of the backlog. Any bug fixes, file changes or localization updates now involve revisiting code when the developers have moved on to their next efforts. By far, the most efficient and least expensive times to find, fix and update are when the developers are in the code working on a feature and not later. This is one of the important credos of why agile development is embraced in the first place.

Definition of Done:

I18n and L10n are attributes of development, and unless specifically being performed on an application for the first time, they should be part of the definition of “DONE”. That’s no different from other requirements, like security or usability. If you think of i18n and L10n this way, you naturally need to look at how to measure, track and process i18n and L10n in parallel with feature development. You also have to consider how to do it at scale, over multiple teams and possibly over multiple products. Looking at i18n and L10n in this way makes it very clear that automation will help substantially in the achievement of the happy path for agile global software development.

Automation:

Early on in the broader adaptation of agile software development, sprints were typically three to four weeks. Now two weeks and less seems to be the norm. Much of that compression has been made possible through automation. Git, dashboards and coding quality checks take center stage here. If we let computers do what they are good at, people can focus more on where they bring the most value.

When it comes to i18n and L10n, consider that a SaaS product is often likely to have perhaps 10+ developer teams. Now think of 10 more products, all with two-week sprints presenting many small changes, spread over various parts of product source code. It gets more complicated if the product architecture uses a micro-services strategy, often with hundreds of source code repositories. With the pressure of sprint timing, it’s no wonder there’s a disparity with how localization actually gets performed and interfaces with development. It’s also no wonder that i18n and L10n bugs tend to pile up over time.

Automation can streamline multiple parts of the i18n and L10n process, making globalization a measured and easy part of the development process; but the minute you have to wait for someone to gather files, send or read an email, search to fix a problem, run a script or FTP an update, file an unspecific bug or update a translation, you have built-in process friction that is likely to break that release cadence. Lingoport Suite changes that for developers and L10n stakeholders.

Developers and i18n/L10n:

Globalyzer SummaryI18n is a vague software requirement. There are some obvious best practices, like the avoidance of embedding strings in your code (obvious, but it still happens), and less obvious issues (i.e. string concatenations, not passing locale into a method, date/time issues, encoding issues, programming patterns that will negatively impact localization and more).

This is no different than any other quality requirement, like security or even automating bug checking. The closer you can get to when the code is being written, the more efficient it is to correct a potential problem in terms of time, development velocity, cost and your definition of done, not to mention the closer you will be to achieving the happy path. Lingoport’s Globalyzer will present i18n issues right in the developer’s IDE (Development Environment) and/or the checks can be automated on pull requests/code check-in. I18n (and L10n) issues are presented on a dashboard for each repo making i18n and L10n status accountable. It’s a fair bet that individuals and teams will not want red marks on that dashboard in association with their code. What gets assisted, measured and visible gets done.

Developers also shouldn’t have manual tasks regarding L10n. Lingoport’s Resource Manager checks for changes to resource files (many types), checks the files for basic quality issues (i.e. no duplicate string IDs, missing curly brackets and general format issues – 40+ checks) and automatically packages and sends those files to the company Translation Management System (TMS) or to a localization vendor portal directly. When the localization files return with translation updates, they are again checked and if there are no critical errors, they are automatically updated into the repo for testing. All this is clearly displayed and tracked in the Dashboard, status emails and Lingobot queries. Nobody has to be a file nanny.

GlobalyzerGlobalyzer and Resource Manager come with extensive default detection and filtering for many programming languages (i.e. JavaScript, Java, C# and much more) and resource file types. Globalyzer uses machine learning capabilities to finely tune i18n static analysis to pinpoint issues and eliminate false positive detections. Setting up and performing functions can be as simple as calling Lingobot from within collaboration tools like Slack or even from an IDE.

If internationalizing for the first time, Globalyzer’s Workbench speeds up both issue detection and i18n refactoring. The Workbench is meant for i18n power users. More commonly used by development teams, Globalyzer Lite, runs from within popular IDEs or can be called during check-in via API.

QA and i18n/L10n:

Family Search HomepageQA are the gatekeepers of the definition of done, but they need a clear path to measure quality. As developers update interfaces, Lingoport Resource Manager automatically updates changes with pseudo-localizations that can be used to test for language and locale requirements without needing to speak the target languages. Pad characters with target encoding, with a clear beginning and end mark, are added to strings with controllable expansion depending upon target locale requirements. Testers can see quickly if there are problems.

When problems occur, they can be traced back to where they occur in the source code, rather than limited to describing an issue. That’s less time hunting for the issue for developers, and a more efficient process overall in pursuit of the happy path of software development.

Localization Managers:

If localization managers and L10n teams (always understaffed) don’t have to chase down files, updates, and problems, they can instead concentrate on vendor relations, project management, interacting with development, marketing, and in-country teams. These are higher value tasks.

L10n Managers can see the process status readily over many products and repos where teams are doing their work. Having a system and a process also helps Localization Managers to be in control of the quality of their deliverables and product destiny. Most Localization Managers would rather be spending more time on high impact initiatives, such as coordinating global teams and building global strategy, than i18n and L10n bookkeeping tasks.

Localization Vendors:

Agile development presents localization vendors with business issues. It typically means many small localization updates over lots of repositories. Consider that one repo has 16 new words, another has 42, another 116, and so on. The minute a vendor has to deal with any file inspection or formatting issues, the vendor turnaround mandate is difficult. Localization file engineering can’t be absorbed over small word counts. If the software development customer is automatically sending files that have been inspected, then the vendors can cleanly deliver the translations, repeatedly. With our process and using our software, we often see i18n, L10n and respective QA turnarounds go from weeks to under three days, which is critical to keeping i18n and L10n within the definition of done.

Linguistic QA (LQA):

Translation has its own set of quality issues involving context. Words between languages often don’t map a clear transition of use case, with one word equaling exactly another from language to language. This is why we have Linguistic QA, which can be performed by an outside vendor as well as from input from in-country teams.

Traditional LQA again falls outside of sprints. The normal process is to go through the interface and when a problem is found, the LQA team member makes a screen print showing the work to change, with a suggestion filed into a tracking system. That suggestion has to be reviewed and confirmed and then needs a localization engineer or developer to find and update the file and word in the source that corresponds to the update. Again, the usual process involves a clumsy multi-party human set of problems that take time outside of sprint schedules. Instead, Lingoport’s InContext QA lets a reviewer see translation in context with the running application, click on a message to change it directly, input the new word(s) along with any bug reporting notes and submit it for approval. If approved, it can pass back through the TMS or vendor portal for translation memory update or management as needed. No more screenshots, file sleuthing and slow processes. It’s fast and helps teams be reactive to in-country stakeholders. It’s brilliantly simple in practice.

The Happy Path:

I18n and L10n should be part of the happy path of globalized software releases. That is, by using automation to streamline the processes computers are good at performing, we compress i18n and L10n into each sprint and release.

There may be cases where outside issues, like a vendor delay or in-country LQA delays force some delivery of a well-localized product beyond a sprint, but that can have a contingency plan before releases, as the updates can be automated into the source code. That becomes the less happy path, but it beats letting i18n and L10n bugs pile up.

Using the benefits of automation, precision issue checking, metrics and visibility will make for a faster and higher quality product delivery for worldwide customers. That matters for your customers and worldwide stakeholders as well as for your company’s bottom line.

Lingoport Releases Globalyzer 6.1: Machine Learning and more

Breakthrough for Software Internationalization with Machine Learning

TLDR: Globalyzer finds and fixes internationalization issues that are complex and important for creating software for worldwide customers. Highlights:

  • New machine learning accelerates i18n issue detection accuracy, lowers false positives
  • More intuitive tuning than existing methods
  • Faster time to global releases

5/14/18

For Immediate Release

Lingoport has released Globalyzer 6.1, which adds the power of machine learning to find internationalization (i18n) issues faster, and with pinpoint accuracy, over multiple programming languages and database scripts. Machine learning makes i18n easier and more intuitive.

Globalyzer’s Machine learning is a step forward in automatically and accurately finding internationalization (i18n) errors within source code as it’s being written or checked in. Machine learning makes customizing i18n detection faster and more accurate while eliminating false positive detections quickly.

Internationalization is the first step to making applications that behave elegantly in terms of regional formatting and other requirements. It’s a critical but difficult requirement for software companies looking to expand their reach in worldwide markets. Finding i18n issues early in software development, when they are fast and easy to fix, saves time to market and expense.

Source code has unique conditions that can make i18n detection challenging. Often what is wrong in some cases is perfectly fine in others. For example, elements can seem to need translation, that in some cases have become programming variable names, which creates an i18n false positive detection. Globalyzer has always had methods to manage problematic false positives, however, machine learning makes customizing Globalyzer’s many default programming language i18n rules three to five times faster, with better immediate results and a more intuitive tuning process.  

Lingoport’s Globalyzer is used by many of the world’s best known technology companies, supporting development for worldwide customers. These companies avoid i18n and L10n rework and produce a high quality user experience concurrent with their new development and product releases.

“Managing false positives is the number one concern we hear from developers, so it’s exciting that our team has built a new approach that’s easy and straightforward,” stated Adam Asnes, Lingoport’s CEO. “With Machine Learning, Globalyzer becomes even more adaptable for the speed of agile development globalization.”  

Globalyzer 6.1. Includes additional features, such as access to Lingobot within the developer’s IDE. Release notes are available here: http://bit.ly/2rCTyTz


About Lingoport:

Lingoport provides a software suite and professional services that enable globally focused companies to create and maintain software that works elegantly in every language and locale.

The Lingoport Suite includes Globalyzer, Resource Manager, and Lingoport Dashboard. Working together, these products continuously monitor, fix and manage both internationalization and localization in each software sprint and release.

www.lingoport.com

Contact: Adam Asnes, aasnes@lingoport.com

Address: 3180 Sterling Cir #201

   Boulder, CO

   80301

###