3.1.3 Windows, locale number format not respected in UI

[Liggliluff]

Describe the bug
The number format in Audacity is based on the translation, and not the system settings. By default, number formats should be based on the system. I use English (Sweden) for proper ISO 80000-1 support, but setting Audacity to English gives me an improper number format, since it's based on British/American usage.

To Reproduce
Steps to reproduce the behavior:

1. Set Windows number format to a language such as German, Swedish, or English (Sweden)
2. Start up Audacity and set the display language to English
3. The number formats at the bottom of the screen (by default) shows up as "000,000,000 samples" and "00h00m00.000s" (hh:mm:ss+milliseconds)
4. See error

Expected behavior
Software in Windows should be using the number format of Windows unless there's a good reason not to. Audacity currently bases the symbols on the translation, which is not a valid reason. For consistency, accessibility reason and more, all number formats in Audacity should show based on what the Windows number format is set to.

Screenshots
Audacity number formats:

Windows number format settings:

Additional information (please complete the following information):

• OS: Windows 10
• Version: Audacity 3.1.3

Additional context
Good software design should take different locales into account. For example, English (Sweden) has the number format 000 000 000,000 and this format is as of now not supported by Audacity. By following Windows number format setting, a user can choose what they want as their symbols in any software that has proper locale support.

You can't make this based on translations, because you currently don't support English (Sweden) as an option, and users might have a valid reason to change how the symbols appear. For example, a user should have the option to change the decimal mark to • if they so choose to have a more visible symbol. In my case, I want to use a space as thousand separator since using comma or period is confusing, and I want comma as a decimal mark since it's a more visible mark than a period.

The Swedish translation is also incorrectly using format 000,000,000.000 when it should be 000 000 000,000 regardless, so I can't even get the ISO 80000-1 format by selecting Swedish as the language.

[petersampsonaudacity]

Given that Audacity has been the way it is since 1.2.6 at least right up to the present day 3.1.3 (and 3.2.0 alpha) using the setting that the user makes in Interface Preferences for Audacity's language setting to determine what format to to display numbers in with their separators - if this change were made to instead rely on the computer's locale then this could introduce an unsettling regression for many users.

So if Audacity were to have the ability to implement its number format based on locale, then this should probably be controlled by a new preference in Interface Preferences, say for example "Use locale not language setting for numerical separators".

And this setting should definitely be "off" by default, so the the current and well-established behavior remains as the default for users.

[Liggliluff]

@petersampsonaudacity

Given that Audacity has been the way it is since 1.2.6 at least right up to the present day 3.1.3 (and 3.2.0 alpha)

Irrelevant. Doesn't matter how long it has been wrong, it should preferably be corrected early on.

if this change were made to instead rely on the computer's locale then this could introduce an unsettling regression for many users.

Could you explain how? If a user prefers their numbers to be 1,000.000 they can set that in their system settings. It should be up to the user to choose their format. Audacity does not let the user choose as of now.

So if Audacity were to have the ability to implement its number format based on locale, then this should probably be controlled by a new preference in Interface Preferences

Sure, fine. As long as it can display numbers like most other software, it would be great. Forcing the wrong format on the user is not that great of a user experience.

And this setting should definitely be "off" by default, so the the current and well-established behavior remains as the default for users.

I strongly disagree on having the default be a well-established error. Users should have the option to opt-out of the bug fix. Not opt-in to the bug fix.

[LWinterberg]

Irrelevant. Doesn't matter how long it has been wrong, it should preferably be corrected early on.

Oh, it is relevant. If a behavior has existed for decades and you're the first person who reports it, it probably isn't a super high priority thing to change.

[Liggliluff]

I'd also like to add the point that most users are probably running Windows in English (United States), English (United Kingdom) or any other major English locale, and therefore uses the format 1,000.000 in Windows, and Audacity is using the format 1,000.000 so for all these users, if the setting is on or off doesn't change anything.

Then you might have a lot of German users, Russian users and more, who has both Windows and Audacity set to German, Russian, and so on. These users would also have the same format in Windows and in Audacity, so for all these users, it also doesn't change whether the setting is on or off.

It does matter for the users who use English (Sweden), German (Switzerland), or any other locale that doesn't follow the "default" language's format. These users therefore don't get their format in Audacity, and this setting would be beneficial for these users. I can't speak for these users and therefore have no idea if they prefer Audacity, unlike all other software, to use the wrong format. Having a setting is beneficial still, but most software don't, and just use the locale from the system.

[Liggliluff]

@LWinterberg

Oh, it is relevant. If a behavior has existed for decades and you're the first person who reports it, it probably isn't a super high priority thing to change.

The vast majority don't report bugs. The vast majority probably don't even have a mismatch in format between Windows and Audacity and therefore have no reason to report anything. I just happen to be the first.

[petersampsonaudacity]

And this setting should definitely be "off" by default, so the the current and well-established behavior remains as the default for users.

