[GNC] Cut and paste does nothing if number formats don't match

[John Ralls]

That’s more like the IBWM tried to set a standard and nobody listened. Customary ways of writing numbers go back centuries and aren’t likely to change because some obscure international organizations publishes a “standard”.

This isn’t strictly a GnuCash problem. Keyboards emit key symbols and the low-level software (in GnuCash’s case glib) converts the key symbols into a character code and the character codes are collected into a text representation called a string. Copy-and-Paste operations involving text also transfer strings. To get a number then the program must convert the string to a number, and if the number has thousands and decimal separators then the simple way to parse them is to use the current locale’s separators and to reject strings that don’t parse into numbers that way.  Even ICU, the reference standard for localization libraries (both Apple and Microsoft use it, suitably renamed, for their OSes) requires a locale to parse numbers from strings. It’s possible to try parsing the string according to each locale until one gets a reasonable result but it’s not possible to be sure that reasonable is the same as correct. 

GnuCash has always taken a simplistic approach to localization—we mostly use POSIX localization which admits only a single locale at a time—and numeric parsing is simplistic too.

Regards,
John Ralls


> On Aug 9, 2025, at 07:14, Paul Kroitor <paul at kroitor.ca> wrote:
> 
> I've gone a bit down the rabbit hole on this and learned that in fact the international standard* separator for digit groups is the "thin space", and it's English (apparently plus most of the other languages) that has gone AWOL here. And it's been so since 1948 (and reaffirmed in 2003).
> 
> I suspect this may all stem from Napoleon and his implementation of the Metric system combined with the French use of spaces as separators.
> 
> Who knew?
> Paul
> 
> * At the International Bureau of Weights and Measures, which includes the SI, the official definition of the metric system.
> 
> 
> On 2025-08-09 9:56 a.m., Paul Kroitor wrote:
>> Hello all,
>> 
>> Afaik lots of locales use spaces to separate thousands, including common ones like French. See https://randombits.dev/articles/number-localization/locale-list.
>> 
>> Apparently there are several different Unicode spaces (no-break space, narrow no-break space, etc) which are specifically used depending on the locale.
>> 
>> Paul
>> 
>> 
>> On 2025-08-09 9:27 a.m., David Carlson wrote:
>>> Graham,
>>> 
>>> There are certain data fields that that have somewhat quirky behavior, but
>>> the only one that has bothered me are the value fields in the transaction
>>> register where, for me, if I inadvertently insert or omit an intended plus
>>> or minus sign or if commas or periods do not comply with the definitions in
>>> my locale, then I get a surprise, usually a very different value than the
>>> value that I intended to insert.  This actually seems to be about the same
>>> as what you describe, except that I usually find an easier recovery than
>>> the methods you use.  As far as I know, at least up through release 5.11 of
>>> GnuCash there has not been any change to that behavior.  In your first
>>> sentence you use the word locale with an example that doesn't seem to be
>>> the difference that I might expect, eg swapping the comma and period in
>>> numbers depending on which country GnuCash thinks I am in.  For me, a space
>>> is always a separator between two different numbers.  I wonder if that is
>>> the source of your confusion.
>>> 
>>> On Sat, Aug 9, 2025 at 3:16 AM Graham Leggett via gnucash-user <
>>> gnucash-user at gnucash.org> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I have various statements with locales all over the show, for example
>>>> "1,234.99". Gnucash wants the figures to look like "1 234.99".
>>>> 
>>>> In the past this hasn't been a problem (other than the annoyance), as I
>>>> could correct the format in the register after a cut and paste, however now
>>>> cut and paste no longer works - specifically the paste is ignored.
>>>> 
>>>> What does work, which is more annoying, is to cut and paste to an
>>>> intermediate location like a text editor, edit "1,234.99" to "1 234.99",
>>>> and cut and paste a second time. Now the paste works.
>>>> 
>>>> Is there a way to switch this behaviour off?
>>>> 
>>>> Regards,
>>>> Graham
>>>> -- 
>>>> 
>>>> _______________________________________________
>>>> gnucash-user mailing list
>>>> gnucash-user at gnucash.org
>>>> To update your subscription preferences or to unsubscribe:
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>>> -----
>>>> Please remember to CC this list on all your replies.
>>>> You can do this by using Reply-To-List or Reply-All.
>>>> 
>>> 
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.