Localization, Internationalization, Globalization? Choosing Wisely

by Adam Asnes for MultiLingual Computing

Many companies with complex software start out knowing they need help meeting product globalization objectives, but they are still new to what help they will need and where technology and language distinctions lay. That’s confounded by grey areas that sit in between internationalization and localization. What’s at stake is meeting delivery time tables, supporting financial objectives and making a quality product that works well everywhere. I thought it would be appropriate to write a bit about the experiences I see working with many companies looking for internationalization help. Full disclosure: I run an internationalization company which provides a wide range of services and product to make the job go faster.

Like most technology verticals, we have some hard to swallow terms in this industry. Many readers of this magazine are familiar with distinctions between localization (L10n) and internationalization (i18n), and the catch all for everything – Globalization (g11n), but I’ll tell you that most of the software development world at large tends to blend it all together in a mishmash of terms that are rarely consistent. Check Wikipedia if you’re reading this and need help understanding the distinctions, but for all intents and purposes they are very blurry to clientele when they first go trolling the internet for help. But very quickly, clients learn that they need to get more discriminating.

When clients go looking for engineering assistance, they often learn late that the basic skills behind localization and those behind internationalization are completely different. They have the same ultimate globalization aims, but localization expertise involves all the issues around working well with language and project management of linguistic resources with only linguistic-deliverable development oriented engineering skills needed. Engineering tasks for localization efforts typically involve managing translation memories, managing resource files, possibly interface geometry resizing, a little build management understanding plus linguistic QA.

Internationalization skills are entirely software development focused. Really the translation is incidental to the target character encoding and locale management in the guts of the software. Internationalization engineers need to be very talented developers who are capable of working with multiple programming languages (as opposed to written languages) and databases, rapidly going from design to development to deployment while dovetailing with your in-house development teams – who aren’t going to sit on their hands and stop creating new features while internationalization efforts are going on.

We actually did a survey (we published results as a whitepaper) of our clients and people that have signed up for our newsletters and communications from our website. The numbers clearly showed that most people, even within our globalization-educated sample, have trouble understanding their own needs, and have often underestimated efforts, scope and distinctions between localization and internationalization.

Different Development Stages – Different Internationalization Needs

Differentiating your immediate situation will help you optimize your choices with vendors and appropriate solutions. Here are some examples:

  • Your software hasn’t been created yet:

    • If your software is first being developed and you’ve established that your globalization requirements are important. You have a great opportunity to minimize expensive surprises from the outset. The types of services you might be interested include:
      • requirements development
      • architectural planning and documentation and
      • training

Consulting might include a product to monitor internationalization development progress, perhaps reporting issues during your regular build process.

  • Your software is developed

    • You want to get it internationalized using your own internal engineers. Usually internationalization efforts need to be performed on an as fast as possible basis. Given that your team may be inexperienced with internationalization issues, consulting can help you effectively leverage your team quickly. You need an educated assessment of what’s involved and what resources will be needed, solid cost estimates and architectural assistance. Internationalization efforts must dovetail with new feature development and ongoing maintenance needs as there often are sets of choices that will need optimizing. Consider:
      • requirements development
      • architectural planning and documentation
      • training
      • productivity software
      • ongoing Development Assistance
      • project management
  • Your Software is developed, but you need to outsource internationalization

    • Maybe your development team has to concentrate on building new features and achieving development goals for your current customer base, and you can’t divert them into focused internationalization efforts. Or perhaps you have a globalization promise that you know you just can’t meet with your development staff. It really makes sense to outsource as that helps fill the expertise gap and you can meet more of your development and marketing goals in less time and arguably less cost. Here’s what you need and what you should insist on:
    • All of the services listed previously plus…

      • You’ve got to be in LOVEwith this team
        • I mean really, this team is going to get deep into changing stuff in your code that you’re going to live with a long time.
        • You need to see really good communication going on
        • The developers need to understand, your team, your product, your objectives clearly
        • Planning processes should be used to help you build confidence in the team
  • A clear and detailed development plan that all parties understand and agree to
  • A strong code management strategy
    • Does it make sense to branch the source? Who’s merging where and when?
    • The right answer depends on working out the solution
  • A joint test plan
    • No outside vendor who’s just been thrown a million lines of your legacy code is going to be able to quickly adapt to knowing and testing your software with as much experience as you have. You’ve got to work together to bridge knowledge gaps.
  • Good documentation skills so you’ll know exactly what’s been done to the code
  • And of course the ability to provide you with ongoing help once the project is done

