306752_en-US

liliconcom

Issues with Scripts ran on PCs with different language settings

 

Hi Team,

 

maybe this is an easy one, but I can't find a solution or at least an answer, so I would be happy to get some hints.

 

A customer in Germany has a person doing lots of analysis and dashboards, nothing scripted though. Her language setting is English, because she is not a native German speaker. The consumers are management and technical colleagues, native German speaking and therefore with German as language setting in JMP.

When the consumers run the table script for the dashboard, they find some of the formatting "resetted". E.g. she is plotting bar charts with mean values, but has eliminated the word "mean" and the brackets in the legend. When the consumers run this plot, they will get the legend with "Mittelwert(name)" in the legend.

 

 

 

 

 

Is there a way to avoid this? 

Re: Issues with Scripts ran on PCs with different language settings

It looks like this has been addressed in JMP 17 to work as you expect it to work, without needing to check the language code. At least the examples shown here seem to be working. Please report it again if you find other cases where this is still not working.

Re: Issues with Scripts ran on PCs with different language settings

Thank you all for the contribution! @hecht_jmp this has solved it for now, but would be great if fixed of course - so thanks also putting it on the list!

 

Best regards,

Florian

Re: Issues with Scripts ran on PCs with different language settings

Thanks, @hecht_jmp,  for reporting this as Defect S1579495.

Re: Issues with Scripts ran on PCs with different language settings

Florian, this looks like a bug. Here is a test case using Big Class:

 

Graph Builder(
 Size( 534, 448 ),
 Show Control Panel( 0 ),
 Variables( X( :age ), Y( :weight ), Y( :height ) ),
 Elements( Position( 1, 1 ), Bar( X, Y, Legend( 6 ) ) ),
 Elements( Position( 1, 2 ), Bar( X, Y, Legend( 7 ) ) ),
 SendToReport(
  Dispatch(
   {},
   "400",
   ScaleBox,
   {Legend Model(
    6,
    Level Name( 0, "aaa", Item ID( "Mean(weight)", 1 ) )
   ), Legend Model(
    7,
    Level Name( 0, "bbb", Item ID( "Mean(height)", 1 ) )
   )}
  )
 )
);

Note the Item ID() clauses that are hard-coded in English. As a workaround, the user can use System Service(Get Language Code) as Nick suggests like so.

aaa id = Match(System Service(Get Language Code),
 "de", "Mittelwert(weight)",
 "Mean(weight)"
);

bbb id = Match(System Service(Get Language Code),
 "de", "Mittelwert(height)",
 "Mean(height)"
);
...
   {Legend Model(
    6,
    Level Name( 0, "aaa", Item ID( aaa id, 1 ) )
   ), Legend Model(
    7,
    Level Name( 0, "bbb", Item ID( bbb id, 1 ) )
   )}

But this is not optimal as it requires the user to find the translations for each language they need to support. JMP needs to do this automatically.

 

Re: Issues with Scripts ran on PCs with different language settings

Just wanted to highlight Localize Your Custom JMP ® Applications for International Users in case folks are unaware.

Re: Issues with Scripts ran on PCs with different language settings

Hi Don,

thanks for your reply. I added a picture to make more clear what I tried to explain. The goal is on the one hand side to understand why it happens, and on the other side to prevent it. But that being said, she aims for a solution without scripting...

 

So, thanks for any advice

 

Best

Florian

Re: Issues with Scripts ran on PCs with different language settings

There was a previous discussion in the community on how to use the "Get Language Code" option in JSL as a way to manage this issue. Manage the display language with JSL (or freezing english language for distribution platform...) 

 

I'm also interested in understanding if there are other methods we could use to avoid this issue.

Re: Issues with Scripts ran on PCs with different language settings

Impossible to tell what's happening without seeing the code. My first hunch would be that the table columns are being referenced in a way to cause this issue. If the column names are hard coded in the platform(s) used to build the dashboard, a solution would be to replace the hard coded reference with a variable. Depending on the circumstances, this may be a bit tricky and require Substitute and/or Eval.