Continuous Globalization Makes You Fast and Agile

The localization industry has been late to the party regarding continuous integration (CI) of its services with software development. Continuous Globalization is finally getting the attention it deserves now, and that’s a good thing not only for the software industry but also for end users around the world. Here’s what continuous integration, and more specifically continuous internationalization (i18n) and localization (L10n) are, and what it can mean for your software development process.

The Basics of Continuous Globalization

For the uninitiated, Wikipedia defines software continuous integration, or CI,  as the practice of merging all developer working copies to a shared source repository several times a day. Multiple builds and automated tests and quality profiles are run against the code to identify bugs and other issues quickly. The sooner you find those issues, the less costly in time, effort, and money they are to fix. CI is fundamentally supportive of agile development principles. Automated quality profiles can include coding quality measurements, security, and more.

Lingoport has been working with some of the largest, well known global technology brands with its continuous internationalization suite of software, Lingoport Suite, including internationalization support for developers, QA support, and localization streamlining. These products work seamlessly with agile-friendly localization providers, providing software companies with systems and services to back up their fast moving product development efforts.

Beware the Invisible Costs

Happily, we don’t usually have to extol the benefits of CI to development teams. I’ll also note that internationalization (i18n) and localization (L10n) requirements are far more openly received than years ago.

That said, managers will comparison shop to lower localization costs per word but can inexplicably regard engineering costs involved in chasing i18n bugs, accounting for localization file updates, and iterative testing as invisible. That typical process involves manual, error-risk prone work even if there are scripts involved. If anything goes wrong with file formatting or myriad other nits, the time to trace it back and fix it eclipses a few penny savings here and there, and can be downright costly in financial terms and damaging from a brand perspective when viewed holistically.

For example, if you consider a SaaS application, perhaps with 5 to 15+ simultaneous sprints running at any given time and with three to five developers per sprint team, there is a lot of room for i18n issues to arise. The localization for any particular sprint or release might be quite small. For example: a few words added in one menu, a new error message, and some new functionality that add up to five to 10 new files with an average of 34 words needing localization per file. The minute someone has to manually handle any of that, you’re losing money and momentum. It costs far less in money and time if i18n issues are found right during day-to-day development, and the localization flow from repository to translator and back to the repository is managed automatically, including validation checks.

Dealing with Short, Fast Development Cycles

If your teams are agile (most teams are at least using some form of agile methodology now), it is particularly challenging to include both internationalization and localization processes within a two to three week or shorter cycle. However, we’ve seen clients using systems go from 5 week localization turnarounds, to three days. Consider that if your i18n and L10n are not integrated and automated within your sprints, you are defacto pushing them into the backlog. As your developers move on to successive sprints, if there is a problem with i18n and L10n that needs development and QA attention, they have to stop what they are doing, figure out what the problems are, where they are located, and fix them, and then QA must again verify that fix. That costs time, money, and momentum. It also likely means that your globalized users have to wait for new releases.

Keep in mind that many software development projects are moving to micro services architectures, which break repositories into many little components that get mixed and matched based on product configurations. This makes the business case for continuous i18n and L10n even more pronounced.

Human Factor Issues

Let me give you examples of human factor problems that cause quality, development/QA costs and localization delay issues:

A very common developer practice is to concatenate a string or message to the user. The message builds based on elements such as variables, plurals, and conditions that determine what the software needs to convey. This is how developers are taught to write code. It’s very efficient if there’s only one language involved. Even if that concatenated string is properly externalized, the word order is likely to be completely different in another language, making the translated version at best quaint, and at worst nonsensical. Since the translator doesn’t see the whole string together, they can’t produce a quality translation. However, if concatenations are found right in that day’s work for the developer, correction is quick and painless. Wait until testing, and now we have a multi-step process.

Another example is a developer not using a proper class or method that can support locale, or not passing locale to a class. Perhaps they are using a calendar class, such as SimpleDateFormat (Java). This will render a US formatted date just fine and will pass unit tests, but it’s not going to go well on a system with a different locale date formatting preference.

