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.

 

How to Identify an Internationalization (i18n) False Positive | Lingoport

What is a false positive

‘False Positive’ is a common term used when dealing with any automated checking system when an error is reported and the user deems that it doesn’t need to be fixed. You have likely run across a false positive or ‘false alarm’ when working with a grammar check in a word processor.

False positives occur for a few reasons. Software is complex, and it can be safer to over-report than over correct. When measuring complex conditions there will be instances where something that would be an error to one person would not be an error to another. Initially, it needs to be reported. As reporting is managed and controlled, the ease of use with the error reporting will increase. It is expected that users understand and address false positives to make the most of whichever system they are working with.

What is an i18n false positive?

There are some quirks that set i18n (internationalization) false positives apart.

False Positive Example

False Positive Example

It can be difficult to locate a false positive when it relates to an issue but doesn’t actually identify a problem that needs to be addressed.

False Positives vs Issues

Software internationalization rule sets are broken down into 4 categories of detection types:

  • Embedded Strings – Any hard-coded string in the application that will need to be translated.
  • Locale-Sensitive Methods – For example, Date/Time, Encoding, or String Concatenation methods.
  • General Patterns – For example, hard coded fonts, encodings, or date formats: ‘ASCII’, ‘ARIAL’, ‘mm/dd/yy’.
  • Static File References – Application references to static files, some of which may need to be localized.

How to fix an i18n false positive

Any quality automated reporting system will have a way to identify similar false positive patterns. A simple example would be if a grammar check was identifying Art as a word that shouldn’t be capitalized in the middle of a sentence. Despite this being the name of someone commonly referred to in the user’s work, the user would identify the error and tell the system to stop reporting the false positive.

When addressing an i18n related false positive in Globalyzer, Lingoport’s i18n software that identifies and fixes i18n issues during development and enables users to eliminate i18n technical debt, new rule filters need to be created. Doing so requires filling out a simple form.

String Method Filter

A more technical overview of Globalyzer’s specific requirements for manually addressing false positives can be found here

Rule filters help by identifying patterns within the reporting system and refining them to the user’s specific requirements. Individual issues can be flagged for removal at the user’s discretion as well.

What if this could automatically be solved?

To achieve seamless global software development that incorporates i18n into the development process itself, it’s necessary to address the complexities of false positives and to learn to manage them efficiently. However, manually checking i18n false positives is simply too cumbersome for today’s fast-paced agile development.

Lingoport is excited to announce we are fixing this problem with Machine Learning!

The power leveraged from machine learning is more complex than simply writing rule filters automatically. Soon i18n error reports will become dynamic documents that allow any organization to spend less time identifying errors and more time optimizing the product.

Ensure your team isn’t wasting time while internationalizing software for the world market. Watch the recording of our machine learning webinar, and discover how machine learning makes i18n false positives a thing of the past.

Apple’s i18n Bug Makes the News

Apple’s iOS Character Bug and Internationalization (i18n)

It’s rare that an i18n issue makes the news. In fact, in a meeting a few years ago with an i18n and localization team, one member lamented just that. “Nobody gets fired for a character corruption issue. That just doesn’t make the news.” The context was that security issues get the attention and with that gobs of budget. There is nothing like the fear of a breach, lawsuits and public humiliation coming with an i18n or localization (L10n) shortcoming. However the problems can still be insidious.

Let’s look at Apple’s iOS bug. It actually did make news, but could have easily been missed in this week’s tumultuous news cycle.

As reported: When a user inserts a particular character from the Telugu language (India) on iOS or MacOS, the system crashes hard. This can even take place from within applications running on those systems. The character looks like this:

Apple Bug

i18n and L10n Matter

Going back to our security bug comparison, let’s consider carrots and sticks. Security is a stick. Don’t handle it right and you get beaten. But if you perform i18n and L10n well, and you have a good product, you’re going to see a different kind of reward. This is absolutely no different than the benefits of paying attention to usability in your user interface. Software that works and behaves elegantly, has a competitive advantage with applications that may not. So it is for products that work well in any language and locale preference. Yes, there are some markets that are more US English tolerant, but they will still need all kinds of other locale formatting for a multitude of data like dates, numbers and addresses.

Want to grow? Go where the people are. Look at Facebook, with 87% of its users outside North America (including US, Mexico and Canada). Netflix has been growing consistently based on expanding their presence worldwide. Even consider technical products, whose managers perhaps had the excuse that system administrators have to learn English anyway. Have a listen to our webinar recording with Anna Schlegel, who leads Globalization efforts at NetApp. They place great strategic importance to their i18n and L10n efforts as a critical product strategy, and not just a checkmark.

If It’s So Important, Why Is It Hard?

There are many reasons why both i18n and L10n can be challenging. Developer teams are tasked with steadily implementing new features and fixes. I18n requirements are often not fully understood. You have organizational turnover, far flung teams, disparate understanding of i18n, and the fact that perfectly functional development may deliver the feature, but not the locale requirement. Testing may or may not ever directly relate to i18n and L10n within the same sprint. Then figure that you have multiple sprints and often source control branches being fired off concurrently. Even more experienced companies with their own internal technology investments tend to have a jury-rigged series of scripts that still depend on human action and are subject to process error and delay.

