Jumping Off the Software Localization Cliff in 8 Steps

Software localization can prove to be empowering, rewarding and, more often than not, a fun process. At second glance, it can also be more sophisticated, demanding and delicate than originally anticipated. What’s the secret behind it? Just like base jumping off a cliff, it's all about preparation. Read 8 steps that will prepare your software for localization, making the process fun, rather than overly demanding.

In a way, software localization is much like base jumping. When you see those guys diving from a clifftop at 100 mph and gliding over razor-sharp rocks (search for “wingsuit base jumping” on YouTube if you don't know what I'm talking about), one could imagine that it takes an impeccable technique, top-notch equipment and lightning reflexes to survive the jump. No question about it. Nonetheless, none of those traits mean anything without proper preparation: familiarizing with the jump spot, calculating trajectory and speed, studying wind flows and even checking for the presence of nearby birds are all critical steps to make a safe jump possible.

Even though no single localization expert has ever had to worry about the risk of running into an imperial eagle during a project, with localization preparation is also key. Understanding the project requirements, defining the workflow, processing source materials, and planning and allocating resources will allow you to not only establish the momentum required for success, but also to identify all potential risks and countermeasures even before making the “jump”.

When the time comes and you are ready to start planning your software localization project, here are eight considerations that will help you set the path to a successful project:

1. Women, Children and Internationalization First

When talking software, “internationalization” (often shortened to “i18n”) is the process of making a product localization-ready at the code level, ensuring that it could “speak” other languages even if it doesn’t already. If you develop your product with only English in mind, you will find yourself struggling to support the particular traits of every other language you add later on, such as non-Latin characters, right-to-left text, local currencies and date formats, and the like. Be smart and take care of internationalization as part of your product development, while it’s still cheap. Fixing internationalization on finished software will be exponentially more costly.

2. Freezing Source Code and Assets Prior to Localization

Whenever possible, put the original source code version on a feature freeze. Stop adding new features so that the localization team can work on fixing any existing issues, while development focuses on other parts of the code. This is important to ensure the stability of the product, and that any changes made during the pending localization process do not unintentionally feed back to corrupt the source version. As any developer would tell you, it is paramount to be able to return to the master version if things ever go wayward, and the localization process is no exception. A minor mistake such as a missing variable, an encoding difference or a broken tag can easily lead to hours of debugging overhead.

3. Seeing the Light at the End of the Project

Give consideration to the launch details of the software product. Are all versions to be launched at the same time or staggered according to a specific schedule? Either way, definite dates and milestones should be used to establish rigid deadlines that will help keep the project on track.

4. Keeping Ahead of the Budget

Of course, an essential ingredient to preparation is a budget plan for the entire process. This particular plan will determine how much time is spent and which techniques and resources are used at each stage of the process. This is one of the most delicate parts of your overall plan, since lack of budget may bring you to a full stop. Plan on twice the number of unexpected hurdles and calculate your budget accordingly.

5. Preparing Teams and Tools

Once the project schedule has been established, team members and resources should be assigned to the process. Naturally, this will include any software tools that will benefit the process. Here decisions should be made on exactly what skills are to be utilized and what tools will be required. Internal native speakers can be an asset in ensuring that translations are correct and in context. Project management and bug tracking software will keep the process on course and document any problems that may arise.

6. Getting the Product Itself Ready

Once a schedule has been produced the software itself needs to be prepared. This requires thought about all aspects of the product, and best practice is to divide it into smaller components that are more easily managed. Focusing on core pieces and features first, and then extending to those optional or less visible, will ensure that the worst issues are detected and cleared off early. The moment one piece is pretty much rounded up, you will be able to also start working on the help and documentation related to it with less fear of regression and duplicated work.

7. Drawing Up the Battle Plans

It’s now time to roll up sleeves and produce a detailed localization plan. In this plan you should:

• Take a deep breath and review the state of the product. The product may have changed during the completion of the previous steps, and you must be aware of any such changes while drawing up the localization plans.
• Estimate the chain reaction potential for any changes to be implemented. Determine the best order in which such alterations need to be conducted, as failure to get the sequence right could result in confusion when the product fails to respond in the expected manner.
• Determine which team member is delegated to which task, how much time they have, and what tools and resources they have at their disposal. If you are in an Agile development environment, make sure that the localization team is not only part of the product team's SCRUM meetings, but also that they are deeply intertwined in the team dynamics (or even better, make the localization team part of the product team!).
• Find out where you stand: Produce a pseudo-localization and evaluate the results. The team responsible for internationalization must have done the same before, but after so many changes, you should check again. Pseudo-localization is easy, inexpensive and probably the most useful self-assessment tool out there.

8. Testing Your Testing Strategy

Three don’ts for your testing strategy:

• Don't wait until localization is done to plan for your testing.
• Don't assume that your nightly builds will just work fine with the localized versions of the product.
• Don't assume that your expert testers will figure out how to deal with languages they don't understand or aren't even able to identify.

Work with the localization guys at your translation agency to anticipate the most outstanding difficulties and plan your strategy to make sure you'll have the right people and resources when the time for testing comes. Then, review your budget to see if adjustments need to be made (in-house or outsourced? test all releases or only a few? test UI only or documentation as well?).

Have Any Questions? Ask Us, Software Localization Is What We Do Best

Don’t base jump off the localization cliff without talking with the experts. Venga Global specializes in software localization and translation and can provide solutions for all your localization project requirements. From planning to testing, our team of specialists will be happy to assist you with the preparation of your project and put you on the right track for success.