-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
context
values resolved differently (and incorrectly) between <Trans />
and t(...)
#1730
Comments
@marcalexiei can you have a look at this? |
Right now If you need to access default value do not provide context parameter I'm not familiar with the types of react-i18next/TransWithoutContext.d.ts Line 17 in bb29742
and here react-i18next/TransWithoutContext.d.ts Line 24 in bb29742
Have them work properly it's not trivial as far as I can tell now 😔. |
But what if you want/need to provide a "unknown" context? For example imagine translating a long list of potential errors for which you get an error code from the backend. You have a somewhat good idea what the codes will be and you want to display them in the same location. But if you encounter a unknown error you want to fall back to the "generic" context. {
"error": "Unknown error, with error code {{context}}. Please contact support.",
"error_NotFound": "The resource you are looking for could not be found.",
"error_Disabled": "Can't edit the resource because it's disabled.",
// ...
} const Error = ({ errorCode: string }) => {
const { t } = useTranslation();
return <span>{t('error', { context: errorCode })}</span>
} I know that you can try to workaround this issue in different ways, but in theory this is already supported by i18next, just not reflected in the typings. Do you see any way of getting such cases handled correctly depending on if a key without a context exists or not? If that is not possible what do you think about having at least an additional |
fallback could be handled like https://www.i18next.com/principles/fallback#key-fallback context is more for a known set of option |
About the other issue with correctly typing the context, after tinkering around a bit this seems to work at least for all the cases we use in our application:
|
🐛 Bug Report
<Trans />
andt(...)
don't throw the same type errors when used with different context edge cases. But besides being inconsistent both<Trans />
andt(...)
don't correctly interfere if the context is ok or not.To Reproduce
https://stackblitz.com/edit/vitejs-vite-pabdwy?file=src%2FApp.tsx&terminal=dev
Expected behavior
See output above.
The text was updated successfully, but these errors were encountered: