Software localization, or L10N (as I like to call it), is a rather esoteric discipline within software development. While not an exhaustive guide (hey, we don’t just give those away), below is a kind of starting point- a checklist – for a software team approaching localization for the first time.
Scope the Project
I was once consulting with a financial software vendor that had a rather sophisticated Excel plugin product that they wanted to localize to Japanese. Presented with only screenshots of the original English, I was immediately asked how long it would take to QA the Japanese version. When I told them it would depend on the scope of the localization, the VP, rather impatiently, responded with, “What’s there to know? We’re just translating the UI!”
“Well,” I said, “there’s more to it than that. For instance, these column headings: will they be localized? I noticed that the function argument names and the column headings happen to match. If we translate the column headings, will that break the functions? Will company names be displayed in Japanese or in English? What if a Japanese user saves a report in Japanese and then opens it later on an English OS? What about date formats and sorting?” At this, the VP replied, “We’ll have to get back to you on that.” Yes, please do. It’s kind of important.
I can’t stress this enough: Localization is a feature like any other software feature, and as such it requires a detailed spec. You wouldn’t add spell-check to your word processor without a requirements document, would you?
What should be in your localization spec is a topic for another article, but in short it should describe how your application will behave in the target language, what will be translated and what won’t, and functional changes to support the target locale. If this is your first time localizing, then you should also think about things like language preferences.
These decisions shouldn’t be made in a vacuum, though. Your requirements need to be validated by the target market. Be sure to involve them early in the process. Will they accept your product if the company names are still in English? Don’t assume that they will and ask them up front. Think of how awful it would be if you spent a year localizing your software to Japanese, only to have the Tokyo sales guy tell you, “I can’t sell this. All of the company names are in English!” Countries, and even market segments in those countries, differ when it comes to tolerance of English in their software.
One more word on requirements: internationalization and localization force you to make a series of decisions about how your application works at a fundamental level. And like any software design change, the longer you wait the more it costs. Invest the time in design, early.
Understand the Costs
You can think about localization costs in terms of internal vs. external, and one-time vs. ongoing.
Internal:
- Development: modifying the code to support language X, fixing bugs
- Product/Program Manager: owning the spec, prioritizing work
- Project Manager: coordinating translation handoffs/deliveries, scheduling vendor work
- QA: regression testing the English, coordinating the localization testing, preparing localization test cases
- Documentation: refactoring the English docs to be more localization-friendly, maintaining the glossary
External (perhaps partially internal):
- Translators: translating the UI and documentation, localizing the graphics
- QA: checking the translations in the context of the application, performing localization QA
- Developers: if this is your first time localizing and you need to a lot of internationalization work, you might hire specialists to take care of this
It is important to note that while development is mostly a one-time cost, translation, QA, and some project management overhead will be ongoing. Depending on the frequency of your releases, you can expect anywhere from 10%~30% of a translation delta with each upgrade, while QA costs will be roughly the same each time around.
Internationalize your Documentation
While documentation is an afterthought for most software developers, especially in the enterprise space, translation of online help and other user manuals accounts for most of the external costs of a localization project.
Do what you can to streamline your documentation. If you have a lot of repeated content, look into implementing a CMS to promote content reuse. Try to reduce the number of screenshots in your manuals. Localizing screenshots is time-consuming, expensive, and will eventually lead to heavy drinking. Keep screenshots to a minimum. Don’t try to be too clever with your writing. This isn’t The Great American Novel, and you’re paying for translation by the word.
Think Hard about Process and Change Management
Development is iterative while outsourced translation is more waterfall-y. You need a way to deal with this mismatch.
Can you easily identify strings that need translation, at any given point in time? What if you send out “This is a pen” for translation, and later you change the English to “This is a pencil”. Will you be able to tell which translations are out of sync with their sources?
Can you tell which graphics are new/changed? How about help topics?
Lastly, how quickly can you turn around localization bug fixes? Things like layout bugs often require some back and forth between developers, translators, and testers. The shorter your translate/build/test cycle, the better.
Don’t Forget about Testing!
Since we’ve already established that localization is a feature like any other feature, then surely we can agree that it should have dedicated test cases, right? Are you with me, fellas? Now, living in the real world, I know you probably can’t write test cases to coax out every measly error message and alert window. Do your level best to get as much test coverage as you can, even if it’s just an application walkthrough. And remember: that detailed spec you wrote earlier will really help you here.
Whatever you do, resist the temptation to simply dump all your functional test cases into your localization tester’s lap. Not only will they confuse your poor bilingual tester, but they will cost a lot of money! Scoping a localization test is like peeling a potato: it’s mostly just about the skin, but sometimes you have to cut in a little deeper.
Find a Good Translation Vendor
This is a huge topic in itself, but here are some guiding principles:
- Make sure they can handle your file formats.
- Responsiveness is key. You don’t want layers of bureaucracy between you and the people on the other end doing all the real work.
- Avoid vendor lock-in. Make sure you can get your translation memory from them at any time and take it elsewhere.
- Biggest or cheapest is not always best. You’re looking for quality, not quantity. Bad quality will kill your project. Trust me.
Make Sure Everyone is on Board
Your goal is to deliver on-time, with quality, within budget. To do that, everyone in your organization – project management, product managers, development, QA, docs- they all need to get with the program. Again, language support is a core feature of your application, not some wacky separate branch that everyone wishes would just go away.