OpenNTF / dojo-webpack-plugin

Webpack plugin for Dojo 1.x
Other
66 stars 24 forks source link

Support for Dojo i18n resource files in webpack #254

Closed ChrisHarvey77 closed 5 years ago

ChrisHarvey77 commented 5 years ago

Hello dojo-webpack-plugin team,

We are currently in the process of moving from Dojo based builds to webpack, and are trying to use your plugin to handle Dojo style AMD modules. Our localized resource files are stored in .js files and are formatted like so:

define({ root:
({
    Cancel: "Cancel",
    Commit: "Commit",
    versionLabel: "version"
}),
"it-it": true,
"ja-jp": true,
"ko-kr": true,
"zh-cn": true
});

Currently, our Dojo setup uses the localeList key in the profile.js file to support locales like:

localeList:'ja-jp,ko-kr,zh-cn,en-us,it-it', // this is working for Dojo build

Our webpack.config.js setup for the DojoWebpackPlugin looks like:

const DojoWebpackPlugin = require('dojo-webpack-plugin');
// ...
new DojoWebpackPlugin({
    loaderConfig: require(path.resolve(path_string + "/loaderConfig")),
    environment: {dojoRoot: "./release"}, 
    buildEnvironment: {dojoRoot: rootdir},
    locales: ["en", "ja", "ko", "zh"], // does not appear to be working for webpack build
    async: true
}),

With all of this configuration above, we have questions on how to properly get the dojo-webpack-plugin to handle our existing locales setup. Our webpack build passes, and we can load our application, but the webpack bundle created doesn't seem to have any information about the locales listed above. When the application is set to a supported locale, the expected resource strings are not loaded.

We are unclear as to where the localized files should exist, and how to verify that they have been bundled correctly.

Is there a setting that we might be missing?

chuckdumont commented 5 years ago

Use stats:verbose in webpack config to get detailed information about which modules are included in which bundles.

You say that when the application is set to a supported locale, the expected resource strings are not loaded. Are there any errors messages in the browser console?

chuckdumont commented 5 years ago

@ChrisHarvey77 - are you still struggling with this or can this issue be closed?

ChrisHarvey77 commented 5 years ago

@chuckdumont - We are still working on this issue, but have been a little hectic lately. By using stats:verbose, we're able to see that the bundle has the localized string information within it, so that's a good start.

However, when we run our application on a localized machine, the localized strings aren't used. The English strings appear on the various UI elements.

Here is a snippet of the verbose output we're seeing specifically around one of our .js files which contain our localized strings:

[60] /build_harness/main/node_modules/dojo-webpack-plugin/loaders/dojo/i18n!./sc-ui/l10n/gen/resources/m_sc/nls/commitFiles.js 624 bytes {2} [depth 3] [built]
       ModuleConcatenation bailout: Module is not an ECMAScript module
       amd require dojo/i18n!sc-ui/l10n/gen/resources/m_sc/nls/commitFiles [138] ./sc-ui/js/CommitFilesDialog.js 2:0-189:2
       amd require dojo/i18n!sc-ui/l10n/gen/resources/m_sc/nls/commitFiles [263] ./sc-ui/js/NameColumn.js 2:0-14:2
       amd require dojo/i18n!sc-ui/l10n/gen/resources/m_sc/nls/commitFiles [264] ./sc-ui/js/StatusColumn.js 2:0-18:2
       amd require dojo/i18n!sc-ui/l10n/gen/resources/m_sc/nls/commitFiles [267] ./sc-ui/js/ContextMenuBuilder.js 2:0-83:2

What else can I include to help track down our issue?

Thanks for being responsive! -Chris

chuckdumont commented 5 years ago

Your snippet doesn't show that any locale specific nls files. That might be the issue. What is the directory structure for your nls folders? Try removing the dojo-webpack-plugin locales option. This should default to including all locales.

ChrisHarvey77 commented 5 years ago

