New Lingoport Suite Release: InContext Translation & QA

Boulder, CO May 21, 2019 – Lingoport releases InContext Translation & QA along with it’s new Lingoport Suite releases. A picture helps a translator use the right words.

InContext Translation presents translators with contextual views of software so that their efforts are visually supported. Software application translation is particularly challenging as the translator is presented with individual words and short messages that traditionally lack context. As many words often lack direct correlations between languages, this presents challenges. For example, the word claim can be a noun or a verb, with ambiguous meanings without context. InContext Translation solves this problem efficiently, without forcing software developers to make changes to their code or existing processes. With the speed and frequency of agile development updates, it’s very important that localization can keep up, while retaining high quality standards and minimal need for corrections.

InContext Translation top benefits:

  • Saves time, reduces the burden of linguistic review
  • Works for complex web applications
  • No need to change developer frameworks or use proprietary libraries
  • Works with many leading translation systems

“InContext Translation has been among the top product development requests for many years. It’s a difficult problem to solve for complex applications which may use multiple programming languages and technologies,” explained Adam Asnes, Lingoport’s CEO. “We felt we were in a unique position to solve this, given our continuous internationalization and localization software connects to software repositories and can map out where messages occur in source code.”

Lingoport’s InContext Translation release coincides with updates of other Lingoport Suite products, including Globalyzer 6.2.1 and Lingoport Resource Manager 5.0. InContext Translation also joins InContext QA software released previously.

Learn more: <



About Lingoport:

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

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


Contact: Cindy Haag,

Lingoport, Inc.

3180 Sterling Cir #201

Boulder, CO 80301 USA

An Interview About Continuous Localization with Vistatec’s CSO, Unn Villius

Unn VilliusAs part of Lingoport and Vistatec’s webinar, A 360 Degree View of Continuous Localization, we interviewed Unn Villius, CSO of Vistatec, to get some quick insights into the state of agile localization as well as other related topics discussed during the webinar on May 16th, 2019.


View i18n Webinar Recording


Lingoport: Since setting up US operations at Vistatec in 1998, what have been the most significant changes to the localization industry over the years?


Unn Villius: In the early days of localization, it was really something that Microsoft, Lotus, IBM and other big tech companies did.

They were big monolithic projects with a start and an end date. Things were sold on CDs in boxes with big printed manuals, and that was really the core of what we were doing, a lot of software. Software localization has always been challenging, and still is, but what we’re seeing today is a completely different landscape.

The idea of a project is not all that common anymore. For mature companies, localization is now just an ongoing and continuous process, consisting of small and quick turnaround jobs. Additionally, a lot of the content now goes well beyond the software product. We’re talking about marketing, PR, SEO with the global aspects of multilingual search engine optimization, E-Commerce, promotional social media, and more. So it’s a very very different landscape.


Lingport: What are a few things developers do wrong that make it difficult for localization teams to keep up with development?


Unn Villius: 1. Developers are not necessarily familiar with how other languages work so they will not take things into account. In English a singular word can be a verb or a noun, and unless you have context you will not know how it should be used. In other languages the verb version and the noun version would be two completely different words. For example, if I say “field”, that can mean “fielding” a question but it can also mean a physical “field” and those would not be the same words in French or German or Swedish or any other language.

2. Developers often don’t understand that a word needs context to be interpreted correctly. For example, in order to save time developers often start a sentence by saying something like “you need to…” but then they cut off the sentence and proceed with writing a bunch of things that people need to do. Unfortunately, chopping up a sentence like that will cause all sorts of problems in a localized language because depending on what the continuation of the sentence is, you will need to express them differently.

3. Lastly developers typically do not plan for allowing languages to expand. German, Spanish, Finnish, and other languages tend to be longer than English. Therefore, if you don’t provide enough real estate for language expansion, you are going to end up with very chopped up translations. This becomes especially problematic on mobile devices where real estate is very limited.


Lingoport: Are there any example companies you feel have mastered keeping both localization and development in sync?


Unn Villius: Microsoft has always been the trailblazer and other big players, such as Google, embraced the fact that they are global companies with global content, and that’s really where the change needs to come from. That’s where the climate is set so to speak, emphasizing the importance of global content to drive revenue, and if it comes from the top, it makes all the difference in the world.

