Translator returns unit type based on key

[noahbald]

Hey, I've been running into a problem where I have a function that should be given a specific translation. I'd like to write a function something like this, that doesn't use next-intl directly

const formatAccountName = (prefix: "account.prefix", accountDetails: AccountDetails) => {
  // ...do some complicated stuff
  return shouldHavePrefix ?  `${prefix}: ${formattedStuff}` : formattedStuff;
};

const t = useTranslations("account");
formatAccountName(t("prefix"), accountDetails) // Ok!
formatAccountName(t("foo", accountDetails) // Type error!

I know that I could pass t to formatAccountName with something like typeof useTranslations<"account">, however I have a script that statically analyses translations in order to cull unused translations (Like in here).

Is this something maintainers think should be worth considering? It could be something enable-able via AppConfig.

Fwiw, I can get this working in my own .d.ts file, but then I have to call t with t("<key>" as const) to get a matching return type.

declare module "next-intl" {
  interface AppConfig {
    Messages: Messages;
    Formats: Formats;
  }

  declare function createTranslator<const TranslatorMessages extends IntlMessages, const Namespace extends NamespaceKeys<TranslatorMessages, NestedKeyOf<TranslatorMessages>> = never>({ _cache, _formatters, getMessageFallback, messages, namespace, onError, ...rest }: Omit<IntlConfig, 'messages'> & {
      messages?: TranslatorMessages;
      namespace?: Namespace;
      /** @private */
      _formatters?: Formatters;
      /** @private */
      _cache?: IntlCache;
  }): {
   // <TargetKey extends NamespacedMessageKeys<TranslatorMessages, Namespace>>(key: TargetKey, ...args: TranslateArgs<NamespacedValue<TranslatorMessages, Namespace, TargetKey>>): string;
      <TargetKey extends NamespacedMessageKeys<TranslatorMessages, Namespace>>(key: TargetKey, ...args: TranslateArgs<NamespacedValue<TranslatorMessages, Namespace, TargetKey>>): `${Namespace}.${TargetKey}`;
      rich<TargetKey extends NamespacedMessageKeys<TranslatorMessages, Namespace>>(key: TargetKey, ...args: TranslateArgs<NamespacedValue<TranslatorMessages, Namespace, TargetKey>, RichTagsFunction>): ReactNode;
      markup<TargetKey extends NamespacedMessageKeys<TranslatorMessages, Namespace>>(key: TargetKey, ...args: TranslateArgs<NamespacedValue<TranslatorMessages, Namespace, TargetKey>, MarkupTagsFunction>): string;
      raw<TargetKey extends NamespacedMessageKeys<TranslatorMessages, Namespace>>(key: TargetKey): any;
      has<TargetKey extends NamespacedMessageKeys<TranslatorMessages, Namespace>>(key: TargetKey): boolean;
  };
}

[amannn]

Not sure if I completely understand your use case, but generally the best way is to simply call t in the place where you retrieve it from useTranslations. Is that an option for you? This also unlocks optimizations like tree shaking as you mention it.

This might be related: #1661

[noahbald]

but generally the best way is to simply call t in the place where you retrieve it from useTranslations.

Yes, sorry, that's what I'm doing 😅

The main purpose of having this is so that such a utility function, which expects a specific translation, can express that as part of the type system.

const t = useTranslations("foo");
const translation =  t("bar");
type Key = typeof translation // "foo.bar"

That way I can enforce users of my function to only ever pass the translation given by "foo.bar".

[amannn]

I see, I guess this is somewhat related to #1661 then. Maybe you could achieve this with branded types in userland where you really need it?

I think for the time being, I don't really see so much use for this, sorry! It's important for next-intl to stay as minimal as possible, given that it already has a somewhat extensive API surface. So I try to be quite conservative with new features, I hope you can understand!