Localization Project Management Log

If you live or plan to be near San Mateo next Friday, 27 Apr, make a reservation to attend this year’s Localization Unconference. Our gracious, recurring host Salesforce.com ensures that the free event is a day well spent, out of the office and talking with fellow localizers who slay the same dragons you slay.

I posted on this event a couple of years ago. The industry needs more of these events, so have a look at the post if you want to know more about what’s in store for you.

Attendance is free, but you must register. Hope to see you there.

(Oh, and if you’re driving down from The City, can you swing by the airport and give me a ride? Thanks.)

John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.

Following the trends in mobile app localization? Distimo has your back with a new report,  “Global Differences in App Distribution.”

As reported in Tech Crunch:

According to its findings, globally, 27% of the most popular applications are popular exclusively in one country in Apple’s App Store for iPhone. Meanwhile, Nokia’s Ovi Store has the highest proportion of apps published in just one country (29.4%) while the App Store for iPad has the lowest (3.4%).

They’ve based it on the number of countries in which given apps are available. That’s not as important a statistic to readers here as the number of languages into which given apps have been localized, but it’s some index of global thinking.

Read the entire report in the Publications section of Distimo’s website.

John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.

How could the world have overlooked this for so long?

From The Mobile Indian:

Android currently supports the major European languages and Chinese, but there is no Hindi version of the OS even though it is one of the most popular smartphone operating systems in India…

It is surprising that even though Hindi is the fourth most commonly spoken language in the world, Android or any other major smartphone OS doesn’t have a version of it. Although there are feature phone operating systems in Hindi from both MNCs and Indian brands, the problem is that the letters on the keyboard are usually in English.

Any other important languages getting left behind in the mobile maelstrom? Let me know in the comments.

John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.

Keep your eye on brands from emerging countries.

It won’t be Microsoft, BP, Siemens and Toshiba forever, you know. Eventually, brands from emerging economies will become household names, even in Western households. It happened before with the likes of Datsun, Honda and Saab, and it’s happening now with the likes of China Mobile (wireless carrier), Petrobras (oil and energy) and Baidu (search engine).

Read all about it in “Millward Brown Optimor BrandZ Top100 Most Valuable Global Brands“. Excerpt:

BRIC Makes a Showing
The BRIC (Brazil, Russia, India and China) nations, the four developing economies many experts predict will be the world’s most important in years to come, all had brands on this year’s Top 100. The first Indian brand, bank ICICI, enters the Top 100 at number 45.

This is the first year that all members of the BRIC nations have been represented with entrants from China, Russia and Brazil. These brands include China Mobile (number 8), as well as Chinese oil and gas company PetroChina (number 51) and Chinese search engine Baidu (number 75).

The Chinese brands are joined by two telecommunications brands from Russia, MTS (number 72) and Beeline (number 92), the Brazilian oil and gas company Petrobras (number 73) and the bank Bradesco (number 98).

Watch that space.

What do you know about interpreters? It’s not the same as localization; not even the same as translation.

I’ve had clients ask me to help them source interpreting projects, but it’s a different kettle of koi. Some observations:

1. Unless you’ve got idle resources at your beck and call, this is not something to be cobbled together at 4:30 on the afternoon before you need interpreting.
2. As in translation, there are fields of expertise. An interpreter well versed in legal proceedings may not be the best candidate to interpret technical discussions at a life sciences conference.
3. Interpreters appreciate – and do much better with – any subject materials you can offer, preferably in both source and target languages. Brochures, datasheets, documentation, terminology lists, Web pages and similar publications help set the interpreter’s brain in the direction needed to do the best job.
4. Interpreting is exhausting. (Try it sometime.) These people conk out after 30-45 minutes and need a break. They often travel in pairs for this reason, to spell each other.
5. Simultaneous interpreting is different from sequential interpreting. An example of the former is what goes on at the U.N, usually with headphones and isolation booths. If you don’t have that kind of infrastructure, you’re probably faced with sequential interpreting, in which a bilateral meeting becomes a trilateral one, as the interpreters become a third party to the meeting, slowing things down to interpret everything in both directions.
6. A good translator does not necessarily a good interpreter make. Don’t assume you have the latter because you have the former.
7. Nobody can believe it’s as expensive as it is.

This is pretty old software. We’ve been working on it for over five years, and it’s not very complex to begin with: a few standalone Win32 applications in the normal .exe-calls-resource-DLL model.

Localization practices and internationalization techniques are mostly behind us. Several years ago, at the behest of the vendor, we managed to convince the developers to modify the layout and controls in all of the UI so that no resizing would be necessary from one language to the next. That was the biggest thing to get out of the way, as it ate up precious hours between translation and successful build. The problem has to do with the coming and going of developers who weren’t there a few years ago, and who move things around and resize them in the English UI. Localization headaches ensue.

I’m not sure, but I think the move from Visual Studio 6 to Visual Studio .NET has played a disruptive role. There’s no inherent reason for that architecture change to cause resizing of controls or changes in coordinates, but it is mucking about with other non-translatables, like

1 TEXTINCLUDE DISCARDABLE

changing to

1 TEXTINCLUDE

or

STYLE DS_MODALFRAME | WS_POPUP |

changing to

STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP

There’s certainly nothing to translate here, but these count as changes in the source-language files that should be preserved in the target-language files. It’s hard to do this sort of thing without some kind of Computer-Aided Translation (CAT) tool or at least text-manipulation utility.

So, I reckon we hand it off for localization engineering, if not translation. The engineers will jack up the translation, slide out the old architecture as if it were HTML or XML tags, slide in the new architecture, and push the translated strings back down into place.

What keeps me up at night? Nothing related to localization, although Client A’s API reference often makes me wake up earlier than I’d like.

In five years we’ve come a long way in localizing it.

• Back when it was only a few hundred pages, Tech Pubs maintained it in FrameMaker and published it as a PDF. Localization was a headache because Acrobat played up with some of the characters in Chinese.
  
• It got too fat for that, so they dumped the PDF and went from FrameMaker to HTML to CHM using WebWorks. WebWorks was a localization nightmare, so I was glad when they outgrew that.
• Then they authored in RoboHelp and went straight into HTML/CHM. That was a little better, but Asian support in later versions of RoboHelp was elusive or costly or both.
• Now Tech Pubs doesn’t do any writing in the API Ref. They maintain about a dozen Perl scripts for extracting HTML files (over 3000 now) from text-based header files, then compiling a CHM.

No matter how they cut it, it’s a lot of work when it comes time to localize the puppy. I look for ways to streamline the process, but they all end up in the tail wagging the dog, because L10n is so far downstream and at the sorry end of the food chain. Besides, most any improvement would require endless, largely fruitless nagging of a platoon of engineers, all to save a few thousand dollars a year.

There’s ROI to localization, but not necessarily to every facet of localization.