Using Advanced Branching for Continuous Localization

Software Development Branching

Before writing code, developers will first create a branch, typically from the main repository branch, such as master or develop. A branch works like a copy of the entire repository. This allows a team of developers to work in isolation and write code in an environment under their control. Once the code is written, the branch is merged and becomes part of the main branch.

Translation for Repositories?

Resource files are files to be translated: .properties files, .resx files, .json files are de facto standards. For example, a file ‘messages_en.json’ may contain key/value pairs, where the value is displayed in the UI of an application. When the locale is switched to French, the values from ‘messages_fr.json’ are used to display the French strings for the same keys.

Keeping track of what has been translated, what has been sent to translation, what is being returned from translation, in what order, for what locale, while passing validating checks on the resource files is time consuming and a pain point for most development organization. Lingoport Resource Manager, or LRM, the Lingoport product seamlessly automates the checking,  sending, and receiving of resource files.

LRM needs a branch from which to find the resource files to be translated and to which to push the translated files. A straightforward way to on-board LRM project is to dedicate one branch to translation. LRM can rebase so that the translation branch also gets the commits from master or a deploy branch, keeping it up to date with the overall source code development. This makes for easy LRM project, where files are picked up from the translation branch and pushed back to the translation branch exclusively.

The benefit with this approach is the simplicity of the on-boarding and knowing only that branch will be affected by LRM. The drawback is that localization happens after all the development is done in a branch separate from everything else.

Advanced Branching

Git has made branching a lot easier and flexible. Developers routinely create a branch for a feature or a bug fix. Resource files are part of the artifacts created during development.

For one application, you may have one repository or you may have hundreds of repositories. You may have a couple of resource files to be translated into three locales, or hundreds of files to be translated into tens of locales. Many development organization would like to include the translation of resource files as part of the regular activities of development, inside the feature branches directly as opposed to a specific translation only branch. To do so, we recommend using LingoBot.

Lingoport Advanced Branching

LingoBot is a Chatbot which works within collaborative environments such as Slack or MS Teams. The user issues commands that the Chatbot passes along to LRM. Here is an example of a session of LingoBot in Slack:

Here the user “Andrew Wong” wanted to check the translation status of a branch, F1404-desktop-group-delivery, for a repository called ‘SSTO.webapp’. There may be lots of different branches on this repository. The one that Andrew Wong is interested in is only the “F1404-desktop-group-delivery” branch. That’s were the feature is being developed.

The system gives an overview of the status and a link to go to the Dashboard to see more information.

At some point, when the development team is ready, the files need to be sent for translation. Instead of hand picking the files from the right repository, the right directories, the right branch, verifying the correctness of the files to be sent, how many to send, tracking the files in some XL sheet, sending an email with attached files, having the attached files downloaded on the translation side, checking the files, on-board a new TMS project, it’s simply a command to tell LingoBot to send whatever is needed to be translated:

When the translation is done and send back to the repository automatically by LRM, a Slack notification will let that room know:

Note: It also provide a link to GitHub in this instance to the repository where the files were pushed and another link to the LRM Dashboard.

LingoBot and I18n

Another usage of LingoBot is to ask for the i18n issues for the files which were modified in that branch. A team of developers may modify a few files during a sprint. The overall code base may have a huge amount of files. To make sure the new code does not have more i18n issues, the command is ‘i18n scan’. It will use the Globalyzer configuration for that project to scan only those files which were modified in that branch.


Lingoport provides an elegant solution to complex branching and all the resource files which works from collaborative environments that developers and other team members are already familiar with. They only need to know a few simple commands, and the automation takes over. This fits in with the way software development is done in most modern companies.

An Interview About i18n Gremlins with Adam Asnes

Adam Asnes, LingoportAs part of Lingoport’s webinar, The Most Common i18n Gremlins and How to Squash Them, we interviewed Lingoport’s own CEO, Adam Asnes to get some quick insights into i18n gremlins and how they are impacting the quality of localization.

View i18n Webinar Recording


What are i18n gremlins?

