多语言一开就烧钱？先别装十个语言包 · Day 58

多语言不是「多翻几页」，是架构选型 + 翻译预算 + 发布节奏三件事一起算清楚。

Day 56 讲了 hreflang：多语言页之间怎么互相声明关系。 Day 57 讲了地理意图：同一语言下，不同地区也可能要不同页面。

今天 Day 58，往下挖一层：

多语言架构怎么选，翻译成本怎么控，i18n 库怎么挑——别一上来就变成无底洞。

很多人的失败路径很像：

1. 1. 英语站刚有点流量
2. 2. 听人说「上西语/葡语能翻倍」
3. 3. 连夜用 AI 全站机翻十个语言
4. 4. 子域名乱飞、URL 乱跳、hreflang 没配
5. 5. 三个月后：维护不动、收录乱、翻译费还在烧

这篇文章只干一件事：给你一套能落地的多语言架构清单。

先说结论（怕你没空往下看）

对 2026 年的出海工具站，默认推荐这套：

✅ 证据等级：URL 结构与子目录偏好，综合哥飞公开文章（子域名在 Google 侧更像独立站、权重冷启动更重）+ 社区常见实践；i18n 选型综合 2026 年 next-intl / next-i18next / Paraglide 等对比文。⚠️ 具体流量倍数因站而异，下文不写「保证翻倍」。

一、多语言真正贵的是什么

不是 API 那几块钱。贵的是：

1. 1. 维护：按钮、FAQ、邮件、支付说明、截图——英改一处，十语跟十处。没同步机制就是债。
2. 2. SEO 技术债：子域名选错、hreflang 写反、乱跳转、多 URL 互抢。Day 56 说过：hreflang 是声明关系，不是自动翻译。
3. 3. 质量债：单位错、法律词翻反、CTA 像诈骗、关键词当地人不搜。机翻解决「读得懂」，解决不了「会转化」。
4. 4. 产品一致性：英文已上新功能，西语还停三个月前——用户不信，搜索也不待见空壳矩阵。

多语言是产品决策，不是翻译插件决策。

二、URL 架构：为什么默认选子目录

三种常见结构

为什么工具站默认子目录

公开实践里，一个很硬的逻辑是：

搜索引擎更倾向于把不同子域名当成相对独立的站点来积累信号。 你开 10 个语言子域名，就接近冷启动 10 次。

子目录则在同一主域下扩展：

example.com/          → en（或默认）
example.com/es/       → 西班牙语
example.com/pt-br/    → 巴西葡语
example.com/de/       → 德语

哥飞写过多语言时也反复强调：多语言更建议子目录，而不是子域名。 （✅ 一手来源：哥飞《再聊多语言：为什么不建议使用子域名而更建议使用子目录》等公开文）

个人/小团队：先别炫技，先子目录。 只有合规强制本地域、品牌完全隔离、或有专职本地团队时，再谈子域名 / ccTLD。

三、翻译成本：五条能直接用的规则

1. 先验证需求，再开语言

开之前至少看三样，空一项就先别开：

1. 1. GSC / 分析里有没有该语言或国家点击
2. 2. 目标语有没有真实可做的长尾（量不一定大，但要真）
3. 3. 你 30 天内能不能维护该语言核心页（首页、核心工具、定价、FAQ）

没有需求信号的「十语言全开」，多半是自我感动。

2. 分层翻译

钱和时间砸在 P0。P2 只求可索引、不丢人。

3. 先术语表，再批量翻

最少固定：产品名、核心功能名、主 CTA、单位/货币/日期、禁用词。 没术语表的批量翻，同一按钮三种译法，转化先死。

4. 流水线，别手工复制粘贴