I strongly disagree on having the default be a well-established error. Users should have the option to opt-out of the bug fix. Not opt-in to the bug fix.

This is not a well-established error, or a bug, it is a design decision made by the originator of this application, Dominic Mazzoni, 20+ years ago when he first wrote it.

Note that I did not say that this should not or could not be done, rather I offered a solution which maintained current behaviors while offering an alternative prefs setting.

Note also that @LWinterberg (who is Mr. QA in Muse, the new Audacity owners) flagged this as an Enhancement Request and not a bug.

One important use case for using the Interface Prefs language setting has been QA testing of things like number format display in various languages. I did much of the QA testing of that for many years (semi-retired now) and whilst I was happy enough to test Audacity in a foreign language by resetting the language in Interface prefs, the was NO way that I would consider that by changing the locale on my PC and Mac. Resetting Audacity to English was (and remains) a simple purge of the Audacity settings folder.

[Liggliluff]

@petersampsonaudacity

I did much of the QA testing of that for many years (semi-retired now) and whilst I was happy enough to test Audacity in a foreign language by resetting the language in Interface prefs, the was NO way that I would consider that by changing the locale on my PC and Mac.

You are confusing language and format. You don't change language by changing the system formats. I also feel like your quality testing has been insufficient if you didn't test changing the system formats.

As a user who prefer using ISO standards, this is one of the struggles I have with software that don't support the system formats. I want ISO 8601 date format for example, yet there are software basing the date format on the language, and worse, only offers US English, with the backwards format. All this wouldn't be an issue for me, or anyone else for that matter, if software consistently kept using the system formats.

[SteveDaulton]

Following a recent thread on the Audacity forum, and a discussion on Audacity Dev discord channel, I'm in agreement with Liggliluff that Audacity should use Windows number format settings.

Language settings are not the same thing as number format settings, and there are good reasons why a user may need to use different number format setting from those that are traditionally associated with a particular language. One good example (provided by Wikipedia) is that several countries that use a comma decimal separator by literary convention, but use a dot as decimal separator for IT and finance - specifically it says that Switzerland uses a comma in handwriting, but a dot in government publications and finance.

Peter wrote:

it is a design decision made by the originator of this application, Dominic Mazzoni, 20+ years ago when he first wrote it.

I don't think that is true. As far as I'm aware, very old versions of Audacity always used a dot, irrespective of the locale. Looking at Audacity 1.2.6, there is no "System" option for language, and after testing a selection of languages, it seems that Audacity always uses a dot.

At some time later, a comma was added as the decimal separator for languages where a comma is thought to be the "official" number format style. In my opinion, the fact that this can conflict with the system's number format setting is a bug, or at least an inadequately implemented feature.

LWinterberg wrote:

you're the first person who reports it

That's definitely not true. It's not reported very often because the vast majority of Windows users never change the number format from what Microsoft decide is correct for their locale, and of those that are affected, only small proportion report the problem. However, the issue has been raised from time to time for many years.

I don't see this as a high priority bug, because it is relatively rare, but I do think that it is a bug and should be fixed.

[petersampsonaudacity]

I have been thinking about this a lot and I now agree with @SteveDaulton and @Liggliluff (the OP for this bug) that the number formatting should be based on locale (or what the user has set in their system settings) and NOT be based on the language set for Audacity.

---

A particularly interesting use case is Switzerland which has 3 official languages: German, French and Italian (actually 4 if you include Romantsch - though I doubt that may computers are set to a Romantsch locale somehow).

My understanding is that the German speaking part of Switzerland uses different separators to those used in Germany - so in this case basing the separators on "Deutsch" language in Audacity is fundamentally wrong.

I only have personal knowledge of the Swiss-German - but I suspect that the French speaking Swiss may well use different separators to that which the French themselves use.

[petersampsonaudacity]

Another interesting use case is the US which has two official languages: English and Spanish.

The US English uses period "." for its decimal separator, whereas Spain (and thus I assume possibly US Spanish) uses comma "," for its decimal separator.

[petersampsonaudacity]

And we do have some inconsistencies.

In Sweden they use comma as the decimal separator and space for the thousands separator - but if we change the Audacity language to Swedish (Svenska) we see:

Here we can see that in the effect comma is used as the decimal separator.

BUT inconsistently in the Selection toolbar the period is used for decimal separator - plus the thousands separator is a comma and bot a space.

However, I can recall of no Swedes ever complaining about this.

[petersampsonaudacity]

Another possible issue is German (Deutsch):

Here we see consistency with the comma used as the decimal separator in both the effect and the Selection toolbar.

BUT space is used as the thousands separator and not period (which is my understanding of German usage from Internet research). This came about because some releases back a German speaker complained about the comma usage and insisted that space was more correct and logged a bug in Bugzilla for this. Accordingly we changed it to be so - but now I'm not so sure that was the right thing to do.