Some time ago, a great article was published by an anonymous writer who goes by the alias "the masked localization insider". You can read the entire article here: http://thecontentwrangler.com/2010/05/03/l10n-reality-check-industry-insider-shines-light-on-the-dirty-little-secrets-of-the-translation-and-localization-industry-that-you-wont-learn-at-a-webinar/
Too bad that we need to address the writer by his/her alias - we would love to give credit because credit is due. The article addresses issues that probably most of the localization providers and customers have come across more than just once.
This article is not a response to the writer's criticism. In fact, we feel that there is a lot that deserves to be criticized and that should be changed by any responsible L10N provider.
Some topics in the article made us want to respond immediately, others took a little longer because they needed to be digested. It all boils down to:
"What's In A Word?"
Running a company that provides L10N service to a number of clients and having done this for many years also means that we have encountered a fair amount of questions and skepticism by potential customers and partners. It all starts with developing a good and lasting relationship with your customers. How do you accomplish that? How to do you maintain such a relationship? The key elements of a good relationship between an LSP and their client:
Trust
Localization is a service provided like many others. The customer is king and the provider tries to make the king happy. Nothing wrong with that. But before you even get a chance to prove your value you will need to be recognized as a serious contender for the customer's attention. There are many people at the table and they all want to have a piece of the pie.
There is no easy way to gain someone's trust. You have to earn it. So get busy on social networks, add as many people to your LinkedIn profile, tweet smartly, don't follow people blindly, establish yourself as someone who is knowledgeable.
If you are given the chance to present yourself to a customer be aware that you're likely not the only one presenting. The others will be there, too, or were there already. We know from localization project managers on the client side that not a day goes by without several L10N offering their "unique" solution to a very common problem. Are these solutions really unique? Or are they just saying the same thing over and over again, just in different words?
L10N is - by default - an international effort. To do your job right you have to have the right people, tools and knowledge. Many L10N providers claim to have offices in many parts of the world (and some actually have ...). The idea is not only to use the best and most economical resources for any given task, but also to show your client that you "know the target market" by being there.
But is that enough or does it actually backfire?
The best and longest-lasting customer relationships are based on really knowing the people you work with and for. Your client trusts you (their contact); it is you who they call if they have a questions and you are the one whose calls they will take if you have a question. Not your partner overseas, not your sales people, either. They trust your judgement, and ultimately, they hold you responsible if something goes south.
Which brings us to...
Counting
Our work is based on units. Units that can be counted. By everyone. And they can be verified. A per-unit-rate is the common way of charging for your services. Units can be words, pages, modules, hours and everything in between.
One of the first and most important steps in creating a good relationship with your partners is to count right. We are not like those services that slap one fee on top of another and yet one more fee on top of that, including a fee to go paperless. Just look at your Ticketmaster charges or your phone bill and you see how additional charges can quickly double your bill.
This is obviously not the way to build trust!
The typical L10N project does not just consist of "flat files" that need to be translated. There are other tasks, more complex files, testing, consulting etc. Some of these are hard to assign simple numbers to. Let's start with the simplest ones first and move up the ladder.
Word counts
You have Microsoft Word documents, and before you send them our way you have checked the word count. There is your starting point. It is very likely that the quote you get will use that word count, or a number very close to it. Most language providers will use the word count of the source files as the basis. There are other systems, but those depend on the source language (think Chinese and Japanese) or traditional ways of counting (for example: per line, using a standard of 55 characters per line including spaces).
Things will start to look quite different when you use translation memory tools or files in another format.
Word is not the only format that source files can be found in. Take for example text in an HTML file, full of tags, like this one:
"<td width="275" style="font-size: 12pt; font-family: Arial Narrow" valign="top">A spectacular view of the entire city</td>". The word count here is either 7 or 14 or anything in between, depending on how you count.
During translation such tags need to be dealt with with by the translator. Translation tools will group the tags and your word count will likely not be 14. But it may not be 7 either.
Page counts
Like with your word count, there should not be a problem counting pages, right? Normally it is not complicated, but the English language is one of the most efficient languages when it comes to expressing yourself with short words. Just think of all the English 4-letter words and then look how long these word are in another language. This effect is called "text-swell". In some languages it can easily increase the required space by 20 percent. And increased space means more pages.
(The paragraph above has 85 words in English and extends over 5 lines. In German, this could be written in 79 words, but would be six to seven lines long). Now multiply this by hundreds of paragraphs and your page count in the target language will likely increase.
If the project includes page formatting (or "DTP" in L10N lingo) each page of the target text needs to be handled. The number of pages of the source document can give a rough estimate of the volume, but what ultimately counts are the target pages.
Graphics and illustrations
It's easy to count the "pictures" in a translation project. It's not so easy to identify those that need to be edited/translated. First of all, it is a manual process. Someone needs to look at each graphic and determine if it contains localizable content. Then the content needs to be counted (after all, someone will need to translate it)
Graphical items can appear in many variations. Some contain text that needs to be translated, some text doesn't even look like it comes from a graphic - think "scanned pages". Either way, they may require additional work, such as layering, text extraction and so on. And don't forget text swell - a button designed to accommodate "OK" may be too small to accommodate "Acceptar".
Websites
There are all sorts of tools that can be used to create a website. And while the end result is what you see through your browser, it is how you get there that counts. Sites like Yahoo or Google allow the creation of your own "site", using their templates and tools. Other websites are hosted on dedicated webservers within your organization. And again, anything in between.
Just as with hosting options, there are many authoring tools - often trying to offer something the others don't have. This creates an abundance of file formats, each of which may require a different tool set or process.
And then you have the many different uses for a website. A front end to an e-commerce site, a marketing site, a corporate portal with extranet access, the "plain old" website. The list goes on and on. To this you can add the plugins that make your site look fancy - think of the Twitter feeds, the Facebook "Likes", the Flash intros. If you want your site to be localized you should plan how you want to handle all of these factors.
Our website consists of about 50 individual pages. Each page can be reached by following a link. Now let's imagine we are localizing our website. Suddenly, each page gets multiplied by the number of languages it is translated to. That makes for a whole lot of links, and each one needs to be managed.
How the site navigation is handled is determined by web designers, programmers, IT staff, mom & pop shops, do-it-yourself-professionals, you name it. Website localization is not automatically on their radar. So we end up with a wide range of possibilities, not all of them "localization-friendly". Fortunately, there are tools. We use them to extract your content, protect your code and manage their interaction. If it weren't for those great tools we would be seeing much less international web presence.
Software
Just translating someone's software is not a good idea. Software needs to remain functional, it's not just something pretty to look at. If you are planning to purchase something over the Internet some time in February it may make a huge difference if the vendor in France offers delivery by 3/5. You may end up waiting a long time, because what you think is March 5th may well be May 3rd. For the date to be understandable, the software behind it needs to be aware of your location.
Software that uses Social Security Numbers (SSN) as part of a user's identification will not function properly if used outside the US. Other countries have other identifiers.
If your password field masks your entries with **** , you're in China, and you want to use the name of your hometown Beijing as password. Now, you type the name of your hometown Beijing as password 北京 and you can't log on. What happened? What happened is that the developer only allowed ANSI characters in the password field and you couldn't see what you were typing because it was masked.
What is behind all this is called Internationalization (I18N) - the process of designing and developing an application without built-in cultural assumptions which is efficient to localize. The process that makes software available to users in other countries is Localization (L10N) - tailoring an application to meet the needs of a particular region, market or culture.
We at BeatBabel do localization. We assist with internationalization. There is much more to the process than to replace each English word with its non-English counterpart. Just counting words is not enough, but it's a start.
When you're done counting and translating the words in an application you will need to make sure that those words fit in the space available. You will need to make sure you are consistent with other modules that may already have been localized. You will definitely need to make sure that you're not using terminology of your client's competitors. And you don't have the comfort of lots of prose surrounding your term - often you have just one word.
This is where a glossary comes in handy. It needs to be researched, translated, approved, and updated. You will likely base your counting on the number of "terms", assuming that a term can consist of more than one word.
Part of the process of localizing software is testing and "resizing". Here you make sure that everything fits, that the "OK" button in Spanish is large enough to display Acceptar and not just "ce". You check that hotkeys and accelerators work and that "View" is translated correctly as a noun, referring to displaying something and not as a verb asking you to look at it. The effort to get it right can be substantial and may require several "roundtrips" where changes to translations need to be made if the context shows that the previous term just wasn't right.
I have seen different ways of accounting for this effort. The most common method is probably to add up the hours it takes to get it done. Others count the number of dialogs and yet other others use word counts charged at a somewhat higher rate. To me this is the best and easiest method.
Which brings us to ...
Rates
"Why are your rates higher than those of an individual?", "There is a company in India offering translation into German for 7 cents per word? Why not use them?" The simple answer is "use these resources if you can afford it ...". The more complex answer is "... but consider the consequences if something goes wrong".
So. Why are our rates higher than those of an individual? Obviously, because as an L10N provider we have overheads that are higher than an individual's; because we have people on staff who don't work directly on your project; because we are a company and pay taxes on top of individual income tax. But that's not all.
The most important reasons are the expertise and service that a team of trained professionals provide to our clients. Imagine your car needs repairs. You can take it to your neighbor who is a mechanic and works out of his garage. He'll probably have the common tools needed and will know the most common procedures on the most common cars. If it is a simple repair he'll probably get it done right, for much less than it costs at the dealership.
Chances are that your neighbor will tweak things that your dealer would replace. It's cheaper to tweak than to replace. But you have no warranty, and you don't know if tweaking really fixes anything. Scary, if you plan to take your car on long road trip the next day. And what do you do if your neighbor is busy fixing someone else's car? Do you wait for him to become available? Do you go and look for another neighbor?
As an L10N provider we don't tweak. Yes, it costs more, but you have a warranty. You know that what we do is backed by experience and knowledge. We don't make you wait because we work on another client's project. That's the advantage of having more than one expert on board.
Communication
Stuff happens. You can't meet a deadline, you don't agree with a client reviewer's comments, the scope of your project changes. So what do you do and how do you tell your client?
None of these are the kind of good news that you just love to pass on to your client. In a competitive environment, one of the biggest fears is that of "screwing up". Is missing a deadline or are the client reviewer's change requests signs of having screwed up? Could be. And your business relationship with this client may be over by that time.
But not always and automatically does this mean bad news is bad for the relationship between us and the client.
Convey good news when it happens - it builds credit for some not-so-good news;
waiting for the situation to "self-heal" doesn't work;
don't make each piece of news into an emergency scenario;
if you don't know/understand something, ask;
don't change the players constantly - work on long-term relationships;
if you use an escalation path, it is just that - it escalates an often simple problem into something bigger and more terrifying, involving people who know less about the issue;
communication is not only written or verbal. Getting to know and understand your partners also happens through meetings and other means. Work on these, too.
Years ago, when I worked for a European LSP and our client was the biggest software company in the world we all needed to develop good ways of communicating. Everyone at the table knew that things would go wrong, but nobody knew what would go wrong, when and how. So we established communication channels that went way beyond the typical status reports and weekly conference calls.
We were lucky to have a stable team and our client had one, too. That way, client-vendor teams were established that grew over time. Changes to the teams were minimal and communication was easy, including regular meetings, trainings, post-mortems, project-launches. And while many things have changed, we still favor this approach over any other approach that is out there. Our teams don't change. We don't rely on sales people maintaining the client contact and we don't change our account managers every six months or so.
BeatBabel's philosophy is built around good and efficient communication. For us, it is one of the tools to make a project better, and we use that tool as intensively as possible. We have yet to see where "not communicating" is the better option.
Looking at all the aspects of a good client/vendor relationship this list could go on indefinitely. Our anonymous writer has certainly poked a hole into the balloon of complacency and BS that should rattle everyone awake who cares about this industry. We will watch carefully what we are doing and how we are doing it, and we hope that the readers of this article will find some ideas worthwhile discussing. We look forward to hearing from you!