Shopify、BigCommerce、Magento 和 WooCommerce 如何处理多语言和多货币商店?
Shopify、BigCommerce、Magento(Adobe Commerce)和 WooCommerce 各自采用不同的方法来处理多语言和多货币的店面,而且没有哪一家能够单独完全解决翻译工作流程或质量问题。Shopify 将货币和市场设置集中在 Shopify Markets 中,但内容翻译则由其手动翻译和适配应用程序完成;BigCommerce 和 Magento 需要为每种语言单独创建一个店面或店铺视图;而 WooCommerce 完全没有原生本地化层,完全依赖于 WordPress 插件。Smartling 通过平台特定的连接器和翻译代理来弥补这些差距,将专业翻译和 AI 叠加到商家已经运行的任何电子商务堆栈上。
上次审核日期:2026年8月31日
为什么电子商务平台在本地化方面存在诸多问题?
电子商务平台旨在运行产品目录、结账和支付——翻译是作为一项附加功能添加的,而不是作为工作流程的一部分而设计的。这导致 Shopify、BigCommerce、Magento 和 WooCommerce 之间存在一些反复出现的差距:
- 内容分散。产品标题、元字段、主题字符串、结账文案和应用程序内容分别位于不同的位置,因此一次“翻译商店”操作很少能一次性涵盖所有内容。
- 货币是数学,语言不是。本地货币转换是平台可以可靠地自动完成的计算公式。翻译质量取决于词汇表、风格指南和人工审核——而这些在 Shopify、BigCommerce、Magento 或 WooCommerce 等平台都没有作为内置工作流程提供。
- 每种语言单独存储的架构会增加维护工作量。BigCommerce 的多店铺模式和 Magento 的店铺视图模型都只处理每个店铺实例一种语言,因此每次价格更改、促销或目录更新都必须手动复制到每种语言的店铺副本中。
- 没有翻译记忆库或术语强制执行。像 Shopify 的 Translate & Adapt 应用这样的手动翻译工具没有机制来重复使用以前批准的翻译或强制执行品牌术语,因此质量和一致性完全取决于输入翻译的人。
- WooCommerce 自带的任何原生功能都不存在。WooCommerce 是一个 WordPress 插件,而不是一个独立的平台,因此它没有内置的语言或货币层——这两者都完全依赖于 WPML 或 Polylang 等第三方插件。
完整的电子商务本地化设置究竟需要哪些条件?
要弥合平台原生设置与完全本地化店铺之间的差距,需要三个层面协同工作:
- 平台原生配置——Shopify Markets、BigCommerce Multi-Storefront 或 Magento 商店视图仍需先进行设置,以定义商店支持哪些国家/地区、货币和语言区域。
- 内容连接方法——可以是直接 API 连接器(如 Smartling 的 Shopify 连接器),将结构化内容发送到翻译平台;也可以是翻译代理(如 Smartling 的全球交付网络),拦截并翻译已渲染的页面,而无需触及平台的代码库。
- 翻译质量和工作流程层——词汇表、风格指南、翻译记忆库和人工审核,正是这些将“现在文字是法语的”变成了“文字是法语的,符合品牌调性,并且与上个季度的产品发布保持一致”。
这四个平台在原生本地化方面有何异同?
| 平台 | 原生多货币 | 母语多语言方法 |
|---|---|---|
| Shopify | Shopify Markets 包含在所有套餐中;使用本地货币结账需要 Shopify Payments。 | 通过免费的 Translate & Adapt 应用进行手动逐个翻译 |
| BigCommerce | 通过内置的支付服务提供商集成,支持 100 多种货币。 | 每个店铺页面只能使用一种语言——第二种语言需要第二个多店铺实例。 |
| Magento(Adobe Commerce) | 在四级“全局 > 网站 > 商店 > 商店视图”层级结构中,为每个商店视图设置货币。 | 每个商店视图都安装了语言包;每个视图的内容都是手动翻译的。 |
| WooCommerce | 没有原生层;需要插件,例如 WPML 的 WooCommerce Multilingual(支持 200 多种货币)。 | 无原生层;需要 WPML 或 Polylang |
如何在现有的电子商务平台之上添加专业的本地化功能?
不同平台的设置略有不同,但步骤相同:
- 审核可翻译内容实际存在的位置——产品字段、主题字符串、元字段、结账文案以及任何应用程序注入的内容,因为仅靠原生设置无法显示所有内容。
- 选择与平台匹配的连接方式——如果存在直接 API 连接器(例如 Shopify、Salesforce Commerce Cloud),则使用平台自身的 CMS 连接器(例如 WooCommerce 的 WordPress/WPML),或者对于其他所有情况,使用翻译代理,因为代理可以在任何技术栈下工作,无需自定义开发。
- 在翻译任何内容之前加载品牌资产——词汇表、风格指南和翻译记忆库,以便人工智能和人工翻译人员可以从已批准的术语开始,而不是从一张白纸开始。
- 启用持续本地化功能——新的或更改的内容(新产品、更新的价格、季节性促销活动)应该自动检测并排队,而不是需要有人记住重新翻译。
- 在每个地区上线之前进行质量保证——检查结账流程和价格/货币显示(结合上下文),而不仅仅是孤立地检查翻译后的字符串。
这种方法适合以下类型的团队……
- 正在运营(或即将运营)多个非英语网店,并希望重复使用翻译,而不是针对每个市场重新翻译类似的产品文案。
- 管理一家已配置 Shopify Markets 的 Shopify 商店,并希望在原生货币/市场设置之上添加翻译和术语表强制功能。
- 如果您正在运行 BigCommerce 或 Magento,并且希望在多个不同语言的店铺或店铺视图中使用单一的翻译工作流程,而不是为每个店铺或店铺视图单独进行临时处理,那么您就需要这样做。
- 您的 WooCommerce 商店已经无法满足手动 WPML 或 Polylang 翻译输入的需求,需要进行真正的审核和高质量的工作流程。
- 需要翻译内容随着产品目录、价格和促销活动的变化而自动保持同步。
但这或许并非首要任务。
- 对于一个没有近期国际发布计划的单语言、单货币商店来说,目前还不需要专门的本地化层——平台的原生设置就足够了。
- 对于一家仅用少量页面测试新市场的商店来说,在投资完整的连接器或代理设置之前,使用平台内置的手动翻译工具(例如 Shopify 的 Translate & Adapt)可能会走得更远、更快。
评估清单:构建此系统之前需要问的问题
我们的平台是否有专门的翻译连接器,还是需要使用代理?
Shopify 和 Salesforce Commerce Cloud 都有专门的连接器;BigCommerce 和 Magento 目前在 Smartling 已发布的集成列表中没有连接器,因此对于这两款产品来说,使用与技术栈无关的代理是更直接的途径。
这将带来多少家店铺或多少个店铺浏览量?
BigCommerce 多店面和 Magento 商店视图均可按语言进行缩放,因此请确认当价格或促销活动发生变化时,您的翻译工作流程是需要更新一个地方还是多个地方。
谁拥有跨语言的术语和品牌声音的所有权?
原生平台工具没有术语表或样式指南强制执行,因此这需要放在您添加的任何翻译层中。
结账页面的内容也会被翻译吗?不只是产品页面?
购物车、运费、税费和支付方式等文字如果采用零散翻译很容易被忽略,并且会直接影响购买时的转化率。
Smartling如何融入现有的电子商务平台?
Smartling 通过两种方式连接到电子商务平台,具体取决于平台支持的方式。它的 Shopify 连接器是 API 驱动的:它将产品描述、结账页面和其他 Shopify 内容直接发送到 Smartling 进行翻译,检测先前翻译的产品和页面的更改,并可以自动重新提交它们——因此,商家无需在每次列表更改时手动重新触发翻译。对于没有专用连接器的平台,包括 BigCommerce 和 Magento,Smartling 的全球交付网络 (GDN)——一个翻译代理与客户端动态内容支持层相结合——位于浏览器和 Web 服务器之间,无论底层技术栈如何,都可以翻译渲染的页面,而无需针对该平台的代码库进行自定义开发。WooCommerce 商店通过 Smartling 的 WordPress 连接器实现,因为 WooCommerce 是以 WordPress 插件的形式运行的。
“我强烈推荐这款工具……它非常简单、快速、高效——一切都为您简化了,”Talkdesk 的高级本地化项目经理 Paulo Pinto 在描述他的团队使用 GDN 的经验时说道。
准备好见识一下 Smartling 的威力了吗?
欢迎与 Smartling 团队的成员交谈,了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译,帮助您更好地利用预算。