Selling in more than one language

Manage → Apps → Multilingual (vi: Quản lý → Ứng dụng → Đa ngôn ngữ) — everything on this page lives there. The first time you open it the screen says the store has not installed the app and offers Install; one click, without leaving the page.

The app has three tabs, and their order is the order of the work: Languages (which languages you sell in), Content (translating), and Review (reading back what the machine wrote).

The thing to know first: adding a language changes no existing address. The default language keeps every URL exactly as it was; each additional language is served under its own path prefix — /en/about is /about in English. Links your shoppers saved keep working, and search engines are told about every language a page has actually been translated into, so they can send a visitor to the right one — see SEO for what counts as translated.

The default language lives somewhere else, on purpose

The Languages tab shows the default with a Default badge, its box always ticked and impossible to untick — a store that stopped publishing its own source language would have no home page. But changing the default is not done here: it is at Manage → Settings → Currency & region.

The reason: this app can be uninstalled. A store selling in exactly one language still has to be able to say which language that is, and a picker that lived inside the app would go away with it. A store that never chose is served in English, and the Languages tab says so rather than showing an empty list.

Adding a language, and the currency it sells in

The first thing the app asks after you install it is which languages this store sells in. Pick one, pick the currency beside it, press Add — as many as you need, and without asking anybody. The languages you add belong to this store; another shop on the same platform selling in different ones is normal.

The platform ships a suggestion list to make that quick, but it is only a suggestion: a language does not decide a currency. Picking one prefills the currency its main market uses, and what you sell in is your call — an English-language store selling in Japan picks yen, which is ordinary. Change it whenever: every language you sell in carries its own currency box on its row.

A language's name is stored in its own words — 日本語, not "Japanese" — because that is the text a shopper reads on the storefront's Language switcher, not the text you read in the admin.

One warning worth reading: if a language you switched on sells in a currency the store has no exchange rate for, this tab says so — shoppers reading that language keep seeing prices in your base currency until you add a rate under Settings → Currency.

The currency shown on a language's row is the one your shop set for that language, and a language you never set one for shows — and sells in — the store's own currency. It never borrows the currency the platform's language list happens to carry: that is what the platform charges its own plans in, not what your shoppers pay.

How the language rides the address — three choices

The path prefix is the default, not the only option. The Languages tab carries "How the language rides the address" with three carriages, and each store uses exactly one — honouring all three at once would give every page three addresses, which search engines punish as duplicate content:

• Path prefix — /en/about. The safest for SEO, and our recommendation.
• Query parameter — /about?lang=en. Every language shares one address plus a parameter; simplest to link to, weakest for indexing.
• Subdomain — en.your-domain.com. Needs a custom domain, and one DNS record per language pointed at the platform — the HTTPS certificate is issued automatically on the first visit. Not available on the built-in .sbuilder.site address, whose certificate covers one label only.

In every carriage the default language carries nothing — no prefix, no parameter, no label — so switching carriages breaks no address a shopper saved in the default language.

Also worth knowing up front: this is not an auto-translate-the-site switch. Translations are your content — the machine only fills in what is missing, and what it writes is marked until you have read it.

Where you translate: one place for all of it

The Content tab is where you translate products, collections, articles, blog topics, courses, pages, forms, the store's own wording, its email wording and the labels you typed into Settings. The left column lists the kinds of content; pick a kind, then pick an item to open its translation panel.

Each kind used to carry its own panel inside its own edit screen — a tab in the product editor, one in the article editor, and a few more besides. Those tabs are gone: if you used to translate a product by opening the product, come here instead. What you get in exchange is two things the old arrangement could not do:

• a search box over the list, and
• an Only untranslated switch — the "what is left" question that previously took a manual page-through to answer.

The panel itself is unchanged, including how it saves:

"The source text is on the left. What you type is what the shopper reads in that language."

A field left empty shows the original on that language's page — never a blank. There is no Save button: each field commits when you leave it, and shows Saved for a moment so you know it went.

SEO travels with the content instead of sitting in a section of its own. A product's or article's panel carries SEO title and SEO description right under the content fields, so finishing a product finishes it. Left empty, each keeps its own original; and on a product that never had its own SEO title, the page title follows the translated product name — exactly as the original followed the original name.

A page is one row with two halves. Open a page under the Pages kind and you get two tabs: Content — every string on that page, each row saying what it is ("Button · Button text", "Heading · Heading text") — and SEO — the title and description a search engine shows for the page. Content comes first because it is what shoppers read; SEO is only the sentence about the page. These used to be two separate kinds, and whoever opened the SEO half first concluded that a page translates nothing but its SEO — it does, and the screen no longer allows that misreading.

