next-i18next
next-i18next copied to clipboard
serverSideTranslations + client side translation
Do you have a documentation issue?
I wanted to load some translations serverside and some dynamic ones client side. Depending on data recieved so backend sends only id and translation are loaded client side, the client sides are ones that dont appear on screen on first load so i can lazy load them for more performance.
At least in documentation didnt find a clear way to do it as if i use "serverSideTranslations" then client side new namespaces wont load. I did this but not sure if this is correct (inspired on available documentation).
const { t, i18n } = useTranslation([`item_${item}`]);
const translate = useCallback((key: string) => {
if (item)
i18n.reloadResources(i18n.resolvedLanguage, [`item_${item}`])
return t(key)
}, [item])
It mainly to contribute and not just complain as this seems to work for me.
Did you follow this?
https://github.com/i18next/i18next-http-backend/tree/master/example/next
Yes, the alternative usage was my guide. But still with that it wasnt working when loading serverside namespaces that where different from the new ones in client side.
So with this implemantation i went from loading 1,4MB worth of translations that i might not need, to loading just 100KB on server.
i might just be dumb but the "'lazy-reload-page" is a param or a namespace? also { bindI18n: 'languageChanged loaded' } is not working with typescript, maybe type definitions.
And my usecase is to load different namespaces on server and client. In server i load the "static" translations and in client the "dynamic" ones that also i dont need to load on first render as i use it for tooltips for example.
Sorry, I don't get your question... it's a namespace.
That i dont understand where the lazy loading is. Isnt it just reloading it on client side? The server loads it, then it sends it to the client and then the client reloads it. I dont see any lazy loading.
ahhh, yes in that example it is not really lazy... but at least the client will load the newest translations.
fyi: regarding the bindI18n typescript... try to update react-i18next...
btw: in general you can have different namespaces listed in serverSideTranslations and others in useTranslation / reloadResources... but you might need to check for the ready flag...
After update: The intelisense still doesnt like it but it compiled at least. Still didnt work correctly for me in dev. And if you use different namespaces in useTranslation from the ones in serverSideTranslations you must use reloadResources, i didnt find that any where in documentation. Maybe i didnt search it correctly.
https://locize.com/blog/next-i18next/#alternative-usage
@adrai thanks for sharing the resource. I tried doing exactly that and while it works Im getting typescript error:
Argument of type '{ bindI18n: string; }' is not assignable to parameter of type 'UseTranslationOptions<undefined>'.
Object literal may only specify known properties, and 'bindI18n' does not exist in type 'UseTranslationOptions<undefined>'.ts(2345)
In my code:
const { t, i18n } = useTranslation(['common'], {
bindI18n: 'languageChanged loaded'
});
useEffect(() => {
i18n.reloadResources(i18n.resolvedLanguage, ['common']);
}, [i18n]);
Is this a bug on the i18n part? Or should I define it in the next-i18next.config file?
@pedrodurek any idea?
I have tried the above and also followed the tutoria here: https://locize.com/blog/next-i18next/ and currently I am getting the hydration error:
Unhandled Runtime Error
Error: Hydration failed because the initial UI does not match what was rendered on the server.
As well as the following error from several components where I changed useTranslation()
to the sample code in the tutorial:
Is there something that I might be missing? I enabled and disable getStaticProps and the result is the same. I am using Next.js with next-i18next with SSR. Here is what I added based on examples to my next-i18next config file:
locales: ['en', 'sk'],
defaultLocale: 'en',
backend: {
backendOptions: [
{
expirationTime: 10 * 1000 // 1minute
},
{
projectId: '---',
apiKey: '---',
version: 'latest'
}
],
backends: isBrowser ? [LocalStorageBackend, LocizeBackend] : []
},
debug: true,
serializeConfig: false,
use: isBrowser ? [ChainedBackend, require('locize').locizePlugin] : [],
ns: ['common', 'validation']
Any Idea how could I solve this?
@datainvestor please provide a minimal reproducible example
@adrai So here is sandbox where I reproduced the second error I am getting: https://codesandbox.io/s/nostalgic-wood-k85ye6?file=/pages/lazy-reload-page.tsx
The hydration warning occurs because your local translations differ from the one in locize...
Compare for example the bottom-navigation.back key in the common namwspace.
https://api.locize.app/f9e15c17-8db4-4a98-9dda-77bcaa83c0cf/latest/en/common
I see but when using Locize platfroms our translator will be changing them to see how they look like in the In-context editor. So they will be different from the local translations anyway. We are trying to integrate your platform with our app but I cant figure out the proper use.
Is the solution to ditch the local translations altogether when using in-context editor?
The hydration message is only a warning.
You need to live with that during dev mode. In prod the warning will not be shown.
Is there a setup guide for next.js to use only translations from Locize platform with next-i18next
? Which backend to use for that? Ultimately I think what can solve this issue is just to get live translations from Locize, no local files, no localstorage whatsoever.
It seems that hydration is an error that switches the app to be clientside only which has some other implications.
This: but I don't recommend: https://github.com/locize/next-i18next-locize#possibility-2-config-for-locize-live-download-usage (Possibility 2)
Seems that this is the only approach to solve my issue for now, I could probably use it only on development environment which would have set up in-context editor with Locize. Do you think is there any other way?
I'm not aware of any other way, sorry.
Is there some kind of throttling applied on Locize platform? It seems that translations are not refreshed immediately when changed on the Platform, or there is a setting in Locize-Backend that is not downloading them at every refresh?
Don't know what you exactly mean, but after keys are saved, and publish mode is set to autopublish, it needs a couple of seconds until they're avaulable all over the world.
btw: also the local storage caching or the cache settings influences this if configured.
btw: https://github.com/locize/i18next-locize-backend#troubleshooting
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.