The next time someone asks you for code translation, localization development, Unicode translation, or globalization, consider that you need to ask a few questions before you leap into guessing what that means. Chances are good even they don’t really know till you work it out together.


*Don’t get me started with the idiotic acronym that is GILT (Globalization, Internationalization, Localization & Translation). I suppose someone wanted to make everyone happy with that one, and forgot that GILT sounds a little too much like something we get from our mothers when we don’t call home.

Your Project is Late! Any Idea What that Costs?

by Adam Asnes for Multilingual Computing

A local leadership conference a few years ago featured a live panel discussion including Eric Schmidt, CEO of Google, and Michael Moritz of Sequoia Capital, a Google’s investor and board member. The first question tossed out was: what makes a company great? Mr. Schmidt quickly answered, “Any great company will make over 50% of its revenue outside North America.” To which, Mr. Moritz fired back, “Yeah, but everybody’s always late on international products, particularly for Japan and China.”

Eureka! Here were two leaders of one of the most influential companies in recent business history singing my song. I wrote down that exchange and still use their quotes in many of my presentations.

So why are international products so often late? And what does that have to do with business greatness? We’ll tackle those questions in this article.

Software Globalization Delays

International products may be late, ranging from business agreements to product development. Your customer or distributor may have their own timetable and priorities that suddenly veer off from your needs.

But in the world of technology product development, there are very real ways to reduce delays – and risk – by accurately planning for and executing development efforts. Given what’s at stake, that’s a very serious question, which sometimes doesn’t get treated by product development teams with the gravity it warrants. When a company is late with a product, it has a very real impact on a company’s income, as well as its competitive position.

A simple exercise using round numbers bears this out. If the Acme company plans to adapt its software to accommodate new sales relationships in Germany and Japan, chances are, before a single developer begins to figure out the tactical aspects of internationalizing code, revenue projections are already set for that opportunity. Let’s say those agreements are worth $10 million in their targeted fiscal year, so a three-month delay reduces available revenue by one quarter, a substantial amount.

But it doesn’t stop there. There are a host of other costs involved. If Acme’s product is late, sales people, offices, marketing efforts and customers are waiting also. Entire teams, whose salaries and costs can’t be optimized until the release is ready, are idle. On top of that, the core development team internationalizing the software isn’t working on key new features for current customers, so there are significant hard costs as well as opportunity costs at stake.

Even with clear additional costs, let’s evaluate simple time to market effects on profit and loss (P&L). We’ll assume a general cost profile consistent with firms Lingoport has served in recent years. And we’ll assume that the product experiences only modest growth over a five-year timeframe.

The P&L below, showing the results both with and without i18n factored in, are below:

As shown, the firm stands to benefit substantially through reducing time to market alone – enjoying nearly 6% increases in both revenue and EBITDA, most of that impact occurring in year 1 of the analysis, with smaller advantage in each subsequent year. If higher sales growth expectations or the expected cost savings from the localization effort to produce these results were included, the impact would be even greater.

And most importantly, for this same product, the same financial improvementwould accrue to each subsequent localization project targeting other overseas markets. That could multiply the benefit by as much as 10 times, given the diverse international markets the average firm might address over time.

Considered from this perspective, development management should always consider enlisting some expert help when dealing with internationalization issues. After all, it may be the first or second time their team has actually planned for or executed an internationalization effort. Internationalization, almost without fail, ends up being more complex than any developer on the clients’ team anticipates. In fact, our 3 month lateness benchmark is likely conservative; the reality is often much worse.

The issue is critical enough that some large global technology companies have built internal internationalization departments that move from development team to team, helping make sure the effort goes as planned. Most companies don’t have broad enough product development needs to warrant growing internal resources, but a few – especially globally ambitious software leaders – do.