Adam Asnes: I18n gremlins are bugs that create localization problems that wouldn’t be tolerated in a product’s native target language (i.e. US-English). They could be as simple as a string that isn’t externalized and will appear in English no matter the target locale, a date/time in the wrong format, a concatenation where the word order, gender or pluralization won’t make sense for translation. These gremlins aren’t cute mistakes and often have a long lifetime until they get fixed.


As software development as evolved to become continuous, how has this impacted the frequency of i18n gremlins going undetected and the impact to the localization quality?

Adam Asnes: It is always far easier, faster and less expensive to fix an i18n gremlin during code creation rather than after localization. With continuous development, we have a clear opportunity to measure i18n and give developers feedback during their sprint, just as you might do for other coding quality measurements.

The impact of i18n gremlins is on the frequency and speed of agile development as developers simply may not have time to go back and fix issues if they are discovered after localization. They will be working in a different area of the source code and just seeing the issue after testing usually doesn’t make it obvious where it occurs. This is why i18n Gremlins can hang around for years.


What is the biggest consequence developers face when they do not proactively prevent and rectify i18n gremlins?

Adam Asnes: The consequence is that the localization and global sales stakeholders have products where they can’t guarantee the presentation and data quality. You localize in the first place for competitive advantage or at least parity in markets. There is so much invested in global opportunities. The US is 24.4% of the global economy measured in 2017 down from 60% twenty years ago. Why not have a product that reflects that?


What i18n issue would you describe as the king of all gremlins?

Adam Asnes: Indifference is the king of all gremlins. When executives remain ignorant, you don’t have global directives. When managers remain indifferent, you have a sloppy attention to i18n. When developers remain indifferent, you have shoddy application of locale.

For a list of i18n Gremlins, see:


Ready to learn more? View the recording today!


  • Date: July 30, 2019
  • Time: 9AM Pacific, Noon Eastern, 18:00 CEST
  • Duration: 40 minutes, plus audience Q&A


View i18n Webinar Recording


An Interview About Improving L10n Quality in an Agile Environment with Jim Compton

As part of Lingoport and RWS Moravia’s webinar recording, A Proactive Approach to Global Release Quality, we interviewed Jim Compton, Technology Partnerships Manager at RWS to get some quick insights into the state of localization, building quality into each step of the process in alignment with sprints, and other topics he discusses in the webinar.


View i18n Webinar Recording


Lingoport: Since the start of your career in the mid-90s, what have been the most significant changes to the localization industry over the years?

Jim Compton: Back when I started, the idea of content was pretty different. It was created, first of all, uni-directionally, so it would be created by a single entity and then deployed out into the world. There was a single direction of content creator and content customer. That’s really changed. The people who are consuming content are also creating content now, and I think that’s created altogether more pressure to be agile.

Previously, you might be able to plan with your product, releasing software documentation and help, let’s say as a package. You might say, “Oh, we’re going to release in Q2 of this year, and then we’ll release our localized version sometime after that.” Industry changes have made that a not very competitive or viable way of doing business anymore. You have to be in a state of constantly releasing and iterating.

That, of course, has put pressure on the concept of the localization project, this idea where you can wait for the customer to be done with what they’re building, and then start a localization project with a defined end date. That’s totally been displaced with this model where things are constantly being created and revised and need ongoing localization support.


Lingport: For a company new to localization and aligning with sprints … what is the top advice that you would give them?

Jim Compton: Quality is a layer; it’s not a step. If you have mistakes upstream in a process, those mistakes will end up compounding throughout the process, and if you’re waiting until the end of the process to identify them, it becomes exponentially more expensive and time consuming to correct them. In turn, you’re increasing your cycle time past the expectations of an agile production cycle.

So, the idea of trying to prevent the problems upstream, becomes really paramount. There are different ways that you can do this, but the practice of internationalization is really consistent with this idea. Make sure that before you go from a phase of development or authoring the software into the next big step of localization, you proactively take measures to prevent potential upstream errors.

Treating quality like a layer instead of a step means if you think of it like a layer, you actually add quality control in every step of the process.


Lingoport: Looking into the crystal ball, what new developments do you see in store for the localization industry in the coming two years?

Jim Compton: I think the big technological shift that I’m seeing right now is a change from the concept of localization to the idea of global content management. Instead of content being created with one market in mind and then adapting it to make it work in other languages, cultures, etc., you create content that is meant to be global from the start.

