Make app culture-specific to make data more portable and UI more readable

[ghost]

Description

Certain parts of UI are illegible with it's current culture-neutral behavior or results in broken data. This is important for cultures/locales where comma instead of period is used as decimal separator.

UI example

With Polish culture set globally on windows, Output Merger Blend Factor becomes "0,00,0,00,0,00,0,00" instead of "0.00, 0.00, 0.00, 0.00" which is much harder to read.

Data example

With (again) Polish culture reported by Windows, exported CVS looks like:
0,00,1,00,1,00,-1,00
Instead of:
0.00,1.00,1.00,-1.00
This makes it harder to import data into e.g. Excel.

Suggested solution

Application.CurrentCulture = new System.Globalization.CultureInfo("en-US");

Somewhere prior to Application.Run() call in AppMain.Main().

American locale are bonkers when it comes to dates, but other than that it should be safe enough to use and would make data exported with RenderDoc portable.

[baldurk]

I might do en-UK since it's less bonkers with dates and I'm biased 😄, but this sounds reasonable at least as a short-term fix.

Do you think it would be useful to have the UI properly localise? I have no ability to translate any of the text elements but I can at least try and follow correct behaviour for things like formatting numbers. Living in an english-speaking country I'm not sure if it's generally expected that programming tools will localise correctly, or stay consistently english. For CSV I guess it should stay with . as decimal separator for practical purposes but the blend factor could e.g. be separated by -s or /s or whatever makes most sense.

[ghost]

I think that complete localization is fairly useless for highly specialized tool like this one. Problem highlighted in this bug is pretty hard to solve: e.g. for the Blend Factor case you'd need a custom format string for various locales to change comma into semicolon (that's what Excel uses for CSV export). But this doesn't solve the portability problem. And what do you do with RTL languages? Localization needs a lot of testing. And that's a lot of effort that could be spent elsewhere (e.g. on correct DPI support, which is a beast to tackle in itself).

There may be markets where proper localization matters. Japan perhaps? Some tech companies have development centers in Japan specifically to address market's needs (localization, documentation, support). But I guess you could take a look at the traffic numbers to see if Japan matters to you at this point.

That'd be my 2c. ;)

[baldurk]

Fair enough! I'd tend to agree, and like you say this is a fairly specialised tool, not intended for mass market use, so the value-per-effort ratio is pretty poor. I just didn't want to be guilty of slapping a quick fix over a problem that will cause serious annoyance for people using it!