Production: Auto-generate the translation files #2

Open
rxaviers opened this Issue Aug 29, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@rxaviers
Owner

rxaviers commented Aug 29, 2015

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:

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

@rxaviers rxaviers referenced this issue in rxaviers/yarsk Aug 29, 2015

Open

Update conf/tmpl.html #1

@alunny

This comment has been minimized.

Show comment
Hide comment
@alunny

alunny Sep 10, 2015

Collaborator

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"
}
Collaborator

alunny commented Sep 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rxaviers

rxaviers Sep 11, 2015

Owner

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?

Owner

rxaviers commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alunny

alunny Sep 15, 2015

Collaborator

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).

Collaborator

alunny commented Sep 15, 2015

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment