How We Fixed an Internationalization Fail

Many savvy people in the localization industry have felt the pain of localizing a product that has been poorly internationalized. If you are not familiar with internationalization or have a vague concept, then I encourage you to look up some of our articles targeting i18n specific issues and how to avoid them in the first place (see below). In brief, internationalization is a critical part of your design or blueprint to create translated versions of your product. If your design is poor, then you will spend a lot of extra money accomplishing your final goal – to bring your product to foreign markets.

While we would like a perfect world, the reality is often that it is somewhat messy. The reason is that there is still a significant lack of focus on the need for internationalization. What we end up with, at times, are products sent to us that take a lot more localization work than necessary. The ideal solution would be to resolve all internationalization issues by sending the work back to the developers, which may in some cases be the only choice. However; in some situations we can offer a solution to help avoid tying up your critical and expensive resources and help you also maintain your project timeline.

You likely do not have the luxury of additional budget, or the time to go back to development and testing to get it right. In some situations, we can solve the issues for you by developing clever automation to help avoid repetitive tasks and resulting high costs on localization as seen in our case study below:

Situation – Translating strings of a poorly internationalized product in Microsoft Excel

First off, Microsoft Excel should be your very last choice as a vehicle to localize strings. Sure, you likely came up with very nifty scripts to export and import strings into your product but – for many web apps, applications, and especially mobile apps – there are specifically designed and proven methods and file types to extract localizable content for translation. If you have more questions about what a proper method or file type should be for your product, contact us.

That said, at times Microsoft Excel may be your only option and you are stuck with it. In this case a client came with extremely large Excel files; 14 files to be exact. These files had many sheets, and also had over 10,000 lines of data filled in some of the sheets. Unfortunately, the files contained obvious and not so obvious code elements and non-translatable content.

Analysis – What to do when you must read between the lines

Having code elements and non-translatable content in a file is never ideal. In fact, the more those content pieces look like translatable content, the higher the risk that they would be translated by a translator. The reality is that linguists are generally really good when it comes to translation, but they are not always good at figuring out what they should and should not touch. In truth, it is not their job. If such content is translated, it could break product functionality and lead to a myriad of issues that are difficult to debug. At this time, you should be seeing a mental image of a large collection of dollar signs. After our analysis of the situation, here is what we determined:

• There was absolutely no time for the customer to go back to their product development team to have them fix a very large number of issues in their hand-off.
• These files were going to come to us on a regular basis for updates and content translation. With thousands of lines of information, we estimated approximately 16 hours of Engineering time to remove or protect non-translatable content in just one of the 14 files. So, the total processing time would have been 224 hours every single time these files came in for translation.
• The customer was using a 3^rd party translation solution and we had no access to the parsers to be able to adjust those or be able to define specific rules to help avoid translating content that should not be translated. Furthermore, the complexity of filtering the content was generally beyond that of what modern CAT tool parsers provide.

Solution – How our solution turned an internationalization nightmare into a high-five moment

We decided that a more custom automated solution would allow us to take a 224 hour job and turn it into something that could be completed in a fraction of the time. Much of the content had to be dealt with differently across several sheets. We also had to exclude specific sheets from translation and manually preparing the files every single time just did not seem like our kind of fun.

We custom-developed an automated prep tool that could work on a collection of Excel files and prepare them by scanning and protecting content that would never be localizable in this product:

• Predefined non-translatable content
• Very specific words within the content of the file even if it was just part of a cells content
• Content beginning with a lowercase character
• Content that has an underscore character anywhere within a cell
• One or more numbers followed by a word
• Any string with a sequence of space + dash + space + one or more numbers
• Content with non-Latin or non-punctuation Unicode characters
• Several tabs that needed to be protected from translation

Our automation had to also be able to finalize any translated deliverables by reverting our protective measures and ultimately creating clean, fully localized Excel files with all non-translatable elements intact. The final objective, of course, was that these spreadsheets would have to import back into the product and most of all not break the functionality.

Result

PTIGlobal’s solution ended up taking seconds to run. We added a minor amount of one hour for each file to validate the automated preparation to ensure the tool was performing as expected, but with a mere 14 hours on the front-end and 2-3 hours at the tail-end we reduced the anticipated processing time by 92.4%. Even better, the entire round-trip process was a complete success on the first try and we had absolutely zero glitches with imports or functional defects after localization.

Conclusion

Our team are experts at finding solutions and often pick up where other teams fail. To be clear, we are a big advocate of proper internationalization of your products and i18n should be a critical part of your design process from the start. With PTIGlobal, you have a partner who can help turn a nightmare into a positive experience.

To learn more about how PTIGlobal can help transform your global content strategy, call us at +1 503-906-6512 or email us at getstarted@ptiglobal.com.

Related Articles for additional reading on i18n, please visit:

https://www.ptiglobal.com/2018/06/13/create-localization-friendly-adobe-indesign-documents/
https://www.ptiglobal.com/2018/04/26/the-beauty-of-unicode-zero-width-characters/
https://www.ptiglobal.com/2018/02/06/internationalization-not-optional/