Add build-locales script

[muffinresearch]

• Add locale building script
• Add locale Provider and translation wrapper
• Add l10n middleware
• Actually extract the locale json.

[coveralls]

Coverage remained the same at 100.0% when pulling 7aae6f9 on muffinresearch:build-locales into 9ac1063 on mozilla:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 612fda3 on muffinresearch:build-locales into 9ac1063 on mozilla:master.

[mstriemer]

Does eslint get mad if you move the return into the try/catch, or do you prefer it this way? It doesn't really matter to me but I'd probably have avoided the extra var (should it be a let?).

  try {
    fs.statSync(lockFilePath);
    return true;
  } catch (e) {
    if (e.code !== 'ENOENT') {
      throw e;
    }
    return false;
  }

[mstriemer]

What makes the locking necessary? Won't two processes that are trying to do this at the same time either both work and produce the same output or one would catch up with the other and fail to open a file for writing then bail?

[muffinresearch]

Yeah you're probably right that the locking is probably not necessary. I based this on the i18n-abide scripts which had the locking. I think I'll remove it and we can always add it back if we have issues.

[mstriemer]

✨ 💥 ✨

[coveralls]

Coverage remained the same at 100.0% when pulling bd23062 on muffinresearch:build-locales into 9ac1063 on mozilla:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 239bae5 on muffinresearch:build-locales into 9ac1063 on mozilla:master.

[mstriemer]

This isn't actually used, do you anticipate we'll need it?

[mstriemer]

So after thinking about this being on props some more I went looking in react-router to see if it could help and it looks like it can. The Router can take a createElement function which is by default: <Router createElement={(Component, props) => <Component {...props}} />.

We are creating a Router directly on the client, so that should be easy to setup.

On the server we aren't actually creating a Router since we're using match but there is a RouterContext being created that will pass a default createElement function to a Router, this is currently being done by ReduxAsyncConnect. I think we can pass our createElement to RouterContext via ReduxAsyncConnect's render prop.

function detectLang(params) {
  return params.locale || params.query.lang || 'en_US';
}
match({ routes, location: req.url }, (err, redirectLocation, renderProps) => {
  const locale = detectLang(renderProps.params);
  const jedData = require(`json!../../locale/${locale}/${appInstanceName}.json`);
  const i18n = new Jed(jedData);

  function createElement(Component, props) {
    return <Component {...props} i18n={i18n} />;
  }

  function renderRouterContext(props) {
    return <RouterContext {...props} createElement={createElement} />;
  }

  return loadOnServer({...renderProps, store})
    .then(() => {
      const InitialComponent = (
        <Provider store={store} key="provider">
          <ReduxAsyncConnect {...renderProps} render={renderRouterContext} />
        </Provider>
      );
    });

    // ...

    return hydrateOnClient({component: InitialComponent});
});

If we took this approach then I believe I18nProvider and translate could be removed and we could still accept i18n from props.

This might be a big change so no worries if we want to move on but I think it would remove some code. Thoughts?

[muffinresearch]

This might be a big change so no worries if we want to move on but I think it would remove some code. Thoughts?

I always like the idea of less code :)

Even if you pass the i18n down via the router is the router data actually availble all the way down the component tree without intervention? If not it won't buy us much and the current way is explicit in the sense we know what's translated and what's not and we can have an app that isn't localized if we want to.

I think it will make sense to land what's working for now and then look at this separately so we can test out the theory. But it's definitely a good call to think of better ways to do the same thing.

[coveralls]

Coverage remained the same at 100.0% when pulling ede4efc on muffinresearch:build-locales into ed553a0 on mozilla:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 8fb2e66 on muffinresearch:build-locales into ed553a0 on mozilla:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 4102d73 on muffinresearch:build-locales into ed553a0 on mozilla:master.