英文源（唯一真相）→ 术语表+Prompt → AI 分文件出稿
→ P0 人校 → 合入 messages/*.json → 预览排版
→ 发布 + sitemap + 抽查 hreflang

禁止在西语文件里「顺手改需求」——主语言会丢。

5. 算月维护预算

月成本 ≈ P0 改动量×人审 + 少量 token + 工程回归 + 多语言客服时间

连每月 2 小时都挤不出，就别开第 3 个语言。 ⚠️ 网上「加语言暴涨」是别人结果样本，不是你的承诺。

四、i18n 选型：2026 年工具站怎么选

下面默认你是 Next.js App Router 出海工具站（现在很常见）。 其他栈把原则带走即可。

选项对比（实用向）

✅ 2026 年社区对比文里的常见共识（⚠️ 第三方综合，非官方排名）：

• • 只做 Next.js 工具站、要快 → 多数人推 next-intl
• • 已有 i18next 资产 / 要跨 React Native → 继续 i18next 系更省迁移
• • 追求极致类型与 tree-shaking → 看 Paraglide / Lingui 路线

小团队默认：next-intl。 别在第一周同时评估 5 个库——评估本身就是成本。

选型时只问 6 个问题

1. 1. 是否原生支持 App Router / Server Components？
2. 2. 路由与 locale 前缀怎么处理？有没有 middleware 范例？
3. 3. 文案是否按 namespace 拆分？（工具页 / 营销页 / 错误码）
4. 4. 日期、数字、货币格式是否好做本地化？
5. 5. 复数、性别、ICU Message 是否需要？
6. 6. 和你的 AI 翻译流水线是否好对接（JSON/ICU 导出）？

6 个问题有 4 个答「费劲」，就换库。

架构上必须分开的三层

很多人把「翻译」和「本地化」糊在一起。建议拆开：

1. 1. UI 文案层（i18n） 按钮、导航、错误提示、空状态
2. 2. 内容层（content locale） 博客、帮助文档、pSEO 模板文案
3. 3. 业务本地化层（locale business） 货币、税、支付方式说明、合规文案、单位

i18n 库主要解决第 1 层。 第 2、3 层要用 CMS/MDX/配置表，不要全塞进一个 common.json。

五、推荐落地架构（可直接抄骨架）

1. 目录与路由

/app
  /[locale]
    /page.tsx
    /tools/[slug]/page.tsx
    /pricing/page.tsx
/messages
  en.json
  es.json
  pt-BR.json
/middleware.ts   → 检测/重写 locale

规则：

• • 每个语言页有独立可索引 URL
• • 语言切换时尽量保留路径（/es/tools/pdf ↔ /de/tools/pdf）
• • 不要只靠 JS 在客户端「假装换语言」却不换 URL

2. 文案命名空间

messages/en.json
{
  "nav": { ... },
  "tool.pdf": { "title": "...", "cta": "..." },
  "pricing": { ... },
  "errors": { ... }
}

按功能拆，不按「一页一个三千行文件」堆。

3. SEO 配套（和 Day 56 对齐）

• • 每个语言页输出正确 html lang
• • hreflang 互指 + x-default
• • 分语言 sitemap 或单一 sitemap 列全 locale URL
• • canonical 指向自身正确语言版本
• • 避免自动强跳把 Googlebot 踢去错误语言

4. 发布检查清单（每次加语言必跑）

□ P0 页人工过一遍
□ 术语表无冲突
□ 语言切换路径正确
□ hreflang 抽样 10 组
□ GSC 里新 URL 可抓取
□ 支付/退款/隐私政策已本地化（或明确仅英语适用）
□ 截图里的英文是否需要重做（视转化影响）

六、预算三档 + 五个坑

独立站长期停在 A→B 很正常。

五个坑：机翻从不回看；子域名子目录混用；只翻营销不翻报错；hreflang 指错协议/旧 slug；IP 强跳把用户和爬虫一起得罪。

七、一键执行清单

给英语站加第一个新语言：

1. 1. 只选 1 个有线索的语言
2. 2. URL 统一子目录，如 /es/
3. 3. Next.js 用 next-intl（或栈内等价），先跑通 1 页
4. 4. 术语表 50 词启动
5. 5. 只做 P0：首页、核心工具、定价、法律
6. 6. AI 翻 + 人校 P0
7. 7. hreflang + sitemap（Day 56）
8. 8. GSC 提交并抽查
9. 9. 30 天复盘：无展示/点击/注册 → 停扩先修
10. 10. 有信号再进档位 B

多语言最容易有幻觉：「页面多了 = 全球化了。」 真事是：有人搜到、看懂、信任、转化，而你还维护得起。

先把一个语言做透，再谈十个语言的版图。

Day 系列 · 模块四 · Day 58 上一篇：Day 57 · 出海工具站本地 SEO 下一篇：Day 59 · 小语种出海机会分析

Day 系列完整索引（持续更新中）

袁锐钦 · AI产品实操 & 出海工具站日更中。做产品、测工具、跑变现，把试过的路摊开给你看。