Matching browser language only matches exact subtypes if browser specifies one

[CherryDT]

Following situation: Website has languages en and de. Matching with browser language doesn't work as one would naively expect: I always got the default language.

The reason this is the case is because the browser was sending de-AT on one test device and en-us on the other, and neither matched with plain de or at.

Looking at the code in vendor/willdurand/negotiation/src/Negotiation/LanguageNegotiator.php I see that this can never work in a sensible way unless the browser sends only en/de, because the logic seems to be: Base-part match is only ignored if browser sent *, sub-part match is only ignored if browser sent nothing.

In order for this to work, we would need to create a multitude of languages matching all compatible subtypes: de-de, de-at, de-ch, en-us, en-uk, ... which is not feasible.

In my mind, it should also ignore the sub-part match if the page language option doesn't have one (and the base part matches), maybe with a lower priority then a language option with actually matching sub-part. Then it would work with en and de as well as with de (matching all of de-de, de-at, de-ch), if we wanted, for example.

I solved my immediate issue by a patch in the LanguageNegotiator.php, but I didn't create a pull request for that one because I wanted to have it discussed - maybe there is a better way I'm overlooking?

[rhukster]

I need to look at this because the whole point of that LanguageNegotiator class is to negotiate the closest match to the requested language. And by that account, it would match de-AT to the de file you have available. I did some extensive testing of this before implementing it, and I'm sure I tested this type of scenario. I need to run or create some more tests to find out what's going on.

[CherryDT]

Thanks!
It seems that the opposite is happening right now: If the browser were to request de, it would match a file de-AT as well as de...

[rhukster]

Did a test of this.. Using the mutlilang-site skeleton package (untouched as it provides a variety of languages), then setting my browser to de-AT for the preferred language, then going to the root of my site, it did automatically send me to the correct de translation:

I also tested a different default language by making es default, but it still sent me to my preferred language first. So seems to be working as expected for me.

Perhaps its browser related? If you are using IE, can you try Chrome instead to see if it makes a difference?

[CherryDT]

I was using Chrome.

This was the behavior I was observing during debugging (look at my comments):

(well, the parameters are not strings, but still.)

[mahagr]

@ricardo118 Did you run into this, too?

[ricardo118]

@mahagr @rhukster indeed i have several reports of this. Like Cherry mentions its the subparts that are no longer functional. Thing like es-ca wont get detected. I've also noticed some inconsistencies regarding capitalization. if you have for example pt-BR and the browser sends pt-br, it was not always matching properly.