The multi-language subscription portal, in detail

Which languages are supported out of the box

Modern subscription portals typically ship with 12–16 languages translated by default. The default set covers the major European markets, the main Asian languages, and a few Nordic languages where Shopify has high merchant density. The exact list varies by vendor, but the overlap between major apps is large enough that you can plan for the same core set whichever app you pick.

• English, Spanish, French, German, Italian, Portuguese (PT-PT and PT-BR usually distinct)
• Dutch, Swedish, Danish, Norwegian (Bokmål), Finnish
• Polish, Czech (sometimes), Russian (sometimes, depending on vendor policy)
• Japanese, Simplified Chinese, Traditional Chinese, Korean
• Arabic and Hebrew (RTL — covered separately below)

If you sell in a language outside this default set — say Vietnamese, Thai, Greek, Hungarian — most apps let you add custom translations via a JSON upload or per-string admin override. It's a one-time effort and the file is portable across stores, so if you have an agency or contractor who builds Shopify stores for a regional market, they often have the file already.

How translation strings are structured

Under the hood, every visible string in the portal has a translation key. The English value is the default, and each other language has its own value for the same key. When the portal renders a page, it looks up the key in the subscriber's selected language, falls back to English if the key is missing, and renders the string.

This matters because it tells you what you can and can't edit. You can edit any string per language — change the French version of the skip button without affecting the German version. You can add custom keys if your app supports it (less common). You cannot insert HTML or React components into a translation value safely; what's allowed is plain text, sometimes with simple variable placeholders like {nextOrderDate}.

• Each language has its own copy of the editable-strings table — edits in one don't affect the others
• Placeholders use a templating syntax (typically {variableName} or %{variableName}) — preserve these exactly when translating
• Pluralization is usually handled per-language (English has 'singular/plural'; Russian/Polish have more forms; Japanese/Chinese often have just one form)
• Date and number formats are not in the translation strings — they're handled by the locale layer separately
• Currency symbol placement (€10 vs 10 €) follows the locale, not the translation string

If you have an in-house translator or agency, give them direct admin access to the string editor rather than handing over a CSV. The reason: context matters enormously for short interface strings. 'Skip' in isolation might be translated as 'Hop over' when the right translation is 'Postpone' — but a translator looking at the live portal sees the button next to the next-order date and gets the context immediately.

How the portal picks a subscriber's language

Three signals are used, usually in this priority order: explicit subscriber selection (the language picker in the portal), the Shopify customer record's locale (set at checkout), and the browser's Accept-Language header. The first one set wins.

This is mostly invisible — subscribers land in the right language without thinking about it. The places it goes wrong are predictable: a subscriber who originally checked out in English but now lives in Berlin will see English forever unless the customer record updates. A subscriber on a shared device with English browser settings will see English even if their personal preference is Spanish. Both cases are why the language picker in the portal matters — give subscribers an easy override.

When a subscriber changes their language in the portal, the change should persist for future sessions — typically stored against the customer record so it propagates back to Shopify too. The next renewal-reminder email then arrives in the right language without the subscriber having to do anything else.

Right-to-left languages: Arabic, Hebrew, and what flips

Arabic, Hebrew, Farsi, and Urdu read right-to-left. A portal that supports RTL doesn't just translate the text — it flips the layout direction so the entire interface mirrors. Buttons on the right become buttons on the left, the back arrow points the other way, the date picker opens from the opposite side, and so on.

What does not flip: numbers (still read left-to-right inside RTL text), product photography, logos, and currency amounts. The portal handles this automatically via CSS logical properties (margin-inline-start instead of margin-left, etc.) so the layout adapts without breaking when the language changes.

• Layout direction: dir="rtl" applied at the document root flips block-level positioning automatically
• Icons that imply direction (arrows, chevrons) need to flip — most portals handle this automatically with CSS transforms
• Numbers and dates render LTR inside RTL text — typical browser behavior, no custom config needed
• Custom CSS overrides may break in RTL if they use left/right instead of logical properties — test custom CSS in both directions
• Magic-link email needs separate RTL handling — verify the email template renders correctly in Arabic before launching to that market

What happens when a string isn't translated yet

Falling back from a missing translation is one of those small decisions that has a disproportionate impact on perceived polish. Three strategies exist, with different trade-offs.

