BigCommerce Multi-Language Storefront: Stencil or Catalyst

A native BigCommerce multi-language storefront lets you serve international shoppers in local languages from a single channel without duplicating your product catalogue or splitting inventory. Adding translated locales creates dedicated URL subfolders immediately, so localisation becomes a translation task rather than a store-sync task.

What native multi-language changes in BigCommerce

Before native multi-language capabilities landed on the platform, selling to French, German or Spanish buyers on BigCommerce usually meant a separate storefront or a separate store, and that in turn meant keeping stock, promotions and product copy aligned across each one. Managing four regional stores just to change product copy from English to German was the eCommerce equivalent of buying four identical houses because you wanted different curtains.

As documented in the official announcement on multi-language storefronts by Kristina Pototska on 21 August 2026, you can now run multiple languages from a single BigCommerce storefront with no separate stores, no duplicated catalogue, and your existing frontend kept intact. Unlike a BigCommerce multi-storefront architecture that powers several distinct storefronts from one store, this setup runs multiple languages directly within a single storefront. Because it removes catalogue cloning, it is the closest BigCommerce equivalent to the language side of Shopify Markets international selling.

When you activate a new locale, language-specific URL subfolders generate automatically. Shoppers can switch languages while browsing, with untranslated content falling back to your default language.

Cross-border conversion and localisation benchmarks

Research from CSA Research in their global study of 8,709 consumers across 29 countries reveals that 76% of online shoppers prefer to purchase products when information is presented in their native language. In the same study, 40% of respondents state they will never buy from websites that operate only in foreign languages, so an English-only storefront is likely to lose a meaningful share of non-English-speaking buyers before they reach checkout.

Checkout drop-off compounds these losses when regional friction remains unaddressed. The Baymard Institute puts the average documented cart abandonment rate at around 70% across the studies it tracks, and Baymard's figure is not language-specific, but untranslated checkout fields, shipping methods and order messages are one more source of friction at the point where abandonment is already highest.

Shopper journey translatable surfaces at a glance

Native localisation covers the main shopper-facing surfaces on the purchase path, covering both catalogue data and checkout system messages. The table below maps each customer-facing touchpoint to its configuration method and underlying tool.

Translations are managed either inside the built-in control panel user interface using the Translations Manager or programmatically at scale through the GraphQL API. Transactional emails per language are handled through the Email Templates API, ensuring order confirmations and shipping notifications align with the customer's selected locale.

How to configure a multi-language storefront in five steps

Enabling additional languages is a control-panel and theme task first, then a translation task.

1. Add your target languages in Localization settings. Go to the Localization section in your store settings and add your desired languages. Language-specific URL subfolders are created automatically.
2. Verify theme version compatibility. Confirm that your Stencil theme is based on Cornerstone 6.19.0, Capacity 6.1.0, Fortune 4.1.0, Merchant 6.1.0, Peak 5.1.0, or newer. These releases contain the native language selector components.
3. Import catalogue and checkout translations. Open the Translations Manager in the control panel for manual edits, or execute batch mutations against the GraphQL Admin API for large catalogues.
4. Test language-specific URL subfolders. Navigate to your newly generated subfolders (such as /fr/ or /de/) and inspect translated product URLs and category paths to confirm fallback behaviour.
5. Verify language-specific sitemaps. Inspect your XML sitemap index to ensure that localised URLs appear correctly for search engine indexing.

On BigCommerce builds we have supported for UK merchants selling into France and Germany, keeping duplicate stores in sync has been the largest recurring maintenance cost. Native multi-language removes that class of work, although we have not yet migrated a live duplicate-store setup onto it.

Managing translations through the GraphQL API

The Translations Admin GraphQL API is available on any storefront type, including Stencil, Catalyst, or bespoke headless frontends. It supports 16 resource types: Products, Product Modifiers, Product Listings, Product Filters, Product URLs, Brand URLs, Category URLs, Locations, Shipping Methods, Tax Rates, Order Statuses, Promotions, Payment Methods, Address Form Fields, Customer Form Fields, and Checkout Settings.

Authentication requires the standard X-Auth-Token header with the Store Translations read-only or modify OAuth scope. Identifying fields use structured URNs: channelId follows the pattern bc/store/channel/{channel_id}, while localeId takes the format bc/store/locale/{locale_code}. Translations can only be added to a non-default channel locale. Adding a translation to your default locale produces unexpected behaviour, and untranslated fields return the default values.

The API enforces pagination with a limit of up to 50 results per request. Here is how to query product URL path translations using store.translations:

