First you figured out that it wasn’t sufficient to localize your products and leave your Web content in English. To attract and support a worldwide audience, you needed to localize a lot of your online content.

Next you saw that you couldn’t simply translate the keywords you use on your site into Chinese, French, Italian and other languages. People in those countries look for different phrases, and you needed to explore MSEO (multilingual search engine optimization).

Now comes social media, and almost as many ways to get it wrong as to get it right. Nadja Specht posted recently on the different ways in which Brazil, Germany and China – to name three countries – use social media and networking. This is a localization problem, although not one that most localization project managers would need to address. It’s a marketing function, I think.

Seem daunting? It needn’t be, even for a relatively small organization. If you’re a Chinese company with lots of customers in the U.S., for example, you might be able to accommodate both audiences with culture-aware, local employees in each market.

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

photo credit: photodaisy

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.

A tip of the hat to Teresa Marshall and Shawna Wolverton of Salesforce.com and Mark Flanagan of VistaTEC for their work on last Friday’s Localization Unconference. Salesforce.com hosted the event in several conference rooms in its intergalactic headquarters in San Mateo, California. Later this month, an Unconference will take place in Dublin. Ireland, that is. (Yes, there’s another one, and it’s not far from San Mateo.)

Permit me to undescribe a well-tempered unconference, for those of you who have never attended one, or who have attended a bungled one.

Unsetup

The event draws 50-60 people from a variety of language-related industries and companies within those industries: client-side localization managers, content development experts, internationalization engineers, QA staff, international product managers, computational linguists, machine translation experts, translation memory mavens, translation tool lovers/haters, translators and translation vendors.

We convene at 9:00 and break up the day into blocks: two morning sessions, lunch (graciously provided by our hosts at Salesforce.com – please support them by buying their unsoftware), two afternoon sessions and a wrap-up.

Here, Unconference Magical Bit 1 takes place. There never having been a call for papers – well, there is one, but we foolishly ignore it – the moderators ask aloud, “OK, what do people want to talk about today?” As attendees call out topics of interest, the moderators write them as headings across whiteboards; for instance:

• translation tools
• crowd-sourcing
• controlled writing
• machine translation
• localization in an Agile environment
• ideal localization process
• content management
• multilingual search engine optimization (MSEO)
• vendor management

The topics posted, attendees then sign up on the boards for a maximum of four sessions. Once the voting is over, the moderators assign each topic to a room.

Thus, the first 30 minutes of the conference is all the time required to decide what will be discussed. Add 15 more minutes to go around the room for self-introductions, then Unconference Magical Bit 2 ensues.

Slide decks need not apply

Our friends all along the watchtower at CommonSenseAdvisory (and others, no doubt) occasionally rate localization industry conferences. Many such conferences depend upon the speaker-audience model. These sessions are not always boring, but the format is not optimized for liveliness (even if every speaker in the world now begins with the thinly veiled plea, “I would like to keep this interactive, so please feel free to interrupt me with your questions at any point…”)

At the other end of the spectrum we have industry folks in a pub, hoisting pints while griping about vendors and Windows-based localization tools. These sessions are not always futile – wasn’t Trados conceived on the back of a cocktail napkin? – but the format is not optimized for productive thinking or process improvement.

The unconference is in the middle. We enjoy the refreshing presence of industry experts, while enjoying even more the refreshing absence of industry experts telling us what to do.

In each session, attendees talk about how the topic relates to their job, ask questions of the group, write on the board, pose what-ifs, put themselves in somebody else’s shoes, hear both client- and vendor-sides to the issue, and, in general, LEARN something new. Nobody presents anything, but information still moves and people are still taking plenty of notes.

The Unconference is not the place to go for the solution for the industry’s imponderables; but then, no place is. The magic of the Unconference is that it’s easy to learn there, because it’s easier to pay attention, because the format is more conducive to it. For four time-blocks plus lunch, attendees have the chance to discuss the industry with peers, and see what people in the industry really care about. I can’t imagine a better, more affordable, more relaxed place to find out how industry issues looks from all sides.