This, I believe, is fundamentally different than the current localization paradigm. The people who are designing/creating the global product must embrace localization best practices, rather than just viewing it as a next step activity

Another big shift is the definition of what content is. In the past, content was primarily considered something you read, however content now goes far beyond text, and even includes things such as voice data. I think the word content is evolving to mean data, and part of the value of the localization industry won’t be just providing translations but will be to provide global data.

Why is that useful? Data is the thing that can be applied to make intelligent decisions about big picture things like, “Should we double down in this market?” “Is what we’re doing in this market working for us?” “Do we need to do something else?” Having that data available when someone is managing their global content program will help them create content that’s likely to have the highest positive business impact.


Ready to learn more? Check out the webinar recording!


  • Date: June 13, 2019
  • Time: 9AM Pacific, Noon Eastern, 18:00 CEST
  • Duration: 40 minutes, plus audience Q&A


View i18n Webinar Recording


Webinar: A Proactive Approach to Global Release Quality

Check out our webinar recording, “A Proactive Approach to Global Release Quality,” and learn how to increase speed while improving quality through technology, processes, and integrated QA.


View i18n Webinar Recording

Bringing Quality and Speed Together

With Continuous I18n and L10n, there’s always pressure to deliver on speed, but it’s of equal importance to deliver exceptional quality. I18n issues, bad file formats, poor translations and a host of human errors consistently break the gains achieved through automation efforts.

Integrating QA to Deliver Superior Speed and Quality

In our June webinar recording, you’ll discover how to not only go faster, but how to deliver higher quality for software translation. We explore the benefits of technology and processes along with how to make QA an effective and continuous part of development, rather than something that happens after a sprint is complete.

We also look at ways to ease push back from developer teams and other stakeholders tasked with delivering new functionality on a tight schedule.

Featured Guest

The webinar recording features special guest, Jim Compton, Technology Program Manager at Moravia’s Language Technology Group. Jim is a localization-industry maven with over twenty-one years of multi-faceted experience. He’s created and implemented solutions to address growing global content needs and has developed a reputation as an innovator and passionate problem-solver.

View i18n Webinar Recording


  • Date: June 13, 2019
  • Time: 9AM Pacific, Noon Eastern, 18:00 CEST
  • Duration: 40 minutes, plus audience Q&A

View i18n Webinar Recording

Detect Software Issues Early Using Pseudo-localization

You’re releasing software in multiple languages for 6 markets. You get back your localized files and get ready for release. But now, at this late stage, you’ve discovered issues. Some of your interface is still in English. Perhaps dates are still showing up in a US-centric format? Perhaps the translations aren’t displaying properly because there isn’t enough space in the UI? Or, you’ve got square boxes and garbage characters that should be displaying in Japanese.

While you could find many of these issues during software development using Globalyzer (when it’s easy, fast and cheap to fix), it is still wise to have a global testing plan that includes pseudo-localization. You can test for localization support, and as a result, not have surprises after translation.

What is Pseudo-Localization?

Pseudo-localization is a technique that helps software development teams detect potential issues around user facing strings early on. Pseudo-localization transforms resource files written by developers and shows the transformed strings when a specific locale, the pseudo-locale, is passed to the application.

String Externalization

When developers write code for a global market, the strings need to be moved from the code into resource files. This process is called string externalization. If the strings are not externalized, they cannot be translated and a user looking at the application will always see the strings in the same way, with the locale set to German, French, or Japanese. Strings which are not externalized are called hard-coded strings.

For example, in some code using .ejs, if the string Family Tree is hard coded, setting the locale to French will still have “Family Tree” showing in the UI:

<span class=“visible-phone”>Family Tree</span>


If instead the string is externalized, it can be translated and setting the locale to French will show another string:

The .ejs file snippet:

<span class=“visible-phone”><%- i18n(‘FamilyTree’) %></span>

The corresponding .json resource file snippet in English:

FamilyTree: “Family Tree”,

The corresponding .json resource file snippet in French:

FamilyTree: “Arbre Familial”,

The UI set to French:



When strings have been externalized into a resource file, they can be transformed for testing purposes independently of translation and that transformation can be shown in the UI using a pseudo-locale.

