Hi all
I am following Appian standard in using a text field on a form with which to populate a decimal field in my rule input.
Appian standard behavior for a decimal field is that if a comma symbol is used to indicate a decimal place, the symbol is automatically removed and the value is then displayed with no separation.
Example:
The user enters 650,52
On refresh, the comma disappears and the value saved in the rule input is now 65052
If one uses the period symbol, the value is displayed correctly, thus 650.52, and the value is saved correctly into the rule input
We cannot assume that the target group of users will understand the distinction between the symbols, so we need to put in some sort of validation in order to avoid the issue.
I have tried using the cleanwith() function, but am unable to make it work.
I would like to be able to do one of the following (in order of preference):
Any help will be greatly appreciated!
Discussion posts and replies are publicly visible
Out of curisoity, have you verified this behavior with a user account whose Locale is set to one that would use the "comma separated decimal" convention? Because I wonder whether you're trying to re-invent the wheel here.
Thanks, Mike
Unfortunately it's not that simple in my case - I am in South Africa and there is a lot of confusion around the correct separator use - see below from limn.co.za:
"Technically speaking, the official format for numbers in South Africa is spaces for the thousands separator and a comma for the decimal mark. The American variation that we had become used to is commas for the thousands separator and a full stop for the decimal point."
confusion reigns as a result....
Understood. I think this would (also) be a perfect use case for things like the Instruction and/or Placeholder text.
Thanks Mike, I would have used the placeholder or instructions option but in many cases our target user group has English as a third, fourth or fifth language.
AFAIK the "proper" solution for this is a strong internationalization setup, providing alternative language versions of the same forms / field names / text values on existing forms, though I must admit I haven't yet had the chance to design or maintain a system with a robust multi-language setup like this so I'm not very versed in what all needs to go into it to do an initial setup.
I would look at that but this country has eleven official languages :-)
I don't suggest you try to cover ALL possible languages - but having more than one option (like by cherrypicking the one or two most common alternatives) would still possibly be better than no options. And once you've figured out how to flexibly implement a small number of alternatives, it'll likely get a lot easier to gradually implement more options, if and when the need arises.
My immediate thought in that case would be to find 1 or 2 that are especially common for the purpose of a lingua franca for the country. It might be English, which is becoming the lingua franca of the whole world. Then there's the question of how British or American do you get with the English.
You've got a nice can of worms here.
Thanks Mike
A bit beyond my skill level and our deadline at present, but definitely on the agenda down the line.
Thanks for your input, and have a great weekend!