LingobitLocalization On Demand DE | DA | FR | ES | IT | JA | NL | PL | PT | RU | TR | ZH
 
Software Localization
 

Lingobit Home > News
News

The Quest for Efficiency in Localization

This is a reprint from Client Side News, December 2005 Volume 5 Issue 12

Introduction

Lingobit Technologies was founded in 1997 in St. Petersburg, Russia. Two IT professionals conceived of the company as an outsourcing provider that specializes in software localization services. While working on localization projects at that time, they discovered that the existing localization tools were clearly inadequate for the tasks at hand. Although the software development environment had quickly evolved from text editor to sophisticated IDEs such as Microsoft Visual Studio, localization activities still remained quite similar to those employed by people twenty years prior. Colleagues embarked on a quest for a better software localization tool. By 1998, the company had already begun to develop its own in-house software localization tools. In 2002, it focused its efforts on developing localization software for the global marketplace. Lingobit Localizer, which was first released to the public in 2003, was born of that intensive development phase.

When Lingobit Technologies began to develop its own localization tool, there were many market players. Generally, however, they all focused on localization functionality. In contrast, Lingobit Technologies decided to focus on localization efficiency. The company wanted to develop an environment that would allow it to decrease the time and cost involved in the localization process and that would enable precise risk management.

Localization Problems

In its ongoing quest to improve the localization process, Lingobit Technologies conducted a thorough analysis of its own projects as well as the localization-related projects of other companies. The company researched localization models offered by competitors and focused its attention on the issues that decrease efficiency. To obtain process-optimization ideas, Lingobit Technologies also researched the techniques that were effectively being used in other fields to resolve similar problems.

During such extensive research, the company uncovered the most frequent problems that lead to a decrease in localization efficiency. It discovered that a hard link exists between the localization process members and a lack of project management capabilities, a lack of automatic error-finding and complicated data representation.

One of the most critical localization problems is the hard linking that exists between members. Linking doesn’t allow for the organization of an asynchronous distributed workflow, a capability that is vital for projects in which many translators and testers participate, often on different continents. This oversight leads to a situation in which members have to anticipatorily await the results of other people. Lingobit Technologies realized that it needed to remove this linking if an iterative, asynchronous exchange of results was to ensue, and that’s precisely what the company achieved. For example, Lingobit Localizer allows translators to begin working before the final software version is ready. It also allows testers to check localizability before the translation process gets underway.

Another important localization problem is a lack of project management tools. It’s customary for a project to have only two translation states: translated or not translated. Typically, the transitory translation states are non-existent. This limited capability is clearly not enough to control translation. Moreover, it is unsuitable for an iterative translation process. What’s more, generally no metrics exist to assess the volume of work and no tools are available to compare the differences between two project states. These oversights significantly complicate project management by decreasing efficiency and deteriorating risk control.

When working on a localization project, one of the most important aspects is the detection and diagnosis of bugs. A typical mistake that arises when working on localization is a lack of clear division between source code and translation errors. This misstep is usually caused by localizability testing exclusion during the initial phase of localization. After that, such errors are discovered only during the final phases, when several translators simultaneously encounter them.

This late discovery causes delays, blocks efficient testing and complicates risk control. What’s more, in many cases, the localization environment contains no tools for finding the translations that have caused the mistake. Instead, the mistake is transferred to a programmer, thereby causing an unnecessary delay in the process. If there were simple error-detection instruments, this work could be accomplished by one person, who could single-handedly find and fix mistakes.

To avoid additional such delays, it is advisable that all localization process participants are capable of building and running the localized application. Such widespread application skill allows for significant time-saving on the interaction.

Furthermore, a large number of translation mistakes that are specific to localization arise: format string errors, missing spaces at the end of strings, inconsistent translations of a single expression, etc. These types of mistakes are very difficult to find by way of usual application testing, but they can be uncovered automatically by comparing the original string with the translation string.

