Localization is Like a RipStik

 

I'm on vacation this week in Santa Rosa (Northern California), and I've dared myself to get acquainted with my nephew's RipStik.

Naturally, since I needed a pretext to post to this blog in the middle of my vacation, the RipStik reminded me of localization. Specifically, simultaneous shipment (simship) localization, in which a company releases the same product in multiple languages "simultaneously," a term that is, fortunately, loaded with shades of meaning and exactitude.

It Works, But It Looks As Though It Shouldn't

The RipStik has only two wheels. Both are 360-degree casters, slightly pitched. Once your feet are on the decks and you give yourself a small push, you move your legs - particularly the back leg, according to my nephew - to propel yourself. Having done this for only a single day now, I have no idea how I keep my balance, but I assume that it has something to do with divine intervention.

Simship shouldn't work, either, should it? You're artificially constraining something (usually the source-language product) and propelling something else (the target-language products). Yet once you're underway, management will wonder at how natural the process seems.

Don't Do It If You're In a Hurry to Get Somewhere

Yesterday I sweated and gasped for half an hour to get about 50m and back. This morning I resolved to get to the end of the street and back, which also took a half-hour. I probably couldn't get to the corner and back on a RipStik if I really needed to get to the corner.

Don't bet the quarter's international revenue on your first simship attempt unless upper management has agreed to flog anybody in the company necessary to meet the goal. You'll need a few release cycles to build up to this.

It Helps to Have a Buddy
In the RipStik How-to-Ride video, the narrator recommends having a friend help you steady yourself when first you mount. This I would gladly have done, but my sons and nephews were too busy laughing at how ridiculous I looked to stop and help me.

Talk to localization professionals in other companies about their experience in simship. If you don't know any, find some on LinkedIn, or lob a question about simship into Multilingual Communications (see "Blogos" link to the right). Don't rely on your vendor for this; they're in the back seat and you're the one behind the wheel.

You Won't Truly Know Whether Your Organization Is Up To It Until You Commit
I have no idea what possessed me to ask my nephew whether I could try his RipStik, but as I stood over it wondering how to operate it, I realized it wasn't going to reveal its secrets until I'd made the first move...and the second and the third and so on.

You may be able to gauge your company's commitment to simship by asking people, but you don't know whether the process is truly possible until you've been through it. You, as localization manager, will of course shoulder most of the burden, but there are plenty of things you'll need from other people, and only by doing it can you see how close to or far from the goal you've landed.

Quantify Your Goals
I challenged myself to get to the corner and back on the RipStik, but I forgot to specify the amount of time I was willing to spend on it. Not much of a goal.

When you launch the project, specify "simultaneous:" source plus 15 days, source plus 30 days, same day for source plus two languages then 30 days for the remaining languages, etc. It makes success appear more probable to all of the other players whose support you'll need.


So, hop onto your RipStik and give simship a try, but keep in mind one important dissimilarity between these two endeavors: I've realized that, like many activities that involve balance, it's best if you keep your head up and focus on your progress, but not on how you're making your progress. In simship, that's a luxury reserved for upper management. You need to keep tabs on everything all the time.

Four Localization Answers, Just In Case They Ask

Sooner or later, someone may ask you, "We've got a new release coming up. Why don't you give us a presentation on what you'll need to localize it properly?"

After you've recovered from the shock, will you have a ready answer?

I received this request last week from one client, and turned it into an invitation to present at the regular meeting for all of the leads - software, Web, documentation, project management, QA, release - and some people in upper management. It's meant to be a very brief (10-15 minutes) presentation, which felt like a limitation at first, but which now strikes me as an advantage because it will help me focus better.

They've stapled me to a slide presentation, and I made the most of it.

• Slide 1: Hello! I'm the Localization Guy and I live to pester people. (Maybe I don't say it in quite that manner...)
• Slide 2: Scope of Work - These are the software, Web and documentation bits we'll need to localize, and the parts that are already in TM.
• Slide 3: Timing of Work - Let's hand off anything we can as soon as it's stable, even if the localized releases aren't for several months yet.
• Slide 4: Help Wanted - Here are areas of the project outside of my control, where a little localization-mindfulness will save some time, money and headaches. This includes tagging XML files for text that should not be translated, handing me early software builds for internationalization testing, and thinking about the stable files we can hand off ahead of product release.
  

I think this will suit their desire for information. They don't want to know the details of how I do what I do, but I want them to know what I need from them.

