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)

Change #1281648 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/core@master] Introduce sharing of section function

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

Test wiki created on Patch demo by Ladsgroup using patch(es) linked to this task:
https://6e9260483c.catalyst.wmcloud.org/w/

https://6e9260483c.catalyst.wmcloud.org/wiki/Alan_Turing#Early_life_and_education

Looks like this with JS disabled:

Should be hidden for .client-nojs IMO.

As @DLynch mentioned in the patch, without js, it'll be a just link to the section which is still useful (you can for example right click on copy it) but indeed the weird look is a bug, I have a feeling interface-edit-section-links less module is not being applied on no-js mode (but it should,, it's a needed css) but debugging it is a bit above my skinning skills. If anyone can give me a pointer, I'd be grateful.

The no-js display issue is because VisualEditor assumes that when there's no JS .editsection-divider should be given display:none, which is normally correct because it's part of hiding the "edit with VE" link... but now there's another element present and it all falls apart.

Change #1281755 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] No-JS: only hide the mw-editsection-divider that follows a VE edit link

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

^ with that patch:

Thanks for catching it!

Change #1281755 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] No-JS: only hide the mw-editsection-divider that follows a VE edit link

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

In T18691#11881882, @DLynch wrote:

The no-js display issue is because VisualEditor assumes that when there's no JS .editsection-divider should be given display:none, which is normally correct because it's part of hiding the "edit with VE" link... but now there's another element present and it all falls apart.

But isn't this link practically useless without JS? Or at least should be renamed to 'link' or something since it's not going to pull up a share menu.

Renaming it might make sense, for sure. Though the no JS experience still makes sense -- someone with JS disabled is probably used to the idea of having to copy link targets by now.

At first, I didn’t note the toast notification, because:

• it was pretty far from the link I clicked;
• and, in the same time, the Page Preview Card (Popups) displays just next to the Share link.

Since the Page Preview Popup is useless and it disturbs user attention from toast notification, I would disable this feature for the Share link.

Consider mobilefrontend:

Change #1281809 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/Popups@master] Ignore section share links

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

Change #1281810 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/skins/MinervaNeue@master] Ignore section share from core

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

I made a patch in Popups to ignore all section share links. I also made a patch in MF to ignore section share too. The reason being that the whole sharing in mobile is being reworked and revamped to something quite nice. See T416432: [Epic] Share Card experiment.

It feels to me that hiding the link from Minerva is extremely wrong if it's something that's going to be in MediaWiki core. The icon ID should just be fixed to display a supported icon, third-party wikis won't have the same experiment (never mind that it's also not a given it'll be kept) for the WMF wikis. If the experiment devs decide section links are detrimental, they could just hide it themselves.

In T18691#11882439, @stjn wrote:

It feels to me that hiding the link from Minerva is extremely wrong if it's something that's going to be in MediaWiki core. The icon ID should just be fixed to display a supported icon, third-party wikis won't have the same experiment (never mind that it's also not a given it'll be kept) for the WMF wikis. If the experiment devs decide section links are detrimental, they could just hide it themselves.

The Reader Growth Team is going to launch an experiment in ~2 weeks around a share feature for mobile, anon users. That experiment will run for ~1 month on a couple of wikis as an A/B test, and we will be collecting data to get a sense of how and whether readers use such a feature. Introducing similar functionality outside of the experiment (but at the same time) is just going to add confusion.

I don't see a problem with this going out to Vector but I'm opposed to making this change on mobile right now. We can revisit after we have A/B test results from the ShareHighlight experiment.

Change #1281831 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/skins/MinervaNeue@master] Add share icon

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

In T18691#11882580, @egardner wrote:

Introducing similar functionality outside of the experiment (but at the same time) is just going to add confusion.

I don't see a problem with this going out to Vector but I'm opposed to making this change on mobile right now. We can revisit after we have A/B test results from the ShareHighlight experiment.

Then ShareHighlight experiment could remove that link for people using it, as I mentioned. This is going to be a core feature so turning it off for a WMF-run experiment would also affect, for instance, translatewiki which also uses the latest alpha but won't have the WMF-specific extension.

I tried. It looks nice on content pages, but maybe there is some clash with the Discussion Tools or something.

DiscussionTools will also have been fixed by https://gerrit.wikimedia.org/r/1281755

Can you add it to the Patch Demo above, please?

@Ladsgroup is the owner of that patchdemo, and would need to do that. (The patch is merged, so the patchdemo just needs to be rebuilt.)

