February 17, 2009

Save $$ and boost valuations, by getting your software “internationalized”

by Gordon Graham, Editor, SoftwareCEO

Why spend a dime on getting your software ready to localize, when you're not yet selling anywhere else in the world?

Well, because that dime may cost you many dollars later on.

Here are three good reasons why you need to think about this now:

• Not having your code ready to localize can devalue your software firm during an M&A.
• Not getting your code ready can lose you customers... the big, juicy kind of customers with operations around the world.
• The longer you wait, and the bigger your code base gets, the more this will cost you.

These are some key messages from Richard Sikes, a globalization consultant and trainer who's been active in the field for 20 years.

His Toronto-based company, Localization Flow Technologies, has worked with software firms doing everything from "corner office high-level planning through hands-on, in-the-trenches coding."

He's also helping organize the first-ever Worldware conference coming up in Santa Clara, CA on March 17-19.

"This is a new conference that targets financial/ technical/ strategic decision-makers in software development," says Sikes. "The premise is to promote the business case for internationalization, that is, creating localization-ready software."

SoftwareCEO chatted with Sikes about this business case, and why you should be thinking about getting your code ready for the rest of the world.

The three levels of software localization
Let's clarify some terms right at the outset, in the sense that Sikes describes them in a pyramid with three tiers.

Globalization: expanding your marketing strategies to address regional requirements of all kinds. This is the base of the pyramid, which requires a C-level commitment and follow-through.

Internationalization: engineering a product so it can be efficiently adapted to local requirements. This is the middle layer, which takes disciplined software development and testing, so that your code base is suitable for localizing.

Localization: adapting software and accompanying materials to suit various target markets. This is the actual "translation" phase, or what most people mean by "localizing software." This is the top of the pyramid, resting on the other two layers.

And if those two lower layers are shaky, your localization effort will be tougher, more expensive, and more risky.

"Companies frequently underrate the importance of smart planning, drift astray from proven best practices, or fail to understand the chain of dependencies between these three fundamental elements," notes Sikes.

You need to manage all three levels to make sure your software can be delivered to international markets. And being more proactive today can repay you well later on.

And now, nine tips on why and how you should get your software ready for the rest of the world.

Localization tip #1: Think global from day one
When planning a software product, it's best to plan for the future, even if that seems a long way off.

"The biggest how-to is never lose sight of the bigger picture," says Sikes. "You need to check your strategy all the way through, and retain the greatest flexibility for the future.

"The immediate knee-jerk reaction — especially in economic times like this — is to put a curb on all spending, and to view something like internationalization as an expendable feature, as opposed to a core attribute of the product."

But that's not going to gain you any flexibility.

"You want to be like a tennis player waiting for a serve in a crouch, ready to move in any direction. Having your software product internationalized from day one puts you in that adaptive kind of crouch, so when opportunities come up you can go straight to them."

Sikes points out that any successful software will eventually need to be sold overseas. And that goes for SaaS just as well.

"Globalization is a state of mind, and that broad goal really needs to be set at the C level. My view is that there is insufficient visibility for these initiatives at the C level, and there should be more."

If you're not thinking global yet, read on.

Localization tip #2: When you retrofit, you can lose opportunities... and sacrifice your roadmap
Sikes points to a company he knows that makes software for truck fleet management. Its clients, of course, operate across national borders.

"They are courting a very large multinational company, and to win the deal, they have to support several different languages. However, the code base is not prepared... which means they can't go to the prospect and say, 'Yes, we can do it in this finite amount of time.'

"There are unknown issues in the code that prevent them from accurately predicting how long it will take to add this layer of localization on top."

In short, says Sikes, "They don't know what ogres are hidden in the closet."

So this firm is in the awkward position of having to sift through its code base under pressure, and retrofit to support localization. And that means sacrificing the product roadmap to take a shot at this big opportunity.

As a rough rule of thumb, Sikes estimates it takes three to six months to retrofit a code base to support localization.

So if the company gets the deal, it can recover. If not... it winds up many months behind.

Localization tip #3: Get some advice about foreign markets
A good first step, before anything else, is to get some advice about the markets you will most likely look at first.

Sikes suggests you call up someone who specializes in helping business expand into that part of the world, and say something like, "I'm thinking about going to Japan... what are the five most important things I need to know?"

"There are people who can tell you that about Germany or France or wherever you want to go," says Sikes.

Expect to pay for a few hours of time at consultant's rates, like $150 an hour. Then ask about the culture, the business practices, and the expectations for your kind of software in that market.

You can find an export development firm through SoftwareCEO's very own international forum.

Localization tip #4: Get a localization readiness audit
Another sensible step is an audit of your code and your procedures.

"You get an independent third party to come in and do a readiness audit," says Sikes. "They look at all your corporate processes, and go through your code to identify any areas where there are risks."

You'll get a status report including a gap analysis and some sound advice on how to move forward.

Sikes can provide that service, which he says generally takes a few days at consultant's rates. So a typical audit would come in between $5,000 and $10,000.