A course is a row with two halves too. With the Courses app installed, the Courses kind lists each course: the Content tab holds its title, summary, description and SEO; Chapters & lessons holds every chapter and lesson title, lessons indented under their chapter. The sales page, the course grid on the home page and the syllabus a shopper reads before buying all follow the page's language. What is inside a lesson (the video, the text) is not translated here — it is what was sold, and video subtitles already exist per language.

A form translates its questions AND its choices. Field labels, hints and help text have been translatable for a while; since 2026-09-06 so are the option lists of Select / Radio / Checkbox fields, and the name and description of each payment method.

The part that matters is this, and it is why they were not offered before: only the words a shopper reads follow the language — the submitted value does not. A shopper picks "Single room" on the English page and the form still submits "Phòng đơn", so conditional rules keep matching, the default choice keeps pointing at a real option, and every response you read back is in one language however many you sell in. That is also why the panel offers no row for "Default value": it names a value that never moves.

Page copy is translatable in both places, and the two answer different questions. A page's Content tab in the app lists everything still missing — that is where "which page is not finished" gets answered. In the page builder, next to the device switch, sits Editing language: pick a language and type straight onto the page, same page and a different view — that is where you see whether the wording fits its box. Layout, images and design are shared; only the words follow the language.

Filter and sort option labels translate too, which is worth saying because most people assume otherwise: the values come from your catalogue, so they look like data rather than words. They are words — "Newest", "Price: low to high", "In stock" are all yours to rewrite per language, on the select and on all four filter elements.

A translation is attached to the option's value, not to its position or its label, and that is what makes it survive: re-syncing a filter against the catalogue rebuilds the rows, and each one finds its translation again. An option whose value the catalogue no longer has simply goes back to untranslated, which is the honest answer rather than a stale word left behind.

The value itself never translates. It is what the shop matches on and what travels in the address (?f.tag=sale), so a translated one would narrow to nothing in that language alone — a shop that looks broken in exactly one place.

A translated row can go stale, and the panel says so. Every translation remembers the source text it was made from. Edit the original afterwards — rename the product, rewrite the heading — and the translation beside it carries a Source changed badge: "The original text was edited after this was translated — check it still says the same thing." Nothing is replaced for you. Reword it, or press Still correct — keep it when the change did not touch the meaning, and the badge goes.

The store's own words are translatable too, since 2026-09-06. A published page carries two kinds of text. The first is your content, and it has followed your translations all along. The second is generated by the page itself as a shopper uses it — the "Added to cart" toast, an image viewer's Close, the names of order statuses, a form's validation messages — and that kind was written by the platform, in Vietnamese and English only. A store selling in Japanese got Japanese pages and Vietnamese buttons, with nowhere to fix them.

It is now a content type like any other: Storefront wording, last in the left column of the Content tab. Each row is one piece of text, named by the words themselves in your store's own language — you read "Added to cart" on your storefront, so you type those words into the search box to find it. Anything you leave empty keeps the platform's own wording, and Fill what is missing covers this type exactly as it covers products.

So are the emails. Every letter a shop sends — verification codes, order confirmations, shipping and return notices, points, bookings, courses — used to be written twice into one message: a Vietnamese line, then an English one, both always sent. Sensible for a Vietnamese store with a mixed audience, and wrong in two directions for everyone else.

The Email wording type, last in the left column, lets you rewrite any of them — and since 2026-09-26 the letter goes out in the shopper's language. Every order records the language the shopper was reading when they checked out, so the order letters — placed, paid, shipped, cancelled — are written in that language alone. The same goes for account letters: a shopper who signs up or asks for a password code on the /en/ pages gets the code in English.

The old two-language letter survives where nothing names a language: an order placed on the store's default language, one you typed in yourself, one placed before this existed — and, for now, the letters that are not about an order or an account (returns, points, bookings, courses). There the rule is the one that has always held, built so nothing changes for a store already running: a store selling in Vietnamese or English sends the bilingual letter, with its own words as the half in its own language; a store selling in anything else sends one language — its own.

The language an order records is checked against the languages you publish, so a stale page or a doctored request cannot make an order's letters come out in a language the store does not sell in. And the language is fixed at checkout: dropping a language later does not change which language that order's buyer is written to.

Order lines follow the same rule. The order itself keeps the product names it was sold under; the letter, and the shopper's own order history on the storefront, print each line's name in the shopper's language when you have translated it.

Two things to watch when editing. Symbols like %d and %s are where a number or a name is dropped in: keep them all, but do move them to where your language puts them. And a few rows are a date layout (02/01/2006 means day/month/year); write yours, as long as it still names a day, a month and a year. Break either one and the platform sends its own wording instead of a broken letter.

