Update on "A thought on localization"

The original post is here.

An employee at Adobe suggested that I copy my rant (which I had originally posted on G+, which is where he saw it) onto an post on Adobe's blog, so I did. That post was one of the things that "inspired" my rant in the first place, so it seemed fitting.

Just this last week, a representative from SDL (makers of Trados, the leading translation tool in the industry) posted a reply. It said basically what I expected it might, that a lot of people might not understand the filters well enough, that generic XML filters might not give the segments to the translators in an "optimal way," and that other information relevant to the document (formatting, etc.) might be difficult or impossible to obtain with a generic filter.

They do admit, though, that "a generic filter could have some value where no specific filter exists." And a major producer of translation tools responded to my comment. Which is awesome.


I still think that variations on a zipped XML filter would be valuable. One could create specific filters for Docx, Xlsx, Idml, etc. and translate those files directly in the original format instead of a middle format, which is what virtually every translation tool that isn't a Word macro does. Trados, Wordfast, Lingotek, Idiom WorldServer, OmegaT... All of them convert your original document into some middle format, usually XML-based itself. Why not create a tool that would take out the middle man? It might be something to look into some time in the future, but it might not be enough of a selling point if the other tools' middle formats can be satisfactorily converted back to the original formats. But then I think of those Word files that we translated in class, not too complex, whose formatting got mangled by the various translation tools that we subjected them to...


Ok. This rant is over. The moral of this post: People listen to you in unexpected ways sometimes.

A thought on localization

Here's a l10n thought I had the other day, and I'm sorry if it gets too technical:

Why is it so hard to add a supported file format to translation tools? A lot of formats, including the current Microsoft Office formats (PPTX, XLSX and DOCX) and IDML, the current export format for InDesign, are simply ZIP files renamed. What's inside of those ZIP files? XML files. That's right: plain text.

It's relatively easy to set up a filter for any sort of plain text file, be it XML, HTML, TXT or whatever, as long as you know a few things: Where is the translatable text? Are there patterns to find the translatable text? What do I do with the non-translatable text? (For example, is it interior formatting information, etc.) What's the encoding?

Most translation tools have filters set up for HTML already, and for TXT as long as everything's translatable. Most will even have some sort of customizable XML filter. It wouldn't be that hard to set up an interface that would let you define a compressed (ZIP) file extension, define which folders and/or files the translatable text would be found in, and define where in those XML files the translatable text is. So why has nobody done this? Sure, there are filters for the MS Office files, but most tools that I'm familiar with, if they support InDesign at all, are stuck back at only supporting INX files, which are the previous export file type, and they're XML to begin with!

What I want is a generic "compressed file" filter that will allow you to find the content. Java JAR files with translatable content are compressed files that (if they're done right) contain PROPERTIES files, which are a type of plain text. The above mentioned file formats are all compressed files that contain XML files. Who knows what files in the future will simply be compressed files that contain plain text information? If there were a generic way in some tool to define where and what is translatable, it would make our lives easier.

While we're at it, we need a better plain text filter. Some image formats contain translatable text information, but as far as I know there are no tools that support those file types.

Maybe I'll work on this stuff eventually, at least in pseudo code. Maybe someone in the right place will come to the same conclusion and make this widely available. Maybe.

Ok, I'm done ranting now.