Translate WooCommerce Product Designer for Global Buyers

Applies to Cmsmart Product Designer (formerly NBDesigner) 2.17.0 · Updated October 2026. This chapter of the admin settings guide covers the two screens that control translation: Settings > General and Settings > Design Tool for the Modern/Visual layout (read by Loco Translate or WPML), plus the Classic layout's built-in Frontend Translate screen. The demo install used for the Plugins and License captures below is running a newer 2.18.0-dev development build; the fields, links and behavior shown are unchanged from the stable 2.17.0 release documented in the public changelog.

In short

  • A translated Cmsmart Product Designer keeps international buyers inside the editor instead of bouncing them to a competitor whose storefront already speaks their language.
  • One field decides the path: Settings > General's Default design editor layout puts Modern/Visual products on standard WordPress strings (translate with Loco Translate or WPML) and leaves Classic products on the deprecated Frontend Translate screen.
  • It takes a layout check, one translation plugin or the Frontend Translate screen, and about an hour per language the first time; Settings > Design Tool's font and character-warning fields catch scripts a font can't render before a buyer does.

Here is exactly where to translate WooCommerce product designer screens inside Cmsmart Product Designer: which settings screen controls the choice, what each field does, its default, and how a shopper actually experiences the result once you save it.

What does it cost you when your design tool only speaks English?

An English-only design tool loses international buyers mid-edit, generates support tickets asking what a button does, and pushes customers to competitors whose storefront already matches their language. Cmsmart Product Designer removes that cost once its admin settings are configured for translation.

If you sell product customization to more than one country, a handful of pains show up in your analytics and your inbox:

  • Mid-design drop-off. A buyer hits an English-only Process button or printing-option label they don't recognize, and closes the tab instead of ordering.
  • Support load. Staff field the same what-does-this-button-mean message by email or chat in every English-only market.
  • Garbled or missing text. A buyer types in a script the default font can't render, and the design silently drops characters instead of warning anyone.
  • Manual relays. Staff re-explain the design flow by phone or chat instead of the interface explaining itself.
  • Competitive gap. Fully localized web-to-print competitors win the buyer who gave up on your English-only editor.

This is not a guess: in a CSA Research survey of 8,709 online shoppers across 29 countries, 66% chose the product listed in their own language over an identical English-only one (CSA Research, 2020) — a real share of traffic landing on an English-only designer today.

What would a fully localized design experience look like?

Picture a buyer who never notices they are using translated software: every settings choice you made in wp-admin shows up as toolbar labels, a printing-option form and an order confirmation that all read in their language. That is what Cmsmart Product Designer delivers once the right admin screen is translated.

Example scenario. A buyer in Lyon opens a sticker product on a French-language WooCommerce store. The Start and upload design button already reads Démarrer et importer un design, because the shop translated the Modern layout's strings months ago. They drop a logo, edit the text panel — also in French — and the character-warning setting confirms the font covers every accented letter they typed, then check out without switching to English or opening a support chat.

That is the whole promise: the buyer's attention stays on their design, not on decoding your interface.

How does Cmsmart Product Designer handle translation across its settings screens?

Cmsmart Product Designer ships every interface string as standard, translatable WordPress text and exposes the choices that affect translation as named fields in wp-admin, so Loco Translate, WPML or the built-in Frontend Translate screen all have a clear, specific job.

Three building blocks make up the translated experience, and which ones you touch depends on one setting:

  • Storefront strings — your theme and WooCommerce's own checkout, cart and account text, translated the same way you already translate the rest of the store.
  • Designer UI strings (Modern/Visual layout) — every button, panel heading and error message is a translatable WordPress string from the plugin's own .pot template (regenerated to 4,107 strings in 2.12.2). Loco Translate (1M+ active installs) edits these in-browser; WPML works the same way across language directories.
  • Frontend Translate (Classic layout only) — a dedicated screen (Cmsmart → Frontend Translate) for overwriting on-screen strings without a .pot file. Not covered by this job's captures (see capture notes); the General settings screen below marks Classic itself as deprecated.
Cmsmart Product Designer Plugins screen row (demo install running 2.18.0-dev) with Settings, Deactivate and native Translate links
Cmsmart Product Designer, WP Admin > Plugins (this demo install is on the 2.18.0-dev development build; the Translate link below is unchanged from the stable 2.17.0 release): the active row's native Translate link opens the same translation project that Loco Translate and WPML both read from.
Translate WooCommerce product designer: Default design editor layout field in Cmsmart Settings General tab, Modern recommended, Classic deprecated
Cmsmart Product Designer 2.17.0, WP Admin > Cmsmart > Settings > General: Default design editor layout is the field that decides your translation path.

The table below lists every field this chapter covers, exactly as it appears in wp-admin, with its default and what changes on the storefront.

