Internationalization Primer: How helping your client solve coding issues can give you a competitive advantage

Adam Asnes, Lingoport, Inc.

While recent industry headlines have been dominated by merger mania, I think the long term story for GALA companies is really about how to provide better service, products and returns for our customers. Thats how we compete for and keep customers. Within software localization, the functional emphasis is typically on words - word counts, what they cost, when they will be received, translation memories, translation quality, localization engineering and delivery milestones. But for our company, we get involved months, if not years, before our clients are ready to localize. This article aims to show that you can put internationalization to work as a repeatable and successful activity to differentiate your company further as a problem-solver, helping clients get to market faster and more efficiently.

Why It’s Important
Internationalizing applications can be an extremely painful activity for software development organizations. If they do it poorly, they can expect a pretty weak localized product…and guess who gets blamed for that! There are many issues for development teams to consider regarding locale requirements when they create applications. If they are internationalizing existing code, it gets compounded by actually having to find and fix all the issues buried in hundreds of thousands to millions of lines of code. Consequently, our customers tell us things like, “this is actually much harder to figure out and do than we thought.” Internationalization causes long delays in development and that means big delays for localization projects. Plus, companies usually do it wrong the first few times, and have to learn through painful lessons which initially seem like the localization company’s fault - not a good experience for your company to be associated with. I’d wager that many of you have lost customers because clients blamed localization issues on you, which were actually their own internationalization issues.

On the positive side, wouldn’t you want a new and earlier way to be involved with the development managers, product managers, VP’s and CEO’s of your clients? Internationalization is a significant undertaking for many companies. When it’s a new process, internationalization always involves executive decision making. It is not unheard of for our small company to make presentations to the board members of large, publicly traded companies as part of budget planning efforts and global decision making. We think that’s pretty cool! We have unique products and services that make the internationalization effort both scalable and repeatable for development teams, even if they are spread out around the globe. That makes us a strategic bridge for companies going global.

Internationalization 101
You can skip this part if you have a technical background, but it always surprises me that there is still the need to define internationalization within our industry. Though clients often confuse how they use the words internationalization and localization, whenever I talk to them, they are generally pretty clear on the differences in the processes, even if they do throw the wrong terms around. Yet I meet many localization sales people and executive staff that actually don’t understand what internationalization is at all. It’s simply a problem that they have never dealt with. Perhaps there’s more than a touch of “eyes glazing over in boredom” when they see technical articles about the subject; but you really don’t have to make major technical leaps to understand the issues. Simply put, internationalization is all of the planning and execution that needs to be included in the development of software that lets the software support languages and locale formatting (like numerical formats, dates, times, currencies, postal addresses and more). Applications not only have to be capable of displaying any language, they have to correctly allow the input, storage, processing and retrieval of that multilingual/multi-locale data. It mostly breaks down to engineering for a few categories of issues which include:

 

• Character Encoding – Every character you see on the screen corresponds to a set of zeros and ones which get “interpreted” into what you read on the screen. How an application supports character encoding determines whether it will actually work in Chinese, Japanese, French, German, etc. This is where terms like Unicode or ISO-Latin apply. The right character encoding strategy isn’t always obvious and will depend on a balance of marketing requirements, technical requirements and development budget, especially if the code already exists rather than starting from scratch.

 

• String, Images and Resource Management – Every message presented and ultimately translated in an application is referred to in software terms as a string. An important and time consuming part of internationalization involves finding all the user-facing messages (but can also include things like interface sizing), extracting them from the source code, and placing them in some kind of repository files (or database) appropriate to the software architecture. That way you can work on translating the words without breaking the source code. With the right engineering those words can be replaced with any language that the application is supporting. Additionally, string management includes issues like sorting, string concatenation and the like. You’ll also want to identify and manage any images that are embedded in the code (just like strings) so that they may be localized as necessary.

 

• Locale-limiting Functions – Each programming language has its own set of functions or methods that do things like limit the way a date is interpreted, or how many bytes a character can contain. There are hundreds of these sneaky little things in C/C++ and there are dependencies based on your character encoding choice (e.g. Unicode UTF-8). Other programming languages such as Java and C# have less of these issues, but still have their own possible pitfalls. These functions need to be found and replaced with others that support the locale requirements that will be needed.

 

• Locale-limiting Programming Patterns – Programmers may do many of the right things in terms of extracting strings, using functions that support “wide” characters and the like, but it’s still easy to get in trouble. Think of programming patterns as logic created for a specific application, which doesn’t work once you include issues around multiple locales. Programmatic sorting logic is a good example; a typical developer would sort by alphabetical order rather than by character brush stroke. Programming patterns can be a big nasty area to re-engineer, and it takes experienced examination and planning to manage.

 

• Locale Operators - Simply determine how the software will detect what locale it needs to support and how it will behave under the circumstances. For instance, does the user manually choose the locale, or does the application check the operating system setting?

 

• Third Party Product Limitations – Most software makes use of other application components. These can include databases, reporting mechanisms (i.e. Crystal Reports), email generators and more. Often these components have their own internationalization support issues, which can create their own challenges to the software developer.

 

Localizing When the Client Hasn’t Internationalized
Another comment I hear from localization companies is that they have localized applications that weren’t internationalized, even working on translating strings that were buried in the code. I have to say this is a poor practice that should be avoided. I have had software companies come to us quite bitter about localization companies that were just doing what they were told in this regard. Chances are very high the software is going to break. In addition, making the interface translatable is just one part of the internationalization effort. If, by sheer luck, the application still works, they will not be able to leverage the translation when they go to a new version. There is no way this is going to have a happy ending in the long run. One way to help a customer in this situation is to suggest them checking their code, for example by running it through our Globalyzer software. This will give them a very clear inventory of what they need to fix. They can use Globalyzer to save 40% to 60% of time and resources to get the internationalization done, or they can hire us to do it for them.

How can you use all this to make a difference?
When your client says they are not ready for localization, that’s your signal to ask them if they are working on internationalization. If they still say no, find out if they have plans of going global with their software. The earlier they start thinking about internationalization and putting practices in place, the less painful the transition will be. If the client is experienced with localization, ask them if they are interested in learning about products that help them perform and verify internationalization so localization is made easier. You are doing them a service to bring it up and discuss it either way. This discussion can establish you as a strategic partner rather than another tactical translation company. Use internationalization to help you get to know your client’s organization - from Product Manager, to the VP of Development. to the VP of Marketing, to the CEO. Don’t try to talk techie if you’re not qualified. But discussing the concept can lead to opportunities and help you build a strong relationship. When it comes to the technical side, work with an internationalization expert who performs well both technically and professionally. Of course I’d like you to contact Lingoport, as we do a great job of partnering with localization companies, and, just as importantly, we have products and a well developed methodology that make internationalization far more efficient and complete.

Adam Asnes co-founded Lingoport in 2001, recognizing that there weren't good scalable software solutions for the costly delays and development problems companies have with software globalization. Adam recruited an inventive team of internationalization experienced personnel. Lingoport has since attracted globally recognized companies as well as customers embarking on their first globalization efforts - providing a unique combination of internationalization software and services. As Lingoport's President and CEO, Adam focuses on sales, marketing alliances and continuing to gather quality technical team members. Prior to Lingoport, Adam was Director of Business Partnerships at OneRealm, an earlier software globalization firm. Adam also has a successful history leading sales efforts in the scientific data analysis software industry, working on projects ranging from fixing the Hubble Telescope to medical applications. Adam can be reached at aasnes@lingoport.com or 303-444-8020 x2.