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.

• So the first lesson here is that you need to separate your thinking around localization and internationalization in terms of their widely different skill demands.

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.