i18nliner-js

i18nliner-js copied to clipboard

some plugins (e.g. react-i18nliner) may need to add some stuff to the i18n runtime extensions (e.g. stick ComponentInterpolator on the I18n global). so plugins need a way to:

1. signal that they have runtime extensions (perhaps multiple exports? or i18nliner could require("plugin-name/runtime")?)
2. do so in such a way so as not to include its non-runtime extensions in the browserified file ... i.e. it makes no sense to bloat the runtime bundle with extractors/etc

probably won't deal w/ this just yet; as a workaround for now, you can just add one more runtime extensions script to your page

ideally though it would be great to just have a single runtime dependency that includes i18n, i18nliner's extensions, and all the plugins' extensions

ideally though it would be great to just have a single runtime dependency that includes i18n, i18nliner's extensions, and all the plugins' extensions

This is what I did in my fork.

The readme for this project says:

You'll need to shoehorn i18n.js into your app, which (as of this writing) is not CJS-compatible

However, there is i18n-js which is CJS compatible. So I think you could make an endpoint in i18nliner, i18nliner/i18n that would just require('i18n-js'), then add the extensions to it and re-export it. I did that here: https://github.com/Download/i18nline/blob/master/lib/i18n.js

You can repeat the same trick for react-i18nliner.

This solution requires end users to include 18nliner via react-i18nliner but I don't think that's so bad.

I don't think you should try to include all plugin's runtime extensions from i18nliner, because the runtime extensions need to be browserified/webpacked, and AFAIK there is no good way to do dynamic includes without bloating the web bundle. Best to make sure all require calls have a literal string as their parameter so they are statically analyzable. This sort of rules out requiring stuff based on plugin configuration.

On another note, it's actually pretty tricky to get the configuration to the client, because the .18nrc file is only available on the server. Most of the options there apply only to the CLI, but there are some options related to the inferred key names that are needed on the client. If you configure these in .18nrc then the CLI will use the option, but you still have to do something to make sure this option is also set on the runtime... I am using the defaults to get around this because I haven't found a neat solution yet... My change of allowing config from package.json makes this problem worse, because you could potentially just require('./i18nrc') from the client to serialize the settings (they would be included in the browserified/webpacked bundle), but it sucks to include the whole package.json...