What I did was to use next-intl and separate my i18n strings into two separate files. One containing the strings required on the client and the other file containing strings referenced solely in server components. When setting up the i18n provider for the client I would then just pass on the client variables and thus have a much smaller footprint for those.

To help out with the setup I wrote a custom script to deduce which variables are used only on the server and which are used in client-side code, however that script is very specific to my project.

Thanks Christian

Do you use two different components to render the localization? Like TranslationClient and TranslationServer?

Not using components but conceptually with separate hooks, yes. The client-side useTranslations hook pretty much returns the values passed to the i18n context provider and works as you'd expect it. In server-side code I use getTranslations (specifically from next-intl) which does some magic under the hood using React's cache function that gets initialized on request and allows you to obtain the same set of server-side variables anywhere in your component tree. It works a bit like a server-side context provider.

Another thing to keep in mind is to evaluate whether you really need to split the translations into separate bundles for lack of a better term. Try to measure the impact of i18n objectively to see whether it's even necessary to optimize. In many cases, that won't be the case and is typically premature optimization without any indication it's required.