In this regard, the Unconference is even more clever than the organizers realize.

People come and go throughout the day, of course, and by the wrap-up at 3:15, about 25 attendees remain. This is an artifact of Unconference Magical Bit 3, which is that there is no charge to attend, so you don’t feel obliged to stay and get your money’s worth come hell or high water.

Next time

From the wrap-up session come ideas on what went well and what could be different.

• There is talk of having “experts” available to cover particular topics, but my notes show that they would be enjoined from using slide decks. Whew.
• Attendees believe that, as informal as the Unconference is, they would benefit from even less formal, more frequent meetings, preferably involving distilled spirits.
• As smoothly as unsetup already runs, it runs even better when people (besides Ultan Ó Broin and Tex Texin) submit candidate-topics in advance.
• Attendees prefer a single online presence for the Unconference, whether in LinkedIn, Facebook or its own Website, instead of all three. The organizers would also prefer this.

For my part, I would like to see a session dedicated to careers in the industry. (Ultan mentioned this as well.) I think that both vendor- and client-side project managers should talk about burnout and how they can protect themselves from it, and I think all attendees have a vested interest in answering questions like:

• How has your job changed? What do you want to do next?
• How will my job change? Whose job should I try to get next?
• I’m tired of [blank]. What other kinds of jobs are there in this industry?
• Is anybody really going to pay me to do this when I’m 35/45/55/65 years old? If not, what will they pay me to do, and how can I get myself ready?

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

One client’s team of extremely enthusiastic engineers has moved its product off of XML-formatted resource files and onto Lua files.

Perhaps this proves once again that XML is not exactly the promised land; something lies beyond it.

There is some organizational momentum toward Lua. The client is in the business of making mobile software – à la “There’s an app for that” (client is not Apple, before you ask) – and Lua is a darling of the mobile gaming community because it is a lightweight, high-performance language. In fact, World of Warcraft uses Lua.

Still, when it comes to handing the resource files off for translation, as it has in the last couple of days, Lua looks like yet another format in a world that we thought had room for no more.

The strings look like this:

