Where Shopify Multilingual Setup Breaks Without Warning

A merchant pinged me last week. Her store sells handmade ceramics, primary language Japanese, secondary English. Three days earlier she had accepted a Horizon point update. The product pages now showed the original auto-translated copy on half her catalog and nothing - empty strings - on the rest. The Translate and Adapt app said the translations existed. The storefront disagreed. If you want to check whether you are in the same hole, the diagnostic is fast: Settings > Languages > Manage on your default language. The translations count tells you if anything dropped.

This is what a broken shopify multilingual setup looks like from the outside: the admin reports everything as translated, the storefront shows the source language, and nothing in between explains why. Over the next two hours I worked through what I thought were the obvious suspects, hit four dead ends, and finally found the cause in a place I almost did not check. I am writing this as the chase rather than the lesson because the dead ends are why the post is worth your time. If you want the lesson and want to skip the trail, scroll to the last section.

What I ruled out in the first ten minutes

Browser cache first. Hard refresh on her phone, on mine, in a fresh incognito session from a Japanese IP. The pages still rendered untranslated.

Cookie state. She had toggled the language picker between English and Japanese a few times that morning, which can put the storefront into a transitional state. I cleared the locale cookie and her geolocation cookie. No change.

T&A status. The app was installed, billing was current, and the in-app dashboard showed her last manual translation pass from late January. The count was right. The matching was wrong.

Other apps interfering. She had a free shipping bar, a review widget, and a popup app. I duplicated her live theme into a draft, disabled every app embed, and previewed. Still untranslated.

Theme version. Confirmed Horizon 3.4.2, which she had been on for two days. I asked when she made the most recent translation edit. February 9. The theme update happened February 11. There was the rough shape of the problem, but I wanted to see the mechanism before believing it.

Where I went next: the Translation API

This is where most merchants do not have the tooling and end up filing a support ticket. If you have GraphQL access through a custom app, you can query the Translation API directly:

{
  translatableResource(resourceId: "gid://shopify/OnlineStoreTheme/{theme_id}") {
    translations(locale: "ja") {
      key
      value
    }
  }
}

Plug in her current theme_id and the query came back with an empty array. Plug in the previous theme_id, which I pulled out of her admin's Theme library page, and it came back the same way. Empty.

I did not believe it at first. Twenty minutes earlier she had walked me through her January translation work, paragraph by paragraph, and she had screenshots. Whatever the API was returning, the data had existed.

The first lead I chased was permissions. Her custom app token had read_translations and I checked the scope on each call. Authorized. The API was not refusing the request. It was returning a real, empty list.

Where the trail went cold

I spent the next thirty minutes looking in the wrong places.

Locale files. Some translated content on Shopify lives in the theme's locales/*.json files rather than the Translation API. I opened her current theme's Edit Code panel and read through ja.json. The file existed and had Shopify's default Japanese strings. Her edits were not in there. They were never going to be in there. Locale files cover theme-level UI strings (button labels, error messages); merchant-authored product copy goes to the Translation API. I knew that and looked anyway because I was stuck.

Markets settings. Multi-market stores can have language-by-market overrides that confuse the picture. She had a single market and the language toggle was straightforward. Not it.

Old theme rollback. I cloned the previous theme version back to draft. The theme editor loaded, the templates rendered as expected, and the storefront preview still showed the untranslated copy. The translations were not in the old theme either.

That last result was the one that stopped me. I had been operating on the assumption that the translations lived somewhere and we just needed to find the right resource ID. After the old theme came up empty as well, I started looking for a different explanation.

The clue I almost missed

I went back to a 2023 Shopify Community thread that lives in the back of my head for these. Specifically, a post from a Shopify Staff member explaining that theme-level translations are stored against the active theme_id at the time of authoring, and each theme version generates new element IDs for translatable fields. When a theme updates, the new template files have new IDs and the old translations point at IDs that no longer exist on any live or draft theme in the store.

The translations are not deleted. They are orphaned. The API returns an empty array because there is nothing the request can resolve. The records sit somewhere in Shopify's database, but you cannot read them through any documented surface.

The official workaround that Shopify Staff documented in that same thread is to export the translation CSV from the old theme before updating, use VLOOKUP in a spreadsheet to map the old element IDs to the new ones, and reimport. The thread has a 2024 follow-up from a merchant who tried exactly this and could not get the import to restore the translations. The workaround is documented and does not work in practice.

She had not exported the CSV before the theme update. Most merchants have not. The Translate and Adapt setup guide does not mention it.

What actually broke, in plain language

