Yet another article about consolidation? Well, with all the opinions expressed recently, throwing a few more stones in the fishpond is hard to resist. I promise, however: no industry models, no Austrian economists, no charts or graphs. I'll stay on the lighter side, give you some food for thought, and remain the only fool to blame for the content.

The Localizers

Today a lot of people call themselves localizers, but where did the first ones come from? They used to call themselves translators and were in business long before the mutation occurred. I am talking about the veterans, those who've been around for a double-digit number of years and can talk about life before Windows.

In those days, when you wanted something translated, you roughly had the choice between literary and technical translators. The latter translated all types of manuals and quite logically started to get requests for software. Of course, three million lines of FORTRAN with embedded strings wasn't quite the same as a user manual.

Equally obvious was that the customers had no clue and lots of dollars. It didn't take much vision to see a promising opportunity in "software translation". The company I worked for in France managed to live a whole year on a single project. As a bonus, when the software finally shipped, it was so obsolete we could start all over again.

The customers had to adapt the software's functionality to local laws and business rules as well. In my part of the world, this change of content was called "localization". For a while, as it always had been, changing the language remained "translation". This made perfect sense, but was probably not vague or sexy enough for marketing purposes. So the lines quickly blurred.

We got up to our ears in software that was never meant to leave the US. What made us special was our willingness and capability to take on some pretty complex engineering, and to suffer the erratic course of a product under constant development. This was not a goal in itself, only the necessary step to deliver translations of this nature. While the means were new, the guiding principles were not: take apart, translate, put back together and validate.

This is still true today, and that's why the majority of localizers should be called software translators. Only those who develop local content, for example for multimedia titles, can claim they are localizing something.

This is not a futile terminology argument. The point is that what most people call localizers are in fact translators who are jumping through technical and logistic hoops to get their work done. Why? Is there an immutable law saying that software by nature is difficult to translate? No, there is a circumstantial law saying that publishers by nature don't pay attention to translation.

The complete history is a lot more complicated, of course, but this is close enough. Just keep in mind that translators practiced internal project management and coordination long before software barged in. Naturally, these internal practices had to be adjusted to deal with new tools and deliverables, but that logical evolution is not the cornerstone of what is now called "localization".

The novelty was the big need for external management and coordination. Most publishers simply threw their products over the wall, without any intention of changing their own habits to accommodate this new activity. Translators rarely succeeded in influencing the products and procedures; many took the business without even trying. They had to invent a whole arsenal of work-arounds and compromises. Over the years, this initial tinkering with the translation industry evolved into the more sophisticated tools and organizational models of the localization industry.

It is precisely this part that nowadays underlies the term "localization" and is highlighted as main strength and added value: compensating for the inability or unwillingness of the publishers to simplify the process.

The Publishers

To be an expert in dealing with problems generated by others has annoying consequences. First, you get what you ask for - problems. Second, you cannot anticipate, so you are constantly operating in reactive mode. Third, you must be technically competent in an environment where technology is abundant and changing faster than you can learn it. This means covering a lot of ground without much chance to capitalize on the skills you acquire. These lessons have long been learned and plead in favor of building larger organizations.

The assumption, however, is that the publishers will happily continue to ignore the requisites of translation. This leads us to the Achilles' heel of this model; the day the software industry gets rid of the problems, the localizers follow. If the need to jump through technical and logistic hoops disappears, the business goes back where it came from: translation. This might sound extremely theoretical, to some probably ridiculous. Does that possibility even exist?

Viewed from the publisher side, attempts to make "international" an integral part of the organization typically go through three stages: too early, too busy, too late. The common factor between these stages is the very foundation of corporate America: "Unless it means revenue for this quarter, forget it". I hold executive information sessions and could summarize the typical attitude of a president or CEO as follows: "This is a real eye-opener. Now at least we understand what (will) hit us. At this point, however, doing something about it might slow us down (read: in this quarter)."

Can this voluntary shortsightedness be the main source of business for the localizers? I don't think so. Not so long ago, it would have been very hard to find a single executive willing to spend time and money for a session on this subject. The information might not necessarily be converted into immediate actions, but the localization managers certainly gain increased attention from it. Actually, the very existence of localization managers is worth a thought. How many were there 5 years ago?

I'm a big fan of software bookstores that have publications so hot from the press you need mittens to pick them up off the shelves. Spending half a day in there is like taking the pulse of the software industry. Not so long ago, a tiny new section appeared: the international section. Just a few books, some fairly old, none very good, but they weren't there before. From the next shelf, open the latest book about some development language and what do you find? A chapter called "international considerations". Just a few pages in the back, but it wasn't there in the previous version.

