I couldn’t disagree with you more. Fair enough, you have to spend time reading the manual and looking through forums when you get a bit stuck now and again (it must be said, that the OmegaT yahoo group is extremely active and helpful), but that’s the case for any new software. As Bowjest mentioned, you can change the segment size. And if you don’t want to see the text as a bunch of segments hindering your flow then print it out or have the document open in the background!

OmegaT’s main advantage is not that it is free in terms of cash, but that it is free in terms of being open source. This means that, unlike many of the larger CAT tools, if there is an aspect of OmegaT which you do not find works well, or if there is a feature you find is lacking, you can feed this back to the development team, as Bowjest mentioned above, and more often than not changes are made (I say this from first-hand experience). This kind of customer service is something that you will rarely experience elsewhere, at least not at such speed, and definitely makes the whole OmegaT package much more appealing.

Beyond OmegaT, there are some extremely useful CAT tools out there. The whole point of the text being split into segments is for the translation memory to be able to work at its best, saving you time and increasing your consistency, and therefore translation quality, in the long run. Any good translator will always start by reading through the text, so shouldn’t be put off by segmentation, whatever the tool.

I’m sorry to hear you’ve not found OmegaT useful.

I’m not sure what you mean by “expand and shrink segments”, but you have the option per project to display the given text as sentence-level segmentation or paragraph-level. Perhaps that’s not what you mean.

I find it a very fluid, useful tool. It is option rich (IMHO), allows me to deal with long texts in a number of formats, and allows me to build a repository of hundreds of thousands of TMs and glossary files.

Give us a bit of detail on what you’ve found lacking and it can be fed back to the development team.

Thanks.

All software of that type (Trados, DejaVu, Wordfast, etc.) have a chaotic, completely ineffective and buggy UI.

OmegaT has just one advantage over the others – it’s free whereas the others are awfully expensive.

Translators should refuse to work with such badly designed “tools” based on a wrong assumption, i.e. that a text is a concatenation of segments.

We’re living in the world of CHT – Computer Hindered Translation.

I’m glad that worked for you. In the interim I’ve had some feedback from a long-established OmegaT user and he advises against doing the above (sorry, it’s what I’ve found works, but he makes good points below):

OmegaT never deletes segments from project_save.tmx. If you change the translation of a segment (e.g. in a second draft), the segment is modified. But if you remove the segment from a project altogether after that segment has been translated, i.e. by deleting the source text file containing it, or by making changes to the source text file (as a result of which the segment concerned ceases to exist in exactly that form), OmegaT retains these segments in project_save.tmx. They enter a form of limbo, because they can no longer be modified within OmegaT (because they are no longer presented to the translator for translation/modification. However, OmegaT does not delete them because they can be useful. They turn up in Find results, for instance, and are marked as “Orphan segments”.

His recommendation is to create a new project for every doc you translate. Then, after you export it and are happy with it, take (or copy) the level1-tmx file and put it into a master folder of TMs that you can use in future. The added advantage to this is that the level1 file doesn’t capture all the inline formatting nonsense that you sometimes have to deal with from converted Word documents (all that stuff).

I’ve started doing what he suggested and it works great!

I did what you mentioned above and it did indeed work!

As long as you rename it, OmegaT will read from this filename – the translator can simply then rename the TMX file afterwards.

Good question! I’m not entirely sure.

I read the following link yesterday:

http://www.proz.com/forum/omegat_support/158125-how_to_update_previous_translation_memory.html

and the bit near the top from Samuel Murray seems to indicate that if you take an existing TM and rename it project_save.tmx and put it in the omegat directory for your given project, OmegaT will write to it. To quote from Samuel Murray:

“4. The TM that OmegaT reads from *and* writes to, is called project_save.tmx, and it is in your project’s /omegat/ folder.”

I’ve not tried this, but it seems logical. I think I’ll experiment a bit with it later today.

Good luck and let us know what results you get.

Thanks for your reply!
So just to clarify, even if a client sends a TM they want you to add to, you still have to start a new project with a new TM, and then merge it afterwards?

I’ve seen the additional merger but, like yourself, thought there would be the option to use an existing TM as the main project TM.

I’ve found in the interim that there’s a merge tool on the OmegaT site that you can use to merge two TM files. I’ve tried it and it seems to work, so hopefully that is the easiest solution.