国际化本地化

• 三家方案的定位与依赖关系（FormatJS 是底层、react-intl 是其 React 封装）
• 消息语法（ICU vs 自研占位符）与资源管理
• 体积、构建时编译与生态成熟度

定位：FormatJS 是底层工具集（@formatjs/intl、intl-messageformat 等），react-intl 是其在 React 上的封装（Provider/injectIntl/useIntl），i18next 是独立自研体系（含 react-i18next 绑定）。消息语法：FormatJS 系用标准 ICU MessageFormat（复数/select/插值规范强大），i18next 用自研占位符（{{name}}、_count 后缀复数）更简单但偏离标准。工程能力：i18next 生态大（检测、后端插件、框架绑定多，支持 JS/React/Vue 等），react-intl 与 React 深度集成、配合 babel 插件可构建时提取与编译、体积更可控；FormatJS 系强调标准与工具链（compile、extract、pseudo-localize）。选型：团队 React 且重视 ICU 标准与体积 → react-intl/FormatJS；需要跨框架、丰富插件与简单语法 → i18next。

考察 i18n 方案的体系化对比：定位关系、语法标准、构建工具与生态，答案需按团队场景给出选型建议。

• 插值、复数、选择（select）的标准表达
• 与翻译工具链（extract/compile）的配合
• 嵌套语法复杂度与降级

ICU MessageFormat 是跨语言的消息格式标准：支持参数插值（{name}）、复数选择（{count, plural, one {...} other {...}}）、性别/分类选择（{gender, select, male {...} other {...}}）与格式选项（number、date 注入 Intl 格式化），让"同一句文案按语言规则自动变形"，避免硬编码拼接。工程价值：格式与引擎（intl-messageformat、Lingui、ICU4X）解耦、翻译平台（Crowdin 等）原生支持、可构建时编译为紧凑函数提升运行时性能。注意点：语法复杂时难以人工维护——建议配合 extract 工具与 lint（如 no-icu-invalid）、控制嵌套深度、字符串提取失败时降级为纯文本占位符，并保证运行时消息与资源文件一致。

考察 ICU 消息格式的工程运用：标准表达复杂语言规则、工具链配合与复杂度治理，答案需覆盖价值与落地注意点。

• dir=rtl 与逻辑属性驱动的布局翻转
• 文本对齐、图标与数字的镜像处理
• 混合 BiDi 文本与对齐容器

RTL 实战要点：根元素声明 lang 与 dir（如 ），布局用逻辑属性（margin-inline-start、inset-inline、text-align: start）让浏览器自动镜像，杜绝物理 left/right 写死；图标与箭头方向用 CSS 变换（scaleX(-1)）或独立 RTL 图标集镜像语义性图标（前进/后退、展开箭头），但时钟、图表等真实方向内容不可镜像；文本对齐用 start/end 而非 left/right；数字与嵌入的 LTR 片段由 Unicode Bidi Algorithm 自动处理，必要时用 dir 属性或 unicode-bidi 隔离；间距与 padding 用逻辑值。测试：真实 RTL 内容（非简单翻转）走查、长文本溢出、混合文本（电话号码、URL）逐处验证。

考察 RTL 的系统性适配：逻辑属性镜像布局、语义性图标镜像、BiDi 自动处理与实测要点。

• Lingui 的编译时消息提取与 ICU 支持
• react-i18next 的运行时架构与插件生态
• 开发体验（宏、类型安全）与体积

Lingui（@lingui/react + @lingui/macro）以编译时为核心：用 Babel 宏（t...、Trans）在构建期提取消息并编译为紧凑函数（messages 对象直接进 bundle），ICU 语法原生支持，配合 extract 命令与 catalogs 管理，产物小、运行时开销低，并可选类型安全（目录类型）。react-i18next 以运行时为核心：资源 JSON 加载 + i18next 核心解析（t 函数、命名空间、lng 检测），插件生态庞大（检测、后端、缓存），但消息默认运行时解析、体积与性能弱于编译时方案，与 ICU 需额外插件（i18next-icu）。选型：重性能与标准、工具链完整（CI 提取、缺失检测）选 Lingui；重生态灵活、非 React 场景或已有 i18next 基础设施选 react-i18next。

考察现代 i18n 方案的设计差异：编译时 vs 运行时、ICU vs 自研、工具链与生态，答案需按团队约束给出选型。

• Accept-Language 头与内容协商的取舍
• URL-based（路径前缀/子域）的 SEO 与缓存优势
• 语言切换、持久化与降级链

