In our current installations running under Plack, the amounts on the pay and paycollect pages suddenly started showing with a decimal comma instead of a decimal point. This causes quite a bit of trouble, as Koha expects a . and amounts entered didn't result in the expected payments. We got several reports about payments being broken in Koha. Test plan: - Add manual invoice - View the "fines" tag - Verify that individual fees and totals display with , instead of . - Pay selected or any amount - Verify that the input field for the amount is also showing the , - Verify that paying something like 1,10 doesn't work as expected. The problem with the test plan is, that you might not see the ,. This appears only on our productions servers, but not in my development environment. We tested: - different language settings in Koha - different language settings in the browser - verified that CurrencyFormat isn't used in the code on those page - verified that all the formatting done was using the TT filter format('%.2f') In the end the problem turned out to be related to Plack.
The 'comma problem' started on our production servers after we have enabled Plack. It seems that the CGI version is using locale C whereas Plack is using the default locale of the server. After we have chosen None as our default locale, the decimal point was back again (partly a reboot was required). Apart from this, the default locale None is also recommended here: https://wiki.debian.org/Locale
Hi Katrin I tried following your test plan doing the following, on the latest version of Koha * Turning on plack * Creating a manual invoice with the value 10.00 * Going to the fines tab and observed both the individual fine and the total were displayed with . i.e. 10.00 not a , Therefore I am unable to replicate this test plan
Hi Alex, this is not easy to reproduce as it depends on the environment/Plack configuration (see comment from my coworker Ulrich). It's real, but not sure if a patch can be written to fix it. We thought it would be good to write up our finding in case another library runs into this.
So, if you fix some variables: - browser, - browser locale - settings in Koha then if you switch the locale and restart plack the behaviour change?
(In reply to Tomás Cohen Arazi from comment #4) > So, if you fix some variables: > - browser, > - browser locale > - settings in Koha > > then if you switch the locale and restart plack the behaviour change? Yes. We have seen this happen twice - we fixed it, we lost the setting in Plack... we fixed it again. I know it sounds strange, we were a bit puzzled as well.
(In reply to Katrin Fischer from comment #5) > (In reply to Tomás Cohen Arazi from comment #4) > > So, if you fix some variables: > > - browser, > > - browser locale > > - settings in Koha > > > > then if you switch the locale and restart plack the behaviour change? > > Yes. We have seen this happen twice - we fixed it, we lost the setting in > Plack... we fixed it again. I know it sounds strange, we were a bit puzzled > as well. The only thing I can think of right now is that Plack is smart and imports the env locales settings. And I bet some of our libraries for handling number representations, like TT, is picking that. So we should be hardcoding the 'no-locale' setting.
Sounds plausible.