Server-side i18n benefits when using NextIntlClientProvider?

[juliusn]

According to the documentation the benefits of server-side internationalization are:

1. Your messages never leave the server and don't need to be serialized for the client side
2. Library code for internationalization doesn't need to be loaded on the client side
3. No need to split your messages, e.g. based on routes or components
4. No runtime cost on the client side
5. No need to handle environment differences like different time zones on the server and client

However, the library allows using translations in server and client simultaneously.

Do these pros apply only when I have no NextIntlClientProvider in my component tree?

In a situation where I have to translate some of the messages on the client, do I still get any benefit from server-side internationalization, or are all the pros negated at this point?

An example of a situation like this would be a message that needs client-side data for dynamic values.

messages/en.json

{
  "Login": {
    "loggedIn": "You are now logged in",
    "welcome": "Welcome, {name}!"
  }
}

app/[locale]/login/LoginForm.tsx

'use client';

export function LoginForm() {
  const t = useTranslations('Login');

  {/* ... */}

  async function handleLogin(formData: FormData) {
    const response = await login(formData);
    if (response.ok) {
      showNotification({
        title: t('loggedIn'),
        message: t('welcome', { name: response.profile.user_name }),
      });
    }
  }
}

t('welcome', { name: response.profile.user_name }) consumes data received by a client-side handler. Any reason to move t('loggedIn') to a server component and pass it down as a prop?

[hqw567]

@amannn I have the same doubts.