Dec 8, 2013

memoQ TM settings: beware the Kilgray defaults!

memoQ 2013 R2 introduced a very significant change in the management of translation memory data which most users are likely not aware of. However, because the default behavior for information storage in translation memories was changed, it is important to be aware of this difference and what to do before your data are unacceptably compromised.


The screenshot above shows several different translations stored in my TM for the sentence in the second segment. In previous versions of memoQ, only one translation would be stored with the way this translation memory was configured. However, in memoQ 2013 R2, the role of the person editing the translation becomes an important part of the "context", and as a result, multiple translations can be stored for different roles. Personally, I find this a rather useless feature, because if I want to know previous translations for a segment, I consult the row history using the context menu. But I understand how in some processes, it may be desirable to maintain a record of translations entered by the translator and the first and second reviewer.

I have no use for these older translations, especially as these may contain errors (as seen in the example of the third entry in the screenshot). If I am proofreading my translation in a "reviewer" role and make changes, I want to overwrite the original entry in my TM and avoid the chance that its errors will be propagated in later work.

To avoid the problems that can result from this redundancy and preservation of errors in the translation memory, as of build 6.8.6 it is necessary for users to explicitly opt out of the current Kilgray TM settings defaults and create their own custom settings.

TM settings are "light resources" which can be managed in four places:
  • The Resource Console,where settings can be created, edited, imported, exported, etc.
  • The Options (Tools > Options... > Default resources > TM settings), where the default for new projects can also be set
  • Project Settings (Project home > Settings > TM settings) in a specific project, where the default settings for the current project can be set
  • Project home > Translation memories > (TM) > Settings where alternative TM settings can be specified for a particular translation memory selected in  project. This would be the case there you want to apply a special set of penalties to the content of that TM, for example.
The last tab of the default TM settings dialog looks like this:


To avoid the trouble of multiple, role-based entries being written to a TM, settings must be created in which the option to Store modifying user's role in the TM entries in not selected, and these custom settings must be applied to the primary translation memory in the project (by default or explicit selection).

Here's the "fast path" for staying out of trouble:
  1. Go to Tools > Options > Default resources > TM settings and if you do not already have custom TM settings to edit, select and clone the default settings. Give them a suitable name like "My Own TM Settings".
  2. Click the Roles tab and unmark the setting to store the user's role in TM entries.
  3. Click OK.
  4. Ensure that the checkbox next to these custom settings is marked so they will be applied to all new projects. Then click OK to exit the options.
  5. In any currently open project to which the desired settings have not been applied, go to Project home > Settings > TM settings and select the desired settings as the default by marking the corresponding checkbox.
Multiple entries written to the TM when the roles are included will not be eliminated after the TM settings are corrected. They must be explicitly removed by editing the translation memory.

I hope that in the future Kilgray will reconsider these troublesome new default settings and make the new possibilities "opt-in" values in custom TM settings. But for now, users must actively change their settings and defaults if they want to avoid role-based additional TM entries. (The current version of the memoQ Help describes roles as being disabled here by default. Would that this were so!)

You can, of course, make other useful adjustments to your custom TM settings, such as defining what a "good" match is (for pre-translation) or adjusting the tag matching behavior or applying various kinds of penalties to reduce match values for content which might have quality problems. The memoQ Help offers guidance on these options.

Postscript:
Even after the settings are "fixed", "existing damage" in a TM caused by the storage of unwanted, role-based information is not repaired. Any messes will have to be cleaned up in the rather inadequate TM editor in memoQ or in an external TMX maintenance tool. At the present time, there is no "easy option" to clean up a large number of erroneous or redundant translations stored because of this role setting. This case unfortunately underscores the woefully inadequate maintenance facilities for translation memory resources in the current version of memoQ. Perhaps some of the sophisticated options developed for Kilgray's TM Repository will finally trickle down in some way in an integrated option with Language Terminal or some sophisticated filtering and editing options will be added directly to the desktop product so that users can finally maintain their TM data in a reasonable way. memoQ is, overall, the best option available to us for project work in most cases, and I recommend it to colleagues because I know they will be able to do most ordinary tasks with a minimum of grief and calls for help (or expressions of anger) directed to me. But in 2013 it is ridiculous that my ability to manage my TM in my tool of choice is inferior to what I could do when I started using Déjà Vu as my CAT tool 13 years ago. Please join me in encouraging Kilgray to raise their game - soon - with respect to translation memory maintenance by writing to support@kilgray.com and expressing your need for better data management! (And more sensible default TM settings, of course.)

