i18n 工程化：十种语言，不靠硬编码

做多语言最容易犯的错误，是在组件里直接写一句中文，然后想着「以后有空再抽出来」。结果是文案越写越多，最后没人知道哪些已经翻译、哪些还是漏网之鱼。

本站的做法是从一开始就把界面文案集中管理。

一个 Key，十份翻译#

所有用户可见的文案都通过 I18nKey 枚举引用，再交给翻译模块解析。组件里不出现具体语言：

1
import I18nKey from "@i18n/i18nKey";
2
import { i18n } from "@i18n/translation";
3

4
const title = i18n(I18nKey.archive);

至于 archive 最终显示成「归档」还是「Archive」，由当前语言决定，组件不需要知道。

带参数的文案是最容易出错的地方。例如「共 {count} 篇」在每种语言里都必须保留 {count} 这个占位符名，否则替换时就会丢值。

当某个语言缺少某个键时，系统需要一个确定的回退顺序。本站优先使用当前语言，缺失时回退到默认语言，而不是直接显示键名。

自动翻译可以解决一部分重复劳动，但界面文案往往很短，缺少上下文。一个词在不同页面可能有完全不同的语气。机器翻译很难保证这种一致性。

界面文案是产品语气的一部分，不能只当成字符串替换。

本站默认语言是简体中文，但 i18n 结构并没有因此简化。这样做的好处是：以后如果增加英文界面，不需要回头重构组件，只需要补翻译值。

分类和标签也要翻译吗？

分类、标签和系列名属于内容，不是界面文案。它们由作者直接填写，因此不进入 I18nKey 体系。界面框架（如「分类」「标签」这些标题）才需要翻译。

i18n 的难点不在翻译本身，而在「让所有文案都有归属」。当每个字符串都能追溯到一个键，遗漏和重复才会变得可见。

对个人博客来说，这套机制可能有点重；但它带来的确定性，在长期维护中很划算。