Segmentation difficulties are often one of the most troublesome aspects of working with translation environment tools. Learning to configure segmentation rules correctly and applying that knowledge can save many hours of wasted time in alignments and translations and avoid filling translation memory resources with garbage from fractured translations of partial sentences with missing verbs, subjects and whatnot.
The usual alternative remedy for inadequately configured segmentation rules which lack the segmentation exceptions needed for abbreviations, for example, is to use the "join" function (Ctrl+J), and sometimes the split function (to manage very long, unwieldy clauses such as one might find in a patent text, and the join the parts again later).
There are situations where joining and splitting of segments is blocked. This is the case with any file which is part of a view, for example; the view must be deleted before segments can once again be joined or split. Segmentation changes are also not possible in a server project which has not been set up to allow them.
There are several options or documents available to project managers when setting up memoQ server project. But to enable translators to correct unfavorable segmentation, there is really only one choice:
If Desktop documents (no web translation) is selected, then on the dialog page which follows, changes in segmentation can be enabled:
If a project manager does not configure a project to allow this, for example because a document is being split between multiple translators (which does not allow for segmentation changes for technical reasons), the full responsibility must be assumed by the project manager for any segmentation issues. The imported documents should be examined carefully, and if any problems are observed, the segmentation rules should be modified and the documents re-imported. Doing otherwise may unavoidably result in garbage being written to the project's translation memory.
This is a very important point for memoQ trainers to emphasize when they are teaching users of the memoQ server to set up projects. Segmentation topics should be covered thoroughly, and the potential for bad results should be understood clearly if translators are given badly segmented documents they cannot fix. Project managers should also be encouraged to avoid restricting translators options in ways which are likely to harm the quality of the results and make parts of the translation unfit for later re-use.
A good rule of thumb is to choose the desktop documents option for projects always unless there are very urgent reasons not to do so. In this way, you will avoid upsetting your translators by forcing unmanageable, fractured sentence fragments on them, and you will be assured of better quality translation memory resources.
Thanks for addressing this, Kevin. A related problem I've faced in server projects is when joining and splitting is not allowed for LiveDocs corpora. I've had project managers simply throw huge PDFs into LiveDocs because they didn't have time to do a proper alignment, which normally results in a big mess (for the 200+ page PDFs of annual reports that I'm talking about). I applaud the intention - at least they're trying to get the necessary resources to the translators, and you know what a fan of LiveDocs I am. But without the translator being able to fix the alignment the corpora are practically useless. And unfortunately, since the option to allow changes to LiveDocs is disabled by default, your average PM probably just overlooks this when setting up a project. Plus it's impossible to change once the project has been set up, so even if I explain the problem to the PM there's normally nothing they can do about it. I would like to see the default behavior as having this option enabled so it's not passed over when setting up projects. And failing that, this point should at least be included in PM server training. After all, it can only be helpful to allow the translator to improve on an alignment where necessary; this in the end saves work for the PM plus benefiting other translators on the project.
ReplyDeleteThank you for bringing up that LiveDocs issue, Susan. Unfortunately, issues like these are not dealt with in any systematic way at the present time in the memoQ "train the trainer" courses, and while topics like these can be found in the documentation if you know what you are looking for, I have yet to find any useful treatment of the subject which discusses how to do things right and avoid project pain. There really is a need for much better training for project managers who use memoQ servers. I've waited patiently for something to happen in this respect for several years now, but what I have seen instead has been serial train wrecks as each new client (and former client) of mine has made the switch from the Troubles of Trados to the expected Garden of memoQ. But gardens need watering and maintenance or they are soon choked with weeds. Server users who set up projects in the best way for their translators in the first 6 months to a year of use seem to be the exception rather than the rule. It's not that it is really that hard - I could teach you a lot of this stuff in 20 minutes and you'd never forget it - but the infrastructure currently available for education is not up to its task, and the same mistakes recur time and again. The result is frustrated translators and data resources of diminished value.
DeleteI am seriously considering adding a "server self-defense" chapter to the next edition of my memoQ in Quick Steps guide. The book is about using the desktop edition, but we desktop users have to deal with badly configured server projects so often, that I think some "instructions to share with the client" are called for perhaps since things are often simply not working at the present time with those responsible for new memoQ server users getting off to the right start. I hope people swipe these instructions in this article, translate them into whatever languages they are needed in and spread them around to lessen the troubles of my colleagues who are confronted with these challenges. (That's a grant of license, people, so go for it if you want to and send me any useful links to share.)