Validation messages does not get updated on reRender

All three ( label, placeholder and error message texts ) is wrapped with the same function ( an i18n function ). The label and placeholder change on update, while error message remains the same, no matter it produced via validate function or validationSchema. Of course, it changes onChange, onBlur and onSubmit but remains the same with state change (i.e: toggle language ).
https://github.com/dNitro/formik-example.git
| Software | Version(s) |
| ---------------- | ---------- |
| Formik | 1.5.7
| React | 16.8.6
| TypeScript | No
| Browser | all
| npm/Yarn | yarn
| Operating System | Mac
To me, this is expected behavior. Think about this, the string that you are passing to the error shouldn't be a translated string. Instead, it would have to be a standard string that will be translated on render, or a component that can choose to render however it wants. Unfortunately, I don't think the current API for errors will allow a component (could be wrong, never tried!).
Instead, what I would do is accept standard text as an i18n string later:
Working here: https://codesandbox.io/s/formiki18n-r0i97
Notable changes:
if (!values.email) {
errors.email = 'required';
}
// .. etc
<div className="input-feedback">
{i18n._(errors.email)}
</div>
Tanx @johnrom, especially for the working example; but this way we would lose the whole meaning of automatic key/id extraction to catalogs; As errors.email is variable, i18n libraries parsers/scanners couldn't be able to extract it.
If we don't want to write catalogs manually then we should go reverse and pass translated strings to error which has the aforementioned problem of updating.
It's crazy how much you think you know until this kind of stuff comes up! I'm not really an internationalization guru, but is there a way to mark the string as translatable before you actually translate it? For example, using errors.value = t(string) separate from the i18n._(errors.value)?
Wow, can't believe I didn't see that !!! Of course there is :)) then the issue could be closed. Cheers.