Localisation for Shopify apps: a practical, top-level view
TL;DR
Why localisation matters for embedded apps, how teams usually tackle it without drowning in keys, and a high-level flow—from strings to shipped locales—that scales to many languages.

Why localisation is worth the effort
Merchants use Shopify in dozens of languages. When your app embeds in the admin—or surfaces text to customers on the storefront—English-only copy is a ceiling on adoption. Localisation is not “nice to have”; it is part of making the product feel native to the person using it.
For our own apps—Waitlist Flow and Shiftify—we recently expanded coverage so both are available in 19 languages. That did not happen by accident; it came from treating localisation as a repeatable process, not a one-off project.
What “localisation” means here (without the jargon)
At a high level, localisation is three things working together:
- Strings live in one place conceptually — every piece of user-visible text is something you can find, update, and ship in more than one language.
- You pick a source language — usually English — and treat it as the reference every other language aligns to.
- You verify in context — labels, buttons, and messages must read well inside Shopify’s admin and in your own flows, not only in a spreadsheet.
You do not need to memorise framework names to get value from that mental model.
The usual pain (and a better direction)
Many teams start with opaque translation keys—short codes that stand in for real sentences. That can work at huge scale, but for product teams it often adds friction: you write settings.billing.title instead of the words a merchant will see, and every change means hunting keys across many files.
Beckett Oliphant describes a different mindset in How to automate translation for a React app: keep the authoring experience human (plain language as the source of truth), then use automation to collect what is missing, translate, and merge back into locale files. The article goes deeper into scripts and AI-assisted workflows; the takeaway for this post is simpler—separate “writing copy” from “maintaining dozens of files by hand.”
We drew inspiration from that kind of programmatic translation idea: one command to see what changed, a controlled step to fill gaps, then merge—rather than manually diffing JSON across nineteen locales for every small UI tweak.
A top-level process that scales
Here is the shape of a workflow that works well for Shopify-style apps, whether you use keys or natural phrases as your source:
1. Decide what you are translating
Start with merchant-facing admin copy first—it is where reviewers and paying users spend most of their time. Then customer-facing strings (emails, storefront surfaces) where they matter for your product. Not every string needs day-one coverage; prioritise paths that block understanding or conversion.
2. Establish a single source of truth
Whether your strings are keys or full English sentences, one canonical locale (typically English) anchors everything else. Other language files should follow that source, not drift into their own vocabulary for the same button.
3. Extract, translate, merge—on a rhythm
On each meaningful release (or on a schedule), you:
- Discover what is new or changed since the last pass.
- Translate those items—human review, vendor, or assisted workflow—into a batch.
- Merge into per-locale files and prune obsolete entries so files do not rot.
That loop is the heart of “programmatic” localisation at the organisational level: less manual archaeology, more predictable batches.
4. Check the real experience
Languages differ in length and direction. A label that fits in English may truncate or wrap in German or Finnish. Build time in the actual embedded admin (and on a couple of representative themes if you touch the storefront) so you catch awkward breaks before merchants do.
5. Treat localisation as ongoing hygiene
New features mean new strings. The goal is not “we translated once” but “localisation keeps up with the product.” Pairing the merge step with your release process avoids a growing backlog of untranslated corners.
What nineteen languages taught us
Shipping Waitlist Flow and Shiftify in 19 languages reinforced a few practical lessons:
- Batching beats heroics — small, regular updates are easier than giant catch-up sprints.
- Cleanup matters — removing dead keys keeps translators (and tools) focused on what users still see.
- Context wins — a string that is clear in isolation can be ambiguous on a crowded settings row; reviewing in the UI catches that early.
Further reading
For a concrete walkthrough of automating extraction, using a single “to translate” file, and merging translations back into locale JSON—with React-style examples—see Beckett Oliphant’s post: How to automate translation for a React app.
Reiwa Dev builds Shopify apps with merchants in mind. If you are shipping in more than one market, investing in localisation early pays dividends in trust, support load, and App Store fit.