Decoupling human review from continuous localization workflow

Context and problem statement

Idea coming from the need flagged in: Enable continuous localization for docs-gitlab-... (#764), we're transitioning to a continuous translation workflow now that all, or almost all, docs wbesite content has been processed through the pipelines.

Key considerations:

• Human review won't be needed for all Phase 2 + 3 files and will take considerable time to organize.
• Phase 2 + 3 translation requests have been open so long that source files are significantly outdated, which will cause problems reviewing the Translation MRs and it's not helping make our JA site updated.
• Source files need more frequent translation cycles while human review is being organized
• Current workflow creates mixed "AI Translation MRs" with varying TM leverage (100% and 101% matches from previous reviews)

Solution approach: Decouple human review from the continuous localization workflow so that:

• Source files are translated more frequently without waiting for human review
• Human review edits accumulate in the translation memory (TM), improving leverage over time
• We maintain a single, consistent Translation MR type

Important references

• Enable continuous localization for docs-gitlab-... (#764)
• Implement AI-from-human decoupled workflow usin... (#797 - closed)

Plan

1. Assessment

• a. Get a list of all the files currently in open GITTECHA translation requests (files not yet human reviewed).
• https://docs.google.com/spreadsheets/d/1kVGMfFeMSdMs9aPohDwNzeRo2SSDSN4jgSzby3RwxDs/edit?gid=0#gid=0
• b. Determine whether to complete human review on existing Phase 2 + 3 requests or close/cancel them
• c. Monitor impact on remaining billed wordcount through Feb 1st

2. Defining human review strategy

• a. Design a file prioritization strategy
• b. Identify files requiring immediate human review
• d. Identify files requiring ongoing human review
• d. Identify files that don't require human review
• e. Define where human review will occur (Phrase step and Argo request type). New request type on Argo + Phrase or editing GITTECHA steps only is enough?
• f. Establish process with linguists and Emi to ensure TM is properly updated during human review
• g. Define decision criteria and ownership for when to initiate human review
• h. Establish SLA for AI translation turnaround in Phrase (target: faster than current 5.8 day average)
• i. Establish SLA for merging AI Translation MRs (target: significantly faster than current 11.2 day average)

3. Test and implement AI-only continuous workflow

Note

All changes must be tested on Argo clone before implementation on Argo production

• a. Argo.Remove human review steps from Argo's GITTECHA translation request template
• b. Argo. Close/cancel Phase 2 + 3 GITTECHA translation requests (depends on 1.b)
• c. Argo. Update Argo Phase priorities so Asset Dashboard detects source content updates when AI translations are merged (not just when human translations are merged). To change the "AI Merged/Closed" priority from 3 to 5
• d. Phrase. Keep Phase 2 + 3 Phrase projects open for human review to update/improve TM (separate from Argo workflow)
• e. Phrase. Determine when to close Phrase projects while ensuring linguists have a place if they want to do a human review of a certain file on a certain Phrase project.
• f. GitLab. Update Translation MR template labels as needed
• g. Argo. Create first translation requests by filtering on the Asset Dashboard by "new" and "updated".