Comparing software tools for world readiness (i18n)

I was asked the other day what the difference is between a Visual Localization Tool (VLT) , such as Passolo or Catalyst, with that of Lingoport's globalization-enabling tool Globalyzer for software development. The question has arisen during my career because some companies used Catalyst for example not only for software localization, but also for some parts of internationalization (i18n). I thought it was a good question, and wanted to make the distinction to the best of my ability in this here blog entry between Globalyzer and a VLT.

Broadly speaking, a VLT supports the needs for localization and translators, while Globalyzer meets the needs of the i18n and software development community. A VLT is very useful in providing a visual representation of what the UI (strings, menus, dialogs, etc) look like in a WYSIWYG environment. It provides translators with valuable context information to provide high-quality translations without requiring access to the source code. The tools functionality and support is localization-centric in that there is also strong integration with translation memory technology that helps companies integrate previously approved translations and terminology lists into this process. VLT’s can expose internationalization issues that only relate to the U/I such as an embedded string. This is a very limited approach to internationalization, but it can be extremely valuable for localization duties.

Specific to internationalization (i18n), a VLT is not a replacement for internationalization. Any code-base needs to be compliant in advance for the locale it is to support (Set up for locale handing or Unicode enabled for double-byte characters for example). If the code base already reflects behavioral-related inputs, such as calendar/display-based inputs based on the locale, then Passolo or Catalyst are sufficient to support companies' globalization process. That said, with complex applications, diverse development teams and rapid releases, it’s pretty easy to make mistakes regarding internationalization within source code. A VLT would only catch those mistakes if they can be demonstrated via a static WYSIWYG translation effort. This is unlikely to be even close to sufficient as an internationalization review, and even then, it would likely be very late in the development cycle. By the time code gets into a VLT for translation, it’s often already been tested and released for the software producer’s home market. That’s a very late and expensive time to be revisiting code for internationalization changes.

An example of incorrect currency and date formats based on the user's locale

Globalyzer differentiates itself from VLT's in the i18n process in many aspects. Imagine a "grammar-check" like functionality that provides managers of all i18n bugs found in the code base, from which they can allocate software developers and other resources to fix, check and test before localization. This can be done from either millions of lines of code or during an Agile process while coding new features and updates. Without a product that reports instances of i18n bugs in advance, finding them and fixing them is often a painful trial and error process.

Support extends beyond a VLT's string extraction by providing developers with the ability to check for locale-sensitive methods (SimpleDateFormat in Java is a good example, which needs a locale to format a date with the proper month and day names) and a company's unique programming patterns. Importantly, Globalyzer works for web-based applications and supports.NET, Java and many other programming languages and scripts. That way, companies can check how well data interacts with external systems and databases, such as Oracle or BusinessObjects.

In summary, it is important to understand your requirements in your globalization process and requirements for i18n support. VLT’s are actually complimentary to using Globalyzer as they improve the localization process, which takes places after i18n.

Globalyzer is particularly appropriate if: 

• Your code base is not up to snuff on several aspects of i18n and you are seeking to reduce technical debt around issues like embedded strings, dates, numbers, currencies encoding data, sorting and more. 
• You want to implement a process for developers working in teams to check, fix, and release code before localization testing. 
• Need a notion of verification and QA before and after the build process for software engineers to check files before localization.