The Internationalization Tag Set (ITS) version 1.0 has just been published as a W3C Recommendation. You can read the W3C press release.

ITS is a set of attributes and elements designed to help in the internationalization and localization of XML material. It can be used externally to the documents (a bit like the “DTD Settings” file in Trados), and it can be integrated within the XML documents themselves.

The ITS 1.0 Specification can be found here: www.w3.org/TR/its

You can find extensive examples, descriptions and links to implementations of ITS on the ITS Working Group page: www.w3.org/International/its.

The next step for the Working Group is the publishing of the “Best Practices for XML Internationalization” which is currently a Working Draft.

The Last Call Working Draft of the Internationalization Tag Set has been published.

Along with it a new document the Best Practices for XML Internationalization has also been published as a First Working Draft.

I would encourage anyone who develop translation tools that provide support for XML to review the ITS Specification document. Part of the specification addresses some of the XML localizability issues, offering a common way to specify localization information:

• what should or should not be translated,
• some terminology identification mechanism,
• identification of inline codes and sub-flows,
• localization notes,
• and more…

You can use Bugzilla to point out issues and provide comments. The review period lasts until June-30 (6 weeks).

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.

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……..