A shopify multilingual setup using T&A treats your default-language manual translations as theme-bound state. Update the theme, lose the state. Shopify confirms this is intentional design rather than a bug.

There is one more piece. The CSV export at Settings > Languages > Export covers your additional languages (her English) but not the default language (her Japanese). So even if she had run the export ritualistically before every update, the Japanese product copy she had spent two days writing in January would not have been in the file.

The half-empty pattern she saw - some pages translated, some blank - comes from the resource type asymmetry. Product and collection translations live against the Product and Collection resource IDs, not against the theme. Those survive theme updates. Section translations, block content, theme-editor blocks: those live against the theme and orphan. Her product pages still had the product-level translations, which is why the titles and descriptions survived. The section text (homepage features, footer copy, custom section blocks) had been authored as theme-level translations and was gone.

What we did about it

A few short answers and a longer one.

For the immediate damage: she had a Notion doc with her January translation work, copied in as she went. We pasted those strings back into T&A on the new theme over the course of an afternoon. If she had not had that doc, the only option was Shopify Support, who can sometimes recover orphaned translation records from the underlying datastore. Sometimes is the word; I have seen them deliver and I have seen them say no.

For the next time: before every theme update, export her two CSVs (the additional-language one is automatic; the default-language one requires copy-paste from a GraphQL query into a sheet). I gave her the query. I am also recommending she stage every theme update on a duplicate first, run a translation check on a small set of representative pages, and only publish if the duplicate's translations render correctly. That last step is not in the official Shopify update flow. It should be.

For longer term: she is going to look at Weglot. The price is genuinely painful at her revenue level. The reason it might still be worth it is that Weglot stores translations against URLs, not theme_ids, so theme updates do not affect her translation work at all. I told her this with the explicit caveat that Weglot is not free of gotchas; the third-party app widget problem is real and Weglot solves it for maybe ninety percent of widgets, not all. If you are weighing this trade-off and you want a second pair of eyes on your specific T&A configuration before the next theme update, that is one of the situations help1's chat is a good fit for - we look at the actual theme delta and the actual translation bindings before recommending anything.

Three other things I now check on every multilingual audit

After the theme-update story I started checking for three adjacent failures on every shopify multilingual setup I audit. None of these is the bug; all three appear independently.

Third-party app widgets. Review widgets, free shipping bars, size guides, and post-purchase upsell modals load their DOM content via JavaScript after the page is interactive. Translation layers run at page load. The widget renders in the source language, the rest of the page in the target language. The customer sees a mostly-translated page with one or two English islands. This is device-dependent and invisible in desktop testing. The fix is one of two things: replace the app with one that stores its strings in Shopify metafields, or use Weglot, which intercepts DOM updates and catches more late-loading content than T&A.

Custom product option values. Standard option types (Size, Color, Material with predefined values) translate cleanly through T&A. Merchant-defined custom option values (engraving choices, personalization fields, custom bundle picks) do not. A Shopify Community thread from May 2026 documents this as a known limitation tied to how the ProductOption and ProductOptionValue resources are exposed via the Translation API, with no fix as of the thread's last reply. If your store sells anything bespoke, check the option dropdowns in your target language before going live.

Transactional emails. Shopify attributes a customer's language at the moment of their first order. Every confirmation, shipping update, and review request after that uses the attributed language regardless of what the customer currently sees on the storefront. A 2023 Shopify Community post by a Shopify Staff member labels this as working-as-designed; a 2025 follow-up confirms the bug is still live. The practical effect is that a French customer who places her first order while browsing your English site will get English confirmation emails forever. There is no native way to update an existing customer's attributed language. For Quebec stores under Bill 96 enforcement, this is a live compliance risk.

What I tell merchants now

A shopify multilingual setup is the layered kind of feature: product resource translations, theme resource translations, app DOM injections, customer-level email language. At least one of those bindings is going to surprise you. The thing nobody told the merchant I worked with last week is that updating her theme would silently empty a category of translations she had spent two days on, because the documentation files that fact under a Staff post in the Community forum rather than in the T&A help center. She read the Translate and Adapt setup page. The page did not mention theme_id binding.

If you are about to roll out a shopify multilingual setup, the cheapest thing you can do is treat your default-language manual translations as work-in-progress that lives somewhere outside Shopify. Keep them in a Notion doc, a spreadsheet, a plain-text file, anywhere you actually own the data. If you already have a multilingual setup live and you are not sure what is bound to what, the theme update angle is the one to test first, because that is the most expensive failure mode to discover after the fact.

Multilingual on Shopify behaves itself right up until the moment it does not, and the moment is usually a routine theme update on a Tuesday.