Adding localized geoprocessing widget input parameters

461
3
Jump to solution
05-23-2018 12:25 PM
by Anonymous User
Not applicable

Just wondering if anyone has come up with a sure fire way to add localized parameter names for the geoprocessing widget? The parameter names (and tool tips) come from the config__##.json file located in the config folder. They don't pull from the nls\strings.js. I realize there's probably a few ways to solve this:  multiple config files, hacking the widget to point at strings.js (this way might be messy) and the list goes on...

I implemented the first method of loading a localized config file for Robert's Identify as I needed it to point at localized fields when performing a query. If the locale matches French (FR), I override the config. Right now this seems like my best path forward for geoprocessing as well.

\jimu.js\ConfigLoader.js

function loadWidgetManifest(widgetManager, e, portalUrl){
     function _doLoadWidgetManifest(e){
          if (e.name === "Identify"){
             console.log(dojoConfig.locale);
               if (dojoConfig.locale.indexOf("fr") >= 0) {
                   e.config = "configs/Identify/config__28FR.json";
                   console.log(e.config);
                }
          }

Other thoughts?

0 Kudos
1 Solution

Accepted Solutions
RobertScheitlin__GISP
MVP Emeritus

Kevin,

   I have never ran into this concern but the route you have above is a great solution to the issue. There are not many widgets that store strings in their json files so you should be good to go with this route. In my identify widget I can only see where you would want to maybe localize the identify layer name.

View solution in original post

3 Replies
RobertScheitlin__GISP
MVP Emeritus

Kevin,

   I have never ran into this concern but the route you have above is a great solution to the issue. There are not many widgets that store strings in their json files so you should be good to go with this route. In my identify widget I can only see where you would want to maybe localize the identify layer name.

by Anonymous User
Not applicable

Thanks for the sanity check, Robert.

The application I'm building will return both English or French data through the identify. These are separate fields within the service. I was finding it difficult to build the logic into List.js for EN/FR as the attributes are built up looping through. I got down a path of trying to identify what field in what loop iteration is needed for English or French and it wasn't a good approach as everything changed if I added or changed a field in the config. Thus the code changes in List.js were minimized by just passing in French or English fields.

Actually, one question, but unrelated - do you have any suggestions getting NLS values into List.js? I don't think this is a good approach, but I made it work by passing NLS into the startup function.

widget.js

postCreate: function () {
 //...
 this.list.startup(this.nls);


list.js

startup: function(nls) {
 this.nls = nls;
0 Kudos
RobertScheitlin__GISP
MVP Emeritus

Actually that is a similar approach the esri uses in several of their widget.