Build-time i18n

[wmertens]

@kossnocorp Hi, I am the author of compiled-i18n which is a framework-agnostic way to embed i18n at compile time.

What happens is, there's a build plugin (currently only for vite) which transforms the browser build so that after the build completes, each locale gets a copy of the build with the i18n strings replaced by the translation. All you need to do is tell the browser to get the js files from the locale directory instead of the generic directory. This means that the runtime cost is 0.

I am thinking it would be nice to have datefns support this way of working. I'm looking for ideas that make it easy for library authors to configure it.

E.g. one of the exported locales could be compiledI18n and that would provide the configuration. For example, formatDistance might be:

import {_} from 'compiled-i18n'

export const formatDistance: FormatDistanceFn = (token, count, options) => {
  const result = _`date-fns:distance:${token}:${count}`

  if (options?.addSuffix) {
    const isFuture: boolean = !!options.comparison && options.comparison > 0
    return _`date-fns:distance-suffix-future:${isFuture}:${result}`
  }

  return result;
};

and the Afrikaans translation file "i18n/af.json" might look like:

{
  "date-fns:distance:$1:$2": {
    "lessThanXSeconds": {
      "0": "nu",
      "1": "minder dan een seconde",
      "*": "minder dan $2 seconden"
    },
  
    "xSeconds": {
      "1": "1 seconde",
      "*": "$2 seconden"
    },
  
    "halfAMinute": "een halve minuut",

    "*": "unsupported token $1"
  },

  "date-fns:distance-suffix-future:$1:$2": {
    "true": "over $2",
    "false": "$2 geleden"
  }
}    

After building, the supported locales would each have a customized build of date-fns/intl with only the actually used translation code directly embedded in the formatting code.

In this example, the code would look like

import {interpolate} from 'compiled-i18n'

export const formatDistance = (token, count, options) => {
  const result = interpolate({
    lessThanXSeconds: {
      0: "nu",
      1: "minder dan een seconde",
      '*': "minder dan $2 seconden",
    },
  
    xSeconds: {
      1: "1 seconde",
      '*': "$2 seconden",
    },
  
    halfAMinute: "een halve minuut",

    '*': "unsupported token $1"
  }, [token, count])

  if (options?.addSuffix) {
    const isFuture: boolean = !!options.comparison && options.comparison > 0
    return interpolate({
      true: "over $2",
      false: "$2 geleden"
    }, [isFuture, result])
  }

  return result;
};

During development, the compiled-i18n vite plugin automatically loads the supported locales in memory.

The changes required on the date-fns side would be:

• a compiled-i18n specific locale
• all translations under i18n/<locale>.json

Ideally, the locale would be default so it never has to be passed.
The translations in json files would mean duplicating all the translations though.

The dev will no longer have to think about i18n, everything is automatic after adding the compiled-i18n vite plugin, and only the actually used translation code is sent to the client.

What do you think?