You too should have a presentation like this in your desk drawer or on your hard drive. Just in case they ask.

ISDN (I still don't know) about Localization

"There are still a zillion people who don't know about localization," the sales representative of the localization company told me. "Can you believe it? After all these years?"

Yes, I suppose I can. We can make sales calls and deliver presentations on the most efficient ways to localize until we're all ready to retire, and there will still be executives, companies and entire industries that haven't gotten the memo.

It's refreshing in some ways, and it keeps us from getting lazy. It reminds me of the ISDN craze around Internet access back in the mid-1990's, before cable and DSL made our choices simple (at least in the USA).

ISDN, or Integrated Services Digital Network, was a high-speed alternative to dial-up, but the phone companies were not very successful in taking the service from the early adopters to the early majority. The acronym became redefined as "I still don't know," because most people couldn't understand the service well enough (or afford it, for that matter) to see how it would benefit them.

The upside: There are still, and will be for a long time, opportunities to sell translation and localization services. As soon as all of our customers know about localizing products and how to do it efficiently, they'll turn to The Next Thing, such as John Yunker's Web Globalization Report Card threshold of localizing the Web site into 20 languages. We won't run out of work, provided we stay a few steps ahead of our customers' requests.

The downside: We may spend a little less time educating new clients, but we're not completely out of the hand-holding business yet. Salespeople will still need to update their presentations and drag an engineer or project manager to that second-round meeting with the prospective client.

Just be sure to stay on top of localization developments and techniques so that you don't have to answer a prospect's question with "ISDN" (I still don't know).

I Don't Want to Localize That, And You Can't Make Me

Ever hear your children make similar utterances, except with different predicates ("go to bed," "clean my room," "do my chores")?

One of our clients is staffed with people too polite to say things quite so bluntly (but not too polite to dig in their heels similarly). The upside is that I enjoy working with almost everybody I've ever encountered there; the downside is that there are some places where their global-readiness is stuck.

Web presence
I bend over backwards to uphold a simple rule of Web navigation: Localize everything along the click-path to a visitor's goal. So, if a visitor starts on a Russian home page, and decides she wants to download a Russian version of the trial product, I believe in ensuring that she doesn't have to put up with English on her way through the site, unless she wants to do so. Or, if we need to push her to an English page, I try to make it apparent with "English only" next to the link.

We've made a lot of progress in combing out the remnants of English that dot many localized sites (that makes my skin crawl - how about you?), so that each page is linguistically pure to several levels. That was expensive and it took a lot of time.

The problem now is that this client's site relies on a lot of plumbing for verifying that the visitor is not from an axis-of-evil country, or hacking the site, or trying to perform unsupported operations, and the UI for all of this infrastructure is in English. Much of it is just background code, but several pages (login, registration) are in English, and the infrastructure team is not interested in localizing any of it, despite my polite persistence.

License agreement
This is a hot one. When you download trial software from Germany or Finland, do you click "I accept" to a license agreement in that language? Granted, German and Finnish are not the lingua franca that English is, but how much more does it say about the relationship you want to have with your customers when you make some effort to inform them of your business terms in their language?

"We don't translate anything legal, and it's not hurting sales," I keep hearing. This is a battle I know I'll never win, so I look for victories elsewhere.

Site logic
There was a sudden need some months ago to place a terms and conditions page in the click-path to a particular download. Naturally, the terms and conditions were in English only, and I could have lived with that. The problem is that the code behind the page sent the visitor to a particular next page, without regard for where the visitor was going when he landed on the terms and conditions page.

So, visitors on the way to download the Korean/Japanese/Chinese/Spanish... version of the product sailed along the click-path in their own language until reaching the terms and conditions page. Then they agreed to text they almost certainly did not read, then they landed on a completely irrelevant page of English, with no reasonable way of getting back to their intended destination.

This is related to the inflexible plumbing I mentioned above. It's great infrastructure; it's just monolingual and it doesn't really need to be.


Anyway, these bits of stubbornness amount to a small downside in a client that is not stingy about localization in general and that has a strong global presence. They're correct when they say, "I don't want to localize that, and you can't make me," so it's easier to roll with the punches and enjoy other victories.

Besides, if I'm around long enough, they'll move on and I can take the matter up with their successors.

What things have people told you they're not going to localize, and you can't make them?

Localizing multimedia (Flash, QuickTime) - Part 2

Part 1 described the background education many companies (especially upper management) require when they want to have their multimedia files localized. This part describes what you, as localization project manager, need to know. This information is important for you to request and deliver the right things, but it's not very likely that upper management will be interested in it.

Assume content like a 60-second product introduction, with actors speaking on screen and graphical text in need of translation and layout.

1. As usual, you should plan for a glossary or terminology list. It's always important to ensure you use a properly current term for "pain relief" or "outfielder's glove," but the cost of opening up an already localized complete project to tweak a couple of words - particularly spoken words - can be prohibitive. If your in-country partner has approved of your terminology ahead of time, you'll save yourself headaches in the long run.
2. Pare down your cast for the localized version. If your commercial includes one female and two male actors, do you really want to pay voiceover fees for all three of them? Consider using the same voice for both males, and subtitling the female. When your budget gets bigger, you can spring for all three linguists.
3. Files are huge, so don't count on moving them over the Internet. You'll want the translation studio to work as far upstream as possible, so plan to give them the original video footage, not a compressed QuickTime or Shockwave Flash (.swf) file. These can be several GB in size for only a few minutes of video, so plan on moving DVDs or thumbdrives.
4. If the commercial was created as a digital studio file (e.g., Final Cut Pro), hand off the entire project, just as you would hand off all the surrounding files needed for a software localization project. This enables the localizers to open graphics, replace text and drop in the voiceover, then output localized versions on par in quality with the source version.
5. Studio time is not very flexible. Even though your movie has only 60 seconds of voiceover, you may need to book half- or even full-day linguistic talent in multiple languages. This can be a rude surprise when it seems to you that the original voice talent was nearly free (or so you thought). And, as stated above, opening and closing these projects to make apparently minor changes can run into major money for engineering time.
   

Clients are not always specific about the output and deliverable formats they want for these localized assets, so it may take a while to find somebody who will give you more details beyond, "We need the video in Japanese, and quickly." Part 3 will cover that.

Making Sense out of Outsourcing Localization to China - Part 2/2

[Continuation of last week's post, Part 1]

Since it was my charter to make this offshored localization project work, we built checkpoints into the project to detect problems as soon as they arose.

We scheduled bite-sized chunks of translation, engineering, layout and editing work early in the project, then handed them off for review in our client’s in-country offices. We established twice-per-week conference calls with the vendor’s team to reinforce the decisions we made in e-mail threads. To overcome low TM matches and shorten the project schedule, we sent source and target files from previous projects for realignment in TM. We agreed mutually on a format for weekly reports that would highlight project status without becoming onerous. In short, we followed every prescription for a successful localization project, and we followed them more carefully than normal.

Our client’s Korean office has expressed satisfaction with the final product. The decision-makers, pleased that nothing went awry – at least, nothing that required their intervention or remorse – asked for a post-partum on the project, in which I underscored these points:

· It was a pleasure dealing with the vendor. They were prompt, courteous, efficient and unequivocally determined to making us happy.

· Even with the short time allowed for the project, they brought to our attention errors in the source materials and they addressed what they considered pre-existing translation issues.

· Their end of the conference calls was noisy to the point of distracting. Several of them in a meeting room with poor acoustics talking into a cheap speakerphone made for frustrating encounters twice a week, regardless of whose bridge we used. The project succeeded in spite of it, but it struck me as a poor choice of places to save money.

· It became apparent that they were cutting corners in ways that experienced LSPs don’t bother trying to cut them (rogue copy of TM software; use of a shareware help compiler on a project that depended on features unique to RoboHelp; testing on Windows MUI instead of native localized OS). I can overlook some things like this, but I’d rather not have to.

Our client had already localized this product into Korean over several versions for a number of years, qualifying it as a sustaining effort. Vendors in China and India have done a brisk business in sustaining engineering, especially for large IT companies with legacy code bases. Naturally, they are turning the corner towards new product engineering, which, like localizing a product for the first time, demands more of the relationship between client and vendor.

Recommendation: If your team is sufficiently aware of what it takes to localize your product, and has a history of successful localization, then testing the waters with a Chinese or Indian vendor in 2008 should be among your options. If your organization is new to localization or must entrust the process to someone who is, this might prove rash. In no event, however, should you simply find the lowest price, lob your product over the partition and hope for the best.

If you enjoyed this post, please read the related article, "Offshoring and localization projects, Part I."

Making Sense out of Outsourcing Localization to China - Part 1

If you have not yet tested the waters of offshore LSPs, consider making 2008 the year in which you take the plunge. You know you are going to do it sooner or later, and if you don’t, your successor will, so you may as well learn the lesson for yourself.

In 2007, one of our clients embarked on a localization project with a Chinese vendor. This brought me, in my role as consulting localization project manager on the client’s side, onto the leading edge of the project. Misgivings? Yes, I had a few:

· The company had no visible qualifications as a localization vendor, though they had devoted lots of Web space and marketing to testing, data analysis, application development, sustaining engineering, payroll processing, helpdesk and data mining. How can you be very good at anything when you specialize in everything?

· Against the same request for proposal, the company’s bid on the project was about 25% lower than that of two other Western LSPs. It didn’t help that they misread the RFP and omitted a big chunk of work, but even if they’d included it, they would still have been 15-20% below the other vendors. What kind of quality would we get for a price that low?

· The target language was Korean, not Chinese, which meant that, as low a price per word as they were offering me, some vendor in Korea was almost certainly offering them an even lower one. What caliber of linguistic talent could we expect?

· Our client imposed a project deadline bordering on the preposterous, which annihilated precious time I wanted the vendor to devote to editing and QA. Midway through the project the deadline changed to allow some more time, but it had already introduced a great deal of stress.

· The lingua franca of the project was English (because I don’t speak Chinese). While the vendor’s efforts were valiant, their English was weak, and I foresaw this as a problem even before we had awarded the project.

· Replete as the Western news media were in 2007 with recalls on Chinese toothpaste, toys, cots, tires, medicine, pet food and other products, it was easy to tar this company/industry with the same brush and worry about their level of quality assurance.

Despite these carefully articulated misgivings, our client’s decision-makers had already made up their mind (and corporate direction) to award the project to the Chinese vendor. So, since it was my charter to make it work, we built checkpoints into the project to detect problems as soon as they arose.

I'll describe these checkpoints and the upshot of the project in next week's post.

If you enjoyed this post, please read the related article, "Offshoring and localization projects, Part I."

Localization - Investment or Expense?

Would you rather expend or invest? Would your company rather expend or invest?

You walk into a pastry shop, buy a slice of cake and eat it. That's an expense because it doesn't last long and you can't use it to make anything else. You walk into a bank, buy a certificate of deposit and reap interest a few months later. That's an investment because it has some durability and you use it to make something else (more money).

A new client is testing the waters in Europe and Japan. To appear serious to prospects there, they asked me for a proposal on some multimedia projects they've hosted from their Web site. It took lots of phone calls and e-mail to ascertain exactly what they expected back, then lots of phone calls and e-mail to ensure that they had sent us everything we needed to estimate costs for a full, end-to-end solution.

They're a small company with solid domestic revenues and negligible overseas sales to date, so they felt sticker shock at the $3-4000 per language that this was going to cost. One of their executives tried to think nimbly: "See whether they can just do the voiceovers and give them to us. We can have our in-house editors replace that layer in the media files."

I don't mind nimble thinking, and I appreciate her attempts to save money, so I won't go into the many technical and quality-related concerns that this approach violates, but when I sent an adjusted quote, I wrote, "I understand that you had $1500/language in mind, but the original English media probably cost a good deal more than that, and you've likely forgotten what you spent on them because of how many prospects have clicked on them. I encourage my first-time clients to regard this is an investment, not an expense. If you choose your overseas markets and partners carefully, and handle translation and localization correctly from the start, your ROI will not be long in coming."

Do you agree? Have you spent time trying to convince your company's executives that good localization practices are an investment, not an expense? What's your favorite argument?

If you enjoyed this article, you may enjoy another one called "Why Localize at All?"

"Why are you charging me for that?" - Part 2

Do you have manuals, resource files, help projects or entire Web sites that you've been localizing for several years and through several versions? Have you thought about the "permafrost" in those files; i.e., the sentences, paragraphs, pages and chapters that haven't changed in ages?

Are you being charged for them in your localization efforts?

In my experience, vendor pricing includes discounts for segments (usually entire sentences or bits of text surrounded by paragraph markers) with high match rates to text that has already been translated. So, a new 30-word sentence at $.25/word may cost $7.50, but a 30-word sentence that does not change at all from one version to the next may cost $.03/word, or $.75.

But why are you charging me for that?

Vendors have different rationales (and they are welcome to post them here) which often boil down to the necessity to "touch" the words in one way or the other: either in engineering unchanged paragraphs into the new manual, or in translation memory maintenance, or in the human editing pass when eyes land upon them. These words are the spare tire of localization, in that they haven't changed, but they're still along for the ride, and moving their weight requires some modicum of additional gasoline.

As a localization manager, try explaining that to your boss.

So, if I don't want them to charge me for the words, or for any words that don't require translation, what should I do?

• Perform your own triage. Pull out code samples, for instance, which will never need to be translated, and hand them to your vendor in a text file. Ask that they be aligned to themselves in TM so that the words fall out as 100% matched. The translators won't touch them and you won't (shouldn't) be charged for them.
  
• Move to a CMS. Deploying a content management system is a long-haul solution; but if this is a long-haul problem for you, look into it. With a CMS in place and an interface between your vendor and the system, it becomes easier for you and your vendor to separate matched from non-matched segments. That which is easier, should cost less.
• Give instructions, not words. If you suspect that there have been only a few changes to a 40-page manual, use a diffing tool to find them, write up the changes, and hand them off to the vendor with instructions to charge you hourly for the spot-changes. If the vendor knows exactly what to change where, it eliminates the guess work, the TM analysis, the file preparation and the engineering. This lowers your costs of localizing the book.

You should be able to have a calm discussion with your vendor about these jillions of unchanging words, and arrive at one or more methods for eliminating unnecessary work. Try to go beyond "Why are you charging me for that?" to "What can we do so that you don't have to charge me for that?"

Interested in this topic? You might enjoy another article I've written called "Why are you charging me for that? - Part 1"

Stages in your company's localization-life

"So, where are we on this localization-thingee?"

Do you get questions like that from upper management? The question demonstrates complete cluelessness about the work involved in creating international versions of your company's products. Secretly, of course, you're gratified that it's on upper management's radar.

Here are typical steps in a company's localization-evolution:

1. No Clue - These companies find out the hard way, often by ignoring in-country requests, bulldozing the project through Engineering, shipping poorly localized product, and not figuring out in advance how to support it. The biggest shame here is the lost opportunity to get Engineering on board properly from the start; unfortunately, localization is going to interest engineers only once - the first time - so missing this chance is costly in the long run.
   
2. Some Clue - Companies with Some Clue designate a localization manager to act as champion (or at least as lightning rod) of the process. A wise investment at this level is in somebody who does in fact know something about localization (or global requirements and differences, anyway); such a person will help the company avoid most of the in-country problems faced by No-Clue companies.
   
3. More Clue - In time, the localization champion evangelizes internationalization/localization thinking to others in the company. People reflexively contact him/her whenever the word "international" is uttered because they correctly perceive that person as the hub in the international-product wheel.
   
4. Advanced Clue - This is the Great Engineering Leap. Along with all of the other fires that Engineering and QA put out, they now know it to be a priority to design their products and processes from the ground up for worldwide versions.
   
5. Total Clue - A company with Total Clue ships multiple languages simultaneously, has happy overseas offices and customers, and probably derives much of its profit from overseas sales. Things do not run on auto-pilot by any means, and the localization team must still crack the whip and pester people, but the entire organization lives with the charter of seeing beyond the home country's borders: the corporate version of the State Department.
   

It's common, by the way, for Sales and Marketing to drive this evolution, since they're closest to the pain caused by not evolving.

So, tell me: Where is your company on the localization-thingee, where does it want to be, and what do you have to do to help take it there?

Interested in this topic? You might enjoy another article I've written called "Whaddya know? They asked me first this time!"

Acceptance criteria for Localization

Have you ever gone to the extent of developing acceptance criteria for a localization vendor's deliverables? Beyond that, have you ever sent a vendor an acceptance letter summarizing these criteria, and grading the vendor on each point?

After years of my simple handshake-and-phone-call approach to acceptance, one of my enterprise clients asked me to develop and communicate these criteria formally. It didn't require too much effort, since I knew what I had liked and disliked about the vendor's performance all along. Here are the points I drafted:

PERFORMANCE

• Responsiveness: You attended all conference calls and apprised me in a timely manner if you were unable to attend. You responded to e-mail very quickly.
• Delays, schedule: You reported only a couple of delays on the project, none of which was more than two workdays in length. In the main, you maintained your schedule day to day and week to week.
• Weekly reports: Your weekly reports were punctual and informative. They helped me to communicate accurately the status of the project to other members of the team at BigCorp.
• Issues, questions: Your process for moving the translators' questions and my answers back and forth was simple but adequate.

TRANSLATION

• Quality: Preliminary reports show that our customers were satisfied by the translation work.
• Bug fixes: You incorporated feedback from the reviewers and me as we requested.

DELIVERABLES

• On-time delivery: You delivered all files to us in a timely manner. You delivered the final files 2-4 calendar days ahead of the final deadline.
• Project files: After giving us the main deliverables on time, you performed housekeeping on the supporting files and delivered them to us.

Frankly, I left out a few things, like the fact that conference calls were arduous because of their phone system, and the rather attention-getting directory that appeared on our FTP site one morning labeled "Trados_crack". But the point of the message is to convey acceptance, and it serves that purpose well.

Did I leave anything out? Let me know.

Right hand and left hand in localization

When was the last time upper management was more enthusiastic about localization than you were ready for? Would you like to have that problem? Are you sure?

A colleague at a very large IT company wrote me that he started as localization manager four months ago, with the direction-from-above of taking his division's products into 5-7 languages this year and twice as many in the next couple of years. Who wouldn't want a charter like that? Most of us would sell our souls to Voldemort for it.

He's discovering to his dismay that most of the software hasn't been internationalized - lots of UI still embedded in code - which will drag out the timeline quite a bit. Instead of managing localization process, he'll spend the foreseeable future managing architecture, internationalization and product. He was ready to jump on the localization horse and ride it into the sunset, but is now finding out that the horse hasn't been born yet. It's parents have barely met, for that matter.

That's the result of the right hand not knowing what the left hand is doing: the right hand promises, and the left hand has to deliver. It's not uncommon in most organizations, but in this case it's overseas offices and customers who will suffer, as if they weren't already marginalized enough.

My colleague laments, "This isn't the 9-to-5 job I was expecting."

As if.

Localization Management: One Big Bag, or Several Smaller Ones?

Are you getting to the point where you need to consider decentralizing your localization project management efforts? That decision point usually comes with growth (more languages, more products, shorter lag-times). Here are some things to consider in distributed vs. centralized localization management models:

• Trying to plant and cultivate this expertise in each group (QA, product teams, release engineering, sustaining engineering) is pretty tough. One prospect appeared to manage things in a decentralized manner like this, telling me that "the car drives itself," but I have my doubts. I've never seen any organization that did it well and robustly without a lightning rod or "localization czar" that ran around pestering people company-wide.
• Frankly, I think decentralization is difficult because, for all but the largest, best funded firms, it's just plain hard to find and keep that many individuals interested in driving international products. I suppose it could be built into the company's incentive structure, so that managers understood it was part of their charter to localize, but that wouldn't guarantee that they would actually care about it, and caring is at the heart of long-term localization management.
• Until somebody really cares about it, most internationalization/localization projects have an out-of-band feel to them. It takes a long time before they feel familiar, and the sooner everybody knows that there's somebody (besides them) responsible for putting out the Japanese version of the product or Web site, the sooner everybody can get back to work.

For these reasons - and a few others - I counsel companies to dedicate a single project manager , preferably with domain expertise, to as many localization projects as practical, rather than to expect each project manager to handle the localization aspects of his/her own projects.

That model will last a good while in most companies.

Why Localize At All?

This question seems more dangerous than it really is.

You should be asking it at the beginning of your localization lifecycle, because you need to convince yourself and others in the organization that the effort will pay off, or at least that the gamble is worth it. The decision to go global ripples to every department in the company, and some companies in certain vulnerable points in their life are not ready for it.

But you'll transform the question from, "We shouldn't localize at all," to "We shouldn't localize right now." So you engage in healthy waiting.

Later in life, after a few rounds of localization, somebody will pose the question again. "The extra revenue isn't worth it. We're spreading ourselves too thin. Why localize at all?" This too is healthy questioning. (There's usually a "Why don't they all just learn English?" from somebody on executive staff. It's best to just smile and steer the conversation away from such ratholes of hopeless ethnocentrism.)

At this point in company history, you'll likely rephrase the question to "Are we really localizing as smart as we could be? How can we do it more efficiently and only for the most profitable regions?" You'll introduce more efficiency and raise the profile of localization.

Go ahead and keep asking "Why localize at all?" It's good for you and for your organization. Start worrying when nobody poses the question any more.