-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
memoize saves fallback with async backend #3
Comments
Will look into this tomorrow....guess best would to be just not memoize in case of fallbacking to key? Agree? |
Yeah, we had it disabled so far due to this issue. We're looking into some performance regressions on our site right now, so I was playing around with reenabling it which led me to the workaround of manually clearing the memoization cache. |
should work with: i18next@11.3.3 i18next/i18next@dd9cabc#diff-42176d501e1082b1431ec21640f0ff05 -> |
Thanks for a quick release, this looks fixed! 👍 |
awesome...if you encounter any other issue let me know....i18next-icu still rather fresh |
In our app, we use key-based fallback with an asynchronous i18next backend with react-i18next and i18next-icu.
When using react-icu with the default settings, it looks like memoization incorrectly memoizes the fallback keys, even after the translations have been loaded.
I can fix this right now by calling
ICU.mem = {}
manually after a new translation has been loaded. This should probably not happen in the first place though.Alternatively, you might want to expose a (documented) method to clear the memoization cache.
The text was updated successfully, but these errors were encountered: