doc(webpack): Using i18next-xhr-backend with webpack

[doktordirk]

I finally got webpack to work with unbundled translations and wanted to share it, particularly since it was easy in the end. The position of this addition isn't optimal, but neither do i see a better place. I still have no idea how to get webpack and Backend.with(aurelia.loader) to work, but with one easy unbundled option (this one) and an easy bundled option (last commit), i certainly not gonna try further.

[zewa666]

I guess this is specifically needed for the webpack-dev-server right? Does this affect prod builds? With regards to the built in aurelia.loader, that for sure won't work, as it relies on lazy-loading capabilities provided by a module-loader (system.js/require.js)

[doktordirk]

It's specific to webpack and the xhr loader and for dev and production (i clarified that further just now) , though only for dev it's not obvious. and since it's xhr, it's lazy loading. as seen in #221, making the webpack loader work with i18n is full of problems. and even if it worked (i didn't manage), where's the point anyways? one suggestion was

new ModuleDependenciesPlugin({
    "aurelia-i18n": [
        { name: 'locales/en/translation.json', chunk: 'lang-en' },
        { name: 'locales/sv/translation.json', chunk: 'lang-sv' }
    ]
})

so specifying a chunk for each translation. that's ridiculous considering that they all come originally in their own 'chunk' named translation.json.
in contrast to that 50+ entries long issue, xhr and the other bundled version are straight forward once it's known.

[zewa666]

I can't see the new changes, have you forgot to push your changes maybe?

[doktordirk]

sorry, i force pushed. i highlighted webpack and xhr in the first sentence and mentioned dev and production mode

[zewa666]

oh alright. Looks good for me let us get that in and thus the story for webpack a bit straighter.

Thanks for all your efforts