5 tips for a smooth localization process

Localization is a process of adapting your product documentation to a specific region or country. That means not only translating from one language into another, but also making sure the content is culturally appropriate for your intended market. As a result, when users interact with your product, their experience is perfectly adapted to their preferences and customs. That’s great for your business – you can access a wider customer base, increase your brand recognition, and make sure new users have a great customer experience.

However, the localization process is not without challenges. There are many factors to consider, from the resources needed to make it happen, to making sure your localization design meets internationalization requirements. If this sounds like a lot to think about, don’t worry – help is at hand. Here at 3di, our team of technical authors and coders deliver award-winning technical writing and localization services. This means we’re uniquely placed to identify some of the key challenges of localization. To give you some pointers for tackling those challenges, to save yourself a headache. So, keep calm, and carry on reading our localization team’s top five localization tips on how to help plan and prepare your content so your localization process runs as smoothly as a Swiss watch.

1. Planning prevents poor performance

Our first tip is to treat localization as an integral part of your design and production processes. This reduces both the time your product takes to get to market, and your development costs. On the other hand, treating your localization process as an extra step after your software development process has finished means you will end up with an already outdated cascade model of localization, where each phase is held up waiting for the previous one to finish.

As the old adage goes, “Planning prevents poor performance”, localization works best when it’s planned as part of your product development. Localization on an ad-hoc basis is not advisable – it’s likely to increase both your costs and your blood pressure!

Another challenge with localization is that it’s an ongoing process. This is because tools and cultural references change, programming environments may start using different concepts, and new devices are regularly being released. Ultimately, it means the job is never done, and being conscious and vigilant is a must.

Remember, localization is not a fire-and-forget process. If it’s done correctly, your localization design will generate valuable resources you can use in the future. For example, you can store your translated content in smart databases called ‘translation memories’, and automatically reuse that stored content for future iterations of your product. This way, you’ll never have to translate the same content twice. Another plus is that a professional localization process generates a crucial feature – stable and predictable translation quality.

2. Localization by design

Today you may want to translate your content into Spanish, but tomorrow – who knows? We live in a global world, so we all need to be ready to go global. What does this mean for localization? Well, don’t design your content for just one market.

The key term to remember here is ‘internationalization’. And what’s that? Well, it’s all the engineering that takes place before localization of your content, and allows the latter to happen. The key takeaway here is the sooner you think about localization, the less costly it will be. The alternative is that localizing your content could become prohibitively expensive. And here’s an even greater consideration – you end up having had to re-design a product just before a planned release because localization was an afterthought. It’s probably the worst thing that could happen to any software development company. So, our tip here is to just treat localization as a natural step in the design process before you even start writing code.

The great news is, there’s no need to reinvent the wheel. The big players have already been there, done that, and probably got the t-shirt! They failed with some products, learned from those experiences, and decided to implement crucial rules for designing and implementing localization as part of the product development cycle. There are plenty of readily available guidelines you can refer to on your internationalization journey. Honorary mentions go to:

• https://docs.microsoft.com/en-us/windows/apps/design/globalizing/globalizing-portal
• https://www.ibm.com/docs/en/i/7.4?topic=globalization-checklists
• https://developers.google.com/international

Also, when your content is properly internationalized, you can avoid producing localized versions with inappropriate cultural references and graphics. This will also allow for text expansion, provide full Unicode support, offer proper fonts, and much, much more.

3. Consider your strings

Your source code is the secret sauce of your product. That means you certainly don’t want to have to share your source code externally to get your content translated, and you most definitely don’t want to bother your software developers with having to recompile the source code every time something like a dialogue box message is changed! Hardcoding is one of the worst code practices you can think of, so let’s start with a simple rule – do not define strings within the source code.

Strings are variables that are used to store and automatically display text, such as warning messages, dialog boxes, and menu items. Strings are often used to automatically display on-screen messages because much of the content is reusable – although a file name or file size may change, the same window can be used to list the files. So you will need to use strings, but only by referring to them as keys or string names. By referring to a document or function that will return a proper string, you will be able to dynamically display the text on the right screen of your application.

Each software development environment uses its own format for managing resources, but the general rule is:

• The resource is in a separate file in a known format such as *.resx, *.properties, *.rc, *.strings.
• The resource can be processed without touching your source code.
• The resource stores key names along with values and text.

4. Room to grow

Most popular translation variants end up with longer target text when compared with the original text. Yes, sometimes texts can be shortened, but for user interface options this can mean your product becomes clunky, and what’s worse, difficult for the user to operate . That’s why it’s important to think about text expansion when you are creating your content. Unfortunately, when truncated text is detected at the very last stage of the localization process, it may already be too late.

Leaving enough space for text expansion will also reduce the time needed for proper publishing and DTP. It means your content will be suitable for localization regardless of the target languages, or to be more specific, target locales. So, how much extra space should you leave? The safe margin is around 30%. Be extra careful when you are close to a page break. For certain target languages, it may be better to break a section earlier in anticipation of the text possibly moving to the next page.

Bear in mind this applies to graphics as well. Leaving enough space is important if the text is on a separate layer, or leaving a solid background if the text is embedded in raster graphics. Preparing graphics for localization generally has three rules: keep it short, keep it on a separate layer, and make sure the font used in the graphics also exists in your target languages. Also, whenever possible, avoid using large amounts of text within multimedia content. Text within multimedia content is much more difficult to fix than standard text.

5. Use existing tools

Ultra-fast development processes and total access to all specifications. That’s the world of a modern software developer. And yes, localization is just a phase in the bigger picture, so it is understandable developers may want to implement a quick and painless solution.

Unfortunately, this approach rarely works with translation. Please, don’t think about creating ad-hoc translation tools that could inject the strings into your software. Just don’t. In a worst-case scenario, you could end up with a terrible in-house editor for overwriting the strings into target languages with no context whatsoever, and alphabetically sorted resources. We strongly recommend you don’t go along that path.

Localization is now an IT-friendly space, so don’t try to solve a problem that has already been solved. Translation tools have been around for over three decades, and nowadays nearly all software formats are correctly processed, parsed and protected. Translators have also learned to work with tagged content on a daily basis. There are data formats available for multilingual content and most of them are XML-based and can easily be parsed. And if you hate XML at this stage – just use JSON, properties or resx/resw. All of them can be used in translation tools, safely translated without corrupting the code elements and special characters, and saved with no issues.

Furthermore, copying your content to Excel is simply unnecessary. It creates additional manual steps that are prone to errors. Using existing translation tools means your required formats can be processed directly, and sometimes can even result in additional contextual information being captured that improves translation quality.

Sounds like a plan

When you think about it, the conclusion is simple – a smooth localization process needs proper planning. And proper planning means avoiding costly errors further down the line. So don’t waste the opportunity to plan your localization accordingly. There are many established processes and guidelines that can help you, and don’t forget about our five localization process tips that are a great way to hit the ground running.

If you think you may need a professional localization partner or perhaps a localization-readiness audit, we can help. At 3di, we can translate content into virtually any language – some of our customers’ projects involve deployment to more than 30 target markets. Plus, by applying our ISO9001:2015 registered quality management system, we ensure you get a quality result no matter the subject or language. To find out more, why not get in touch with us?