Title: Known issue: document synchronization problems in online projects when using splitting and joining
Description: When two or more users are working on the same document in parallel in an online project, and do splits and joins, some work by the translators can be lost on synchronization. In these cases, after the synchronization, a translation can either be reverted to an empty segment, or to a previous state, resulting in the loss of useful edits or changes made by translators or reviewers.
Status: Kilgray is aware of the issue and is working on this problem with very high priority. A fix is expected within days or at most one or two weeks.
Affects: The problem can happen in "desktop documents" type online projects in version 2013 R2 (6.8), and in any online project in version 2014 (7.0) Version 6.5 and before may be affected (in "desktop documents" type projects only), but they are no longer supported at the time of writing. It affects both splits and joins done manually or by the pre-translation function. Pre-translation can cause this if and only if the pre-translation is done with the "Automatically join and split segments for best match" option, resulting in actual splits or joins. Read the below example scenario for a technical explanation.
Example scenario 1: A and B are two translators working on the same online document in GroupSourcing
- Translator A joins segments 1+2, and synchronizes the document.
- Translator B synchronizes the document, and gets the new joined first segment. At this point, this new segment 1 is empty on the target side. B never touches the first segment from that point on.
- Translator A translates the new joined first segment, and synchronizes the document.
- Translator B synchronizes the document. The translation done by Translator A is lost, overwritten by the empty segment (the state at Translator B).
Example scenario 2: A and B are two translators working on the same online document in GroupSourcing
- Translator A pre-translates the document, and the pre-translation results in some automatic splits and joins, e.g., it joins segments 1+2. Translator A then synchronizes the document.
- Translator B synchronizes the document,
and gets the new joined first segment. At this point, this new segment 1
contains the pre-translation received from the translation memory in step 1 above. Translator B never touches the first segment from
that point on.
- Translator A modifies (corrects) the translation in the first segment, and then synchronizes the document.
B synchronizes the document. The changes done by Translator A are lost, overwritten by the earlier (pre-translated) state of the translation (as it currently is on the PC of Translator B).
logical interpretation of what happens in both cases is that the synchronization
logic treats the first segment as if it had been changed by Translator
Until the issue is resolved by Kilgray, you can do the following to avoid this problem.
- "Server document" type projects in version 2013 R2 and before do not allow splitting and joining, meaning the problem cannot happen if you use that type of project.
- If you pre-translate online documents that will be accessed by two or more users, do the pre-translation as a preparatory step in the online project management window, before the users check out the project for translation. This way the joins and splits caused by pre-translation can not cause the problem described here. Instruct your translators not to use the pre-translation function themselves.
- Or if your translators will use pre-translation, instruct them not to use the option to automatically split and join segments.
- It is best to stay away from splits and joins during translation if a document is being worked on by two or more users. If it isn't possible, use the QA functionality in memoQ to catch the issues this problem could have caused, The memoQ QA module contains a check that verifies that the translation of every segment is the same as the translation of the matching segments in the translation memory. If you run this check, and all the translators used the same translation memory, you will find the problem segments. When using QA to look for specific problems like this, it is best to create a custom QA configuration that disables every other QA check, so that you do not get any irrelevant false warnings. For example, you could do this as a separate QA round, before or after the normal QA checking you do before delivering the translations.
- If you are forced to do many splits and joins because of segmentation issues, adjust your segmentation rules to solve the segmentation issues before you import documents for translation.
- Fixing segmentation issues by manual splits and joins could be performed as a preparatory action before translation even begins.