|
There have been plenty of Top Ten lists released by smart people in our industry during the past few weeks -- not surprising, considering that we are about to enter a new decade -- so I won't bore you with yet another one.
Instead, I thought it would be interesting to take a look at the translation technology landscape out there, kick back, and dream of things that I think are missing and would make our work a lot easier.
The difference from a typical "Top Ten" list? This is stuff that is probably not going to happen (though I would be truly happy to be proven wrong!)
Here is my dreams list, in no particular order:
1. Open standards for server-based systems
2. Full fruition of XLIFF
3. Wide and customizable access to tool-external resources
4. Feature parity of browser-based vs. hard-drive-based tools
5. Integration of common word-processing features
6. Morphological tool kits
7. Rediscovery of terminology and integration into TM and MT workflows
8. Completely integrated terminology extraction
9. App stores for all kinds of tools
10. Honest communication by tool vendors
Open standards for server-based systems
This is not exactly a new idea. For instance, in the last edition of the newsletter I wrote about how important the release of the Server API for Trados will be so that other tools can hook into its server-based workflows. But since most tools have some kind of server-based workflow, it's not just Trados we're talking about.
What exactly is a server-based workflow and why do we need to "hook" into it?
Well, we've been talking about translation exchange standards forever -- standards like TMX to exchange translation memories, TBX to exchange terminology databases, and XLIFF to exchange the actual translation files (and others, including SRX, GMX, and xml:tm). These standards are really important to facilitate the exchange of translation project between different (versions of) translation environment tools. Traditionally, the focus of these standards was the desktop so that projects could be exchanged from one system to another. With the advent of server-based projects, assets (translation memories and terminology databases) are stored online with real-time access to a translation professional, and suddenly things are no longer quite so clear-cut. While in some cases it is possible to download some or all of the data into one of these exchange formats, it defeats the purpose: the real-time collaboration between various translation professionals is therefore typically not granted. Ergo, the data is only accessible with the originating tool (which could be Trados, Déjà Vu, Across, memoQ, or any of the other tools that support this kind of workflow).
What is needed, therefore, is a standard that allows for any translation environment tool to hook into that workflow, i.e., query the underlying translation memories and terminology databases that remain on the server and write data to them as the project continues, enabling other folks who are working on the project to benefit from that data in real-time. Sound unlikely? Agreed. But it's no doubt possible if there is a real will on the side of tool makers. Is there? No, not really, and this is true for big and small vendors alike. Yes, they all support the above-mentioned translation data standards in some way or other and communicate this very publically and proudly. But with the future and present clearly going in the direction of server-based projects (at least for large projects), many vendors are only too happy to have found this new way of capturing their technology. You find that frustrating? I do, too. There is actually an email address that Alan Melby and I set up awhile back to allow you to voice your concerns so we can pass those on to the vendors. Feel free to let tool makers know through the address I listed, or talk to them directly. Are they gonna listen? That depends on how many of us are talking, I think.
Full fruition of XLIFF
XLIFF (XML Localisation Interchange File Format) is probably one of the best things that has happened to our industry in the last few years, and ironically it almost happened by accident. XLIFF really was only meant to support the translation process of software development formats, but it has long since morphed into an exchange format for all kinds of files (and in fact, many tools use XLIFF internally for all their supported file formats).
It's a really cool standard. Yeah, it's great that we can exchange TMs and termbases with standards, but how much greater is it to exchange the actual translation file between different tools? No more awkward converting of source files or need for filters to support file formats of other translation environment tools if everything went through XLIFF!
The problem with XLIFF is that it is extendable by definition. This means that you can create perfectly valid XLIFF documents that still cannot be read -- or read in their entirety -- by other tools. Now isn't that lovely! There is a really instructive presentation on this very topic that shows one quality assurance tool vendor's struggle when he needed to support the output of the exchange format XLIFF from various other tools. It tends to sound like an oxymoron when you have to create customized filters for an exchange format. The plea to tool vendors needs to be this: don't extend your XLIFF definitions. Use what XLIFF already offers.
(And yes, you might want to use the same email address as mentioned above.)
Wide and customizable access to tool-external resources
Some tools, especially Across and Fluency, already offer the ability to easily link to online and, in the case of Across, even hard-drive-based resources for third-party terminology resources. With tools like IntelliWebSearch (see the article below), it is also possible to do searches on terminology resources on virtually anything and everything from within any tool in the Windows environment. Still, it would be a helpful and easy add-on for all TEnTs to offer online dictionary and corpus searches as well as dictionary searches from within their environment. Why? Because not everyone is reading this newsletter to find great ways of getting to helpful resources (can you even imagine what life would be without this newsletter? ;-), and the more help we can provide to the uninitiated, the better.
I would not be surprised if we might actually see this in upcoming versions of tools!
Feature parity of browser-based vs. hard-drive-based tools
2010 saw at least two translation environment tools (XTM Cloud and Beetext) come out with browser-based translation interfaces that are almost as easy to work with as the interface of desktop tools. There are some things missing, though, including features such as a global search and replace. Clearly there will be more and more tools that will offer browser-based interfaces. The mantra for the developer of these tools is that less is better (i.e., don't over-clutter your interface) while at the same time offering all or most of the features of desktop-based tools. Some things work in favor of a browser-based interface, including spelling checking provided by the browser or an AutoSuggest feature that many browsers also offer by default. Still, this continues to be a tough nut to crack. And since virtually all tool vendors will be looking at an online-based translation process, they'd all be well-advised to look at the two tools mentioned above.
Integration of common word-processing features
This is an area that many tool developers have been working on, but it's also one that needs serious expansion. With MS Word all but out of the picture as the interface in which translation is being done (I know that many of you still use tools that allow for it, but even you will have to admit that there is a general trend away from MS Word), some features are missed by translation professionals in the tabular or otherwise structured interface of translation environment tools. Many tools now have decent spelling checkers, AutoText features, and some even AutoCorrect, and an increasing number also have visible formatting (WYSIWYG) for features such as bold and italic text, but that's not all that tools like MS Word or OpenOffice offer. What about grammar checks? What about track changes? What about more than just italics and bold as visible formatting? In many cases, tool developers have to deal with limitations on the editing areas that their particular environment can handle, but maybe it's time to look for more highly enabled environments.
Overall, I see a little improvement on this front, but it's likely that we'll see third-party tools (or add-ons -- see below) stepping into the fray.
Morphological tool kits
I have had many conversations with tool vendors about this area. Why don't the tools know morphological rules when it comes to recognition of termbase and TM entries or the automatic adjustment once matches are found? Some tools offer some functionality in this area in some languages (Across and Transit), but the majority of tools don't. And why? It's too expensive. Plus, any kind of development in this area will be language-specific -- so where do you stop? Which languages do you include?
Here is a suggestion: Why don't tool vendors develop tool kits to have users develop morphological language-specific rules that they can share with others or with their same language group who also will have some contributions to make? Too simple a solution to make it work? Let's see whether we can find some takers among the tool vendors. I certainly promise to give them all the coverage they need in my newsletter.
Rediscovery of terminology and integration into TM and MT workflows
How long have we/you been preached to about the importance of proper terminology work? Like, forever? It sure seems like it, and yet I think it would not be presumptuous to say that most of us are still not particularly prudent about it. And being prudent can mean a lot of things: Do we take terminology work seriously and really invest into it? How do we use terminology in our workflows? Do we have manual look-up procedures or do our tools automate look-up and utilize their findings? Do the different components of our tools (translation memory, grammar checking, morphological "knowledge," machine translation, etc.) "talk" to each other and work in concert with each other?
I think it's this last point where there can still be a lot done on the side of the tool vendors. Some tool vendors have offered features where termbases and translation memories "talk" to each other, so terms in a fuzzy TM match are switched on-the-fly if the old and new terms are "known" to the termbase (Déjà Vu does that, for instance). But there is clearly so much more that can be done. How about grammatical adjustments (singular vs. plural or gender-specific changes in articles, etc.)? And how about communication between machine translation matches and terminology databases?
Some kind of machine translation feature is present in virtually all translation environment tools. But it's by no means advanced. The feature usually provides for a suggestion from a machine translation engine when no translation memory match is found, but there is no automatic lookup or even replacement of terms that are found in the termbase. And it would be an easy thing to do (especially if the same kind of communication already happens between the translation memory and the termbase). Provided that we had good termbases (!), we might actually get decent hits even from machine translation engines like Google Translate or Bing Translator.
Now of course there are ways to integrate terminology into machine translation processes, but only by training processes and not on-the-fly. I foresee this feature as a potential game changer on two fronts: a) it could make machine translation a more reasonable additional feature for many of us, and b) many of us might actually start to take terminology work seriously.
Completely integrated terminology extraction
Terminology extraction has been around for a while. The idea behind this is that you can either take a set of documents (in source and target language) or a bilingual file (XLIFF, TMX, TTX) and have a program identify matches in those files, which in turn can serve as the basis of the glossary or terminology database for a given project. This is pretty ingenious, and yet most of the stand-alone programs that do that (for instance, MultiTerm Extract or SynchroTerm) have not exactly been flying off the shelves.
So why not include this feature into any file that is being processed by default, at least by creating a monolingual glossary that can then be leveraged against the TM or termbase? Tools like Déjà Vu and Text United (I'll write about that next year) can do it, and so can other vendors. Granted, it is a little more processing-heavy -- but not by much. And it once again would increase the use of terminology resources.
App stores for all kinds of tools
In the last newsletter I wrote about OpenExchange, SDL Trados' app store. Here developers can create and offer applications that can extend the usefulness of SDL Trados.
Other vendors: follow suit! Not only will you prevent SDL from building up its market dominance, but you will also help users of your tools. (Plus you might learn quite a bit about what users actually want and need.)
Honest communication by tool vendors
This is pretty self-explanatory: We have been hurt enough by false promises. This is certainly true for machine translation technology, but also for the technology used in translation environment tools.
The much-heralded "support for PDF" in many tools? Give me a break. No tool truly supports PDF files -- at least not in the way that other file types are supported. Complete openness because of XLIFF support? Well, I already talked about that a few paragraphs earlier.
Hint to the tool vendors: by definition, translators are smart people (even though we may not look like it!).
And will this happen next year or even in the next decade? I doubt it. But there is always room for hope.
| 
