제품 카탈로그 현지화 워크플로

번역 전에 소스를 동결하세요

카탈로그를 내보내고 변경할 수 없는 소스 스냅샷을 보존하세요. 출처, 내보내기 시간, 리비전 또는 파일 해시를 기록합니다. 모든 변형에 안정적인 식별자를 할당하고 언어 작업을 만들기 전에 누락되거나 중복된 식별자를 확인하세요. 처리하려는 제품-로케일 쌍의 매니페스트를 유지합니다.

소스 준비와 번역을 분리하세요. 모순되는 측정값, 누락된 단위, 근거 없는 주장은 먼저 제품 소유자와 해결합니다. 공급업체 내보내기를 정규화해야 할 수 있지만 해당 수정을 소스 변경으로 기록하고 언어 작업 전에 소유자가 결과 기준선을 승인하게 하세요.

보호된 사실과 편집 가능한 텍스트를 나누세요

SKU, 가격, 통화, 단위, 변형 관계, 기타 운영 값을 위한 보호된 기록을 만드세요. 텍스트 패치만 생성합니다. 조립 시 보호된 값을 소스에서 직접 복사하고 다시 비교해 모델이 컨텍스트로 보기만 한 필드의 권위자가 되지 않도록 합니다.

주장도 추적 가능하게 만드세요. 승인된 주장을 근거에 연결하고 초안 단계에서 근거 없는 내용을 표시하도록 하세요. 다음 구성은 Shopify 또는 WooCommerce가 받아들이는 파일이 아니라 예시 파이프라인 정책입니다. 어댑터는 실제 대상 계약에 매핑해야 합니다.

{
  "identity": ["product_id", "variant_id", "locale"],
  "protected": ["sku", "price_minor", "currency", "unit", "parent_id"],
  "editable": ["title", "description", "care_text"],
  "revisionInputs": ["source", "glossary", "prompt"],
  "releaseRequires": ["field_checks", "fact_review", "language_review"],
  "destinationWrite": "separate_authorization"
}

용어집과 로케일 브리프를 연결하세요

로케일 브리프에는 독자, 어조, 승인된 용어, 표현 규칙을 식별해야 합니다. 제품 개념과 선호 철자를 분리하세요. W3C ITS는 더 풍부한 현지화 시스템에 참고할 용어 및 번역 메타데이터를 정의하지만, 이 워크플로는 버전이 있는 더 간단한 편집 기록을 사용합니다.

실제 범주의 예시로 모호한 용어를 해결하세요. 용어집 항목이 바뀌면 영향을 받은 후보를 식별하고 재생성이 필요한지 대상 편집이면 충분한지 결정합니다. 각 로케일을 같은 승인 소스에 연결하세요. 번역된 한 버전이 나머지의 검토되지 않은 중간 소스가 되게 하지 마세요.

로컬 사례: 제품 20개, 언어 패치 40개

20개의 가상 제품으로 동결된 카탈로그를 gpt-5.6-luna와 xhigh 추론을 사용하도록 명시적으로 구성한 번역 에이전트가 일본어 패치 20개와 독일어 패치 20개로 번역했습니다. 각 패치에는 sku, locale, title, description만 들어 있습니다. 조립기는 source.json에서 가격, 통화, 소재, 치수를 복사하므로 해당 사실의 보존은 모델에 맡긴 복사 작업이 아니라 파이프라인의 속성입니다.

저장된 validated-ja.json과 validated-de.json은 각각 20개 행과 비어 있는 failures 목록을 포함합니다. 읽기 전용 재조립 결과는 두 저장 출력과 일치합니다. 자신의 배치에도 이 패턴을 사용하세요. 소스 리비전을 보존하고 언어 패치를 별도로 저장하며 검토 패키지를 조립하기 전에 커버리지와 허용 필드를 검증합니다.

편집 검토 전에 결정론적 확인을 실행하세요

출력 스키마, 허용 필드, 식별자 매핑, 소스 리비전, 필수 텍스트, 보호된 값을 검증하세요. 애플리케이션의 실제 템플릿 문법으로 플레이스홀더 수를 비교합니다. HTML에 일반적인 텍스트 치환을 적용하지 말고 마크업을 파싱하세요. 잘못된 레코드는 가져오기에 수리를 맡기지 말고 보류합니다.

스프레드시트 검토 파일의 경우 OWASP는 수식 인젝션 위험과 보편적으로 안전한 CSV 변환이 없다는 점을 문서화합니다. 선택한 스프레드시트 도구에 대해 검토된 내보내기 정책을 사용하고 해당 산출물을 기계 가져오기와 분리하세요. 사람의 확인을 위한 이스케이프 접두사를 추가해도 스토어 페이로드의 SKU가 우연히 바뀌어서는 안 됩니다.

검토 결정을 콘텐츠 리비전에 연결하세요

검토자에게 소스 사실, 용어집 컨텍스트, 후보, 구조화된 이슈를 제공하세요. 사실 결정과 언어 결정을 별도로 요구합니다. 누가 콘텐츠를 승인했는지와 어떤 리비전을 보았는지 기록하세요. 검토자가 현지화된 문구는 승인하면서 근거가 필요한 주장은 보류할 수 있습니다. 기록은 이 차이를 표현해야 합니다.

로컬 사례에서 AI 검토는 일본어 DEMO-003을 골판지를 암시하는 표현에서 소스의 cardboard backing과 일치하는 표현으로 수정했습니다. 또한 DEMO-010을 총 두 개의 손잡이라는 뜻으로 명확히 했습니다. 원본 출력은 raw-ja.json에 남아 있습니다. 조립된 두 언어 모두 review_status: unreviewed와 translation_semantic_review: pending을 유지합니다. 이러한 수정은 원어민 또는 판매자 승인이 아닙니다.

대상 패키지를 조립하고 검증하세요

승인되고 소스가 최신인 후보를 선택해 허용된 필드만 변환하세요. Shopify의 번역 API는 리소스와 다이제스트 계약을 사용하고 WooCommerce 배포에는 제품 매핑과 여러 언어를 위한 검증된 현지화 계층이 필요합니다. 일반 검토 패키지 자체가 범용 스토어 가져오기는 아닙니다.

스테이징에서 소규모 승인 가져오기를 테스트하세요. 가져오기 결과를 저장하고 대상 필드를 다시 읽은 뒤 제품과 로케일 동작을 검사합니다. 계획한 제품 집합과 저장 결과를 대조하세요. 실패한 행은 분리하고 필요할 때 범위가 신중하게 정해진 되돌리기를 위해 이전 값을 보존합니다.

결과와 한계를 기록하세요

완료된 매니페스트는 소스, 용어집, 프롬프트, 후보, 확인, 승인, 대상 결과를 연결해야 합니다. 근거가 있는 모든 시도의 실제 사용량을 재시도까지 포함해 기록하세요. 누락된 사용량과 누락된 검토 결과는 명시적으로 알 수 없는 상태로 유지합니다. 파싱할 수 있는 파일이라고 해서 스토어가 받아들였다는 증거는 아닙니다.

범위가 정해진 로컬 사례에서 선택된 모델은 Astra가 아니라 Luna였고 게이트웨이 호출이나 실제 스토어 가져오기도 없었습니다. API 사용량, 요청 ID, 결제는 노출되지 않았으며 model_api_usage와 model_api_cost는 0이 아니라 null로 남아 있습니다. 다음 단계는 의미 승인 후 별도로 승인된 대상 테스트입니다.

자주 묻는 질문