I just rebuilt it and it looks correct me (https://6e9260483c.catalyst.wmcloud.org/wiki/Talk:DiscussionTools) let me know if it's not fixed.

Great, thanks.

Would be nice to somehow add it to their overflow menu on mobile. Not a necessity of course but this is probably one of the most useful feature applications for the editors.

@stjn: that's actually completely-independently happening recently in T418197. (There's https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1278593 to merge and it'll be out for everyone.)

Since this is the same feature, we should probably use the same label.
Personally, I have a preference for “copy link” over “share” because that is more explicit. “Share” is often used for modal windows which allow to publish the link.

Responding to the usernotice tag. Is this being pitched for coverage in Tech News? How should it be worded?

Some data for Persian Wikipedia where it had the section share functionality gadget since April 9th: https://w.wiki/QTg$

Basically it's the human traffic to Persian Wikipedia from Germany. The data is less noisy than the traffic from Iran (or all of Persian Wikipedia) since the internet was shutdown for almost all of the duration of the past three months. That also meant a lot less people could use proxies which meant traffic from Germany also was affected (in fact, three fourth of traffic of Germany to Persian Wikipedia before the war was from users in Iran using proxy, but that's a discussion for later) and as you can see once the internet shut down was lifted, the traffic from Germany is jumping too. But let's ignore that for now

If you compare the traffic based on referrer, the "no referrer" traffic was roughly the same amount of traffic from google in Persian Wikipedia but right after the gadget was added, we now see 5K-10K more pageviews from "no referrer" compared to traffic from Google. That's roughly 10% of all of human traffic to Persian Wikipedia from Germany (actual traffic, not proxy). There is some increase in traffic from social media too (notably twitter) but total page view is low and by nature quite spiky (viral tweet about something on Wikipedia) so I'm ignoring that but it is still visible in averages.

Noting that this increase is not as clean in other countries such as US or GB and I assume partially that's because in those countries there are a lot more scraper active (the traffic is quite spiky meaning it's not organic):

It would be really nice if another large wiki also adopted the gadget so I can have a another system to compare (and they are very likely way less noisy then Persian Wikipedia due to *gestures at the world*)

@Ladsgroup I think what you're looking for is Referer_Class "none", which is how we classify pageviews that did not have a HTTP Referer header.

Breakdown by Referer Class: https://w.wiki/QWfd

