Contentful 번역 신뢰성 체크리스트

번역은 언어적으로 훌륭해도 릴리스를 실패시킬 수 있습니다.

잘못된 소스 스냅샷이 사용되었을 수 있습니다. 리치 텍스트 구조가 변경되었을 수 있습니다. 검토된 값이 Contentful에 도달하지 않았을 수 있습니다. 업데이트가 존재하지만 게시되지 않았을 수 있습니다. 신뢰성은 하나의 모델 응답을 최적화하는 것이 아니라 전체 경로를 보호하는 데서 나옵니다.

번역 전

명확한 소스 경계부터 시작하세요.

• 정확한 Contentful 엔트리와 환경을 식별합니다
• 소스 및 대상 로케일을 캡처합니다
• 번역 대상 필드만 로드합니다
• 링크, 임베드, 마크 및 번역 불가 구조를 보존합니다
• 모델, 프롬프트 및 용어 규칙을 기록합니다
• 비어 있는 소스 필드가 포함되는지 표시합니다

생성 전에 요청 범위가 모호하면 이후 모든 단계가 그 모호성을 물려받습니다.

생성 중

공급자 호출은 검토를 지원할 수 있을 만큼 관찰 가능하고 반복 가능해야 합니다.

응답에 예상된 모든 필드와 보호된 플레이스홀더가 포함되어 있는지 검증하세요. 그럴듯해 보이는 조각을 살리려 하기보다 잘못된 구조화 출력을 거부하세요.

재시도는 동일한 요청 범위를 재사용해야 합니다. 다른 모델이나 프롬프트가 선택되면 결과를 새로운 시도로 취급하여 검토자가 초안이 왜 바뀌었는지 이해할 수 있게 하세요.

검토 중

검토에는 세 가지 상태가 나란히 필요합니다:

1. 번역에 사용된 소스 값
2. Contentful의 현재 대상 값
3. 제안된 현지화 초안

이렇게 하면 오래된 소스 데이터를 드러내고 기존 현지화 작업을 보호할 수 있습니다.

리치 텍스트의 경우 언어와 계층 구조를 모두 검토하세요. 레이아웃, 링크 또는 임베드된 콘텐츠가 페이지에 영향을 미치는 경우 승인 전에 CMS 미리보기를 여세요.

검토자가 수행한 편집은 최종 푸시에서 사라지지 않고 저장된 초안 기록의 일부가 되어야 합니다.

푸시 중

가능한 가장 작은 변경만 작성하세요.

승인된 대상 로케일 필드만 푸시하세요. 현재 Contentful 엔트리를 다시 가져오고, 관련 없는 값은 보존하며, 최신 엔트리 버전을 사용하세요. 검토가 시작된 후 동일한 대상 필드가 변경되었다면 자동으로 덮어쓰지 말고 판단을 위해 중단하세요.

Contentful이 어떤 필드를 언제 수락했는지 기록하세요. 성공적인 API 응답은 UI가 완료를 알리기 전에 지속 가능한 요청 상태에 매핑되어야 합니다.

게시 중

푸시와 게시는 별개의 결과입니다.

엔트리가 구성된 게시 모드의 대상인지, 그리고 사용자가 게시 권한을 가지고 있는지 확인하세요. 게시가 자동이라면 그 실패를 번역 및 푸시 성공과 독립적으로 유지하세요.

요청은 전체 워크플로를 일반적인 실패로 뭉뚱그리지 말고 "푸시됨, 게시 실패"를 명확히 보여줘야 합니다.

복구 중

신뢰할 수 있는 시스템은 공급자가 타임아웃되고, 네트워크가 중단되며, CMS 버전 충돌이 발생한다는 점을 전제로 합니다.

• 일시적 오류는 제한된 범위 내에서 재시도합니다
• 실패한 단계부터 재개합니다
• 성공한 번역과 푸시는 그대로 유지합니다
• 가장 최근의 실행 가능한 오류를 노출합니다
• 진행 중인 작업을 안전하게 중단할 수 있는 경우 취소를 허용합니다
• 실시간 이벤트가 없어도 폴링을 통해 최종 상태를 복구할 수 있게 합니다

복구는 작업을 보존해야지, 반사적으로 처음부터 다시 시작해서는 안 됩니다.

핵심 요점

Contentful 번역에 단 하나의 신뢰성 기능이 있는 것은 아닙니다.

신뢰는 모든 경계에서의 세분화된 안전장치에서 나옵니다: 명시적 범위, 보호된 구조, 비교 가능한 검토 상태, 최소 쓰기, 분리된 게시 상태, 그리고 단계 인식 복구. 이러한 제어가 함께 작동할 때 팀은 모든 다국어 릴리스를 도박처럼 여기지 않고도 빠르게 움직일 수 있습니다.