Posts

What Is i18n?

Internationalization (i18n) is the process of preparing software so that it can support local languages and cultural settings. An internationalized product supports the requirements of local markets around the world, functioning more appropriately based on local norms and better meeting in-country user expectations.

Let’s say you land a new contract with a company in Japan, or your management team is looking to make an aggressive push into the EU. Then internationalizing your software is the path towards meeting the needs and expectations of local users in those markets.

I18n is often misrepresented as Localization (L10n) and sometimes even Translation. I18n is product development focused so that in the case of software, one code base is made capable of supporting worldwide languages and locale-specific formatting and behaviors. It’s a critical and sometimes underestimated step that is needed for successful and scalable L10n. Conversely, Localization makes a product specific to a target market or region(s), including translation of the interface and possible adaptation of terminologies and more.

Releasing software that has not been properly internationalized can lead to many problems, including lack of market acceptance. Addressing and fixing i18n bugs after product release results in additional costs, time, resources, and a potentially damaged reputation in local markets. Retrofitting a product for a global market after release, in contrast to internationalizing the source or during development, can be time-consuming, costly, and provide alternative products with a competitive advantage.

What Does Software i18n Involve?

Typical software internationalization tasks include:

  • Developing software to be independent from a specific language or limiting character set, and independent from cultural conventions (e.g., date display, time display)
  • Locale Frameworks
  • Achieving Unicode compliance
  • Elimination of hard-coded text (strings) in the code
  • Removal and reworking of concatenated strings
  • Support for collation of data
  • Support for bi-directional languages, such as Hebrew and Arabic
  • Plus more, including issues that may be application and market specific

Benefits of Internationalizing Software

Benefits of software i18n include:

  • Higher quality software that meets the technical and cultural needs of multiple locales
  • Reduced time, cost, and effort for localization (L10n)
  • Single source code for all languages of the product
  • Simpler, easier maintenance for future iterations of the product
  • Greater in-country customer acceptance and satisfaction

i18n Stories

Companies come to Lingoport with their i18n problems, so we’ve seen a lot that can go wrong with global software releases. Here are some brief examples:

One company had been internationalizing for years, but had persistent i18n bugs that garnered complaints. When counted, there were nearly 500 of them on one product alone. That’s a significant impact, expensive to fix and distracting from new features. By using Lingoport software to support ongoing development, they can now measure and fix i18n issues during development, which is much faster and results in a higher quality global product experience. Using Lingoport’s Globalyzer and Lingoport services assistance, they are working their way through the i18n bugs.

Still another company knew they had an i18n business case, but it was not immediate. They hired summer interns to externalize strings and perform minimal i18n adaptations. Without good direction or appropriate skills allocation, they didn’t get very far. They then sent the i18n offshore to a general contractor, spent over $500,000, and still didn’t have a properly internationalized application. In the meantime, they didn’t feel they were much closer to product readiness, and were passing up new opportunities.

Continuous Internationalization & Localization

Agile development has changed i18n and L10n tasks dramatically, as software changes faster but in smaller increments. It’s easy for i18n and L10n to fall behind. Regarding i18n, it’s often not apparent to a developer that there is an i18n problem in the code they are writing, as the scope of i18n is broad and there are QA challenges. For L10n, there is all kinds of management and manual task overhead, as files get moved around and updated. We believe that some of the biggest globalization efficiency gains for software companies to realize will be in systematically and continuously integrating i18n and L10n with agile teams, rather than hoping to find and fix issues in QA cycles when the development team may have moved on.

The key here is automation. Not necessarily of the actual translation via some machine translation, but managing legacy and new development for i18n issues and moving files for localization from the build to the translator and back again in a very visible and verified manner.

To do this, we automatically monitor software code repositories for i18n and L10n changes and issues/violations.

Continuous i18n and L10n features include:

  • Visibility – Dashboard measurement and drill-down of i18n and L10n violations and changes via static analysis of source code repositories including tools for fixing problems early during development
  • Automation – i18n support in the developer’s IDE, upon check-in and regularly run on targeted source code. Automated analysis, verification and exchanging of localization resource files from the build to translation (or translation management technologies) and back again to the build for staging and linguistic QA
  • Metrics – Tracking progress, coding quality, translation timing and more so that you can plan and improve
  • Integration – Integration with the tools that you are already using, such as a Translation Management Solution (TMS) and Slack for communications

As you add and update features and locales to your software, you have an automated framework for faster, trouble-free global releases.

Why Continuous i18n and L10n is important:

In practice, most software development endeavors treat localization as a delayed and often manually managed process, outside of ongoing sprints and releases. This is contrary to agile and good software development management practices.

There’s all kinds of “bookkeeping” issues around managing what’s changed, missing files, getting it out for localization, then putting it back in the source code. By its nature, this delays the process, lends itself to handling errors later when the teams have moved on, shortchanges QA efforts and delays localized releases. It’s costing you time, headcount, and cleanup, and it impacts the global imperatives of your company. Continuous i18n and L10n is simply a much more effective strategy.

