A continuous project and its outcome

Owned by Damian Rozmiarkowski (Unlicensed)
Last updated: Jul 12, 2024 by Damian Rozmiarkowski
11 min read

Introduction

A continuous project (CP) is a project in which source files (with the same name!) are updated with their newer versions, i.e. new content, to prevent the creation of multiple projects with the same constantly evolving files. This could either involve changing existing text in the file, which would lead to existing source segments being changed, or adding brand-new content to the file, creating new source segments in XTM Workbench (or both). Source files can be replaced multiple times in a single project.

IMPORTANT!

Once a continuous project update is performed on a particular file, its workflow progress will reset, regardless of whether or not it is active or has been finished, which means a need to reassign the linguists and restart the entire workflow.

When it comes to the XTM Cloud UI, the continuous project update is performed by uploading an updated source file for a specific project in the Project editor → Files → Manage source files → Add or update files section (with or without project reanalysis – more on that later in this article).

You can also perform this action by selecting API methods:

Performing continuous updates on a project does have certain implications for:

  • translation memory (TM) matches in the project,

  • translated segments,

  • added comments,

  • added LQA errors on workflow steps with the “LQA” option enabled,

  • existing status of a particular segment.

This article provides a detailed explanation of what happens in the project in question when a continuous project update is performed on it.

Implications of a CPU on the project

This section describes all the changes to the overall project if a continuous project update is performed with and without selecting the Reanalyse project in the UI.

IMPORTANT!

Even if you do not select the Reanalyse project option, this does not mean that the file itself will not be analyzed again. Every update to a particular source file in XTM Clouds triggers immediate reanalysis of that file. However, the rest of the files in a project (if there are any) will not be reanalyzed.

Translation memory (TM) matches

Keep in mind that the type and number of TM matches and the priority in which they are displayed in XTM Workbench strictly depend on:

  • the general settings applied to translation memory in the XTM Cloud UI (Configuration → Settings → Translation → TM),

  • use of TM penalty profiles,

  • status of a particular TM match (Approved vs Not approved),

  • use of machine translation (MT) matches.

Since, considering the above, there are an unlimited number of combinations of TM matches that might be displayed as a result of a continuous project update, the following example is based on the most "primitive" settings” possible: permitting all matches to be inserted in a project (even if matches with a higher priority exist), lack of any TM penalty profile, lack of any MT matching. Another vital restriction applied is to for existing TM records to only be modified if the project segment has the same source, inlines, context and tags.

TEST CASE

OUTCOME

TEST CASE

OUTCOME

Imagine a new project with a source file containing 10 segments and one workflow step. We translate and confirm all the segments and finish the workflow. The translation memory from this project is saved in our database.

 

I continuous project update

 

With project reanalysis

Without project reanalysis