French is a typical ‘real’ locale: French users will most likely want to see the application in their language. The same is true for most regions, like Japanese, Chinese, Spanish, etc.

A pseudo-locale is a locale that is not a going to have many, if any, users. A typical pseudo-locale is Esperanto. Very few if any users will want to see an application in Esperanto so it makes it a good candidate for a pseudo-locale.

Using the previous ‘Family Tree’ example, here is a possible corresponding snippet in Esperanto:

FamilyTree: “[Ƒåɱîļý Ţŕéé—- П國カ]”,

When viewing the application in Esperanto, the banner will now look like:


Why Pseudo-Localize?

The benefits of pseudo-localization are many, including:

  1. If the strings are displayed in pseudo-localized form, they have been externalized and can be translated.
  2. If the strings do not have any mojibake (corrupt characters), the user interface displays Unicode characters correctly.
  3. If QA can see the start and end character (here “[“ and “]”), the layout takes care of strings which will be longer when translated, say, in German.
  4. Pseudo-localization may also help identify concatenation issues, for instance when in what should be the same resource, the end and start characters appear multiple times.

When to Pseudo-Localize?

Pseudo-localization should be part of localization (L10n) automation. For instance, Lingoport Resource Manager, or LRM, automatically pseudo-localizes all resource files as they are modified or based on a frequency, such as twice a day.

This means that ‘someone’ does not have to think about it, ‘someone’ who may have other things to do such as coding an application.

Both Lingoport’s Globalyzer and Resource Manager support pseudo-localization. The former, helping developers unit test their work, the latter, on a continuous basis so that QA can always use pseudo-localization in their test criteria. It should be noted that pseudo-localization is a testing procedure, while using Globalyzer, particularly when it’s implemented within an IDE, helps avoid internationalization (i18n) issues as software is developed (and when it’s most efficient to fix). This includes i18n bugs beyond string-related issues. Even so, we always recommend implementing pseudo-localization as part of your software development practice.

New Webinar: Measuring Your Software Localization Process ROI

Return on Investment (ROI) is critical for the justification of business initiatives, as it strengthens an organization’s financial health and ensures more sustainable business success. The gap between localization (L10n) and development has been an ongoing pernicious complaint in the software industry for many years, and this gap has continually eroded returns for software organizations. 

Emphasis on agile and continuous development brings software users new functionality quickly, with controlled risk, faster execution, feedback and adaptation. L10n is performed to raise the appeal and competitiveness of software in any particular market. There should be alignment between L10n and development to maximize business results, yet why is it that the majority of software organizations are lacking in sophisticated internationalization (i18n) and L10n practices, systems, and technology to bridge the gap?

View our webinar “Measuring Your Software Localization Process ROI” to help your organization understand the underlying causes of increased time/costs in the software L10n process. Uncover how your L10n can keep pace with software development and help you achieve greater efficiency, cost savings and business returns.

View i18n Webinar Recording

Special Guest

Darin GobleOur special guest on the webinar will be Darin Goble, Director, Client Solutions at Welocalize. With 20 years of experience in the localization industry, Darin has worked in production, engineering, solutions and management roles in four different services organizations and held technical and finance roles at Hewlett Packard. He has also served on the Project Management Institute’s board of directors for the Portland Oregon Chapter.


ROI Calculator

All webinar attendees were provided with access to an interactive ROI calculator that enables you to see your potential ROI gains through available software L10n automation.

Webinar Date/Time

  • Date: Wednesday, January 30th
  • Time: 9AM Pacific, Noon Eastern, 18:00 CET
  • Duration: 45 minutes, plus audience Q&A

View i18n Webinar Recording

Take the 2019 Survey! The State of Continuous Internationalization & Localization

Today’s software is built using agile methodology, which is superior at getting new features out fast, in contrast with waterfall. Many in the industry have talked about making Internationalization (i18n) and Localization (L10n) continuous, automated and in step with agile.

Yet, in a Lingoport survey last year, it was obvious that the industry still has a long way to go. For example, merely 8% of respondents thought they did an excellent job at measuring and managing i18n requirements. One respondent summed up the reality of the situation: “We do agile development but waterfall localization.”