If you catch these sorts of issues as the developer is writing or committing their day’s work, it’s minutes to fix them. Find them later, and likely QA has gotten involved, the developer has to track down the issue (often not obvious to locate in the code), verify it’s fixed and then update a bug report. It’s no wonder these issues slip in favor of a release date.

Automation, Efficiency, and Speed

For QA, a pseudo-locale is created automatically which adds pad characters around strings so that the tester can see the U/I in English. The pad characters prove that the interface can expand to support likely longer translated dialogs and more complex character sets. Again, nobody has to remember to run a script at some point in time. The updates are automatic and continuous. When the interface is changed by the developer, the pseudo-locale update is automatically updated. This gives QA departments immediate functional U/I test cases for every new feature that confirms to worldwide requirements.

For localization, the changed U/I resource files are automatically detected. Those files are then automatically vetted for quality checks (i.e., no duplicate string IDs, proper file formatting, and more) and sent out for translation or pushed into a Translation Management System (TMS). The localization vendor, which must understand and even thrive in agile localization, then delivers the translations, which are updated leveraging a TMS, Localization Vendor Portal or other translation systems, and our Resource Manager process verifies the file formatting again and takes care of updating the source repository.

Nobody has to track down all the resource files, measure for changes, run a script, verify the file formatting, and figure out issues like duplicate string IDs or silly things like a missing curly bracket in the file format. When the translation comes back, there is no need to manually check the files again, track the fact that some translations came back before others, find a missing translation, or some broken file parameter or encoding. That’s all done. If there’s an issue, it’s clearly described and the fix is fast. If as fallible humans we were to miss any of that, it’s often not detected till much later and even so, it can be hard to unravel. Because there is no human processing delay, linguistic testing can begin faster and within context of the application.

Integrating i18n and L10n has another human factor effect that changes the cultural thinking of the company. When measurement and updating is quick, visible, and relatively painless, you change the way that developers think about globalization requirements. You’ll find teams learn to automatically think about the global implications of their development efforts and the needs of new customers, and factor that into their decisions upfront. As one executive described it, the teams moved from being like a US based company that is looking to do international business, to a global mindset, looking to write software for the world. That makes for global product leadership, rather than a simple checkmark for minimal product requirements.

Strengthening Your Competitive Edge in Global Markets

Remember, there are competitors whose primary model is to copy what is successful in some markets, but use a better localized product to outcompete dominant industry players in new markets. Internationalization and localization are now not just about reaching new customers, they are also about defending customers and capitalizing on new opportunities going forward. What some people think is good enough, is not good enough. It’s best to give your global customers a continuous, excellent, up-to-date experience, or someone else will do that for you.

Additional Continuous Globalization Resources

Bridging Gaps Between Localization & Development

Here’s a 10 minute whiteboard talk posing a solution for gaps in understanding that happen between localization, development, management and QA teams with a focus on agile teams and schedules. Organizational visibility and systems integrated cleanly with build management make for proactive internationalization and localization. We’ll have a webinar with more detail and examples on the subject on October 15th. Learn more and register for the webinar and please watch the video below.


Lingoport Resource Manager Released

Connecting Development and Localization, New Technology Automates Translated File Management

Today, Lingoport announced that it has released Lingoport Resource Manager (LRM) to support development projects in their localization efforts. By optimizing the manual and often error-prone process of resource file management, LRM effectively bridges the gap between development and localization, ridding the two areas of unnecessary testing iterations and file confusion.

In a press release sent out today, Lingoport President noted:

 “During our product research for LRM, we saw great demand for an automated resource manager solution yet no commercial product was available. Localization and engineering teams talked about the difficulty in keeping up with changes and even delaying global release versions because of the management and integration overhead. Our solution allows localization managers and project engineers to automatically view changes right at the build/source management level, prepare those files for localization and then reintegrate them back into the product build when translated, along with quality and error checking in every step. LRM particularly helps agile teams with complex applications in keeping up with development changes and translation processes. It makes globalized products easier to keep up to date for every market.”

