Summary. In wxrks, a confirmed segment is carried to the next workflow step. If a linguist later corrects that segment and confirms it again, the corrected version should replace the earlier one in the next step. Between 21 and 28 September, in projects with two or more linguistic steps, it did not. The corrected version stayed in its own step and the next step kept the earlier version. If nobody in the next step changed that segment afterwards, the delivered file contained the earlier version. No error was shown, and the segment looked correct where it was corrected.

Root cause. The platform carried a segment forward when it detected that the segment had become confirmed, by comparing its status before and after each save. A correction to an already confirmed segment only looked like a new confirmation if the segment first went back to draft on the server, and the editor recorded that draft state as soon as a correction started. The 21 September release fixed a cursor problem that occurred while correcting a confirmed segment, and in doing so stopped recording that state. The platform then saw "confirmed before, confirmed after" and did not treat the correction as a new confirmation.

Impact.

• Nothing was deleted: every version remains in the segment history. The next step kept an earlier version from the same workflow step.
• Corrections that did not carry over were also not written to the translation memory.
• Only corrections to already confirmed segments were affected. Single-step workflows and segments confirmed only once were not.
• In the projects we analysed, 781 edits did not reach the next step during 21–28 September, against 6 between the fix and 2 October.

Timeline (2026).

• 21 Sep: release that changed how corrections to confirmed segments are recorded.
• 25 Sep: our QA reproduced the behaviour.
• 28 Sep: release with the fix. Corrections to confirmed segments are carried to the next step again.

Resolution. Released to production on 28 September. From that point, corrections to confirmed segments carry to the next step, including in projects already in progress.

What we did for affected accounts. For the accounts that reported it and those we identified, we provided the list of affected segments. We propagated corrections where the next step was still in progress and wrote them to the translation memory. Where the next step had already been edited or delivered, we left the decision to the customer so as not to overwrite their reviewers' work.

Preventing it again.

The cause of this incident was that the platform depended on the editor saving an intermediate draft state to recognize a new confirmation. These measures remove that dependency and add checks, so a change in the editor cannot silently break propagation again.

• Verified before and after release: our QA team tested the fix before it was released, and we verified in production that corrections to confirmed segments are carried to the next step again.