Update:
It looks like this default problem may end with the 6.8.6 build. One of the key people involved with memoQ and its features has stated that "After the [next] update, the default TM settings resource will have 'Store modifying user’s name in TM' unticked." Excellent.

For cases where there may already be data problems from older, erroneous entries being retained, the following workaround was suggested:
  • Export to TMX
  • Start up 6.5 and import into an empty TM
In the process, memoQ 2013 (version 6.5) will ignore the role information in the TMX, and entries with the same source will not create duplicates; translations with a later timestamp will be preserved in the TM if there are duplicates in the TMX.

This still doesn't change the fact that we need better means of maintaining our data in memoQ, but it is good that once again, Kilgray has responded quickly to important concerns of its users and is on the way to solving the problem.

6 comments:

  1. Kevin, thank you very much for this information. I honestly hadn't noticed the 'roles' tab and changed the settings immediately. Even before this release I've always felt there are too many versions of identical source segments in there (I had ticked the overwrite box in the settings somewhere).
    One thing that really annoys me, however, is the lack of a proper TM maintenance feature. Why can't Kilgray include AND operators or phrase search? When I'm looking for all segments containing 'like ice in the sunshine' (it doesn't happen often I'll admit), I don't want all segments containing 'like' or 'ice' or 'in' or 'the' or 'sunshine' -- that will probably return about 95% or more of all segments stored in my TM. I'm using the old Olifant for TM maintenance but surely it's bad business to force people to rely on an external, potentially unsupported tool for citical backend functionality. If it were up to me -- go easy on the fairly useless Muse and Fragment Assembly fuctions and don't get me started on MT, which I keep switched off at all times! But some TM maintenance module with functionality that goes beyond the rock-bottom stuff we're being provided with right now is desperately needed! Back in the Wordfast Classic days, PlusTools4 was a pretty useful TM editor with good functionality. I use MemoQ at my workplace and if I ever have to go freelance again I'd be seriously tempted to get MemoQ as well, but TM maintenance is the one thing that might still make me switch to a competitor's product.

    ReplyDelete
  2. According to a report I just read, this problem may actually have started sooner, in version 6.5 (memoQ 2013). Apparently, when one colleague tested the proofreader's role in build 6.5.17, she found that changes did not overwrite the original translation in the TM. In a way that's worse I suppose, because in version 6.5.x the roles are not exposed and you can't deactivate them for the TM as described here.

    ReplyDelete
  3. Hi all! Roles in TM were not there in 6.5, that's for sure. As for the default settings, I can only encourage you to lobby! And while at it, have that a ominous allow multiple translations moved to a far hidden place. It's current position does more ham than good!...

    ReplyDelete
    Replies
    1. Indeed. It can do a lot of ham, and that ain't kosher!

      Delete
  4. Well, the roles we're talking about do exist in 6.5; they just don't seem to be called that (yet). If you go to Project Home/Settings/General/User and meta-information/Confirm using status, you can select "Confirmed," "Reviewer 1 confirmed" or "Proofread." The problem Kevin alluded arose when selecting "Proofread" and then re-confirming or changing confirmed segments; the "proofread" segments did not overwrite the "confirmed" segments (rather counterintuitively imo). And apparently there isn't a way to change that in version 6.5 (2013 R1).

    ReplyDelete
  5. Hello

    I'm not sure how it ties in with the window and controls you speak of, but when setting up a TM, there is a window where you can tick 'allow multiple translations'.
    The problem therefore is also that the configuration settings are all over the place and we don't know how they interact with each other exactly

    ReplyDelete

Notice to spammers: your locations are being traced and fed to the recreational target list for my new line of chemical weapon drones :-)