Feature request : infer error message as a union of all possible string literals

[seedydocloop]

Summary

Context

I am using i18next with typescript (https://www.i18next.com/overview/typescript) to get intellisense for translations and rely on type safety.

Therefore, the translation keys expected by the library are string literals instead of simple strings :

t($ => $['my.key'])

To keep static zod schema definitions, I am giving only the keys to my zod errors, for instance :

// schema.ts
export const SOME_SCHEMA = z.object({
  description: z.string("field.invalid").min(1, "field.required"),
});

I then rely on rendering inside components to make sure my translations are recomputed whenever language changes :

// component.tsx
return (
  {errors.description?.message && (
    {t($ => $[errors.description.message]}
  })
)

This is my best option so far, to keep schemas and i18n decorrelated.

Please note I am using RHF as my form manager. The library receives those errors and seems to type them itself. It would then be also responsible for properly typing error messages.

Need

I'd need a way to infer the possible types of an error message based on its schema definition :

t($ => $[errors.description.message] 
// ideal type for message : 'field.invalid' | 'field.required'

Alternatives considered

Integrating with zod locales

Is there a way to load my custom error messages with their i18n into zod ?

Zod built-in locales seem not to match my need, as I want custom error messages.

Calling t within Zod schemas

Sadly, this option not only tightly couples my i18n solution with zod, it also brings 2 issues, mentioned here : #5259 (comment)

since RHF use some memoization on error messages, translation isn't recomputed after a "change locale event"

every schema is computed from a hook that use the useTranslate hook under the hood (not very suitable since the ideal solution would be to declare schema outside the React lifecycle)

Checking translation keys exist via a satisfies check

Adding the following to my schema :

// schema.ts
export const SOME_SCHEMA = z.object({
  description: z.string("field.invalid" satisfies keyof SomeDictType).min(1, "field.required" satisfies keyof SomeDictType),
});

Would ensure my translation keys exist. The only requirement is to have access to the generated dictionnary of translations.

Other ideas ?

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔ ｜ pullfrog.com}

[PunitSoniME]

Hi @seedydocloop

Could you please check this reply until we get this feature to be available ?
#5259 (comment)

[seedydocloop]

Hi @seedydocloop

Could you please check this reply until we get this feature to be available ? #5259 (comment)

Hi @PunitSoniME thanks for your workaround proposal.
If we skip implementation details, your workaround relies on transforming unknown strings into known strings.

In a very simplified way, it would look something like the following (for my use case):

if (message === "key") return t($ => $.key)

This brings type safety on translation keys, but not on error messages.

Thanks to your proposal, I added another workaround to my issue post : Checking translation keys exist via a satisfies check
I think I'll go with this one now, as it ensures the keys I pass to zod are part of my translation dictionaries, which is already good enough for me !

I ended up ignoring typing complaints from my translation library when I pass it string keys, as recommended by one of its maintainers here : i18next/i18next#2322 (comment)

t($ => $[error.message as never])

I can't secure the whole typing chain for now. The important for me is to secure keys I pass to my zod schemas.

[PunitSoniME]

if (message === "key") return t($ => $.key)

This will work when you don't have namespaces.

For my personal project, I have created a Template repository where I have added translations for that repo only.
I have another repository which I have created from that Template repository.

So just to keep things different, I have created translation files for Template repository as _common.json
and for my another repository I have created extended.json

When you generate types, you might have option to combine all namespaces into one, for my case I have keep it different

This is my translations folder structure

And this is my types file generated by npx i18next-cli types command

Our approach might be different as per the project requirements