为多语言内容建立清晰边界

Astro Kami 目前支持 en、zh 两种本地化路径。语言已经从一个全局设置，变成路由、内容和界面都能明确感知的上下文。

多语言支持最容易被低估的地方，是把它理解成一张“待翻译字符串清单”。翻译当然重要，但真正决定系统能否长期维护的，是内容之间如何建立关系，以及缺少翻译时页面应该怎样表现。

URL 是公开契约

语言应当出现在稳定、可预测的 URL 中。Astro Kami 采用以下结构：

• /zh/posts/…：简体中文内容
• /posts/…：默认语言英文内容，保留原有 URL

URL 一旦被搜索引擎收录或被读者分享，就很难随意改变。因此，我们需要先确定默认语言是否带前缀、旧链接如何重定向，以及不同语言版本之间如何通过 hreflang 互相声明。

内容不是字符串的集合

同一篇文章的不同语言版本应该共享一个稳定身份，但可以拥有不同的标题、摘要、发布时间和正文结构。当前语言由内容目录决定；未来建立翻译关系时，内容模型还需要补充稳定的翻译标识：

interface LocalizedPost {
  translationKey: string;
  title: string;
  description: string;
}

translationKey 用来说明两份内容互为翻译，内容所在目录则决定路由、日期格式、页面语言属性和可用字体。它们承担的是不同职责，不应该只靠文件名猜测。

先约定回退，再处理缺失

并非每篇文章都会同时拥有所有语言版本。与其在运行时悄悄混用语言，不如把回退规则写清楚：

界面文字

缺少翻译时可以回退到默认语言，同时在开发环境给出提示。

文章正文

不自动拼接其他语言正文；页面应明确告诉读者当前没有对应译文。

元数据

标题、摘要和社交图片必须与当前页面语言一致，避免搜索结果语言错位。

视觉系统也要理解语言

中文、英文和其他文字系统对字体、字重、行宽及断行有不同要求。多语言支持因此也是视觉系统的一次压力测试。

这也是新增中文样例文章的原因：在真正改动组件之前，我们先准备能够暴露问题的内容。之后每一次调整字体、间距或路由，都可以同时用 Markdown 与 MDX、中英文和宽窄屏进行验证。

最终目标不是让每个页面都塞满语言判断，而是让语言边界足够清楚：内容知道自己属于哪种语言，路由知道应该展示什么，组件只负责呈现已经确定的结果。