A New Approach to Continuous Internationalization & Localization | IMUG

Our industry is ripe for a new way to deliver software internationalization and localization. Localization runs behind development, as a bolt on process. Even current continuous localization practices are built on old linguist-centric models of translation tools and handling. By nature, localization and its QA are an additional lag. Engaging input from in-country reviewers adds even more delay and overhead into the process. In this presentation, we will show you what we’re working on to change all this. We’re looking to make both internationalization and localization immediate, right in the developer workspace, with in application review and updating that’s quick, easy and doesn’t require knowledge of translation tools.

We will show a connected system from Slack and Teams, to the IDE, to the repo, any commit or pull request, testing and deployment. We’ll show internationalization and localization, plus review on a live application. We think this is the future for our industry – an exciting change that makes localization a natural and scalable deliverable of product development. We’ll also welcome your input as the session will involve technology that hasn’t been released yet to the public.

Check out the recording!


Webinar: Localization Leadership with Loy Searle

Join us on Tuesday, September 29th for our next webinar where we’ll be interviewing Loy Searle, Sr. Director of Localization & InfoDev at Workday, to get an insider’s view into the future of localization and discover how to improve team efficiencies for a much faster higher quality product.

Loy has a tremendous amount of knowledge and strategic insights from her experience leading localization efforts at a number of global powerhouse companies.

“I am a great advocate of upstream intervention to prevent downstream pain and reduce costs and believe data, technology and teamwork can accomplish almost anything.” – Loy Searle

Register for Webinar

Learn from a G11n Pro

In this webinar, you’ll learn from a pro about taking the reins of enterprise globalization, with a lively discussion around the following topics:

  • Overcoming organizational resistance
  • Strategic planning 
  • Optimizing your team
  • Winning the budget!

Loy Searle

Loy Searle has 25+ years of experience within the globalization industry, working for some of the largest and most complex globalized organizations in the world including Google, Intuit, Delux Entertainment & more.

Loy’s specialities include but are certainly NOT limited to:

  • Single-sourcing processes leadership from content creation through translation & product management
  • Process optimization work to grow scalable solutions
  • Transforming and leading global teams – fixing what’s broken and creating what’s needed
  • Leveraging data to make solid decisions
  • Building, buying, and implementing strong technical solutions that support efficiently delivering quality offerings

Key Discussion Points Include:

  • The Most Common Localization Pain points
  • How to Create a better Partnership Between Dev and L10n
  • How to Save Time and Money Caused by Blockers
  • Real-World Examples of L10n Challenges
  • The Leading Ways to Solve and Prevent Future L10n Issues

Who Should Attend

  • Localization Management
  • Localization Engineers
  • Development Managers
  • Product and Project Managers
  • Anyone interested in improving their G11n/L10n process

Register for Webinar

An Overview of The 5 Most Common i18n Gremlins

I18n Gremlins come in many nasty and disruptive forms. Maybe a concatenated or embedded string. Perhaps the date format shows up wrong or you see square boxes and gobbledegook in your user interface.

They are annoying bugs for localized products that detract from your product quality for worldwide users. Typically, they are found late in a development cycle and sometimes sit for months to years in bug tracking backlogs. But you can find these Gremlins and eliminate them as code is being written, when internationalization (i18n) is fast and easy to fix.

Let me explain. When developers are creating new products and features, it is easy to inadvertently add i18n Gremlin issues. Some are pretty obvious, like embedding a string (messages in a product interface), rather than using a locale framework and a key, so that words that will need to be translated are all in resource files. It’s one of the most basic practices for i18n – writing software that can be quickly and efficiently translated for worldwide customers. Other i18n Gremlins are a bit more complex. For instance, embedding a font that might work fine in English but is illegible in Chinese, or forgetting to pass locale into a calendar class.

We came up with the term Gremlins because, like the mythical sprites they remain hidden and cause sabotage. i18n Gremlins aren’t immediately obvious and often are not found until later, when it costs much more in time and distraction to locate the gremlins’ source and fix the issues.

Here are some of the fundamental areas of i18n Gremlins that Lingoport’s Globalyzer software will detect as developers write software:

1. Concatenations

