I have an issue with the default locale setting and an @TextToNumber formula.
We run Domino 6.02CF2 on W2K (standalone, not as an NT service).
Problem: I want to be able to display dates and numbers based on the user’s browser accept-language, but I don’t want server-side formulas to evaluate numbers differently because of different user settings in the browser.
The server locale is NO (Norway). The decimal sign for this locale is a comma.
Problem example: a dropdown list named Type has a value of “S2,5”. I want to convert the last part of the string and store it in a computed number field using:
@TextToNumber(@Right(Type;“S”))
This should yield the number 2,5.
However, if my user’s accept-language is unknown to the server or of a locale that use a period as decimal separator (such as en-US), the server uses a period as decimal separator when evaluating the formula, truncating everything from the comma onward and returning the number 2 - which is obviously not what I want.
The solution is of course to set the default regional locale to “Server locale” in the Web engine settings. However, then all dates and numbers will be displayed using the server locale, even for users with, for example, en-US settings. Since we have users from all over the world, this is not desirable either.
A workaround is to keep default locale on browser’s accept-language, then evaluate the result of the string conversion first, and then re-evaluate it with a different decimal sign if the first conversion dropped the decimals. This is a sort of kludgy hack though, and lots of work when applied to many fields/databases.
So the basic problem is that using the user locale setting affects more than the display of data, it affects server-side calculations as well. I would like the server to compute the formula above using server locale settings, and rather apply the user’s locale settings ONLY when the results are displayed.
Is this intended behavior, or new behavior for R6? If so, it seems counterintuitive. I can’t recall having run into a similar problem on R5.
P.S. it also seems that Domino either has the wrong settings for some accept-languages (such as nn-NO) or either doesn’t recognize them, applying default U.S. settings instead.
Daniel Arnrup
SIU, Norway