Our flagship store serves English, Spanish, French, and Chinese from one product catalog. The obvious question is how we translate it. The better question is what happens on the morning a translation job dies halfway through a seasonal refresh.
Machine translation of catalog copy is a solved demo. Point it at a few thousand attribute values and titles, get fluent output, ship it. Then a batch fails — an API hiccup, a rate limit, a malformed attribute — and the storefront quietly serves three languages' worth of new copy and one language's worth of last season's.
The pipeline, not the call
Translation on our stack is a pipeline with an explicit state. Batches move from queued to translating to published. A batch that dies does not sit in a dead state waiting for someone to notice: it is handed back to the sync pipeline automatically and re-run, and it stays unhealthy and visible until it lands.
That handoff is the whole product. Anyone can call a translation API. Keeping four languages in lockstep with one catalog — through launches, price changes, and the hundred small edits a merchandiser makes in a week — is an operations problem, and it is solved with recovery paths and health checks, not with a better prompt.
One source of truth
The catalog is authored once. Translations are derived artifacts, regenerated whenever the source moves, never edited in place — because the moment a translated title becomes a second source of truth, the languages drift apart and stay drifted.
For a brand, that means the French storefront never carries a discontinued product, the Chinese storefront always shows this week's price, and nobody runs a translation project. The languages stay current because staying current is the pipeline's default state, not a quarterly initiative.