"I certainly get tired of localization."

Have you said this lately? Have you thought it lately? Do you wish you'd joined the Rolling Stones when they invited you?

What do you plan to do after localization? What will you do next in your career?

Look at the localization people around you. How did they get into this business? How has their job changed since they did what you're now doing? At least two prominent figures in our industry started out as professionals (attorney and tax consultant), then started small translation companies that grew very large. Neither of them translates anything or manages projects anymore, but both have used the industry as a springboard to broader career paths.

On the vendor-side, translators become project managers, who become leads, who become salespeople, who ultimately run the company, or start their own. On the client-side, localization managers become product managers, who become directors of product marketing. On either side, your company could easily be purchased and you might have to start over from scratch. Will you be ready?

I've visited high school and college classes to describe to language students how they can use their talents to enter several industries, including translation/localization. It hasn't occurred to me to address the question, "After that, what?"

Of course, you don't need to wait until you've grown tired of localization to start planning your own outplay. If you don't have another marketable talent in your back pocket right now, then you must not be reading the newspapers. Years ago I had a very discerning boss who asked me in confidence, "In how many completely different ways can you earn a living? You should always be accumulating multiple talents you could apply to make money, if you had to."

So, during the day you're a localization manager, and at night you offer bookkeeping services to small businesses. Or, Monday through Friday you run translation projects, and on Saturdays you do search engine optimization for friends' Web sites.

Yes, it's more work, but when the localization train reaches the last station and you get off (or are pushed off), you'll have more options in picking the train to board next.

Giant Localization Leap Backwards

"All of the strings are embedded in the code."

There was a time when I welcomed - or at least was not very much surprised by - sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.

So, when one of my client's engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.

But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don't usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won't go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.

"Is there a phased approach we could take to enabling this app for localization?" the engineer asked.

I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.

This is disappointing, because we've made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I'll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.

Isn't that why we localization project managers and international product managers were sent here?

What do you do in your company when engineers tell you that all the strings are embedded in the code?

User Interface and localization

"We are Marketing. We own the user interface."

An engineer with one of my clients told me, with some bitterness, that a previous regime had summarized its hegemony over the company's software product with those two sentences. I'll grant you that it sometimes help in a company to know which lines are not to be stepped over, but I'll also grant you that you catch more flies with honey than with vinegar.

Most of us don't mind if Marketing dictates the user interface, unless people with our global perspective tell them that something in the UI won't work well when the product is localized and they refuse to accept it.

In this case, the fuss is over an HTML-based UI and help system that lives in firmware in a networking device. The old Marketing guard wanted a tabbed look with labels on the tabs (Connections, Security, Setup, Help, etc.), and the tabs had to be graphics. The graphics are .gifs, nobody knows where the source files are, and we're trying to find an expeditious way to localize the product, including the text on those tabs. (If you're in localization and haven't already faced this situation, I can assure you that you don't have long to wait.)

I've floated some ideas by them that might result in a more flexible approach for future versions of the product. The current Marketing team is not so doctrinaire as their predecessors, but they're not very engaged in this process, either. I offered Ockham's razor: Let's remove the tabs and replace them with hyperlinked text near the top of the page, and the problem will go away. They have yet to reply to that.

I'll give them another week, then make my own arrangements. After all, "We are Localization. We own the rest of the world."

Localization Conundrum

My client received a request from Korea for a localized version 6.5. There are two issues:

1. It's going to cost a lot, because the last version localized into Ko was version 5.01.
2. English is up to version 8, and the process of creating the help is much better than in 6.5 . Should we include those enhancements to 6.5 Ko, even though they would take it out of parity with 6.5 En?

I experimented to see whether the improvements mattered to the localization process in general and the cost in particular. I re-created portions of version 5.01 help using version 5.01 Perl scripts, then did portions of that same help using version 6.5 Perl scripts. Then I handed both sets off for wordcount analysis. They were within 2-3% of each other, so the cost-savings in translation are not there.

However, I suspected that the vendor would charge me a lot more for engineering on the 5.01 help, because the version 6.5 scripts are much cleaner, and they handle the raw text much better. This compelled me to examine the matter further.

Better help or not, the problem is one of product management. Even if 6.5 help is "better," it differs too much from 5.01 help. I imagine a Korean customer struggling to bounce back and forth between 5.01 En and Ko, and puzzling at the discrepancies, even though the Ko version had a lot more information than the En version.

They are the sort of discrepancies that make cowards of us all (albeit well advised cowards). I've decided to hand off the pure 5.01 En help system for this project, warts and all.

The Localization Manager's Team - If You're Lucky

How many of you out there in L10n-Blog land get support from other internal groups?

A long time ago my boss told me why it's important to be a complete zealot about localization, especially in an organization that is new to the process.

"For people in general and engineers in particular," he observed, "localization is interesting only once: The first time. After that, they're just humoring you."

I've kept that in mind as I take off like a street fighter with most clients, eager to ride the wave of novelty that accompanies the prospect of going global. Product managers brief me up one side and down the other, in-country partners promise to devote legions of in-house staff to testing the product the minute it's ready, and QA resources jump at the chance to configure localized test benches.

At the water-cooler level, employees want to connect me with their cousins who are studying French and would love to proofread the manuals, or with their former co-workers in Japan who would make excellent beta testers. Naturally, I diplomatically avoid these golden opportunities, but I appreciate how high spirits can run at the outset.

In time, though, product managers stop returning phone calls, in-country partners run out of time, and QA leads are unexpectedly besieged by other priorities. (In one memorable instance, after I had explained to the QA manager the relatively paltry need for a few machines and 10 person-hours of testing per week for 4 weeks, she replied, "Oh, we'll have no part of that," and walked away.)

It's not so tiresome when my task is simply to get a localized product out the door; in that case, I work things out on my own to achieve that goal, since I know the process from end to end. But if clients hire me to build teams and to put procedures in place for localization, the expectation is different, and people know it's an edict from above. I need stick and carrot for engagements like that. That's more like a, well, a job.