Why Does Localization Take So Long?
Part 1 in a Series: Optimizing the Localization Process
1. Why Does Localization Take So Long?
2. Why Is Localization So Expensive?
3. Can’t Linda in Accounting Translate It?
4. I Just Need “Hey, Baby” in Twelve Languages. What’s the Holdup?
Localization has the potential for delays, it’s true, but actually, for a process so important and complex, it’s amazingly fast. But you can make it even faster for your company. Imagine this scenario. It’s about software development, but you can substitute any project that requires translation.
You’re the project manager in the big meeting room for an emergency scoping session. The VP wants to create a new product and launch it in six months, just in time for the trade shows. Your software team says they can get it done with twenty developers full time. That’ll be expensive, but at least it’s doable.
Then the localization manager speaks up, and you dread her pessimism. She’ll demand weeks at the end of the development cycle for translation and review, and she’ll want developer time to argue about fonts and to set up test harnesses for translators. You’ll never the launch on time!
But the localization manager surprises you. “That’s an aggressive timetable, but I think we can make it work. Let’s talk briefly offline to plan it.”
What did she say? She thinks we can make it work? Frankly, even you don’t think it can work! You and the bigwigs had actually sort of forgotten about localization in your planning. There will be a couple thousand strings of user interface (UI) and about fifty topics of user assistance (UA). How could it work?
Integrate localization into development
The localization manager will tell you offline that she can deliver on time if localization is integrated into the software development cycle rather than tacked on at the end of it. Here are the key concepts in the strategy.
Prepare your LSP
Leverage the work you’ve already done with your language service provider (LSP). Work with them to update the glossaries and style guides. Train the LSP in the new product features. Have them scope the project and line up preferred translators. Discuss potential cultural issues and concerns about the design. Draft a schedule, considering international holidays that will affect translators’ schedules.
Share feedback with the software developers right from the start to minimize bottlenecks later.
Translate in batches
Translate as you go. You know you’ll never really have a code freeze, so don’t wait for anything to be final. Translate and implement early, as soon as you have a dozen UI strings or a roughed-in widget. You’ll get good quality from your translators because they won’t be overwhelmed by the volume and racing the clock. They’ll ask good questions because they have time to, so they’ll understand your product, and they’ll use your company’s style guide and glossary to help them deliver right tone and terminology. And their feedback will help smooth out issues with user flow.
As soon as the LSP delivers the first localized batch, you can start review. Remember that last project when you couldn’t get the review finished before launch? This time, you’ll be reviewing all along and improving the quality with each batch.
Keep a regular cadence—say a batch every week or two. Never rush. When you hurry localization, translators won’t have time to ask you questions, understand your product, or abide by your style guide. Terminology and tone will be inconsistent, and you’ll never quite recover.
Get buy-in from the developers
Software developers don’t like last-minute changes requested by translators, but they do want users to have a great experience. So tell the developers early the questions that translators are asking and where they’re having trouble. Developers like explaining their inventions, and they like optimizing them. They’ll be happy to explain the context better or deal with date formats and fonts—as long as it’s early enough.
Deliver a localized batch, and ask to see it in context in a development or staging environment. Tell the developers what works well, not just the concerns. Developers are proud of their code, and they want it to work in every localization, so keep them involved—not hassled, but aware of how it’s coming along. Sure, they’d rather have the translator shorten the text instead of having to edit code widen a button, but you’ll work that all out. Everyone wants what’s best for the user.
Review in market early
Get review at every stage by stakeholders and by native speakers in the target markets. Stakeholders would delay reviewing till just before launch if you let them. Instead, demand sign-off with every batch. That keeps all the creeps at bay (scope creep, quality bar creep, and concept creep).
Make sure you have linguistic reviewers in the target markets who can see the text in context. They’ll know current business lingo, and they can assess whether the text sounds natural and savvy, and whether the layout is acceptable.
Know your target markets
If your Japanese text is slightly awkward or foreign sounding, your brand will take a hit, and if there are grammatical or typographical errors, you may not get a second chance. Besides that, Japanese translators require more context, and they’ll want to provide fuller descriptions and more detailed instruction for the users. Japanese reviewers will request more changes than other reviewers. You can’t rush Japanese. Consider launching the Japanese localization later than others.
Arabic-speaking markets may have more cultural constraints than some others. Translators and reviewers may want to change the tone and terminology. And you can count on issues with right-to-left orientation and with ligatures. Give Arabic the time and attention it requires.
Every market has its unique opportunities and pitfalls, but savvy in-market reviewers will guide you to success.
Plan for on-time delivery
Localization takes longer when you hurry, so plan well and communicate constantly. Done right, localization can be proceed at a quick, comfortable pace in the development life cycle.