Before we created a local-to-remote map that looked like this:
{"it-IT": "it", "it_IT", "it"}
And then, to create the remote-to-local map, we reversed it. The problem was that, since both values are the same, the key that ended up being selected was random, so it could either be:
{"it": "it-IT"}
or
{"it": "it_IT"}
To fix the issue, we now create remote-to-local first, going over the global configuration first and the resource-level configuration second so that the resource-level will prevail and thus take preference, and then we create the local-to-remote by reversing. So,
First, we will consume the global configuration:
{"it": "it-IT"}
Then, as the resource-level configuration is consumed, it will replace the old key:
{"it": "it_IT"}
And then, the local-to-remote will end up being:
{"it_IT": "it"}
This is the deterministic and the intended behaviour, since resource-level configuration should take precedence.
Consider this scenario: Someone has in their config file:
Before we created a local-to-remote map that looked like this:
And then, to create the remote-to-local map, we reversed it. The problem was that, since both values are the same, the key that ended up being selected was random, so it could either be:
or
To fix the issue, we now create remote-to-local first, going over the global configuration first and the resource-level configuration second so that the resource-level will prevail and thus take preference, and then we create the local-to-remote by reversing. So,
First, we will consume the global configuration:
Then, as the resource-level configuration is consumed, it will replace the old key:
And then, the local-to-remote will end up being:
This is the deterministic and the intended behaviour, since resource-level configuration should take precedence.