Sell Custom Products Internationally with WooCommerce

Applies to Cmsmart Product Designer (NBDesigner) 2.17.0 · Updated October 2026. This case study covers running Cmsmart Product Designer on a multilingual WooCommerce store, so you can sell the same configurable products to buyers who shop in a different language than your admin team.

In short

  • Outcome: a WooCommerce store running WPML or Polylang can sell custom, designer-built products to buyers in every language the store supports, from one product catalogue and one order queue.
  • How it works: the designer, pricing, cart and checkout all read the same WordPress and WooCommerce data your translation plugin already manages, so a translated page shows the same price matrix and print options as the English one.
  • What it takes: a translation plugin (WPML or Polylang), translated product copy, and about an afternoon to test the designer, checkout and order emails in each language before you launch.

What does staying English-only cost a custom-product store?

Cmsmart Product Designer sells to buyers in whatever language your WooCommerce store speaks, because the designer, price matrix and checkout all run on the same WordPress data that WPML or Polylang translate. Staying English-only quietly caps who can discover, configure and buy a custom product from you.

Concrete pains we see in print and personalization businesses that haven't gone multilingual yet:

Put a number on it: (non-English visitors/month) × (conversion gap vs. your English pages) × (average order value) is the monthly revenue walking past a designer that only speaks one language.

What would a multilingual Cmsmart storefront look like?

Cmsmart Product Designer lets a WooCommerce store show the same product, price matrix and design tool in each language WPML or Polylang manages, so a buyer in Berlin and a buyer in Boston both design, price and check out in their own language from the same catalogue.

Talk to an ecommerce expert about what a multilingual rollout would look like for your product range.

Example scenario. A personalized gift store sells in English and Spanish. A Spanish-speaking shopper lands on the translated product page, opens the same online designer, picks the same fonts and cliparts, and sees the price matrix recalculate in their own language as they add engraving. They pay through the same WooCommerce checkout, localized to their billing country. The order lands in the same admin queue as every English order, the designer sends the same approval email (now readable to the admin in whichever language the shop operates), and the print-ready PDF that reaches the press is identical in structure to an English order's file. Nobody on the print floor needs to know which language the buyer used.

That's the business case in one sentence: the designer, price matrix and production file stay identical across languages, so production never branches by locale — only the storefront text does, and that's WPML's or Polylang's job, not a rebuild.

Cmsmart Product Designer buyer product page for a WooCommerce store that wants to sell custom products internationally
The buyer-facing product and "Start and upload design" flow is standard WooCommerce markup, which is exactly what a translation plugin needs to produce a localized version.

How does Cmsmart make the product designer work in every market?

Cmsmart Product Designer ships as a standard, text-domain-translatable WordPress plugin, so WPML, Polylang or Loco Translate can translate its interface the same way they translate any other WooCommerce extension, while the design engine, pricing and order pipeline keep running on the untranslated product and order data underneath.

Four building blocks make up the architecture — what's in the plugin today versus what we build as custom work:

  • Translation layer (in the plugin today, via WPML/Polylang/Loco Translate). Every admin screen ships under a WordPress text domain and a regenerated .pot file, so its row in Plugins carries a standard Translate link — no separate multilingual module to buy.
  • Catalogue and pricing (in the plugin today). The product, its print options and its price matrix are stored once; WPML or Polylang translate the surrounding page copy while the designer reads the same options and prices regardless of which translated page loaded it.
  • Order pipeline and notifications (in the plugin today, hardened in 2.17.0). Since 2.17.0 the admin's approval-notification email checks the order's status key, not its translated subject text, so a fully translated storefront no longer breaks that review alert.
  • Print-ready output (in the plugin today). The cloud renderer, the server renderer and the admin's Create PDF button all read the same page geometry, giving every order a print-ready PDF that matches the order regardless of which locale the buyer checked out in.

Cmsmart insight: in our delivery work, most "the designer broke in Spanish" tickets turn out to be a translation plugin overwriting a string the designer's JavaScript expects verbatim (a status key, not its label). Keep status keys and option slugs out of what you hand your translator, and translate only the human-facing labels.

