Page MenuHomePhabricator

RFC: Section header "share" link
Open, NormalPublic

Tokens
"Love" token, awarded by MusikAnimal."Like" token, awarded by Trizek."Love" token, awarded by Quiddity."Like" token, awarded by nray."Love" token, awarded by Niedzielski."Burninate" token, awarded by osorio-juan-microsoft."Love" token, awarded by Sebastian_Berlin-WMSE."Like" token, awarded by Liuxinyu970226."Love" token, awarded by eflyjason."Love" token, awarded by Kaartic."Love" token, awarded by Niharika."Like" token, awarded by Pcoombe."Like" token, awarded by Ciencia_Al_Poder."Like" token, awarded by He7d3r."Dislike" token, awarded by Jooojay."Like" token, awarded by waldyrious."Like" token, awarded by gpaumier."Like" token, awarded by Arghman."Like" token, awarded by fbstj."Mountain of Wealth" token, awarded by Nemo_bis.
Assigned To
None
Authored By
brion, Dec 17 2008

Description

Problem statement

Today, it is hard to share links to sections of wiki pages. Sections on a page don’t have a link to themselves on the page, except at the top of the page in the Table of Contents. If the page is long, a reader would have to scroll all the way to the top to copy the link and remember the name of the section they wanted to share.

Objective

This task aims to make it easier for readers to share links to sections on wiki pages. Both for "external" purposes (full URL to the section) and "internal" links (to use as internal link from another page in VisualEditor or in a wikitext editor).

Acceptance criteria:

  • Accessibility: The section section share link read should not be read aloud by screen readers as part of the heading text when iterating through the headings on a page.
  • Internationalization: The section share link should work for both left-to-right and right-to-left layouts.
  • Headings that are produced by <h2> syntax in wikitext currently do not have utility links like "edit section". The section share link should also not be added to these (T91271).

Related ideas:

Status quo

There are a number of workarounds that already provide the basic functionality on some wikis through gadgets and user scripts:

Proposal 1

Clickable section anchors, in the form of an § icon next to page heading, were implemented and briefly deployed in March 2015.

Code:

Screenshot

This has since been reverted from MediaWiki core and un-deployed from WMF wikis. There were numerous problems that can be found in detail at T18691#1051560, T18691#1098570 and other comments after it. Including:

  • The CSS was not compatible with an RTL layout.
  • The space for the element was not consistently reserved for the layout box (e.g. partially "hanging out" if the heading is inside another element) – T18691#1073006
  • The meaning of the icon it used was not clear to some users. – T18691#1097797, T18691#1097768
    • It was mentioned that making the symbol localisable might be enough to address this. Others mentioned that using a symbol relating to "anchors" and "linking" might work universally (instead of an icon relating to "sections" or "paragraphs"). – T18691#1098570
  • The element was not excluded for <h2>-syntax headings.
  • The element could not easily be disabled for some headings, such as on the Main Page. It was thought this could be resolved by applying a CSS class to the HTML element, so that it can be hidden by CSS override.
  • The element was visible by default, which was thought to be distracting or "crowded" by some.
    • It was mentioned we could or should perhaps hide it by default and show it after a certain interaction with the heading or section, e.g. hover/focus on desktop (for mouse, keyboard navigation, and assistive technology). Mobile UX has not yet been proposed.

Other variations of this proposal were originally documented on mediawiki.org, at https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors.

Proposal 2

This is the solution we currently want to get approved and merged.

  • A “share” link will be added to the existing “edit” or “edit | edit source” widget.
  • This applies to all MediaWiki heading classes, that currently has the edit link widget.
  • But this will not apply to literal headings (when users use HTML header tags directly, such as <h1>, <h2>, <h3>…)
  • This “share” link is a clickable link.
  • When the user clicks on this “share” link, a window pops up that allows both sharing internally with wikitext and externally with full URL.
  • This solution works for both left-to-right and right-to-left layouts.

The implementation looks like this:

Related Objects

StatusAssignedTask
OpenNone
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

...

