Play nice with server pre-rendering?

[EXC-BAD-ACCESS]

it appears that there's no way to specify that the messages should be included in the entry chunk instead of in separate language specific chunks. typically (as in i don't know how else to do it) if an app is broken up into a pre-rendered server side version and a downloadable client side version (much better description here) then the server version is one big bundle that contains everything and only the client version is broken up into multiple bundles.

if there's no work-around (i.e. some way to load the message chunks from the main entry on the server), then i think globalize-webpack-plugin needs to be updated to take the configuarion target into consideration and place the messages into the entry bundle when target = node, and in separate bundles when target = web.

[rxaviers]

You're right, there's no way to specify different chunks the messages should go to. All the messages (and other locale specific compiled data) go to the language chunk.

The architecture envisioned by this plugin assumes you have an app.js completely independent of locale data. The locale part comes from a separate i18n/.js file that extends the app with such locale.

Please, correct me if I'm wrong, but I understood you want an app.js (entry chunk) that has locale code (pre-rendered views), so you have n different app.js'es (one per supported locale) that are dynamically generated/served by your server and on top of it you still have language chunks for other non-pre-rendered views. Please, could you include a reduced example that demonstrates this?

Additionally (or even alternatively) to help me clarify what you need, could you provide with two things? (a) Assuming we have the feature you're looking for implemented, how would the globalize-webpack config look like? (b) Also assuming we have the feature you're looking for implemented, what content would go in each of the final files?

Thanks

[EXC-BAD-ACCESS]

I started to answer and ended up writing a novel...so i just went ahead and implemented what i wanted instead ;)

if you take a look at my fork or the latest submission to my pull request #17 i've added a new class to deal with prerendering, and an example of how to use it.

essentially you opt into this new behavior by specifying 'target: "node"' in your webpack config. when that's specified the plugin will remove the globalize runtime from the main bundle and dump it into each of the locale bundles, replace each instance of 'require("globalize")' in the main bundle with "require(locale)" and then wraps the whole main bundle in a function which accepts a locale variable.

so on the server you would do something like:

var appPath = path.join(__dirname, "./dist/prerender/app.js");
var languagePath = path.join(__dirname, "./dist/prerender/i18n/en.app.js");
var prerenderedApp = require(appPath);
prerenderedApp(languagePath);

the example in my fork has a simple node server that dumps will pull the "accept-language" header form the request and dump the language specific messages to the console.

[losogudok]

Please, correct me if I'm wrong, but I understood you want an app.js (entry chunk) that has locale code (pre-rendered views), so you have n different app.js'es (one per supported locale) that are dynamically generated/served by your server

Hi, I would like to know if it is possible to generate separate bundle for each locale, that is exactly what I need. Similiar behavior has https://github.com/webpack-contrib/i18n-webpack-plugin. It just replaces function invocations with translated string.

[EXC-BAD-ACCESS]

it's been a long time...i created my fork the way i wanted it back then and have been using it ever since...don't really remember the details. i did a tree on my production directory structure and removed a bunch of extraneous files, it looks like:
.
├── prerender
│   ├── app.js
│   └── i18n
│   ├── de.app.js
│   └── en.app.js
└── public
├── 1.43ea3636664b04621cdb.js
├── 10.0fcda33bc3d442d2add9.js
├── 11.c15de446c409cf6c3d48.js
├── 12.fd7ebde6182562ab6a52.js
├── 13.fd7b2b940881ac041d90.js
├── 14.40c99753d152232db33e.js
├── 15.130f8ba3d6a33f55c7ea.js
├── 16.44e8fd49b2a3ec3deff0.js
├── 17.3a2a0c88740076f1df2f.js
├── 18.2970b2a35390f6bced6d.js
├── 19.185b54916f749610c2ff.js
├── 2.697a5b2d6244928cc554.js
├── 20.7e540b559caac51e76d3.js
├── 21.cbf09fb1a237651b7a4c.js
├── 22.991b72efff81cacf1df4.js
├── 23.367f8d97ccdebd7104fd.js
├── 3.433696e1774e33c89793.js
├── 4.674e4daacf1e5e248357.js
├── 5.c5fb53df9f498831c374.js
├── 6.fd4eedce0ad74263bcb0.js
├── 7.0ce55ca5d5bbb93494d2.js
├── 8.c0330076ef4ef5d0b811.js
├── 9.1e79413e86403e7f00a4.js
├── app.bf78bf547de3f9b731b8.css
├── app.bf78bf547de3f9b731b8.js
├── app.chunk-manifest.json
├── app.manifest.json
├── common.93e493d291cd970ae3cd.js
├── common.b75ca7a559a8ac8e4850.js
├── i18n
│   ├── de.app.e3efc6bbea1ed9b6ac58.js
│   └── en.app.0b469d63d5a3a6968c56.js
├── manifest.json
├── vendor.178f0ebc014c6b6ac33a.js
├── vendor.c205a2eaef3ab843db01.js
└── vendor.f26b82288b04271eec48.js

[losogudok]

@EXC-BAD-ACCESS
Think I should try your fork, thanks. By the way, does it support plural or translations that have variables?

[EXC-BAD-ACCESS]

https://github.com/globalizejs/globalize/blob/master/doc/api/message/message-formatter.md