Following up from last year’s effort, we are conducting a new 2019 industry survey. To that end, we invite you to take the survey and let us know your company’s level of adoption of continuous i18n and L10n.

Take the 2019 Survey

powered by Typeform

The survey takes only 3 minutes. If you enter your email address, we’ll email you the results upon conclusion of the survey.

Plus, for each entry received we’ll donate US$2 to Translators Without Borders. So, please help us in accurately capturing the state of the industry while helping a good cause.

New Lingoport Suite Release: Continuous i18n & L10n

We are pleased to announce new releases of our products within the Lingoport Suite, including Globalyzer 6.2, Lingoport Resource Manager (LRM) 4.1 and Lingobot 2.2.

Lingoport Suite products work together to deliver continuous internationalization (i18n), localization (L10n) and Linguistic QA, eliminating iterative globalization fixes and making global releases efficient and timely.

Globalyzer 6.2 adds improved i18n issue detection and sharing, expanded Android support, and more project sharing for i18n analysis within developer IDEs.

LRM 4.1 adds more ways to deliver continuous L10n across multiple products and repositories. We’ve added a Text parser, supporting text files for translation, a YAML Parser, improved automated resource file locators (especially powerful for microservices), more pseudo-localization support expanding in-context testing, and more prep-kit control for launching localization.

Lingobot 2.2, Lingoport Suite’s Chatbot to assist collaboration and engaging i18n and L10n, adds MS Teams support, translation status for all locales, status for specific locales and a new cleanup command for when a branch doesn’t exist any more.

See the links below for release notes and more feature details:

Want to see Lingoport Suite in action?

View a dashboard for an open source project,  or contact us to set up a demo where we dive deeper into how Lingoport Suite impacts software i18n and L10n.

New Webinar: Concatenations, Bad File Formats and Other Gremlins

There are certain internationalization (i18n), localization (L10n), and quality assurance (QA) issues that commonly arise in software organizations. As an i18n solutions provider, we see these problems at many of our client organizations when they first come to us for assistance. These issues not only make for poor L10n results or worse, they can even break localized builds and ultimately hurt business performance.

The Most Common i18n Issues

In Lingoport’s webinar “Concatenations, Bad File Formats and Other Gremlins,” we demonstrate a few of the most common and problematic issues, with solutions for finding and fixing them at their source, rather than finding and fixing them later in testing…or worse, after release when it’s much more costly and time consuming. During the webinar, we look at:

  • Concatenations
  • Improper date formatting
  • Character set issues
  • Dealing with messy resource file formats
  • JSON and YAML issues
  • Continuous QA

View i18n Webinar Recording


Date: December 6, 2018
Time: 9am PT | 12pm ET | 18:00 CET
Duration: 45 minutes, plus audience Q&A

Agenda Highlights

  • Identifying common i18n, L10n, and QA issues during global software development
  • Methods for uncovering these issues at their source during development
  • Strategies for fixing issues efficiently, reliably, and in a scalable manner
  • The benefits of continuous QA
  • Audience Q&A

View i18n Webinar Recording


Webinar Recording: Integrating i18n Expertise with Your Development Team

When working with outside internationalization experts to facilitate the global release of your software products, you’ll be faced with a key challenge: how to best collaborate in a way that drives efficient global releases, while also transferring knowledge to your internal development team.

In Lingoport’s webinar “Integrating i18n Expertise with Your Development Team,” we feature a case study of an i18n engagement with a leading medical and veterinary products and technology company involving Lingoport’s services to internationalize the client’s SaaS application.

Like many managers, our client wanted his team to be a part of the i18n effort, gaining i18n knowledge through the process. At the same time, he also needed to balance his resources with budget, availability, and other concurrent development efforts.

During the webinar, we discuss the initial challenges in finding the right balance, as well as lessons learned and successes achieved.

View i18n Webinar Recording

Agenda Highlights

  • Formulating a plan
  • Assigning work responsibilities
  • Cadence of meetings
  • Project risks
  • Gaining team buy-in
  • How the work gets done
  • Localization in parallel
  • Success stories


  • Date: October 30, 2018
  • Time: 9am PDT | 12pm EDT | 17:00 CET
  • Duration: 45 minutes (plus audience Q&A)

View i18n Webinar Recording