In the meantime, here are some dump-based numbers for two Wikipedias (I'll try to run this for enwiki too), for mainspace pages:

And here is the result for enwiki:
total number of articles: 5817124
... with Level 2s: 5500191 = 94.552%
... with Level 3s: 1282941 = 22.055%
... with Level 4s: 172667 = 2.968%
... with Level 5s: 13084 = 0.225%
... with Level 6s: 763 = 0.013%
... with Level 1s: 443 = 0.008%

(data source - btw this took 5h 28min, thankfully PAWS did not kill the process)

Thanks! Do you happen to still have the underlying database query and could post it here so we could re-run it?

I searched and asked, but we do not have it available anymore, sorry.

While the stats on heading levels usage are interesting, I'm not sure they will help with the dilemma: If a heading is commonly used that makes the case for both adding the sharing links and that adding those links will clutter the interface. Conversely for less-used headings it is safer to drop the sharing links, but also won't help will reducing clutter.

What might be helpful would be knowing how much content appears under each heading level, however that would be a much more complex thing to calculate.

For shorter articles that don't have any/many h3's that might be fine, but for feature-article length pages it would be not very useful.

Maybe making this configurable per-wiki is a potential solution?

I'm not sure how that solves the problem for our big wikis? Or are you thinking of other use cases?

Moving this to blocked on others pending our follow-up meeting with @Msftwikipmey and @osorio-juan-microsoft.

nray awarded a token.Apr 3 2019, 5:53 PM

Change 513234 had a related patch set uploaded (by Juan Osorio (Microsoft); owner: Juan Osorio (Microsoft)):
[mediawiki/core@master] Adds a Share widget to the Section Headers

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

This is the current implementation I have pushed:

Looking forward to your feedback/questions!

Looking forward to your feedback/questions!

Looks good to me. It may be useful to also discuss it on the mailing lists to get more input

Quiddity added a comment.EditedMay 31 2019, 5:13 PM

This is the current implementation I have pushed:

  1. Overall: Looks great to me. :)
  2. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?
  3. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

Looking forward to your feedback/questions!

The screenshot looks great.

  • would it be possible to test the feature out?
  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel? The easiest way to inspect the styling of them might be from here. Here is a screenshot of the panel I'm referring to:
  1. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

+1

  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel?

+1

  1. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?

By this, do you mean we should place the subsection title as-is after the # on the Wikitext version? Or just replace underscores with spaces?

  1. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

Definitely. Do you at WMF have a test site we could deploy this to? From our end we currently don't have the capacity to open up a place where everyone can test out the feature.

  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel?

I think this is part of the Popups extension. Correct me if I'm wrong, but I think what we should do is update the WikimediaUI styles for OOUI PopupWidget to match the Popups extension. The alternative is to use the Popups code, but as this is part of the core I think that would be more difficult.

  1. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?

By this, do you mean we should place the subsection title as-is after the # on the Wikitext version? Or just replace underscores with spaces?

I think I mean the former? I'm not entirely clear on what the technical distinction would imply. :-) The main thing I want to avoid, is having to manually replace the underscores with spaces, which I currently have to do whenever I copy part of the URL from the browser-address-bar. (I/we remove the underscores because otherwise they lead to linewrap issues, as well as being not an actual part of the title).

  1. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

Definitely. Do you at WMF have a test site we could deploy this to? From our end we currently don't have the capacity to open up a place where everyone can test out the feature.

We do have a Cloud VPS infrastructure that you could use for this, with extensive documentation at https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS

Alternatively, you could simply copy some strings of text from existing projects. I tend to just pick whatever the Featured Article of the day is from the main page. E.g. https://ja.wikipedia.org and https://fa.wikipedia.org - then add e.g. ?uselang=ja to the URL to change the interface language (and direction for RTL languages).

The main complexity (based on my limited understanding) is making sure the feature does not turn 白血病#概要 into %E7%99%BD%E8%A1%80%E7%97%85#%E6%A6%82%E8%A6%81 (as it does when I copy the full URL from the address-bar).

Perhaps some developers already watching this task can give better suggestions for how to test this kind of thing?

I think I mean the former? I'm not entirely clear on what the technical distinction would imply. :-) The main thing I want to avoid, is having to manually replace the underscores with spaces, which I currently have to do whenever I copy part of the URL from the browser-address-bar. (I/we remove the underscores because otherwise they lead to linewrap issues, as well as being not an actual part of the title).

I have to think about this one because it should still be valid Wikitext for subsections with special characters like ] (closing square bracket)

