Brand language when not logged in [bug or feature?]

[Luis]

I have Spanish (regular) enabled in a brand (only that language) but my browser is set to Latin American Spanish. I noticed that the customer store/front end shows in Latin American Spanish when not logged in, instead of the regular Spanish wich is the only enabled language.

Shouldn't the front end only use available/enabled languages instead of using the auto detected one?

Maybe this only happens with Spanish.

[Chris]

Hi @Luis – i've checked the brand you are referring to and can see that the browser is only loading in `es` language packs.

[Luis]

Hi @Chris

I did some tests and found these results:

- My browser has this language priority, being Latin american Spanish (es_419) the default.

 

I created a test product in order to test this.

If I browse the store being logged out from any customer's account, I see the price of the product and the label of the text using Latin american Spanish (notice the comma as thousand separator).

 

But when I log in to a customer (which has Spanish default language), I see the label changed to Spanish es_ES, but the amount remaining in the es_419 or Latin American Spanish format. Since in Spanish the five thousand should be 5.000 instead of 5,000

 

Just to clarify, I only enabled es_ES (or Spanish) language in this brand, and didn't setup Latin american Spanish in any way.

I'm using Chrome to test this.

[Luis]

Hi!

Any news about his?

[Chris]

Hi @Luis,

So, the FE logic is along the lines of this…

1. We collate an array of ‘preferred’ locales from various sources (searchParams first, then localStorage and finally the browser language). Note – the order IS important here.
2. We create an intersection to determine which of the preferred locales are supported at a brand level, when comparing the FIRST part of the lang code (eg. es from es-419).
3. We then use the first locale from this intersection

So, based on the following example sources `[fr (searchParams), null (localStorage), es-419 (browser)]` and the brand supporting `[es, en]` – the intersection would be `[es-419]` and we pick the first value from the array. If the array is empty (no matches) we fall back to the brand default locale.

This is why the `es-419` lang pack gets loaded even when the brand has only specified `es` support. We do this intentionally because it gives a better, more localised, experience for the end-user.

Separate from this, it looks like the API formatting of currency values might not be correctly honouring the passed locale code, which is why the price is not changing. I suspect formatting is being applied based on the currency only, and not the locale. We'll come back to you with an update on this issue.