Vue-i18n: Default locale based on browser settings?

[miloandco]

As title says, I can't see anything regarding this in the docs. Am I missing something?

[oboshto]

const i18n = new VueI18n({
  locale: navigator.language,
  messages: {
    // your messages
  }
});

[kazupon]

In about it, @oboshto mentioned .
You can resolve it. 😉

[fungiboletus]

Shouldn't it be the default ?

[praetp]

@fungiboletus I would assume so...

[justice47]

For those who use 2-chars code of the language in i18n ('en', 'ru', etc.) you can easily translate navigator.language to that format via:
locale: navigator.language.split('-')[0]

[zolomatok]

The answer to this question is saying locale = navigator.language || navigator.userLanguage

Plus, it might be a good idea to clip the second half of the locale string as per justice47's comment.

[fjeddy]

@zolomatok Why would that be a good idea? Unless you used two characters from the get-go and destroyed the ability to actually support all languages and just support one single language per country.

[zolomatok]

@fjeddy Hmm, yeah fair point.
TBH I was just thinking of en-US and en-GB, since not many sites bother with that distinction, but you may be right, there could be countries where the distinction matters.

[zolomatok]

@fjeddy Although this is about dialects of the same language, not multiple languages in the same country. That’s still supported this way, since it’s the language tag you keep, not the dialect part.

[fjeddy]

@zolomatok You couldn't be more wrong, there are multiple countries, including my own, that has and use multiple completely different languages that have nothing to do with one another (As in, not dialects).

nb_NO
nn_NO
se_NO

In this case, nb and no are interchangeable, it's just the typing that's different (A dialect), but absolutely no one that speaks nb or nn will understand a word of what se is saying. As it is a completely different language within the same country. Norway isn't alone here, there are plenty of countries that have multiple, independent languages, France for one.

Edit: You're right, you keep the language bit so you wouldn't get around it. But you do indeed fuckup for variations of the same language. en-ca, en-us, en-gb etc, they all become one unified language (Which they really shouldn't)

Edit2: For those reading this later, there is absolutely no reason you should use just en or nb, go with the full representation and do en-US and nb-NO, doing otherwise will just create a headache the day you decide you need them.

[zolomatok]

@fjeddy

Yupp, I know that, that’s not what I was contesting.

The thing I wrote about stripping the second half of the string (“_NO”) doesn’t create a problem in this regard.

You are left with nb, nn or se and if your site supports that, you can switch to that language for the user. It doesn’t matter in this case, that the user’s country itself is Norway, what matters is the actual language.

[fjeddy]

Yes, you're right, there is still, just no need to do it this way tho. Do it properly or don't do it at all :P

[zolomatok]

@fjeddy

If you want to _store_ the locale, than sure, I agree, store the whole thing for sure.

But my impression was this is just a frontend question and the OP just want to check and set the language locally, without storing the value.

[fjeddy]

@zolomatok Not what I mean.

He is obviously storing and keep his own translations and language files as en.json and nb.json. Otherwise, it wouldn't be necessary to split it when defining the locale. If he made the language as en-US it wouldn't be a problem.

You create the languages with the full ISO code and write code to check if you have the exact language the user wants, then you check if you have the language code he wants, and if both of them fail, you fall back to default.

My point is merely; if he wants to support en-US and en-CA now, then he needs to rename and redo all his language files. Because it isn't supported from the getgo. And there is no reason it shouldn't be.