WordPress Plugins screen showing the Cmsmart Product Designer row with its own Translate link
Every Cmsmart/NBDesigner plugin row carries a standard WordPress "Translate" link, the same mechanism WPML and Loco Translate use for any other extension.
Cmsmart Product Designer General settings tab with layout, DPI and dimension unit options that apply to every storefront language
Design-tool settings — layout, output DPI, dimension units — are set once in General Settings and apply to the designer in every translated version of the store.
Manual multi-language workflow vs. Cmsmart Product Designer on a translated WooCommerce store
TaskManual / ad hoc approachCmsmart Product Designer + WPML/Polylang
Product pricing per languageRe-key prices and options per translated productOne price matrix; translation plugin only changes the labels around it
Design tool UIHire a developer to hardcode a second language string setStandard WordPress .pot file, translated with WPML String Translation or Loco Translate
Approval emailsRewrite email templates per language, risk breaking status logicStatus-key based notifications (2.17.0), readable in any admin language
Print-ready filesRe-check each order's PDF by hand for layout driftSame renderer, same page geometry, for every locale
RTL layout, per-region price rules, ERP sync by marketNot practical without development timeCustom development (see below)

What's the ROI when you sell custom products internationally?

Cmsmart Product Designer turns each new storefront language into incremental orders from the same catalogue and the same production line, so the main costs are translation and QA time rather than new infrastructure — which is what makes the ROI case straightforward to build with your own numbers.

BenefitHow it shows up in your businessKPI to track
More buyers can complete a designNon-English visitors stop bouncing on the product page before they even open the designerAdd-to-cart rate by site language
Fewer manual quotesB2B buyers in other languages see the live price matrix instead of waiting for a translated replyTime from RFQ to quote sent, by language
Fewer reprintsPrint options and specs are shown in the buyer's language instead of guessed atReprint rate by order language
Lower support loadApproval and status emails are readable to admins and buyers in the language each side usesSupport tickets per 100 orders, by language

