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.

I repeat the title: “Localization, Globalization – What’s in a word?” Plenty, if you want people to find you on the Web.

If you’re a language provider trying to get noticed among search engine results, you know that it’s important to choose your words carefully. In my post Top 5 Web searches I outlined several keyword combinations people frequently use to reach this blog and our Web site. Two of the most important terms in our industry deserve some attention.

Globalization/Globalisation. Many vendors use this term, and many of us in the industry apply it to our job titles: “Globalization Consultant,” or “Sr. Globalization Manager.” There was a time when I used it as a keyword for Web pages, pay-per-click campaigns and even my business card.

I stopped after a while, though. “Globalization” is often associated with rioting by farmers in developing countries, and multinational companies that behave like sovereign states. Yes, I do riot and behave imperiously from time to time, but those are not the services I’m advertising, so the use of that word brought me erroneous visits from people doing research on the World Trade Organization and coffee prices.

If you qualify it with “software globalization” or “Web globalization,” the search engine delivers more accurately, but it’s still a prickly bit of jargon. Try telling your uncle or somebody you’re cold-calling that you’re in globalization; they’ll think you’re talking about leftist politics. The word just gets in the way.

Localization/Localisation. This term is different. As with “globalization,” most uncles and persons you cold-call don’t know the term; however, it’s unlikely that they’ll confuse it with something else, because it’s unique.

Or so I thought.

I replaced occurrences of “globalization” with “localization” among my keywords and I now receive far fewer mis-visits as a result of search engine results, but I think the mis-visits will increase before long. The English word “localize” means “to fix or assign to a particular place,” but it’s not a very common term in English. The term is a bit muddy now (because of French), and will get muddier in the future (because of cellular telephony).

Early on, I received queries from France, Italy and Canada using “localisation” in combination with words that suggested “how to locate something” or “where somebody is right now.” These people land on my site or blog by mistake; they’re trying to find a device for locating merchandise in a warehouse, or want to know how to restrict malaria to a particular region. This is just a case of mistaken (keyword) identity.

With cellular communications, however, come location-based services equipped to help your favorite people (and favorite retailers, it goes without saying) “localize” you. For example:

About Krillion – Krillion is a premier provider of local shopping search information, serving today’s ready-to-buy consumers who research products online for purchase from retailers in their area…The powerful combination of our patent-pending Krillion Localization Engine, localized search results covering over 10,000 products in 40,000 U.S. locations, and unique, real-time StockCheck(TM) tool enables consumers to speed their research-to-purchase process and take advantage of in-store pickup services offered by many retailers near them.
(I have no financial interest in Krillion.)

We’ve all dreamed of the day when businesses would begin to talk more about localization, because we could spend less time educating and more time improving the process. If the term gets muddied, however, we’ll spend time explaining which “localization” we offer (language, not global position).

What is your most frequently used Web search regarding localization? Are there search phrases you check every now and again to see what new results they yield?

Over the last couple of years, I’ve tuned the keywords on this blog and on our Web site, www.1-for-all.com, for both pay-per-click and search engine optimization. I have a pretty good idea of which search topics bring people to this blog, and here are the top five topics, with my comments:

1. Localization of HTML help projects (Robohelp, CHM, etc.). I can’t tell whether people have trouble with this, or whether they’re poking around to find out whether they are going to have trouble with it once they undertake it. My hunch is that Robohelp, the dominant product for creating HTML help, either doesn’t do a good job creating localized help systems or doesn’t do a good job in explaining how to create them. Our experience has been that double-byte localization requires a specifically enabled, separate version of Robohelp, which strikes me as silly, but perhaps Adobe has addressed this by now.
2. How much to charge/pay for translation. Everybody wants to know this. Responding to the frequency of these queries, I wrote an article called “Going Global Without Going Broke” to help people who want a few benchmark figures from which to cobble together a budget. If you’re any further along than that, you should just contact a vendor, push your files to him and get an estimate. If you’re a translator or want to become one, phone a localization company, tell them what you can do and find out what they’ll pay you.
3. Localization project manager/management. I would guess that about half of these are vendors (a.k.a localization service providers, or LSPs) and half are companies with localization needs to fill.
4. Localization jobs. Most of these queries come from Ireland. There’s a relatively high concentration of localization talent in that country, and perhaps a high rate of turnover as well.
5. What is localization? Again, the frequency of these queries prompted me to write articles called “Opening the Black Box.” I’m glad to see people asking this question, because it demonstrates continuing and continuing interest in this specialty. At the same time, however, I notice that some of these queries come from China and India, suggesting to me that the IT shop which has just promised you it can localize your software for one-seventh the price you’ve gotten from other vendors, is now trying to figure out what’s involved in fulfilling that promise.

At the other end of this list are the searches we’re not seeing: questions we believe people should be asking but aren’t.

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.