Go-Pro is another great example. If you go back and look at their news, I think it was about a year ago, they evangelized, the C-suite bought into it, and they actually saw some amazing growth in Japan and some other markets. I’m not entirely up to date, but I do remember one press release where approx. 65% of their growth came from overseas markets. You can see the importance of being able to communicate.


Check out the webinar recording to learn how to achieve visibility between development and localization for faster, more accurate localization in alignment with your sprints.


  • Date: May 16, 2019
  • Time: 9AM Pacific, Noon Eastern, 18:00 CEST
  • Duration: 45 minutes, plus audience Q&A


View i18n Webinar Recording

Webinar: A 360 Degree View of Continuous Localization

Check out our webinar recording, “A 360 Degree View of Continuous Localization,” and learn how to achieve visibility between development and localization for faster, more accurate localization in alignment with your sprints.

It Takes Tech, Process and People


View i18n Webinar Recording


Visibility’s Impact on Global Agility

When each contributor on your global team has visibility into project status and relevant metrics, your organization can be more globally nimble. During the webinar, hear success stories of effective coordination among software localization teams and developers and uncover the underlying drivers of such success.

Featured Guest

The webinar features special guest, Unn Villius, CSO at the localization and global content firm Vistatec. Unn brings 30 years of industry experience, having served roles ranging from Swedish localizer to engineering manager. Vistatec counts some of the largest organizations in the world among its clients.

View i18n Webinar Recording


  • Date: May 16, 2019
  • Time: 9AM Pacific, Noon Eastern, 18:00 CEST
  • Duration: 45 minutes, plus audience Q&A

Who Should Attend

  • Development
  • Localization
  • QA
  • Vendor Partners
  • In-country Stakeholders

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.

Webinar: The New Game Changer for Agile Localization – InContext

Check out the recording of our webinar, “The New Game Changer for Agile Localization – InContext,” and learn how to gain speed and accuracy using an innovative approach to context for software localization through Lingoport InContext.

View i18n Webinar Recording

The Most Requested Feature is Now Here

A critical software challenge is that translators get lists of words in files, but must make assumptions of the context for their translation work. Glossaries and translation memory help, but a picture is worth a thousand words.

Context increases accuracy, lowers the QA burden and increases agility.

In this webinar, we demonstrate how we bring visual context from the source code to the translator’s TMS view, then deliver translations back to the code. This adds speed and accuracy, without impacting development efforts.

This is one of the most requested features from our software customers over the years, and we’re thrilled to deliver it to you now with InContext.

A Repo-aware Tracking System with Visual Context


In this webinar, learn how you can automate in-context translation updates, with a repo-aware system tracking localization changes and providing visual rendering of new strings to the translator.

We present this webinar in tandem with special guest Larry Furr, VP of Product at Lingotek, developers of a leading cloud-based translation management system. In the webinar, we feature how context is moved into a TMS environment including the translator workbench.

Solving the Speed Issue of Software Localization

The key issue that holds back localization from keeping up with development is speed. The leading benefit of continuous localization is moving projects faster, in alignment with agile development. But we still have to translate, and despite all our translator tools, when it comes to complex software, the context of the translation has been a problem.

In continuous localization, U/I strings are sent in small batches, leaving the translator little context for a word or message. The translator might receive 16 words in one file, 32 in another, 6 in yet another, and so on. With words having so much nuance per language, you can understand that this is a tough challenge and a solution creates opportunity for improved global user experiences plus cost, time and hassle savings.

But there is no magic in software and that’s why this challenge remained for so many years. We’ve come up with an elegant solution, and we’ll show you how it works.

Like people say, a picture tells a thousand words.

Webinar Date/Time

  • Date: April 18, 2019
  • Time: 9am Pacific Time | 12pm Eastern Time | 18:00 CEST
  • Duration: 45 minutes, plus audience Q&A

Who Should Attend

  • Localization Managers
  • Product Managers
  • Globalization Leads
  • Localization Team Members


View i18n Webinar Recording

Calculating Software Localization Costs and Savings Using LRM

We’ve created a simple online calculator to estimate your hidden localization costs as well as the potential savings you can achieve with Lingoport Resource Manager’s (LRM) continuous localization benefits. The calculator is not intended to be perfect, but it should help you consider the cost principles involved.

Try the Lingoport Resource Manager ROI Calculator.

Reasons why software localization processing is costing you so much are summarized below.

Mind the GapMind the Gap

