@brandelune do not like omegaT. really only works with plain text. ugly. burdened w/ typical java on mac shortcomings. not customizable.
That barely begins to cover what I don’t like about OmegaT. I’ve been thinking about what I would like in a translation tool for a while now. My desires break down into two categories: the translation-memory engine, and the environment presented to the translator.
The TM engine
Translation memory is based on the concept of the segment. Typically, a segment is one sentence, and the TM tool can pre-segment the document at sentence breaks, but there’s no firm rule that all segments must be sentences.
A sentence is a logical unit for segmentation, but it’s a Procrustean rule that doesn’t always apply comfortably. I suspect that many texts that would benefit from TM would get more benefit from a different level of segmentation.
A friend of mine is working on a TM tool that allows for nested segments, and I believe that’s an important piece of the puzzle, but it’s only one piece.
The problem is that with the current state of the art, these different segments (nested or not) would need to be created manually, which defeats the purpose. The tool is supposed to make you work more efficiently, not work more. I believe that smarter segmentation logic could automatically identify phrases or clauses. Another piece of the puzzle—and one I confess I haven’t quite figured out—is comfortably specifying which segment one is translating at a given moment when working with nested segments.
I believe this could be accomplished, at least in part, by searching for frequency, which would have certain knock-on benefits. If a phrase or clause is repeated in a document (or across multiple documents), it should be marked as a segment. If not, it’s less important to treat it as one. Just knowing that a segment is going to be repeated later in a document could be useful to the translator, and a CAT tool that could show the other contexts in which that segment is used could be very helpful. I don’t believe any CAT tool gives a prospective view of segments like this. This kind of thing is tougher with, say, a Japanese source text, because there are no spaces as word delimiters, so there needs to be some lexical analysis (which could be tripped up by imperfect grammar or spelling). Still, it could be done.
Translation memory would be only one aspect of the translator’s work environment, even if it is central. Even just considering that, I don’t much care for the ones I’ve seen.
There seem to be two approaches to presenting the TM interface: self-contained apps and floating windows. OmegaT is a self-contained app that reads in the source document and lets you iterate through it, one segment at a time, so that you wind up with a document interleaving source segments with target segments.
Some other computer-assisted translation tools let you work inside Word (or whatever), viewing the source document in situ and providing a floating window for entering translated text that hovers over the main document like a remora, and overwrites the source as you go.
I don’t particularly care for either view. I like to be able to look at the source document in its entirety, likewise my target document, as it gives me a sense of the flow between sentences. Interleaving source and target or simply replacing source with target makes this difficult. Ideally, I’d like a large pane showing the source document unmolested and as it was meant to be read. Perhaps this is my old-fashioned paper-oriented mentality showing through.
I like the idea of a self-contained environment, but I recognize that a good one has several hurdles to overcome that the parasitic environment would not, most notably file-format support.
One of OmegaT’s biggest shortcomings, in my opinion, is that it is effectively limited to plain text. It can open HTML, docx, and some other file formats, but any format with, well, formatting is presented with tags surrounding the formatted text. In the case of a (seemingly) lightly formatted document that I tried opening in OmegaT, a chapter heading reading “第2章 高度成長下の事業拡大（1960～1966）” with no apparent formatting at all was rendered as
<w0> <w1> <w2/> <w3/> <w4/> <w5/> </w1> <w6> 第</w6> </w0> <w7> <w8> <w9/> <w10/> <w11/> <w12/> </w8> <w13> 2</w13> </w7> <w14> <w15> <w16/> <w17/> <w18/> <w19/> </w15> <w20> 章 高度成長下の事業拡大（</w20> </w14> <w21> <w22> <w23/> <w24/> <w25/> <w26/> </w22> <w27> 1960</w27> </w21> <w28> <w29> <w30/> <w31/> <w32/> <w33/> </w29> <w34> ～</w34> </w28> <w35> <w36> <w37/> <w38/> <w39/> <w40/> </w36> <w41> 1966</w41> </w35> <w42> <w43> <w44/> <w45/> <w46/> <w47/> </w43> <w48> ）</w48> </w42>
I went no further with OmegaT.
Other big hurdles are what would make a translation environment more than just a TM tool: the inclusion of other tools, and the decision of what other tools to include.
One obvious tool is a dictionary. OmegaT does have a facility for job-related glossaries, which is nice as far as it goes, and I believe that other CAT tools can support job, client, and general glossaries, but none of these tie in with general-purpose dictionaries that use the EDICT or EPWING formats, or Chinese-character dictionaries (which are their own very special ball of yarn).
Another obvious tool would be a web browser, or a specialized Wikipedia browser.
I have done a series of jobs where, in addition to a text transcript, I also had video files. It might seem a bit much to integrated video playback into a translation tool, but it would have been fantastically useful for that work.
Something that may be peculiar to my style of translation is the need for some scratch space. Working in between the opening and closing tags for a segment imposes a subtle psychological confinement. I need room to spread out. When I encounter a long, knotty sentence, I’ll work out the individual clauses on separate lines, and then compose the whole thing into a sentence that hangs together. A self-contained CAT tool would need to offer that.
All in all, I think there’s a huge amount of untapped potential in CAT tools. Translation is a very narrow market, but the commercial tools out there sell for $350 and up. It’s also unfortunate that the only ones out there are either Windows-based or Java-based. There’s an unsupported, primitive, and inscrutable TM tool from Apple, and that’s it on the Mac side. There’s no reason to think that a TM tool could only succeed on the majority platform: it’s a specialized enough market that, given a breakthrough product, translators will buy the platform that runs the software, not the other way around. My layman’s understanding is that the development environment on the Mac would provide a programmer with enough tools to get a decent head-start over a Windows (or multi-platform) alternative.