Sorry for the late reply here. The current implementation is approved from our side, in terms of both product and design. That said, deploying to production would probably take some time - we'd have to consult with communities and make sure the change is accepted overall, we'd also have to do some detailed QA across projects and identify which projects this makes sense going out to. I think that's where the feature flag @Jdlrobson mentioned plays in. From our side, MVP is okay, but we still have to do some due diligence prior to deployment and, as we're currently focused on desktop improvements, it might take us a bit of time before we get to it.

@Krinkle is there a clear point person/team for who will review https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/513234/
Given it touches the parser output, I'd be keen for the parser team to own the review/merging of the core patch. Once it's in per @ovasileva we can arrange rollout. I'd really like to see this move forward in some way.

@Jdlrobson I don't see my concerns/questions from T18691#6033238 addressed. I think that's needed before we can move forward with the RFC, let alone its implementation or rollout.

Generally relevant: on Hindi Wikipedia there is a share feature located next to the article title

Here's an example of why this is a good idea: https://www.theguardian.com/commentisfree/2021/nov/09/europe-must-seize-this-chance-to-help-restore-democracy-in-hungary (archived version: https://web.archive.org/web/20211109195209/https://www.theguardian.com/commentisfree/2021/nov/09/europe-must-seize-this-chance-to-help-restore-democracy-in-hungary) links to the section edit URL https://cs.wikipedia.org/w/index.php?title=Demokratura&veaction=edit&section=5, presumably because someone assumed, no unreasonably, that right-click and "copy link URL" would get a link to the section.

Apologies to Nemo Bis who saw it!

It should be noted that while these work:

• https://cs.wikipedia.org/w/index.php?title=Demokratura&veaction=edit&section=5
• https://cs.wikipedia.org/w/index.php?title=Demokratura&action=edit&section=5

the following does not work nor refer to the same thing:

• https://cs.wikipedia.org/w/index.php?title=Demokratura&action=view&section=5

but rather one has to use something like:

• https://cs.wikipedia.org/w/index.php?title=Demokratura&action=view#Pou%C5%BEit%C3%AD_pojmu_v_%C4%8Cesk%C3%A9_republice
• https://cs.wikipedia.org/wiki/Demokratura#Pou%C5%BEit%C3%AD_pojmu_v_%C4%8Cesk%C3%A9_republice

I realize URL fragments are handled in the client-side browser and although it is possible to have "action=view" support a "section" causing a redirect to the correct fragment, this is probably a poor idea as adding any intermediate heading would then break these links. This is precisely why edit links should not be bookmarked (and why adding "section" to "action=view" is not useful).

I bring this up because the edit links are stylized in a certain way and proposal 2 wants to add to these but the semantics are completely different (and why I liked proposal 1 better—despite its other issues that caused it to be rejected).

And while we are on the subject, there is also the issue of how to share anchor links that are not subject headings. Will this code also provide for that. I know many Wikipedia pages that have sections that have changed names many times (often with longer descriptive headings) but they also have succinct anchors to the sections allowing links that change considerably more slowly. Redirects often used these anchors instead of the section names.

If we are going to encourage external links to sections, I recommend we also encourage external links to editor created anchors (e.g., those created via Module:Anchor or Template:Anchor ).

In T18691#7502596, @Uzume wrote:

If we are going to encourage external links to sections, I recommend we also encourage external links to editor created anchors (e.g., those created via Module:Anchor or Template:Anchor ).

That doesn't seem feasible, and it's outside of the scope of this task

In T18691#7502612, @Ciencia_Al_Poder wrote:

That doesn't seem feasible, and it's outside of the scope of this task

I never suggested such was feasible or in scope, however, I do think it deserves a discussion point as the reason for wanting such external linking is actually even larger for editor created anchors than for sections. As such, they help define the problem here and possible arguments for or against the proposals here.

This is important and would be very useful. Could you please add this asap?

I can't believe this has been proposed in 2008 but still hasn't been implemented – if there are some unsolved caveats and issues with it, why don't you add a simple preliminary version of it now right away? Any minor problems can still get solved later, at least the user then have this basic functionality.

Currently, most similar websites have such a feature. I support Proposal #1 which is what I'm referring to here. To see how it can look like see this example (hover over or tap-and-hold the section header and see the § on its right or left) or any Github readme.

This would be especially useful needed on mobile where one doesn't have a TOC. If one wants to share a section link on mobile (most readers), which is very useful and common, one has to (most readers on mobile don't know this):

