리치 텍스트는 진짜 번역 워크플로 테스트다

헤드라인과 짧은 설명만으로도 거의 모든 번역 워크플로가 충분히 유능해 보일 수 있습니다. 진짜 시험은 소스 엔트리에 중첩 목록, 인라인 링크, 임베드된 엔트리, 그리고 의미를 담고 있는 서식이 들어 있을 때 시작됩니다.

바로 그 지점에서 번역은 더 이상 텍스트 문제가 아니라 콘텐츠 구조 문제가 됩니다.

리치 텍스트는 문자열이 아니라 문서입니다

Contentful 리치 텍스트는 트리 형태로 저장됩니다. 문단은 텍스트 노드를 포함합니다. 목록은 목록 항목을 포함합니다. 링크와 임베드된 엔트리는 다른 콘텐츠를 가리킵니다. 마크는 굵게, 기울임꼴, 코드 및 기타 서식을 전달합니다.

그 트리를 일반 텍스트로 평탄화하면 단어는 살아남을 수 있어도 엔트리는 그렇지 못합니다.

신뢰할 수 있는 워크플로는 문서를 보존하면서 언어를 번역해야 합니다:

• 제목은 제목으로 유지되어야 합니다
• 목록 항목은 올바른 순서를 유지해야 합니다
• 링크는 대상 위치를 유지해야 합니다
• 인라인 엔트리는 편집자가 배치한 문장 안에 그대로 남아 있어야 합니다
• 임베드된 블록은 주변 본문과의 관계를 유지해야 합니다

번역 모델에게 워크플로가 명시적으로 보호할 수 있었던 구조를 다시 재구성하라고 맡겨서는 안 됩니다.

위험한 실패는 그럴듯해 보입니다

리치 텍스트 손상은 번역 검토에서 항상 눈에 띄는 것은 아닙니다. 누락된 임베드는 여전히 자연스럽게 읽히는 문단을 남길 수 있습니다. 분리된 목록은 여러 개의 그럴듯한 문단처럼 보일 수 있습니다. 인라인 엔트리는 문장이 그 빈자리를 감싸며 끝나기 때문에 사라져도 눈치채기 어려울 수 있습니다.

이 때문에 구조적 오류는 눈에 보이는 예외보다 더 위험합니다. 현지화된 엔트리가 더 이상 원본을 나타내지 않는데도 요청은 성공으로 표시될 수 있습니다.

좋은 검토 도구는 보호된 구조를 눈에 보이게 만듭니다. 편집자는 원시 JSON을 읽거나 모든 토큰이 살아남았다고 믿는 대신, 임베드, 링크, 서식이 어디에 위치하는지 확인할 수 있어야 합니다.

먼저 보호하고, 그다음 번역하세요

강력한 리치 텍스트 파이프라인은 번역 가능한 콘텐츠와 구조적 콘텐츠를 분리합니다.

모델이 문서를 받기 전에 워크플로는 보호된 노드를 안정적인 플레이스홀더로 대체할 수 있습니다. 모델은 주변 언어를 번역합니다. 그런 다음 워크플로는 원래 노드를 복원하고 모든 플레이스홀더가 정확히 한 번씩 반환되었는지 검증합니다.

이렇게 하면 책임이 명확해집니다:

• 모델은 언어를 처리합니다
• 애플리케이션은 구조를 처리합니다
• 검증은 누락되거나 중복된 보호 콘텐츠를 잡아냅니다

이 경계는 관례에 따라 CMS 문서 전체를 보존하라고 하나의 확률적 응답에 맡기는 것보다 훨씬 더 신뢰할 수 있습니다.

문장만이 아니라 계층 구조를 검토하세요

사람의 검토는 문장만 비교해서는 안 됩니다. 다음 질문에도 답해야 합니다:

1. 모든 원본 섹션이 반영되었는가?
2. 목록의 중첩 구조가 그대로 유지되었는가?
3. 링크와 임베드된 엔트리가 여전히 올바른 맥락에 연결되어 있는가?
4. 비어 있는 원본 블록이 번역 결과에 포함되지 않았는가?
5. 렌더링된 미리보기가 원본 페이지의 콘텐츠 계층 구조와 일치하는가?

마지막 질문이 중요한 이유는 구조적으로는 유효한 문서라도 여전히 어색한 페이지를 만들 수 있기 때문입니다. 미리보기는 번역된 제목이 이상하게 줄바꿈되는지, CTA가 레이아웃을 깨는지, 또는 임베드가 예상치 못한 시각적 위치에 놓이는지를 보여줍니다.

핵심 요점

리치 텍스트는 번역 워크플로가 신뢰를 얻는 지점입니다. 단어를 보존하는 것은 첫 번째 요구사항일 뿐입니다. 시스템은 또한 편집자가 그 단어들을 중심으로 구축한 문서 자체를 보존해야 합니다.

구조를 보호된 데이터로 취급하고, 저장 전에 이를 검증하며, CMS 미리보기에서 결과를 검토하세요. 리치 텍스트가 이 전체 경로를 무사히 통과한다면, 더 단순한 필드는 원래 그래야 하듯 쉬운 사례가 됩니다.