This is where our Lingoport Suite software for managing i18n and L10n can make for significant gains in quality, time to market and development savings. It is natural that if you find i18n issues during the day’s development tasks, you can fix them easily and quickly without any backlog or impact on your development velocity. Same goes for localization changes. Automate those, and you can stay right on target and never have to search for changes and updates to files. If one little string changes, it’s no big deal. The updated translation is automated out and back into your code. Plus it’s all made visual via dashboard and controllable even through collaboration tools like Slack. Even the QA team has continuously updated test cases, so that US English (or whatever your home language may be) is just another locale.

Back to the Apple Bug

I did a little reading plus reached out to a few experts beyond our team, to pin down what might have happened at Apple. Their situation is probably not a simple case of using some deprecated function or locale unsafe class. Apple does support Unicode after all. It’s a bit surprising that one Unicode character out of some 55,000 in the first Unicode plane would cause such problems. As a (useless) guess, something is going wrong at the OS level when the character is processed and displayed. Perhaps the character processing algorithm, in this case, leads to a buffer overflow. Even if you don’t expect to converse in Telugu, nefarious types are using the character in text bombs to disable Apple devices. A fix is forthcoming.

Why This Matters:

It’s unlikely that you’ll run into a bug this complex within typical application development. But this is an excellent illustration that it’s far less painful to get i18n and L10n right before release. Have good systems for finding and fixing issues like embedded strings, concatenations, functions/classes that aren’t locale safe, character encoding bottlenecks, and programming patterns that mess up your intended results. Then take out the file nanny busy work around localization updates so every sprint is easily localized. Win over your worldwide customers with software that’s up to date with their own preferred locale behavior and language.

Further reading:

Bug report: http://www.openradar.me/37458268

Interesting analysis: https://manishearth.github.io/blog/2018/02/15/picking-apart-the-crashing-ios-string/


The State of Continuous i18n & L10n Survey Results

Throwing it Over the Wall

Don’t fall into this simple trap when internationalizing for the first time that can cost years of work and millions of dollars! Our friend Steve, from Plodding Tech. was subject one such story.

Steve knew Plodding Tech. needed to expand their market reach, but he felt his team was too busy to tackle the large-scale project of Globalization. His assumption was that it would be simple string refactoring and translation work anyway. The presumed solution was to reach out to a low-cost outsourcing firm, Raindrop.

It seemed like a cost-friendly solution when it was initially pitched.

Once Steve threw the globalization work over the wall he felt like Plodding Tech. would be moving into the global marketplace in no time.

It was a couple of months before Steve realized his outsourcing firm was learning the intricacies of internationalization (i18n) for the first time. Every couple of months his contact at Raindrop changed as the firm was dealing with a heavy staff rotation.  Steve found that despite outsourcing he was acting as a manager of Plodding Tech.’s i18n efforts. This was exactly the effort he was trying to avoid by throwing it over the wall. 

The outsourcing firm simply didn’t understand what Plodding Tech. was about and what their software brought to the world. What’s worse is they simply didn’t have the ability to quickly react to messaging changes or detail corrections across the target locales in a timely manner. Even after two months, there we still many embedded strings

Often mistakes were overlooked and code drops from the outsourcing group were resolved months after their due date. This was frustrating as Steve was making weekly efforts to advance within the domestic market.

As time wore on Steve felt less like he had hired an outsourcing firm but paid for an assortment of entry-level contractors to tackle a specialized job.

Months became years, and when evaluating the project Steve came to a harsh realization. Even though they started out thinking the solution would be cheaper, little by little, they ended up spending $750,000, not including their own time spent trying to manage the efforts. The outsourcing firm had not developed a methodology to get through the i18n process. There were still embedded strings, application components that hadn’t be updated, Locale frameworks were insufficiently implemented. There was no clear definition of complete.

His own team had moved ahead with several versions and now he had a forked development effort as the i18n had never been well tested, had unresolved issues and so hadn’t been merged back into their code.

That was 3 quarters of a million plus 2 years of phone calls, emails, meetings, and stress. In addition, 2 years of lost market potential.

Steve was burying his head in his hands. This isn’t right, i18n should be creating new revenue streams, not cutting away from the bottom line.  Steve needed to try something new…

Steve needed experts.

When Steve started looking for i18n experts he quickly stumbled upon Lingoport, as anyone reading this article has. After laying out the scope and details of his project Lingoport was able to complete the work for Plodding Tech. in a few short months because our methodology is already in place.

Lingoport’s software was put in place. A list of bugs and issues found in the code could be methodically burned down, tested and completed. His team could work in concert with Lingoport’s services.

Rather than working hard to manage the outsourcing firm Steve found Lingoport came to him knowing the right questions to ask to get the job done and were addressing i18n concerns he didn’t know existed.

Now I’m sure you’re thinking Steve and Plodding Tech. are made up, and you’d be right their name has been changed to protect the innocent. However the 2 years wasted, and the spent dollars were all too real. Don’t let your company face the horrors and losses of throwing i18n over the wall.  


The State of Continuous i18n & L10n Survey Results