北京
在 Lumora，我们用 AI 制作个性化儿童书，并用十种语言创作。今天想讲一个我们在国际化（i18n）路上撞上的真实问题，以及它带来的教训。这不是代码 bug，却让我们重写了一整场营销活动。
几乎所有团队都会把“语言”和“国家”混为一谈。我们在界面语言选择器里放上“ES”，把所有文案抽到 JSON 文件，然后交给翻译，就认为任务完成了。这套流程通常没问题，直到你的产品开始涉及“日期”。
那天我们发现：西班牙语不是一个市场，而是好几个共享词汇的日历。
具体发生了什么？我们策划了一场用西班牙语写的节日礼物活动。语法正确，翻译审核通过，没有任何拼写错误。结果，对相当一部分读者来说，它完全是错的。
在西班牙，儿童礼物的重大时刻不是 12 月 25 日，而是 1 月 6 日的“三王节”（Reyes Magos）。我们的文案写着“请在 12 月 24 日前下单”，对西班牙家庭来说，这等于把截止日期提前了近两周，而真正的送礼日还在后面。
在墨西哥，两种习俗共存：家庭既过圣诞，也过三王节，1 月 6 日还会吃“rosca”面包。一个统一的截止日期，显然无法同时覆盖这两种节奏。
在阿根廷、智利或乌拉圭，12 月 25 日没错，但那是盛夏，气温常到 30 度；学校长假刚刚开始，而不是结束。圣诞、暑假、开学季，三者关系与北半球国家完全不同。
请注意这里的麻烦：三个案例说的都是西班牙语，都通过了同样的翻译校验，却需要完全不同的推送文案、配图、截止日期和购买引导。任何一个写死日期的规则，都会伤害其中一部分用户。
葡萄牙语也有同样的坑。在巴西，圣诞节同样在盛夏，1 月是全民休假月，而家庭生活真正重新回到轨道的日子，不是 1 月 1 日，而是 2 月的“返校日”（volta às aulas）。如果你在内容日历上写下“新年新习惯”并在 1 月启动，等于在巴西人还躺在沙滩上时，提前了一个月打扰他们。
最自然的技术方案是：使用 locale 代码，比如 es-ES、es-AR、pt-BR。这个答案对不对？对，但几乎解决不了问题。locale 只告诉系统“用户用哪个变体”，它不知道马德里、墨西哥城和布宜诺斯艾利斯面对的是三种完全不同的节庆时间线。
事后我们明白，真正的国际化不是把“December 25”翻译成“25 de diciembre”，而是理解一个日期在不同市场上意味着什么。日期是文化符号，不是字符串。你可以在代码里写满 if-else，但如果初始模型里就没有“日期+地区+文化事件”的维度，任何翻译质量都无法救回一场活动。
这次失误让我们重写了一整场活动，也让我们在设计 i18n 策略时，把“日期逻辑层”和“语言翻译层”分开。语言只是外衣，日历才是骨架。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