1. make the mobile Web browser show the desktop version of the page and then
2. manually remove the m. from the url and
3. press-hold the very small section header in the TOC to copy the link

In T18691#9034663, @Prototyperspective wrote:

Currently, most similar websites have such a feature. I support Proposal #1 which is what I'm referring to here. To see how it can look like see this example (hover over the section header and see the § on its right or left).

How do you hover on mobile? Which design do you expect for Proposal #1 from mobile devices?

Press-and-hold tapping as described in step 3; edited.
A § appearing next to the section header that you can press and hold to copy the link (preferably on the left). This is implemented (since quite a few years) for readmes (markup language) on GitHub.

“tap-and-hold” may trigger other actions depending on browsers (e.g. contextual menu, text selection…)
GitHub uses @media (hover: none) .icon { visibility: visible !important; } to ever show icons which are only showed while hovering on desktop.

1 - Note: I noticed there's a new extension which relates to this task. It does not solve it, but is of interest.
It doesn't help us, because it has a built-in feature that makes Clicking the link immediately copy it to our clipboard, which I know is not wanted by many people (because it unexpectedly overwrites whatever was currently in our clipboard).
Basic docs: https://www.mediawiki.org/wiki/Extension:SectionAnchors
And more details on the 3-types of click (click, ctrl+click, and ctrl+shift+click) feature, at https://en.wiki.bluespice.com/wiki/Reference:SectionAnchors#Features

2 - @Prototyperspective We tried a simple version in 2015, but there were significant problems and edge-cases (summarized in the Description under proposal#1), plus some people strongly dislike any moving/changing-elements in a webpage as they scroll so there were widespread complaints.

3 - Relatedly, I've now overhauled the "Open questions" section in the wikipage ( https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#Open_questions ), and that's probably the best place to record all objective details about the options and their pros/cons, rather than here where they get scattered (and emails are sent to ~100 people each time).
Hope that helps!

@Pols12 Yes exactly, what I referred to is how to make the context menu show up on mobile where one can then copy the link. On Github readme this is also on mobile, if you test this. Maybe one can make the section link get copied automatically when one press-holds the section header on mobile but I meant showing the context menu of the section link.
Note that all of this should also be possible in the mobile app, not just in mobile Web browsers.

@Quiddity 1. Great but even stranger that it hasn't been implemented by now: maybe you could just use that extension code.

2. These problems can get solved or if too complex get solved after it's rolled out due to being minor. "The element was visible by default" is an understandable major problem but I suggested the § is only shown at hover (you could even require a 1 second hover) just like most websites have it by now. There will always be some niche largely unjustified complaints even for the best, most needed, externally widely established (e.g. GitHub), community-wise heavily supported changes.
3. That is linked only as "Other variations of this proposal..." above. For deliberating, voting on and aggregating Pro/Cons of options, Kialo can be very useful at some point but currently requires users here to sign up first rather than logging in with Wikipedia credentials.

In T18691#9034663, @Prototyperspective wrote:

This would be especially useful needed on mobile where one doesn't have a TOC.

This is a very sensible petition.

With the collapsible sections of MobileFrontend, it may help if uncollapsing a section, the anchor gets added to the URL automatically (without affecting scroll). There's a JavaScript api for that implemented by browsers, that also doesn't add entries to the browser history. It can also update the anchor in the URL automatically when scrolling, to the section heading placed at the top of the viewport. However, this has the problem that, sometimes readers won't want to link to a specific anchor, or the correct anchor is not correctly guessed.

Ran into this in compiling a newsletter this week. :) Only realized on finding this ticket that someone has had such good + quantified success. https://phabricator.wikimedia.org/T18691#6019615

@Quiddity what's the current status? (or feel free to comment on the RFC talk page)

Current status is that nobody is working on this. The first attempt was reverted 9 years ago (reasons: T18691#1098570), the second one stalled 5 years ago (not sure why, it looks like it got bogged down because people tried to turn it into RFC and MediaWiki RFCs were dysfunctional at the time and then went to live on the farm upstate).

However, I think the landscape looks more welcoming than it used to be, and if someone wanted to work on it, I think the chances of success are higher than the last time.

• We're currently in the process of deploying parser changes that will allow this change (and similar changes) without again causing the accessibility and search indexing issues that were the primary reason for the revert 9 years ago. This work is happening in T13555: .mw-editsection links should not be part of the <h#> element.
• We're also currently in the process of deploying changes that add a similar link to all comments on talk pages, and so far that feature has been received positively on Wikimedia wikis. The people crave shareable links. This work is happening in T302011: [Release Ticket] Introduce permalinks on wikitext talk pages.

The next steps would be to 1) remove any mention of "RFC" from this task 2) update or propose a new patch 3) if you want to make it available as a default-off feature for non-Wikimedia wikis, convince someone to merge it; if you want to release it to Wikimedia wikis too, figure out who the stakeholders are and notify them.