Localization tip #5: Factor localization-readiness into a firm's valuation
One of Sikes' audit reports recently came in handy for a client.

"A few months later, there was an acquisition in the works, and one of the points on the checklist was localization readiness. The CTO was able to pull out my report and put it on the table, and the acquiring team was very impressed."

This kind of objective report creates value in the eyes of any potential buyer, Sikes says, because it helps to reduce risks.

"Let's assume that I want to add the new company's products to my portfolio, and my standard customers are international. So my customers expect that any new product in my portfolio is also international."

But what if your due diligence uncovers the fact that none of your target company's code is ready to localize?

"All of a sudden you've got many months — likely six months — of delay reaching those markets, so six months of prospective revenue could be lost."

In that case, any buyer will reduce its offer, or perhaps move on to another company that's better prepared.

Localization tip #6: Remove hard-coded cultural assumptions
What does it mean to have your software ready to localize?

One of the first things Sikes and his colleagues look for is cultural assumptions hard-coded into a software product.

"Cultural assumptions are not made by developers out of malice, but through ignorance," he says. "Unfortunately, few computer science departments teach these principles, so one can hardly fault the graduates of those institutions."

Some of these hard-coded assumptions include:

• Fixed-length strings, text boxes, and dialogs; these likely won't hold the text after it's translated.
• Different time notation; where the U.S. uses mm/dd/yyyy, most of the world uses dd/mm/yyyy.
• Different currency notation; where the U.S. uses a decimal point (.) much of the world uses a comma (,).
• The British systems of units; where most of the world uses metric.

There are many more, some very subtle. And they all need to be dealt with.

For example, text boxes and string lengths need to be flexible, with sufficient space to absorb the growth that results from translating English text.

All other culturally dependent items must be configurable through simple menus or widgets. And of course, the most sensible defaults should be pre-set for each version of the software.

If you want some advice, or a hand tracking down all these issues, Lingoport in Boulder, CO is a company focused on helping software firms bring their offerings to other markets.

The company has some interesting articles on its website, including this piece on 10 localization mistakes to avoid.

Localization tip #7: Tell your developers to avoid string concatenation
Here's another example where Sikes feels our educational system fails us.

"One of the big ones that we run into all the time is string concatenation," he says. "In school, programmers are taught that concatenation is very cool."

For example, an error message is put together from a set of string variables, such as:

"The installer found [Eudora] [Lotus Notes] [Microsoft Express] [Microsoft Outlook] [no mail client] on this system."

Sikes say it's tough to get developers to stop using concatenation, because in English it works just fine, and even seems elegant.

But this simple example breaks down in German, where there are different verbs meaning "to find something" and "to determine a state" when you have NO mail client installed.

"So you end up with a linguistic paradox; Whatever verb you use in German is going to be wrong in at least one of those cases. This also happens with articles and with genders," he says.

"Frequently, the phrases that are substituted are scattered through the code and are poorly documented, so the translators are essentially translating blind. This is tragically common, and not taught very often. Most people only learn about this on the job, through a negative experience."

The solution?

Have developers write a complete error message for each case:

"The installer found Eudora on this system."
"The installer found Lotus Notes on this system."
"The installer found Microsoft Express on this system."
"The installer found Microsoft Outlook on this system."
"The installer found no mail client on this system."

Maybe that seems inelegant, but it will save headaches and costs all down the line in other language versions. And that's what internationalization is all about.

"Often the developers in a North American company do not see the interconnections, so they radically underestimate the negative impact of some decision they make," says Sikes.

"As you can imagine, if you're going back through the code to find all those places, you're really looking for needles in haystacks."

Localization tip #8: Separate the presentation layer
Another must-do to support efficient localization is to separate the presentation layer, the UI that users see, from the business logic and database layers of your software.

This is a basic of modern software design.

But even within the presentation layer, it's essential to keep all the textual items organized: buttons, dialogs, error messages, menus, prompts, status codes, and so on.

All these should be collected together in files, or at least coded in a disciplined way so they can all be found and exported with one sweep through the code base.

Then you can simply hand those files to your translators... and save a bundle of time and money.

If these elements are scattered all through the code with no automated way to find them, you're back to that haystack again.

Localization tip #9: Start by training QA
So how do you bring in more awareness of these issues? Train all your developers?

That may not be the best place to start, says Sikes.

"The best thing to do is include internationalization testing as a criterion for release of the core code. You want to get the training in QA to ensure that they know what they need to look for, and have the tools to look for it.

"The developers will get trained by having to go back and fix bugs. There's no point investing in training your developers if there's no control mechanism to evaluate their output."

And of course, no one at all will pay any attention unless they know that the CEO is behind this. So get behind it. Think global, as they say, so you can go local.

About the author: Gordon Graham is an award-winning journalist with 30 years in the software industry. And as That White Paper Guy, he helps B2B software firms tell their stories with persuasive, fact-driven white papers.