The labels you typed into Settings translate too. A delivery option's name and the name you give your tax row are printed on the order confirmation straight from the snapshot stored on that order — no form in reach — so they used to stand in Vietnamese inside a letter that was otherwise translated. The Store labels type lists what the shop has configured right now: each delivery option's name and description, plus the tax label.

The translation is attached to the text itself, not to the settings row. Rename an option in Settings and a new row appears here while the old translation stops being used — which is exactly right for a receipt already sent: that order keeps printing what it printed, rather than picking up next year's wording.

Each language can have its own address

Since 2026-09-26 an address translates too. Products, product categories, articles, blog topics, courses and pages each carry a URL slug row in their translation panel, so the English page of /gioi-thieu can live at /en/about-us instead of /en/gioi-thieu. Left empty, the language keeps the original slug under its prefix — exactly what every page did before.

What you type is folded into address shape for you: lower case, accents dropped, spaces turned into hyphens, so About us is stored as about-us. Text that folds to nothing — a title written entirely in Japanese, say — is refused rather than stored as an address nobody could type. Translate what's missing fills slugs too, from the translated name.

The old address keeps working, permanently. Once /en/about-us exists, /en/gioi-thieu answers with a permanent (301) redirect to it, query string and all — a link somebody shared before you translated the slug still lands, and a search engine moves its ranking to the new address rather than counting two.

So does a renamed one. Change a product's, category's, article's, blog topic's or course's slug, or a translated slug — or rename a page and publish it — and the address it used to answer at redirects (301) to where it lives now. The redirect points at the item, not at a fixed address, so renaming it a second time does not build a chain: every old address goes straight to the current one. And a live page always wins over a redirect — make a new page at an address that used to redirect, and the new page is what shoppers get.

The rules that keep two things from answering at one address:

• One address per item, per language, per kind. A translated slug that another product (another article, another page…) already answers at in that language — as its own slug or as its translation — is refused, and the refusal names the address. Pick another.
• It works the other way round too. Typing a product, article or course slug that is already another item's translated address is refused. Leaving the slug empty, so the platform derives it from the name, never is: a clash there quietly becomes -1, -2 on the end, because nobody chose that address. For a page the check runs at publish — a page cannot go live at an address another page answers at in some language, and the refusal names the page and the address.
• The store's own addresses are not for pages. A page's translated slug cannot be checkout, search or account: those are the checkout, the search results and the customer account, and a page translated onto one of them would take that address away from the real thing.

When Translate what's missing comes back with a slug that clashes, that one row is simply left empty — the rest of the item still fills — and you type the address yourself.

The machine fills what is missing

Machine translation comes at three reaches, one rule:

• One item — the Translate what's missing button in the open item's panel on the Content tab.
• One page — in the page builder, while standing in a language, the ✦ button beside the language picker translates everything missing on that page, and the canvas changes in front of you.
• The whole store — on the Languages tab, Translate what's missing — whole store walks every kind the Content tab lists in one press: products, collections, articles, topics, courses with their chapters and lessons, each page's copy and its SEO, forms, and the store's own wording. Before 2026-09-06 it walked only the first four, so anyone who pressed it and looked again found the page copy untouched.

The rule that matters most sits right under each button:

"Only fills empty fields. Text you have written is never overwritten."

Which means pressing it any number of times is safe: a translation you fixed by hand stays yours. The result says so explicitly — "Translated 12 fields. 3 already had text and were left alone."

One exception, and it only ever touches the machine's own work: a machine translation nobody has approved yet, whose source text has since changed, is translated again from the new source. Anything a person wrote or approved stays exactly as it is — those get the Source changed badge instead, and the rewording is yours.

Machine translation has a monthly allowance, counted per store in characters sent to be translated — 200,000 a month unless the platform's operator set a different figure. It exists because the translation service is shared by every store on the platform, and one store looping the button should not be able to spend everybody's. A request that would cross the allowance is refused whole, before it is sent; a request the service then fails on is not counted. When it runs out the button says so plainly — "The translation allowance for this month is spent. Manual translation still works." — and everything else keeps working. On a whole-store run, everything translated before the quota ran out stays — press again next month and it continues, precisely because the machine never overwrites a field that has text. The platform can chain several translation services; when one's quota is spent the next steps in, and you never need to know which one wrote a sentence.

No machine-translate button? Automatic translation is something the platform's operator switches on; until then the Languages tab and each page's panel say so plainly — "Automatic translation is not switched on for this deployment. Manual translation works." — rather than leaving you hunting for a button that is not there. Nothing else in the app depends on it.