Accept-Language 由浏览器发送用户偏好，服务端按 q 值协商：实现简单、首次访问自动匹配，但不可分享链接、不便 SEO（内容语言与 URL 解耦）、代理缓存粒度差；URL-based 把 locale 放进 URL（example.com/ar/ 或 ar.example.com）：可索引可分享、服务端缓存清晰、语言切换可预测，但需重定向与站点结构设计，且首访仍需结合 Accept-Language 重定向。工程实践：首访用 Accept-Language + IP 兜底重定向到对应路径，之后以 URL 为准；语言切换写 cookie/localStorage 并做 302 到新路径；降级链：请求 locale → 路径缺失按 accept 语言 → 默认语言，并确保 与实际内容一致；CDN 缓存按路径而非头信息。

考察 Locale 协商策略：两种方案的取舍（SEO/缓存/分享 vs 自动检测）、切换与降级链、lang 一致性。

• 资源文件的组织（命名空间、key 策略、版本化）
• 插值的类型与安全（转义、HTML 片段）
• 复数规则的资源表达（CLDR 类别）

资源文件组织：按命名空间（common、forms、errors）与语言拆分（locales/{lang}/{ns}.json），key 用语义化路径（header.login）而非文案本身（便于翻译变更不改 key），资源纳入版本管理与 CI 校验（缺失 key、多余 key 检测）。插值：运行时占位符（{{name}} 或 ICU {name}）替换，注意 HTML 场景要区分"纯文本插值（自动转义）"与"富文本片段（组件插值，如 ）"，禁止把用户输入直接插成 HTML；复数：资源中按 CLDR 类别提供（en 有 one/other，ru 有 one/few/many/other），翻译平台按类别显示输入框，运行时由 ICU/引擎按数量选择，避免把数量硬拼进字符串。

考察文案资源治理：命名空间与 key 策略、插值安全、复数类别的资源表达，答案需覆盖组织、安全与规则落地。

• 构建时编译消息为函数的收益（无运行时解析）
• ICU 复数/时区规则数据的按需加载与裁剪
• 体积-性能-维护性的平衡

构建时编译（Lingui macro、@formatjs/cli compile）把 ICU 消息编译为闭包函数：运行时不再解析消息语法，只有插值调用，性能最优、产物可摇树；运行时 ICU 数据（复数类别表、时区/日历数据）体量大，必须按需加载——只加载目标语言（复数规则按语言子集）、Intl API 用浏览器原生（native Intl 不打包数据），必要时用 ICU4X 裁剪数据或服务端格式化。取舍模型：编译时消息 + 原生 Intl 是默认组合（体积小、性能好）；需要旧浏览器时用 polyfill（@formatjs/intl-* 按需装）、非标准场景用精简 ICU 数据；维护性上编译产物进版本管理、CI 校验消息合法性。避免把整套 ICU 数据打进 bundle。

考察 i18n 的性能工程：消息编译消除运行时解析、ICU 数据按需裁剪、原生 Intl 优先，答案需给出组合取舍。

• 各 API 的能力与输出语义（列表、相对时间、名称显示）
• 与手写拼接/正则替换的对比
• 浏览器覆盖与 polyfill 策略

现代 Intl API 把高频本地化格式交给引擎：Intl.ListFormat 生成语言正确的列表（"A、B 和 C"、or 连接、长/短/窄样式）；Intl.RelativeTimeFormat 输出相对时间（"3 分钟前"）并支持未来/过去方向与数值格式化；Intl.DisplayNames 输出语言、地区、货币、脚本的本地名称（"法语"、"欧元"）。工程价值：替换手写拼接与正则替换（后者在 20+ 语言上必然出错）、保证与 CLDR 数据一致、零额外依赖。注意：数值粒度（单位组合如"1 小时 20 分"需自行组合多次调用）、结果可被框架直接渲染（返回字符串或 parts）；支持度良好但旧环境需 @formatjs/intl-listformat 等按需 polyfill。

考察现代 Intl API 的替代价值：三类 API 的语义与场景、对拼接实现的优势、兼容与 polyfill。

• 伪本地化的原理（加长文本、替换字符、加宽标记）
• 捕获的缺陷类型（溢出、截断、硬编码、编码错误）
• 实施方式（伪语言包、CI 流水线）

伪本地化是"不依赖真实翻译的本地化模拟"：把源字符串按规则转换——加长（前缀/后缀填充字符使长度 +30%+）、替换 ASCII 为视觉近似字符（如 a→ä）、加 [标记] 前缀识别漏译，用于提前暴露布局问题。它捕获的缺陷：文本溢出与截断（按钮、容器、表格列）、硬编码字符串（未走 i18n 的文案原样出现）、字符编码问题（非 ASCII 显示为乱码）、换行与竖排异常、RTL 混淆字符的显示。实施：构建流水线自动生成伪语言包（pseudo locale），测试环境注入，配合视觉回归（截图对比溢出）与 E2E；关键流程（登录、注册、支付）全量跑一遍伪本地化环境，把"本地化回归"提前到翻译就绪前。