You get the point - attitudes are changing. Is that enough to start shaking in your localization boots? Probably not. The trend is undeniable, and it slowly crunches away at the foundation of "localization" as I defined it earlier, but I can't see it turning into a tidal wave, complete with T-shirts, caps and magazines. No, the real killer might be lurking in a domain that is surprisingly absent from the debates among localizers. Although there is a lot of talk about machine translation and other technologies of the trade, little is being said about the publishers' technology.

The Technology

In my favorite bookstore, you have to search a while to find the international shelf, but you would have to be blind to miss the impressive mass of novelty books covering the walls. At first sight they seem to address very different topics, but if you take the time to browse, you realize that no matter how unrelated the titles, they share a common concept: objects. Don't confound these with the objects you got acquainted with in object-oriented languages. This is a new breed, one that has a life of its own and represents a technology of software components that has the potential to change the face of an industry.

This is not the place to diverge into technical details using acronyms like COM, DCOM, CORBA, OLE, or ActiveX. Only the concepts are needed. Look at it this way: up till now, when you wanted to buy a software hammer, you had to buy the whole toolbox, complete with a set of screwdrivers, saws, pliers, etc... Whether you needed all these other tools didn't matter, you couldn't get the hammer without them. With this new technology, if you need a hammer, you can grab one out of the toolbox. I could also send you one over the Internet.

What makes this technology so powerful is that it works regardless of who created the object, what language or tools were used, and on what platform it was developed. It also doesn't matter whether the object resides on your desk or lives on the other side of the planet. In other words, the industry has invented Esperanto for software components.

The consequences are profound. If software companies were building cars, the way they operate currently is to start digging for iron ore every time they design a new car. With this new approach, they'll be able to operate much more like a real car builder: buy engine blocks from one vendor, wheels from another and headlights from a third. Components will be ordered from catalogs and delivered literally at light speed.

Viewed from a localization angle, the implications could be far-reaching:

• The short term tendency is to convert whole applications into a single object, which is the quickest way to send out the right marketing message. However, to obtain the real benefits, objects must execute very specific tasks and travel easily in cyberspace. The trend therefore will be towards smaller, more specialized objects, which means that the volume of translatable elements in any given object will significantly decrease.
• Objects are autonomous entities that are developed independently; they can therefore also be translated independently.
• The specifications define very rigid rules for maintenance and versioning. In short, a changed object is a new object. For translation, this would mean no patches or last minute updates.
• Objects must comply with specific standards. This creates a rock-solid basis for more standards. Rules for the implementation of translatable elements could open the door to standard translation tools and procedures.

Today, beside hitting the bookstores, this technology is brewing in every R&D department. Engineers are still grappling with the concepts and their implications. The software industry might be fast-paced, but it does have inertia, and there is no telling how long it will take before software components reach their full potential. What should be clear is that they will. This technology is extremely compelling and can very quickly find its place both on the T-shirts and in the "revenue for this quarter" category.

The Consolidators

From the start, the proposal to accept any technical or logistic challenges in order to deliver translations is a recipe for trouble. The tools, the processes, the organizational models built over time are completely at the mercy of the publishers and their products.

How localizers work is, first of all, determined by the position of the line their customers draw to separate the internal work from the external. Having myself tried to draw that line from one extreme position to the other, I've learned that when a publisher's organization is truly determined to do what is required, the only activity a localizer can perform more efficiently is translation.

Having a localization manager is one way of redrawing that line. Unfortunately, these positions are often as powerless and isolated in their own company as the vendors are outside. Unable to influence internal operations, their only option is to continue pushing the problems down the chain. This is what really underlies the publisher's constant requests for better project management and procedures: "My company is not going to pay more attention to this. You better be ready for anything". This approach perpetuates the idea that jumping through hoops is the quintessential quality of localization.

Twice I started managing localization out of Europe, and twice I ended up relocating to my company's headquarters in the US. Why? Because there is only so much you can do at the end of the chain. The roots of most of the issues localizers are struggling with lie at the very heart of the publisher's organization. The only path that leads to durable solutions is the inside track. External parties have no access to it. That's why the publishers could easily beat the localizers at the efficiency game, if they decided to do so.

With the perspective of radical shifts in technology, this already brittle foundation turns into a patch of quicksand. Consolidating to build an empire on such grounds is clearly a perilous exercise. The biggest danger is that by the time the consolidation is completed, the massive troops equipped and trained for vast offensives and sustained sieges find themselves in a war of commando units and hit-and-run tactics.