--[[Standard Strings--]]
ModRsc {
	name="IDS_CLEAR",
	type=1,
	id=1110,
	data =EncStringRscData(0x03, "Clear")
}
--[[noneuse 'none' to indicate no URL or specify URL (e.g. http://www.johnwhitepaper.com/)--]]
ModRsc {
	name="IDS_START_URL",
	type=1,
	id=1111,
	data =EncStringRscData(0x03, "none")
}

The strings are similar to those of a typical value-pair resource file, like a .rc or a .properties file, and they even support comments, wherein one could pack context for translators.

But the CAT tool parsers don’t like it. Both the string ID and the string itself appear in quotation marks, so even if you created a rule to isolate all quoted text, you’d end up with the string names and the strings. The tools have evolved so far that it’s frustrating to see them grab elements we don’t need, then have to tell the translator to ignore those.

Last year, I posted on the issue of unsophisticated translators and file formats. At the time, the client’s India development center was working on a way of extracting these strings to .xls files. Sadly, there has been no progress worth announcing, so here we are with tweezers, pulling out the strings for translation.

I don’t see an easy way around it. Do you?

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit:http://www.flickr.com/photos/cursedthing/ / CC BY-ND 2.0

Rebecca Ray and I had a chat about localization and software as a service (SaaS) products.

This had my dander up because I’ve been tangentially associated with the localization of a Salesforce.com application for the last few months, and there are some gaping holes between how you localize one and how we as an industry have come to understand localizing everything else in the world.

The industry standard, of course, is to externalize everything in need of translation so that it is not part of the code base. Anything else is what we refer to as a “giant localization leap backwards.” Once all of the bits of UI are out of code and into a resource file, we hand it off to computer-assisted translation (CAT) tools that make it easy for translators to do their work. The tools use fuzzy matching and lookups to help in translating consistently throughout the product, documentation, marketing collateral, Website, etc. The resulting translated resource files then go back into the code, and the result is a localized product.

Salesforce.com is doing something different. The bad news is that it’s annoying; the good news is that they realize it and have plans to address it.

(Disclaimer: Salesforce.com is hosting next week’s Localization Unconference in San Mateo, and I plan to attend, so I should not be a churlish guest by slanging their outrageously successful product. I shall be polite.)

Translation in the Cloud

If you use Salesforce.com, you know that you access it on the Web through a browser. It does not reside on your computer the way that, say, a copy of Microsoft Excel does. This “cloud” model is popular, and Salesforce.com is hardly alone in providing it: Intuit, Oracle, SAP, Google Docs and a jillion other vendors and packages run this way. In fact, Lionbridge wants to move the entire localization function into the cloud with its GeoWorkz initiative.

The problem is that, not only is all of your company’s data in the cloud, but everything in the user interface is, too. So, if your company developed an elaborate customization to its version of Salesforce.com’s product – as my client has – and if you suddenly needed to localize all of it, you need to translate a great many strings that reside in the cloud, and which you cannot simply spin down into a resource file and hand off to a translator.

Salesforce.com has done this deliberately. In their fervor to keep everything in the cloud, they have built and made available their Translation Workbench utility, which allows your translators – you do know who your translators are, don’t you? – to translate your customized application in the cloud.

The problem is…

It’s not the Jedi way.

When translators work in the cloud, they have no recourse to the above-described CAT tools that contribute so roundly to their ability to deliver a professional, consistent translation. It’s like “tastes great” and “less filling:” you can’t really have both, despite what the commercials would have you believe.

They need to scribble notes to themselves and remember stuff. If several of them are working on the project, they have to phone or IM one another, instead of having all the history and intelligence reside in the tools. It’s like going back to translating when all you had was a typewriter, a dictionary and a sheet of paper.

The Other Way to Localize a Salesforce.com Application

The forward-thinking localization product manager at Salesforce.com, Shawna Wolverton, is painfully aware of this problem. She told me that the company has in place a somewhat clunky procedure for exporting all translatable strings through the use of a high-end version of  Salesforce.com, the Force.com IDE, the Eclipse IDE, three forceps, a banana and a bicycle pump.

Shawna has made available a document on this procedure, titled “Localizing with the Force.com IDE.” As the document describes the procedure,

The Force.com IDE can offer great time savings by allowing you to work with your translations in XML files and use a simple interface to load the translations into Salesforce.com easily.

Even with my 10% markup, you can obtain the document for free.

The result of this procedure is that you will have XML files which your translators or language service provider can pull into CAT tools, translate and hand back to you for re-import to your application.

Shawna also tells me that they envision an even easier export-import function as an option in the main product sometime in the near future.

“What’s next, Johnny?”

I’m glad you asked.

Ten years ago, we had the same problem, except that instead of translatable content residing in the cloud, it was in our content management systems (CMS). Companies had invested mega-bundles of money to centralize documents in CMS, and people in my position felt, well, silly having to pull documents and files out of the CMS, attach them to e-mail messages or burn CDs with them, and send them to our localization partners. Silly, I say.

The vendors came to our rescue by building interfaces between their CAT tools (or the server versions thereof) and our CMS, so that they could find changed files, pull them out for handoff to translators while we slept, and check them back into the correct language branch in CMS before we knew they’d even been touched.

I have no doubt that this similar predicament will inspire vendors to enable their tools for the cloud, so that they can find your Salesforce.com application, translate the UI while you’re asleep, and let people in other countries work in their own language before you’ve had your first cup of coffee the next morning.

Ain’t technology grand?

John White of venTAJA Marketing is a localization project manager and consultant.

How specific do you want to be about the language of your terms and conditions?

Suppose you have your copyright information or software license translated or localized into a variety of languages, and somebody exploits a mistake or misunderstanding or mistranslation. How do you cover yourself?

Here’s an example from the Terms and Conditions for Carbonite, a provider of online backup:

English Language

These Terms and Conditions of Use were negotiated and written in English. Any inconsistency between the Terms and Conditions of Use as expressed in English and any other language shall, to the full extent permitted by applicable law, be resolved by reference to the English version. Les parties ont convenu de rediger cette entente en anglais.

Is this a good way to leave yourself an out? Carbonite’s attorneys and management must think so. Ask yours.

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit: tracie7779

Among the dozens of unsung challenges of translation, file formats are among the most infamous.

There is almost always a disconnect between the format in which content creators save their files and the format (or the tools, really) in which the translators want to work. The content is in .pdf, and the translators want to work with MS Word .doc files. The software application works with .xml, and the translators want to work in with MS Excel .xls files.

One client, which distributes a platform for creating mobile phone applications, is grappling with this at the moment. It manages resources in a structured file format based on a programming language called Lua, so its translatable text looks like this:

They have asked me how translation works, because they’re willing to build a converter into their editing tool that takes resources like “This is a new app” and puts them into a format (.doc, .xls, .txt, etc.) that translators can use.

I applaud this kind of thinking, and spent about an hour on the phone with their development team in Hyderabad discussing it.

Background on Translators

There are two kinds of translators:

1. Sophisticated – proper localization companies using computer-aided translation (CAT) tools and professional linguists
2. Unsophisticated – “Here, Bob (or Najiv or Youli or Ramesh). Have your brother-in-law translate this for us.”

Sophisticated translators will use tools that parse XML, HTML, .rc, .properties, etc. files flawlessly, isolating the text for them to translate and hiding the code, tags and other things we don’t want them going near. As long as the convention is reliable – e.g., translate anything in quotation marks – the sophisticated translator can modify the parser to find and extract the text. These translators and tools are appropriate for apps with any number of translatable strings.

Unsophisticated translators are limited to tools like MS Word and Excel. Therefore, somebody or something needs to pull out and transform the translatable text into these formats. Then, after translation, somebody or something needs to reverse the transformation and put the text back in. These translators and tools are appropriate for apps with small numbers (<100) of translatable strings.

Recommendation for Resource Files

I explained that the Lua files would pose no problem for sophisticated translators. Tools like Trados, SDLX and Déjà Vu will easily parse and isolate translatable content in quotation marks.

For unsophisticated translators, one of the engineers suggested creating a plugin for MS Word that would parse all translatable text and allow translators to work in their favorite tool. There would be no need for developing transformations or conversion routines to go from Lua format into .xls/.txt/.doc/etc. The plugin could save the translated version back out in native Lua format.

Everybody wins with this solution.

• My client’s engineers get off the hook of creating an intricate program to cover multiple output and input formats for resources.
• The app developer has an easy way of pushing resources out to translators and pulling in the translated result.
• Sophisticated translators don’t need to change the way they work at all.
• Unsophisticated translators get a simple format that only requires that they install an MS Word plugin.

What kinds of file-format trade-offs do you have to make?

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit: woodleywonderworks

Get localization right, from the bottom up

“Here’s our pet rabbit. Can you change its DNA for us?”

“Nice house of cards. Could you replace the red one in the bottom row with this green one?”

“Good job localizing the Web site. Can you change all instances of usted to tú?”

Has this ever happened to you? It’s happening with one client on a Web portal we’ll soon roll out in Latin American Spanish.

***

In Spanish, there are two levels of address: formal (usted) and informal (tú). Historically, if you’re talking to the king or somebody whose business you want, you use formal address. If you’re talking to your friends or to a small animal, you use informal address.

A few years ago, this was a no-brainer in localization. Most software, Websites and marketing material still used usted because you’re talking to customers and you want to honor them. Trendy sites like AOL.com and terra.com used tú because they wanted to be your friend as quickly as possible.

NAFTA, the Web, immigration patterns and cross-border commerce have brought Mexico and the U.S. so close together that the old rules don’t apply as much anymore. Cell phone companies, auto dealers, even banks are using tú in customer-facing materials. There aren’t reliable rules anymore; the choice depends on the organization’s messaging.

***

We started localization about five months ago, assuming usted. We dutifully created a glossary and asked for in-country review by the customer, a wireless network operator. The customer must have been too busy, so we received feedback from a business development manager along the way. The comments gave us some terminology preferences, but no mention of usted vs. tú.

Now the portal is up in Spanish, and the customer has finally begun to review it. New and changed text is coming back to us with tú. They haven’t asked us to change the DNA of the rabbit yet, but sooner or later the usted and tú fronts will collide and we’ll need to work it out.

The moral: You should have learned long ago to have your customers specify the region for the Spanish (or French or Arabic or Chinese…) they want. Remember to ask them about usted vs. tú as well.

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit: bloomsberries

Translations for Facebook Connect is a new program FB has implemented to get its user interface translated into other languages, according to a write-up in the New York Times by Brad Stone.

Google has been known to do this with machine translation, using technology to automatically translate Web sites and text. FB’s approach will differ, in that:

The translation tool works by asking users to submit possible translations of phrases, and then soliciting their votes on which is the most accurate.

Facebook can get away with this for a few reasons:

• It has the traffic. Large numbers of visitors will yield large numbers of willing translators.
• The traffic is social-minded, instead of hunched over in research mode. Most people spending time on Facebook are in helpful/social mode, instead of trying to get work done. They’ll take the time to work on this and consider it another dimension of customer engagement.
• It has figured out that the best translation is the one the customer wants – or in this case, the largest number of customers wants – so it’s going to give it to them.

It’s open-source translation, after a fashion, which is not that different from open-source software coding, except that the translator community raises a hue and cry when somebody tries to take away potentially paying work, whereas software developers just do it for the crack and to make a better product.

Localization by vote could even help clean up some of the Microsoft-imposed software idiom that users (and translators) in several countries have complained about for years. Your chance to get this vocabulary back on track.

What do you think? Would you help Facebook out?

"Let me help you localize that."

We’re running a medium-sized project from En-Us (English for US) into Es-Mx (Spanish for Mexico) and Pt-Br (Portuguese for Brazil). It’s a Web portal based on Java, and the strings are in resource bundles  or .properties files. The product manager and I are in California, the engineering lead is in UK, the Java developers are in India, and I don’t know where the translators are. Maybe Greenland. Par for the course these days: the sun never sets on this project.

One of the translators sent me an anguished e-mail and a screenshot the other day during linguistic QA of the Spanish portal:

“Here is a screen grab containing a few Es strings I don’t recognize,” she wrote. “I’m the only translator, so I know all of the text, but I’ve never seen these strings before. They’re not in TM, either. In fact, the En strings aren’t even in TM. Have you been translating strings yourself? Has somebody else? What’s going on??”

(I like my translators intense. The drama keeps things from getting dull.)

It took some digging, but I deduced that someone on the chain of development had been creating new strings – which I knew they were going to do – and using Google Translate to stage them quickly and see whether they would run too long. If they were too long for the button or some other element in the UI, the engineer had more work ahead, but s/he didn’t want to wait for the proper translation, and so made use of free, Web-based translation.

This kind of translation gets many of us in the industry in high dudgeon, and there’s no point in my rehashing the pros and cons. This, however, was an unintended consequence of having machine translation as close as your browser. If the engineer had staged the translation, gauged its length, then removed it, it would never have befuddled the translator.

The problem, then, is that machine translation looks just the same as human translation, except that a linguist needs to trip over it, double-check it and raise a QA issue over it.

I told the engineering lead about this via e-mail:

PLEASE PLEASE PLEASE PLEASE PLEASE tell the team not to do their own translating. They may think it’s helpful, but It’s counterproductive. I’d rather just have the En strings alone.

The moral: To the list of things you work out with Engineering at the start of a localization project, add “I promise I won’t write code for you if you promise not to do any translation for me. Deal?”

John White manages localization projects for several technology clients. He fancies himself the localization manager for companies that do not want one.

photo credit: pulihora