考察伪本地化的测试价值：加长与替换揭示溢出/硬编码/编码问题，答案需说明生成机制与测试流水线集成。

• CLDR 复数类别与语言映射（en 2 类、ru 4 类、zh 1 类）
• plural 与 select 的嵌套表达
• 缺失类别时的回退（other 兜底）

CLDR 按语言定义复数类别：英语 one/other（1 与其余）、俄语 one/few/many/other（1、2-4、5+、0/小数等）、中文只有 other（一切统一），ICU 消息用 {count, plural, one {...} other {...}} 声明类别分支，运行时引擎按语言的 plural rules 选择。落地要点：消息中必须包含 other 兜底分支（任何语言都命中）；嵌套场景（数量+性别）用 {count, plural, ... {gender, select, ...}} 组合；翻译平台按语言展示类别输入框（英语只见 one/other，俄语见四类）；避免把复数逻辑写进代码 if 拼接——统一交给 plural 规则；数量为 0、小数、负数等边界由 CLDR 规则判定，不要手工假设"1 就是 one"。

考察 ICU 复数落地：CLDR 类别与语言的映射、plural/select 嵌套、other 兜底与平台协作。

• 逻辑属性与物理属性的对应（inline/block 轴）
• dir 切换时逻辑属性的自动镜像
• 逻辑值的边界（边框、圆角、定位）

CSS 逻辑属性以 inline（行内轴，随 dir 翻转）与 block（块向轴）表达布局：margin-inline-start 在 LTR 等价 margin-left、RTL 下自动等价 margin-right，inset-inline-start 对应 left/right 定位，border-inline-start、padding-inline、border-start-start-radius（圆角）同理；text-align: start/end 与 float: inline-start 随 dir 生效。协作方式：根元素设 dir（或 HTML dir 属性），逻辑属性自动跟随，无需媒体查询翻转；物理属性（left/right/margin-left）在 RTL 下保持不动，会破坏镜像。边界：writing-mode 改变时 block 轴也换（竖排文本需整体考虑）；transform 平移、百分比定位等不受逻辑属性覆盖的场景需单独处理；JS 侧用 getComputedStyle 逻辑值或 ResizeObserver 兼容。

考察逻辑属性的 RTL 适配机制：inline/block 轴与 dir 联动、物理属性的失效风险、特殊场景边界。

• Intl.DateTimeFormat/NumberFormat 与货币、区域格式差异
• 复数规则与语言的绑定
• 常见错误：手动格式、硬编码符号、时区误用

工程价值：同一数据（日期 2026-08-04、金额 1234.5）在不同语言/地区有不同呈现——日期顺序与历法（en-US 月/日/年 vs zh 年/月/日）、数字分隔与小数（1,234.5 vs 1 234,5）、货币符号与位置（$1,234.50 vs 1 234,50 €）、复数形式（1 item/2 items）。正确实现：用 Intl.DateTimeFormat（含 timeZone 参数，避免拿服务器时区当本地）、Intl.NumberFormat（style: currency、最小/最大小数位）、复数交给 ICU plural 或 Intl.PluralRules；数据层统一存储（时间用 UTC ISO、金额用最小单位整数），展示层才格式化；切勿手写"${amount}" 或 toLocaleString 无参数裸用。价值：自动化覆盖 20+ 语言规则、避免返工、与 CLDR 保持一致。

考察核心本地化格式的工程化：Intl 系列的正确使用、数据与展示分层、常见错误规避。

• TMS 的核心能力（资源同步、上下文、审校、术语库）
• 与代码仓库的集成（自动同步、PR 流程）
• 质量保障（翻译记忆、术语、评论闭环）

TMS 的工程价值：把"提取→翻译→回填"变成自动化闭环——CI 提取源字符串自动上传（API/CLI），翻译完成自动下载并开 PR 回填资源文件；翻译侧获得上下文（截图、key 说明、源语言字段）、术语库（词汇统一）、翻译记忆（相似句复用）与评论讨论；审校流程（机翻候选→人工审校→QA 检查）在平台内闭环，QA 检查可校验占位符完整性、复数类别、ICU 语法。集成模式：Git 同步或 CLI 在 pipeline 中触发、未翻译完成度低于阈值时 CI 失败、翻译变更记录可回溯；多语言、多项目共用一个术语库保持一致性。价值本质：减少人工同步成本、提升翻译一致性与可追溯性。