The software component technology has all the ingredients for this. Small, independent chunks of software could be translated in a standardized way by a few people located anywhere on the planet. External project management and coordination in such an environment could be as exciting as watching trains go by in the control room of a large city's subway system.

Of course, all of that is guesswork. Whether or not it materializes, none of it will happen overnight. In the current environment, consolidation is a logical move. If the larger organizations manage to set their own standards and acquire sufficient clout to convince the publishers to work accordingly, the whole profession will benefit. I also know and respect the players involved and have no doubts they are aware of the dangers...and have planned accordingly. With the right strategies and back-ups in place, even shifts in technology can be dealt with.

The Roots

In the previous sections, I tried to demonstrate that the activities getting the most attention today are a very unstable basis on which to develop a business. Don't misinterpret this thought. I'm not pretending you can stay in business without excellent procedures and project management. My point is that the implementation of these services cannot be the foundation for growth.

If you don't like the quicksand, you might go back to the roots to find some solid ground to build on: local expertise. This expertise can be related to language or to content, and I hope you don't mind if I ask you to adopt my terminology for these last few lines - when you change the language you translate, you change the content you localize.

I often hear development managers declare that they must first finish core development before they can give translation or localization a thought. Nonsense! Translation and localization are core development. They are the instruments used to develop products for markets other than the ones originally targeted. The vast majority of publishers don't have and don't want these instruments in-house, and this makes a lot of sense. Consequently, what drives this business is translation and localization. The customers need language and content expertise. These are the real values this industry has to offer, the rest is auxiliary.

But aren't the publishers more interested in project management, tools, procedures and delivery dates etched in stone? Isn't that where the real business lies? The problem is that most publishers want personalized service at the price of mass-consumption. What they want to buy is their project management, their tools, their procedures and their delivery dates. There are no two publishers who define project management the same way or have the same procedures.

What would happen if they did pay the price of personalized services? They would quickly find out that it is less costly to implement proper internal structures than to pay external parties to run around like headless chickens every time development makes a change. They would realize that it is not very efficient to let half a dozen people in France spend a week figuring out how to take apart a product, when a guy upstairs could explain every detail in 30 minutes flat. They would understand that translators and localizers must be part of the project, but cannot lead it.

Nowhere is it written that efficiency is mandatory and this business has been alive and well without it for years. I suspect, however, that only one side was picking up the tab. If executed well, consolidation might come to terms with this rampant problem. The resulting business proposal could take the form of a choice: jumping through hoops at a cost or standard projects with discipline. Considering the stature of the players, I can't help finding language and content a much safer bet.

You will notice that while language is largely covered by the industry, content is not. You would be hard-pressed to find among today's "localizers" somebody who not only knows how the publisher's customers speak, but also their habits. After all, isn't the publisher's customer base the ultimate target of this whole effort?

The Conclusion

I liked the Far West analogy given by Finbarr Power in Mainz, and it inspired this conclusion. While working at it, my writing took a strange twist. Quite accidentally, a peculiar rhythm and rhyme had appeared in my first sentences. I got caught up in the game, and that's how I ended up with these rather facetious paragraphs. Hopefully you'll pardon me for the irreverence and will have as much fun reading as I had in writing it:

The convoy has halted, it needs rest and repair. On a soapbox the notable has news to share: "Friends you've worked hard, suffered our abuse. Of all this, what was the use?
We're still rich, you're still poor, you can see this for sure:
our chariots are new, they're loaded with gold; yours are empty and old.
We think it's unfair! Here's what we will do: divide it all between the strongest of you".

"Sell me your wagon, your horses and all", proposals are whispered at nightfall.
Fists fly, tempers flare, friend-foe alliances fare.
"The convoy's my life, what should I do? Stay or leave? I have no clue!"
"You were never that strong, never were one of us. Aren't you tired of eating our dust?
Why not build a farm? Why not raise a cow? You could be smelling the roses by now".
Some say yes, some say no. Most really don't know:
"The horses won't like this, I know them so well. Can I still hold the reins if I sell?"

Wagons are emptied, wagons are filled, wagons change owners till night is killed.
"Let's ride!", at dawn the notable cries. Is it amusement twinkling in his eyes?
Whips crackle, wheels creak, straining horses feel weak.
Dewy meadows, blue sky, cash-filled hands waving chariots good-bye.
Some with relief, some with regret. And on moves the convoy ... to the vast swamps ahead.