Lingoport Resource Manager represents the next step in answering how Agile and localization can co-exist. So often we have heard at trade shows and conferences that the two were not made for each other and many outdated localized versions of projects were released without proper translations implemented. This conundrum inspired months of research and development and we are happy to bring our solution to market.

Watch this introductory About Lingoport Resource Managervideo detailing the processes that LRM automates.

For more details on Lingoport Resource Manager or to request a demo, visit or download the white paper detailing the business case for LRM.

ISO Latin-1 and Canada i18n

Targeting a first time internationalization effort for Canada is one of the more forgiving target locales from a technical risk perspective when working with code that is US English-centric. If there’s a missed string, chances are the user be able to work through it. Currency symbols are represented the same. Numerical units use the decimal point the same. Address formats are the same other than postal codes. However, this can also present a false sense of internationalization compliance. It has consistently been our experience that firms who thought they had internationalized their code for Canada and Canadian French, had much missing upon further examination.

There are a few reasons for this:

  • It’s actually very hard to detect and then measure many internationalization issues. Because understanding of i18n is likely to be limited, there’s a disconnect in the feedback loop to developers when i18n is incomplete.
  • Many developers used on internationalization projects tend to be new to the process and are often not the people who wrote the code. Unless they have powerful tools and strong guidance for architectural changes and planning, they are not going to understand the i18n requirements and be able to fully recognize what changes will be needed – yet they will perceive tasks as completed.
  • Without clear diagnostic tools, it often takes companies at least three release cycles to deal with many stray internationalization issues. New issues tend to crop up with continued development activity. The worst is the first time through.
  • Typically there is an over reliance on creating pseudo-translations and working through a QA process to visually inspect strings. While this is a good process, it is limited by nature in its incompleteness and late and iterative cyclical inefficiencies.
  • I18n is initially understood as a string externalization exercise. While strings are a highly visible component, they are far from the whole story.
  • Locale handling and changes to the database schema represent larger changes that can effect an entire software system. However, they are often implemented the first time in a way that doesn’t account for what is learned later on for more complex internationalization efforts.
  • Programmatically, many things in code can look like strings when looking to find and externalize them. The heuristic logic of this process is difficult, so searching a code base for string externalization usually misses much.

While the above internationalization changes are easy to overlook for Canada, we’ve found that they make themselves more obvious when going to markets, like those in western European locales. They are exacerbated when going to Far Eastern locales, where support for Unicode will require another significant phase of i18n development. Supporting bi-directional languages adds further complication. All of these business developments are greatly supported by using Globalyzer along with additional Lingoport products such as Dashboard and Resource Manager.

Demonstrations of each solution can be requested by contacting Lingoport staff.

Concepts on Being a Globally Aware Company

In preparation for my moderation duties for next week’s 2012 Internationalization and Localization Conference in Santa Clara, I’ve been speaking with the panelists to learn about their experiences over the years in building a globally aware organization.

Some of the information shared with me reflects their systematic approach of shifting more and more of their focus to the start of the globalization process with their internal “customers”, sometimes even before code is written. This focus comes from the years of data they have collected on the cost, time and quality ramifications of shifting issues down the globalization process chain, resulting in other departments have to deal with them – or not at all.

Tools and technology that help organizations collect data, and I mean not just on translation metrics but an overall globalization process, have led to some interesting findings. One panelist on the “Internationalization and Localization Process – How to Make Your Organization Global Aware” will talk about the concept that not all bugs are the same.

What do you mean, Herr Blau? Well, should an embedded string be given equal weight to that of a time/date i18n bug that shows the date incorrectly to a bug that causes data to be read incorrectly with the web application and takes over a week to fix?

