I'm not seeing this… perhaps you have a gadget enabled (or I don't?) can you include a screen shot?

I'm interested in where this task has been "Resolved"!?!

Funny thing: At least two wikis implemented this in Common.js, and the code broke because of undefined mw.util.$content dependency, taking all of VisualEditor and WikiEditor with it. The same probably happens in more wikis.

Given that so many wikis are interested in it and doing it themselves not-so-perfectly, it would really be nice to just have this in core.

On the French Wikipedia, there is a gadget for this, EditZeroth, enabled by 2 678 users (among them 442 active).

On the English Wikipedia, there is also a gadget, edittop, enabled by 29 741 users.

In T2156#2954216, @Dereckson wrote:

On the French Wikipedia, there is a gadget for this, EditZeroth, enabled by 2 678 users (among them 442 active).
On the English Wikipedia, there is also a gadget, edittop, enabled by 29 741 users.

The easiest place to find most of stats, is https://meta.wikimedia.org/wiki/Gadgets - (note there are many duplicates because of capitalization variance, e.g. [[m:Gadgets/wikipedia]] contains sections for: "Gadgets/edittop", "Gadgets/EditTop", and "Gadgets/Edittop", which are otherwise identical.
The Frwiki gadget (also used by bgwiki, ocwiki, rowiki) uses a different implementation and UX, by placing the En-tête link in the "More" dropdown (in Vector).

Additionally, all projects have Special:GadgetUsage, which lists both the number of users, and number of active editors that are users. (except Enwiki, where active users is too 'expensive' to calculate) E.g. https://fr.wikipedia.org/wiki/Special:GadgetUsage

However, neither of those will include the people who obtain the gadgets via their personal global.js (as I do with navpopups and edittop).

Given this would require a disruptive change to the desktop read interface, a decision on this would need to be OK'ed by Web-Team.

Disruptive?

@Jdforrester-WMF - it's okay with us, unles @Nirzar has any objections.

In T2156#2960388, @MZMcBride wrote:

Disruptive?

See my comment above, T2156#28900 (at Apr 14 2014, 7:05 PM), trying to give the detailed overview.

TLDR: I think many/most of us would be fine with the gadget-style implementation, but it would almost certainly create some confusion or complaints, amongst:

1. people confused, because they expected the most visible/prominent link, next to the title, to let them edit the whole article
2. people annoyed, because of the visual aesthetics of the edit link(s) right next to the article header.

