Computer assisted translation (CAT) tools need to provide an editor in which to perform the actual translation. There are basically two ways to accomplish this:
- Providing a stand-alone editor
- Providing a plug-in (add-in) to an existing editor
Both approaches are used by various CAT tools. Felix actually has both: Felix itself comes with interfaces for MS Office, and Tag Assist is a stand-alone editor for HTML.
Each approach has its strengths and weaknesses.
Providing a stand-alone editor
Stand-alone editors have two main advantages. Firstly, they’re more stable because they don’t have to worry about maintaining compatibility with multiple versions of the editor they’re plugging into. Secondly, since they can design the editor environment specifically for translation, they can make a smoother workflow.
The main weakness of the stand-alone approach is that you’ve got to re-implement all that word/document-processing functionality. Things like spell checking, word counts, and rich formatting take a lot of time to implement, and you would basically them get for free by piggy-backing on an existing editor.
Another weakness of the stand-alone approach is support for document formats. With MS Office in particular (pre-2007), a closed, binary format was used, making perfect conversion between the MS Office format and the stand-alone editor quite difficult. Even the Macintosh and Windows versions of MS Word have notorious interoperability issues.
Providing a plug-in
Using a plug-in approach with an existing editor also has two major advantages. The biggie is that you can leverage all the non-trivial work that has gone into developing that editor. Office is Microsoft’s killer app, and several lifetimes worth of programmer hours have gone into developing it.
Secondly, this approach allows you to use the same file formats as your client. When using a stand-alone editor, there’s generally some sort of filter process going on, first to import the Office document into the editor environment, and then to put the translation back into the original format. When you’re dealing with very simple documents this isn’t usually a problem, but things soon break down. This may be alleviated somewhat in the future, as Microsoft Office moves to its new, open, XML-based format. Time will tell; but even so, expect a few years at least until most consumers of translation move away from the older Office formats.
Another benefit of the integrated approach is user familiarity: if your users are used to MS Word, then having your tool integrated into MS Word should have a shallower learning curve than making them learn a new editor.
The biggest weakness of the integrated approach is that you’ve got to support a foreign interface, usually across multiple versions. This greatly multiplies the failure points of the software. One example of this in the case of Felix is PowerPoint 2007. The first Felix interface from PowerPoint was developed for PowerPoint 2000, and it worked fine with PowerPoint XP and 2003. But when PowerPoint 2007 was released, a change in the code caused PowerPoint to melt down and crash hard (requiring a reinstall) if the Felix add-in was installed. I scrambled and patched the interface as quickly as possible, but due to problems with my then-distributor, it took several months for the new version to be released, and during that time I had to advise users to not use Felix with PowerPoint 2007.
With the stand-alone approach, you don’t have these compatibility issues.
Conclusion
Choosing a stand-alone versus an integrated interface is about making trade-offs. With the stand-alone approach you get greater stability and customization at the expense of feature richness, while with the integrated approach you get a rich feature set, document compatibility, and user familiarity at the expense of greater fragility.
