Best practice to use translations in Client Components

[hkmute]

As suggested in the documentation, we can pass the translation as props from a server component to a client component. But this approach is getting tedious when my client component is deeply nested.

Say I have a Table which is a server component, then I will pass down a Button which can trigger a modal with Buttons inside. When I need to provide translation to the Button label, I will have to go back to the closest server component (which is the Table in this case) to pass down the translation messages (Table => Button in the Table => Modal => Button in the Modal).

This is also getting confusing as the translation messages could partially stop at each level. Is there better way to handle this kind of case?

[amannn]

Edit Jul 15, 2024

Due to ease of use, we're now recommending passing all messages to the client side to get started: Setup for layout.ts.

If you're interested in improving the performance of your app, you can additionally explore this section: Using internationalization in Client Components.

---

Previous answer

That's a great question! In the pages directory this was easier, because there are only Client Components (see the docs on "Providing messages" at "How can I know all the namespaces needed for a page?").

However, static properties from Client Components can't be read from Server Components, therefore this doesn't work unfortunately anymore.

Supporting either such a property access within React/Next.js or a built-in compiler for next-intl would work as a solution. Unfortuantely, I don't have a better answer here currently!

[hkmute]

It sounds to be that for more complex components, it would be better to take the client side approach, otherwise the messages would be hardly maintainable as the project grows.

[TomJD]

We are having the exact same issue and so far cannot come up with a decent solution. As our application grows, we will have more and more translations nested deep also into client components. We try not to use the <NextIntlClientProvider> because of the performance trade-off. If someone does come up with a fancy solution or even a work-around for time being, would love to be in the loop!

[skonky]

I think I ran into the same issue as you have, and I solved it by using the core library instead of the hooks.
This is my Table component composition which is a "use client" component.

'use client';
import {
  Table,
  TableBody,
  TableCell,
  TableHead,
  TableHeader,
  TableRow,
} from 'ui';
import { type Advertisers } from '@/lib/advertiser';
import Money from '@/app/components/money';
import { AdvertiserTableMessagesReturnType } from './advertiser-messages';

export default function AdvertiserTable({
  advertisers,
  messages,
}: {
  advertisers: Advertisers;
  messages: AdvertiserTableMessagesReturnType;
}) {
  const { title, description } = messages;
  return (
    <>
      <h3 className="mt-10 text-2xl font-bold tracking-tight">{title}</h3>
      <p className="text-muted-foreground">{description}</p>
      <Table className="mt-4 max-w-[400px]">
        <TableHeader>
          <TableRow>
            <TableHead>ID</TableHead>
            <TableHead>Name</TableHead>
            <TableHead>Spent</TableHead>
          </TableRow>
        </TableHeader>
        <TableBody>
          {advertisers.map((advertiser) => (
            <TableRow key={advertiser.id}>
              <TableCell>{advertiser.id}</TableCell>
              <TableCell>{advertiser.name}</TableCell>
              <TableCell>
                {/* Makes use of a formatter*/}
                <Money
                  amount={advertiser.expenses.amount}
                  currency={advertiser.expenses.currency}
                />
              </TableCell>
            </TableRow>
          ))}
        </TableBody>
      </Table>
    </>
  );
}

This money component can now be imported in "use client" components too.

import { createFormatter } from 'next-intl';

export type MoneyFormatProps = {
  amount: string | number;
  currency: 'EUR' | 'USD';
};

const format = createFormatter({ locale: 'en' });

export default function Money(options: MoneyFormatProps) {
  const { currency } = options;
  const amount =
    typeof options.amount === 'string' ? +options.amount : options.amount;

  const numb = format.number(amount, {
    style: 'currency',
    currency,
  });

  return <span>{numb}</span>;
}

I also have a separate file that is responsible for fetching the correct messages for the component:

import { useLocale, createTranslator } from 'next-intl';

// This is a representation of how the messages look for this component
export type AdvertiserTableMessagesReturnType = {
  title: string;
  description: string;
};

export default async function advertiserTableMessages(): Promise<AdvertiserTableMessagesReturnType> {
  const locale = useLocale();

  const messages = (await import(`../../../../messages/${locale}.json`))
    .default;

  const t = createTranslator({
    locale,
    messages,
    namespace: 'AdvertiserTable',
  });
 
  return {
    title: t('title'),
    description: t('description'),
  };
}

And as last I have a "container component" which is combining it all together and passing the props into the presentational component:

import { getAdvertisers } from '@/app/lib/advertiser';
import AdvertiserTable from './advertiser-table';
import advertiserTableMessages from './advertiser-messages';

export default async function AdvertiserTableContainer() {
  const advertisers = await getAdvertisers(); // fetch data
  const messages = await advertiserTableMessages(); // fetch messages 
  // then pass it as props so it can be serialized
  return <AdvertiserTable advertisers={advertisers} messages={messages} />;
}

[adnan-smlatic]

Having to go into this deep of a rabbit hole for simple translation support just makes me realise what an utter joke the entire javascript ecosystem is. Just a bunch of broken things taped together and shipped as a "framework" with zero thought put into anything.

Why does handling translations in Client Components have to be such a pain in the ass? You already have the fucking locale and file, just fetch the fucking file and give me whatever key I fucking want instead of this nonsense. i18next does it, why can't Next? A component that needs its own separate component to fetch translations for it and a container component so you can pass the translations to the original component? What kind of braindead DockerScript fucking shit is this, what the fuck am I doing with my life

fuck all of this

[TomasSestak]

How to consume picked messages passed through NextIntlProvider with working typescript?