Is there a nice way to combine a formatter with a type?

[chriscoomber]

I want to write a simple translation like:

en/index.ts

import type { BaseTranslation } from '../i18n-types';

const en: BaseTranslation = {
  numItems: '{0} item{{s}}'
}

(I've got the typesafe-i18n file watcher running.)

However, if I have 10000 items, i18nObject('en').numItems(10000) prints "10000 items". I want it to print "10,000 items" with a comma (or "10 000 articles" in french, etc.).

I think the solution is to add a formatter. The vanilla number formatter seems to work:

formatters.ts

import type { FormattersInitializer } from 'typesafe-i18n';
import type { Locales, Formatters } from './i18n-types';
import { number } from 'typesafe-i18n/formatters';
import { i18n } from './i18n-util';

const L = i18n();

export const initFormatters: FormattersInitializer<Locales, Formatters> = (locale: Locales) => {
  numberFormat: number(locale),
}

and then update my index.ts:

import type { BaseTranslation } from '../i18n-types';

const en: BaseTranslation = {
  numItems: '{0|numberFormat} item{{s}}'
}

The problem:

I get a typescript warning in formatters.ts saying Type 'string | number | boolean' is not assignable to type 'number | bigint'. Basically in my index.ts, this formatter can be used with any type (string|number|boolean), but my formatter only works for number (and bigint).

I can work around that by writing:

import type { BaseTranslation } from '../i18n-types';

const en: BaseTranslation = {
  numItems: '{0:number|numberFormat} item{{s}}'
}

But this feels redundant. Surely because my numberFormat function only accepts values of type number, it should include type-checking the inputs to be number type, rather than having to specify it extra. Is there a nice way around this?

[ivanhofer]

All types are being generated by reading your BaseLocale file. If you specify a formatter there, then it get's added to the Formatters type. The types of the parameter of those fmatter functions also need to be read using the type information you give when applying a formatter i one of your translations.
If you don't specify a type then the input to your formatter function will be unknown. But because it get's used in a plural rule, typesafe-18n will narroẇ down the type to string | number | boolean which are the only allwed input types to the Intl.PluralRules.

If ou don't want to specify the type manually, you can write your formatter function like this:

export const initFormatters: FormattersInitializer<Locales, Formatters> = (locale: Locales) => {
	const numberFormatter = number(locale)
	return {
		numberFormat: (value: any) => numberFormatter(value),
 	}
}

[chriscoomber]

Using any isn't what I want because I do want the type checking, I just want it to be inferred from the |numberFormat.

I see, so the BaseLocale file generates the names and types of the formatters required, and the formatters.ts needs to provide them.

I feel like could maybe be nicer if it went the other way around. I.e. formatters.ts describes the formatters names and types, and then the BaseLocale file (or any locale file) can choose to use them (or not).

The reason why I suggest that, is that I think I'd like it if I could write:

formatters.ts

export const initFormatters: FormattersInitializer<Locales, Formatters> = (locale: Locales) => {
  numberFormat: (value: number) => ...something...,  // Here, the codegen looks at the type of `value`
}

en/index.ts (BaseLocale)

const en: BaseTranslation = {
  numItems: '{0|numberFormat} item{{s}}'  // Here, the codegen figures out that arg0 should be the same type as `numberFormat`'s `value`.
}

I appreciate that that's a big change, and not likely to happen...

[ivanhofer]

Your BaseTranslation consists of just texts and therefore can't easily be type checked if you accidentially wrote numberFomrat
(typo). If you want to be on the safe side, you need to specify the type on the param inside the string.

And it also is the single source of truth. Having two sources makes the whole process more complicated.