Assuming we perform a continuous project update by uploading a new version of the source file where:

  • segments: 1, 2, 3 are left intact,

  • segments: 4, 5, 6 are modified,

  • segments: 7, 8, 9 are left intact,

  • segment 10 is modified,

  • two new segments are added: 11, 12.

  • segments: 1, 2 are turned into In-context exact matches (they retrieved TM matches from the previous iteration, and their context did not change);

  • segment 3 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration but the context changed on one side due to a change in segment 4; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segments: 4, 5, 6 receive Fuzzy match (they retrieved TM matches from the previous iteration; also, their XTM status was changed from Completed to Incomplete);

  • segment 7 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration but the context changed on one side due to a change in segment 6; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segments 8 is turned into In-context exact match (it retrieved a TM match from the previous iteration, and its context did not change);

  • segment 9 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration but the context changed on one side due to a change in segment 10; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 10 receives Fuzzy match (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segments 11, 12 remain untranslated and without any TM match.

  • segments: 1, 2 are turned into ICE matches (they retrieved TM matches from the previous iteration, and their context did not change);

  • segment 3 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration but the context changed on one side due to a change in segment 4; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segments: 4, 5, 6 receive Fuzzy match (they retrieved TM matches from the previous iteration; also, their XTM status was changed from Completed to Incomplete);

  • segment 7 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration but the context changed on one side due to a change in segment 6; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segments 8 is turned into ICE match (it retrieved a TM match from the previous iteration, and its context did not change);

  • segment 9 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration but the context changed on one side due to a change in segment 10; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 10 receives Fuzzy match (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segments 11, 12 remain untranslated and without any TM match.

 

We translate all the segments and finish the workflow once again.

 

II continuous project update

 

With project reanalysis

Without project reanalysis

Assuming we perform the second continuous project update by uploading yet another version of the source file where:

  • segment 1 is modified,

  • segments: 2, 3 are left intact,

  • segment 4 is modified,

  • segments: 5, 6 are left intact,

  • segment 7 is modified,

  • segment 8 is left intact,

  • segments 9, 10 are modified,

  • segment 11 is erased from the file,

  • segment 12 is left intact.

 

  • segment 1 changes from In-context exact match to Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 2 changes from In-context exact match to Leveraged match (100%) (it retrieved a TM match but the context changed on one side due to a change in segment 1; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 3 stays with Leveraged match (100%) (it retrieved a TM match from the previous iteration, and the context additionally did change on one side due to modification of segment 4; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 4 receives yet another Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segments 5, 6 receive Leveraged match (100%) (they retrieved a TM match from the previous iteration, and the context additionally did change on one side due to modification of segment 4 and 7; also, since the context was altered, their XTM status was changed from Completed to Incomplete);

  • segment 7 changes from Leveraged match (100%) to Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 8 changes from In-context exact match to Leveraged match (100%) (it retrieved a TM match but the context changed on both sides due to changes in segments 7 and 9; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 9 changes from Leveraged match (100%) to Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 10 receives yet another Fuzzy match (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 12 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration, and the context also changed because segment 11 was deleted; also, since the context was altered, their XTM status was changed from Completed to Incomplete);

  • segment 1 changes from ICE match to Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 2 changes from ICE match to Leveraged match (100%) (it retrieved a TM match but the context changed on one side due to a change in segment 1; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 3 stays with Leveraged match (100%) (it retrieved a TM match from the previous iteration, and the context additionally did change on one side due to modification of segment 4; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 4 receives yet another Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segments 5, 6 receive Leveraged match (100%) (they retrieved a TM match from the previous iteration, and the context additionally did change on one side due to modification of segment 4 and 7; also, since the context was altered, their XTM status was changed from Completed to Incomplete);

  • segment 7 changes from Leveraged match (100%) to Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 8 changes from ICE match to Leveraged match (100%) (it retrieved a TM match but the context changed on both sides due to changes in segments 7 and 9; also, since the context was altered, its XTM status was changed from Completed to Incomplete);

  • segment 9 changes from Leveraged match (100%) to Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 10 receives yet another Fuzzy match due to its new source content (it retrieved a TM match from the previous iteration; also, its XTM status was changed from Completed to Incomplete);

  • segment 12 receives Leveraged match (100%) (it retrieved a TM match from the previous iteration, and the context also changed because segment 11 was deleted; also, since the context was altered, their XTM status was changed from Completed to Incomplete);

 

CP In-context exact match vs. ICE match

In is important to distinguish between two kinds of in-context exact match:

  1. the first one results from a standard project reanalysis process or relevant TM matching → ICE match;

  2. the second one results from a continuous project update (without project reanalysis) → In-context exact match.

Those two are identical at project Metrics level so they are treated the same way during costs generation. Furthermore, CP In-context exact matches are created in the same way: during the TM matching stage, XTM Cloud compares the strings in the old and new segment to check whether the SHA code is exactly the same for a particular TM entry on database) and goes on to compare its contextual information (source & target previous, next crc).

However, there are a couple of major differences between the two:

a) In-context exact match does not return the actual match in XTM Workbench. Its presence is only signified by the relevant state qualifier, displayed when you hover over the status icon:

Note that there is no "label" for this match on the right-hand side of the segment, which means the lack of match in XTM Workbench, contrary to the "regular" ICE match:

b) In-context exact match is not subject to ICE match locking. The project options such as:

  • Allow editing of ICE segments,

  • Mark segments as locked when: Match type is approved or not approved ICE and Leveraged / Match type is approved ICE and Leveraged,

will not have any effect. In all other aspects, they do act the same as “regular” ICE matches.

Comments

With regard to commenting in XTM Workbench, a without project reanalysis continuous project update action causes comments to be removed in segments whose status changes from Completed to Incomplete (either because their content is changed or their state qualifier changes). This applies for all workflow steps. If no change has been made to a particular segment, comments inserted in it in the first iteration of the project will remain intact.

A with project reanalysis continuous project update action removes all the comments from the project, regardless of actual segment statuses.

LQA errors

For more information on how the LQA mechanism works, read the following article: Types of LQA report – description and use case.

For more information on how the LQA mechanism works, read the following article: Types of LQA report – description and use case.

Similarly to XTM Workbench comments, a without project reanalysis continuous project update action causes LQA errors to be removed in segments. This changes their segment status from Completed to Incomplete (either because their content is changed or their state qualifier changes). This applies for all workflow steps in which the LQA option is enabled. If no change has been made to a particular, its LQA errors, applied in the first iteration of the project, will remain intact.

A with project reanalysis continuous project update action removes all the LQA errors from the workflow steps for which the LQA option has been enabled, regardless of each segment's actual status.

Segment status

As described in the section about TM matches, every alteration to the source segment and change to its TM match (or state qualifier, to be more precise) in the course of a continuous project update action causes a currently applied status (i.e. Completed, Draft, To be corrected) to change to Incomplete. The exception to this rule is when a segment acquires either an ICE match or In-context exact match. This applies for all workflow steps and works identically with and without project reanalysis.

XLIFF:doc status

In the case of XLIFF: doc statuses (if enabled. For more information on this topic, see XLIFF:doc status), a without project reanalysis continuous project update action will cause segments to retain their current XLIFF:doc status, except for segments in the source text has changed. The new status for these segments will be 1:New.

A with project reanalysis continuous project update action will update all the XLIFF:doc statuses of TM matches (if they exist). Also, as mentioned above, segments with changed source text owing to the continuous project update action will be assigned the status of 1:New.