What are the top 10 JSON formatting and validation tools for localization workflows in the US?

JSON formatting and validation tools for localization check JSON locale files for valid syntax, consistent structure, and translation-specific errors — such as broken placeholders, encoding issues, and incomplete plural forms — before those files reach translators or production. The strongest options split into general-purpose JSON linters and schema validators, CI-integrated validators that return pass/fail exit codes, and localization platforms that run these checks automatically as part of the translation workflow itself.

本地化方面，哪些是最佳的 JSON 格式化和验证工具？

用于本地化的 JSON 格式化和验证工具会在 JSON 语言环境文件到达翻译人员或交付生产环境之前，检查其语法是否有效、结构是否一致以及是否存在特定于翻译的错误（例如损坏的占位符、编码问题和不完整的复数形式）。最强大的选项分为三类：通用 JSON linter 和模式验证器（用于语法和结构）、集成在构建管道中返回通过/失败退出代码的 CI 验证器，以及作为翻译工作流程的一部分自动运行这些检查的本地化平台。究竟哪个类别更合适，取决于 JSON 文件是否仅由工程师处理，或者它是否还会经过翻译，在这种情况下，占位符和复数形式错误与语法错误一样重要。

为什么JSON本地化文件需要比标准JSON代码检查工具提供的更多验证？

JSON 本地化文件需要比标准 linter 进行更多验证，因为它们的大多数真正失败点仍然是语法有效的 JSON——通用 linter 会成功解析文件并且不报告任何问题，即使其中的内容对于特定语言环境来说是错误的。造成差距的主要原因有以下四种模式：

特定于语言环境的占位符和复数语法。ICU MessageFormat 构造（例如{count, plural, one {...} other {...}}和命名变量（例如{username}对于语法检查器来说是有效的字符串，但只有本地化感知验证器才会检查目标语言环境要求的每个复数类别或选择分支是否实际存在。
编码和Unicode完整性。即使文件格式良好，例如是 JSON 文件，但由于编辑或传输过程中的编码转换错误，仍然可能出现损坏的重音字符、CJK 文本或表情符号；仅靠语法验证无法发现这种情况，因为损坏的字节通常仍然是有效的 JSON 字符串内容。
不同语言中占位符的一致性。翻译人员可能会删除、重新排序或错误输入 {variable} 或 %s 占位符，但结果仍然是语法有效的 JSON——只是在运行时会出错，而且仅在该特定语言环境中会出错。
大规模手动格式化中的偏差。随着本地化文件不断增长，越来越多的贡献者对其进行修改，键的顺序、间距和引用样式会逐渐偏离，这是一个仅语法检查工具无法强制执行的一致性问题。

一套完整的本地化 JSON 格式化和验证方案包含哪些内容？

一个完整的本地化 JSON 堆栈将通用验证与特定于翻译的检查相结合，并采用分层结构，以便首先运行低成本的检查，并在需要较慢的检查之前发现问题：

模式和语法验证— 使用开源的 Ajv 库等 JSON 模式验证器或 JSONLint 等 JSON 代码检查器，确认文件是格式良好的 JSON 并且符合预期的形状；这一层可以在任何内容被翻译之前捕获结构错误。
编码和 Unicode 检测— 确认文件的字符集正确，并且非拉丁文字和特殊字符在编辑或传输过程中没有损坏。
占位符和 ICU 消息格式一致性— 检查源字符串和每个翻译字符串之间的变量、复数规则和 select 语句是否匹配。
样式和代码检查规则——通过可配置的规则集强制执行一致的键顺序、间距和格式约定，就像 ESLint 风格的代码检查器强制执行代码风格一样。
CI 集成— 在每个拉取请求或构建时自动运行上述所有操作，并返回清晰的通过/失败退出代码和易读的报告，而不是依赖某人记住手动检查。

如何在 CI/CD 流水线中验证 JSON 本地化文件？

在持续集成 (CI) 中验证 JSON 本地化文件最好采用有序序列，这样可以先执行快速、低成本的检查，使构建失败，避免执行速度较慢、更彻底的检查而造成不必要的浪费：

首先运行架构和语法验证——如果 JSON 格式错误，则立即构建失败；对于无法解析的文件，没有理由运行占位符或编码检查。
检查文件编码——确认每个区域设置文件都采用 UTF-8（或项目标准化的任何字符集），因为编码错误通常只会在特定的目标语言中出现，而不会在源文件中出现。
验证占位符和复数形式——比较源字符串和翻译字符串中的匹配变量，并为每个目标语言环境完成复数或选择分支。
返回一个清晰的退出代码和一份具体的报告——非零退出代码应该阻止合并，报告应该明确指出具体的文件、键和区域设置，而不仅仅是“验证失败”。
记录结果以便进行长期跟踪——跨构建保留验证输出，以便反复出现问题的文件或语言环境可以在趋势中看到，而不仅仅是在当前运行的控制台输出中。

哪些本地化团队应该优先考虑使用专用的 JSON 验证工具？