Issues: It’s like an Embedded String which cannot be externalized as such. In many languages the word order is likely to be different, so translations will read terribly. The string first needs some redesign. This one comes in all kinds of shapes and sizes. Here is a concatenation example: “Welcome ” + username + ” to our Rebel Outfitter store”

Remedy: The typical remedy is to create a parameterized strings and keep the parameter variables outside of the string itself. For instance, the parameterized string may look like “Welcome %{userName} to our Rebel Outfitter store”.

2. Embedded Strings

Issues: When you change locale, the string stays the same. The string was hard-coded in the application and is resistant to locale changes. For example if there was simple code that looks like:

  • String d =”All the young ones”;
  • String e =”Having a good time”;

Remedy: Externalize the Embedded String from the source code. Generate a Key/Value pair in a resource file, refer to that key in the code to retrieve the value. The value is the string itself. With your locale framework, you can then retrieve the string from a locale dependent resource file.

When the string is externalized, the code looks like:

  • String d =getString(“JAVA_TESTSTR_105”);
  • String e =getString(“JAVA_TESTSTR_106”);

And the key/value pair in the resource file looks like:

  • JAVA_TESTSTR_105=All the young ones
  • JAVA_TESTSTR_106=Having a good time

3. Locale Sensitive Methods

There can be hundreds o these locale sensitive methods, functions and classes depending upon the programming language. They effect issues like date formatting, numerical formatting, character encoding, currency handling, measurements and more. Here are some examples:

Date/Time Format

Issues: The application may look right but provides the wrong information. If the date shown is 05/06/07 independently of the locale, it means:

  • May 6, 2007 for an American
  • June 5, 2007 for a Frenchman
  • 2005, June 7 for a Japanese

Remedy: The application needs to format the data based on the user’s locale and, for instance, show May 6, 2007 as

  • 05/06/07 to an American user
  • 06/05/07 to a French user
  • 07/06/05 to a Japanese user

In addition, the date/time may be displayed using Time Zone. The entity or value itself may need to be a GMT date / time.

Currency Format

Issues: The application displays the same amount whatever the locale/region of the user. For instance, a Canadian user sees $5000 and may think that in Canadian dollars when it’s in US Dollars.

Remedy: The application needs to format the number, display the symbol, and most likely use some exchange rate to display the actual currency amount for the user’s language / region.

4. General Patterns

Issues: This gremlin may take the form of an encoding like ISO8859-1 when UTF-8 is required, or set a font that cannot be used in Chinese, even decides a format output.

Remedy: Make sure to check for each pattern to decide if it is a General Pattern, if more need to be added to your specific application, and how to refactor the code.

5. Static Files

Issues: The application serves the same file, maybe a video or a legal HTML file, independently of the locale. For example, a Chinese video is shown to a Russian application user. For example:

placemarkAttributes.imageSource = “./img/marker.png”;

Remedy: The locale framework needs to provide for an internationalization way to refer to the file so that a locale with a static file name will result in serving a Russian video to the Russian user.

All of these types of Gremlins are quickly and easily found using Globalyzer, which can detect i18n Gremlins in a number of ways:

  • In the developer’s IDE – A developer can add Globalyzer i18n detection to their development environment and see i18n issues as they work.
  • During commits or pull requests: As a developer submits her day’s work, a Globalyzer scan can run automatically illustrating any i18n issues. That makes it easy to fix any i18n issues that can arise and then move on.
  • Dashboards for specific repositories, entire development products, or software across your enterprise – gives a broad view of i18n readiness, while also enabling issue drill downs, assignments and other management features.


Learn more about i18n Gremlins:

There are other problems of course that our software suite will solve for you, so that you localization is fast and in tune with software development. To discuss your own localization process, continuous localization and Linguistic QA, please reach out to Gremlins@lingoport.com.

Webinar: Agile Localization Bottlenecks and the Cure

There are common blockers that interfere with agile localization for software, which puts localization behind feature development and sparks the common rift between developers and localization teams. This in turn, costs time and money over and over…and over again.

It doesn’t have to be that way, but it takes some planning, technology and advocacy to impact your development teams.

In our August webinar, we explore the common blockers that interfere with agile localization for software and solutions for how to fix them and avoid them in the future.

Register for Webinar



