#3988 closed defect (bug) (maybelater)
Alter hreflang behaviour on plugin pages
Reported by: | jonoaldersonwp | Owned by: | joostdevalk |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | Plugin Directory | Keywords: | seo |
Cc: |
Description
When a plugin is / has been translated, we include hreflang tags to/from each translated version, on each page. This creates a 'matrix' of reciprocal tags between these pages.
We currently omit untranslated versions from that matrix.
E.g., because https://wordpress.org/plugins/bacon-ipsum/ is available only in English, this page features only itself as the x-default
value, and as the en
value.
However, https://es.wordpress.org/plugins/bacon-ipsum/ also exists - but because it has not been translated, it is omitted from the translation matrix. It also has a self-referential canonical tag, and so now competes with other localised pages for this plugin.
We should therefore include all versions/localisations of each plugin in the hreflang matrix, but, when a version has not been translated, we should alter the hreflang attribute to reflect this.
E.g., the hreflang value for https://es.wordpress.org/plugins/bacon-ipsum/ should be en-es - 'English for Spain'.
Change History (6)
#2
in reply to:
↑ description
@
6 years ago
Replying to jonoaldersonwp:
However, https://es.wordpress.org/plugins/bacon-ipsum/ also exists - but because it has not been translated, it is omitted from the translation matrix. It also has a self-referential canonical tag, and so now competes with other localised pages for this plugin.
Could we perhaps set the canonical location to the english variant when the localised variant doesn't have any content translations? If we were doing it all 'again' I'd probably have suggested having all non-translated URLs redirect to the main domain
I'm not too fond of the idea of marking these pages as en-$country
when it's a rosetta domain, but if it's really the only option to specify the content as being "different" than the w.org/plugins/ variant..
#3
@
6 years ago
Non-translated URLs shouldn't redirect, as that takes you out of your localised site/experience. That causes issues.
Canonicals (and removing the hreflang markup) is a possible option, but, not as technically correct as the hreflang markup I've suggested. These are the localised equivalents of the EN-US versions (and should be marked up as such); they just happen not to be translated into the relevant language.
If we want users to find the right content in/for the right sites, we need the hreflang approach. Otherwise, users in Spain will find, and end up in, the US site rather than the ES site.
What's the objection against adding the en-$country
markup?
That can be tricky. Let's say we go ahead and create the (requested) locale es_US.
Now if a plugins readme hasn't been translated to Spanish (US), the fall-back would be en_US, which coincides with another locale.