query getProductUrlTranslations { store { translations(filters: { resourceType: PRODUCT_URL_PATHS, channelId: "bc/store/channel/1", localeId: "bc/store/locale/fr" }, first: 50) { edges { node { resourceId fields { fieldName original translation } } } } } }

A product URL translation node pairs resourceId (for instance, bc/store/productUrlPath/77) with fieldName url_path, an original value like /fog-linen-chambray-towel-beige-stripe/, and the translated string /fr-fog-linen-chambray-towel-beige-stripe/.

To write or update strings, use the updateTranslations mutation. Pass entities containing the target resource URN and an array of field key-value pairs:

mutation updateProductTranslations { translation { updateTranslations(input: { resourceType: PRODUCTS, channelId: "bc/store/channel/1", localeId: "bc/store/locale/fr", entities: [ { resourceId: "bc/store/product/123", fields: [ { fieldName: "name", value: "Serviette en lin" }, { fieldName: "description", value: "Serviette en lin lavé de qualité supérieure." } ] } ] }) { __typename errors { __typename ... on Error { message } } } } }

When you need to remove a localised override and fall back to channel default data, call deleteTranslations:

mutation deleteProductTranslations { translation { deleteTranslations(input: { resourceType: PRODUCTS, channelId: "bc/store/channel/1", localeId: "bc/store/locale/fr", resources: [ { resourceId: "bc/store/product/123", fields: ["description"] } ] }) { __typename errors { __typename ... on Error { message } } } } }

According to the BigCommerce developer changelog, the platform added the BRAND_URL_PATHS resource type on 5 August 2026, followed by CATEGORY_URL_PATHS on 7 August 2026. Together with product URL paths, these let you translate category and brand URLs as well as product URLs.

How do Stencil and Catalyst resolve shopper locales?

The Storefront GraphQL API determines which locale to display by evaluating three inputs in order: an explicit directive, the shopper's browser preferences, or the channel default.

When querying the storefront, the @shopperPreferences(locale: "fr") directive takes precedence over the Accept-Language header specification on MDN. If no explicit preference is set, BigCommerce evaluates the header before falling back to the primary store language. You can inspect locale resolution directly:

query getStorefrontLocale @shopperPreferences(locale: "fr") { locale { resolved locales } }

Stencil exposes a language_selector object (added 7 August 2026), and Cornerstone 6.19.0 and the other listed theme releases ship a built-in language selector. In headless environments using the Next.js based Catalyst repository on GitHub, static UI copy is handled by the framework's native internationalisation libraries while dynamic catalogue data resolves through the Storefront GraphQL API. A custom headless frontend must build its own language switcher component using the Storefront GraphQL API to manage active locale state.

Stencil versus Catalyst: what differs

The data layer is the same on both: translations live in BigCommerce and are managed in the Translations Manager or through the Translations Admin GraphQL API. What differs is the theme side. On Stencil, the language selector ships with Cornerstone 6.19.0, Capacity 6.1.0, Fortune 4.1.0, Merchant 6.1.0 and Peak 5.1.0 or newer, so an older theme needs an upgrade before shoppers can switch language. On Catalyst (see our Catalyst CLI guide for provisioning and upgrades), static interface strings are handled by the built-in internationalisation framework while catalogue and checkout data arrive already translated from the Storefront GraphQL API. A custom headless storefront builds its own switcher on that same API.

Multi-language SEO structure and architectural limits

Translated product URLs and language-specific sitemaps help local search visibility by presenting crawlable endpoints for each regional market.

BigCommerce states that AI-assisted translations are only coming next in their product roadmap. Teams implementing multi-language today must supply their own translated strings via the Translations Manager interface or integrate automated translation pipelines using the GraphQL API.

In our experience, teams that rely only on automated feed translation tend to miss hardcoded theme strings and modifier options. A fully localised experience requires mapping custom modifier labels and form validation messages alongside the primary product descriptions.

Before you commit

Before switching your international commerce architecture to a single storefront, confirm that your operational model fits. If your regional markets share the same inventory pool, pricing structure, and legal entity, consolidating into a native multi-language storefront reduces operational overhead and removes redundant catalogue maintenance.

However, if your French or German operations require separate domestic bank accounts, segregated warehouse inventory, or distinct localised catalogues, multi-storefront is still the better fit. The new multi-language capability solves content translation, not fiscal segregation.

If you have an existing Stencil or Catalyst build ready to expand into European markets, our team can audit your theme version, connect the Translations Admin GraphQL API to your PIM, and check the translated URLs and language-specific sitemaps before launch through our BigCommerce development services. We start by mapping your translatable fields, confirming Stencil or Catalyst theme compatibility, and testing the GraphQL translation pipeline against a sample of your catalogue.