This library is used to translate Zod's default error messages.
yarn add zod-i18n-map i18nextThis library depends on i18next.
import i18next from 'i18next'
import { z } from 'zod'
import { zodI18nMap } from 'zod-i18n-map'
// Import your language translation files
import translation from 'zod-i18n-map/locales/es/zod.json'
// lng and resources key depend on your locale.
i18next.init({
lng: 'es',
resources: {
es: { zod: translation },
},
});
z.setErrorMap(zodI18nMap)
const schema = z.string().email()
// Translated into Spanish (es)
schema.parse('foo') // => correo inválidoDetailed customization is possible by using makeZodI18nMap and option values.
export type MakeZodI18nMap = (option?: ZodI18nMapOption) => ZodErrorMap;
export type ZodI18nMapOption = {
t?: i18n["t"];
ns?: string | readonly string[]; // See: `Namespace`
handlePath?: { // See: `Handling object schema keys`
context?: string;
ns?: string | readonly string[];
keyPrefix?: string;
};
};You can switch between translation files by specifying a namespace.
This is useful in cases where the application handles validation messages for different purposes, e.g., validation messages for forms are for end users, while input value checks for API schemas are for developers.
The default namespace is zod.
import i18next from 'i18next'
import { z } from 'zod'
import { makeZodI18nMap } from "zod-i18n-map";
i18next.init({
lng: 'en',
resources: {
en: {
zod: { // default namespace
invalid_type: "Error: expected {{expected}}, received {{received}}"
},
formValidation: { // custom namespace
invalid_type: "it is expected to provide {{expected}} but you provided {{received}}"
},
},
},
});
// use default namespace
z.setErrorMap(makeZodI18nMap())
z.string().parse(1) // => Error: expected string, received number
// select custom namespace
z.setErrorMap(makeZodI18nMap({ ns: 'formValidation' }))
z.string().parse(1) // => it is expected to provide string but you provided numberYou can translate also custom errors, for example errors from refine.
Create a key for the custom error in a namespace and add i18nKey to the refine second arg(see example)
import i18next from 'i18next'
import { z } from 'zod'
import { makeZodI18nMap } from "zod-i18n-map";
i18next.init({
lng: 'en',
resources: {
en: {
my_custom_error_namespace: { // give the namespace a name
my_error_key: "Something terrible"
}
},
},
});
// use global error map
z.setErrorMap(makeZodI18nMap({ns: 'my_custom_error_namespace'}))
z.string().refine(() => false, { params: { i18n: 'my_error_key' } }).safeParse('')// => Something terrible
// you can use local error map
z.string().refine(() => false, { params: { i18n: 'my_error_key' } })
.safeParse('', {errorMap: makeZodI18nMap({ns: 'my_custom_error_namespace'})})// => Something terribleWhen dealing with structured data, such as when using Zod as a validator for form input values, it is common to generate a schema with z.object.
You can handle the object's key in the message by preparing messages with the key in the with_path context.
import i18next from 'i18next'
import { z } from 'zod'
import { zodI18nMap } from "zod-i18n-map";
i18next.init({
lng: "en",
resources: {
en: {
zod: {
errors: {
invalid_type: "Expected {{expected}}, received {{received}}",
invalid_type_with_path:
"{{path}} is expected {{expected}}, received {{received}}",
},
userName: "User's name",
},
},
},
});
z.setErrorMap(zodI18nMap);
z.string().parse(1) // => Expected string, received number
const schema = z.object({
userName: z.string(),
});
schema.parse({ userName: 1 }) // => User's name is expected string, received numberIf _with_path is suffixed to the key of the message, that message will be adopted in the case of an object type schema.
If there is no message key with _with_path, fall back to the normal error message.
The suffix can be changed by specifying handlePath.context.
Object schema keys can be handled in the message with {{path}}.
By preparing the translated data for the same key as the key in the object schema, the translated value will be output in {{path}}, otherwise the key will be output as is.
You can specify handlePath.ns to separate the namespace of translation data for {{path}}. Furthermore, it is possible to access nested translation data by specifying handlePath.keyPrefix.
i18next.init({
lng: "en",
resources: {
en: {
zod: {
errors: {
invalid_type: "Expected {{expected}}, received {{received}}",
invalid_type_with_path:
"{{- path}} is expected {{expected}}, received {{received}}",
},
},
form: {
group: {
userName: "User's name",
}
}
},
},
});
z.setErrorMap(zodI18nMap({
handlePath: {
ns: "form",
keyPrefix: "group"
}
}));zod-i18n-map contains translation files for several locales.
- Arabic(ar)
- German(de)
- English(en)
- Spanish(es)
- French(fr)
- Icelandic(is)
- Italian(it)
- Japanese(ja)
- Dutch(nl)
- Portuguese(pt)
- Chinese Simplified Chinese(zh-CN)
It is also possible to create and edit translation files. You can use this English translation file as a basis for rewriting it in your language.
If you have created a translation file for a language not yet in the repository, please send us a pull request.
Many users will want to use it with next-i18next (i.e. on Next.js). This example summarizes how to use with it.
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
This project is licensed under the MIT License - see the LICENSE file for details
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!