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

Sometimes I feel that I am losing my sense of direction in that proliferating thicket of technologies, programs, workflows, releases, processes, updates, tools, routines, patches, exceptions, fixes, and if none of these work - workarounds.

Usually I come down with something, then: a mild bout of toolitis, or a little fixema - nothing serious, really.

Time for recovery is also time for reflection and recollection:

There really was that charming turn-of-the-century “challenge to the world community to bridge language barriers by developing technologies with real-time digital translation so anyone on the planet can talk to anyone else” (albeit by a presidential candidate).

And Arthur C. Clarke (of ‘2001: A Space Odyssey’ fame) really did set the ultimate benchmark almost half a century ago:

“Any sufficiently advanced technology is indistinguishable from magic.”

I haven’t quite regained my sense of direction, but at least some of my immoderate sense of proportion.

Anybody else with a thirst for magic?

I’m not a blogger (as I said at the panel discussion) but I’m going to blog the way I think you’re supposed to… write what you feel like when you feel like it.
I just heard about an opensource tool that lets you share your mouse and keyboard over TCPIP….and it’s platform independent. So you can have a mac, a pc, and a linux box each with a monitor attached, but only one mouse and one keyboard interfacing with all 3 (and I’ve heard it shares the clipboard, so you can cut and paste between screens/computers). Haven’t used it yet, but a friend of mine says it’s great. http://synergy2.sourceforge.net/index.html. I’m always dealing with cross platform issues, and this should be time saver.

In the past, we were very reluctant to make generally available some internal tools that we used internally, but a couple years ago we decided to give away as freeware a couple of tools that were very important in our process: Xbench and Comparator.

Since ApSIC is a localization provider for Spanish, our greatest concern was that our direct competitors would benefit from them for free, but it turned to be the other way around: our competitors are more reluctant to use our tools than anyone else!

We discovered that, in fact, releasing freeware had many upsides for our own performance as a language provider. Those who develop your internal tools know that normally internal tools are smart, but consistently quick and dirty in the execution. They are very vaguely documented - if at all - and the interface often needs to be demoed to new users so they get started with it.

By releasing freeware, we have been able to make great improvements in performance, documentation, and ease of use for the tools that were very important in our process. This effort translated into either many saved hours and/or more quality for the outcome of our employees and vendors.

If we had not released them as freeware, we probably would still use them, but they would not be as fast, clear and ready for our own users.

Another great benefit was that since both Xbench and Comparator are tools for quality-oriented people (in the areas of extreme consistency and traceability respectively), the e-networking achieved supporting them has been also very positive, as also valuable were the bugs or suggestions reported by the community of users.

Currently, we continue to enhance these tools and plan to continue releasing updates to them with additional functionality in the future.

If you also develop in-house tools, I encourage you to consider the freeware channel as a way to raise the bar of your own tools. The instant benefits are great improvements in your own process, more visibility both from your clients and resources, and who knows, maybe the tool can eventually become or be part of a commercial offering, or ‘grow up’ as an open source tool if it happens to make business sense.

At the Localization World conference last week in Seattle, this topic has been identified as one of the “hot topics” in the industry at this moment. There have been controversial discussions about buying an off-the-shelf product (such as LTC Organizer or project-open) or creating your own tool, which suits the needs of the company best.
In the Technology discussion group at the GALA Annual Meeting, we have decided to pick up this topic and start a web blog on it.

We therefore welcome any comments you have regarding this topic, or any experiences you would like to share with the rest of the world:

What tool are you using, what are the pros and cons from your point of view?
Did you create your own tool, what are the obstacles to look out for?
Are you validating tools at the moment, would you like to share some of your results?
Do you consider implementing such a tool in your company, what information are you looking for?

We do appreciate an open and frank discussion about this topic, but please no bashing of any kind.

A little word on a new initiative announced at the GALA meeting at Seattle last week:

ENLASO has released a first set of implementations of components and tools in the Okapi Framework. You can download them freely as they are open-source software. There are a few screen shots available.

In short, the Okapi Framework is a set of interface specifications, format definitions, components and applications that provides an environment to build interoperable tools for the different steps of the translation and localization process.

The idea driving Okapi is that during the course of a localization project, one need often to write small utilities that perform specific tasks. Developing such little programs within an organized framework can make a big difference after a while since you can start re-using a lot of the components you have already made. Doing this within an open-source project makes also sense because you can re-use components other peoples have made.

The core of the framework is a set of object interface definitions that allow the components to communicate. For example: the Filter interface, the FilterItem interface, and the UtilitySet interface.

The first set of components include few things but provides a foundation upon which new components are being build:

• There is a filter for PO file and a utility set that provides three functions: Text extraction (in RTF, XLIFF, TMX, and table format), Text merging (for extracted XLIFF), and Text rewriting.
• There is also Tikal. It’s a simple command-line tool that run launch any utility, and do various things like editing utility options and filter parameters files.
• And finally there is Olifant (early Alpha version). That is a program to manage TMs. More on it later.

The next release of the components is coming soon. It will include a Properties file filter, an Encoding Conversion, and a Line-Break Conversion utility, as well as some enhancements to the existing utilities.

So, next time you need to write a little program for a localization tasks, try to see if the Okapi Framework can help you out.