The answer to that question, and many more, will be addressed in the panel. The audience also be granted the opportunity to learn from the experts about i.) readiness programs they have instituted, ii.) scorecards that measure globalization acceptance criteria and iii.) how localization can embed into other departments to demonstrate which actions can positively or negatively affect making products world ready.

I encourage you to reach out, comment or email me at ablau(at) if there are other topics or themes you would like me to address to the panel. If you haven’t already signed-up, we only have a few spaces left and now would be a good time to do so to join us in the conversation. Sign up here.

Out of the Flat Black Box: Mobile Apps Localization Strategy

This guest article was authored by Talia Baruch of  Copyous (now LinkedIn).

The Urban Nomad

Sounds familiar? Like someone we’ve transformed into, slowly and steadily, encapsulated by the virtual ritual. Yep, we’re on the GO.  And we demand instant, interactive information anytime anywhere. The Urban Nomad in us is never bound to one place. Wherever we are, across oceans and continents, our carry-on mobile device is our port of communication with the world around us. We pull it out to check our calendar, to interface with our connections, to play games, purchase goods, manage photos, read books, watch movies, or just idly slide-flick through its menu bar, while waiting for our transit.  If 2011 was crowned as the year of the tablet, 2012 is the year of the ultra-thin, ultra-light ultra-book black box, leaving laptops and PCs in the backseat.

Mobile Commerce: Stand out in the Cloud

Mobile web traffic is already surpassing PC-based traffic. According to ABI Research, by 2015 mobile commerce will have reached $119B worth of goods and services purchased via mobile phone. In the less developed world, mobile phones will play a center role in e-commerce, as they are often the only pathway to the internet. This means that companies are now quickly planning their mobile commerce strategy to get a fore and stand out in the cloud within this dominant market. Mobile storefronts now fit into companies’ broader multichannel outreach to consumers. Therefore, when we examine pipeline paths for the localization industry, it is the mobile vertical that frantically calls for our attention.

Reaching Markup Goals

One of the key hurdles localization vendors face in the mobile vertical is the conceptual method of budgeting localization accounts. In most other verticals, reaching markup revenue goals is largely determined by word count volumes. In the mobile arena, however, text is minimal and LSPs need to transition their work scope budgeting to a different ball game model. Typical features in mobile localization are short user interface strings, multiple target language simship releases, focus on layout design, on usability and on compatibility with a variety of platforms: iOS, Android, BlackBerry. Culturalization plays a key role in mobile localization, culturally adapting the usability and design elements to enable a native look & feel for each market.

Global Strategy for New Market Entry

When you explore new market opportunities for your application performance, research what types of applications are popular in the target markets. Brazil, Russia, India, China, Japan and Korea are markets with heavily growing mobile traffic use: smartphone sales, apps store installation, ads revenue and virtual goods consumption.

Visibility & Usability

We often customize the application performance, usability and functionality to the locale culture and usability. Another consideration is determining dominant mobile operating systems and carriers in the target markets. For example, China Mobile is the leading carrier in China. In the Arab world, BlackBerry is still the leading device, while Apple iOS takes the 2nd place trophy. Switzerland is an example for a challenging mobile market, featuring three spoken languages: French, German and Italian; three dominant operating systems: iOS, BlackBerry and Android; three major carriers selling these operating systems: Swisscom, Sunrise and Orange. This translates into a total of 27 test instances, all for one market locale!

Got Game? Measuring ROI of Localized Goods

ROI from localized apps is given, providing you implement sustainable and scalable localization processes and conduct careful market research for product acceptance in new market entry. Electronic Arts’ revamped car racing games localized into Russian yielded a 600% ROI over the English version! Likewise, Julio Vieitez, Director of LUG—distributor of online games in Brazil, reported that a game version localized into Brazilian Portuguese yielded a 15 times higher revenue than the English version in the local market. Not bad for ROI! An example for revenue loss due to mis-culturalization is when “Age of Empire” was localized into Greek. It was banned by the Greek government because of the name “Macedonian.”

