国际化工程：翻译字符串只是第一步，后面还有五个坑

很多团队把国际化理解成“把文案抽出来翻译”，做完之后发现阿拉伯语页面布局错乱、德语按钮文字溢出、日期格式在部分地区显示错误。国际化是一套工程约束，字符串翻译只是其中最表层的一环。

坑一，文本膨胀。 德语和芬兰语的单词长度经常是英语的两到三倍，按钮、标签、表头在英文下刚好放得下，翻译后溢出。设计时就要给文本容器留弹性空间，避免固定宽度；关键 UI 要做伪本地化测试，用加长文本模拟翻译后的布局。

坑二，双向文本。 阿拉伯语和希伯来语是从右到左书写，整个布局需要镜像。CSS 的 direction: rtl 可以处理文本方向，但图标方向、进度条、轮播图、表单对齐都需要单独处理。用逻辑属性（margin-inline-start 而不是 margin-left）可以让布局自动适配方向，但历史代码里的物理属性要逐步替换。

坑三，复数规则。 英语只有单数和复数，但阿拉伯语有六种复数形式，俄语有三种，日语没有复数变化。简单的“单数加 s”逻辑在多语言下会出错。应该用 ICU MessageFormat 或框架提供的复数处理能力，按语言规则选择形式，而不是在代码里写 count === 1 ? ... : ...。

坑四，日期、数字和货币。 日期格式（年月日顺序）、数字分隔符（千分位用逗号还是点）、货币符号位置、时区处理，每个地区都不同。用 Intl API 做格式化，不要手写拼接。时区要显式处理，服务端存 UTC，展示时按用户时区转换，不要假设用户都在同一个时区。

坑五，字符串拼接。 "欢迎 " + name + " 回来" 这种拼接在语序不同的语言里会出问题。应该用带占位符的模板，让翻译者可以调整语序。占位符本身也要注意，某些语言里名词的格变化会影响占位符周围的词形，必要时把整个句子作为一个翻译单元。

国际化的工程检查清单可以收敛成：所有用户可见文本走翻译文件，不硬编码；布局用逻辑属性，支持 RTL；复数、日期、数字用标准 API 而不是手写逻辑；字符串用占位符模板而不是拼接；上线前做伪本地化和 RTL 截图测试。翻译质量重要，但工程约束不做好，翻译得再准也会在界面上出问题。