|
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 phrase 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.
Another
topic that has not (or had not) received the attention it
deserves is the effective support for Web programming languages
such as JSP, ASP, ASP.NET, PHP, JavaScript, VBScript, etc.
I sincerely believed that this support would only be available
in the more distant future, but this scenario began to change
with the introduction of ABLE Innovations’ WizTom for
the Web – one of the first tools to offer direct support
to this segment of the localization market.
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.
|