考察翻译工作流的工程化：TMS 的自动化同步、上下文与术语库、质量闭环，答案需说明与 CI 的集成方式。

• MT 的接入方式（API、批处理）与成本
• 机翻质量边界与人工审校配合
• 术语、占位符与格式的保真策略

工程实战要点：接入——用供应商 API（DeepL、Google Translate）批量翻译源字符串，接在 TMS 或 CLI 流程中作为"初稿生成"，敏感内容与成本控制（API 配额、批量与缓存）；质量边界——机翻适合短句与界面文案，复杂句式、双关、品牌语、法律文本需人工审校，设置"机翻草稿→人工确认"流程而非直接上线；保真策略——翻译前保护占位符与标签（{{name}}、ICU 语法、Markdown），翻译后校验占位符一一对应（自动化 diff），术语表（glossary）同步给 MT 保证术语一致；评估——抽样人工评分（流畅度/准确度）建立质量基线，迭代 prompt 或换引擎。工程上机翻是"效率工具"，质量责任仍在人。

考察 MT 的工程集成：接入与成本、质量边界、占位符保真与术语控制，答案需强调人机分工。

• DateTimeFormat/NumberFormat 的选项体系
• 时区、历法与区域数据的正确传递
• 与框架/服务端格式化的协作

使用要点：Intl.DateTimeFormat(locales, options) 用 dateStyle/timeStyle 或显式字段（year/month/day/hour）组合，必须传 timeZone（"UTC"或用户时区），显示用户本地时间用 timeZone: 用户时区并配合 ZonedDateTime 语义；Intl.NumberFormat 的 style（decimal/currency/percent/unit）、currencyDisplay、最小/最大小数位、分组（useGrouping）按需求配置；货币金额存最小单位整数、展示时除以精度。协作：前端格式化用于展示，服务端用同一 ICU 规则（ICU4X）保证一致性；缓存构造器实例（构造昂贵）；需要"分部分样式"（数字与货币符号分别着色）用 formatToParts；旧环境用 @formatjs/intl-datetimeformat 等 polyfill。

考察 Intl 格式化实践：选项与时区传递、货币数据规范、实例缓存与一致性协作。

• 页面级 dir 切换与逻辑属性联动
• 文案适配（标点、图标、数字）的镜像规则
• 切换瞬间的布局抖动与持久化

方向切换处理：页面级 dir 属性（html 或容器）整体切换，布局靠逻辑属性自动镜像；文案适配——标点与括号在 RTL 中镜像（"text (x)" 变 "(x) text"）、语义性箭头图标翻转、时间/电话号码等 LTR 片段用 dir="ltr" 隔离（或 unicode-bidi）、数字方向按语言规则（阿拉伯文可能用西方数字或东方数字，由 lang 决定）；切换实现：语言选择器更新 dir 与 lang 并持久化（cookie/URL），必要时刷新后按持久化值渲染避免闪烁；抖动处理——切换时用占位宽度/骨架屏，或对容器做过渡，防布局跳动；切换后自动重跑 RTL 走查（溢出、对齐、焦点顺序）。

考察 RTL 方向切换的工程细节：dir 切换与逻辑属性、文案镜像规则、LTR 片段隔离与切换体验。

• Unicode Bidi Algorithm（UBA）的文本布局规则
• 数字与嵌入 LTR 片段的方向（EN/AN 类别）
• dir=auto 的检测与显式 dir 的边界

Unicode Bidi Algorithm 决定混合方向文本的排列：段落基础方向（由 dir 或 first strong 字符决定）、嵌入方向（RLE/LRE 控制符或 HTML dir 属性隔离）；数字分西方数字（EN，LTR）与阿拉伯-印度数字（AN，上下文相关），希伯来语用西方数字时数字方向按 UBA 的 European Number 规则处理（整体保持 LTR 排列），阿拉伯语可用东方数字（AN 类别随基础方向）。混合场景处理：短嵌入片段（品牌名、邮箱）用 或 dir 属性隔离，避免弱字符（标点、@）因"孤数字/弱类型"错排；dir=auto 让浏览器按首强字符自动定方向，适合用户生成内容（混合语言评论），但需注意：URL/邮箱开头的 LTR 会让整个段落变 LTR——关键内容用 bdi 包裹；工程上按内容来源决定 dir 策略（已知语言用显式 dir，未知用 auto + bdi）。

考察 BiDi 的文本工程：UBA 基础方向与数字类别、弱字符错排、dir=auto 与 bdi 的组合策略。