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.

My name is Josep Condal, and I am the Managing Director at ApSIC. I currently serve as GALA’s Head of the Technology Committee.

My professional background is both in software development and localization, so no wonder why my Holy Grail is to reach new levels of quality and performance driven by technology and, where the technology does not reach yet, processes.

My main interests on technology revolve around tools that directly or indirectly enforce streamlined operations. Streamlined operations mean happy clients, happy vendors, and happy CFOs. A number of tool publishers in our business have gradually evolved to serve their clients (the ones in an organization who have a purchase decision), forgetting a little bit (and sometimes a lot!) who the actual users downstream are. This attitude is obviously understandable and respectable, but leaves plenty of opportunity for great improvements that really can change things. We hope that this blog space can contribute to open new paths of communications among those who use the tools and those who make them.

The Trados acquisition by SDL was really eye-popping for many and the apparent aftermath is that it has set a new ground for opportunity and innovation both inside and overall outside SDL’s walls. I anticipate many important changes technology-wise over the next 5 years, and we hope that this GALA blog can become a good source of information and discussion for what’s here and what’s coming.

Sorry for this long post! I just would like to add a couple more lines to thank Tony O’Dowd for volunteering to be the host and moderator of this blog initiative, Aki Ito for his determination on making sure that things happen at GALA, and to Laura Brandon for turning an idea from a brainstorming exercise into something that we can touch and feel. I would also like to thank in advance all the contributions that the bloggers of this space will be making to help define the role and shape of technology in the GILT business.

Welcome to the GALA Technology Blog. This first of its kind in the industry.

This BLOG is designed to gather, collate and discuss the impact of tools within the Localization Industry. It is designed to capture your thoughts, ideas and suggestions from improving the current number of technologies and products that you use on a daily basis within your company.

The feedback will be condensed and sorted and made available to tools manufacturers so that they can incorporate these suggestions and enhancements in future versions of their product offerings.

So what not give it a try! Your ideas are valuable and can make a difference!