Production: Auto-generate the translation files

[rxaviers]

Goal

• Auto generate the base language JSON file using the default messages from the source code (from the react components). So, such content can be sent off to a translation service.
• Auto initialize/update the translation table (JSON files) using the base language as default for the not-yet-translated-messages. So, generating the production bundles is never impacted by the translation service natural delay.

  Implementation Idea

On production, when Globalize webpack plugin is generating the translation chunks, i.e., when globalize-before-compile-extracts is called with request === undefined, we generate the translation JSON files. Note, the files can be generated asynchronously and independently of the ongoing webpack workflow.

When locale === attributes.developmentLocale, use globalizeCompiler.generateDefaultTranslation to generate the base language JSON file. Otherwise, use globalizeCompiler.initOrUpdateTranslation to manage the other files.

Expect the translation filepath to be passed by attributes.messages (similar to this). The filepaths for the various locales is deduced by replacing the [locale] part.

Requirements:

• [x] react-globalize-compiler support for statically extracting the default messages.
• [x] react-globalize-compiler support for generating the base language file
• [x] react-globalize-compiler support for initializing/updating the translation table using the base language as default for the not-yet-translated-messages.

[alunny]

Implementation idea sounds good - looks like much of it is in commented out form here: https://github.com/rxaviers/react-globalize-webpack-plugin/blob/master/ProductionModePlugin.js#L120

It might be good to have a callback/hook for manipulating the JSON object before it's written out. In our case, the translation files look like:

{
  "en": {
    "hello world": "hello world"
  }
}

instead of

{
  "hello world": "hello world"
}

[rxaviers]

It might be good to have a callback/hook for manipulating the JSON object before it's written out. In our case, the translation files look like:

Sounds good to me. I guess, then, you'll need a hook to convert after it's read in and before it's written out.

What do you think of first implementing this without the hook and then in a subsequent PR include the hooks?

[alunny]

Implementing without a hook sounds like a good start.

I actually think, if the phrase extraction doesn't take too long, it would be good to extract the default messages in development mode as well as production. This means that engineers can't accidentally commit code that introduces new messages without changing the default messages file (unless they didn't execute the code at all). That way, a CI hook can just watch messages/[defaultLocale].json for changes, and send things off to a translation service.

(the development thing would be a further enhancement, not part of this issue).