Here's another snippet that shows locale-specific nls file information. I tried both with and without the locales option in the dojo-webpack-plugin and didn't see any changes.

[142] ./sc-ui/l10n/gen/resources/m_sc/nls/ja-jp/commitFiles.js 561 bytes {2} [depth 4] [built]
       ModuleConcatenation bailout: Module is not an ECMAScript module
       cjs require /sc-ui/l10n/gen/resources/m_sc/nls/ja-jp/commitFiles.js?absMid=sc-ui/l10n/gen/resources/m_sc/nls/ja-jp/commitFiles [60] /build_harness/main/node_modules/dojo-webpack-plugin/loaders/dojo/i18n!./sc-ui/l10n/gen/resources/m_sc/nls/commitFiles.js 2:0-269
chuckdumont commented 5 years ago

So it sounds like the issue is client-side. How are you specifying the locale to use. Dojo should detect the brower's preferred locale and use that automatically. If you're trying to specify the locale to use by setting the dojoConfig.locale property, then the dojo-config-api has condition must be enabled. It's enabled by default, but the sample program disables it. If you copied this in your config, try removing it and see if that resolves your problem.

ChrisHarvey77 commented 5 years ago

Hey Chuck,

So, we have tried both approaches to setting the browsers preferred locale. Our initial setup was to allow Dojo to pick up the locale automatically. That didn't work, so we were trying to set the dojoConfig.locale directly. With your advice above (enabling the dojo-config-api has condition), we still do not see the ja-jp strings we expect.

Here is how we are setting the locale in our test HTML file.

    <script>
        (function () {
            var locale = navigator.language;
            locale = locale.toLowerCase();
            if (locale === "ja" || locale === "ja-jp") {
                console.log("Setting dojoConfig.locale to ja-jp in CommitFilesDialog....")
                dojoConfig.locale = "ja-jp";
            } else {
                console.log("Setting dojoConfig.locale to en-us in CommitFilesDialog....")
                dojoConfig.locale = "en-us";
            }

        })();
    </script>

It feels like we're just missing something small somewhere to get all of this connected correctly. Thanks for your continued assistance.

chuckdumont commented 5 years ago

OK, not sure what else it could be. Would you be able to provide a test case that reproduces the problem?

ChrisHarvey77 commented 5 years ago

Hey Chuck,

We realized one problem with our configuration. We don't have dojo in the node_modules folder, instead it's in a separate 3rd party installation location. We added that location to the resolveLoader's "modules" attribute and are now sometimes seeing the localized content appear in the UI.

We're not sure why it's appearing sporadically. If we can successfully get it to appear, a simple refresh of the browser sometimes results back to en-us on a Japanese machine. We're trying to dig in on this behavior, but if this sounds familiar, we'd love to hear your thoughts.

Thanks!

chuckdumont commented 5 years ago

I haven't seen this. I'd start by examining the value of dojo.locale after your application has loaded. If the value matches the displayed language, then you know that the problem is with initializing the value of the locale (If you're still setting dojoConfig.locale, then check that too). If they differ, then the problem may be timing related (i.e. you may be initializing it too late).

Also, look for any relevant error messages in the browser console.

chuckdumont commented 5 years ago

Actually, something's not right. Your shouldn't need to point webpack's resolveLoader to the location of the Dojo files. resolveLoader is used by webpack to load webpack loaders. Dojo 1.x doesn't include any webpack loaders. Pointing resolveLoader to your Dojo location would result in webpack trying to load Dojo loader plugins as webpack loaders.

What lead you to believe that you needed to do this?

ChrisHarvey77 commented 5 years ago

Hey Chuck,

We've finally resolved our issues with our project. You were right in your previous comment, it didn't have anything to do with the resolveLoader. We did have to enable the dojo-config-api, as well as set the supportedLocales differently than we had originally configured.

We're all set now. Thank you for all of your responses.

Best, -Chris

chuckdumont commented 5 years ago

@ChrisHarvey77 - I believe the issues you encountered were caused by #258.