I'm a little lost on the exact problem here. Ideally:
- Whenever Aurora is reading a string from the UI to transform it into a number in memory, it should use the culture of the computer where the software is running.
- Whenever Aurora is printing a number in memory to the UI, it prints it using the culture of the computer where it is running.
If the DB is storing some numbers as strings with a particular separator, then writing or reading those strings from the DB to a number in memory should be done with whatever culture the DB is expecting. This means that Aurora may need two different code paths to handle transforming between strings and numbers if the DB culture and the user culture are different.
The only problem would be if the DB has a number stored as a string, and then that goes directly to the UI without being transformed to a number in memory, or viceversa. Those cases would need to be changed so there's a middle transformation to a number so the correct culture is applied.
This is kind of where my understanding of the problem has got to. C#, by default, is doing everything localised. All the methods that transform a string into a number, or a number into a string, are all going to use the user's culture unless they are specifically told not to. So it should all be transparent to the developer.
The only way I can see these problems happening, are numeric string literals, hardcoded either in the db or the code, that are being put directly to the UI. Solving this would seem to be the way to fix it, rather that writing your own number parsing routines.
Or just stop C# from localising at all (which is the current solution, except the user is doing it manually by changing their system settings). Which I believe is pretty trivial, though I admit I've never done it. This article:
https://csharp.net-tutorials.com/working-with-culture-and-regions/application-culture-and-uiculture/Seems to suggest you can set the entire application's culture with a one-liner.