번역 상태는 다음 질문에 답해야 합니다

번역 시스템은 많은 상태를 만들어 냅니다. 작업은 대기열에 들어가고, 제공업체는 응답하고, 초안은 저장되며, Contentful은 업데이트되고, 항목은 게시되며, 재시도는 시작됩니다.

이 모든 활동을 보여준다고 해서 진행 상황이 자동으로 명확해지는 것은 아닙니다.

유용한 상태는 편집자가 다음에 갖게 될 질문에 답해야 합니다.

하나의 요청에는 여러 생명주기가 있습니다

다국어 요청은 보통 세 가지 주요 단계로 이동합니다:

1. 번역
2. 푸시
3. 게시

각 단계는 유휴, 대기 중, 작업 중, 성공, 건너뜀 또는 실패 상태일 수 있습니다. 이러한 상태를 한 단어로 압축하면 중요한 정보가 사라집니다.

"완료됨"은 번역 초안이 검토 준비가 되었음을 의미할 수도 있고, 대상 로캘이 Contentful에 기록되었음을 의미할 수도 있으며, 항목이 라이브 상태임을 의미할 수도 있습니다. 이는 실질적으로 서로 다른 결과입니다.

인터페이스는 단계와 해당 상태를 함께 명시해야 합니다.

상태와 작업은 함께 가야 합니다

편집자는 다음에 무엇을 할 수 있는지 결정하기 위해 상태를 읽습니다.

• 준비된 번역은 검토할 수 있습니다.
• 승인된 번역은 푸시할 수 있습니다.
• 성공적으로 푸시된 항목은 게시할 수 있습니다.
• 일시적인 실패는 재시도할 수 있습니다.
• 진행 중인 작업은 취소할 수 있을 수 있습니다.

가능한 작업이 표시된 상태와 일치하지 않으면 제품은 일관성이 없게 느껴집니다. 한 번도 푸시되지 않은 요청 옆에 게시 버튼이 있는 것은 단지 혼란스러운 것이 아니라, 기본 워크플로에 대한 신뢰를 약화시킵니다.

백엔드는 지속 가능한 상태와 권한을 기준으로 가능 여부를 결정해야 하며, 그다음 UI는 그 결정을 일관되게 반영해야 합니다.

진행 수치는 안정적인 분모가 필요합니다

각 단계가 설명 없이 서로 다른 총계를 사용할 경우 배치 진행 상황은 오해를 부르게 됩니다.

번역 요청이 10개인 배치에는 번역 10개, 푸시 8개, 게시 6개가 있을 수 있습니다. 일부 로캘은 검토 전용이거나 자동화가 비활성화되었기 때문입니다.

진행 상황은 다음을 구분해야 합니다:

• 전체 요청 수
• 현재 단계의 대상이 되는 요청 수
• 완료, 진행 중, 실패 및 건너뛴 요청 수

특히 건너뜀은 중요합니다. 그것은 미완료 작업이 아니라 종료된 결정입니다.

화면을 복잡하게 만들지 않으면서 이력을 보존하세요

현재 상태는 간결하게 유지되어야 하지만, 문제가 발생했을 때 운영자는 여전히 이력이 필요합니다.

확장 가능한 이벤트 타임라인은 요청이 언제 대기열에 들어갔는지, 어떤 시도가 실패했는지, 자동 재시도가 실행되었는지, 그리고 Contentful이 언제 업데이트를 수락했는지를 보여줄 수 있습니다. 이렇게 하면 모든 테이블 행을 로그 뷰어로 바꾸지 않고도 디버깅을 지원할 수 있습니다.

주요 상태에는 사람이 이해하기 쉬운 언어를 사용하고, 세부 보기에는 기술 식별자와 타임스탬프를 유지하세요.

종료 상태는 종료 상태로 유지되어야 합니다

폴링과 실시간 이벤트는 순서가 뒤바뀌어 도착할 수 있습니다. 더 오래된 "작업 중" 이벤트가 완료된 요청을 이전 상태로 되돌려서는 안 됩니다. 새로고침된 페이지가 데이터베이스에 이미 성공이 기록된 뒤에도 일시적으로 대기 중을 표시해서는 안 됩니다.

상태 전환에는 순서 보장과 멱등성이 필요합니다. 인터페이스는 단순히 브라우저에 마지막으로 전달된 메시지를 받아들이는 것이 아니라, 권한 있는 타임스탬프나 버전을 사용해 업데이트를 병합해야 합니다.

핵심 요점

상태 설계는 워크플로를 꾸미는 장식이 아니라 그 일부입니다.

번역, 푸시, 게시 단계를 분리하세요. 각 상태를 그것이 가능하게 하는 작업과 연결하고, 건너뛴 작업도 정직하게 집계하며, 자세한 이력을 가까이에 두세요. 가장 좋은 상태는 다음 결정을 명확하게 만드는 상태입니다.