-
-
Notifications
You must be signed in to change notification settings - Fork 193
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
Keys extracted with escaped characters starting in v8.4.0 #886
Comments
Update: according to the answer I got in the issue I reported in react-i18next (i18next/react-i18next#1662), |
The only change in v8.4.0 that might've caused this (other than dependency updates) was a change to make it so that extracted keys are not equal to the I just want to make sure: you're sure this was working correctly without the |
I agree @nicegamer7 I don't think it was just introduced. I'm trying to evaluate if we should actually unescape the key or not. It is a breaking change and not something I want to treat lightly. Is there a reason you don't follow @adrai suggestion to use the |
I'm sorry, I didn't paste all my configuration because I didn't realize it was relevant (silly me, I know 😓 ). I guess the relevant part is this (but I'll paste everything below): defaultValue: function getDefaultValue(locale, __namespace, key) {
if (locale !== 'en') {
return '';
}
return key;
}, The reason I don't use a key as suggested by @adrai is that I like to have my keys equal to their English translations. Anyway, in case it is relevant, I can assure you this change in behavior is a result of 8.4.0. I just doubled checked: with 8.3.0, key is extracted with As promised, this is all my module.exports = {
locales: ['en', 'es'],
input: ['**/*.{ts,tsx}', '!cypress/**/*', '!node_modules/**/*'],
output: 'public/locales/$LOCALE/$NAMESPACE.json',
createOldCatalogs: true,
keepRemoved: false,
keySeparator: false,
namespaceSeparator: false,
defaultValue: function getDefaultValue(locale, __namespace, key) {
if (locale !== 'en') {
return '';
}
return key;
},
resetDefaultValueLocale: 'en',
i18nextOptions: null,
pluralSeparator: '_',
contextSeparator: '_',
defaultNamespace: 'translation',
}; |
I tried following @adrai 's suggestion and use a key, but that creates another issue. Since I'm using |
We also use key fallback (where the value is the key) at the company I'm working at, but it seems to be working fine for us. I'll try to look into this in the coming days. |
I created a MWE of this issue using stackblitz. You can access it here. It's currently using <Trans shouldUnescape>Don't click me!</Trans> You can see in But if you update Please note that the usage of |
Thanks for the MWE and for your explanation @lgenzelis. After taking a look at our company's code, it looks like we're also being affected by this. I believe this is indeed a bug @karellm, since the keys being extracted are not the same as the ones expected by react-i18next. Here's a screenshot of what react-i18next expects vs what we extract: What react-i18next expects (got this using
edit2: never mind, we just didn't have |
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
refs i18next/i18next-parser#886 - Locks the version of i18next-parser to v8.3.0 - Otherwise the `si` language gets updated with random \u200d characters in between.
Should be fixed as of |
🐛 Bug Report
Up to v8.3.0, the following code would result in the key being extracted as
"Don't click me"
:Starting in v8.4.0, it gets extracted as
"Don't click me"
. The main reason this is an issue is that i18next will look for the key as "Don't click me", disregarding of whethershouldUnescape
istrue
orfalse
(I reported that as a separate issue here).This basically means that all the keys extracted by i18next-parser which contained escaped characters will be ignored by i18next.
Your Environment
The text was updated successfully, but these errors were encountered: