Prepping for Software Localization Saves Blood, Sweat, and Tears
This is the first article in a series addressing the questions we see most during the software localization process. This week we’ll start with the basics, like how to set up your localization process, how to choose the right languages, and why you should translate your products in the first place.
You’ve committed yourself to localizing your software. Now it’s time to ask yourself some serious questions. Where do you see things five years down the road? Who are you trying to impress? What’s the point? Sorry, let’s back it up and take it slow.
What’s the Point? Why You Should Localize Your Software
It might be easiest to start with that last question—what’s the point?—because your process should revolve around your purpose. You likely already figured out the purpose of your software during your original development process, but you’ll want to think about it again when it’s time to implement a software localization process. If your software is going to have a global reach (or even reach everyone in the US, for that matter) you’ll want to localize your software into a few languages. At first, some clients think that localizing software will require as much work (and money) as developing the English was. But if you approach the task intelligently, adding language support can be a relatively painless process. Here’s how you can get started, one question at a time.
Who are You Trying to Impress? Selecting Content and Target Languages
As technology use becomes more widespread, global companies are localizing all over the place to keep pace with the demand. You’re probably not going to need hundreds of languages for your software, but it’s still worth thinking about who you want to reach, and how. Chances are you’ve already done some research about your target markets to decide whether or not you want to localize in the first place. But deciding to move into a certain region might not tell you everything you need to know. For languages like Chinese, you’ll have to choose between Simplified or Traditional, Mandarin or Cantonese.
If you’re releasing software in India, your users might speak English (which you should localize) . . . or any of hundreds of other languages. It’s also possible that expanding into a new market won’t require the localization of all of your software. If your product is made up of several components, you might just choose to translate the most important ones for the initial launch and release additional translations over time. You might not need the full suite of documentation if a quick reference guide will be enough to get people started (more on that in a later entry!). Translating the “highlights” of your software can also save some money and allow for quicker turnaround.
Where Do You See Yourself in Five Years? Managing Updates
When you’re in the middle of the software localization process, it’s easy to get short-sighted and only think about the next release deadline. But if you’re always thinking a few moves ahead, you can avoid getting cornered into expensive, time-consuming, tricky situations. I’ve seen it happen too many times: we start on one version of the software, and a week later there’s a new version, where half the strings we’ve completed are no longer even part of the application. This is why it helps to know in advance how often you plan to make updates, and how you want to structure them.
There are two basic update schedules that you usually hear about in translated software: waterfall localization and agile localization. In the waterfall model, everything comes at once and is delivered at the end. But what about all those updates and bug fixes your development team wants to make halfway? That’s why we’re big fans of agile localization. Depending on how frequent your updates are, we agree on a schedule and all updates are sent together. This model is easier to follow if your content is set up for translation in a way that allows you to flag deltas, so that you can simply send changed strings and ensure that unchanged strings in English stay unchanged strings in translation.
Where do I go from here?
Once you’ve thought through your needs and goals and established a roadmap for accomplishing them, it’s time to start thinking about the specifics: the little differentiators that take a well-planned software project from okay to great. Next week we’ll look at some of your best friends during the software localization process: terminology, consistency, and context.