The pain is real, especially when you localize at scale. The solutions are about much more than a git connector and we will be demonstrating solutions that address the most common challenges and bring localization in line with modern development practices.

This webinar is an education for some, with real-world examples, intended to provide good illustrations to help you get ahead of frequent real world problems.

We explore the following common challenges:

  • Broken or irregular file formats
  • Errors introduced with human processing
  • Frequent iterations on U/I content
  • Why even fast localization turn around is still late
  • Translator errors
  • Linguistic QA backlogs
  • I18n gremlins
  • L10n bugs going to JIRA to die!

What We Discuss:

  • The Most Common Localization Pain points
  • How to Create a better Partnership Between Dev and L10n
  • How to Save Time and Money Caused by Blockers
  • Real-World Examples of L10n Challenges
  • The Leading Ways to Solve and Prevent Future L10n Issues

Who Should Attend

  • Localization management
  • Localization engineers
  • Development managers
  • Product and project managers

Register for Webinar

Lingoport Suite – New releases, Machine Translation and More

We are pleased to announce the latest new releases of Lingoport Suite products, including enhancements to Globalyzer and Lingoport Resource Manager (LRM).

Lingoport Suite products work together to integrate internationalization (i18n), localization and QA together with modern agile development practices and continuous engineering systems. With so many software companies realizing substantial growth using language and regional customization to reach new customers, it’s more important than ever to have software systems that speed up and simplify the globalization process. Here are the release highlights:

Globalyzer – Continuous i18n

LRM – Continuous Localization:

  • Integration with Amazon Translate and SYSTRAN neural machine translation engines deliver immediate translation returns directly to and from your Git repositories, and empower developers to iterate on features without waiting for translation. Machine translations are then quickly edited using Lingoport’s InContext QA.
  • DITA support for documentation projects using .dita and .ditmap files, increasingly popular within git projects and hard to manage for localization without automation
  • XHTML parsing
  • More flexibility for locale support in file structures
  • See: https://wiki.lingoport.com/LRM_Release_Notes

Lean Localization Process

Lingoport’s patent pending Lean Localization Process combines its software suite so that applications are always internationalized and localized with all feature development, and no lag in waiting for translation. The right time to deal with i18n and Localization updates is as software is written, and the right time for human translators to correct machine translation is during QA and review. This keeps localization tightly in sync with feature development, rather than lagging development progress by days to weeks. Please visit: https://lingoport.com/lean-localization-process/ to learn more about this industry changing approach.

Make better software for the world, do it faster, and in tune with agile development.

Webinar: Can Read, Will Buy | Language’s Impact on Online Behavior

Our friends at Nimdzi have just recently released an important report looking at online behavior, buying decisions and the intimate way in which language impacts behavior. Nimdzi calls their report Project Underwear, because consuming content for personal decisions and communicating in our own language is as private as it gets.

“That is the Underwear Effect, the term to describe situations where consumers are making their buying decisions during their (almost) most private moments, with their mobile phone in hand wearing nothing but their underwear. And what clings to a person even more closely than his or her undergarments? Why, their language, of course.”

In our upcoming webinar, we’ll be exploring the takeaways from the report with special guest and Nimdzi Co-Founder, Tucker Johnson and taking questions from the audience both before via and during the webinar via chat.

View Webinar Recording

Project Underwear:

Codename: Project Underwear, Nimdzi’s internal name for this study, is one of the most ambitious projects Nimdzi has undertaken to date. This is a global project, with surveys and data collection executed across more than 70 countries. Based on an end-user survey consisting of 25 questions translated into 66 languages and carried out with native speakers living in those countries.

Project Goal: Demonstrate how language affects buying behavior and answer the following:

  • How do people engage with and consume content online?
  • How do they act if given the choice between English and their native language?
  • Would they consume more if there were more content in their native language?

Tucker Johnson:

Tucker has served in many different capacities throughout his career, from engineering to senior management. His special experience lies in:

  • On-boarding and building out large scale localization programs
  • Supply chain governance
  • Global team management
  • Advising business leaders on international strategy

Tucker’s latest endeavor is the founding of Nimdzi Insights company with a focus on the international market. Nimdzi works with international businesses, language service providers, universities, private equity firms, government agencies, and more.