Another important problem that must be considered is the complicated data structures that are used in the localization process. Often, translation data consists of a lot of files. And frequently, these files are in a custom format, sometimes even in C++ source code or some other programming language. As a result, translatable elements are often not separated from other resources.

All of these issues significantly complicate project work and specifically influence the work of translators, who have to discern each file’s format. What’s more, complex data structures almost completely block out the possibility of automatic translation processing, leaving no place for automatic validation, translation or filtration. Given all these drawbacks, it’s obvious that the preferred storage solution for localization data is a single project file.

The Lingobit Localization Process

After Lingobit Technologies studied the existing problems, the company spent several years focusing on the development and improvement of a specialized process, the goal of which was to increase localization efficiency, thereby saving time and money and, more importantly, decreasing the risk of poor-quality translation. This process was a cornerstone to the ultimate solution offered by Lingobit Localizer.

Let’s consider the aforementioned process in general. First of all, let’s select the roles that participate in the process: localization manager, testers, translators and developers. Although in large projects these individuals are usually different people, in smaller projects, one person might very well be simultaneously responsible for the roles of translator, tester and localization manager.

The localization manager controls the project and coordinates other participants’ activities. The tester conducts testing and cooperates with the localization manager (receiving a version for testing and reporting about its results) and with the programmer (asking for additional information about certain errors). The translator conducts the translation of resources and is often geographically separated from the localization manager.

The localization process consists of two stages that cyclically repeat themselves when a new version is released: Preparation and Translation.

The Not-to-Be-Overlooked Preparation Stage

The preparation stage of localization is of extreme important, so much so in fact that it should not be overlooked. That’s because how well this stage of the localization process is performed significantly influences the efficiency of the successive stages. Errors missed during this stage might very well cause significant problems in the next stage. The preparation stage consists of initially preparing for project and localizability testing.

Initially, the localization manager creates a project, locks strings that are not supposed to be translated and writes comments. He or she also estimates the volume of work, taking the number of strings and elements (sized, etc.) into consideration. Finally, he or she imports translations from previous projects, existing TM databases, etc.

The two most important roles in localizability testing belong to the developer and the tester. The tester is supposed to detect errors in the program that may appear after the application is translated. He or she is also charged with finding elements that should not be translated but that the manager failed to lock. The developer is supposed to diagnose errors found by the tester. How critical those errors are to localization is estimated by the localization manager.

To find errors and resources that should be translated but have not been separated from the source code, the tester can use a pseudo-translation tool. After he or she runs the application, the tester searches for elements that were not translated by the pseudo-translation tool (i.e., those elements that were not separated from the resource files). Furthermore, he or she can find errors that are caused by the changing of localizable resources. Often, characters are not displayed correctly by a non-unicode application, so instead of Japanese chars (for instance), one sees gibberish. After uncovering errors, the tester uses Crash Finder to find the elements that caused those problems. He or she then discusses them with the developer. If the error was caused by an element that should not have been translated, that element should be locked (i.e. isolated from the translation process). If, however, the error occurred in the source code, it should be fixed according to the development process.

Translation: The Most Vital Phase

Translation is the most important stage in the project localization process. The main roles during this stage belong to the localization manager, the tester and the translator. Another key participant is the developer, who should fix/diagnose problems that were not detected during the localizability stage.

Using the exchange wizard, the localization manager sends the assignment to the translators via a single package. All information the translator requires is contained in this package.

After installing the package, the translator is ready to begin translating. During translation, the translator performs two additional functions in addition to translation: 1) he or she constantly checks him/herself using the Validation tool and 2) he or she runs and tests the localized application. Using Translation Memory, he or she can also use terminology from other projects. To control translations, the translator uses statuses and statistics. During every stage of the process, the translator can send transitory results to the localization manager, all the while continuing to work. This capability allows the localization manager to tightly control the translator.