(I think we're all still hoping someone has an epiphany on a way to cleanly solve it, in a way that makes everyone happy. (!!!))

I agree with @Quiddity on this. They are issues that the gadget has never dealt with, because it was never enabled for all users (especially not for anonymous users).

A option that has not been named to deal with this, is to make it more clear in the edit interface that you are editing a section, and make it easier to switch from section editing to full page editing straight from the edit dialog. That might require extra controls (which then also need to be duplicated again in the 2017 editor of course).

people confused, because they expected the most visible/prominent link, next to the title, to let them edit the whole article
people annoyed, because of the visual aesthetics of the edit link(s) right next to the article header.

I strongly agree with both of these and see them as blockers

I had another question regarding this. in VE if you edit a section, the whole article goes into edit mode, so this section edit feature is not useful there. so when we talk about 0th section edit, we are talking only about wikitext editor?

In T2156#2975089, @Nirzar wrote:

I had another question regarding this. in VE if you edit a section, the whole article goes into edit mode, so this section edit feature is not useful there. so when we talk about 0th section edit, we are talking only about wikitext editor?

Currently yes, but it's a long-standing feature request for VE too (to make it only load the single section for editing, and keep the rest read-only and perhaps "grayed out" – transferring and processing the data for an entire large article can be pretty slow). I can't seem to find the task right now.

@matmarex that's good to know. whatever solution we come up with here has more shelf life. Thank you!

I will draw some stuff up and present here.

I've been looking at the way the mobile app is doing this in the latest iteration: https://www.mediawiki.org/wiki/Wikimedia_Apps/Short_descriptions

And that's actually pretty damn interesting. I'd be all for a 'progressive' enhanced edit link, that when hovered or selected allows you to pick from "Edit full article, Edit this section, Edit summary description (wikidata), Edit page title". Might be interesting to build a gadget to experiment with that. When you don't have JS enabled, it could be just a edit section 0 link.

To edit an introduction, we have to edit the whole article. The problem is that it isn't possible on a large page using the new VisualEditor. It requires just too much CPU or cache. The page freezes and then the browser (edge Windows 10) too. We need to kill and restart the browser.
The introduction of an article is a section by itself, it should thus be editable (without having to open the whole article in the editor)

EDIT:
the solution mentioned above is working: go in preference/gadget/ under "Appearance" check the box "Add an [edit] link for the lead section of a page"

Some skins have tasks already for adding or improving section-0 edit links:

• Minerva: T387175: Improve discoverability of full-page editing on mobile
• Timeless: T182520: Come up with somewhere sane to put first section editsection links
• Vector-2022: T325038: [ edit ] link for lead section is too high on the page in Vector 2022 (this is about how the gadget does it, but if we were to add the functionality to the skin there's lots of useful into there)

It sounds like the simplest cross-skin approach might be to add it to the tools menu.

Change #1207828 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/skins/Vector@master] Add section-0 edit link to the first paragraph on a page

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

Is it necessary/good/bad/confusing/marvellous to add the /* top */ (English), /* ievads */ (Latvian), /* đầu */ (Vietnamese) etc. to the edit summary when editing section zero? Most of the gadgets and scripts do so (and none appear to localize it). But this means that it appears as a normal-looking section title in the history, diff, etc. even though the link that gets created for it doesn't actually link to anything.

The above patch for Vector is a bit of an exploration of what it'd be like if the edit link(s) were added at the top of the first paragraph on a page and then floated to the end of the line, e.g.:

It's not yet ready for review, and perhaps doesn't even belong in Vector.

Good idea to add /* top */, bad idea to translate it. #top is part of the HTML specs so translating it would be confusing.

The above patch for Vector is a bit of an exploration of what it'd be like if the edit link(s) were added at the top of the first paragraph on a page and then floated to the end of the line, e.g.:

It's not yet ready for review, and perhaps doesn't even belong in Vector.

I find it intrusive and ugly as sticks out in the reading part.

Good idea to add /* top */, bad idea to translate it. #top is part of the HTML specs so translating it would be confusing.

It's a string that's seen by users, and it'd be much better to translate it. They don't care that HTML has some internal feature for linking to #top, and would just see some randon word that sticks out from its surroundings:

I find it intrusive and ugly as sticks out in the reading part.

I think it's better than having the links far separated from the first section, as they are in Vector-2022:

The screenshot I posted earlier also has the two edit links, and in many situations it'd just be one, which is a bit neater. There's also a possibility of, if it's a single link, showing it as a pencil icon. That looks pretty good:

It's a string that's seen by users, and it'd be much better to translate it. They don't care that HTML has some internal feature for linking to #top, and would just see some randon word that sticks out from its surroundings:

There isn't even an equivalent that conveys the same thing as #top, because the web is already Latin/English-based. How is one supposed to tell the difference between a translation of top and a section named that? Note many languages don't have the notion of casing. The fact there's suddenly an English word efficiently conveys it's about something technical.

You seem to be coming from the perspective of an English speaker who's used to seeing everything in the same language. That is simply not the experience of the web for most people around the world. Never impose it on others without consulting them first.

/* top */ must be translated of course. There shouldn't be any non-localized strings in the interface :)

https://ru.wikipedia.org/wiki/MediaWiki:Gadget-edittop.js

Following the work @Samwilson and I have been doing during the Wishathon 2025, I’m sharing the explorations and WIP implementation so we can keep iterating (also shared in the task's description):

Design proposal:

• Include an option to edit the lead section within the first paragraph of the lead section (same as in App).
• Use a Tooltip when hover over the different edit options, indicating which part of the article will be edited.
• Depending on how much we want to unify the experience across skins and platforms — and how prominent we want the edit action to be — there are 2 possible solutions:
  1. Use the [edit] link on desktop and an icon-only button on mobile. This approach follows the current production pattern and maintains the traditional behavior.
  2. Use the pencil icon-only button across all skins. This option unifies the experience across platforms, making the edit action more prominent and visually inviting.

Using [edit] link on desktop	Unifying to pencil icon-only button in all skins

WIP implementation:

Engineer: @Samwilson

• https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1207828
• How to try out?: Vector-2022 & Vector
• Status:
  • Experimenting with Vector (both) to put the edit link in the 1st paragraph of the intro.
  • Unclear if it should be a skin feature or in Core. Or the new WikimediaCustomizations extension.
• Next steps:
  • Gate behind a feature flag, and add to the Experimentation Lab.
  • When VE isn’t installed, or in VE’s single-tab mode, use an icon instead of the word ‘edit’.
  • Regardless of the edit link, the prefilled edit summary could be added, e.g. /* top */

Open question to resolve before moving forward

• Do we want to replace the desktop [edit] link with an icon-only button to unify the experience across skins?

There shouldn't be any non-localized strings in the interface :)

top is not part of the interface. It's code. It's in the HTML specs. Translating it would mean adding an ID that varies by site language to every single wiki page, elements on which would need to avoid duplicating. That's a disruptive change nowhere near the scope of this task.

If you're proposing /* top */ appear translated rather than "→top" only in the parsed result (and still linking to #top), I can see some reason for it. But if you mean changing /* top */ and adding an ID to the top of every page, that's not something you should entertain so willy-nilly.

In T2156#11396289, @Nardog wrote:

If you're proposing /* top */ appear translated rather than "→top" only in the parsed result (and still linking to #top), I can see some reason for it. But if you mean changing /* top */ and adding an ID to the top of every page, that's not something you should entertain so willy-nilly.

What I'm saying is that the edit summary shouldn't contain English words that part of the user don't understand.

+1 Iniquity. The string in the edit summary should be localizable. Or...
Or, perhaps it should be left out entirely, if localizing it is much harder?
Or if there are concerns about the UX being confusing? (I.e. When *normally* the /* string */ results in a link to a relevant section (from History/Diff/Feed pages) but in these cases it won't.)
Personal context: I usually just delete that "/* top */" placeholder, when I'm editing with the gadget on Enwiki, as the "top" doesn't really provide any useful context beyond the edit summary I manually write; it's just clutter in my opinion/experience.

For reference, from a quick skim check of a few gadget examples:
The Viwikibooks gadget uses /* đầu */
The Srwiki gadget uses /* увод */ or /* topувод */ (I'm not certain what the distinction is, code-wise or linguistically)
The Frwiki gadget uses /* Introduction */ for French language users (and, perhaps confusingly(!?), uses /* Lead section */ for English language users. I imagine it ought to be consistent for everyone on a monolingual wiki-project?).

What I'm saying is that the edit summary shouldn't contain English words that part of the user don't understand.

I have news for you: The source of virtually any wikipage that's not in English contains—if not is littered with—English words. Sure, magic words and template names and parameters can be translated, but they frequently are not, and HTML(-like) tags can't be translated at all. Not to mention many punctuation characters in the ASCII set are culturally specific to Europe/anglosphere (less tech-savvy East Asian users are frequently confused when full-width characters don't generate code). /* top */ is code that generates a link to #top, which is in the HTML specs. That's no different from <b> or <span> or class=. If you think top should be translated then you should think those should be translated too (which I don't). If you think you're doing non-English speakers a service by translating it, I find that naive and short-sighted.

For reference, from a quick skim check of a few gadget examples:
The Viwikibooks gadget uses /* đầu */
The Srwiki gadget uses /* увод */ or /* topувод */ (I'm not certain what the distinction is, code-wise or linguistically)
The Frwiki gadget uses /* Introduction */ for French language users (and, perhaps confusingly(!?), uses /* Lead section */ for English language users. I imagine it ought to be consistent for everyone on a monolingual wiki-project?).

And those links lead nowhere! (Or worse, to the wrong sections.) I don't see any element with id="đầu" etc. on those wikis. It's clear they didn't understand top was code that means something in HTML, as these links show: #top / #đầu. One navigates you to the top of the page, the other does nothing. Porters on the other 100+ wikis seemingly understood that.

Vector

I find this intrusive and ugly, inhibiting the reading experience. If it's how it's going to be implemented, I'll keep using the edittop gadget, which defeats the whole point of this task viz. to make the gadget redundant.

The current position the gadget puts the link in is obvious and intuitive in Vector legacy and Timeless, as it's under the full page edit link. For Vector 2022 you might as well put it in p-cactions just like Minerva (but section and full page reversed).

Placing the [edit] link to the left of the infobox is actually technically quite complex and the WIP patch already shows some of this https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1207828. Aside from the fact that we are placing more UI within the content area, which will require some review by the Content Transform Team, it is essentially the same problem as lede-paragraph hoisting that is done on Mobile Web and Mobile Apps. Web and apps have slightly different implementations and neither are perfect. There is also some tech debt around those as well as outstanding tasks to unify the logic (T277367, T359002).

@Samwilson @Nardog @Iniquity @Quiddity Regarding /* top */ and #top, I think the ideal option would be to use /* */ when editing the lead section and make it link to # (currently it does not produce a working link), and display a special localisable message for that case in the edit summary renderer. That would keep the functionality, and wouldn't cause any localisation problems, as far as I can tell. It could be done here in the code.

Note that both #top and # are special cases in the HTML spec that link to the top of the document, although #top will instead link to an element with that ID if one is present, while # always goes to the top:

https://html.spec.whatwg.org/multipage/browsing-the-web.html#select-the-indicated-part

3. If fragment is the empty string, then return the special value top of the document.

(...)

10. If decodedFragment is an ASCII case-insensitive match for the string top, then return the top of the document.

I think we could split out the edit comment changes from this and into a new task, as we can implement that separately (after all, it's already possible to edit section 0; this task is about how to link to doing so — perhaps 21 years ago when the task was opened, it was about the whole lot). Those are good ideas @matmarex about how to link and localize it. I agree that we shouldn't implement anything that's not translatable.

Strong agree @Esanders on the above approach to adding in the edit link being not a very good way to do it! :-) I just wanted to get something working during the wishathon last week. It's how MobileFrontend is doing it, but surely we shouldn't need to be re-parsing the HTML to do this. If we agree on where the link should go, we can figure out how to implement it properly.

Adding a 'edit lead section' link to the tools menu is much simpler, and might be the easier thing to do here. That wouldn't get in the way of anyone, and it'd echo the 'edit full page' menu item that's on mobile.