The Referer Name "none" value is somethin differnet, and only makes sense with looking within one specific Referer Class value. Otherwise it is ambiguous. Under referer_class=external, all pageviews from a specific external website are aggregated as "referer_name=none" (because we don't generate for that column in this dataset for size reasons, except for the handpicked search engine and media site names). Likewise, we don't aggregate individual WMF domains under referer_class=internal either, so all of those also carry Referer Name "none" .

My screenshot shows that most of those "none" values are from referer_class=internal, which means they did have a referrer, and the referrer was Wikipedia itself. Without knowing more, it seems that after April 9, there is a lasting increase in how many pageviews are opened within a reading session (i.e. more secondary pageviews, deeper/longer sessions).

Do you see a lasting increase in first pageviews? i.e. class "external" from a shared link via a website or web app, or class "none" from a shared link via a chat/social/messaging app?

Thanks for catching there. I started looking into this now more in terms of ratios. So for example, this is the ratio of none referrer class to search engine referrer:

The ratio before intervention is 15.7% and before intervention is 17.1% and using t-value test for two independent samples, the p-value (two-tailed) yields 0.01566 meaning it's a statistically significant difference (\o/). The difference is 1.377%,

For social media, after intervention is actually slightly smaller (1.25% vs 1.075%) but the difference is extremely small and p-value is 0.5375 meaning it's not significant.

Funnily enough, the internal to search engine traffic bumps from 79.9% to 98.1% with p-value of 1.2e-24(!). It can be just coincidence or small data but it can be that people are sharing more and that is leading to more people ending up in rabbit holes (i.e. every external referrer actually leads to many internal traffic leading to compound effects)

In terms of raw numbers: it seems, the none referrer class average has gone from 4510 page views per day to 5741 page views per day and that has led to page views with internal referrer jump from 22978 to 33280.

(I used https://www.statskingdom.com/140MeanT2eq.html to calculate the values, if someone has a better way of doing it, let me know)

TLDR: My explanation is that when someone gets to wikipedia through clicking on search engine results, they usually meant to look up a fact and then they leave. While if they are coming to us through other means (=with no referrer), they will stay and read more and click on links. Based on a simple regression, on average, every page view with referrer of none leads to 4.52 page views with internal referrer (clicking on links)

Nice!

Pageview counts absolute numbers: https://w.wiki/QgqT

fa.wikipedia, user, worldwide:
fa.wikipedia, user, Germany:

Potentially instead of guessing the impact of it, maybe you could just track how many times the feature was clicked on? Seems like a reasonable use of that if you want to measure how useful it is to people.
https://www.mediawiki.org/wiki/Gadget_kitchen:_recording_metrics

In T18691#11991419, @stjn wrote:

Potentially instead of guessing the impact of it, maybe you could just track how many times the feature was clicked on? Seems like a reasonable use of that if you want to measure how useful it is to people.
https://www.mediawiki.org/wiki/Gadget_kitchen:_recording_metrics

I have mixed feelings on tracking. I think both are needed.

• I would generally avoid tracking unless absolutely needed out of respect for privacy of people. Doubly so, if it's about readership or it's on a wiki where users could be targeted (which this is both).
• Tracking is useful on finding the immediate impact but it can't measure the secondary impact (as we shown, it seems people click on the share functionality and then read further, we can't really measure that via tracking metrics) [1]
• It is also important to measure the net change. Krinkle mentioned this somewhere: What if more users are using the section share but using less of direct ways of sharing (e.g. the whole page share via copying the url). We need to see the overall impact.

If ruwiki wants to try this out, let me know! I don't think I'll put tracking for ruwiki either but I'm hoping to get another wiki onboard in which I'll probably use wbprov (https://wikitech.wikimedia.org/wiki/Provenance)

[1] You theoretically could track that by javascript adding the tracking/provenance uri query to every link on the page if it is being accessed via the section share and basically chain it until infinity but I really really don't want to do that.

URL-based tracking seems much more intrusive to me than mw.track on the feature itself without any additional data collection 🤷 (I don’t think I want to spearhead adding this to ruWP as a gadget since in my personal opinion, it is not helpful enough of a feature at any wiki with Unicode URLs, and the plan to remove it from Minerva because of a WMF-only experiment is especially strange. Maybe someone else can take that up though.)

Adding the share link to the section edit link area is something the Editing team would need to consider. The area is crowded on two-edit-tab wikis as it includes [ edit | edit source ], for example dewiki:

we would want to consider:

• If added to this already crowded list is the best solution
• If doing so has a negative impact on section-edit sessions initiated (or completed)

In T18691#12014663, @Esanders wrote:

Adding the share link to the section edit link area is something the Editing team would need to consider. The area is crowded on two-edit-tab wikis as it includes [ edit | edit source ], for example dewiki:

• Three links is not that many. For example the top of the article just the right side has four links and one on top:

• The underlying problem IMHO is that we are showing both "edit" and "edit source" specially to readers. It's confusing and most of our readers don't know what is wikitext nor what a markup language is. We should eventually have only one entry point IMHO (users can decide what that should be and I assume readers/default will get VE, some people decide to use both or only old editor but they wouldn't be too big in numbers). I know it's not easy to get there but the end result is obvious to me.
• I have looked at edits to sections in Persian Wikipedia. Both edits and number of editors go up slightly after the gadget is added (The date of addition is April 9):

For the sake of reproducibility, I made these queries to extract the data:

select left(rev_timestamp, 8), count(*) from revision join comment on rev_comment_id = comment_id join page on rev_page = page_id where rev_timestamp like '2026%' and page_namespace = 0 and comment_text like '/*%' group by left(rev_timestamp, 8) order by left(rev_timestamp, 8);

select left(rev_timestamp, 8), count(distinct rev_actor) from revision join comment on rev_comment_id = comment_id join page on rev_page = page_id where rev_timestamp like '2026%' and page_namespace = 0 and comment_text like '/*%' group by left(rev_timestamp, 8) order by left(rev_timestamp, 8);

Change #1281809 abandoned by Ladsgroup:

[mediawiki/extensions/Popups@master] Ignore section share links

Reason:

Better way suggested by Jon

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

Change #1281648 merged by jenkins-bot:

[mediawiki/core@master] Introduce sharing of section function

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

Change #1308669 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Drop the share icon from the mobile site

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

Change #1308669 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Drop the share icon from the mobile site

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

Change #1308787 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Switch to continue from break for section icons

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

Change #1308787 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Switch to continue from break for section icons

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

Change #1309290 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/core@wmf/1.47.0-wmf.10] Introduce sharing of section function

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

Change #1309291 had a related patch set uploaded (by Ladsgroup; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@wmf/1.47.0-wmf.10] Drop the share icon from the mobile site

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

Change #1309290 merged by jenkins-bot:

[mediawiki/core@wmf/1.47.0-wmf.10] Introduce sharing of section function

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

Change #1309291 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@wmf/1.47.0-wmf.10] Drop the share icon from the mobile site

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

Mentioned in SAL (#wikimedia-operations) [2026-07-09T20:53:13Z] <ladsgroup@deploy2003> Started scap sync-world: Backport for [[gerrit:1309290|Introduce sharing of section function (T18691)]], [[gerrit:1309291|Drop the share icon from the mobile site (T18691)]]

Mentioned in SAL (#wikimedia-operations) [2026-07-09T21:11:03Z] <ladsgroup@deploy2003> ladsgroup: Backport for [[gerrit:1309290|Introduce sharing of section function (T18691)]], [[gerrit:1309291|Drop the share icon from the mobile site (T18691)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-07-09T21:27:27Z] <ladsgroup@deploy2003> Finished scap sync-world: Backport for [[gerrit:1309290|Introduce sharing of section function (T18691)]], [[gerrit:1309291|Drop the share icon from the mobile site (T18691)]] (duration: 34m 14s)

Change #1281810 abandoned by Ladsgroup:

[mediawiki/skins/MinervaNeue@master] Ignore section share from core

Reason:

Done in a different way.

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