1. Fall back to English — the default and safest option. Subscribers see English where the translation is missing, which is suboptimal but not broken. Used by most portals.
2. Show the key name — useful in development (you immediately see which keys are missing), bad in production (subscribers see 'portal.skip_button.label' instead of a real word).
3. Fall back to a related language — Spanish missing falls back to Portuguese, Norwegian missing falls back to Danish. Rare; only some portals support this, and it can produce confusing results when the languages diverge.

The right default is fall-back-to-English. The reason: English missing renders something coherent (slightly off-brand), whereas key-name renders something broken. Most portals let you check which keys are missing in your active languages from an admin report so you can fill the gaps over time.

If you're launching in a language progressively, prioritize translating the high-traffic strings first: the welcome message, the four primary action buttons, the confirmation messages, the next-order-date label, and the entire magic-link email. These represent ~80% of what subscribers read. Edge-case error messages can lag behind without obvious damage.

Why brand-translated copy outperforms machine translation

The default translations that ship with subscription portals are competent and generic. They're typically professional human translation, but they were done once by a translator who didn't know your brand. The English source says 'Manage your subscription' and the French translation says 'Gérez votre abonnement'. Both are accurate. Neither sounds like your store.

When you edit the English copy to match your brand voice — say, 'Your next box' instead of 'Manage your subscription' — the other languages stay at the original generic default unless you edit them too. So a subscriber who reads English sees 'Your next box' and a subscriber who reads French sees 'Gérez votre abonnement'. Same store, different feeling.

The fix is brand-voice translation: hire a translator (or use a bilingual team member) to translate your edited English copy into each language you sell in. This is genuinely high-leverage work — the LTV impact of subscribers who feel the portal speaks their language naturally is large enough that even a few hundred dollars per language pays for itself within the first cohort.

• Edit your English copy first — that becomes the source of truth
• Use DeepL or GPT-4 to generate first-draft translations of the edited English
• Have a native speaker review each draft for tone, formality (tu vs vous, du vs Sie), and dialect (es-ES vs es-MX)
• Publish to the per-language string editor; verify in a real subscriber session in that language
• Iterate based on real subscriber sessions — your sample size will be small early but the data still beats guessing

Date, currency, and number formatting per locale

Localization is more than language. Subscribers in different locales expect different date formats (15/10/2026 in the EU, 10/15/2026 in the US, 2026-10-15 in ISO/Japan), different number separators (1,000.00 in the US, 1.000,00 in Germany, 1 000,00 in France), and different currency-symbol placement ($10 in the US, 10 € in France, € 10 in the Netherlands).

Most subscription portals handle this automatically via the subscriber's locale — set the language to French and the dates render as DD/MM/YYYY without any extra config. The currency follows the Shopify market the subscription is in, not the language. A French-speaking subscriber in Canada sees CAD prices in French formatting; a French-speaking subscriber in France sees EUR prices in French formatting. The combination matters; don't assume language = country.

• Date format — follows locale, not language; en-US is MM/DD/YYYY, en-GB is DD/MM/YYYY
• Number separator — period vs comma, follows locale
• Currency symbol placement — follows locale; the symbol comes from the Shopify market's currency, not the language
• Time formats — 12-hour vs 24-hour follows locale (US is 12-hour, most of Europe is 24-hour)
• Week start day — Monday in most of Europe, Sunday in the US; affects calendar pickers

When you don't actually need multi-language

Multi-language is a real feature with a real maintenance cost. If 95% of your subscribers are in one market and one language, the right answer is to launch in that language and skip the rest. A polished single-language portal beats a half-finished multi-language one.

The threshold is roughly this: if a second language would cover more than 10% of your subscribers, it's worth translating. If it covers less than 5%, the marginal subscribers in that language are probably better served by a clean English fallback. Between 5–10% is judgment — translate if you already have the language capability in-house, skip otherwise.

The ongoing translation workflow

Translation isn't a one-time setup. Every time you add a feature, the new strings need translating. Every time your subscription app vendor adds a default string, you should review it across your active languages. Treat translations as a small but recurring maintenance task — typically 15–30 minutes per quarter for a brand selling in 3–4 languages.

If your store is large enough to have a marketing or localization team, give them direct admin access to the portal string editor and treat the portal as just another surface they own (alongside storefront copy, email marketing, etc.). The portal is a brand surface even if it doesn't feel like one — subscribers spend more time there per visit than on most product pages.