Translation-related settings: field, default and recommendation
Field (as shown)What it doesDefaultRecommended: print shop / POD apparel / B2BWhere it shows on the storefront
Default design editor layout
(General)		Picks the designer engine: Modern, Visual, or Classic.Modern (selected here)Modern for all three — Classic gets no new features.The product page's designer and every string in it.
Default font subset
(Design Tool)		Character set the text tool's default font renders.All languageKeep "All language" for any multi-script store.The Text panel and any buyer-typed text.
Enable check text language
(Design Tool)		Warns when the font can't render a typed character.NoYes, for any translated or multi-script store.Inline warning in the text tool while typing.
Translate link
(Plugins row)		Opens WordPress's native translation editor for the plugin.as installedUse it, or Loco Translate's Plugins list, to start a language.Admin-only — not shown to buyers.
New language
(Loco Translate)		Builds a .po/.mo file from the plugin's .pot template.none installedInstall for any store translating Modern/Visual strings.Every Modern/Visual string, store-wide.
Frontend Translate screen
(Classic only, not captured)		Overwrites on-screen strings per language, no .pot file.as installedOnly if Classic products are still live; new stores use Modern + Loco/WPML.Classic-layout product pages only.
Cmsmart Product Designer 2.17.0 Manage Products screen showing 34 design-enabled products that share one set of translated strings
Cmsmart Product Designer 2.17.0, WP Admin > Cmsmart > Products: translation is store-wide — these 34 design-enabled products all pull from the same designer strings you translate once.

Cmsmart insight: translate the Modern layout first even if Classic-layout products are still live. Most of a store's strings — cart text, account pages, your theme — are shared across layouts, so the Loco Translate / WPML work carries over, while Frontend Translate only covers the Classic designer itself.

Manual multilingual workaround vs. translating Cmsmart Product Designer
Manual workaroundTranslating the designer
Staff re-explain buttons over chat in every marketThe interface already reads in the buyer's language
A second, hand-built storefront per languageOne store, one set of translated strings per locale
Garbled text discovered only after a print runEnable check text language warns the buyer first
No shared source of truth for wordingOne .pot file / Frontend Translate list per store as the source of truth

What's the business value of multilingual product design?

Translating Cmsmart Product Designer turns language from a silent drop-off point into a measurable lever: fewer abandoned designs, fewer repeat support tickets, and a storefront that can expand into a new country without a developer re-building the editor.

Business value of a translated designer
BenefitHow it shows up in your businessKPI to track
Fewer abandoned designsBuyers who understand the editor finish the design instead of closing the tabDesigner start → Add to cart rate, by language
Lower support loadFewer what-does-this-mean chats and emails from non-English buyersSupport tickets tagged designer help, by locale
Faster market expansionA new storefront language ships by changing settings, not rebuilding the designerDays from language request to live
Higher reorder rateBuyers who had a smooth first design come back for a second oneRepeat-order rate per locale

Back-of-envelope ROI: monthly designer sessions in a language × your abandonment rate there × average order value — the revenue a translated designer competes for, against a one-time hour or two of settings work.

How do you set up and translate WooCommerce product designer screens step by step?

Setting up translation starts with the Default design editor layout field in Settings > General, continues through either Loco Translate/WPML or the Frontend Translate screen, and finishes with WordPress's own site-language switch so buyers actually see the result.

Pick the path that matches your products' layout. Most 2.17.0 stores should use the Modern/Visual path below.

Modern or Visual layout (recommended):

  1. Go to Cmsmart → Settings → General and confirm Default design editor layout is Modern or Visual (see the settings table above).
  2. On the Design Tool tab, check Default font subset covers the new language's script, and set Enable check text language to Yes.
  3. Install Loco Translate for a free, in-browser workflow, or use WPML if you already run it.
  4. In Loco Translate, open Plugins and select Cmsmart Product Designer, or use the Translate link on the Plugins row shown above.
  5. Click New language and let Loco Translate build the translation file from the plugin's template.
  6. Work through the string list — toolbar labels, panels, buttons, error messages — translating each, then save.
  7. Add the new language under WordPress Settings → General → Site Language (or in WPML/Polylang).
  8. Run a test design end to end — product page, editor, Process, cart — to confirm every string is translated and no font warning appears.

Classic layout (deprecated, still supported):

  1. In Cmsmart → Frontend Translate, add a new language.
  2. Work through the on-screen strings that matter for your Classic-layout products and save the language.
  3. Switch the Site Language in WordPress → Settings → General the same way as the Modern path.
  4. Verify the result on a Classic-layout product page.
Video thumbnail: managing WooCommerce Online Designer Frontend Translate in the backend
Video: How to manage WooCommerce Online Designer Frontend Translate in Backend (Cmsmart on YouTube).

Common mistakes and troubleshooting when translating Cmsmart Product Designer

