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

 

Does i18n Have an Optimal Sequence?

Suppose you begin the long and complex task of internationalizing your software, only to discover a fundamental flaw in your i18n framework. What if your language files aren’t compatible with the translation vendor? What if the chief architect has identified a key software component for replacement? What if your approach isn’t compatible with each of the locales you wish to target? Overlooking the optimal sequence of i18n, or missing critical components altogether, can lead to significant, and costly, mistakes.

I18n Communication, Planning and Architecture

Large companies with multiple development teams operate within a paradox. The development teams operate independently to ensure fast delivery of product enhancements, but that same independence often results in a lack of communication or big picture design of the system itself. The first step in any i18n project is to communicate with the teams and examine both the long and short terms plans of all aspects of the product.

It’s surprisingly common for long term architectural plans to be overlooked in the i18n process. For example, a company may have a solid framework using RequireJS, and the development team moves forward using the integrated RequireJS framework for i18n. But just a few years later, support for the RequireJS framework stagnates, and the architects find themselves in the unfortunate position of needing to upgrade not only their RequireJS component, but their entire i18n framework that uses it. Following the optimal sequence of i18n would have solved this problem.

Do you write documentation? Small, agile teams often do very little in this regard, preferring instead to focus on manageable enhancements that can easily be documented with a short paragraph. But i18n of a large software product is a different beast, and requires detailed planning and documentation. And with that documentation comes a listing of the components that need to be refactored, what changes are needed with each refactor, and the sequence of refactors needed to ensure a seamless implementation in that agile environment.

Looking beyond design, are there specific refactors in an i18n project that should happen before others? The short answer is yes. Once a proper design has been determined, it’s still critical that upgrading of certain components takes place before others. Failure to do so can lead to lost time as developers wait for dependent projects to complete, redundant passes through code as interfaces are upgraded haphazardly, and bugs in the app when code does not interface properly throughout the entire i18n process.

String Externalization and Concatenation

First, let’s talk strings. Supposed Jeff was given the task of externalizing the strings in the app. With the string externalization framework in place, this would simply be a matter of replacing each string with a call to the string framework. On the surface, the task seems pretty easy: if you see a string, externalize it! But Jeff and his superiors didn’t consider the optimal sequence of i18n, and they overlooked a critical prerequisite: concatenations. So, Jeff continued on his merry way, refactoring strings like this:

   var text = “The ” + fieldName + ” field is required.”;

   and turning them into this:

   key.the = “The “;

   key.fieldisrequired = ” field is required.”;

   var text = GetString(key.the) + fieldName + GetString(key.fieldisrequired);

It wasn’t until much later that they discovered sentence structure plays a key role in localization, and concatenations should therefore be refactored to use insertion points prior to the strings being externalized. Using Jeff’s incorrect refactor, the phrase

   “The Name field is required.”

   could not be properly translated into Spanish since the word “field” (campo in Spanish) switches to the left side of the inserted “Name” (Nombre in Spanish):

   “El campo Nombre es obligatorio.”

   Even further, translators have difficulty translating partial sentences. What does “The” refer to? Will it refer to a masculine or feminine noun? A more proper refactor would therefore have been:

   key.thefieldisrequired = “The {0} field is required.”;

   var text = String.Format(key.thefieldisrequired, fieldName);

By using the refactored concatenation, the Spanish translation can adjust for the revised sentence structure:

   key.thefieldisrequired = “El campo {0} es obligatorio.”;

   var text = String.Format(key.thefieldisrequired, fieldName);

I18n and the Database

Next, let’s talk database. Suppose Sally’s project was to refactor addresses in the app, allowing storage of additional address lines and adding a country. On the surface, the project seemed pretty easy. The db administrator had already added a Countries table for reference, plus added 2 additional address columns to the client database. Sally thought everything was good to go.

But after adding the new address fields and running a test, she discovered that Japanese characters weren’t being properly stored in the database. After a great deal of debugging, she discovered the address columns were VARCHAR and couldn’t store Unicode characters! She spent the next few hours putting in a request to the database admin to upgrade the address columns to NVARCHAR, and waited patiently for the database to be upgraded.

But Sally’s next problem quickly arose. The ZipCode column was only 10 characters long, and she realized that international Postal Codes could be significantly longer than that. So again, she put in a request for a database change, and again she waited patiently for the upgrade.

Sally’s problems, however, were not over. As she continued her i18n of addresses, she discovered that some countries have “States” and others have “Provinces”. The Countries table they’d originally created had no knowledge of this distinction, but clearly one needed to be made. So again, Sally put in a request to the db administrator to add a new column to the Countries table, and waited patiently for the upgrade.

One of the greatest inefficiencies in software development is improper planning. By ignoring the optimal sequence of i18n, Sally and the db administrator had to go back and forth multiple times, upgrading the database piecemeal and slowing the i18n process considerably. The proper sequence should have been: Complete Address Design > Complete Database Refactor > Complete Code Refactor.

Synchronizing i18n Processes

Finally, let’s talk synchronization. The I18n Team at Widgets R Us had a number of front-end and back-end modules that needed refactoring, and they began merging their front-end upgrades first. All seemed fine, until customers began reporting program exceptions in various areas throughout the app. A crisis was underway.

As it turned out, the I18n Team had refactored the dates sent to the server to be in ISO format (YYYY-MM-DD). And while they had tested many of the adjaxPostSync calls, there were still a number of untested interfaces where the server was expecting a localized MM/DD/YYYY format, and the app was crashing with the unexpected data.

Improper synchronization in the i18n process can lead to program errors, and unhappy customers. In the case of Widgets R Us, the server interfaces either should have been refactored first to allow the use of both ISO and localized dates, or the client and server modules should have been upgraded together.

Does i18n have an optimal sequence? Every app is unique in its requirements, but the answer is definitely “yes”. Communication amongst all development teams is paramount, extensive planning and design is critical, and the sequence of implementation is vital. Failing to follow the optimal sequence of i18n can lead to time consuming, and costly, mistakes. Don’t let it happen to you.

Localization Resource File Best Practices – White Paper

One important requirement to successfully delivering continuously internationalized and localized software is to consistently use standard formatting of resource files that will be translated. Though this seems a mundane detail, the minute you consider having a localization engineer clean up files for translation processing, you lose time and money, and you possibly cause errors that could break your localized versions.

There’s absolutely no benefit to doing it wrong, and everything to gain from doing it right. Yet, we see errors here, we think, from lack of understanding, or mistaken approaches. Lingoport Resource Manager (LRM) checks for and enumerates resource file integrity issues when files are created and passed through the system, whether to or from the translator/vendor.

This white paper describes the benefits and best practices for localization resource file creation and formatting. Whether you use our Lingoport Suite software or not, following best practices will help your teams leverage the benefits of locale frameworks and will help you work more seamlessly with localization providers.

You can download the Localization Resource File Best Practices white paper by filling out the form below, and a link will then be emailed to you.

Enter Your Information to Download the White Paper

  • This field is for validation purposes and should be left unchanged.