Force the default locale to have intTest working even if the default locale is not en_US

[jbonofre]

No description provided.

[adutra]

What is the issue if the locale is not en_US?
Don't we need this for test as well?

[dimas-b]

IDK about what JB hit, but in general String upper/lower case conversion depends on the locale even for the ASCII char sub-set

[dimas-b]

In other words, I'd prefer to have this setting fixed in the main server properties, not just in test.

Are there reasons to run the Server under a custom locale?

[jbonofre]

For instance https://github.com/apache/polaris/blob/main/integration-tests/src/main/java/org/apache/polaris/service/it/test/PolarisManagementServiceIntegrationTest.java#L366 and https://github.com/apache/polaris/blob/main/integration-tests/src/main/java/org/apache/polaris/service/it/test/PolarisManagementServiceIntegrationTest.java#L383 assumed the locale is en_US: it expects must not be null.

If the locale is not en_US, let say fr_FR, then the tests fail as we have ne doit pas être nul instead of must not be null.

Same failures can happen with any default locale not en_US.

[adutra]

OTOH, don't we want to have i18n in Polaris? French customers may be happier reading error messages in French. Setting the locale to en_US sounds very... US centric :-) Can't we adapt the tests instead?

[jbonofre]

@adutra that's a good point, but I think there's more work to do for i18n support. Maybe we can do step by step. My PR is only in the integration tests here. So maybe we can start by this and create an issue for i18n.

[dimas-b]

Also, we can fix string manipulation in Polaris code, but I would not be 100% sure about dependencies :)

[adutra]

There is definitely more work than just that to get good i18n, but OTOH if we carve the locale in stone as en_US, that's not a good start ;-)

[dimas-b]

True, I'm totally fine preparing for i18n 👍

Let's then fix the test or the related server code that fails in #885 ?

[snazy]

Question: Since quarkus.default-locale is a Quarkus setting, why no put it in application.properties? I suspect all servers should behave the same way - even on French systems ;)

[jbonofre]

What's our thoughts about this one ?

[flyrain]

cc @gh-yzou

[adutra]

What's our thoughts about this one ?

I would personally fix the test by making it resilient to other locales.

[dimas-b]

Do I understand it correctly that the test fails under some locale because the error message produced by the server running with that locale is not in English?

[gh-yzou]

It feels little bit wired to me that we are enforcing this setup for all tests, will we be able to set those up for the particular test points?

[dimas-b]

From my POV, this may be a signal of a bigger problem. If the server provides error messages (to be confirmed) in different language or chartsets depending on its locale, that would lead to a degraded UX from the client's perspective because clients (humans or programs) do not necessarily know the locale of the server and may run in a different locale. Let's confirm the basic server behaviour in this case first.

[jbonofre]

Quick sum-up on this one:

• PolarisManagementServiceIntegrationTest does assertions on REST response like response body should not contain foobar must not be null
• if the machine locale where the test is executed is not en_US, then the build is failing as the assertion is not valid: if the default locale is fr_FR, the REST response will be foobar ne doit pas être null instead of foobar must not be null. This is the same if the locale is not en.
• In this PR, I propose to just force the locale for the tests in the quarkus app

My intention is:

1. just to fix the test for contributors using another locale. It's possible to "square" to the specific PolarisManagementServiceIntegrationTest.
2. not to introduce any complex i18n or similar thing (that should be discussed (does it make sense yes or no)).
3. if you think 1 is not a good idea, another approach would be to clear document what's needed to have the int tests passing (like set your locale to en, with something like export LC_ALL=en_US

@gh-yzou @adutra @dimas-b @flyrain @snazy just to provide a kind of sum-up. Happy to update this PR with your advices.

[gh-yzou]

@jbonofre Thanks a lot for the summary! Just fix the particular test failure for now sounds good to me, and I think we should definitely have some discussion about how to move on for that i18n thing. Let's also see what does other people think here!

[jbonofre]

@jbonofre Thanks a lot for the summary! Just fix the particular test failure for now sounds good to me, and I think we should definitely have some discussion about how to move on for that i18n thing. Let's also see what does other people think here!

@gh-yzou thanks, let me update this PR to set the locale only for PolarisManagementServiceIntegrationTest.

[dimas-b]

Thanks for the explanation, @jbonofre !

Making tests stable in this PR in case another locale is default on the local machine makes total sense.

I'd personally take this one step further and actually set en_US as the locale in the Polaris Server by default. This is to ensure error messages do not change without the admin user's intervention just because of running on a different platform. The admin user should be able to set any locale for the server, if needed, of course.