Setting hreflang language locale

Wow, seems like a big issue here, I am surprised that nobody brought it up until now. So, do we need to show locale in hreflang instead of language code? What do you have for locale? en_IE, en_CA, en_AU, en_NZ?

If we use locale, then it will look like this:

<link hreflang="en-IE" href="https://example.com/en/" rel="alternate" />
<link hreflang="au-AU" href="https://example.com/au/" rel="alternate" />
<link hreflang="ca-CA" href="https://example.com/ca/" rel="alternate" />
<link hreflang="nz-NZ" href="https://example.com/nz/" rel="alternate" />
<link hreflang="x-default" href="https://example.com/" rel="alternate" />

Two-letter language code, which is used to encode URL can be anything, there is no standard on how to encode a URL, as far as I understand, but “hreflang” should indeed go by the known standard for locale instead of using arbitrary two-letter code? I do not think the case matters, for example the source of this page shows lang="en-US" and q-X shows the locale configured on language edit page (https://w.marina.soutyrine.com/wp/wp-admin/options-general.php?page=qtranslate-x&edit=xx) in “lang” attribute as well (with ‘-‘ instead of ‘_’).

Could you research it a bit more and let us know on the best way for doing it? Would the above example for you be ok?

There is a few words on SEO in https://qtranslatexteam.wordpress.com/2015/02/26/browser-redirection-based-on-language/, which we probably need to update with the information in this topic too.

Thanks a lot.

The next version will have locale instead of language code in “hreflang”.

@john Clause,

For all languages? I think that is not the intention.

de: German content, independent of region
en-GB: English content, for GB users
de-ES: German content, for users in Spain

German content is with locale de_DE but maybe your solution is better

Yes – I also don’t think specific country locale is the best option. For some maybe it should be possible to select it – but in general sticking to simple language code is better (at least for me).

If you are however e.g. in Switzerland – and targeting Swiss users primarily – then de-CH and it-CH and fr-CH (or however they are called) would be better than generic.

I already hate the separation in Google Analytics – e.g. this recommendation is so Google can target regions better – but I don’t really understand why you cannot group and just use simple independent of region content (like en: international not English speaking only).

It looks like we need another option then? The current property of language named “Locale” must have a value coincided with WordPress locale in order for everything to work correctly on admin side. However, that one is not necessarily the best for front-end, so we will have to introduce “Front-end Locale”, the one to put into “hreflang” and in “lang”? Indeed it may also help to resolve some other issues reported by Chinese, Japanese, Taiwanese, etc. people?

so we will have to introduce “Front-end Locale”, the one to put into “hreflang” and in “lang”

I think this is a good idea.

Sounds good.

Thanks very much for considering my request. When do you expect this update to be released?

@angela_t

Soon, but for now you can download the latest Beta version of qTranslate-x Download it here

Do not use install via WordPress admin!
First unzip the new file.
Deactivate the existing version of qTranslate in WordPress admin.
Then with FTP delete all files in the existing qtranslate-x folder and after that copy all new files in it.
Activate qTranslate-x again via WordPress admin.

@angela_t, @extremecarver: The new option “Locale at front-end” is now available for testing https://github.com/qTranslate-Team/qtranslate-x/releases/tag/3.3.8

Please, let me know if you find any problems. Thank you.

Thanks @gunu, @john Clause: I’ve installed the latest version and it’s outputting nicely, although I’m not sure about that first line affecting SEO as the /en/ directory gets redirected to the root:

<link hreflang=”en” href=”https://example.com/en/&#8221; rel=”alternate” />
<link hreflang=”en-au” href=”https://example.com/au/&#8221; rel=”alternate” />
<link hreflang=”en-ca” href=”https://example.com/ca/&#8221; rel=”alternate” />
<link hreflang=”en-nz” href=”https://example.com/nz/&#8221; rel=”alternate” />
<link hreflang=”x-default” href=”https://example.com/&#8221; rel=”alternate” />

Regardless, this is a great improvement that should help a lot of users looking to use the plugin for localisation so thanks very much for your help with this issue.