Supporting Commas and Periods as the decimal point

[caseywhite]

I see in the LANSA Web Admin that you can choose Comma or Period for your decimal point as the setting for numeric editing/display. Are there any tips on how to support both comma or period for the same LANSA system based on some criteria, like user id.

For example some users will want to enter a number like 12,99 which is 12 dollars and 99 cents.
Other users form other countries will want to enter 12.99.

Has anyone created a LANSA web site where some users can use the comma as the decimal point and other users use the period as the decimal point? If you have, any tips on how you accomplished this? Did you run into major issues. For example, we support CSV downloads and uploads so that would seem to be another hurdle we would need to get over.

[BrendanB]

Casey,

This is actually controlled by the chosen 'LANGUAGE'. so it comes back to choosing a different language BASED ON THE USER. (There are various suggestions on the forum for how to acheive this).

The 'other' way is to treat the INPUT fields as Strings/Char/Alphanumeric values.

then you can simply STORE the values how your system requires it:

Code: Select all

#myNum := #inputString.replace("," ".")

or when displaying:

Code: Select all

if (#userWantsCommas)

#displayString := #myNum.asString.replace("." ",")

endif

of course, this means you lose the 'automatic' +/- buttons (although you could create a custom RP that 'added them back').

HTH.

[caseywhite]

Thanks for the reply Brendan.

Could you elaborate on what you mean by it is controlled by the chosen 'LANGUAGE'. I was looking in the Housekeeping menu at the language options and don't see anything that lets me configure how the period and comma are handled.

Not sure if it matters by we are using WebEvent and WAMs.

[BrendanB]

Sure - on the URL you would have something like:

https://yourpc:8443/learn/dem/xmdmain?l ... eloper=yes

(for a VL webpage)

the lang=eng part indicates what language you are using.

typically the language is set on the partition (and you can setup multiple)...

so you need to indicate which language to use.

WAMs also use a language indicator:

http://localhost/learn/lansaweb?wam=LIS ... W&lang=ENG

(NOTE the end part of the URL).

WEBEVENT: has the language at the end of the url as well.

The parameters to call a LANSA function are:

PROCFUN+<process name>+<function name>+[<partition>]+[<language>]

For example, if you want to execute the MYFUNC function in the MYPROC process in the DEM partition, your URL might be entered as:

http://www.lansa.com/CGI-BIN/LANSAWEB?P ... NC+DEM+ENG

[caseywhite]

Thanks for the reply Brendan. I am able to set the language but what I don't understand is how can I tell LANSA and the IBMi server that for this language the numeric values will be using a comma as the decimal point instead of a period. I don't see how I can configure the language to use a comma instead of a period for numeric fields.

[BrendanB]

Casey,

check your partition definition, specifically the ISO language code.

ISO publishes various language codes that specify things like commas instead of periods...

so you will need to use the correct one for your language. https://www.iso.org/iso-639-language-codes.html

For example 'fr' will give you commas instead of periods.

[caseywhite]

Thanks Brendan.

Maybe version 14.0 of LANSA, or more specifically LANSA Web Event, doesn't support that because I can see we already have one of our languages set to fr as the ISO could and the pages still show numbers with period as the decimal. Since Web Event hasn't been enhanced since before version 14.0 upgrading won't resolve the issue. This makes me think the best plan of action which would give us the most control would be to use alpha fields in place of the numerics and add logic that reads/sets these alpha fields based on a local setting that we associate with the language and/or user or some other criteria. This way we get the flexiblity of defining what will make a number display in a certain way and can control the exact formatting that will occur. My only concern will be in some of our Javascript logic that does calculations on numbers. I will need to think about that.

What are your thoughts?

[BrendanB]

Casey,

definately, using strings with appropriate conversion logic will be easier...

Javascript does allow conversion (i had a WEBEVENT customer that insisted on numbers with thousands seperators -- which needed a calculation done on them...) so it may be that you need to do the conversion in javascript...

Code: Select all

const search = ',';
const replaceWith = '.';
const result = '100,55'.replaceAll(search, replaceWith);
// result;  => '100.55'

var number = parseInt(result);
// number; => 100.55  << do your calculations now...

so you should be able to handle that in Javascript. (noting that replaceAll will not work in InternetExplorer).

Brendan.

[caseywhite]

Thanks Brendan. I am going to pursue the Javascript approach. I think that makes the most sense.

[caseywhite]

Hi Brendan, I am looking at 2 possible ways to determine what the separator should be. One will be task the user to set it in their preferences in the app. The other is for the application to pick up the regional settings from the user's device. Below is Javascript that I have seen on various sites as tips. I tried going into Windows regional settings. I found the Number Decimal Symbol and changed it to ,. I rebooted by this code still returns a period.

Have you found a clean way to determine what the users regional settings are? We don't want to rely on the language. We want to let the user pick the separator. I think it would be cleaner to do it automatically by getting the device setting than asking the user to pick one. Our fallback would be to have the user pick their seperator.

function whatDecimalSeparator() {
var n = 1.1;
n = n.toLocaleString().substring(1, 2);
return n;
}

[BrendanB]

Casey,

personally no.

the Fiddle at https://codepen.io/diego-fortes/pen/YzEPxYw demonstrates determining a users Country.

I would think that if you know the users country, you can most likely determine things such as what language, date formats, decimal seperator etc...

That would seem to be the way most sites do it...

I would suggest that you could determine what you want to show, based on country -- and allow the users a way to change languages/features if required.

you dont get access to the 'regional settings' of the PC directly from a browser -- typically the TIMEZONE is all you get, so you would determine from that if there were other settings you want to change.

b.

[caseywhite]

Thanks Brendan. That makes sense. One of the business users wants the users to be able to override so I have proposed as you suggested below. We base it on what the browser tells us the decimal point is which will be based on language. If they user doesn't like that they can go to our user preferences page and select which decimal point character they actual want to use.