Typescript instead of json for message dictionaries?

[jorgebef]

I've started needing i18n for a couple of projects and I've encountered the usage of JSON for the translation dictionaries.

However, they can get kind of extensive and are prone to errors when you update in the main language, but forget to update all the others, or mistype the key for the JSON object.

I would like to know if there is any inconvenience to use Typescript objects as the dictionary at all that I'm missing?

I've used TS objects for this purpose and I'm testing the RSC branch right now and it works just fine with it, while providing autocompletion and screaming at you if you forget to update any language or mistype any key for the dictionary objects.

For example, here is a config.ts file I use to set up the project and provide some useful types:

import enMessages from './en';
import esMessages from './es';
import frMessages from './fr';

const validLocales = ['en', 'es', 'fr'] as const;
export const LOCALES = [...validLocales]; // make LOCALES mutable
export type LocalesType = typeof LOCALES[number];

export type MessagesType = typeof enMessages;

type Messages = {
  [k in LocalesType]: IntlMessages;
};

export const messages: Messages = {
  en: enMessages,
  es: esMessages,
  fr: frMessages,
};

Additionally, I use a global declaration to have type safety for the usage of the messages as it is described in the docs:

import { MessagesType } from '@config/locale/localeConfig';

declare global {
  interface IntlMessages extends MessagesType {}
}

With both of these, I feel like the DX is almost unbeatable.

Please let me know if there are any inconveniences with using Typescript that I've missed or if it's worth changing the examples and/or docs to maybe encourage said usage instead of plain JSON objects.

[amannn]

Hey @jorgebef,

that's perfectly fine from my perspective, great to hear if this works well for you!

The messages that next-intl accepts is really any kind of JavaScript object: It can originate from JSON, but you can also build it directly in TypeScript files. I'm primarily proposing JSON, because it's interoperable with other tools, like localization services.

If you export all messages from a single file, you probably want to ensure that this module is only used on the server side, but as far as I understand, that's already the case in your setup.

[jorgebef]

yes, exactly!
I only plan on using it server side, however, if I understand correctly, by specifying the namespace in the useTranslation hook it should only load the part that is specified (in case that I would need some translations client side)?

If not, I guess I would have to either pass the translations as props or create separate files as dictionaries for those?

[amannn]

by specifying the namespace in the useTranslation hook it should only load the part that is specified (in case that I would need some translations client side)?

As of the current state of the implementation, messages for the client side have to be passed explicitly.

I was in fact wondering, as now with suspense, we'd have a chance to load namespaces automatically when they are used on the client-side. This will be more ergonomic for the user, but the downside is, that it can cause waterfalls of fetch > render > fetch > render etc. when there are multiple nested client components that need translations. Loading all the relevant ones upfront is more performant. Potentially we could also support both, an ergonomic API + a preloading pattern. Not sure yet, for now I'm mostly concerned about getting this to work reliably on the server side. But I made a note of this, this is certainly something to consider—thank you for the input!

If not, I guess I would have to either pass the translations as props or create separate files as dictionaries for those?

Yep, currently this is the way to go (see the link above).