Intl API、本地化数据与可移植的浏览器格式化
使用浏览器 Intl 格式化日期和数字，同时尊重语言选择、时区、本地化数据差异和无障碍回退。
JavaScript Intl API 可帮助应用以人们熟悉的形式呈现日期、数字、货币和其他依赖语言的信息。它不会判断用户的意思、所属国家或事件发生的时区。可移植的格式化始于清晰的应用数据和明确的显示选择。之后，浏览器可以把值转换为本地化字符串，无需应用自行维护所有标点和顺序惯例。
应用应把底层值与屏幕上显示的文字分开保存。同一个数字在不同区域设置下可能有不同的分组方式，但数值不变。事件时间戳代表同一时刻，即使两位查看者看到不同的当地时间。格式化后的文字是给人阅读的，不是稳定的存储格式、可靠的解析输入或用户身份依据。明确这一区别，可以避免产品支持其他语言或地区后才暴露的错误。
运行环境更新时，浏览器的区域数据可能变化，不同环境支持的显示细节也可能不同。正确的兼容目标不是让所有地方的标点完全一致，而是让人理解这个值、在需要时选择适当的语言或地区，并完成任务。如需了解浏览器语言和时区设置如何保持一致，请参阅时区、区域与语言指南。本文聚焦于应用输出，而非浏览器身份。
让用户选择显示语言
浏览器可以提供语言偏好，但应用不应把它当成不可更改的决定。人们会共用设备、旅行、使用多种语言工作，也可能针对不同任务偏好不同语言。账户语言也可能比浏览器当前偏好更适用。应用可依据现有信息选择初始显示语言；当语言会影响任务时，应提供明显的更改方式。
如果产品需要区分界面语言和格式区域设置，就应将两者分开。有人可能用英语阅读说明，却希望日期和价格使用地区格式。也有人选择内容语言，却不希望账户的计费货币随之改变。应用应清楚命名提供的选择。“语言”控件不应悄悄更改金额的货币或事件的底层时区。
用户明确选择的语言应优先于推断出的默认值。用户选择受支持的语言后，应依照产品说明，让界面在页面和后续访问中保持一致。并应允许用户再次更改。若应用在账户或浏览器存储中记住该选择，应说明其适用范围。用户在一个工作区选的偏好不应意外控制无关账户。
回退行为也应可预测。请求的语言可能尚未翻译，或者缺少某种地区变体。应选择有文档说明的回退，保持所选语言清晰可见，并避免在同一任务中混用无关语言。回退可以保留服务可用性，但若界面只有部分内容已本地化，就不应假装已经完整翻译。
语言标签用于标识语言，也可以包含文字系统或地区子标签。ECMA-402 国际化 API 规定了格式化服务如何处理区域标识符。应用仍需决定支持哪些语言，以及偏好如何映射到可用内容。向 Intl 传入区域标识符不会翻译标签、说明、法律文本或用户生成内容。
尽可能让内容语言与格式行为一致，但不要让一个值承担所有用途。西班牙语消息可以同时包含按计费地区格式化的金额，以及按查看者所选时区显示的会议时间。应说明每个值由哪个选择控制。这样比把浏览器语言偏好当作个人完整档案更清楚。
区域设置选择也会影响无障碍，而不只是视觉效果。正确的语言元数据有助于辅助技术以恰当方式朗读文字。更改语言的控件名称应让用户在意外切换后仍能识别。界面语言变化时，页面应保留焦点和当前任务。若必须完整重启或丢弃表单输入，原本有用的偏好就可能变成障碍。
测试首次访问时的默认语言、用户主动更改、已保存偏好、不受支持的变体，以及返回之前语言的流程。一起检查界面文字和格式化值。日期可能正确，但周围标签仍是另一种语言；翻译标签也可能正确，但硬编码数字格式仍未改变。
如需进一步了解浏览器、账户、网站和网络选择如何相互影响，请阅读浏览器多表面隐私指南。语言偏好是显示输入；将它与无关信号结合来分类用户，则属于不同的数据用途，不是日常格式化的一部分。
使用 Intl 呈现，而不是作为事实来源
Intl 为 JavaScript 应用提供格式化器及其他依赖语言的服务。ECMA-402 规定了这些服务的行为和区域操作模型；MDN 记录常见格式化接口及其应用方式。浏览器提供实现和区域数据，应用提供值、相关选项，以及结果显示的上下文。
应使用能表达含义的类型和字段保存规范数据。货币金额需要数值和独立的货币代码。预定事件需要一个时间点，或定义清楚的当地时间规则及适用时区。度量值需要数值和单位。标点、符号、顺序和语言都可能变化，因此格式化字符串无法可靠地把所有这些字段带回存储。
格式化通常是显示前的最后一步。数据服务可以返回结构化值，页面再应用查看者选择的显示偏好。这样更换界面语言时无需改写存储记录，也能明确导出规则：机器可读导出保留结构化值，人类可读报告则可包含本地化标签和格式。
不要解析本地化显示字符串来恢复原值。逗号在一种惯例中可分隔分组，在另一种惯例中却表示小数。货币符号可能对应多种货币。只有数字的日期在日月顺序不同的地区可能产生歧义。如果产品接受用户输入，应另行定义输入格式和校验行为，并在字段旁显示可接受格式。
根据领域选择选项。付款收据可能需要由财务流程确定货币和舍入政策。科学显示可能需要保留有效信息的单位和精度规则。相对时间标签有助于理解上下文，但需要比较记录时不应取代精确时间戳。Intl 可以表达选定的显示形式，却不会决定法律、会计、科学或排程规则。
机器协议与人类显示应分开。API、数据库、日志和签名需要稳定的数据合同。除非协议有明确规定，本地化格式只应出现在面向人的边界。从本地化页面复制的值应附带足够上下文，以便在其他位置理解，尤其是用户可能将它粘贴到消息、表格或支持请求中时。
格式化器输出也不适合作为持久用户标识。浏览器区域数据、选项或运行时版本变化时，输出的具体外观可能改变。如果应用需要记住用户偏好，应存储偏好本身，例如所选语言或时区，而不是上次格式化的结果。不要把显示差异变成设备档案。
这种分层有助于测试。测试可先验证底层值和选定的显示选项，再验证输出是否传达预期含义。无需要求每个有效运行环境都使用完全一致的空格、缩写或标点。只有产品明确规定固定标签或受监管显示要求时，才需要精确文本断言。
根据上下文格式化数字、货币和日期
数字需要比区域标签更多的上下文。计数、百分比、距离、温度、价格和标识符都可能由数字组成，但用户对它们的理解不同。应向格式化器提供界面正在显示的值的类型，并在旁边给出清楚标签。缺少单位或用途的数字即使显示精致，也仍可能含糊。
百分比需要区分存储值和显示惯例。若产品存储的是小数，应按照格式化器预期的输入模型呈现。若产品存储百分点，则需要不同的转换选择。数值含义由应用决定，区域设置无法修复存储数量与标签不匹配的问题。
金额应与货币代码一起保存。区域设置会影响符号顺序、间距和数字分组，但不会决定交易使用了哪种货币。更改查看者语言不应悄悄换算金额或改标为另一种货币。如提供换算，它应是独立操作，并说明汇率来源和生效时间。
舍入也是产品规则。格式化器可以显示指定的小数位数，但不应成为财务或科学舍入政策唯一的承载位置。需要存储、比较或汇总的值应有明确的计算流程。为便于阅读而舍入的显示值，不应被误认为交易或分析所用的精确值。
日期同时需要日期值和时区选择。系统中记录的时间点可以按查看者时区、活动举办地时区或固定报告时区显示，它们代表不同的产品含义。语言标签会改变日期部分的文字和顺序，却不会自行选择预约或法律期限适用的时区。
本地日历日期也需要谨慎处理。生日、酒店入住日期和每日报告周期可能表示日历日，而非全球统一时间点。把这类值转换到任意时区可能使日期移到前一天或后一天。格式化前应明确领域类型；若时间事件可能产生误解，应显示适用时区。
夏令时变化使随意假设尤其不可靠。转换日的当地墙上时间可能重复出现或根本不存在。负责排程的应用应根据有文档说明的规则解决此问题；时间戳格式化只是显示步骤。若用户需要比较不同地点的时间，日常显示应包含时区名称或偏移量。不要让用户根据语言或所在地猜测时区。
API 的边界是明确的：Intl.Locale 处理区域标识符，Intl.NumberFormat 呈现数字和货币，Intl.DateTimeFormat 呈现日期与时间值。这些 API 不会选择交易货币、定义日历日，或解决应用的排程规则。
时区正确性需要针对应用进行测试，尤其要覆盖旅行、重复事件和夏令时边界。应把领域逻辑与通用格式化层分开。JavaScript Math 跨浏览器一致性文章 讨论数字计算和可移植性，但不能代替对日期、货币或单位含义的判断。
评审时应使用符合实际任务的例子。收据应显示正确金额和货币；日历应在所选时区显示正确事件日期；度量值应显示单位；计数在数值很大时也应清楚可读。这些检查能发现通用格式化字符串快照无法发现的含义错误。
考虑区域数据和运行时差异
Intl 的行为既取决于 ECMA-402 合同，也取决于运行时提供的区域数据。规范定义算法和必需行为，但不会永久固定所有语言中的每个词语、缩写或排版细节。区域惯例会演变。即使应用代码未变，浏览器或操作系统更新也可能带来新数据。
应把区域支持视为具有可观察结果的产品要求。列出应用承诺支持的语言和地区变体、使用的格式化器功能，以及不支持时提供的回退。应在产品支持的浏览器上测试这些承诺。不要仅凭版本号，或另一个区域的一次成功格式化推断支持情况。
若首选区域设置或选项无法生成所需显示形式，应用应能妥善处理。回退应保留原值并让结果可理解。缺少地区惯例不应使付款金额变成无标签数字，也不应让排程期限成为没有时区的日期。在高影响工作流中，应说明回退，并让用户查看底层上下文。
应接受无害的排版差异。不同有效实现可能在空格、分组符号、标点和缩写方面有所不同。看起来相同的空格可能由不同字符表示。若用户可见含义仍正确，硬编码字符串相等断言可能令测试过于脆弱。尽可能比较结构化值和产品结果；精确文本检查应保留给产品真正控制的文字。
区域数据不是身份事实来源。某个运行时选择了特定缩写，并不能证明用户居住地或使用的语言。应用不应依据格式化器输出给用户分类。显示决定应依据明确偏好和任务数据，兼容性诊断也应限定在相关产品结果内。
应使用真实本地化字符串审查字体和布局。本地化日期和价格可能比设计中使用的英语示例更长。货币符号可能需要字体回退；日期标签可能换行；从右向左书写的语言可能改变周围布局需求。这些是格式化器无法单独解决的界面问题。应预留空间、允许换行，并核对受支持语言的阅读顺序。
还要考虑复制和导出的内容。在带标签的表格中清楚的数字，离开标题后粘贴出去可能含糊。导出和分享时应包含单位、货币、日期时区或其他必要上下文。机器可读导出应使用明确的架构，并由接收界面本地化，而不是只导出显示文字。
浏览器更新改变输出时，应先调查对用户的影响，再判断是否回归。金额含义变了吗，标签无法阅读了吗，还是只有空格变化？应用依赖的是不是平台从未承诺固定的字符串？以实际任务为依据的一组有限测试样例，比收集每种格式化器差异更容易做出区分。
记录产生显示问题的应用版本、浏览器版本、所选区域设置和输入值。这些事实有助于复现问题，而无需收集无关浏览器属性。仅在问题处理需要期间保留支持诊断，并避免把格式投诉扩大为通用环境清单。
让格式化易懂且无障碍
本地化字符串必须结合上下文才能理解。仅包含数字的短日期可能很紧凑，却容易产生歧义。包含分组和小数标记的数字仍需要标签。用户作出决定时，货币、单位和时区上下文应当可见，而不应藏在辅助技术可能无法访问的提示框中。
格式化值周围的文字应使用语义化页面元素。表格标题可以标明金额或日期，表单标签可以说明可接受的输入格式，状态消息可以解释偏好更改。这种结构有助于屏幕阅读器和其他工具将数值与含义关联起来。若页面标记缺少关系，格式化本身无法补足。
文档语言应反映文本的实际语言。页面包含其他语言的段落时，应正确标记，让辅助技术采用恰当发音。即使当前选项令用户陌生，语言选择器仍应容易找到。不要只用国旗表示语言：一种语言可在多个国家使用，一个国家也可以有许多语言。
自动默认值不适合时，应让用户自行控制。在共用设备、旅行和多语言工作流中，明显的语言或地区格式选项尤其重要。应让它与位置权限及无关账户数据分开。用户不应仅为了用熟悉的格式阅读日期或金额，就被迫透露精确位置。
显示方式变化时，不应更改底层记录。用户编辑表单时更改语言，应保留已输入值，并说明其显示形式发生变化。如果预定事件改用另一个时区显示，应保留原事件身份，并标明新显示使用的时区。这些转换应可逆，不能悄悄提交新交易或预约。
应使用辅助技术和受众常用字号进行测试。检查较长的本地化值换行时不会遮挡相邻控件、阅读顺序仍然合理，以及复制的值在页面之外仍包含必要上下文。若视觉上缩写能让界面更清晰，应在有帮助时提供无障碍完整文本。避免重复播报导致页面过于嘈杂。
错误消息也需要本地化和上下文。应用拒绝数字或日期时，应说明接受的输入格式，并给出适合所选语言的例子。不要只把用户输入转换成另一种格式回显后就说它无效。要区分解析错误与符合格式但超出领域范围的值。
最好的验收测试是实际任务：付款确认前，用户能否理解价格和货币？参与者能否确定事件何时开始以及适用哪个时区？切换语言时能否保留工作？这些结果比重现某一运行时输出的每个字符更重要。
将格式化作为产品合同审查
应明确哪些值由浏览器格式化、哪些由服务以本地化形式返回，以及哪些必须保持机器可读。多个环节重复格式化可能混用语言或重复转换。清晰的边界让应用可以改变显示，同时不更改底层数据，并保持服务合同稳定。
为每种受支持的工作流保留少量代表性测试样例。至少包括普通日期、排程场景中的时区转换临界时间、大数或小数，以及产品处理货币时带显式代码的金额。每个样例都应验证明确的用户结果。真实故障揭示新风险时再添加样例；不要构建没有产品决策依据的任意区域字符串目录。
对于合成货币样例，将数值 1234.5 使用 en-GB 显示，明确指定 EUR 货币代码并保留两位小数。用户应能读出等值于 1234.50 欧元的金额并看到 EUR 标识。区域数据变化导致空格差异可以接受；金额改变或缺失货币标签则表示测试失败。如果应用仅支持英语和法语，却收到西班牙语偏好，声明的英语回退应显示相同金额和货币，并标明当前使用的语言。
对于排程样例，固定同一时刻 2026-01-01T01:30:00Z：UTC 显示为 2026 年 1 月 1 日 01:30，America/New_York 显示为 2025 年 12 月 31 日 20:30。两个视图都必须标明各自的时区语境，并对应同一个已存时刻；标点可以不同，但时刻发生变化或日期变化没有解释都应判定失败。
回退路径也应像首选路径一样认真审查。请求的区域设置不受支持、翻译缺失或格式化器失败时，值和任务仍应易于理解。界面应说明当前使用的语言或格式，不要悄悄混用变体。并应保留用户返回受支持选项的能力。
添加本地化工具或第三方组件时，应检查隐私数据流。浏览器内运行格式化器，并不要求应用向其他服务发送详细浏览器清单。如果服务为了正当任务接收语言或地区偏好，应说明需求原因及保留期限。不要把显示偏好当作隐藏的定向信号重复使用。
国际化是应用持续承担的责任。Intl 能免去手工编写许多语言专属格式规则，但它不会翻译产品内容、定义存储值的含义、选择用户身份，也不保证每种运行时输出相同字符串。应把值、显示偏好和格式化输出视为不同层。这样，用户可以读到熟悉的内容，同时继续控制底层任务。
