一开始只有英文壳
后面再补语言时，常常要重写路由、导航与 metadata。
Feature / i18n
既服务产品国际化，也服务多语言 SEO 的 i18n 基础层
BunShip 已包含 locale-aware routing 与双语内容基础，方便团队在多个语言市场上线，而不是等到站点已经有流量后再痛苦补国际化。
- locale-aware App Router 结构
- marketing 与 docs 的多语言路径
- 适合作为 multilingual SEO 起点
- marketing、app、docs 共用 locale 模型
2
现有语言
英文与中文已经覆盖到核心产品面。
3
多语言面
marketing、docs 与核心产品流共用结构。
SEO-ready
路由模型
本地化 URL 与 alternates 不是后补功能。
国际化已经体现在产品壳中，而不是一句 roadmap 注释。
Locale routesLocalized docs共享导航Search-ready 结构
这个页面要解决什么问题
多语言产品最怕的是把 i18n 一直往后拖，最后导致路由、metadata 与内容体系一起返工。
文档和 marketing 分裂
如果 docs 与 marketing 不共用 locale 模型，国际化维护成本会持续上升。
SEO 意图被拆碎
过早拆很多 hreflang / translation workflow 小页，往往只会做出薄页。
What's included
页面应该聚焦“多语言产品基础层”，而不是过早拆成一堆细碎 SEO 子页。
Locale-aware routing
marketing、docs 与 product pages 已经共用统一 locale 路径策略。
Localized docs support
文档中心已经能够承载多语言内容。
Metadata foundation
localized metadata 与 alternate paths 已在 SEO 层实现。
Why it matters
对独立开发者、创业团队和 agency 而言，i18n 更多时候是增长杠杆，而不是纯技术任务。
支持国际获客
更容易扩展到新语言市场与新内容面。
提高内容复用效率
marketing、docs 与未来 blog 都能复用同一多语言结构。
避免后补返工
不需要等有流量后再重构 locale 路由模型。
Implementation notes
更深的技术细节放在 docs 和 deployment 页面承接。
Who it's for
适合从一开始就要服务多个语言市场或多个地区客户的团队。
全球化独立开发者
不用等产品成型后再回头补双语壳。
区域化产品 agency
可以复用已经考虑 locale 路径与 metadata 的模板。
文档驱动型 SaaS
更容易保持产品界面与文档国际化的一致性。
FAQ
产品级 i18n 问题放这里，教程型与长尾问题放 docs / blog。
Next step
把 i18n 当成增长与信任资产，而不是以后再补的任务
继续看实现文档，或者配合 pricing / stacks 完成更完整的评估。