i18n Implementation Tips

For legacy i18n refactoring and new development:

1. Learn, Build and Support the Business Case
Continuous i18n and localization (l10n) in support of agile development is going to have a cost. Unless the business case is defined, the project is unlikely to get done. Make sure you build a strong business case to compel all team members to align on i18n implementation.

2. Clarify Your Global Release Objectives and Concurrent Development
i18n touches a good deal if not all of your application, rather than being like adding a feature or fixing a bug in a particular sprint and area of your code. It usually involves more than your software’s presentation layer, as data is input, stored, transformed and retrieved. When internationalizing your product for the first time, you’ll need a branching, merging and testing strategy that covers the full i18n scope.

3. Assess and Document Requirements
Establish user requirements as they relate to target locales. i18n is almost never just a string externalization exercise you can pass to an intern. You’re going to need to put some thought into locale requirements, how data is going to flow through your application, changes to your database, methods/functions/classes that will have to be made locale-aware and of course the U/I and all it’s strings.

4. Build a Plan
An i18n project plan typically starts with about 200 tasks and increases with size and complexity (consider this for multi-tiered applications). To build this type of plan, one option is to analyze the code base with Lingoport’s i18n software product, Globalyzer, which provides detailed static analysis on internationalization issues that will need to be addressed. Combine that with architectural analysis from whiteboard discussions and requirements documentation.

5. Reduce Risks and Manage Trade-offs
Being late in deploying your global software is very costly to your business. The risk can be a broken agreement, market launch and business plan. A three-month delay may make an annual revenue goal unattainable. Ensure that your executive management team is fully bought in to your i18n efforts, and that your team has the budget, resources and tools to get the job done efficiently, reliably and successfully.

Internationalizing a large application is generally resource intensive. In cases where you have lots of legacy code, you may need an implementation partner in order to keep up with ongoing development objectives outside of internationalization.

6. Long Term Support
Once you internationalize and localize your software, your ongoing development has a new set of requirements. Measure i18n just like any other coding quality. Do not wait until testing to find out if i18n is broken. For your ongoing agile development, it’s good to automate the management of changes to strings that may change somewhat with every release.

Common Mistakes Made When Trying to Internationalize

Be sure to avoid these 10 common i18n process mistakes:

1. Don’t Forget What Drives Internationalization
Your company’s top and bottom lines. The costs of being late or delivering lousy quality products endure beyond any benefits of cutting corners on development.

2. Don’t Assume Internationalization Is Just an Older Software Legacy Issue
No framework, whether it’s React.JS, J2EE, .Net, Java, Ruby on Rails, PHP or whatever is new and improved, internationalizes itself. You still need to perform all the steps necessary to implement locale and all the associated i18n practices.

3. Don’t Assume You Can Treat Internationalization Like Any Other Feature Improvement When It Comes to Source Control Management
It’s typical for new feature development and bug fixing to be conducted in parallel with i18n. However, in the process of performing i18n, you are going to be breaking major pieces of functionality within your application as you make large changes to your database and other application components. In order for respective developers to work on their own tasks and bugs, you typically need to branch code, often with specifically orchestrated code merges.

4. Don’t Assume Internationalization Is Just a String Externalization Exercise
String externalization is important and highly visible, but the scope of i18n includes so much more. For example: creating a locale framework, character encoding support, major changes to the database, refactoring of methods/functions and classes for data input, manipulation and output.

5. Don’t Wing It on Locale
Designing how locale will be selected and managed often doesn’t get the amount of thought and planning deserved. How the application interacts with the user, detects or selects locale, and then how it correspondingly behaves is a design process needing input from an experienced architect, product marketing and the development team.

6. Don’t Create Your Very Own Internationalization Framework
Various companies have half-way implemented internationalization using their own homegrown methods for string extraction and locale management when there were already well established methods provided within their programming language framework or established solutions like ICU. Using these methods or solutions will ensure that your code is far easier to maintain. No unpleasant surprises.

7. Don’t Think That the Team Internationalizing Your Software Can Work without a Working Build
Without a working build, the developers can’t smoke test the changes they are making. Even if you provide a dedicated QA person, developers need to be able to compile and run themselves to head off problems later. It’s too hard to rely on reconstructing coding errors at a later time and make for unnecessary bug fixing iterations, lost time and poor quality. It’s odd that we even have to mention this, but it comes up.

8. Don’t Run Out of Money
I18n planning often suffers from underscoping. Lapses in funding can cause expensive delays, as new funding takes more time than anyone imagined to get approved. And chances are, if you need to ask for more money, than you also need more time, which brings you back to consequences regarding tip #1.

9. Don’t Use a Half Thought-Out Character Encoding Strategy
Use Unicode, rather than native encodings. If you have budget and time constraints and you’re only targeting dominant languages in markets like Western Europe, North and South America, you can often get away with ISO Latin – 1, but even for Eastern European languages, go Unicode. Then when you do, make sure your encoding works all the way through the application.

