Detektering av källändringar håller översättningsgranskningar ärliga

En översättning kan vara korrekt och ändå vara inaktuell.

Det händer när en redaktör ändrar källposten efter att översättningen har påbörjats. Det lokaliserade utkastet återspeglar fortfarande den ursprungliga ögonblicksbilden, men granskningsvyn kan visa den senaste källtexten. Om arbetsflödet inte markerar skillnaden kan en granskare godkänna två innehållsdelar som aldrig faktiskt har jämförts.

Detektering av källändringar hindrar att denna tysta diskrepans når en release.

Översättning börjar från en ögonblicksbild

Varje översättningsbegäran har en källgräns: en uppsättning fält, värden och rich-text-strukturer vid en viss tidpunkt.

Den ögonblicksbilden bör sparas tillsammans med begäran. Den förklarar vad modellen fick, vad granskaren utvärderar och varför målutkastet säger det som det säger.

Att hämta källtexten på nytt för visning är användbart, men det får inte ersätta den historiska ögonblicksbilden. Arbetsflödet behöver båda:

• källan som användes för att generera utkastet
• den aktuella källan i CMS

Utan den första har utkastet ingen tillförlitlig proveniens. Utan den andra kan teamet inte se att sidan har gått vidare.

Inte varje ändring ogiltigförklarar allt

Enbart en tidsstämpel kan tala om att en post har ändrats, men inte om översättningen är inaktuell.

En redaktör kan uppdatera en intern anteckning, lägga till en tillgång i ett icke-lokaliserat fält eller rätta ett fält som inte ingick i begäran. Dessa ändringar bör inte nödvändigtvis blockera det lokaliserade utkastet.

Jämför i stället på nivån för översatta fält. Om källtiteln ändrades, markera titelutkastet som inaktuellt. Om bara brödtexten ändrades, behåll den granskade titeln intakt och återför brödtexten till uppmärksamhet.

Snäv ogiltigförklaring bevarar färdigt arbete samtidigt som den återstående risken görs explicit.

Visa granskarna den faktiska skillnaden

"Källan ändrades" är en varning, inte ett beslut.

Granskare behöver se vad som ändrades mellan den ursprungliga ögonblicksbilden och det aktuella värdet. För vanlig text kan en diff på ordnivå vara tillräcklig. För rich text bör jämförelsen också visa strukturella ändringar, såsom en borttagen länk, en ny listpunkt eller en annan inbäddad post.

Den användbara frågan är inte bara om strängarna skiljer sig åt. Den är om den godkända måltexten fortfarande representerar den aktuella källtexten korrekt.

Ge teamet medvetna val

När ett översatt källfält ändras kan arbetsflödet erbjuda en liten uppsättning tydliga vägar:

1. behåll den nuvarande översättningen när ändringen inte påverkar betydelsen
2. redigera det lokaliserade utkastet manuellt
3. regenerera endast det påverkade fältet
4. skicka tillbaka begäran till översättning när ändringen är omfattande

Valet och granskaren bör registreras. En varning om inaktuellt innehåll som kan avfärdas utan ett granskningsspår är lätt att ignorera under releasepress.

Kontrollera igen före push

En granskning kan börja med matchande källinnehåll och sluta efter att ännu en redigering har gjorts.

Kör källjämförelsen igen omedelbart innan du pushar till CMS. Denna sista kontroll stänger gapet mellan godkännande och leverans. Den bör använda samma regler på fältnivå som granskningsvyn och bara stoppa de påverkade skrivningarna.

För automatiserad publicering är kontrollen ännu viktigare. Automatisering tar bort en mänsklig paus, så systemet måste vara exakt med vilken godkänd ögonblicksbild det är villigt att publicera.

Slutsats

Översättningsgranskning är bara tillförlitlig när källan som granskas är källan som skapade utkastet.

Lagra den ursprungliga ögonblicksbilden, jämför den med aktuella CMS-värden, identifiera ändringar per fält och låt granskare hantera betydelsefulla skillnader medvetet. Detektering av källändringar bromsar inte lokalisering. Den hindrar team från att med självsäkerhet publicera gårdagens svar på dagens innehåll.