소스 변경 감지는 번역 검토를 정직하게 유지합니다

번역은 정확할 수 있어도 이미 오래된 상태일 수 있습니다.

이런 일은 번역이 시작된 뒤 편집자가 소스 항목을 변경할 때 발생합니다. 현지화된 초안은 여전히 원래 스냅샷을 반영하지만, 검토 화면에는 최신 소스가 표시될 수 있습니다. 워크플로가 그 차이를 표시하지 않으면, 검토자는 실제로는 서로 비교된 적이 없는 두 콘텐츠를 승인하게 될 수 있습니다.

소스 변경 감지는 이런 조용한 불일치가 릴리스에 포함되는 일을 막아줍니다.

번역은 스냅샷에서 시작됩니다

모든 번역 요청에는 소스 경계가 있습니다. 즉, 특정 시점의 필드 집합, 값, 리치 텍스트 구조입니다.

그 스냅샷은 요청과 함께 저장되어야 합니다. 그래야 모델이 무엇을 받았는지, 검토자가 무엇을 평가하고 있는지, 타깃 초안이 왜 현재의 내용을 담고 있는지 설명할 수 있습니다.

표시를 위해 소스를 다시 가져오는 것은 유용하지만, 그것이 과거의 스냅샷을 대체해서는 안 됩니다. 워크플로에는 둘 다 필요합니다.

• 초안을 생성하는 데 사용된 소스
• CMS의 현재 소스

첫 번째가 없으면 초안에는 신뢰할 수 있는 출처 정보가 없습니다. 두 번째가 없으면 팀은 페이지가 이미 변경되었다는 사실을 알 수 없습니다.

모든 변경이 모든 것을 무효화하는 것은 아닙니다

타임스탬프만으로도 항목이 변경되었다는 사실은 알 수 있지만, 번역이 오래되었는지는 알 수 없습니다.

편집자가 내부 메모를 수정하거나, 현지화되지 않는 필드에 에셋을 추가하거나, 요청에 포함되지 않았던 필드를 바로잡을 수 있습니다. 그런 변경이 반드시 현지화된 초안을 막아야 하는 것은 아닙니다.

대신 번역된 필드 수준에서 비교해야 합니다. 소스 제목이 바뀌었다면 제목 초안을 오래된 것으로 표시하십시오. 본문만 바뀌었다면 검토가 끝난 제목은 그대로 유지하고 본문만 다시 주의가 필요하도록 돌려보내십시오.

범위를 좁힌 무효화는 완료된 작업을 보존하면서도 남아 있는 위험을 명확하게 드러냅니다.

검토자에게 실제 차이를 보여주십시오

"소스가 변경됨"은 경고이지 결정이 아닙니다.

검토자는 원래 스냅샷과 현재 값 사이에서 무엇이 바뀌었는지 확인할 수 있어야 합니다. 일반 텍스트라면 단어 수준 diff로 충분할 수 있습니다. 리치 텍스트라면 제거된 링크, 새 목록 항목, 달라진 임베드 항목 같은 구조적 변경도 비교 결과에 드러나야 합니다.

유용한 질문은 단순히 문자열이 다른지 여부가 아닙니다. 승인된 타깃이 현재 소스를 여전히 정확하게 나타내는지 여부입니다.

팀에 신중한 선택지를 제공하십시오

번역된 소스 필드가 변경되면, 워크플로는 작고 명확한 경로 집합을 제공할 수 있습니다.

1. 변경이 의미에 영향을 주지 않을 때 현재 번역 유지
2. 현지화된 초안을 수동으로 편집
3. 영향받은 필드만 다시 생성
4. 변경 범위가 넓을 때 요청을 번역 단계로 되돌리기

그 선택과 검토자는 기록되어야 합니다. 감사 추적 없이 해제할 수 있는 오래됨 경고는 릴리스 압박 속에서 무시되기 쉽습니다.

푸시 전에 다시 확인하십시오

검토는 소스 콘텐츠가 일치하는 상태에서 시작될 수 있지만, 또 다른 편집이 반영된 뒤 끝날 수 있습니다.

CMS로 푸시하기 직전에 소스 비교를 다시 실행하십시오. 이 마지막 확인은 승인과 전달 사이의 간극을 닫아줍니다. 검토 화면과 동일한 필드 수준 규칙을 사용해야 하며, 영향받은 쓰기만 중단해야 합니다.

자동 게시에서는 이 확인이 더욱 중요합니다. 자동화는 사람이 잠시 멈추는 단계를 없애므로, 시스템은 어떤 승인된 스냅샷을 게시할 의향이 있는지 정확해야 합니다.

핵심 요점

번역 검토는 검토 중인 소스가 초안을 만들어낸 바로 그 소스일 때만 신뢰할 수 있습니다.

원래 스냅샷을 저장하고, 이를 현재 CMS 값과 비교하고, 필드별로 변경 사항을 식별하고, 검토자가 의미 있는 차이를 신중하게 해결할 수 있게 하십시오. 소스 변경 감지는 현지화 속도를 늦추지 않습니다. 그것은 팀이 오늘의 콘텐츠에 대해 어제의 답을 자신 있게 게시하는 일을 막아줍니다.