tname_i18n_order test sets language to system language instead of English

[mqrause]

Describe the bug

13:47:15.744 INFO : Setting language to: 'ru'
13:47:15.745 INFO : [i18n] Scanning core translations from lang/mo/
13:47:15.837 INFO : Setting language to: 'de'

This causes all subsequent tests that compare translated strings to fail.

On top of that, even if I force the test to set the language to English, the math_parser_parsing test will generate failures if it is run after tname_i18n_order. It passes when run on its own.

tests\math_parser_test.cpp(97): FAILED:
  CHECK( testexp.eval( d ) == Approx( 2 ) )
with expansion:
  0.0 == Approx( 2.0 )

tests\math_parser_test.cpp(129): FAILED:
  CHECK( testexp.eval( d ) == Approx( 87139.7243098 ) )
with expansion:
  -394.0162907268 == Approx( 87139.7243098 )

tests\math_parser_test.cpp(135): FAILED:
  CHECK( std::isnan( testexp.eval( d ) ) )
with expansion:
  false

Also maybe bonus issue: \data\mods\TEST_DATA\lang\mo\ru\LC_MESSAGES\TEST_DATA.mo isn't compiled when building tests with Visual Studio. But I also didn't manage to run compile_mo.sh and instead just made MSYS2 compile languages for me, so it might just be a me issue. Compiling tests in MSYS2 does compile the file as expected.

Attach save file

n/a

Steps to reproduce

Run .\Cataclysm-test-vcpkg-static-Release-x64.exe tname_i18n_order,math_parser_parsing,item_name_pluralization for example on a system with a different system language than English? German in my case, which might be relevant for the math parser issue.

.\Cataclysm-test-vcpkg-static-Release-x64.exe tname_i18n_order,math_parser_parsing,item_name_pluralization --order lex on the other hand will pass.

Expected behavior

Tests pass.

Screenshots

No response

Versions and configuration

3173580d8ac5662aec5add59b751301e7058e0bc

Additional context

No response

[PatrikLundell]

I've recently (a few days ago) seen the math_parser_test failures when trying to run tests locally. My system is only partially set to English (I think various conventions are set to the local ones, as well as the keyboard, while the language UI as such is set to English).

[andrei8l]

This causes all subsequent tests that compare translated strings to fail.

Pass --option_overrides=USE_LANG:en to the test binary. There are at least two other tests that depend on default settings and I always have to use --option_overrides=24_HOUR:12h,AUTOSAVE:true. Alternatively, just change from set_language_from_options() to set_language( "en" ). Not sure on the correct approach; I'll leave it up to you.

On top of that, even if I force the test to set the language to English, the math_parser_parsing test will generate failures if it is run after tname_i18n_order

I can't reproduce this. The math parser sets locale to classic before parsing and there's a specific test for that too. Additionally, tname_18n_order doesn't change locale so I'm not sure what could go wrong there. I need more info or specific reproduction steps. It could be a platform-specific issue.

[andrei8l]

I've recently (a few days ago)

Can you bisect please?

[mqrause]

Yeah, set_language( "en" ) was what I tried, but then ran into the math parser issue, which led me to believe there's a bit more going on that I don't understand. My best guess is that it's still using swapped decimal and thousand separators, though I'm not sure why and at what point that'd swap. That could explain why "-1 ^ 0.5" is a number (0.5 read as 0 or maybe 5 instead), but I can't really explain why "clamp( 1, 2, 3 )" fails but "max( 1, 2, 3, 4, 5, 6 )" succeeds. I'll probably have to step through it to see what actually happens.

Not sure I can offer better reproduction steps. I tested on regular German Win 11, and the language switching from tname_18n_order is necessary to cause the failure, that's really all I have right now.

[andrei8l]

but I can't really explain why "clamp( 1, 2, 3 )" fails but "max( 1, 2, 3, 4, 5, 6 )" succeed

Yeah, the errors indicate that parsing is broken somehow rather than this being a locale issue. I still can't reproduce it though, even with ASan/UBSan. I'll wait for bisect or whatever you can find.