After he or she gets the package back from the translator, the localization manager imports translations into the main branch. Furthermore, he or she can import translations from the application’s old version into a new one. Thanks to this ability, it is possible to concurrently develop and localize an evolving application. Also, it allows the localization manager to simultaneously work with several translators.

Using Lingobit Localizer’s Version and Compare feature, the localization manager can control project changes not only after translation import but also after every other action. Changed, new and deleted translations can be easily seen by the localization manger. The importance of this feature is well known to people who use source control management systems.

After checking the translations, the localization manager uses the Validation feature. This feature allows him or her to discover bugs, such as incorrect format strings, that would otherwise be very difficult to find. At any moment during the process, the localization manager can send the project to the tester for validation. There is no need for coordination between the translation team and the QA department.

After finding a bug, the tester acts exactly the same as he or she did during localizability. That is, he or she finds the elements that caused the error and, if necessary, consults with the developer. In this stage of the process, however, most mistakes are errors in translation.

When translating a new version of the application, the localization manager imports strings from the previously translated version of the application into a new one. This strategy allows him or her to capitalize on previous work. It breaks the link between the development and translation stages and allows for the simultaneous performance of two activities: translation of the application and development of it. As a result, the localization manager doesn’t have to wait for the final version of the application before beginning localization. The preliminary version is given to the translator so he or she can start translating immediately. When an updated version appears, it is sent to translator. At this point, the translator can see new, changed and/or deleted strings. Armed with this feature, one can ship his or her application in multiple languages on the same date he or she ships the application in its original language.

Usability: The Key to Efficiency

One feature that can significantly improve the efficiency of the localization process is usability. Two parameters of usability are important during localization: the speed of learning and the performance of work.

The learning curve involved is very important to localization. By nature, localization requires that multiple people participate in the process, but many of them work on the application for only a limited amount of time at significant intervals. What’s more, localization often requires the short-term involvement of external professionals (e.g., translators, native-speaking testers, etc.). As a result, it is important that the localization process decreases the learning curve by simplifying the user interface and by making it more intuitive.

On the other hand, some people must spend a large amount of time working in Lingobit Localizer. For them, the most important aspect of the localization process is work performance. Solid performance is especially important for translators and localization managers.

It is widely known that such elements as a learning curve and performance depend on usability. Because Lingobit Localizer was developed without a prior legacy, Lingobit Technologies constantly tried to stay one step ahead of its too complicated competitors. Along the way, the company’s clients continuously praised Lingobit Localizer’s interface and usability. Nevertheless, Lingobit Technologies decided to improve its interface even more.

During the preparation of Version 4.2, Lingobit Technologies began to investigate how usability influences the cost of localization. To that end, the company created several metrics and metered its users on both real projects and testing tasks. It recorded video of both first-time and experienced users and analyzed how they behaved in different situations. In the process, it discovered their behavioral patterns.

After Lingobit Technologies obtained enough statistical data to work with, the company looked into what factors significantly influence the performance of first-time users and professionals. Some of the results proved unexpected to the Lingobit Technologies’ team. After the company isolated bottlenecks, it began to search for a better solution. It studied various interface solutions in different products and in different industries.

Finally, Lingobit Technologies succeeded. It got the terrific results it was seeking. According to its metrics, the new version of Lingobit Localizer has led to a translator-efficiency increase of 32% and a rise in localization manager efficiency of 24%. Meanwhile, the learning curve has decreased by 22%. At the same time, the localization cost for a typical project has decreased by 27%.

Conclusion

In developing Lingobit Localizer, Lingobit Technologies tried to make the application maximally efficient (i.e., powerful for the localization manger, simple for the translator, reliable for the company and smart for everyone). This is why the company’s clients select Lingobit Localizer for both small applications translated into a couple of languages and large projects translated into dozens of languages. Lingobit Technologies is proud of its results and hopes to continue successfully developing its product with equal dynamics in the future.