How To Choose Translation Services
Posted in Development
We've been involved with a translation company (no names) for about a week now, and, frankly, this has been a shocking experience. I decided to share some lessons I learned from this saga to save y'all headache should you embark on a localization campaign.
If you develop an ASP.NET web application and you want to ingrain support for multiple foreign languages you should plan accordingly right from the start! Doing localization as an afterthought will prove difficult, if not impossible! Localization is a commitment which requires discipline to store all text in resource files which are, in essence, XML files. In ASP.NET resource files have .resx extensions and you store each chunk of text as a name-value pair.
For example, suppose you have a login screen which encourages a visitor to register. You might want to add the following entry to your resource file:
<data name="MyWebApp.RegisterPrompt"> <value>Not registered yet? Become a member today!</value> </data>
A resource file is compiled into a satellite assembly and with minimum of effort you can have you web app speak a foreign language! The whole discussion of localization in ASP.NET is well beyond the scope of this post. Please, see Walkthrough: Localizing Web Forms Pages on MSDN.
The translation services company in question seems to be well-established, and it was recommended to us by a large client of ours. We sent them our resource files for translation and what we received back was shocking.
Lesson #1: Know Thy Unicode
Make sure translators know what Unicode is. This is an obvious tip, but... Properly encoded files should have a proper Unicode Byte Order Mark (BOM) signature. For the sake of this discussion, let's assume we go with utf-8 which should be sufficient for 99% of your needs. Any contemporary text processor must be able to prepend the three-byte signature at the very beginning of a text file.
This is only half of the story, though. Our resource files were being translated into Spanish, and those folks saved translations with an ISO encoding which, quite naturally, maimed all foreign characters. When I opened them up in XMLSpy I saw Japanese kanji characters instead, while Visual Studio.NET couldn't even make heads and tails of the content.
ASP.NET is all about Unicode under the hood which is great. Visual Studio.NET works great with Unicode too, as long as it understands that a file is utf-8 encoded. I've already published some research on this subject in Unicode in Visual Studio.NET 2003.
Rationale: make sure they use software that can save files in utf-8 encoding! Ask them if they understand how to do it. Properly encoded files should be a deliverable.
Lesson #2: Apples Go In, Apple Juice Comes Out
Next, make sure they don't change the format of your files. You give them a clean, nicely indented XML file, and should expect a clean, nicely indented translated XML file back.
In our case, a large resource file was "flattened" into one line. What enraged me is that one file had HTML comments (!) injected by their software right in the middle of our text.
I've worked for a translation company before, and messing up the client's format was out of question. Why they took liberty to reformat our files I don't know. If you take your car to a shop to have the tires rotated, you don't expect them to change your dashboard gadgets with racing type ones because yours look dull.
We happened to have a couple of encoded HTML tags, e.g. <b> and </b> as <b> and </b> respectively. Translators dared to decode them back to <b> and </b> which started breaking visual representation and in the case of an open <br> tag broke validation of the entire XML file!
Rationale: demand same formatting of translated XML files. Don't take a "no" for an answer. If you have encoded HTML don't let them decode it back. They should leave it alone. Convey it to them.
Lesson #3: Know Thy XML
Make sure the translation company you approach has had experience with developers before. They must be familiar with XML. They need to have firm understanding of what validation and well-wormed mean. Ask if they use a tool capable of reading, parsing and validating XML. At least, tell them to load XML files in a web browser and make sure they display correctly.
Rationale: You give them a perfectly valid XML, expect the same back.
Lesson #4: Check Data Integrity
This is a stupid one. Once I pulled a translated resource file in VS.NET and had it create a satellite assembly I noticed that our product was 50% English/50% Spanish. I fished through the main resx and discovered that 200 lines of text were missing from the translation! Didn't see this one coming. They simply lost them. Lost in translation, so to say. :) After a follow-up email, the lost content was found on their end. Sheesh, do I really have to enforce it?
Lesson #5: Know Thy Developers
This goes with the #3. Make sure the translation services company has worked with developers. It's a whole different crowd. Translating business letters ain't the same as translating XML. It would be ideal if they had a techno geek on staff.
Lesson #6: Know Thy Real Estate
Translators need to understand they translate for the web where the length of navigation elements is very limited. "Newspaper headline" style works best.
Lesson #7: Maintenance
Make sure translators maintain history of previous translations. When you update your resx files and email them, translators should pick up and translate what's new and re-translate what has changed. Obvious, but all of the previous tips seem to be obvious at first, too.
Conclusion
Localization doesn't come easy. It's painless if you stick to the game plan and exercise discipline. .NET takes care of the rest and makes it a breeze. Yes, really. I hope this post helps you cross that bridge and saves you some hair pulling.
Any other tips from the field?
14 comments
Jonathan Font-Rubí
on February 25, 2005
Localization companies have been providing poor services for decades, even well-established companies that have good reputations.
I own Acendia (www.acendia.com). Acendia is the largest Spanish-only localization company in the U.S., to my knowledge. I founded Acendia because I noticed too many shoddy translations and ineffective product localization services. There was definitely a need for a better service.
How do companies get away with providing poor services and keep a good name? Because it takes an expert in language or localization to ferret out errors, and, usually, the companies that seek localization services have no experts in language or technology at the decision-making level. If they don't use a third party QA company, there is no way to ensure the work they recieved was acceptable. Of course, when it comes to errors in .NET and XML (like changing output escaping into written tags), the product immediately throws an error.
The localization company in question was lazy in my opinion. Localization testing should have been part of their service.
The only company I know of for hardcore multilingual .NET and XML localization is ABC Translations (www.abctranslations.com). They have done .NET/XML work for Acendia and we're happy with them. In fact, they're whole online enterprise is .NET/XML based.
- Jonathon J. Font-Rubi
Milan Negovan
on February 26, 2005
Jonathan,
Thank you for your comment. Out translation company wasn't so much lazy as ignorant in the matter. On the second attempt they did everything right, from the technology standpoint, although their translator kept changing his/her mind on a number of things. Something tells me this person hasn't done much web app localization. :)
Marian
on October 19, 2005
It is to the advantage of developers and translation companies to utilize a common interface during the localization project. Many translation companies allow developers to upload resource files or (xml files) via a portal and then provide access to the files for translators via web interface to translate the text in the files. This way it is easy to keep track of the changes in the files, allow reusing previously translated text and ensures that the resource files are always formatted the same way as original files. An example of such translation agency is www.translatorsbase.com which handles all the localization projects via web interface provided for developers and translators.
David Grunwald
on October 31, 2005
1. Our company has done several .NET localization projects, my contribution to this thread is to make sure your CAT tool can simulate the runtime environment of the app you are localizing. Otherwise, the CAT tool WYSIWYG views will not match those that your customer sees when you deliver the files, and people will be upset by this. Ask the customer what software/SDKs etc. you will need to install on your testing stations to make it look right. You can contact our company to learn more about our .NET localization project experience by going to www.global-translation-services.com.
Henry W.
on February 15, 2007
Actually, though the agencies will describe the process as overly complex or even daunting, working directly with a highly qualified freelance translator for each language (not hard to find, either!) is less expensive, more cost-effective, quicker and more streamlined in most cases than going through an agency. Particularly with computer files, it's mostly e-mail forwards, and it's quicker and easier to explain something ONCE directly to the pro who will do your translation than to risk having the message be mangled by a "project manager" who may or may not know a thing about Unicode or even know a bit from a byte. The American Translators Association searchable online database is a great place to start...because -- guess what -- all the agencies pull on the same pool of freelancers anyway. Why pay the markup?
Nico Laudel
on February 16, 2007
The http://www.elanex.biz company recommended above didn't even have the courtesy to respond to a quote request. It took time to go through my files, word counting, file uploading, etc. per their quote request. They did not respond, not even an email to say "not interested".
Sergio
on February 26, 2007
Great article.
Harihs
on July 6, 2007
Hi i am a very new learner. What i wanted to know is that how will you translate the xml file into other languages? Or how will translate the .resex file and implement in the web page as translated web page. Is it possible to convert data in the Database? I am looking for your reply impatiently.
regards
harish
Richard Harper
on October 6, 2007
Another approach which is one that I use is to store the texts in a database with a message number and language key. That way the translators get a plain Excel file which is a lot harder to screw up than a whole bunch of XML
Sally
on January 16, 2008
Hi,
At first i want to thank you for the article.
Also I wonder what types of automated translation do you use?
Milan Negovan
on January 16, 2008
Automated? None. You can't run UI through an automated translator. Can you imagine what will come out on the other end?
Jonathan Font-Rubi
on May 5, 2008
My first post was some time ago when we were "Acendia." Please note our new domain.
The best machine translation I've found for the Spanish/English combination is Google translate. The translations are decent, but they need thorough editing by a human being. You would never want to use machine translation alone for customer-facing content.
In terms of ASP .NET localization, we have found Sisulizer to be very easy to use. Translating the .resx files in your "App_" directories is easy. Just import the .resx files and look at the Sisulizer interface and you'll figure it out without even needing to read the manual. They also have a free translator's version.
Perhaps, finally, Microsoft is making localization easy with the new localization capabilities of version 3.5.
YakuYaku
on April 26, 2010
Among other points to check before hiring someone: speed of reply, translation credentials, transparency...
Great article overall!
Michael Teper
on September 27, 2004
Try Elanex (http://www.elanex.biz). I know the principals of the company personally and have done some technology consulting for them. These guys are very tech savvy (and know .Net).