What We’ll be Discussing:

  • While it’s clear that online services have proliferated magnificently, how have our language preferences and baseline expectations changed?
  • What does this mean for language and product marketing professionals?
  • How should this information affect product development planning and process?
  • What is the impact of English language proficiency on personal preferences?
  • If you had to pick between speed and accuracy for delivering in languages, which is more important?
  • What are the functional expectations for applications used by worldwide communities?

Who Should Attend

  • Localization management
  • Localization engineers
  • Development managers
  • Product and project managers

View Webinar Recording

Webinar: Continuous Localization Training for Software Development

There are excellent opportunities to join localization teams with development, but the solutions aren’t in your TMS or Translation Workbench. Even with modern deployment of “continuous localization,” it’s not really continuous like other developer services…and that should change.

We’ll show you what we mean.

Going Under the Hood of Continuous L10n

Check out our training webinar recording where we go over the mechanics of continuous localization integration and hardwiring into the developer’s world – from the developer’s IDE, to source control, collaboration beyond messaging, and systems like Jenkins.

Discover opportunities to go further.

Register for Webinar

Why it matters:

  • Deliver global products faster with less hassle
  • Built in coordination with ongoing development makes for better products
  • Opportunities to include input faster from target market stakeholders

Check out our webinar teaser below.

What You Will Learn

  • Continuous i18n and L10n overview and why that’s where L10n needs to improve
  • The developer’s perspective
  • Examples of continuous integration
  • The Lean Localization Process
  • Immediate localization feedback
  • Audience Q&A

Who Should Attend

  • Localization management
  • Localization engineers
  • Development managers
  • Product and project managers

Register for Webinar

Globalyzer i18n Express – A Free i18n Analysis on GitHub

Globalyzer i18n Express – A free i18n analysis on GitHub

    • Create software that’s ready for localization and the world
    • Find i18n issues in source code as you develop, before they become a problem
    • Super easy and fast way to get basic i18n code analysis for GitHub users
    • Free for now on the GitHub Marketplace

What is Internationalization (i18n) and Why Does It Matter?

I18n is the practice of writing software so that it will function well in any targeted locale. Locale will include language (translation) and formatting (i.e. date formats, sorting, character support and much more).

With access to global customers faster and easier than ever, attention to i18n and ultimately, localization is more important than ever. Global technology companies frequently report 50% or more of their revenues coming from outside home markets, and often, these are the same areas with the highest sales and user growth potential.

Software that is written without quality attention towards locale requirements will not make for a good user experience in new markets, and will likely create all kinds of translation and formatting bugs that are expensive and time consuming to fix later on.

I18n issues are not always as straightforward as telling your team not to embed or concatenate a string within the U/I. For example, a correct calendar class might be used, but a developer may forget to include locale. Like issues around security, there are mistakes that are made. Those mistakes are often found late or after any development cycle, making i18n issues especially expensive to revisit and fix.

Globalyzer i18n Express

Lingoport’s Globalyzer is used by many of the world’s leading technology companies to scale i18n support across their development teams.

Globalyzer i18n Express is a simplified functionality version of the full Globalyzer system, intended to help developers on GitHub get up and running with i18n analysis quickly and easily, and without necessitating IT department involvement. It is Lingoport’s intention to spread the adaptation of systematic i18n analysis, making it a measured and automated component of coding quality. For a limited time, we are making it available free from the GitHub marketplace.

Globalyzer i18n Express will detect:

  • Embedded strings
  • Concatenated strings
  • I18n unsafe methods, functions and classes for leading programming languages
  • Programming patterns, such as fixed fonts
  • Static files, such as images that could be locale dependent

Globalyzer i18n Express will find i18n issues in a wide range of programming languages, including Java, C#, JavaScript including variants for React, Node and jQuery, C++ and more.

See links for more information about Globalyzer i18n detection and programming language i18n support.

How Globalyzer i18n Express Works

Globalyzer i18n Express uses a basic set of Globalyzer capabilities, and it’s fast and easy to get i18n checking into GitHub projects. I18n Express uses basic Globalyzer rule sets to provide i18n detection to developer commits automatically as developers engage their usual workflow.

Getting Started

Step 1: Go to the GitHub Marketplace and select Globalyzer i18n Express:

