Its emerged that including language links in the page HTML is useful for SEO purposes.
The reason a change is required on our side is that Google is **transitioning to a mobile first indexing crawler**. While the desktop site will still be crawled, mobile will be the default. While our mobile pages include a canonical URL to the desktop site, the mobile site will still be the primary source.
Currently on mobile language links are hidden inside an overlay, so to respond to this we'll need to add markup in the mobile site, to allow discovery of these pages. For that there are two options:
1) Using link[hreflang] tags (Google's preferred and recommended solution)
2) Include a[hreflang] tags in the page. Google has confirmed that even though the `a[hreflang]` elements we use in desktop are non-standard, they work and will be crawled if present.
We clarified that it is enough for the mobile site to link to desktop URLs.
That leaves us with 2 options to consider
# Solutions we are considering
## Option 1 - We change mobile HTML
This does not impact [[ https://wikitech.wikimedia.org/wiki/Performance/Guides/Frontend_performance_practices#Size_of_HTML_payload | the first 14kB of HTML guideline from the performance team ]] so should not have any negative effect on page load. However, since this is non-standard there is no guarantee this will work for all search engines and will work in future.
Patch: https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/879607.
## Option 2 - We change both mobile and desktop HTML to include the language links in the HEAD.
This is likely ill-advised by the performance team given their guidelines around [[ https://wikitech.wikimedia.org/wiki/Performance/Guides/Frontend_performance_practices#Size_of_HTML_payload | the first 14kB of HTML ]] but perhaps this is a special case (it's not clear from the text if this is a non-starter or open to compromise) - The guidelines from the performance team specifically warn against this under "Reduce amount of per-page header bloat" and for well developed articles this could be considerable. Web team will do some analysis to identify what the average number of languages is for an article, and also look at the top 100 articles to get a sense for the average HTML bloat this would add and whether this would clash with the 14kb guidelines.
Patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/891919
# TODO
[] Identify how many language links exist on the average Wikipedia page.
[] Identify how many language links exist on the most read Wikipedia page's (use the top 100 for a given day to get a rough sense of this value)
[] Quantify the impacts on page HTML payload for options 1 and 2
[] Quantify the impacts on the first 14kb of HTML payload for options 1 and 2
[] Run synthetic tests on 1 and 2 to identify impact on first paint and other key metrics (if any)
[] Once we've done the above analysis we plan to summarize and put forward a recommendation about what to do here. Identify the tradeoffs to consider based on performance measures.
[] Inform the performance team (performance-team@wikimedia.org) of our decision
# Proposal notes
## Option 1
[] Add languages to the footer of the page and hide them by default
[] Change links to languages to point to the new fragment identifier
[] When the fragment identifier is the target using the :target selector display it
## option 2
[] Check there are link tags in the HEAD of the article
## Sign off steps
[] If needed, create a ticket for updating MobileFrontend to avoid use of Special:MobileLanguages, and avoid API request for languages given they are now in the page.
[] Decline T104660 pointing to this ticket and SEO recommendation around best practice here if necessary