GNOME Bugzilla – Bug 370331
Changing locale causes parsing errors in scheduled transaction due to changing decimal separator
Last modified: 2018-06-29 21:14:50 UTC
Please describe the problem: I have recently changed my locale from en_US to ca_FR. The last time I opened gnucash, an error popped because of a scheduled transaction. The transaction got created with a blank amount. In the transaction editor, clicking in the amount field then out popped the same error again. Steps to reproduce: 1. Create a scheduled transaction with the en_US locale. Save&close the program. 2. Restart gnucash on the cmd line with "LC_MONETARY=ca_FR gnucash". 3. Open the transaction editor. Click in the amount field. Actual results: The transaction editor protests. Scheduled transaction wouldn't get created correctly. Expected results: The monetary separator should adapt to locale changes, just like any amount entered in the register. Does this happen every time? Yes. Other information: There are two workarounds: 1. Replace the separator in my scheduled transactions, but this is not a permanent solution. If the monetary separator changes again, my scheduled transaction break again. 2. Stick with my monetary separator of choice by using the appropriate LC_MONETARY locale.
In bug#121740 Josh wrote "With respect to the decimal seperator issue, use the LC_MONETARY envrionment variable to control that handling apart from the language setting." and this very same bug has been reported as bug#120927 before. However, I'd agree that modifying the env variable doesn't seem like a good permanent solution to this problem. The permanent solution would be to save all numbers in a locale-independent format (or in a format of a known locale). However, that would require an additional parsing at each presentation time.
Dup-age. *** This bug has been marked as a duplicate of 170729 ***
Whoops. This is not a dup of 170729; this still affects manually-entered SXes.
*** Bug 626671 has been marked as a duplicate of this bug. ***
r19550 might fix this for newly entered scheduled transactions (in 2.3.16 or higher) which do not use any of the additional variables. That's at least something.
*** Bug 639101 has been marked as a duplicate of this bug. ***
Still a problem in 2.4.7
Christian: even simple transactions does not seem to work with r19550+ For example, new scheduled transactions created under 2.4.10 (r21973) are still broken in this respect - the transaction splits use current locale (which breaks if gnucash is run under different locale). For example, simple transaction for 57.60 HRK gets splits like this (note comma instead of dot): <trn:split> <split:id type="guid">5c9cef15f6a97893614da77caba9a8af</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>0/100</split:value> <split:quantity>0/1</split:quantity> <split:account type="guid">c3fa3e3dedac6d7427b8b8ea96ca7a5f</split:account> <split:slots> <slot> <slot:key>sched-xaction</slot:key> <slot:value type="frame"> <slot> <slot:key>account</slot:key> <slot:value type="guid">982d2fb750749ab2da067b9d940b0158</slot:value> </slot> <slot> <slot:key>credit-formula</slot:key> <slot:value type="string">57,60</slot:value> </slot> </slot:value> </slot> </split:slots> </trn:split>
Potential concept for solution: The core issue is that numbers in the formula are stored using the locale specific number format. When the locale number format changes between the time the formula is stored and the time it is read, this results in parse errors. One idea might be to store each number found in the formula in a locale independent format, for example based on the internal format gnucash uses for numbers (gnc_numeric): nominator/denominator, where both parts are integers (no decimal separators required). Possibly this representation should be wrapped with a unique marker to make it easy to see where numbers start and end, like for example: #nominator/denominator# Since this would create formulas that are incompatible with older versions of GnuCash, this should only be done in combination with a new features flag.
*** Bug 725171 has been marked as a duplicate of this bug. ***
I was also affected by this bug. Not only 200,00 but also 1 470,80 (so the space as thousands separator gave problems)
Bug still exist :( I am using version 2.6.18.
Note that users can apply Geert's proposed fix in comment 9 as a workaround: Write numbers in formulae as 20000/100 and 147080/100 instead of 200,00 and 1 470,80.
Thank you for the workaround, that's a good idea. Bug still exists otherwise.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=370331. Please continue processing the bug there and please update any external references or bookmarks.