lingoport globalyzer express github install


Step 2: Set up your plan

setup directions screenshot


Step 3: Get Started

lingoport globalyzer express github


Step 4: Work as usual, and after a commit, inspect any detected issues. For example:

i18n express github notes


For more information about Globalyzer as well as the Lingoport Suite, supporting continuous i18n, Localization (L10n) automation and Linguistic QA, please visit: https://lingoport.com/products

Lingoport’s Lean Localization Process

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!

lingoport lean l10n process

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

Lingochat | Join L10n Industry Leaders for Peer Discussions

What is Lingochat?

“Lingochat” is a weekly small group discussion, created to share ideas, troubleshoot issues, and help identify to solutions to problems. The groups are intentionally kept small so that everyone has an opportunity to interact and participate, and attendees will primarily be localization specialists and managers. 

There is no cost and the only thing required is that you have a problem you wish to solve, you have solved a problem in your organization, or you wish to brainstorm.  Also, you don’t have to commit to being there every week.  It is just a great way to help each other with solutions.  To join, simply email lingochat@lingoport.com.

A general topic will be published each week as a way to get started.  But what we REALLY want is for the community to suggest topics. 

1st Lingochat Meeting Notes

We had the first Lingochat on the 19th of May, 2020. Below please find the the problems, suggestions, and solutions discussed during the meeting.   

Problem #1

We have a continuous localization process where GitHub is connected to the TMS.

In one product, certain languages require us to deviate from the source content. Our typical issue is between English source and Japanese target.  

We have three different cases:

  1. English strings should not show up in the Japanese locale
  2. There are Japanese strings that need to be there that do not have English source
    1. This case also requires back-translation (see below)
  3. English strings need to have translations that are different

Back-translation:  We currently back translate to English for case 2 because there are times that people in the Japan locale want to view it in English

The way this is handled right now is through override files, and these files contain strings that override the standard strings for specific locales.  But there are many problems with the override files.  They require manual translation and they are hard to maintain over time.

Solution suggestions that could eliminate the override files

  1. Cases 1 and 3 above can be solved by simply modifying the target resource file directly.  In case 1, a null string can be inserted.  In case 3, the modified string can be substituted.
  2. Case 2 might be solved by simply adding a second string in the resource file that is only used for the specific locale.  This approach would require some i18n code changes.  

Problem #2

We don’t have a good testing process for translated strings.  The way we do it today is to ask development to take screenshots, and we send them to the translators.  With dozens or more locales, this can be a lot of screen shots and we get pushback from development.  One of the key issues is with Thailand and spaces.  Spaces can really cause problems with this language.  This is for both mobile and web applications.  

Solution suggestions

  1. Perhaps the screen shot function could be done by a QA or testing organization instead of development.  This might require getting the QA group involved earlier in the process rather than waiting until the localization process is complete.
  2. Pseudolocalization might be used early in the process to make sure page spacing is correct prior to translation.  
  3. Some TMS products allow “fake” spaces to be inserted that then allow a line break.  This might help.

(Note: Lingoport has software solutions for QA context eliminating screen shot hassles and streamlining fixes, but we do not make LingoChat a sales platform…but sorry, I couldn’t resist.)

Problem #3

How much should be budgeted for fixing internationalization (i18n) issues in source code? Is there a standard on how much it costs to fix bugs?

  1. One company did a study on how much it costs to fix an error in the source string when you consider all of the translation work etc.  For example, if there were a missing comma in a source string in a resource file, how much does it cost to fix it for all locales.  That case study was used to help educate the organization on the kind of bugs that should or should not be fixed.
  2. Lingoport services routinely fix i18n bugs in source code.  We find that the cost varies quite a bit depending on the approach.  If it is a fairly large number of bugs, the cost per bug can be fairly small.  But if it is only a few bugs, the cost per bug is much higher due to the overhead of code familiarization, setup, testing, and regression testing.  In addition, the cost is very different if the framework is not set up correctly in the first place.  Changes to the architecture take longer.
  3. One company assigns points to the bugs.  Developers go through a scrubbing process to make sure the points that are assigned are consistent.  There might be a way to gather some of the point information and convert it to a cost.  

Please email lingochat@lingoport.com if you would like to join a future LingoChat.