How Can We Better Educate Our Clients?
By: Thomas Deibjerg (TLT Documents)
04 May 2007
"I'm going away on vacation now. Will you please get this thing localized while I'm gone?" Do you recognize this scenario? Two minutes before your own vacation starts, one of your key clients kicks off the localization of a software suite into 14 languages for what he claims is his company's most important release ever. One minute before your vacation, you receive a poorly prepared file hand-off kit comprising software for translation, documentation, help systems, marketing material, etc. To top it off, your client contact forgot to appoint a replacement contact during his vacation - so you're on your own.
Halfway through localizing the software, your teams report that the client neglected to implement most of the linguistic bugs you reported during the last localization cycle. On page one of the user guide, the first of multiple inconsistencies between software and documentation emerges (and this is the text that will go into the help system, too). Finally, when you get started on localizing the marketing material you find that that the client's marketing people managed to name the new innovative Acme PowerSoft'n'Easy functionality something different from what the software developers named it. And so the story goes… Great frustration on both the client and the MLV side.
This situation is of course a bit exaggerated, but nevertheless it has some recognizable aspects – even in the year 2007.
At one of the past GALA member meetings, we briefly discussed the aspect of better educating clients. But what do we need to teach our clients? Haven't we developed all the fancy translation memory tools, the ideal workflow systems, the terminology management tools, the style guides, the processes, etc. that will help our clients and our own companies get the jobs done in good order and in good time? On top of that – haven't we offered our very, very discounted word rates for each update in order to make ourselves attractive to the market?
The answers are yes, yes and yes.
The fact is that no matter how advanced the tools we implement and use, no matter how much we lower prices, we still often end up facing the same problems.
Localization is most commonly situated in the final stage of the development and launch of a product, and sadly, this is often when bottleneck issues arise. The greatest stress on product development is usually on the validation phase when the testing and bug fixing occurs. Localization traditionally adds to this by creating most of the quality feedback and bugs during these late stages. This is frustrating for both clients and localization agencies.
So perhaps it is in the preparation stages that we as MLVs have something extra to offer.
A corporate strategy for localization
Many MLVs offer custom project management tools, tools for terminology management, and counseling on localization processes. But the prime obstacle still seems to be the client's unwillingness to invest the necessary time and effort to get things working, and thus planning for localization often receives a low priority. Let me give you an example: at TLT we recommended that a client implement a terminology management tool – over 1½ years ago – and yet the technical writers still have not started using it.
Many businesses simply view localization as a necessary evil that needs to get done as quickly as possible. Some clients cede all responsibility to the localization agencies and then lean back, expecting everything to be resolved automatically. Then they are surprised when the MLVs return with issues such as linguistic errors, inconsistencies, spacing and formatting issues, etc.
One thing clients could be taught is that it does matter to have what we might refer to as a corporate strategy for localization . Clients need to take the time to get to know the principles and processes of localization. A heightened awareness will improve the client's ability to prepare the product for localization and to avoid the usual pitfalls of localization. Likewise, MLVs could be the providers of corporate strategies for localization to a far greater extent than we are now.
The people involved
MLVs can help clients understand how localization is part of the bigger picture. Minor decisions they make in the initial stages – prior to developing the product – might have a major impact on localization ten months later. They need to consider the whole development process of an IT product –from the requirement specifications to software development to localization as a whole. On the client side, these development processes involve many people with different backgrounds and personalities: engineers, architects, project managers, marketing people, technical writers, etc. If localization is a core objective in a business plan, all of these people should know the importance of a solid approach.
At one of my clients, the key technical writer has compared his corporation with holding a tiger by its tail… anarchy rules. This client company has been localizing their product for 10 years, and yet still today, their software developers and technical writers find it very hard to coordinate. We need to teach our clients the necessity of working closely together – not just the client with the MLV, but cohesion among all players involved on the client side: technical writers, project managers, marketing people, software developers, etc.
At the Localization World conference in Barcelona last year, F-Secure's Mika Pehkonen presented a model of agile localization . In agile localization, translators are part of the actual development of the software. Localization happens on a daily basis as the mother product is being developed. Term databases and translation memories are automatically updated during the night.
Is this more expensive? Yes it is, but Mika Pehkonen's own calculations showed him that each linguistic bug that was discovered during traditional localization cost his company about 1000 Euros in internal costs to fix. So the move to agile localization actually saves his company money in the end.
Could we learn from this?
The irony of underbidding
This brings me to an ironic fact. Clients focus more on word rates than knowing the reasoning behind the rates. They focus on word rates because they know they can use this to their own advantage to get the cheapest prices – make the MLVs compete on pricing. That's what we have taught them.
But what is it worth to a client to save 0.005 Euro per new word if the combined internal costs sky rocket due to an ill-prepared product that causes immense internal bug-fixing during localization?
Successful localization begins with the technical writer
Of all the people involved in developing an IT product, I believe our industry must address the technical writer. He/she has linguistic knowledge and should be the starting point for a corporate strategy for localization. As a linguist (not a technician) the technical writer can become an advocate for the MLV and help to elucidate a number of areas for improvement. I base this view on my own background as a technical writer and my ten years in the localization industry. The technical writer and the MLVs deal with the same thing: Words!
The technical writer can play a central role in making a project successful, because he/she:
- Can implement a linguistic standard
- Often functions as a software tester
- Can function as a linguistic mediator between the different development teams and marketing
- Has a focus on consistency
- Has a focus on usability
- Can function as the contact with the MLV
- Is able to locate and deal with potential problems before they arise, for instance by writing explanatory notes or other guidelines for the translators
So a corporate strategy for localization requires that the technical writer has a clearly defined sphere of responsibility – either as an individual or as an administrative decision-maker in a central unit of the business. Most importantly it requires that the technical writer has the backing of the management to implement the strategy across the organization.
If we want to find ways to better educate our clients, we cannot afford to ignore the technical writer. Go tell your clients this!