Find out who loves your apps and make them love you more. Determine the top-three non-English locales for your apps traction. Localize into these three target languages first, as a tier-one pilot. Not all languages in a localized app will generate significant added revenue. Make sure your translators understand your app and are active users. Detecting terminology nuances is a landmine in apps localization, where jargon and context shape the content. For example, the Chinese translated term for “User” is different in a standard app compared to a gaming app.

It’s the Urban Nomad Bit Again, for Closure

The Early Nomad would travel in search of fresh pasture. The Urban Nomad travels in search of fresh opportunities. His modular, fast pace life style demands multiple adjustments, relocating from one place to another. But all along it is the little lit screen flickering in the back pocket that keeps the humdrum aligned, centralized in cyber space, home away from home.

About Talia/Copyous

Talia is an independent localization and culturalization consultant with 17 years experience optimizing companies’ international outreach. She founded Copyous, devoted to fitted localization program development and management for companies’ go global goals. Talia is a frequent speaker at principal localization and internationalization conferences and an avid contributor at industry roundtables. Contact Talia at via LinkedIn and Twitter @TaliaBaruch.

Localization Strategies for Global E-Business

Lingoport is proud to have collaborated on Localization Strategies for Global E-Business by Professor Nitish Singh, PhD, Associate Professor of Int. Business & St. Louis University Director Alternative Delivery Programs. The book is out now and is available on Amazon and the Cambridge University press websites.

A major focus of Singh’s book is on internationalization, a point of expertise of Lingoport. Lingoport President & CEO Adam Asnes is featured a number of times from describing the best i18n support technologies to the necessity of Unicode in a project.

Preface for Localization Strategies for Global E-Business

The acceleration of globalization and the growth of emerging economies present significant opportunities for business expansion. One of the quickest ways to achieve effective international expansion is by leveraging the web, which allows for technological connectivity of global markets and opportunities to compete on a global basis. To systematically engage and thrive in this networked global economy, professionals and students need a new skill set; one that can help them develop, manage, assess and optimize efforts to successfully launch websites for tapping global markets. This book provides a comprehensive, non-technical guide to leveraging website localization strategies for global e-commerce success. It contains a wealth of information and advice, including strategic insights into how international business needs to evolve and adapt in light of the rapid proliferation of the ‘Global Internet Economy’. It also features step-by-step guidelines to developing, managing and optimizing international-multilingual websites and insights into cutting-edge web localization strategies.

Book Features

• A comprehensive, non-technical guide to tapping the growing global e-commerce market with ready-to-implement localization strategies for effective international web presence
• Presents a blend of strategies, models, checklists, tools, research insights, examples and cases to help readers comprehend the complexities of global e-commerce
• Shows how to avoid common web localization mistakes and, in the process, achieve significant cost savings

The book is available for purchase on


Singh presented a well-received presentation at last year’s Worldware Conference entitled The Rise of Chindia: Opportunity or Threat? The video is available here.

In the absence of the Worldware Conference this year, Lingoport has stepped to the plate to bring the 2012 Internationalization Conference. The conference features several great internationalization and localization tracks as well as an in-depth pre-conference i18n training course.

CNGL Launches Localization Careers Guide

Centre for Next Generation Localisation (CNGL) releases guide urging secondary students to consider language and technology for a potential career

Crafted by Sean Sherlock T.D., Minister for Research and Innovation, the guide is an effort to maintain Ireland’s leadership position in the multi-million euro localization and global services sector. The guide is being distributed to all secondary schools in Ireland this week and features profiles of top professionals, companies and courses to help students get on the right track for a career in localization.

Mr Sean Sherlock, TD, Minister for Research and Innovation, pictured with Prof Josef van Genabith, Director of CNGL, at the launch of CNGL's Next Generation Localisation Careers GuideSpeaking at the launch, Minister Sherlock stated “Many of the world’s largest software and web companies co-ordinate their localization activities in Ireland and the sector contributes an estimated €680 million annually to the Irish economy. It is imperative that we highlight the opportunities available to our young people in this sector.”

