Strategy for fully sever-side translations with App router.

[markoleavy]

Hi everybody,
I've just published an article on Medium, that shows a strategy to implement next-intl with app router and server-side translations, simplifying the typing and field translation process.
I would love to know what you think about it, and if it could be the base for a new feature!
Cheers!

[amannn]

Thanks for sharing your thoughts @markoleavy! Keeping i18n purely on the server side definitely has it's advantages, but I think I wouldn't push it too dogmatically (depending on your app).

In regard to avoiding prop drilling, there's an example in the Passing translations to Client Components docs in the expandable section "How can I implement a form?". Sometimes the way how you structure your components (by accepting children or even multiple "slots") can work better for having many Client Component leaf nodes, making it more natural to provide props from Server Components without larger objects.

That being said, there's absolutely a necessity for handling i18n in Client Components in Next.js apps. I'd like make this more natural to handle in the future without performance drawbacks (see e.g. #962 and #1).

In any case, your approach will definitely continue to work!

[markoleavy]

Hi @amannn and thanks for tour replay and work, that made the i18n implementation almost flawless for the website of the company I work for.
Your comment made me think that the best part of my work is not actually the server-side execution (as you said, different needs would need different approaches), but the ability to get typed translation objects with a single function call, which combined with typed sheets it's a great way to simplify the translation process and organization (think about a componente with 10 levels of nested components who might require namespace with 10 levels of nested objects).
To get this result in a much simpler way compared to the one my guide would be nice to have:

• A codegen executable function to get sheet types from a 'master' translation sheet, that creates a FullTranslation type and allo fe the namespaces separates types.
• A new function/hook similar to getTranslations/useTranslations that could work like that: useTranslationBlock<NamespaceType>('namespace.eventualNestedFiedl') that returns a typed object (or a string in case there is no more nesting) instead fo the t() function.