I built a POC gadget in testwiki: https://test.wikipedia.org/wiki/MediaWiki:Gadget-section-share.js

I‌ enabled it as default so it's easy to test. You can go to https://test.wikipedia.org/wiki/Test for example and you see

Clicking on it will copy the url with the fragment to clipboard.

Unicode being encoded is not ideal. Most websites and apps these days support readable links, and this renders the potential feature not useful for non-Latin wikis.

It'd be awesome to have it offer both an external URL and an internal link, and also a permalink option! I still use https://en.wikipedia.org/wiki/User:The_Earwig/copy-section-link.js for this and I think it's great.

In T18691#11707767, @MusikAnimal wrote:

It'd be awesome to have it offer both an external URL and an internal link, and also a permalink option! I still use https://en.wikipedia.org/wiki/User:The_Earwig/copy-section-link.js for this and I think it's great.

This is a feature for readers who wouldn't know what wikitext internal link is or what permalink means. It would also clutter the interface a lot. I suggest that your suggestion should be non-default gadget with "more" options.

In T18691#11707679, @stjn wrote:

Unicode being encoded is not ideal. Most websites and apps these days support readable links, and this renders the potential feature not useful for non-Latin wikis.

Let me investigate this.

The current implementation on test.wikipedia is fine for me as a screen reader user, but speaking strictly for myself I'd still turn it off as soon as I could. I almost never use section links. But I'm not the target audience for this feature ...

I think it's counter-intuitive.

On most sites, in mobile and desktop, a "share" link generates a pop-up or offers a list of apps or services (Email, Facebook, Watsapp, etc.)

The correct approach for a share button now is to use the Web Share API.

I'm aware of Web Share API. But this gadget is on desktop only. The mobile skin require a different design to which it'll definitely use the web share api too but that is broderline useless on desktop.

According to caniuse only Firefox seems to be the major outlier, the script could check if it's available/supported right?

I forgot that desktop Firefox still hasn't implemented it, pretty irritating. Yes, the script would need to use Navigator.canShare() and provide fallback functionality for that and any other cases. But I disagree strongly that it's "borderline useless on desktop". Here's how the demo at MDN looks in Chrome on Windows:

Would be great if for this feature it was possible to override the default behaviour to do something else. That way, Wikipedians could set it to display a popup with various types of link syntax and regular readers could just get Web Share API or a fallback.

That would be pretty easy. If something like that was implemented, it would be useful to be able to trigger the Web Share API from the link syntax panel if that's what's needed.

In T18691#11707679, @stjn wrote:

Unicode being encoded is not ideal. Most websites and apps these days support readable links, and this renders the potential feature not useful for non-Latin wikis.

Let me investigate this.

You can reliably generate a readable URL like this: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/6867d172115f5e68b71fafe735c60a75da57e59c/modules/permalinks.js#13

I updated the gadget to include both the decode and using the share API where possible: https://test.wikipedia.org/w/index.php?title=MediaWiki:Gadget-section-share.js&diff=prev&oldid=735190

Does navigator.share require encoded URL to work? Because that's what's currently gets passed there.

In T18691#11749898, @stjn wrote:

Does navigator.share require encoded URL to work? Because that's what's currently gets passed there.

No, it wasn't intentional. Fixed now.

Change #513234 abandoned by Hashar:

[mediawiki/core@master] Adds a Share widget to the Section Headers

https://gerrit.wikimedia.org/r/513234

Change #513234 restored by Thcipriani:

[mediawiki/core@master] Adds a Share widget to the Section Headers

https://gerrit.wikimedia.org/r/513234

An update. After community consensus. We have pushed this as part of common.js of Persian Wikipedia. After a while, I take a look at webrequest logs to see if it has had impact on page views (specially to sections) on the wiki. It is a bit hard since the internet is still shut down in Iran and 91% of traffic to fawiki is from there. If any other wiki wants to try the gadget so we can gather more data, I'd be grateful. Once we have enough data, I think I can try to push this to vector skin in the Milan hackathon (fingers crossed)