Is it possible to anyhow customize Zod's messages?

[0xaa55h]

Hi! I use hey-api to generate from my openapi spec together with Zod plugin. Is there a way to customize the Zod messaging, as the whole app is in Czech and not a English?

For example, here replace the default message with something more sensible to the user.
Any guidance/help much appreciated, thanks!

[dosubot[bot]]

Hi @0xaa55h! I'm Dosu and I’m helping the openapi-ts team.

The Hey API Zod plugin doesn't currently support customizing validation error messages in the generated schemas [1]. However, you can handle this at the application level using Zod's built-in custom error map feature.

You can set a global error map that translates all Zod messages to Czech:

import { z } from 'zod';

z.setErrorMap((issue, ctx) => {
  // Customize messages based on issue.code
  switch (issue.code) {
    case z.ZodIssueCode.too_small:
      if (issue.type === 'string') {
        return { message: `Musí obsahovat alespoň ${issue.minimum} znak(ů)` };
      }
      break;
    case z.ZodIssueCode.invalid_type:
      return { message: `Očekáváno ${issue.expected}, obdrženo ${issue.received}` };
    // ... other cases
  }
  return { message: ctx.defaultError };
});

Set this once at app startup and it will apply globally to all Zod validations, including those from generated schemas. Libraries like zod-i18n-map also exist and provide pre-built translations (Czech may be available or easy to contribute).

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[mrlubos]

@0xaa55h can you not use the built-in i18n to achieve this? https://zod.dev/error-customization?id=internationalization#internationalization

[0xaa55h]

Great, that should, together with the bot's answer, work pretty smoothly. Just one more question: Is it possible to generate the schemas for request bodies, but don't actually apply them to the update functions? The reason I need this is that I use TanStack Form, which has the data in null values but the schema expects them as optional (that would make the form inputs uncontrolled, though). The fix to this would be to remap the values before validating; I can do this at the form level, but not at the update function level.

[mrlubos]

@0xaa55h I'd need to see a reproducible example. If I'm understanding it correctly the answer would be "no, not at the moment" but can't confirm until I see the code