What Do We Want From Localization Tools?
Become a member of TranslationDirectory.com at just $8 per month (paid per year)
A few years ago, the preparation of certain files for translation was a task that took hours. Depending on the lot of files being prepared, it could take days! Even with a good deal of time allotted to the pre-production process, the hours spent did not always result in a project that would be free of problems during the actual production phase or the phases to follow.
Translation tools, with their constantly evolving versions, are increasingly helpful for such work as they allow companies to become even more competitive and efficient. With each new version, filters, plugins and converters are added to the core of these tools, allowing them to handle a wider range of files without requiring costly hours of manual service.
Among the existing tools designed to assist translators, also known as Computer-Aided Translation (CAT), software translation tools are the ones that have been the most extensively developed over recent years. In the area of software development, there is a wide array of tools, languages and operating systems. Each one generates and uses the most varied binary files for a myriad of purposes. This leaves localization tool developers in an eternal race to provide support for the main languages demanded by the market.
Until recently, Visual C++ was the main programming language used for projects requiring software localization. Therefore, this was one of the first languages to be supported by the different translation programs specializing in this niche of the market. Today, C++ is still widely used. However, developers and localization companies started to pay attention to other languages such as Delphi, Java and .Net (the latter two with the differential of being multi-platform languages. This, in turn, made it possible for software localization tools to handle projects that incorporated these new technologies.
Apparently, these tools will be focusing next on the support of database content translation. Currently, they are used in almost every existing program, from Internet news sites, to purchase and sales control programs, information exchange, games, etc. Databases are used in virtually all applications for which it is necessary to store information and make it readily accessible.
Few tools already offer actual support to meet this need, and those that do still need to develop this support further, both in terms of the number of supported databases as well as the translator’s ease of use with the tool. Alchemy’s Catalyst, Applied Information Technologies’ Visual Localize, and Multilizer are among the tools that already offer support for database translation.
The demand for Flash (SWF) and PDF file translation has grown. However, these types of files belong to a niche of the market that has yet to be explored. Localization tools run into a technical problem that prevents them from supporting these files: their formats. Both are considered “final files,” designed for publication rather than editing, a fact that makes it impossible for the user to directly translate the text in the file.
Recently, some new alternatives have appeared to assist with the translation of PDFs, since the client does not always have (and actually almost never has) the source file from which the PDF was created. These are basically tools that use the OCR (Optical Character Recognition) principle to convert the PDF file into a translation-friendly format, such as XML or RTF. However, there are still several problems relating to the proper maintenance of the formatting, layout, distribution of graphics in the body of the text, and especially, the maintenance and organization of tables.
Flash files are even more problematic because the FLA file, which would correspond to the original of the PDF, complicates the task of extracting the strings for translation. To extract these strings, the tool must be able to parse the entire internal structure of the FLA file because the texts might be located in different scenes and layers. In the absence of a tool with this capacity, a possible solution would be to create specific macros to extract and re-insert the strings using the Flash programming language, called ActionScript. This macro would allow the user to access the dynamic text boxes using an ID that would identify and access the dynamic text box object. However, because most texts in Flash are written in static text boxes, ActionScript cannot access them, thus destroying the potential efficiency of this solution.
With the development of Tramigo, Avral was one of the first companies to propose a solution for the localization of Flash (FLA and SWF) files. This tool, however, has the same limitation described above: it is only able to translate dynamic text boxes. In other words, if the author of the original (FLA) file is not concerned about the later localization process and decides to use static boxes, string translation can only be done by extracting and re-importing the strings manually. This means a highly time-consuming job, especially if the task involves only a simple analysis or project quote.
The future of software localization tools is in the hands of God and of those companies that develop them. We localizers and engineers are responsible for observing the trends and exposing the day-to-day difficulties that we find in these tools to company developers so that they can continue to improve them. This is the only way we can all contribute to the evolution of the localization market.
This article was originally published in Сcaps Newsletter (http://www.ccaps.net)
E-mail this article to your colleague!
Need more translation jobs? Click here!
Translation agencies are welcome to register here - Free!
Freelance translators are welcome to register here - Free!