The gap between software development and localization has been a sore point since software was first localized. Development moves at a fast pace, with frequent sprints to release new features, and localization needs to keep up.

Status Quo

Out of necessity companies develop manual steps and scripts, with their own process for managing string localization. But these processes often lag behind development and frequently break down with shorter release cycles, small changes to source strings, and inconsistent timing of the return of translated strings.

Chances are good that internal process still takes time, introduces hassles, lacks organizational visibility via dashboard and messaging, isn’t scalable, and can’t be easily cloned for new projects and branches.

We developed Lingoport Resource Manager (LRM) to deliver Continuous Software Localization. LRM integrates with source code repositories so that managing agile localization involves no intervention from the development team and gives visibility, speed and accuracy to all stakeholders – from product development, to localization and QA. It all just works and keeps up with development, while finding file problems early, when they are easy and fast to fix. Clients experience far faster localization that’s right in line with their agile development.

Agile localization projects typically have small numbers of words per file, combined with lots of file handling. Cost per word matters less, as velocity increases and multiple file updates average just over 50 words each. The minute you have to have an engineer handle those files or fix a file formatting issue, cost per word becomes irrelevant.

The critical issue behind that gap between development and localization is that it’s costing you speed and engineering overhead. Localization file bookkeeping pulls resources away from tasks that are core to responsibilities, like creating new product features or dealing with more strategic localization objectives.

Prep Kit ContentAny hitch in the process, like a missing curly bracket or a duplicate string ID, is often found later in QA or when something breaks. That means a developer has to go back and find where that issue occurs, causing additional lost progress.

Developers have come to expect to work with Continuous Integration systems that connect to their source control for automated processes, high visibility, and clear indication of where problems may occur. We see this commonly for security, code review and other coding quality measurements. Localization updates should be managed the very same way.

Status quo tasks that create development-localization gaps, costing your company money and speed:

Sending files for translation:

  • With a new sprint, the localization team doesn’t know what’s changed until they get the files
  • Need to identify the files that have changed across repositories and files
  • Extract the files from the repository
  • Transform the files to a localizable format, or track file locations and content in excel or another system
  • Manually package and send to a vendor via email or FTP
  • Or, upload to a TMS
  • Translation manager or vendor receives and audits the files
  • If there’s a problem with the file, they must fix it

When the translation returns:

  • Developer or L10n engineer must track where the files will go and place them
  • If files come back not in order, or with some locales and not others, the developer is likely to delay
  • reintegration with the translation updates, which then delays testing
  • Problems with files, such as a broken encoding, or a translated parameter, often don’t get discovered until QA or even after release
  • New bugs are created which are difficult to locate, costing you more time and misdirection

Stumbling points LRM solves and automates:

  • Localization turnaround duration from repository to translation and back to repository is out of sync with development pace
  • Human factors, like a developer waiting a few days til she has time, can delay each step
  • Problems with file formats often go undiscovered until they are harder to find and fix
  • Pseudo-localization isn’t automated, so QA may not have globalization functional criteria
  • Manual handling can cause file encoding errors
  • A broken file parameter can break the build
  • Mishandled continuation characters cause further bugs
  • Some strings will be rewritten and need retranslation, causing further manual steps
  • File naming conventions may be erroneous causing further errors
  • Localization needs to be fluid with developer multi-branching and microservices practices
  • Status needs to be visible to all stakeholders
  • Localization collaboration with developers should be facilitated via messaging systems, automated email and dashboards

Learn More:

Measuring Your Software Localization Process ROI [WEBINAR RECORDING]

Return on Investment (ROI) is the ultimate measurement that underwrites so many business initiatives. With software internationalization (i18n) and localization (L10n), there’s significant opportunity to increase sales through global releases, but the time and costs associated with implementation are often misunderstood to the detriment of many software organizations.

Measuring efficiencies with global software releases is tricky. Many inefficient processes around software i18n and L10n are assumed to be necessary, following long-standing practices in the industry. In this webinar, we separate fact from fiction, looking at the actual costs underlying L10n, including costs, time, and quality issues associated with new development with code that’s been internationalized, the L10n process, file management, and QA. We also introduce you in this webinar to our software L10n process ROI calculator to aid you in uncovering your actual L10n costs and potential savings.

View i18n Webinar Recording

Lingoport Continuous Localization products include:

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