“我们英文站上线了，为什么巴西客户还是不下单？”
去年一个做家居用品的客户这么问我。我打开他们的站——英文版挺像样，切到葡语就散架了：商品标题是机翻的，尺码表还是英寸，结账页要求填 ZIP Code（巴西填的是 CEP），支付只有信用卡（当地人在用 Pix 和 boleto），客服邮箱是北京时间早九晚六。
这不是语言问题。语言只是最外面那层皮。
多语言其实是四层，别混着做
| 层次 | 里面是什么 | 谁管 | 变动频率 |
|---|---|---|---|
| UI 静态文案 | 按钮、报错、导航、邮件模板 | 前端 | 低 |
| 商品内容 | 标题、卖点、详情、规格、图片里的字 | 运营 / PIM | 极高 |
| 交易字段 | 地址格式、货币、税、支付、尺码单位 | 后端 | 中 |
| 服务与政策 | 退换货、物流时效、客服时区和语种 | 运营 | 中 |
大部分公司只做了第一层，就以为做完了。
语言不等于国家，映射关系要先定死
香港是繁体加英文并存，只给简体是个漏。新加坡英文为主，简体是加分项，但别默认人人都看中文。巴西用 pt-BR，不是 pt-PT，拿欧洲葡语语料翻出来的东西读着别扭。南非以英语为主，局部加南非荷兰语。尼日利亚、塞拉利昂用英语。尼日尔用法语。
URL 建议一语言一个可索引地址，比如 /zh-hant/、/pt-br/、/en-sg/，互相加 hreflang。别用 cookie 或 IP 自动跳转——爬虫看不到，用户分享出去的链接也会乱。
翻译别塞进商品主表
最省事的做法最坑：给 products 加 title_en、title_pt、title_es……加到第七个市场的时候，你就再也不想上新市场了。
正经做法是一张 translation 表：entity_type、entity_id、field、locale、value、status（机翻 / 待审 / 已审）、updated_by、updated_at。读取时走 fallback，pt-BR 缺了落 en，en 缺了落 zh，但每次 fallback 记一条日志，月底就知道哪个语种最缺内容。
主表只留业务事实：SKU、价格、重量、库存。文案全部走翻译表。这样加语种是插数据，不是改表结构。
三个地方最容易翻车
价格。 不是乘个汇率就完事。巴西报含税价，美国不含税，欧盟含税。尾数策略也不一样，.99 在有的市场显得便宜，有的市场无所谓。价格得按站点配置“含税展示 / 取整规则 / 展示货币”，不能一个字段全站复用。
地址和身份。 巴西要 CPF；尼日利亚很多地方没有邮编，靠 landmark 和 LGA 定位；南非有 suburb 这一层。表单如果写死“州 + 邮编必填”，这些市场直接在付款页卡死。字段要能按站点配：要哪些、什么格式、怎么校验。
支付和客服。 支付不本地化，转化上不去；客服不本地化，退货和差评就上来。巴西和非洲大部分地区，WhatsApp 是主渠道，邮件反而靠边站。
几个真踩过的坑
- 只翻了 UI，商品还是中文，客户点进去一脸问号。
- 没建术语表。一个“充电宝”全站三种写法，自己的页面互相抢词。
- 图片里的促销文字没换，中文水印挂在葡语页上。
- 长文案直接塞按钮。德葡语种比中文长 30%–50%，按钮直接撑破。
- 上线后才有翻译流程，运营改一句话要提需求等发版。
落地顺序
- 先定两三个目标市场，别一次开十个语种。
- 先搭多语言数据模型和 fallback，这是地基。
- UI 文案进词条库，运营自己能改。
- 商品先做 Top 20% SKU 的人工审校，长尾机翻加抽检。
- 每个站点跑通一单真实下单：地址、货币、支付、税。
- 再补 hreflang、分语种 sitemap，以及各语种关键词——是找当地人真实在搜的词，不是把中文词直译过去。
这套东西说穿了不复杂，就是琐碎，尤其是边开新市场边维护老系统的时候。我们做过几个覆盖港澳、东南亚、非洲和南美的跨境项目，上面这些坑基本都踩过。如果你正卡在“加了英文版但没人下单”这一步，可以聊聊，看看是补一层还是重做地基。
