deprecation of defaultTranslationValues

[mxkaske]

First of all, thanks for the amazing package.

I am here seeking for best practices for the German language. As you might know, we have formal and informal tone.

I was about to do following (many times):

{
  "overview": {
    "navigation": "Übersicht",
    "title": "Hi {name},",
    "description": "Unten {tone, select, formal {finden Sie} other {findest Du}} einen Überblick aller Funktionen"
  },
}

And on initialization we get info whether or not we should use the ‘formal’ or ‘informal’ tone.

import { getRequestConfig } from "next-intl/server";

export default getRequestConfig(async () => {
  const locale = "de";
  const tone = await getUsersTone();

  return {
    locale,
    messages: (await import(`../messages/${locale}.json`)).default,
    defaultTranslationValues: { tone },
  };
});

And include the same with the client context.

    <NextIntlClientProvider
      messages={messages}
      defaultTranslationValues={{ tone }}
    >
        {children}
    </NextIntlClientProvider>

Like this, I don’t have to bother to add the tone wherever it is being used in the translations. It’s just there if I need it.

Now in the docs, this approach is deprecated (and will be removed in the next major version) in favor of using RichText. I find it not trivial without adding the RichText wherever we use any t(…) translation key and the app will be a bit bloated.

Anyone has some recommendations on how to best approach that use case?
Appreciate your time!

[amannn]

That's an interesting question! Yep, defaultTranslationValues was indeed deprecated.

I think the majority of apps/sites pick one tone, but I did see one app so far where this kind of personalization is possible. There, the chosen approach was to create separate messages for the formal and informal tone, providing a maximum of flexibility for messages without having to branch a lot in messages. You could use a locale with a private extension to encode the tone (e.g. de-x-formal).

The other option would be to handle the tone for each message individually, like you did in the example above.

Do you have an estimate about how many messages are affected? I.e. are messages generally personalized / refer to the user? If so, maybe a separate locale could be a good choice.

What do you think?

[mxkaske]

Hey @amannn! Thanks for the answer!

So in our case, it's very mixed. Lot's of translations key are also same for both tones. We started having two different de-informal.json and de-formal.json messages but it would require lots of duplication work. After reading about the enum-based values and defaultTranslationValues I thought it would be a perfect fit.

Didn't know about private extensions (💡) - it's kinda cryptic on the first glance haha.
But because of German phrases being quite different when using the different tone, unfortunately you cannot simply replace "Du" with "Sie" as phrase composition and verbs can change.

Maybe, and only maybe, it is possible to consider a e.g. informal message file only with required translation keys and merge the default formal messages including all translation keys. Otherwise, going back to two distinct files will do the work as well.

Edit:

The other option would be to handle the tone for each message individually, like you did in the example above.

That would mean using RichText and all occasions (translation keys) where we have the tone used?

[amannn]

But because of German phrases being quite different when using the different tone, unfortunately you cannot simply replace "Du" with "Sie" as phrase composition and verbs can change.

Yep, that's true—the difference can be significant, also the sentence structure is often more complex in formal tone.

E.g.:

• "Könnten Sie mir bitte sagen, wo sich das Büro befindet?"
• "Kannst du mir sagen, wo das Büro ist?"

Merging messages to avoid duplication could be another option, but I personally have mixed feelings with that. It can make it hard to know which message comes from where and also if you use a translation management system, they don't know about this relationship.

It seems to me that translation of messages is moving towards an AI-driven model, if you consider upcoming solutions like https://crowdin.ai and https://languine.ai. I could imagine it may become cheaper to manage multiple translation files, even if they have some overlap (also regional variants like en-US vs en-GB are examples of that).

Due to this, I think separate messages could be a reasonable strategy, yes 👍. But that's only my impression, your decision might depend on other factors depending on your app!

That would mean using RichText and all occasions (translation keys) where we have the tone used?

Not necessarily RichText, but maybe something like this:

function Greeting({firstName}) {
  const tone = useTone();
  return t('hello', {firstName, tone});
}

[mxkaske]

Alright, I think going with two distinct messages, similar to the regional variants en-US and en-GB and having some AI tools convinced me on that one!

I really appreciate the long, comprehensive responses. You are awesome! 🔥