语言按钮明显，只完成了双语体验的一小部分。对小企业来说，更难的是后续维护：一项服务变了，英文页面更新了，中文页面却一直保留旧信息。好的结构应该让这种不一致更难发生，也更容易被发现。
共享事实，不一定逐句对应
价格，时间，联系方式和服务编号，尽可能使用同一份业务记录。围绕这些事实的表达可以不同，因为自然沟通不一定逐句翻译。英文短标题可能需要不同的中文布局，一项服务也可能需要解释，而不是直接换几个字。
先确认谁能审核两种语言的业务事实。自动翻译可以帮助形成草稿，但价格条件，取消规则和服务声明仍需要人确认。不能让某一种语言变成隐藏重要例外的角落。
每种语言有稳定的页面地址
Google 的官方说明介绍了如何标记互相对应的语言页面。我们的架构为英文和中文保留各自的 URL，并指向相应语言版本。可见的切换按钮也遵循这个对应关系，而不是每次都把访客送回首页。
规范网址和语言替代关系负责不同的事情，应由发布流程明确生成，不要把所有翻译页都当作需要丢弃的重复页面。原来的指南地址保留不变，新文章区也使用同一套语言结构。具体实现应该结合当前官方说明，而不是复制另一个网站的代码片段。
语言，币种和地区分开处理
阅读中文，不代表顾客身在中国。阅读英文，也不代表一定想看美元。两项选择应各自独立，清楚显示当前状态，并允许修改。地区检测可以提供建议，但较晚返回的网络响应不应该覆盖用户自己的选择。
进入询盘时，应保留已选币种和方案。切换语言需要更改 URL 时，可以保留这些非敏感选择，但不要把姓名，邮箱和自由填写的需求放进地址栏。
把内容修改当作一次小发布
不要只看某个文本框有没有更新。先列出受影响的页面，修改共享事实，检查两种语言，查看手机排版，再确认预约或联系目标。保留一份简短的修改与审核记录。
先维护得过来，再增加数量。少量完整而准确的服务页，比几十篇无人复核的翻译更有用。我们目前的文章系统要求中英文都准备好，才能进入发布状态，草稿不会进入公开路由和订阅源。这是本项目的编辑保护措施，不是所有网站都必须采用的唯一方式。
交接要让老板真正会用
老板应该知道哪些字段可以安全修改，另一个语言版本在哪里，以及发布前要检查什么。用改一次营业时间或服务描述这样的实际任务进行培训。能够独立重复完成，才比单纯交付一个账号更接近真正的交接。
把语言元数据当成发布流程的一部分
页面上的语言按钮只是多语言网站的一小部分。每个页面还需要正确声明语言，对应语言版本之间也要有稳定关系。Google 说明了 hreflang 可以怎样标记本地化版本，W3C 则解释了页面语言声明为什么会影响浏览器和辅助技术。
真正重要的不是背一段代码，而是让这些关系从同一套路由和内容模型自动生成。如果编辑者可能单独新增中文页却忘记英文对应页，或者改了一个地址却没更新 alternate link，这个流程就太脆弱。
把共享事实和本地化表达分开
有些信息应该在两种语言完全一致：营业时间、套餐标识、经过批准的价格、预约链接。有些内容则应该允许本地化：服务解释顺序、例子、术语和语气。把两类东西混在一起，审核会越来越难。
可以建立一个小型“共享事实层”，两种语言围绕这些事实各自表达。事实变化时，系统知道哪些页面都受影响；只是文案变化时，各语言审核者可以判断自然度，而不用重新确认业务规则。
表达可以自然不同，业务承诺不能因此改变。
- 批准价格与服务标识
- 当前时间与预约入口
- 范围与真实政策条件
- 清楚术语与解释顺序
- 读者能够理解的例子
- 自然措辞与相同限定条件
只有市场真的不同，才建立地区版本
语言和地区不是同一个维度。加拿大英文页和美国英文页可能大部分内容一样，但货币、税费措辞、服务范围或政策不同。Google 关于 locale-adaptive 与多地区网站的说明提醒我们，不要把浏览器语言当成可靠的市场判断。
如果服务本身没有变化，就不要为了“国际化”增加一堆地区 URL。更多地址意味着更多维护成本。一个英文文章可以同时配手动货币选择；只有服务规则真的不同，才更可能值得单独地区版本。
内容量变大之前，先设计发布和回退
双语运营最昂贵的时候，是一次很小的修改需要靠人记住几十个地方。应该提前定义一次发布包含什么：共享事实修改、英文审核、中文审核、链接检查、手机检查和最终批准。新版本构建成功之前，旧的公开版本继续可用。
更完整的双语内容运营指南会继续讨论 API、审核和发布流程。这篇短文承担更简单的任务：让小企业主先理解，真正困难的不是“有没有语言按钮”，而是两套公开内容能不能长期保持真实。
