International Keyboard Frenzy

My wife is traveling through Europe, sending us e-mail from Internet cafés along the way. Here's one I received this morning:

thnks for the msgs.  i luv zou and miss zou 9sorrz i hav a bratixlava kezboard0. will trz longer message in a few dazs. 

love, hugs and kisses.

She's actually a pretty good typist, but she was flummoxed by the keyboard on the computer she used in Bratislava, Slovakia, because several of the keys are in different places from where here fingers expected them to be on a U.S.-English keyboard. The interface between fingers and keys is a fragile one in computing. 

Of course, my wife could have tinkered with the Regional Settings control panel (Windows) or International system preference (MacOS) to disregard the hardware keyboard and interpret the keystrokes according to any other supported keyboard layout (like U.S.-English), but machines in Internet cafés are probably not set up to allow that kind of modification without administrative permission.

Thosé of üs whö frequently wríte with çharacterß from othër langüages not natively supported by our hardware need keyboard tricks to do so.

DOS

• Are there any dinosaurs out there who remember how to do this besides me? To generate ü on a U.S.-English keyboard, for example, you had to hold down the left Alt key and enter 129 on the keypad. The left Alt key accessed the ASCII characters above 128.
• I don't think Latin-based operating systems supported non-Roman characters; you had to either buy that version of the OS or get special software to add the functionality. (Who cares? It's ancient history.)

WINDOWS

• U.S.-English users can use the U.S.-International keyboard layout to generate combined Latin characters like ëüöàñçß¿¡. I use it as my default mapping. It takes a bit of getting used to the change in how you use your quotation mark key -" ' - because you hit it before the key you want to accentuate. 
• You can also Insert Symbol in most Windows applications, but this is clunky. 
• For Asian and other non-Latin characters, or to map a different soft keyboard over your hardware keyboard, enable a different input language in the Regional Settings control panel. (This may require installing additional fonts in some exotic languages.)

MAC OS

• Right out of the box, you can use the same keyboard tricks that have been in place since System 7. Option + e tells the OS that you want an accent aigu over the next character, such as e or a; option + u generates the diaeresis or umlaut over the next character, and other option + combinations result in other common accented Roman characters.
• From the International system preference you can display a character palette in the desired language, then select the characters as you need them, or you can impose a software keyboard over your hardware keyboard. 
• There's also full support for Asian and other non-Latin input methods, but again, you may need to install fonts (e.g., for Indic languages) from your original installer discs.

I have no doubt that these functions are elegantly handled in Unix/Linux variants as well, but I have the disadvantage of never spending time on them. Post a comment if you have useful tips on this.

How do you handle multilingual character input in your daily work?

"I can quit smoking whenever I want to."

"...I just don't want to."

Have you heard that one before? I heard something similar last week from a director of engineering:

"All of our strings are embedded in source code. This is deliberate, and we planned it very carefully."

How would you have reacted?

At first, I figured he was pulling my leg ("taking the mickey," "having me on," etc.). Then he explained the process of localizing strings in the gnu gettext model, which can live peacefully without external resources.

A line of code reading

result = wx.MessageDialog(_("Welcome to my blog. Today is %s"), date.today)

uses the _ function in the English context as an identity function. In a localized context it will load the language pack built using the gnu gettext utilities and map the English strings to the localized equivalent:

"Welcome to my blog. Today is %s" -> "Bienvenido a mi blog. Hoy es %s"

To redeem what seems like shortsightedness in allowing developers to embed strings in code, these utilities also contain scripts that can pull out all the English strings from source code and make localization packages, which translators can work on without danger of touching the code. Other scripts can push the localized strings back into place.

Like .properties files in Java and .rc files in C++, these localization packages isolate non-code elements for easy localization. However, a programmer's coding mistake could still result in strings going undetected by the scripts, so I still plan to perform pseudo-translation and internationalization testing on this software as soon as possible.