Reviewing what the machine wrote

Machine-translated text carries the label Machine — unreviewed until a person has read it. That label exists for a reason: publishing storefront copy nobody in the store has ever read is a decision, not a default.

So an unapproved machine translation does not go live. Shoppers keep seeing the source text in that spot; a page whose only translation is an unapproved machine one does not count as translated in that language yet (no sitemap entry, no alternate-language tag); and emails to shoppers use the source wording too. Approve puts it live at once. The top of the Review tab always states how many are waiting, so you know how much copy has not reached shoppers yet.

The Review tab is the queue: everything the machine wrote that nobody has read, oldest first. Each row offers two moves — Approve when the wording is fine, or Open in context to land where the text actually lives before you decide: a page text row opens the page builder itself — the right page, that element already selected, the canvas standing in the language under review. Each row says which page it lives on.

The queue is searchable, by the same rule as the storefront's search box: accents are optional — "ao thun" finds "Áo thun" — and matching is by word start, so "ao" does not drag in "Chảo". The filter beside it keeps one kind of content (products only, articles only…) when the queue is long.

Approving works in bulk, which is worth knowing before you settle in to click one row at a time. Every row has a tick box, and the bar above the list has Select this page. Tick what you have read and Approve N sends the whole batch in one go rather than one request per row.

The selection is dropped whenever the list changes: another page, a word typed into the search box, a different filter, a different language. Kept, the button would approve rows that scrolled out of sight two screens ago — which is precisely what a bulk control must not do.

Approve all stands apart, and it names the number it would clear. It covers every row matching the filter currently on — including pages you have not looked at — so it asks once before it runs. Narrow to one kind of content first and only that kind is cleared.

The three buttons say three different things, and that difference is the whole meaning of this queue: Approve is "I read this one", Approve N is "I read these", and Approve all is "clear the queue". Only the last one approves wording nobody opened, which is why it is the only one that asks.

When you would rather not review at all

If the store trusts its machine translations and does not intend to read them back, the Languages tab carries a switch — Machine translations need no review — beside the whole-store translate button. With it on, every automatic translation is written already approved and goes live at once, the queue never receives it, and the Machine — unreviewed label stops appearing.

It applies from the moment you turn it on. Rows already waiting stay where they are: flipping a switch must not quietly approve a backlog you deliberately left. Clear that with Approve all, where you see the number before you decide.

The switch sits in the Languages tab rather than in the queue for a reason. It is not a shortcut to be found halfway through a tiring review; it is the store's answer to "what does machine translation mean here", so it lives beside the place machine translation is turned on.

The Language Switcher block — for shoppers

Shoppers need a button, not a hand-edited address. In the page builder, the Add-on entry (vi: Tiện ích) on the left rail opens its own panel, with two tabs across the top — Installed and Not installed:

• With the Multilingual app installed it sits under Installed; click the app to pull out the Language Switcher block — drop it in a header or footer, beside the currency switcher.
• Without it, the app sits under Not installed, and Install installs it and opens its screen so you can choose a language.

The block lives only inside its own app, not in the general element palette — a one-language store that could drag it out would get a button that switches to nothing.

On the published page the block renders one real link per language — pointing at the page being read in that language, through whichever address style the store chose (prefix, parameter or subdomain); active filters ride along. The language being read shows bold, not as a link. Other apps follow the same two tabs: an installed app unfolds into its draggable blocks, a not-installed one installs on click.

Flags are pictures, not emoji. Switch on Show flag in the block's properties and the published page shows the rectangular flag of the matching country — the same flag on every device, instead of an emoji that Windows draws as two letters in a box. The country is inferred from the language: the flag the platform's operator assigned to the language in the catalogue if there is one, else the region in the language code (en-GB → the UK), else the country usually associated with that language (vi → Vietnam, en → the US, ja → Japan). The flags inside the app and in the language lists come from the same set. On the page builder's canvas alone the flag still shows as an emoji — same size and place as the real page, only drawn differently.

Shoppers find things in whichever language they search

Storefront search matches translations too: a shopper on /en/ typing a product's English name finds it, even though you named it in Vietnamese. Nothing to configure — once translated, it is findable.

Progress

The Languages tab shows per-language progress — how many items have a translation. With one line worth reading carefully:

"Counts what has been translated. Items nobody has started are not counted here."

Meaning the number measures work done, not work remaining — a store that has translated nothing shows "nothing yet", not "0%".

Uninstalling

You can, but not while the store publishes two or more languages — drop the extra languages on the Languages tab first. That order is deliberate: uninstalling with languages still live would leave pages with nowhere left to edit them.