ROI worksheet (your variables):
Extra monthly orders from a new language ≈ (non-English visitors/month) × (conversion rate uplift you expect once the page and designer speak their language).
Reprint savings ≈ (orders/month in that language) × (current reprint rate) × (cost per reprint).
Set-up cost ≈ (product copy to translate) × (your translator's rate) + (QA hours testing designer, checkout and emails in the new language).
Compare the two sides before you commit a launch date.

How do you set up Cmsmart Product Designer for a multilingual store?

Setting up Cmsmart Product Designer for more than one language means installing and configuring a translation plugin first, then verifying the designer, checkout and order emails in each language — the plugin itself needs no multilingual-specific installation step because it is already translation-ready.

Here is the sequence we use when we add a language to a store that already runs Cmsmart Product Designer:

  1. Install and activate WPML (with WooCommerce Multilingual) or Polylang, and set your default and additional store languages.
  2. Translate the designer's own strings with WPML String Translation or Loco Translate — see our dedicated walkthrough — not by editing plugin source files.
  3. Translate the product titles, descriptions and any print-option labels you show buyers, using your translation plugin's product duplication workflow.
  4. In Cmsmart → General Settings, confirm the default design editor layout, output DPI and dimension unit — these settings apply store-wide and do not need to be re-set per language.
  5. Open the designer on the translated product page and design a test item end to end: pick a template, add text, add a clipart, and confirm the price matrix updates correctly.
  6. Run a test order through checkout on the translated page, and confirm WooCommerce captures the buyer's billing country and currency the way your store expects.
  7. Approve or decline the test design from Orders → Customer Design and confirm the admin notification email arrives and reads correctly — this is the flow the 2.17.0 status-key fix protects on a translated site.
  8. Open the order's print-ready PDF (or run Create PDF) and confirm the production file matches the design exactly, the same as it would for an English order.
  9. Check the order in the main Orders dashboard alongside your other orders — it should need no special handling because it sits in the same queue.
  10. Repeat steps 2–9 for each additional language before you make the language switcher public.
WooCommerce checkout billing details with a Country/Region field, part of testing a translated storefront
WooCommerce's own billing fields, including Country/Region, carry over unchanged to every translated checkout page — test them alongside the designer.
Cmsmart Orders dashboard listing orders from every storefront language in one queue
Every order lands in the same Orders dashboard regardless of which translated page it came from — no per-language order queue to manage.
Cmsmart order detail timeline showing Placed, Paid, Awaiting review and In production stages
The order timeline and line-item design file look identical whatever language the storefront used to take the order.
Customer Design approval box with Accept/Decline actions and a Send notify mail option
The Customer Design approve/decline box and its notify-mail option are the flow the 2.17.0 status-key fix keeps working on translated stores.
Print-ready PDF status marked Ready, rendered by the cloud renderer
The print-ready PDF status and renderer timestamp are the same for every order, so production never has to treat a translated-site order differently.

For the deeper mechanics of translating the designer's own interface strings — which tool to use, how to handle missing strings, and the Modern vs. Visual layout setting — see our guide on translating the WooCommerce product designer. If you're planning localization beyond the plugin itself (payment methods, shipping, legal pages), our international ecommerce localization guide covers the wider checklist.

What custom development can Cmsmart build for global sellers?

Cmsmart builds the parts a multilingual storefront needs beyond the core plugin as custom development — right-to-left layouts, per-region pricing rules and ERP/MIS sync by market are not built-in today, so we scope and deliver them as a project fitted to your store rather than implying they ship out of the box.

Extensions we build on top of Cmsmart Product Designer for stores selling across languages and regions:

  • RTL layout support. For Arabic, Hebrew or other right-to-left markets, we adapt the designer's layout and storefront templates so the experience reads correctly in both directions — this is custom development, not a core toggle.
  • Per-region price matrix rules. When a market needs different print-option pricing (import duty, local paper cost, currency rounding), we build pricing logic on top of the existing price matrix rather than maintaining parallel products.
  • ERP/MIS sync by market. Routing translated-store orders into region-specific production systems or MIS platforms so a multi-factory operation doesn't re-key orders by hand.
  • Region-aware approval routing. For B2B accounts, approvals can route to the reviewer responsible for that market or language instead of one shared inbox.
  • Template libraries per market. Curated clipart, fonts and starter templates relevant to a specific region's holidays, scripts or design conventions.

We deliver this like any Cmsmart project: discovery, solution design, build sprints, QA against your live catalogue, launch, then support — the model behind our ecommerce delivery projects.

Plan my multilingual product designer store

Why work with Cmsmart on your international storefront?

Cmsmart has built WooCommerce product customization since 2012 as a Netbase JSC division, with 6,300+ client projects and stores now live in 80+ countries, so the same team scoping your multilingual rollout has already shipped storefronts across multiple languages and currencies.

  • In business since 2012, with 6,300+ client projects and 4,600+ projects delivered.
  • 1,800+ live stores run today, with clients across 80+ countries.
  • Rated 4.2 on Trustpilot (404 reviews), verified.

From Trustpilot: "Thank you very much for my Web site translation." — antonissanchez, Taiwan.

If web-to-print is the wider context for your project, our web-to-print solutions hub covers storefront, pricing and production in more depth, and our product designer customization service is where multilingual and other tailored builds get scoped.

Frequently asked questions

Does Cmsmart Product Designer include its own multilingual module?

No. The plugin ships as a standard, translation-ready WordPress plugin with its own text domain and .pot file; you still need WPML, Polylang or a similar translation plugin to actually translate and serve pages in more than one language.

Will the price matrix or print options change per language?

No — the underlying product, its print options and its price matrix are stored once. A translation plugin changes the surrounding labels and copy; the designer reads the same pricing data regardless of which translated page loaded it.

Does a translated store break order notifications?

As of version 2.17.0, no: the admin approval-notification email checks the order's status key rather than its translated subject text, which is specifically what used to break on fully translated stores before this fix.

Can Cmsmart build right-to-left (RTL) support for Arabic or Hebrew stores?

Yes, as custom development. RTL layout is not a built-in toggle today, so we scope and build it for your specific storefront and templates as a project.

Is this the same as translating the product designer's own interface?

Related but different. Translating the designer's admin and buyer-facing interface strings is covered in our Loco Translate walkthrough; this guide is about the business case and setup for selling the same products across a multilingual storefront once that translation is in place.

What if our store also needs multi-currency, not just multi-language?

Currency switching is typically handled by a companion tool such as WooCommerce Multilingual or a currency-switcher plugin; Cmsmart Product Designer's pricing reads whatever currency WooCommerce presents, and we can scope custom regional pricing as part of a project.