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?

A localization lesson from North Korea

You never know how your next lesson in localization will reach you. What if you were to learn something from a digital trailblazer like North Korea?

The International Herald Tribune reports that North Korea is offering overseas shoppers the chance to buy hundreds of its goods through the Internet. Offered items include boxing gloves, bicycles, commemorative stamps, roller skates and uniforms for Taekwondo. While the site is obliging enough to accept credit cards, it has not yet reached the level of capitalistic level of revealing prices.

But the most forward-thinking aspect of the site is that, right out of the gate, it is localized into Korean, English, Chinese, Russian and Japanese. How many of us are that enterprising and globally inclined? Show this post to your boss and say, "See? Even lowly North Korea can develop and implement a localization strategy. Why can't we?"

The hitch: The site has been live since 31 Dec 07, but it spends a lot of time off line. Try your luck: www.dprk-economy.com/en/Shop/index.php

Amtrak.com in deutscher Sprache!

This is probably more in the domain of John Yunker, whose Global by Design site focuses on American companies coming out of their americocentric stupor, but I'll mention that Amtrak's site has been localized into Spanish and German.

This is a hot one. Passenger train travel is not exactly all the rage. The network is not expanding noticeably, and even after Antarctica melts, Americans still aren't going to get out of their cars and take a train, except to amuse their children. Why throw marketing dollars at a localized Web site?

Why Spanish? Because hundreds of thousands of Hispanic Americans need to move from city to city, and if they're going to take the train, it's easier for them to research routes and schedules in their own language. On the other hand, the railroads in Mexico, in particular, are a popular joke, and buses long ago displaced trains as the default means of intercity passenger transportation. So it seems that Amtrak sees the demographic potential, but may have some cultural baggage to overcome in attracting this new ridership, not to mention the issue of whether their sector of the Hispanic market uses the Web (yet).

Why German? Because Germans (and Austrians and Swiss) believe in the trains, I suppose. This is even more intriguing than the Spanish site, because it required more research than simply picking up the newspaper and reading that Hispanic buying power in the U.S. will have risen 347% to almost $1 trillion from 1990 to 2009 ("The Multicultural Economy, 1990-2009", from the Selig Center for Economic Growth). The move to German must have involved polling actual passengers and getting hip to the fact that these people not only think in terms of train travel, but also use the Web to research it.

Both Spanish and German sites are more than mere afterthoughts; they seem to be comprehensively translated, several levels deep. Notes:

• They even translated "California" as "Kalifornien" in the state drop-down menus, no doubt as a nod to the governor.
• Don't use accented characters when you enter your name on the Spanish site. The error message telling you what you did wrong and how to rectify it is still in English.
• I don't know which credit card the Spanish- and German-speaking travelers are likely to use, but the only choices are Visa, MasterCard, AmEx, Diners and Discover. No debit cards, no PayPal.
  

Sometimes the mechanics of a localization project are less compelling than the story behind it. If you know the story behind the Amtrak localizations - or an offbeat story behind a project you've done - please post it here.

(Blogger's note: Travel between San Diego and Los Angeles by car has lost all of its allure, and I opt for Amtrak whenever I can. I have had multiple pleasant conversations in Spanish with people on this train route, usually people from Mexico visiting family in Southern California.)

Localization Testbenches, Part III (Web sites)

What are you using to test your localized products? If you're handing them to your domestic QA team and expecting that they'll intuitively test them with correct language locale settings, you may be in for an unpleasant surprise.

2) Web sites
Performing QA on localized Web sites requires less overhead. Most browsers nowadays accommodate multi-byte characters automatically and without installing language packs. So, if you send e-mail pointing your executive staff to your newly unveiled Chinese site, you can be sure that most of them will see a page free of corrupted characters.

Dumb HTML pages, however, are not where the biggest problems lie. You need to ensure that your forms, auto-responders, search pages, search result pages, search indexing and databases all support the target languages.

This can in fact be more complex than localizing software; while localizing software requires plugging a lot of holes, they're all your holes. Localizing an entire Web presence and user experience can require plugging holes among different products and platforms: Web server, Web application, database, reporting utility, e-mail software, shopping cart. To do right by the visitors to your Web site, you need to test everything all along this click-path.

It's rare that you will need to build a new app server based on the Hebrew versions of Linux, Apache, etc. to support these languages and users. But if characters and messages are not surviving all the way through your e-path, you may need to enable the support in several places, order some language packs and research the locale's computing needs. This is hard to do on a testbench in a lab, so you may end up testing your own international-stage instances on production servers throughout the organization.