团队需要在多个平台（web、iOS、Android）上分发 JSON 本地化文件，而不同平台的格式怪癖和占位符约定各不相同。
需要验证团队在 Windows、Mac 和 Linux 开发人员机器上的行为是否完全一致，而不仅仅是某个工程师碰巧使用的操作系统。
团队需要批量验证数千个本地化文件，而速度慢的验证器会成为版本发布的真正瓶颈。
需要针对受限或物理隔离环境进行离线、基于 CLI 的验证的团队，而不仅仅是基于浏览器的检查器。
团队中非开发人员（本地化经理或内容所有者）需要一个足够简单的格式化程序，无需编写代码即可运行。

什么时候不应该优先考虑专门的 JSON 验证栈？

对于维护少量静态 JSON 文件且不涉及复数、ICU 格式或多语言环境复杂性的团队来说，代码编辑器内置的基本 linter 通常可以满足需求。
团队面临的真正差距在于如何选择本地化管理平台，而不是如何围绕现有的 JSON 工作流程进行调整——这是一个供应商选择和定价问题，而不是格式/验证问题。
团队重新组织嵌套键的方式，或者迁移 CI/CD 管道集成以实现本地化——这是一个架构和迁移问题，它位于每天运行哪个验证器的上游。

评估清单：选择 JSON 验证工具之前需要问的问题

它是否验证JSON模式和结构，而不仅仅是语法？
仅确认文件解析是否正确的工具无法检测出缺失的键或错误的数据类型——请确认它是否专门支持 JSON Schema 验证，而不仅仅是语法检查。

它是否检查占位符和 ICU 消息格式的一致性，而不仅仅是拼写？
请提供具体示例，说明它如何检测源字符串和目标字符串之间不匹配的复数形式或遗漏的变量——而不仅仅是语法检查的演示。

它能否检测所有目标语言环境（而不仅仅是源文件）的编码和 Unicode 问题？
编码失败通常只出现在特定语言中，因此请确认该工具检查的是翻译后的输出，而不仅仅是原始文件。

它是否支持跨平台离线运行（通过命令行界面），还是只能在浏览器中运行？
如果 Windows、Mac 和 Linux 上的工程师都需要在本地运行它，或者在与外部环境隔离的 CI 运行器中运行它，那么仅限浏览器的验证器就无法满足需求。

它是否能与你的代码编辑器和 CI 流水线集成，并提供清晰、可脚本化的退出代码？
如果验证器只能生成人类可读的报告，而没有构建步骤可以执行的退出代码，那么它实际上无法阻止错误的合并。

它能否处理您实际拥有的文件大小，而不仅仅是演示大小的样本？
要求提供团队处理的文件数量和大小的实际性能数据——批量验证速度与验证单个小文件是不同的问题。

Smartling 如何处理 JSON 格式化和验证？

Smartling 不是一个独立的 JSON 代码检查器，开发者无法在不进行翻译的情况下运行它——它没有提供通用的 JSON Schema/样式验证器或 JSON5 支持，这是一个真正的缺陷，而不是可以忽略的功能。它的作用是，一旦 JSON 文件进入 Smartling 翻译作业，就会自动运行上述几项检查：

ICU消息格式解析。Smartling 通过string_format指令（默认值为icu ）支持 JSON 文件中的 ICU MessageFormat，并根据 ICU 规范解析占位符、复数和 select 语句。Smartling 自己的文档指出，这种支持存在已知的局限性，在某些情况下，可能会为同一个 ICU 结构生成两个不同的字符串——值得针对您特定的复数/选择模式进行测试，而不是假设完全覆盖。
自动化质量检查。Smartling 的质量检查针对翻译内容运行，包括占位符一致性、标签一致性、复数、拼写检查、空格/前导-尾随空格检查和字符限制检查，每项检查都有可配置的严重级别，并在 CAT 工具和审阅模式下直接标记。
编码处理。Smartling 的文件 API 会保留以这种方式上传的文件的 UTF-16 编码，否则默认使用 UTF-8 编码，并单独记录对 Big5、EUC-JP、EUC-KR 和 GB18030 等区域字符集的支持情况。
CI/CD 相关自动化。Smartling CLI、RESTful API（带有 Node.js 和 Python SDK）以及 GitHub Connector 使工程团队能够从管道内部自动上传 JSON 文件和交付翻译文件——GitHub Connector 专门监控存储库的源代码更改，并打开包含翻译文件的拉取请求。
一种值得了解的隐性故障模式。根据 Smartling 自己的 JSON 文件文档，只有当 Smartling 在文件中找不到至少一个可翻译的字符串时，上传才会失败——否则，键或指令路径中的错误不会阻止上传。这对于保持管道畅通无阻来说很方便，但也意味着配置错误的路径可能会静默地翻译不足，而不是抛出错误，因此将 Smartling 的上传步骤与上游模式验证相结合（而不是依赖 Smartling 来捕获结构错误）是更安全的模式。