Most translation problems in Cmsmart Product Designer trace back to one of three things: the wrong layout setting, a font whose character set leaves out the target script, or a license check running against the wrong URL on a multilingual site — all three are visible in wp-admin once you know where to look.

  • Translating only one string pool. Loco Translate/WPML and Frontend Translate cover different layouts, so translating one leaves the other untouched. Check Default design editor layout per product.
  • Skipping the font-subset check. Adding Cyrillic, Vietnamese or CJK characters without checking Default font subset can leave typed text unrenderable. Enable check text language catches this before a print run.
  • AI tools failing on a translated URL. Under WPML's language-directory mode, a license check once read the page's translated URL instead of the store's real domain, returning a 401 error for AI preflight, upscale and background removal — fixed in 2.12.0. Still seeing it? Check the License screen below.
  • Forgetting the WordPress site-language switch. Translated strings do nothing until WordPress serves that language — set it under Settings → General → Site Language and test as a logged-out visitor.
  • Trusting a page cache. A cache that doesn't vary by language can keep serving English to translated visitors; exclude those URLs or clear the cache after publishing a translation.
Cmsmart Settings Design Tool tab: Default font subset and Enable check text language fields for translated storefronts
Cmsmart Product Designer 2.17.0, WP Admin > Cmsmart > Settings > Design Tool: Default font subset and Enable check text language catch scripts the default font leaves uncovered.
Cmsmart Product Designer License and activation screen (demo install running 2.18.0-dev), used when troubleshooting AI tools on translated WPML pages
Cmsmart Product Designer, WP Admin > Cmsmart > License (this demo install is on the 2.18.0-dev development build; the screen is the same in the stable 2.17.0 release): check here first if AI preflight or upscale reports a license error on a translated page.

Going further: custom multilingual development from Cmsmart

Beyond the settings in this guide, Cmsmart builds merchant-specific multilingual work — automatic buyer-locale detection, translated print-ready output, and right-to-left language support — as custom development on top of the core plugin, scoped to what your store actually needs.

These settings cover most stores. A few requests come up often enough to plan for as custom development rather than expecting them in the core plugin:

  • Automatic locale detection — matching the designer's language to the buyer's browser or WPML language, instead of the manual Site Language setting.
  • Translated print-ready PDF labels — carrying the buyer's language into the production file's own labels and layer names.
  • Right-to-left language support — adapting panels and the text tool for Arabic, Hebrew or other RTL markets, building on Default font subset above.
  • Shared glossary across systems — consistent product and printing-option wording across the storefront, the designer and an ERP/PIM feed.
  • Per-market template sets — different starter templates by storefront language or region, instead of one global library.

Cmsmart's delivery model for this work runs discovery → solution design → sprints → QA → launch → support, the same process behind the custom ecommerce projects in our portfolio. See the product designer customization service for how this is scoped and priced.

Get a quote for multilingual designer development

Why work with Cmsmart for multilingual commerce?

Cmsmart has built WooCommerce product customization since 2012 as a Netbase JSC division, with 6,300+ client projects and a 4.2 Trustpilot rating, including stores that specifically asked for storefront and designer translation.

1,800+ of those projects are live stores today. Reviews on Trustpilot sit at 4.2 out of 5 across 404 reviews, with translation a recurring theme — one reviewer wrote simply: "Thank you very much for my Web site translation." — antonissanchez, Trustpilot, Sep 2022. See the Cmsmart Product Designer product page.

Frequently asked questions

Which settings screen should I check first to translate WooCommerce product designer screens?

Settings → General's Default design editor layout field. It tells you whether a product is Modern/Visual (translate with Loco Translate or WPML) or Classic (use the Frontend Translate screen).

Which layout should I use for translation, Modern or Classic?

Use Modern or Visual with Loco Translate or WPML for new work — it's the actively developed layout. Classic's Frontend Translate screen still works in 2.17.0, but gets no new features.

Do I need a separate plugin for storefront vs. designer strings?

No. Your theme, WooCommerce and Cmsmart Product Designer's Modern-layout strings all go through the same WordPress translation system, so one plugin like Loco Translate or WPML covers all of them.

What does the "Enable check text language" setting actually protect against?

It warns the buyer inside the designer when the current font cannot render a character they just typed, catching a missing glyph before the order goes to print rather than after.

Will translating the designer affect my checkout or order emails?

No — those are translated separately, the same way you'd translate any WooCommerce store. One related fix in 2.17.0: the admin approval-notification email now checks the order status by its internal key rather than its translated subject line, so approval emails work on translated stores too.

How long does a full multilingual setup take?

Translating one language's worth of designer strings with Loco Translate typically takes under two hours, since you're working from the plugin's existing template rather than writing copy from scratch, plus a short pass reviewing the storefront.

This chapter is part of the admin settings guide series: start at the installation and setup hub, or continue with how to use the WooCommerce product designer plugin in the backend and how to create a component in Product Builder.