Just in case the director of engineering can't quit smoking as easily as he thinks he can.

Getting Documentation Ready for Localization - The Audience Speaks

Don't you love it when the audience is listening? Even more when they write back?

Last week's post included a handful of considerations about preparing documentation for localization. An alert reader and industry veteran (who prefers obscurity to the onslaught of Web-fame that this post will undoubtedly unleash) sent me a table of resources she has compiled on the topic over several years' time:

Title	Publisher	Summary and Notes
25 Tactics to “Internationalize” your English	Intercom (STC magazine)	Hints on writing localization-friendly copy. (One example: choose words with one or few meanings).
Authoring and controlled language	TAUS (Translation Automation User Society)	A guide to how and why companies are starting to manage their writing and editing “upstream.”
Basic Tips for Loc Writing	Globalvision International	A brief overview from a translator’s perspective on how to simplify the work of the translator.
Color Connotations	Lionbridge	Guidelines on how different colors are perceived throughout the world.
Localizing Art	Globalvision International	Tips on how to improve graphics localization.
Reducing Localization Costs	Globalvision International	Tips on how to write text that is less expensive to localization – both new copy and updates.
Tech Writing for Localization	Client Side News Magazine – Tech Writer supplement	How culture and jargon impacts writing and localization. Tips on the purpose and benefits of standards and templates.
Terminology Management White Paper	Jonckers	Why consistent terminology is important to localization.
Writing for Translation	Multilingual Magazine	Tips on how to simplify text. Information on how DITA impacts localization.

The contributor comments, "Please note that some of this is proprietary to the publisher and not generally available."

Find what you can and help yourself!

Getting your Documentation Ready for Localization

Have you had to prepare your documentation for localization yet? My experience is that in almost all companies, writers have far too many other oppressive concerns gnawing at them to think about writing for localization.

A few days ago an industry colleague sent me a message asking, "Do you have experience making recommendations for how documentation can be authored for localization? I am looking to make our doc  process more efficient to reduce costs."

I replied that, given his stature and tenure in the industry, there was not likely anything I could suggest that he hadn't already considered. Nevertheless, I sent him a list of ideas, in increasing order of difficulty:

1. Make sure all the writers' computers are plugged in. (A bit of ironic humor I could not resist.)
2. Is it easy to get from the authoring tool(s) into TM, and back out into publishable format? This is my current headache with an API reference manual we localize for one client, because moving from source language to the translator tools and back to target format is a colossal headache. If you have similar problems, devote some cycles at the format-layer, even if it means writing an interface between your content management system and the translation tool.
3. There are "authoring memory" tools that can suggest and re-use already-xlated source text, so that writers don't say nearly the same thing multiple times and incur unnecessary TM penalties. Sajan has one, and SDLX contains one as well. I've never used either one, but I can imagine that success with the tools would require somebody with the documentation-familiarity of a technical writer and the global consciousness of a localization manager. Like you.
4. I've presented on localization to a variety of audiences, and have consistently found tech writers to be the most interested in it, vastly more so than developers. When you show writers how the TM tools work, tell them how they can save money and re-use content, and let them know that you care about the impact of their work on international products, they will smell the coffee and engage. This takes a bit of evangelism, but it's worth it if the writers change their own practices.
5. Convert everything to XML. Although Renato and Don of Common Sense Advisory joke that that will fix any L10n problem, it's nonetheless a good, long-term direction in which to move. It's easier to re-use text, and easier to mark text that should/should not be translated. That will save you money.
6. Start a program of controlled language authoring (dumbing down the sentences, always writing in a structure that machine translation will recognize, etc.). I guess that GM and Caterpillar are poster children for this kind of thing, but it puts the writers (and you, in the bargain) through the change of life, which is why I mention it last.

What about you? Have you faced this in your organization? How have you made document localization easier for the company, without driving your writers crazy?

If you liked this post, have a look at Getting Writers to Care about Localized Documents.

"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.