团队把界面翻译成十几种语言，开发人员用办公室 IP 打开网站，看到的语言是对的——看起来大功告成。实际上五层里只检查了一层。货币、价签中的税费、配送可用性,甚至商品目录里出现哪些商品,都不取决于浏览器语言,而取决于网站认为访客是从哪里连接进来的。不通过目标国家的真实地址,本地化核查就是盲测。
本地访客实际看到的内容会有哪些变化
货币并不总是根据语言设置自动换算——触发条件往往是地理 IP,国家识别一旦出错,该显示当地货币的地方就会显示成美元或欧元。价签中的税费是另一个变量:有的平台展示不含销售税的价格,有的展示含税价格,这个判断在后端根据访客地址完成,而不是根据所选的界面语言。
配送可用性是用本地 IP 才能看到的另一层。同样的商品页面,对一个国家显示「有货」,对另一个国家显示「无法配送」,页面结构完全一致。最后是商品目录构成:部分商品因授权限制、当地品类限制或缺货而按地区隐藏——只有从目标国家的地址访问才能看到这一点。
为什么界面翻译只测了一半
语言切换按钮是前端改动。货币、税费、配送和商品目录属于后端逻辑,与地理 IP 甚至 ASN 相关:部分定价服务会区分家庭地址和数据中心地址,给办公室代理展示的页面版本与普通用户不同。「文字已翻译、按钮都在」这种核查只回答了语言问题,没有回答目标国家的客户实际会看到什么。住宅地址与移动地址的差异在这里同样重要,详见移动代理与住宅代理对比。
本地化核查清单
第一,通过地理定位而非猜测确认国家与城市:地址必须精确解析到目标用户实际所在的位置。第二,核对目录页与结算页的货币,两者有时不一致。第三,最终价格中是否含税以及税额多少。第四,该地区的配送可用性与支付方式。第五,商品目录构成:用本地地址与常规 IP 分别查看商品列表,差异会暴露地区限制。
第六,界面语言以及日期、数字、电话格式是否符合当地习惯,而不只是语言切换本身。这些项目需要系统化核查,而非抽查——代理质量核查方法介绍了应依赖哪些指标才能得到可复现的结果。
只有本地地址才能看到的典型本地化 bug
第一,价格与实际相差 15%–20%,因为税费是否计入取决于 IP 所在国家,而非表单中填写的收货地址。第二,结算按钮可点击,但真正尝试配送到目标地区时,最后一步会报错——用办公室 IP 没人会走到这一步。第三,开发者用家庭 IP 能看到商品,但从目标国家地址访问时商品消失,原因是一个谁都不知道的地区门槛。第四,货币按语言而非国家切换,加拿大讲法语的用户看到的价格是欧元,而不是加元。
这类 bug 无论是办公室 IP 的人工测试,还是没有地理模拟的自动化测试,都无法捕捉:需要真正从目标国家出口,最好覆盖多种地址类型,因为不同平台对数据中心 IP 与住宅 IP 的处理方式不同。关于如何为核查任务选择合适的地址类型,可参考代理省钱是否真划算。
本地化核查会消耗多少流量
含图片的完整目录页约 2–5 MB,无媒体的纯文本页约 0.3–1 MB。核查一百个商品卡片的价格、税费与配送可用性大致需要 0.3–0.5 GB,对多个国家的一百个页面做每日监控约每月 1.5–3 GB。节省流量应通过在自动化核查中禁用图片与字体自动加载实现,而不是选择最便宜的通道:因地址不稳定导致的会话中断,代价高于省下的流量。
常见问题
核查本地化用数据中心 IP 够用吗？
核查界面语言与网站基本可用性——够用。核查价格、税费与商品目录——不一定:部分平台会给数据中心地址展示精简或不同版本的页面,因此核查精确价格更适合用目标国家的住宅或移动地址。
地址必须精确到目标用户所在的城市吗？
对税费和货币而言,通常国家级精度已足够,若税费按地区征收,有时需精确到州或省。对按邮编判断的配送和本地促销,城市级精度可能很重要,需针对具体平台单独核实。
网站核查过一次后,多久需要复查本地化？
价格、税费与目录逻辑的变化与界面发布节奏无关——供应商更新了价目表、税务规则变了、新增了一个地区门槛。合理的复查周期是每 2–4 周一次,或在任何价格或目录逻辑变动后立即复查。
用目标国家的代理亲自核查本地化——地址与类型的完整目录见代理专区。