ajv-i18n

ajv-i18n is a companion package for Ajv, the widely used JSON Schema and JSON Type Definition validator. It provides localize functions that rewrite Ajv’s array of validation errors into human-readable messages translated for a specific language, covering dozens of locales contributed by the community.

Ajv itself emits terse English error messages; ajv-i18n takes those error objects after validation and replaces each message with a localized string appropriate to the failing keyword. This makes it straightforward to surface user-facing validation feedback in the visitor’s language across draft-04 through 2020-12 schemas and JTD.

What You Get

• Per-locale localize functions for dozens of languages
• Translations for every standard Ajv validation keyword
• Support for JSON Schema drafts 04, 06, 07, 2019-09, 2020-12, and JTD
• A tiny, dependency-free runtime that plugs into any Ajv setup
• Community-maintained locale files with a shared build pipeline

Common Use Cases

• Showing form validation errors in the user’s language
• Localizing API error responses generated from schema validation
• Supporting multilingual applications that validate data with Ajv
• Translating JTD or JSON Schema validation messages at runtime

Under The Hood

Architecture - The distributed localize directory is generated from templates: message logic lives in messages/index.js (JSON Schema) and messages/jtd.js (JTD), and scripts/compile-locales.js uses doT templates (localize/*.jst) to emit one localize function per language into the published build. Each generated localize function iterates over the Ajv errors array and, switching on error.keyword, assigns a translated error.message. The package’s main points at localize/index.js, the aggregated map of locales.

Tech Stack - Plain JavaScript with no runtime dependencies. The build relies on the doT (dot) templating engine to compile locale sources, with Ajv 8, ajv-formats, and ajv-keywords as dev dependencies for testing. Type definitions are generated from .jst templates too.

Code Quality - The spec directory holds a Mocha test suite with nyc coverage plus json-schema-test conformance tests run against generated locales, and Prettier and ESLint gate every change. Because messages are template-generated, the locale set stays consistent; 44 contributors have added languages through the same pipeline.

API Design - Usage is a single clear step: import the locale (for example require('ajv-i18n/localize/de')) and call it on validate.errors. Every locale shares the same signature, so switching languages is trivial, and the README documents which drafts each locale supports. The main caveat, common to i18n-by-mutation, is that you must call it after validation and before reading messages.