localization-strategy

本地化策略

负责本地化决策与交付的端到端生命周期。不要把本地化当作翻译所有源页面，或在内容尚未准备好时创建本地化路由的请求。

职责范围

• 本技能负责市场与区域语言选择、范围、技术架构、发布、迁移、发布门槛和衡量。
• translation 负责译文、术语、风格、审校以及源内容变更后的更新。
• keyword-research 负责目标市场的查询词研究；不要翻译源关键词列表。
• page-metadata、canonical-tag 和 url-structure 负责各自专业领域的实现细节。在此处与它们协调，但不要重复其完整规则。
• 在项目上下文或实现仓库中保留项目特定的产品事实、路由清单和术语。不要将它们转化为通用规则。

确认当前状态

如存在，请阅读根目录的 contextus.md。根据生产网站、路由或 CMS 清单、导航与内部链接、站点地图、源代码仓库、分析数据和搜索数据（视可用情况而定）收集证据。仅凭站点地图无法获得完整的页面清单。

确认：

• 目标市场、语言及实际的区域差异；
• 当前和拟议的公开 URL 模式；
• 默认区域语言，以及是否带前缀；
• 哪些页面类型已本地化、仅提供源语言，或因市场而异；
• 内容负责人、术语表、审校能力和更新频率；
• 当前路由、规范链接、hreflang、站点地图、语言切换器和回退行为；
• 需要重定向或兼容处理的现有已编入索引 URL。

如果网站有数千个使用相同模板的页面，请清点页面类型和代表性示例，而不是逐一列出所有 URL。

决定是否推出某个区域语言版本

根据现有需求、搜索机会、转化或收入潜力、竞争深度、支付与支持准备情况、合规性，以及团队持续更新内容的能力等证据，为区域语言版本确定优先级。

区分以下决策：

1. 语言支持：界面或内容可使用某种语言。
2. 区域语言支持：拼写、格式、货币、术语或产品行为存在差异。
3. 市场进入：某个地理区域的定价、支付、渠道、信任证明、支持和合规均已准备就绪。

不要仅因国家不同就创建国家/地区专属副本。新的区域语言版本必须对应需要持续维护的用户或市场差异。

定义覆盖模型

创建页面类型或路由系列矩阵，并为每种区域语言指定一种状态：

状态	含义	公开行为
source-current	源语言页面内容是最新的	源语言 URL 公开
translation-draft	已有译稿，但尚未获批	仅供预览或设置为 noindex
localized-ready	内容、术语、事实和元数据均已通过审校	区域语言 URL 可以编入索引
outdated	区域语言内容获批后源内容发生变更	按风险等级保留页面、在内部发出警示并加入审校队列
not-applicable	产品或内容不适用于该市场	不要人为创建对应页面

核心产品、定价、结账、法律和高意向页面的发布门槛应高于低风险的支持内容或用户生成内容。不要发布仅以区域语言外壳包裹源语言正文的区域语言 URL。

选择 URL 和路由架构

公共本地化页面应使用稳定且便于抓取的 URL。子目录通常更易于运维，但如果托管、所有权、法规或市场运营方面的需求有此依据，也可以使用子域名或国家/地区顶级域名。不要声称某一种结构普遍更优。

关键不变量：

• 每个可编入索引的语言区域页面都有一个稳定的公共 URL；
• URL、渲染语言、<html lang>、导航、元数据和结构化数据描述的是同一语言区域；
• 语言切换器使用易于发现的链接，并且在存在对应页面时保留当前页面上下文；
• 用户偏好可以改善回访体验，但不能取代公共语言区域 URL；
• 缺少译文时，不得在本地化 URL 下静默显示源语言内容；
• canonical、hreflang、站点地图、内部链接和重定向对公共 URL 形式的设置保持一致。

根据实际区别使用合适的 BCP 47 语言或语言区域标识符。不要仅为 SEO 而虚构区域变体。

协调内容制作

对于每个已批准的语言区域：

1. 锁定源版本，并记录页面类型、受众、意图、声明、限制和负责人。
2. 使用 keyword-research 研究目标市场，而不是翻译源语言查询词。
3. 使用 translation 生成文案、术语表决策、风格指南和审核证据。
4. 仅在确认适用于该市场时，才调整示例、证明材料、定价、支付方式、日期、单位、图像和合规内容。
5. 确保功能可用性和法律声明对应实际语言区域或市场。
6. 只有内容和实现均通过关卡后，才将该语言区域标记为 localized-ready。

法律或受监管内容需要由主题专家审核。除非获得授权律师修改，否则翻译必须保留当事方、数字、义务、权利、司法管辖区、版本优先级和章节对应关系。

迁移现有语言区域 URL

替换查询参数、Cookie、旧前缀、域名或路由系统时：

1. 记录当前 URL 和行为清单，包括已编入索引及被外部链接的变体。
2. 冻结目标公共 URL 策略和语言区域映射。
3. 将旧 URL 映射到最相当的新语言区域 URL。
4. 在替换旧公共 URL 时添加永久重定向；在安全的情况下保留相关路径和查询状态。
5. 更新内部链接、语言切换、canonical、hreflang、站点地图、结构化数据和分析细分。
6. 保留兼容性重定向，直到日志和搜索数据表明不再需要；不要采用任意且普遍适用的保留期限。
7. 定义回滚触发条件，并确认回滚不会恢复相互冲突的索引信号。

框架示例可能有用，但公共 URL 和内容状态不变量优先于特定的 Next.js 或 i18n 库配置。

发布验证

验证可观测到的生产环境行为，而不只是配置文件：

• 每种页面类型和语言区域的代表性 URL 均返回预期状态；
• 初始 HTML 包含正确的语言、标题、描述、canonical 和适配语言区域的结构化数据；
• 只有在确实等效且已发布的页面之间，hreflang 才相互对应；
• 语言切换会跳转到对应页面，或者明确说明不存在对应页面；
• 不得让语言区域 URL 显示混合语言内容或源语言回退内容，并将其伪装成本地化内容；
• 站点地图只包含 canonical、可编入索引且已发布的语言区域 URL；
• 重定向链有限、保留预期目标，且不会暴露重复的公共 URL 形式；
• 在存在对应目标页面时，内部链接保持在当前语言区域内；
• 构建、lint、路由生成和项目专属测试均通过。

对于规模极大的路由集合，使用有代表性的样本，并为路由系列添加自动化检查。

监测与扩展

按语言区域和市场衡量，而不只看全球总量：抓取/索引覆盖率、展示次数、点击次数、转化次数、激活量、收入、支持工作量和过时内容率。报告关键词蚕食、错误语言区域排名或索引冲突；未经授权，不要自动重构页面。

首个语言区域证明内容发布和源内容变更同步流程可持续维护后，再进行扩展。单纯追求数量并不代表成功。

输出

仅提供请求所需的内容，例如：

• 语言区域和市场决策；
• 当前状态发现；
• 覆盖矩阵和归属；
• URL 或迁移映射；
• 分阶段实施计划；
• 发布和生产环境验证结果；
• 尚未解决的产品、法律或市场决策。

如果现有项目 SSOT 或实施 Skill 可以更新，就不要新建规划文档。

相关 Skills

• translation：内容制作、术语表、风格、语言审校和更新工作流
• keyword-research：目标市场的搜索用语和意图
• page-metadata、canonical-tag、url-structure：SEO 和 URL 实现专项工具
• pricing-strategy、gtm-strategy：市场经济情况和进入规划
• navigation-menu-generator：语言切换器和便于发现的导航