For more information on CNGL and the Localisation Careers Guide, please visit:

The guide can be downloaded in PDF form here

For educational resources on internationalization, please visit


Empowering Quality Localization


Localization managers often do not act onL10n bugs that fall in source code because they don’t speak the language of software developers. In this three-minute video, Lingoport VP of Sales Adam Blau presents how these challenges are addressed through measurement and analysis of source code issues that directly affect localization.

Related Content

Comparing i18n Software Tools for World Readiness

Originally posted on

I was asked the other day what the difference is between a Visual Localization Tool (VLT) , such as Passolo or Catalyst, with that of Lingoport’s globalization-enabling tool Globalyzer for software development. The question has arisen during my career because some companies used Catalyst for example not only for software localization, but also for some parts of internationalization (i18n). I thought it was a good question, and wanted to make the distinction to the best of my ability in this here blog entry between Globalyzer and a VLT.
Broadly speaking, a VLT supports the needs for localization and translators, while Globalyzer meets the needs of the i18n and software development community. A VLT is very useful in providing a visual representation of what the UI (strings, menus, dialogs, etc) look like in a WYSIWYG environment. It provides translators with valuable context information to provide high-quality translations without requiring access to the source code. The tools functionality and support is localization-centric in that there is also strong integration with translation memory technology that helps companies integrate previously approved translations and terminology lists into this process. VLT’s can expose internationalization issues that only relate to the U/I such as an embedded string. This is a very limited approach to internationalization, but it can be extremely valuable for localization duties.
Specific to internationalization (i18n), a VLT is not a replacement for internationalization. Any code-base needs to be compliant in advance for the locale it is to support (Set up for locale handing or Unicode enabled for double-byte characters for example). If the code base already reflects behavioral-related inputs, such as calendar/display-based inputs based on the locale, then Passolo or Catalyst are sufficient to support companies’ globalization process. That said, with complex applications, diverse development teams and rapid releases, it’s pretty easy to make mistakes regarding internationalization within source code. A VLT would only catch those mistakes if they can be demonstrated via a static WYSIWYG translation effort. This is unlikely to be even close to sufficient as an internationalization review, and even then, it would likely be very late in the development cycle. By the time code gets into a VLT for translation, it’s often already been tested and released for the software producer’s home market. That’s a very late and expensive time to be revisiting code for internationalization changes.
Globalyzer differentiates itself from VLT’s in the i18n process in many aspects. Imagine a “grammar-check” like functionality that provides managers of all i18n bugs found in the code base, from which they can allocate software developers and other resources to fix, check and test before localization. This can be done from either millions of lines of code or during an Agile process while coding new features and updates. Without a product that reports instances of i18n bugs in advance, finding them and fixing them is often a painful trial and error process.
Support extends beyond a VLT’s string extraction by providing developers with the ability to check for locale-sensitive methods (SimpleDateFormat in Java is a good example, which needs a locale to format a date with the proper month and day names) and a company’s unique programming patterns. Importantly, Globalyzer works for web-based applications and supports .NET, Java and many other programming languages and scripts. That way, companies can check how well data interacts with external systems and databases, such as Oracle or BusinessObjects.
In summary, it is important to understand your requirements in your globalization process and requirements for i18n support. VLT’s are actually complimentary to using Globalyzer as they improve the localization process, which takes places after i18n.
Globalyzer is particularly appropriate if:
  • Your code base is not up to snuff on several aspects of i18n and you are seeking to reduce technical debt around issues like embedded strings, dates, numbers, currencies encoding data, sorting and more.
  • You want to implement a process for developers working in teams to check, fix, and release code before localization testing.
  • Need a notion of verification and QA before and after the build process for software engineers to check files before localization.