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>

Pseudo-Localization

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:

Pseudo-localization

Pseudo-Localization

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:

Pseudo-localization

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

Join us on April 18th for 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.

Register for Webinar

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’ll 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

InContext

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’ll be presenting in tandem with special guest Larry Furr, VP of Product at Lingotek, developers of a leading cloud-based translation management system. We’ll 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

Register for Webinar

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.

Welocalize

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/Time

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

 

N7M Puzzle Challenge #2

The winner of last week’s N7M challenge is Ellen Bossert!  Congratulations Ellen.

The correct response was  “Lingoport challenges the localization community to the magnificent numeronym puzzle contest”

Here is a new one for this week

Lingoport e5d p11g in t1e #SDLConnect18 e3t l2t w2k in S3a C3a

How to Play

Welcome to the Lingoport numeronyms puzzle contest.  Numeronyms are spelled with letters and numbers.  For example, the numeronym for internationalization is i18n and localization is L10n.

Here is an example of how the puzzles work.  You will be given a phrase written in numeronyms and you will have to decipher it:

It is f1n to d6r a n7m

The solution is:    It is fun to decipher a numeronym

The first contest is below and the first person to correctly solve the puzzle will win a prize.  Simply email your solution to n7m@lingoport.com.

Note, if you win and don’t want your name to be published, please say so in your email.  In order to make the challenge fair, you may only enter 1 response per day.  If you enter more than one per day, only your first response will be counted.

Lingoport c8s t1e L10n c7y to t1e m9t n7m p4e c5t

Good luck !

The L7t N7M team

P.S.  If no one solves the puzzle we will provide hints every couple of days.

N7M Puzzle Challenge

Welcome to the Lingoport numeronyms puzzle challenge.  Numeronyms are spelled with letters and numbers.  For example, the numeronym for internationalization is i18n and localization is L10n.

Here is an example of how the puzzles work.  You will be given a phrase written in numeronyms and you will have to decipher it:

It is f1n to d6r a n7m

The first challenge is below and the first person to correctly solve the puzzle will win a prize.

Simply email your solution to: n7m@lingoport.com.

Note, if you win and don’t want your name to be published, please say so in your email.  In order to make the challenge fair, you may only enter 1 response per day.  If you enter more than one per day, only your first response will be counted.

Lingoport c8s t1e L10n c7y to t1e m9t n7m p4e c5t

Good luck!

The Lingoport N7M team

P.S.  If no one solves the puzzle we will provide hints every couple of days

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/Time

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

View i18n Webinar Recording