Product catalog localization workflow

Freeze the source before translating

Export the catalog and preserve an immutable source snapshot. Record its origin, export time and revision or file hash. Assign every variant a stable identity and check for missing or duplicate identifiers before creating language jobs. Keep a manifest of the product-locale pairs you intend to process.

Separate source preparation from translation. Resolve contradictory measurements, missing units and unsupported claims with the product owner first. Normalizing a supplier export may be necessary; record those corrections as source changes and have the owner approve the resulting baseline before language work begins.

Split protected facts from editable text

Create a protected record for SKU, price, currency, unit, variant relationship and other operational values. Generate only a text patch. At assembly time, copy protected values directly from the source and compare them again, so a model cannot become the authority for a field it merely saw as context.

Make claims traceable too. Keep approved assertions linked to their evidence and tell the drafting step to flag anything unsupported. The following configuration is an illustrative pipeline policy, not a file accepted by Shopify or WooCommerce. Your adapter must map it to the actual destination contract.

{
  "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"
}

Attach a glossary and locale brief

A locale brief should identify the audience, tone, approved terminology and presentation rules. Keep product concepts separate from preferred spellings. W3C ITS defines terminology and translation metadata that can inform a richer localization system; this workflow uses a simpler versioned editorial record.

Resolve ambiguous terms with examples from the actual category. If a glossary entry changes, identify affected candidates and decide whether they need regeneration or a targeted edit. Keep each locale tied to the same approved source. Do not let one translated version become an unreviewed intermediate source for the rest.

Local case: 20 products, 40 language patches

A frozen catalog of 20 synthetic products was translated into 20 Japanese and 20 German patches by a translation agent explicitly configured for gpt-5.6-luna with xhigh reasoning. Each patch contains only sku, locale, title and description. The assembler copies price, currency, material and dimensions from source.json, so preserving those facts is a property of the pipeline rather than a copying task delegated to the model.

The saved validated-ja.json and validated-de.json each contain 20 rows and an empty failures list. Read-only reassembly matches both saved outputs. Use this pattern in your own batch: retain the source revision, save language patches separately, and validate coverage and permitted fields before assembling the review package.

Run deterministic checks before editorial review

Validate the output schema, allowed fields, identifier mapping, source revision, required text and protected values. Compare placeholder counts using the application's real template grammar. Parse markup rather than applying a general text substitution to HTML. Hold malformed records instead of asking the importer to repair them.

For spreadsheet review files, OWASP documents formula-injection risks and the absence of a universal safe CSV transformation. Use a reviewed export policy for the chosen spreadsheet tool, and keep that artifact distinct from the machine import. Adding an escape prefix for human viewing must not accidentally alter a SKU in the store payload.

Bind review decisions to content revisions

Give reviewers source facts, glossary context, the candidate and structured issues. Require factual and language decisions separately. Record who approved the content and which revisions they saw. A reviewer may accept a localized phrase while holding a claim that needs evidence; the record should express that distinction.

In the local case, AI review corrected Japanese DEMO-003 from wording implying corrugated cardboard to wording consistent with the source's cardboard backing. It also clarified DEMO-010 to mean two handles in total. The original output remains in raw-ja.json. Both assembled languages still carry review_status: unreviewed and translation_semantic_review: pending: these corrections are not native-speaker or merchant approval.

Assemble and verify the destination package

Select approved, source-current candidates and transform only their permitted fields. Shopify's translation API uses its resource and digest contract; a WooCommerce deployment requires its product mapping and, for multiple languages, the verified localization layer. The generic review package is not itself a universal store import.

Test a small authorized import in staging. Save the importer result, read back the targeted fields, and inspect product and locale behavior. Reconcile the planned product set with stored outcomes. Keep failed rows separate and preserve previous values for a carefully scoped reversal if needed.

Record the result and its limits

The completed manifest should link source, glossary, prompts, candidates, checks, approvals and destination results. Record actual usage for every attempt where evidence is available, including retries. Keep missing usage and missing review results explicitly unknown. A file that can be parsed is not proof that a shop accepted it.

For the bounded local case, the selected model was Luna, not Astra, and there was no gateway call or real store import. API usage, request IDs and billing were not exposed; model_api_usage and model_api_cost remain null, not zero. The next step is semantic approval followed by a separately authorized destination test.

FAQ