Translating error messages with i18n

[iamacook]

I'm using i18next to translate our site and the user can switch between languages. However, RHF's error messages don't translate when toggling between languages.

I have tried calling trigger() and control.reRender() on language change but nothing helps, bar reloading the page. If you have any advice on how to force reload the validation schema, it would be greatly appreciated.

[bluebill1049]

provide a simple codesandbox please.

[bluebill1049]

thank you for sharing solution.

[mleimer]

The suggested workaround isn't a viable option in my opinion. It solves the problem of showing the error message in a different language upon a language change, but only as long as no additional arguments need to be passed into the translation-function later on. If additional parameters need to be passed, for example to describe a dynamic length limit, then the only option I can see so far is to stringify the object to comply with Message being of type string. Having said that, there are also no sub-classing possibilities. Moreover, having dynamic keys prevents the static discovery of translation keys for an export into a TMS or alike.

[shaungrady]

I've opened a new issue proposing a flexible solution that has worked for my team.

[npearson72]

@shaungrady and @bluebill1049 what ever happened to @shaungrady's PR? Is there another solution available?

[shaungrady]

Sorry, I haven't had time to devote to this.

[terryatgithub]

Is there some official solution or progress about this issue? we also met this problem.
any feedback would be appreciated.

[debel27]

Here's my proposal to solve the issue.

@bluebill1049 could you tell me what you think? If you see no red flag, I can attempt a PR.

Main idea

This proposal aims at giving developers more flexibility when defining errors objects in react-hook-form.

The main idea is to add a data property to FieldError, ErrorOption and GlobalError. Example:

export type FieldError = {
  // ... existing properties
  message?: Message;
  // -- new property --
  data?: unknown;
};

RHF will treat the new property as opaque and just forward it along.

In application space, developers can pick whichever information they need from FieldError to display the error properly. They can keep using message as usual, or they can use data for more advanced use cases.

Producing data

Like message, the data property will be filled in by validators.

For declarative validators, we can add a data property to ValidationValueMessage:

export type ValidationValueMessage<TValidationValue extends ValidationValue = ValidationValue,> = {
  value: TValidationValue;
  message: Message;
  // -- new property --
  data?: unknown;
};

For function validators, we will extend ValidateResult to support arbitrary data:

export type ValidateResult = 
  | Message
  | Message[]
  | boolean
  | { data: unknown } // <- new union member
  | undefined;

In a nutshell, the goal is to provide first-class support for data in every place Message is used.

In resolver functions, the problem of providing data will be solved in userland.

Caveat: HTML validation

The proposal works fine when error objects are used as reactive data (as defined by React), because RHF can delegate error formatting to application space.

However, if RHF is configured to use native HTML validation, errors will be used as event data instead. RHF will imperatively call HTMLInputElement.setCustomValidity whenever an error occurs, and must therefore produce a localized message on-demand.

This raises the following questions:

1. given a FieldError message, how can the library decide whether to use message or data?
2. if data is picked, how to transform it into a string for setCustomValidity?

1. can be solved by picking message first (as in message ?? data).

2. requires RHF to operate in "inversion of control" mode. Developers can provide a formatErrorData function to the library ((key: string, data: unknown) => string), which will be called to derive message from data in case the former is absent. If the function is not provided, data will be ignored in HTML validation.