10. Don’t Use Your Same Testing Plan, or Just Rely on Localization Testing, When Your Functional Testing Needs to Grow to Include Internationalization Requirements
Use pseudo-localization of not only the interface, but send test data using target character sets, locale altered date/time formats, phone numbers and more, from data input to database, to reports and so on. In your pseudo-localization testing, expand data fields to fit physically longer strings, accounting for expanded strings from translation. Pseudo-localization is automated when you use Lingoport’s Resource Manager.

State of the i18n Industry

Lingoport recently conducted The State of Continuous Internationalization & Localization Survey. There’s been plenty of talk within our industry about making i18n and L10n continuous, automated and in step with Agile development. However, we wanted to uncover the true state of the industry and therefore launched the survey.

The reality is, the industry still has a long way to go… For example, only 8% of respondents thought they did an excellent job at measuring and managing i18n requirements. Download the report to see where the industry stands on localizing for every sprint, the lag time between feature releases and L10n turnaround, and other global software development issues.

Download the survey results.

Lingoport’s Market-Leading i18n Software & Services

Lingoport is the premier i18n software and services company in the market. If you are looking for software, or for i18n assessment, consulting or implementation services, we encourage you to explore the following links and to contact us at any time.

  • Lingoport Globalyzer – Find and fix i18n bugs. Lingoport Globalyzer is your operating system for exceptional global software. Avoid rework. Find and fix i18n issues as the code is written. Default rules and machine learning pinpoint existing i18n issues in source code for a wide variety of programming languages and database scripts. Improve your agile software development for global markets with Lingoport’s flagship i18n software.
  • Lingoport Resource Manager – Automate change detection and export/import resource files for localization with Lingoport’s localization process management software. Eliminate error-prone, manual processes and save thousands of hours of engineering time.
  • Lingoport Dashboard – The hub of our i18n suite. See it all, drill down, create notifications and manage the process. Bridge gaps between localization & development. Increase visibility and track globalization metrics.
  • Lingoport i18n Services – Benefit from our 17 years of experience. Enjoy expert teams for software i18n assessment, planning and implementation.

Lingoport Webinar: Highly Effective i18n Planning

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.

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

Winter Holiday Season

The winter holiday season is a great time to look at a more human element in the localization process. A few quick examples of global holidays might give some inspiration of how to approach different regions during this festive time.

Chinese New Year/ Lunar New Year

Lunar New Year

In America we think of the holiday as Chinese New Year, but the holiday is more commonly referred to as the Lunar New Year. This winter holiday takes place in either January or February. In 2018 it will fall on the 16th of February.

If you make content around this holiday you’ll want images to focus on either Lanterns, the dragon dance, fortune gods or other related decorations. Another good focus would be on the zodiac animal of the year. For 2018 the zodiac is the dog representing loyalty and honesty.

Another interesting aspect are small embroidered red envelopes used to exchange cash gifts. These red envelopes have seen some digital representations used with increasing frequency lately.

China is a good focus for the Lunar New Year but it is also celebrated heavily throughout Southeast Asia, Australia, New Zealand, as well as having a presence in highly populated areas of America and Europe. With some creative application the materials you put together could be applied across many locals.

Boxing Day
Boxing Day

America may be known for a shopping frenzy on Black Friday. However, in the UK, Canada, Australia, and New Zealand; Boxing Day has been the more recognized shopping holiday. Though many shops are now promoting with both holidays in these countries, as it’s another sale.

More traditionally boxing day was recognized as feast day of Saint Stephen, the patron saint of horses, which is why Boxing Day became associated with horse racing and fox hunting. It’s also considered customary to give gifts to people in the service industry on this day like the mail carrier or doorman.

Many prior marketing materials around this day focus on images with a box. Some however play more into the horses or fox hunting angle to look more daring, and lean into the roots of the holiday.

The Day of Goodwill

The Day of Goodwill

It would be best when putting together materials for South Africa to refrain from referring to Boxing Day and instead refer to December 26th as the Day of Goodwill. It was renamed so by the South African Government in 1994. This holiday is more family focused, and emphasizes itself as day of giving to others. Focusing more on goodwill and charity are more appropriate here.

Kentucky for Christmas!

Kentucky for Christmas

CC Image courtesy of rumpleteaser by Day on Flickr

KFC is the Christmas meal of choice in Japan. It used to be that the traditional meal was a turkey, which is an expensive delicacy in Japan. Assuming many would be satisfied with having a bird on their table KFC in 1974 launched their Kentucky for Christmas campaign.

Chicken was cheaper and bringing home KFC was much easier than trying to cook a turkey. It’s become such an ingrained tradition people will wait for hours in line to get their Christmas dinner from KFC.


To keep up with more i18n and l10n updates subscribe to our newsletter.


State of the i18n and L10n Industry Webinar