GALA Blog

ITS (http://www.w3.org/TR/its/) is a set of elements and attributes that supports the internationalization and localization of schemas and XML documents. This first draft addresses the following type of information (called data categories in the document):

• translatibility
• localization information
• terminology
• directionality
• and Ruby text

For example, ITS provides attributes to identify within your XML document parts that should not be translated, or words/phrases that should be treated as “terms”, as shown below:

<para>
And he said:
You need a new <span its:translate='no'
its:term='yes'>motherboard</span>.
</para>

Each data category can be used in schemas, in-situ (within the content), or dislocated (defined somewhere else than where the corresponding content is located). XPath is used to provide all the scoping mechanism.

I think it is important for the localization and translation tools vendors who are not part of the ITS working group to provide feedback on this draft, so the final version of ITS can be well-suited for their applications. You can send your comments to www-i18n-comments@w3.org. Use Comment on its tagset WD in the subject line of your email. The comments archives are publicly available.

I recently learnt about the release of a beta of Windows Workflow Foundation, a .NET library which is currently in the works both for Windows client and server operating systems.

Among other more sophisticate possibilities, workflow can be sequential, which to a large extent means that the computer is in charge and outsources some tasks to human beings, or state-oriented, which means that the human beings decide the actual transitions from state to state according to their own judgment and the role of the computer is basically to limit the acceptable transitions for each state and track the status. But this is probably easy to say but awkward to code in a model that gives the level of flexibility that LSPs need. Hopefully this library in the pipeline comes to help to make it simpler for developers.

The RTM (Release-to-Manufacturing) version of this framework is still a few months away, but I think that its mere existence increases significantly the chances that both Tool Vendors consider workflow in their product roadmaps, and other existing frameworks (or future copycat frameworks) empower developers so that they can add more features to their tools.

In the localization tools market there are a number of organizations which deliver various localization and translation tools.

They all focus on specific areas of localization which in general has been driven by the localization needs of clients at the time they were designed.

As soon as documentation translations became a requirement the tools to enable translations of this type of material started surfacing.

In general the same applied to software localization tools and localization project management applications which have been designed and released following the huge demand to be able to control the localization process in better way.

Based on your requirements you will find that the commercial available tools will fit a number of more or less independent groups.

o Tools which will handle your Software localization requirements.

o Other tools which will take care of your Documentation localization requirements.

o Tools which will handle the project management side of your localization projects.

o Tools which will limit the translation cost by reducing documentation source material, and the typical single source
publishing tools which are available in a number of different flavors.

o And the tools which will focus on Machine Translation.

Depending on the organizational structure and translation requirements your will find that in most of the cases the difference in translation requests can’t be covered with just one tool.

The functionality and file type support is not matching your requirements, so it will become clear that if you decide to purchase you’ll need at least two or more tools to handle your projects.

As a result a number of large corporations decide to figure out if there would be a possibility to design and develop localization software internally and fill the caps between the commercial tools available on the market, and the requirements they had internally.

Many organizations have followed this path and have build tools varying from simple batch files on one side to highly complex and fully integrated localization solutions on the other side.

But what are the drawbacks of that approach ?

Wouldn’t it be much easier to discuss your requirements in the BLOG and let us (Tool Vendors) know all about it ?

We may be able to deliver the Solution……..