On August 21, 2026, BigCommerce provided an example of this: native multilingual support, generally available, that manages language variants within the platform instead of splitting the store by language. That’s a real feature. It’s not a decision. The decision is where the translation resides – in the platform, in a layer in front of it, or in the source. And its impact lasts long after the project goes live.
Blackbit is a commerce engineering partner for mid-sized e-commerce companies in the DACH region that want to tap into new markets without duplicating their product data management efforts.
Technically, there are three approaches, and they differ in terms of where the translation is located. First, within the store system itself: the platform natively manages language variants and creates language subfolders without duplicating the catalog. Second, in a translation layer that acts as an intermediary between the platform and the user, translating content at runtime. Third, at the source: product data is translated in the PIM and transferred to the store as if it were natively managed content. All three result in a multilingual store – but with different operating costs, varying levels of SEO depth, and differing degrees of dependence on a single provider.
My experience with multilingual BigCommerce stores comes from multi-storefront implementations and from Weglot, not from the new native feature. This distinction is important: How many storefronts a market needs is a different decision than where translations are maintained. Four criteria are decisive for each of the three approaches – SEO depth, data sovereignty, maintenance and scalability, and cost model.
Native to the platform. The platform manages language variants itself and creates language-specific URL subfolders without duplicating the catalog. BigCommerce manages its native multilingual support via a Translation Manager or the GraphQL API and, according to its documentation, covers products, checkout, payments, shipping, and post-purchase communication. Shopware and Shopify approach the same task differently, each according to their own documentation: In Shopware, languages are separate entities assigned to sales channels, and each sales channel can be assigned its own domain or subdirectory. Shopify maps languages via Markets, manages content in Translate & Adapt, and assigns unique URLs for each language. SEO depth: All three generate standalone, indexable language-specific URLs; market-specific content and metadata still require editorial review. Data sovereignty: The translated texts are stored in the platform’s database. For product texts, this is rarely a data protection issue, as personal data is generally not stored there. It is a matter of dependency and traceability: The platform remains the leading system; exports occur via its interfaces; and versioning and audit trails extend only as far as the platform provides them. Where the hosting location and legal jurisdiction themselves become criteria, this should be factored into the platform selection decision. Maintenance and scalability: Every platform has upper limits – for BigCommerce, for example, about five locales per storefront. Cost model: Confirm availability and costs for the selected plan; budget for implementation, translation, and proofreading separately.
Translation layer, example: Weglot. A cloud layer between the platform and the customer, integrated via a JavaScript snippet or a plug-in. New content is automatically machine-translated and delivered as part of the page layout; manual corrections can be made afterward. SEO depth: It’s not the product that matters here, but the type of integration. Weglot notes in its own documentation that client-side JavaScript integration is not SEO-friendly; the subdomain and subdirectory variants perform server-side translation, assign their own URLs, and automatically set hreflang. So check first which variant you’re using—this determines whether the translated pages will even be indexed in the target market. And this doesn’t just affect Google: In the most comprehensive study on this topic to date (Vercel and MERJ, December 2024), none of the major AI crawlers executed JavaScript. What is generated only in the browser does not exist for them—and therefore does not appear in their responses either. Data sovereignty: The translations are managed by the provider; check the export access and migration terms for the selected plan. Maintenance and scaling: Not only new content, but also changes to existing content are automatically captured and retranslated. Manual corrections are not lost in the process; they remain in the translation list – but the new machine-translated version is displayed. Verified metadata must therefore be checked again after a change to the source. Cost model: tiered subscription based on word count and number of languages, published on Weglot’s pricing page.
Translation in the source system – example: Pimcore with Data Director and DeepL. Content is translated and stored in the source system. The Blackbit Data Director connects Pimcore to a provider such as DeepL and can automatically trigger the translation as soon as source content changes; on-demand workflows are also available. The results are stored as language variants in the PIM and transferred to the online store. This model is platform-independent: Whether the target platform is Shopware, Shopify, or BigCommerce, language control remains within the PIM – we follow the same approach in Shopware projects. SEO depth: Content can be editorially adapted for each market instead of being translated word for word. Data sovereignty: The translated fields are maintained in the PIM; processing via DeepL must be considered separately – verify the provider’s processing locations and contractual terms. Maintenance and Scaling: The data model must support multiple languages, and triggers must be configured in advance; after that, recognition runs automatically. Cost Model: Budget for the PIM and integration, plus translation usage. The DeepL Growth API plan combines, according to DeepL, a fixed base fee, an included character quota, and usage-based costs for exceeding that quota.
Five questions do most of the work, and none of them are about the platform.
How many target languages? The native approach and the layer can handle a handful without any issues; the higher the number, the more important automatic detection becomes. Additionally, platforms have limits on the number of languages per storefront – about five on BigCommerce, for example. You should be aware of this limit before choosing your approach, not after.
How SEO-relevant are the target markets? For critical markets, check how editable the content and metadata are, how the language-specific URLs are structured, and how the approval process works – base your decision on the actual implementation, not on the category. Weglot documents the editing of translations, meta titles, and descriptions; editorial control is therefore not a unique selling point of the PIM approach.
How quickly does the content change? Fast-moving content is well-suited to the Layer’s automated capture; a stable catalog benefits more from editorial quality in the source.
What do data sovereignty and auditability require? B2B companies and regulated industries should answer this question before choosing an approach, not after.
How much editorial capacity is available? The source-based approach requires someone to configure the translation triggers and review the results. Without this capacity, automation won’t work properly on its own.
A hybrid setup can assign product and category translations to the PIM and editorial pages to a layer, with clearly defined rules for responsibility and updates for each content type. While this division is part of a broader shift toward modular architecture, our article on Composable Commerce explains when this step is worthwhile - a hybrid translation setup alone does not yet constitute Composable Commerce.
Four risks are worth examining before launch.
Automated localization without human oversight. Machine translation captures the vocabulary; however, it does not reliably capture cultural nuances, tone, or technically correct but contextually awkward phrasing. Someone must review the output.
Plan language URLs and hreflang together. Google recommends using separate URLs for language versions and markup that points to the alternatives; both should be checked before launch and are described in Google’s documentation on managing multiregional websites. And don’t rely on your system to handle everything: The hreflang value “x-default” cannot always be set in common CMS platforms – a gap we’ve already encountered in practice.
A new market without a well-maintained PIM. The storefront goes live in the new language, but the product data behind it doesn’t receive the same editorial attention as in the home market. Listing quality suffers.
Visibility in the target market isn’t measured – least of all in AI-generated responses. Without a baseline, it’s impossible to tell whether the brand even appears there – let alone whether the chosen approach is effective.
Making an online store multilingual is not a translation task, but an architectural decision with three approaches. First, the platform’s native language feature: language variants and language subfolders are created within the store system itself, without duplicating the catalog – BigCommerce made such native multilingual support generally available in August 2026, and Shopware and Shopify offer comparable mechanisms. Second, a translation layer like Weglot, which acts as an intermediary between the platform and the user: new languages go live within hours, but the translations are managed by the provider. Third, translation at the source: Product data is translated in the PIM and delivered like natively maintained content – in the Blackbit stack via the Blackbit Data Director with DeepL integration. Which approach is best depends on the number of target languages, the SEO relevance of the target markets, the frequency of content updates, and data sovereignty requirements; hybrid setups are a valid option when different content types require different workflows. Blackbit digital Commerce, based in Göttingen, supports medium-sized e-commerce companies in the DACH region with this decision and implements solutions in Pimcore, Shopware, BigCommerce, and Shopify.
If you’re planning to internationalize in the next two quarters: Describe your setup to us – data model, SEO situation in the target markets, editorial capacity – and we’ll classify the three approaches for your specific case. No platform preference.