3) Help files
Your online documentation also deserves some testing. After its contents (usually HTML pages or XML documents) have been translated – in the correct encoding for the target language – the help project will be compiled, in the same way that software applications are compiled. This compilation step needs to account for the correct language, locale and encoding, and this doesn’t happen by itself, no matter how lucky you may feel today.

Again, it’s important to test the help file in an environment that closely matches your customers’ environment. Run your Greek help file on a native Greek operating system. Be sure to test the main window, the contents pane and the index for properly displayed characters. Above all, perform a few searches using native characters in the Find field to ensure that your help file’s index was properly created and encoded; if your searches are successful, then your customers’ searches will probably be successful as well.

Note: HTML Help under Windows has some idiosyncrasies when it comes to the table of contents (TOC) pane and the main window. Most tools like RoboHelp will properly encode the TOC and main pane content for, say Japanese, when all of the content resides in the same project. However, if you’re building your HTML help files with your own tools (e.g., Perl scripts and hh.exe), you may find that encoding sauce for the goose is not encoding sauce for the gander. We’ve found, for example, that the HTML pages displayed in the main window are happy with UTF-8, whereas the TOC pane won’t support UTF-8 but will support Shift-JIS.

To get the broken sentences in the new files to find their equivalents (or even just fuzzy matches) in translation memory we have three options:

1. Modify the Perl scripts that extract the text from the header files into the HTML, so that the scripts no longer introduce the hard returns.
2. Massage the HTML files themselves and replace the hard returns with spaces.
3. Tune the segmentation rules in Trados such that it ignores the hard returns (but only the ones we want it to ignore) and doesn’t consider the segment finished until it gets to a hard stop/period.

To go as far upstream as possible, I suppose we should opt for #1 and fix the problem at its source. This seems optimal, unless we subsequently break more things than we repair. Options #2 and #3 are neat hacks and good opportunities to exercise fun tools, but they burn up time and still don’t fix the problem upstream.

Also, I don’t want the tail to wag the dog. The money spent in translating false positives may be less than the time and money spent in fixing the problem.

Here’s the mess I face.

The HTML files are filled with paragraphs formatted like this:

Currently, this function gets called for trust overrides and

client authentication. On client authentication, the supplied

interface contains the server’s Certificate Authorities Distinguished

Names list (see references) and the negotiation handler

always gets called so as to give a chance to the client to supply

the correct client certificate based on the DN list.

At the end of each line are two hard returns. It wasn’t always this way, so each complete sentence is sitting happily in translation memory. Unfortunately, Trados pulls in each of these six 80-character fragments and calls it low- or no-match because it can’t find enough of a concordance. This is a classic case of false positives driving up translation costs.

I’m still exploring options. Meanwhile, there’s no sense in starting the translation work.

The localization estimate has come back on the HTML files in the API Reference, and it’s as ghastly high as I’d feared.

The vendor’s project manager does something clever with these thousands of files: she uses SDLX Glue to glue them together into six or seven batches of several hundred files each. That way she avoids carpet-bombing the translator with jillions of files; this also keeps the translator in the translation business and out of the file management business. After translation, the project manager un-glues them using SDLX Glue and hands them off internally for engineering, QA, etc.

The downside to this technique is that the TM analysis comprises only the six or seven files. I can’t see down to the level of granularity I want unless I ask for a special analysis down to the file. They don’t mind doing it for me, but it’s not in their regular workflow and I have to wait for it.

Anyway, the count of unmatched words is preposterously high, and I’m pretty sure it’s due to changes in the scripts that extract the HTML from the header files. Sentences and segments in version 4.0 don’t match those in the last version because of things like double line-feeds and mucked up HTML tags.

I need to have a deeper look at the original English HTML files and bucket them for handoff. BeyondCompare shows me that the text in some files hasn’t changed at all, and I’ll need to spoon-feed these to the vendor.

Either that or get shot down when I take this estimate up to the third floor for approval…

It’s a bit strange, the way in which I get my work done.

Naturally, I play the role of localization manager and primary contact at developer meetings, and I manage budget and schedule for several projects at once. I’ve become the lightning rod for issues ranging from character sets to encodings to what-do-these-Chinese-characters-say. All in all, most localization issues are pretty well in hand because I’ve been able to manage them in a way that conforms to best practices, with a bit of experimentation thrown in to see how much better we can make things.

I suspect, though, that most localization managers who might read this have teams and staff and reporting structures. I would bet they also spend more time scrapping internally with development managers, QA and upper management, struggling to make localization conspicuous and wildly successful. I just make it work.

As localization manager for a software company in the early 1990′s I went through that. I get a lot more done this way, and I enjoy it more.

There was that exception last year. I had a client that drove me bonkers because their entire corporate culture was geared to nothing more than tolerating localization, and that with a clothespin on their nose. Wish I’d been blogging during that engagement; it was a wild ride.