Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

In Configuration → Settings → Translation → TMMatches - general, there is an option called Do not store in TM segments with XLIFF:doc status set to Rejected, which, as the name suggests, causes all the TM records with the -1:Rejected status not to be displayed in TM database in the XTM Cloud UI.

...

  1. When we create a new project, the default XLIFF:doc status value for every segment is 1:New. Even if we enter a translation and confirm it, the translation is not changed immediately: we need to update the XLIFF:doc status manually, on the right-hand side of a particular segment.

  2. If we create a second project that uses translation memory from the first project, its TM matches reflect the XLIFF:doc status from the original project, and:

  • when auto-population of a specific TM match is enabled: XLIFF:doc status in the segment is also changed accordingly;

  • when auto-population of a specific TM match is disabled: XLIFF:doc status in the segment is not changed accordingly, even though we insert the TM match directly in the segment.

...

  1. If we change the strong XLIFF:doc status (and translation) in the segment in the original project, the status will be changed accordingly in TM matches in XTM Workbench in the second project, but it will not be changed in the segments in that second project. Also, the appropriate TM record will be overridden with a new XLIFF:doc status (and translation) in the database or a new TM entry will be created with that status, depending on the TM modification settings.

  2. If we change the XLIFF:doc status in a segment in XTM Workbench in the second project, this change will be reflected in a TM record in the database, but it will not change the XLIFF:doc status in a TM match in XTM Workbench. The status will only be changed in the TM match as well if we reanalyze the project (which will cause the newest TM entries from this project to be matched against the segments).

  3. In the case of TIPP packages (or, to be more precisely, in XLF files that are contained within packages of this kind), the XLIFF:doc status of a particular segment is indicated in the following element: <target state=></target>; for example: <target state="translated">Tłumaczenie</target>. Once the package has been uploaded to XTM Cloud, that status will be displayed in XTM Workbench.

  4. If we move the workflow back or forth between steps in either project, the XLIFF:doc statuses will not be changed in any way. The segments maintain the same status across all the workflow steps.

  5. If we parse the segments through the Automatic step in the first project, the XLIFF:doc status is changed to whatever status was set up in that Automatic step, both in TM records in the database and TM matches in XTM Workbench in the second project, but the status in the segments in that project will remain unchanged. Once the TM match has been inserted in the segment and we reanalyze the project, the XLIFF:doc status is also changed in that segment.

  6. If we change an XLIFF:doc status by modifying a TM record directly in the database, it will be changed in a TM match in XTM Workbench in the second project, once we reopen the editor, but not in the segments. Once the TM match has been inserted in the segment and we reanalyze the project, the XLIFF:doc status is also changed in that segment.