A very real world example from Lingoport’s experience involved a client with an online auction system for heavy road building and construction equipment. They simply had to have their product internationalized before the spring construction season started, or they would miss heavy seasonal demand. At the same time, their development group had other deliverables they had promised for their current customer base.

With Lingoport’s support services staff to help, it was a happy story of on-time delivery. But what if the client’s team had elected to struggle through internationalization themselves and been confronted by expensive and time-consuming surprises that inevitably occur when thye lacked the experience? Fortunately, the client’s engineering management, deeply experienced in commercial software development for global markets, saw that risk in advance. Not everyone is so lucky.

This is all familiar territory, in my firm’s experience. Internationalization is frequently underestimated and under-scheduled, for a variety of reasons. First, remember that software developers are a pretty smart bunch. After all, they built the software in question. Who knows it better than they do? Plus, they enjoy an interesting new technical challenge. So it’s natural for developers to conclude they can handle the effort themselves, without the inconvenience of dealing with outsourcing experts, developers or tools.

The reality is that internationalization involves much more than display-focused issues around language. Adapting software to support any locale – not simply the next locale – typically means big changes to how software operates, extensive changes to database schema, research and adaptation to third-party products, and refactoring locale-limiting methods within the code’s operations. There’s a whole new set of QA issues to plan for as well. Until you’ve been through internationalization over a number of technologies, from start to finish, it’s a notoriously hard process to estimate. Exacerbating the situation is the fact that many issues are buried in the large amounts of source code, hard to precisely identify. Lingoport’s Globalyzer software, for example, was built specifically for this issue; otherwise, developers are inclined to develop code analysis and search tools likely to be awkward at best in the identification process.

To help clients quickly get an idea of the internationalization health of their code base, Lingoport’s developed Globalyzer Diagnostics. We’re making it available free, and we’d love your take on it. It’s a simple-to-use utility that counts internationalization issues and reports on them for you, while giving you basic decision-supporting information about the extent of internationalization issues in your code. It provides a quick, easily understood code “health check”, specific to internationalization issues.

Understand how serious delays are to your company’s bottom line and market efforts. Know the revenue projections and business factors involved. Then make sure you go into internationalization with your eyes wide open to the potential for delays and the consequences and how to minimize the risk. Would you want the cost of being late to be on your head?

Getting Globalization Projects Approved and Started Fast

Getting you software internationalization project approved
Just last week I visited with a past customer with a possible new project. Actually I was there primarily discussing implementing Globalyzer, and they brought up the possibility of having our team provide services for them.

The situation was not unusual in that they had clear high-level directives (as in get it done yesterday) for the internationalization effort, but hadn’t figured out the how part of the equation. As is often the case, the first request was to do an extensive assessment and architectural document. I told them what I’m going to tell you here. We’ve found projects that start with detailed technical assessments and documentation, often end up stalled for a year or more.

While assessing and architecting are essential activities, they don’t give executives the Return on Investment (ROI) answers, nor the teams involved the picture they need to initiate development. After seeing many projects flounder, we’ve changed our approach with our customers to first perform a quick budget analysis and project plan. We do this through a combination of interviewing technical staff and management to quickly gain architectural knowledge, while leading discussions on requirements.

In parallel, we perform a detailed code analysis using Globalyzer to create an accurate inventory of code-level issues including embedded strings, locale-support-limiting methods and functions and analysis of the database schema. By combining our methodologies with Globalyzer’s broad power, we can get a quick picture of what must be done, even over very large and complex code bases.

This in turn gives our customers a set of numbers, requirements and time frames from which they can align budgeting, resources and global sales and marketing efforts. Once that’s taken care of, more detailed design and implementation is ready to begin.

Take the time to read our Globalization ROI whitepaper in our download library. It provides example ROI formulas to help you think and present software globalization in terms your CFO or other executive members will appreciate. For him or her, approval will be first about presenting returns and a clear path to success, rather than interest in the detailed technical issues covered in an architectural document.

Got a project that needs internationalization yesterday? to get it on the fast track.