The main complexity (based on my limited understanding) is making sure the feature does not turn 白血病#概要 into %E7%99%BD%E8%A1%80%E7%97%85#%E6%A6%82%E8%A6%81

What it looks like after playing around a bit:

Notice that the actual URL has some escaped characters. This behavior is taken from the TOC and is consistent with it.

Also, check out the widget with RTL rendering:

  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel?

I think this is part of the Popups extension. Correct me if I'm wrong, but I think what we should do is update the WikimediaUI styles for OOUI PopupWidget to match the Popups extension. The alternative is to use the Popups code, but as this is part of the core I think that would be more difficult.

I wonder if @Jdrewniak @thiemowmde or @Jdlrobson might be able to provide some technical guidance here, as I am unfamiliar with the code.

I would suggest not to call any code from the Popups extension (tagged as Page-Previews here on Phabricator, as well as Reference Previews). I would also suggest not to reuse the design from the Popups extension. I mean, there is not really anything wrong with this design. It still fits quite well with the current style guide. But it's outdated and much older than the current OOUI styles. Please stick to the OOUI PopupButtonWidget.

Technically, the design of the popup windows as shown by the Popups extension can only be reused if you are fine with having very strict, pixel-based size constraints (always 320px wide).

There is now an mw.widgets.CopyTextLayout in core, as used on the URL shortener (https://meta.wikimedia.org/wiki/Special:UrlShortener):

There is now an mw.widgets.CopyTextLayout in core, as used on the URL shortener (https://meta.wikimedia.org/wiki/Special:UrlShortener):

Yes, @Fomafix mentioned it on the Code Review. I have since changed my patch to use it. I have also added some changes to that widget: being able to select partial text from field, and being able to style it as seen in the Section Header Share widget.

@Esanders @alexhollender I have removed some of the extra styles so that the copy field looks the same as the other CopyTextLayouts.

@Esanders @alexhollender I have removed some of the extra styles so that the copy field looks the same as the other CopyTextLayouts.

Looks awesome 👍

Elitre removed a subscriber: Elitre.Aug 29 2019, 9:08 AM
WDoranWMF added a subscriber: WDoranWMF.

I'm going to move this into CPT's clinic duty for review but we'll need the merge conflict resolved first if that's ok.

I'm going to move this into CPT's clinic duty for review but we'll need the merge conflict resolved first if that's ok.

Fixed merge conflict. Thanks!

On https://gerrit.wikimedia.org/r/c/mediawiki/core/+/513234, @daniel commented:

Note that this functionality is subject to an ongoing RFC, T18691.
It should not be merged until that RFC has been approved.

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?

We did briefly discuss it in the TechCom meeting yesterday. Two issues have come up:

  1. The proposal in the task description is quite different from what has been implemented. For this to progress as an RFC, the task description has to be updated to reflect what we are actually deciding on.
  2. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?

We did briefly discuss it in the TechCom meeting yesterday. Two issues have come up:

  1. The proposal in the task description is quite different from what has been implemented. For this to progress as an RFC, the task description has to be updated to reflect what we are actually deciding on.
  2. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

W.r.t...
#1 - The design has indeed evolved quite a bit as we work with @ovasileva @alexhollender to the section anchor more usable and intuitive. We can update the description of this RFC.
#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

Josve05a removed a subscriber: Josve05a.Sep 12 2019, 7:28 PM

#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

It means enabling it on at least some of the WMF sites. Whether it's part of core or an extension isn't so relevant.
The original RFC has been filed with the idea of having this enabled on Wikipedia and friends, but I'd like to have explicit word on that from the relevant WMF folks.

  1. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

Offering a technical perspective: the current implementation of this feature relies on some changes to the Parser output and the Skin template, which require changes to the core. In order to accomplish the same in an extension, there still needs to be some change in the core - specifically to provide the anchor values on the SkinEditSectionLinks hook (which means all the changes except the actual adding of the 'share' link would need to go into the core anyway). I think because of this it makes more sense to have this as a core change. It is still configurable through $wgEnableSectionHeaderShare global, which is off by default. When the value is false, no extra logic or JavaScript/CSS resources are invoked by the feature.

@osorio-juan-microsoft Thanks, that does sound like it would be difficult to do this in an extension. And if we (WMF) don't enable it, it probably wouldn't need an RFC. But if we are planning to enable it on WMF sites, it will need a closer look.

#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

Yes, we are planning on enabling the feature on en.wiki once it becomes available.

Yes, we are planning on enabling the feature on en.wiki once it becomes available.

Thank you for clarifying, Alex!

Krinkle renamed this task from RFC: Section headings should have a clickable anchor to RFC: Section headings with clickable anchor.Sep 18 2019, 7:54 PM
Msftwikipmey renamed this task from RFC: Section headings with clickable anchor to RFC: Section header "share" link.Sep 18 2019, 8:34 PM
Msftwikipmey updated the task description. (Show Details)

We did briefly discuss it in the TechCom meeting yesterday. Two issues have come up:

  1. The proposal in the task description is quite different from what has been implemented. For this to progress as an RFC, the task description has to be updated to reflect what we are actually deciding on.

The task description has been updated to reflect what was actually designed by @alexhollender and implemented by @osorio-juan-microsoft :)

daniel moved this task from Under discussion to Inbox on the TechCom-RFC board.Sep 19 2019, 9:37 AM

Putting this in the RFC inbox for discussion.

I assume the idea is to get approval on this. So the next step could be a public meeting for discussion. Or we could go directly for last call. A TechCom member will probably want to have a closer look beforehand, though.

daniel moved this task from Inbox to Under discussion on the TechCom-RFC board.Sep 25 2019, 8:44 PM
Krinkle updated the task description. (Show Details)Oct 1 2019, 11:36 PM
Krinkle updated the task description. (Show Details)

@Msftwikipmey Thanks for adding that screenshot. Could you update the proposal section as well with some text about how the implementation works and how it addresses the various concerns raised so far. I've edited the task description to make these a bit more structured and easier to scan through.

Msftwikipmey updated the task description. (Show Details)Oct 2 2019, 4:52 PM

Will check with @osorio-juan-microsoft about whether screen reader would read this out...

osorio-juan-microsoft added a comment.EditedOct 4 2019, 5:12 PM

Will check with @osorio-juan-microsoft about whether screen reader would read this out...

It will be read out by screen readers, similarly to "edit". It will just read out "share". Adding aria-hidden="true" to the action links (so neither edit nor share are read by screen readers) would be a separate task.

I agree that the consideration of making "N" utility links spoken or not by default when reading an article is a separate task. However, I think it's important to consider that we don't have N utility links today. Historically (and for most pages for most users, still) there is 1 link, the primary action we invite users to do: Edit. The transition to having "a group of utility links", in a way that is visible to most users, starts with this RFC.

The question becomes: When scanning an article through assistive technology, what should the experience be? Should they hear by default in unskippable fashion: "Name of person, Biography, Link edit section, Link share this section, (text of biography), Early life, Link edit section, Link share this section, (text about early life), See also, Link edit section, Link share this section (list of other articles)".

I don't know the answer to that. I also don't know what the alternative is, or how other (greatly accessible) web apps tend to deal with the use case of providing inline actions about a paragraph in context with reading.

This is a great question! I don't specialize in accessibility, so I also would love to hear input from someone with more experience in this field :)

Ok, so, good progress here. The technical committee would like to see concerns from the March 2015 version reviewed, to ensure we don't repeat any of those problems. As stated in the description, the issues were raised in and around comments T18691#1051560 and T18691#1098570, and include:

  • The CSS was not compatible with an RTL layout.
  • The space for the element was not consistently reserved for the layout box (e.g. partially "hanging out" if the heading is inside another element) – T18691#1073006
  • The meaning of the icon it used was not clear to some users. – T18691#1097797, T18691#1097768
    • It was mentioned that making the symbol localisable might be enough to address this. Others mentioned that using a symbol relating to "anchors" and "linking" might work universally (instead of an icon relating to "sections" or "paragraphs"). – T18691#1098570
  • The element was not excluded for <h2>-syntax headings.
  • The element could not easily be disabled for some headings, such as on the Main Page. It was thought this could be resolved by applying a CSS class to the HTML element, so that it can be hidden by CSS override.
  • The element was visible by default, which was thought to be distracting or "crowded" by some.
    • It was mentioned we could or should perhaps hide it by default and show it after a certain interaction with the heading or section, e.g. hover/focus on desktop (for mouse, keyboard navigation, and assistive technology). Mobile UX has not yet been proposed.
  • Accessibility issue raised by Timo above: T18691#5547922

I would like to assign stakeholders to go over these and also read through the original task comments that raised them. I'm thinking @ovasileva can help coordinate a review of the technical concerns and @Volker_E can help coordinate a review of the design concerns, especially the accessibility. If I guessed wrong, ping me and we'll try to find someone else. Ideally the feedback would be incorporated in the RFC (task description), and I can help with that.

New design has a few benefits over the old (icon based) design. I'll try to address all the points.

Ok, so, good progress here. The technical committee would like to see concerns from the March 2015 version reviewed, to ensure we don't repeat any of those problems. As stated in the description, the issues were raised in and around comments T18691#1051560 and T18691#1098570, and include:

  • The CSS was not compatible with an RTL layout.

Current solution is RTL-compatible (feel free to verify).

  • The space for the element was not consistently reserved for the layout box (e.g. partially "hanging out" if the heading is inside another element) – T18691#1073006

Current design extends on the "edit" link section and thus doesn't have this style issue.

Current design does not use an icon.

  • It was mentioned that making the symbol localisable might be enough to address this. Others mentioned that using a symbol relating to "anchors" and "linking" might work universally (instead of an icon relating to "sections" or "paragraphs"). – T18691#1098570

Symbol not used anymore. localisable text "share" used instead.

  • The element was not excluded for <h2>-syntax headings.

<h2>-syntax headings do not have the "share" link, as expected.

  • The element could not easily be disabled for some headings, such as on the Main Page. It was thought this could be resolved by applying a CSS class to the HTML element, so that it can be hidden by CSS override.

Current design respects the NOEDITSECTION magic word

  • The element was visible by default, which was thought to be distracting or "crowded" by some.
    • It was mentioned we could or should perhaps hide it by default and show it after a certain interaction with the heading or section, e.g. hover/focus on desktop (for mouse, keyboard navigation, and assistive technology). Mobile UX has not yet been proposed.

Still visible by default. In my opinion, current design is less intrusive.

Need to explore this one

I'm a screen reader user who commented waaaaaay above. If a link *had* to be added, adding it after the "edit" link would be best. However screen readers will generally read the link text, not the title, unless instructed otherwise, so they'd here, for example, "Early life edit share". I for one think an edit link is relatively straightforward, but a share link would be confusing ... the average user would be thinking "share what? With whom? How? The same would apply to a lesser extent with "Share this section", but that's more words. I don't know about anybody else, but I would use this rarely enough that I would disable it immediately if it was ever enabled by default on Wikimedia wikis.

Pelagic added a subscriber: Pelagic.Oct 6 2019, 8:36 PM

I was planning to log a feature request ticket, but found that this task already exists. For what it’s worth here is my user story:

As an editor and collaborator, I would like an easy way to copy the wikilink for a section to paste into an article or talk page. As a reader I might also want to copy the URL to paste elsewhere.

My point is that collaboration is a big part of this. Also linking to help or policy sections. As Quiddity wrote:

As a Wikipedia editor, I frequently need to link to subsections of discussion pages, and of policy/guideline pages, …
… frustation of having to copy & paste from the page-title and subsection independently (or remove the underscores from the URL).

This task looks pretty mature, and a lot of decisions are already committed. A few extra thoughts anyway:

  • Hover versus always-visible: please don’t make it hover-only. Some people use the desktop site on touch devices. Structured Discussions has some good elements that toggle state on tap as well as hover, though that behaviour isn’t very discoverable.
  • Heading level. If a page doesn’t have level-4 headings, then it’s not going to have level-4 sharing either. It’s not deep subheadings that cause clutter, but short sections.
  • On-by-default and user preference. Personally, I would like to see this default-on for all Wikimedia wikis, with per-user opt-out. It would benefit non-logged-in users. But the language communities being what they are, we should allow each one to hold their own RFC. Turn it on for Beta and MediaWiki wiki as soon as available, to showcase the feature and let people see it in action. In case English Wikipedia says “no”, can I have a user preference to turn it on for myself, please? (In other words, deploy as user opt-in, then let each wiki community choose to flip it to opt-out.) Could it be promoted with a banner or a one-time popover, or is that too intrusive? (I only learned about AMC because of the popover.) Let’s not have another MediaViewer SuperProtect incident so soon after FramBan (and similar SanFranBans that happened on DE and ZH).
  • Mobile site. Please don’t leave mobile in the too-hard basket. This would benefit non-AMC users too. A link icon next to the pencil would be great.
  • Skins. Will skins like Timeless need to be modified to work with section sharing? I gather @Isarra has been very busy, hope it won’t be much work.
  • Permalinks. I’d love to have a permalink option for both the URL and wikilink (using Special:Permalink for the latter). Four text fields may be too cluttered. How about a selector to switch between standard and permanent forms?

@Pelagic As a workaround--and to be able to copy anchors from other sites, my add-on (Firefox or Chrome) might help: https://github.com/brettz9/jump-to-anchor#jump-to-anchor

@osorio-juan-microsoft you are planning to look into the screenreader issue on your side? Thanks!

@osorio-juan-microsoft you are planning to look into the screenreader issue on your side? Thanks!

I think in technical terms the solution isn't too challenging (I would just add aria-hidden labels to the link elements in order to have screen readers skip them).

However, I think that's a bigger discussion to be had. Whether or not the links are read (or which ones are specifically), as well as what kind of text is read ('share' vs. 'share this section', etc), is way beyond my scope.

stjn added a subscriber: stjn.Oct 14 2019, 9:43 AM

Please make sure not to add aria-hidden to focusable elements without removing focus, see:
https://dequeuniversity.com/rules/axe/3.3/aria-hidden-focus

stjn added a comment.EditedOct 14 2019, 10:04 AM

Historically (and for most pages for most users, still) there is 1 link, the primary action we invite users to do: Edit. The transition to having "a group of utility links", in a way that is visible to most users, starts with this RFC.

On most wikis, not counting English Wikipedia, there are two links: ‘Edit’ and ‘Edit source’. In fact, it is kind of strange that all the design proposals are seeing how it looks just with ‘Edit | Share’, not considering how it would look, for example, with text ‘Bearbeiten | Quelltext bearbeiten | Teilen’ or ‘править | править код | поделиться’.

Noe added a subscriber: Noe.Oct 15 2019, 7:25 AM

Hi,
It's a very interesting conversation. It reminds me https://phabricator.wikimedia.org/T183747
Maybe they could be related?

If the page is long, a reader would have to scroll all the way to the top to copy the link and remember the name of the section they wanted to share.

A radical proposal: Instead of a "share" link, have a "TOC" link that links to the relvant line in the TOC (rather like links from citations to where the citation lies in the body text).

For Chinese wiki, we have at least 2 conversions: traditional Chinese and simplified Chinese. Till now, the section anchor only works on exactly the same characters of the section title. I think it will be a good idea to let the section link also works on different conversions. However, it maybe needs a new design.

If the page is long, a reader would have to scroll all the way to the top to copy the link and remember the name of the section they wanted to share.

A radical proposal: Instead of a "share" link, have a "TOC" link that links to the relvant line in the TOC (rather like links from citations to where the citation lies in the body text).

Unfortunately, that wouldn't solve the two issues of

MusikAnimal added a subscriber: MusikAnimal.EditedOct 17 2019, 10:08 PM
In T18691#5550415, Pelagic wrote:

...

  • Permalinks. I’d love to have a permalink option for both the URL and wikilink (using Special:Permalink for the latter). Four text fields may be too cluttered. How about a selector to switch between standard and permanent forms?

👍

I currently use User:The Earwig/permalink.js extensively for this. It creates a wikilink with Special:Permalink, which is great, but I often need to change it to full URL which can be tedious (underscores instead of spaces, etc.). There is a "Permanent link" option under "Tools" in native MW, but you of course still need to manually append the section title.

Also, I should note that it's super common for people link to live discussions without using a permalink, so the link can quickly become broken after the discussion is archived or renamed, etc. If there's a native way to easily get permalinks, people will eventually learn to use them, and save the follower of those links a lot of time. It's very un-fun trying to dig through archives and revision histories to just find the discussion.

In T18691#5585283, @MusikAnimal wrote:
[...]
If there's a native way to easily get permalinks, people will eventually learn to use them, and save the follower of those links a lot of time. It's very un-fun trying to dig through archives and revision histories to just find the discussion.

Yes! This is a great point. I agree that we should include the ability to generate permalinks.

Let me know if you need any review specifically from Reading web team by re-adding the tag.