There is no need for any preference. It simply needs to be ensured that the link doesn't disturb page layout.

With the current float-right section-edit links this is problematic as that area is frequently home to floating info boxes or images.

If section-edit links are moved to the left margin (before header text) or inline after the header text, then where should the section-0 edit link go?

MediaWiki wrote:

(In reply to comment #38)

There is no need for any preference. It simply needs to be ensured that the
link doesn't disturb page layout.

With the current float-right section-edit links this is problematic as that
area is frequently home to floating info boxes or images.

If section-edit links are moved to the left margin (before header text) or
inline after the header text, then where should the section-0 edit link go?

Having seen the action=render pages, I know I don't like having the [edit] links on the left (and no, making them smaller wouldn't help). This is purely cosmetic, but I think they should stay on the right.

As for vertical placement, I don't see what's wrong with putting them on the same line as the title. It's out of the way... Sure there are some icons and stuff up there (actually, my [[User talk:Voyagerfan5761|talk page]] has a position:absolute box), but there has to be a way to work around existing stuff.

random832 wrote:

For the interface, it's worth mentioning that (via a site javascript) Malay Wikipedia apparently does this as a tab.

circeus wrote:

This preference seems to have been enabled on en:, why is the bug still open?

MediaWiki wrote:

(In reply to comment #41)

This preference seems to have been enabled on en:, why is the bug still open?

The preference on the English Wikipedia is the one in the Gadgets tab, yes? That's not part of the MediaWiki core; it's a piece of JavaScript. This bug aims to add one in the output HTML by default when section-edit links are enabled, whether or not the user has JavaScript available.

ayg wrote:

To confirm, implementing things like this in JavaScript is not acceptable in core for a wide variety of reasons. It's not acceptable at all, really, except that enwiki has no other way to implement it since it can't change the software, so it has to settle for JS.

ayg wrote:

(In reply to comment #13)

The section edit link can be added to MediaWiki: namespace pretty
straightforwardly by an admin if any given wiki wants it. So this is really
something for each wiki to decide, and should be WONTFIX.

(In reply to comment #43)

To confirm, implementing things like this in JavaScript is not acceptable in
core for a wide variety of reasons. It's not acceptable at all, really, except
that enwiki has no other way to implement it since it can't change the
software, so it has to settle for JS.

Someone has pointed out to me that these sentiments seem to conflict somewhat. To clarify, I no longer agree with the statement I made 19 months ago (before I was even a dev) in comment 13. JavaScript is a bad solution to this, by admins or anyone else. I'm just not convinced that I've seen any very good placement of the edit link by anyone, where its function is at least somewhat obvious and where it doesn't clutter the interface. (Not that edit links are currently placed reasonably for *other* sections.)

A tab (in Monobook) is too much clutter to be justifiable, IMO. And it's not similar enough to the other section edit links to be obvious. One that floated to the right just below the main header might be reasonable, although it would horribly break all the infoboxes, unless those get cleared right.

The first section is much less in need of a section edit link, honestly. If you click "edit" at the top, you're brought right to the first section; and it's not like edit summaries are any more informative (AFAIK) when you do a section edit with section=0. The only utility I know of is slightly lower loading times and ability to edit in some ancient (or possibly mobile) browsers that can't handle big textareas. Both are honestly somewhat marginal advantages, and arguably don't justify the clutter of an extra button, which is a very real cost. I would be inclined to leave this up to skin authors, and WONTFIX as a general software request, or a request for long-established skins like Monobook.

bugs wrote:

To disagree with Simmetrical on the importance of this:

• Editing big pages in a text area is perfectly possible in modern browsers, but it's still a pain in the arse.
• When using the "preview" function, it's a similar PITA to have to render the entire page when you're working on the lead. It also moves the edit box a very long way from the rendered version.

So, nice edit summaries or browser incompatibility are not the major reasons for section editing: working with manageable sized chunks of wikitext and rendered HTML are.

A compromise might be to add an extra link when editing the entire article to edit "just this section" or something. Then you don't lose screen real estate at view time, you get the advantages described above, and the only cost is an extra pageview/mouseclick.

alfred.maghi wrote:

This feature is already there:

• With interface messages in core: you can use the "&action=edit&editsection=0" in MediaWiki interface messages to add an extra link when editing the entire article (look at [[MediaWiki:editnotice]] messages);

• With JavaScript: you can use the "edittop" javaScript for user gadget or for importing in common.js ; http://www.mediawiki.org/wiki/MediaWiki:Gadget-edittop.js & http://www.mediawiki.org/wiki/Extension:Gadgets/Scripts

I just ran update.php, and in the above URL that I just put in the top of this bug, there are only edit links for the remaining sections. That is all I can figure out.
Also I put an accessibility keyword in, as you should provide a solution for text browsers too.

ayg wrote:

(In reply to comment #46)

This feature is already there:

• With interface messages in core: you can use the "&action=edit&editsection=0"

in MediaWiki interface messages to add an extra link when editing the entire
article (look at [[MediaWiki:editnotice]] messages);

• With JavaScript: you can use the "edittop" javaScript for user gadget or for

importing in common.js ;
http://www.mediawiki.org/wiki/MediaWiki:Gadget-edittop.js &
http://www.mediawiki.org/wiki/Extension:Gadgets/Scripts

That is not a fix. That is a way for users to work around the problem. The request is to fix it, by default, in the core software.

Perhaps someone should ask the people working on Vector about this.

alfred.maghi wrote:

(In reply to comment #48)

That is not a fix. That is a way for users to work around the problem. The
request is to fix it, by default, in the core software.

As there is a core solution with URL link: title={{FULLPAGENAME}}&action=edit&editsection=0 the bug matters with where to add an extra edit-top link. As there is non a consensual need and place in interface for this, it seems WONTFIX.

Those comments lead to WONTFIX status:

(In reply to comment #38)

There is no need for any preference. It simply needs to be ensured that the
link doesn't disturb page layout.

With the current float-right section-edit links this is problematic as that
area is frequently home to floating info boxes or images.

If section-edit links are moved to the left margin (before header text) or
inline after the header text, then where should the section-0 edit link go?

(In reply to comment #12)

[[Wikipedia:WikiProject User scripts/Scripts/Add edit section 0]] and
[[Wikipedia:WikiProject User scripts/Scripts/Edit Top]] are implementations of
this. I would suggest marking the bug WONTFIX, as implementation details are a
bit iffy, and it's probably better to leave it to the users to choose which they
prefer.

(In reply to comment #34)

There will likely a large ammount of opposition if this is introduced into core
code by defualt, one solution would be to add it as a configuration variable or
preference - however they are already very overused. Another problem is the
location of such a link, currently there are several skins and the link would
have to find a different place in each, one solution would to just put it in
the top right corner (or left in rtl mode) of the artcile - however if an
infobox were being used that would look ugly.

Therefore I suggest that this be closed as WONTFIX because it can easily be
added if someone wants to make their own skin, or via CSS\JS.

(In reply to comment #15)

Yarg, that was destined to send another bug to hell.

ayg wrote:

Please do not resolve bugs as WONTFIX unless you're a MediaWiki developer. Thank you.

Al: It seems you are proposing that one use {{fullurl}} in combination
with title={{FULLPAGENAME}}&action=edit&editsection=0 on pages where
is desperate enough to do that just to get a way to edit section 0.

All I know is Junior's shirt looks ugly with the top button missing,
and that is a giant button you are proposing, when viewed from inside
the garment.

Anyway, I never looked under the hood... all I can tell you is from
the outside, yes, clothes look good with the top button open, but they
always still have that button, if one day the wind blows and you want
to close it.

I am not sure this way can work or not:

Introduce a new global variable like $enableEdit0SecLink = false;
This can be set by site admin whether to make that enabled or disabled
by default on that site.

Also, set a check box toogle on user preferences and let the users to
display the link or to suppress it.

mike.lifeguard+bugs wrote:

This doesn't seem to have anything to do with accessibility -> removed the keyword.

FYI, it seems this is something that is being considered for the next iteration of the usability initiative work. See also http://usability.wikimedia.org/w/index.php?title=File:Contents.pdf&page=1

(In reply to comment #53)

This doesn't seem to have anything to do with accessibility -> removed the keyword.

Perhaps need a 'usability' keyword. E.g., perfect for bug 20116, that baffled an oldster.

en.wikipedia has the gadget "Add an [edit] link for the lead section of a page". It would be great to have it enabled by default in Vector, and in Monobook, too.

Currently in Malayalam wikipedia using some templates on right side of Article title. (Some templates are important, such as [[:w:ml:Template:Prettyurl]], which provides a non percentage encoded redirect URL for a particular article URL, helps redistributing article URL).But may be lead section edit link become helpful to some people. So adding a check box option in preference's edit tab will be useful for them to enable it. I can see lot of blank space at tabs position of non-special pages (Vector skin). Adding there an additional tab for 0-th section editing may be not a big issue.

(In reply to comment #57)

Currently in Malayalam wikipedia using some templates on right side of Article
title. (Some templates are important, such as [[:w:ml:Template:Prettyurl]],
which provides a non percentage encoded redirect URL for a particular article
URL, helps redistributing article URL).But may be lead section edit link become
helpful to some people. So adding a check box option in preference's edit tab
will be useful for them to enable it. I can see lot of blank space at tabs
position of non-special pages (Vector skin). Adding there an additional tab for
0-th section editing may be not a big issue.

It's not a big issue. It's very very trivial to add a section link for the 0th section. The issue has been on where to put it.

We've been discussing it for almost 6 years now. It's absurd.

• Bug 26981 has been marked as a duplicate of this bug. ***

• Bug 4888 has been marked as a duplicate of this bug. ***

bruno-wikimediabugs wrote:

If you want to enable this for your own MediaWiki installation, there is still some leftover code in Parser.php that makes it quite easy:

Index: includes/parser/Parser.php

• includes/parser/Parser.php (revision 87502)

+++ includes/parser/Parser.php (working copy)
@@ -3809,13 +3809,14 @@

		$i = 0;

		foreach( $blocks as $block ) {

• if( $showEditLink && $headlineCount > 0 && $i == 0 && $block !== "\n" ) {

+ if( $showEditLink && $headlineCount > 0 && $i == 0 && $block !== "" ) {

1. This is the [edit] link that appears for the top block of text when
2. section editing is enabled
3. Disabled because it broke block formatting
4. For example, a bullet point in the top line
5. $full .= $sk->editSectionLink(0);

+ $full .= $sk->editSectionLink($this->mTitle, 0, "Intro") . "\n";

			}
			$full .= $block;
			if( $enoughToc && !$i && $isMain && !$this->mForceTocPosition ) {

Note that section=0 is different to all other headings where subheadings ARE included in the edit. If I cared enough I'd add a new suggestion that existing [edit]s only edit their section and not subsections. Again this would need to be a configurable option to avoid retraining everyone...

sumanah wrote:

Adding link to a Wikipedia Village Pump discussion about this: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&oldid=508962495#Activate_section_0_edit_link_for_everyone

Conclusion:

"There is a strong consensus in favour of the proposal in principle. Several editors raise concerns that the section 0 link might be confusing for editors (particularly new, but also experienced editors who weren't expecting it) and these concerns are worthy of consideration. Support for the revised proposal to label the link in a way that would not cause confusion was unanimous.

I recommend that the wording of the link be worked out, and then that the applicable modifications be made to the interface, via a Bugzilla request if developer intervention is required."

The main problem here is finding a good user interface for it. Especially avoiding further complication of the user interface.

Putting an [edit] link on top looks weird and out of place, because as pointed out there is no heading for it.

So far we've managed by holding up that to edit the text before the first section, use the main "Edit" tab for the entire page. Its not ideal, but it works without problems.

A better editor will take care of this problem, for example in VisualEditor.

So is this really a problem in the long term? If so, we'll need to figure out a way to do it without compromising the interface. I don't see a way to do that.

I believe my current settings have the "show edit section 0" and "show [edit]s on the RHS, rather than next to the heading text" settings on and as far as I know no other settings adjust these.

For me the [edit] links all line up on the RHS of the page (I know there are variances when there are images on the RHS, but that's OK) including the section 0 [edit].

They all have tooltips saying "Edit section: <section title>", except for section 0 which just says "Edit section: 0".

The edit section 0 link is on the page heading and a long way a way from the "edit this page" tab (in Monobook). It is not quite as far apart in Vector, where the edit the whole page "tab" is just called "Edit".

Perhaps Vector's "Edit" needs to be expanded to "Edit this page", like Monobook.

Adding a design keyword to get feedback from designers.

Raising priority from low to normal. As this is an often required thing by several wikis, outside the foundation wikis, we should at lease settle to offer the section edit link as an option.

Of the many things this is not, "UNCONFIRMED" is probably the top of the list. Not sure why it was set to this state?

(In reply to comment #67)

Not sure why it was set to this state?

How to express that something is likely to be wontfix'ed?
It's almost impossible to find an acceptable way to do this. I like this feature a lot as super-user, and it looks good enough on monobook where a "0" tab takes very little space, but most implementations are unacceptable.

This has been implemented and enabled by default on pl.wikipedia for years. I've never heard any complaints.

Example page: https://pl.wikipedia.org/wiki/Zręczyce

This works in pair with moving the edit links next to headings and making them smaller; this way, we can implement the edit link for 0th section in a similar way.

This can be trivially fixed in the manner done for plwiki when bug 41729 is resolved. Adding as a dependency.

• Bug 47416 has been marked as a duplicate of this bug. ***

I'm going to work on this.

(In reply to comment #72)

I'm going to work on this.

This bug isn't a simple technical fix. There is a lot of debate over the right way to do it.

As the Target Milestone on this ticket has been set to 1.22.0:

According to http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072030.html "MediaWiki 1.22 is slated for release on November 30th, at the very latest."

If this is still intended to get fixed for 1.22.0, a patch is needed soon.

Doesn't seem plausible to me, to be honest, so I'm removing it. Sadly I ended up doing other things and I won't have as much free time now.

The fact is that nobody is working or planning to work on this. Not only in the plain wikitext interface, for what I can see VisualEditor and Winter don't have a concept for "editing the first sections separately".

In fact VisualEditor got rid of the concept of "editing sections".

This request, reported almost a decade ago, pointed to a solution instead of a problem: " Add section edit link for 0th section". The problem mentioned was "This is especially bad if the page is very large where the complete page has to be loaded and saved back to the database."

I would welcome a reassessment of this problem under the light of VisualEditor, and opinions on whether it is still worth keeping this request open, or resolve it as WONTFIX.

In the meantime I'm changing the resolution to Lowest in order to reflect the current situation. Feel free changing it if you want to work on this.

(In reply to Quim Gil from comment #76)

I would welcome a reassessment of this problem under the light of
VisualEditor, and opinions on whether it is still worth keeping this request
open, or resolve it as WONTFIX.

IIRC VE works with deltas so a VE section edit mode would send back to the database the same minimal amount of data in a section edit mode as it would when editing a small bit of an entire page.

Also they were hoping for the parsoid DOM to be capable of being served as the page contents themselves so the "download the whole page" part would be eliminated as well since someone reading the article to hit edit section would already have the whole page parsoid DOM.

This is not lowest priority. Solving the bug is easy, the problem is that a design has not been agreed upon. Setting UNCONFIRMED again, nobody proposed alternatives.

At this point I'm afraid the only solution may be a user preference... Another solution that would probably be approved easily enough if someone submits a patch is section edit on double click (when the corresponding preference is enabled).

(In reply to Chad H. from comment #58)

It's not a big issue. It's very very trivial to add a section link for the
0th section. The issue has been on where to put it.

What you are saying is: the complexity of this problem is to decide the UX, after that the technical implementation should be simple. Correct?

Is it worth discussing UX solutions in the context of VisualEditor UX and/or Winter UX, trying to adapt whatever decision to barebones MediaWiki?

Quim, I totally misunderstood this bug. This is being handled via the Winter work, assigning to brandon. see https://www.mediawiki.org/wiki/Winter

(In reply to Quim Gil from comment #79)

What you are saying is: the complexity of this problem is to decide the UX,
after that the technical implementation should be simple. Correct?

I believe so. See Comment #38 in particular.

The issue with the existing gadgets/scripts, was historically that they:
(A) interfere with right-floated top-icons (Featured article stars, Protection padlocks, etc), eg http://i.imgur.com/KFXDc0a.png
This is still the case for users (like me) who use the Gadget "Move section [edit] links to the right side of the screen."
(B) Are ambiguous. (Ie. a newcomer might expect that top-right-link will let them edit the whole article)

Nowadays, with Vector's current left-floating edit-links, it looks like this,
http://i.imgur.com/3Tvz7Lu.png
Which makes problem (B) even worse.

Changing the wording for this link only, has been suggested before as the solution. "Edit intro" had unanimous agreement in the last (August 2012) discussion at Enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_92#Activate_section_0_edit_link_for_everyone I'm not sure why that didn't get pushed through afterwards.

With VisualEditor added in, it gets a bit more complicated... On Enwiki, we'd end up with this:
[edit intro source] [edit intro ^beta]

The code is easy. Where to put the links (and how to label them) is not.

Is it worth discussing UX solutions in the context of VisualEditor UX and/or
Winter UX, trying to adapt whatever decision to barebones MediaWiki?

Yes. Because other skins, and other sites.

(In reply to Jared Zimmerman (WMF) from comment #80)

It's called "section 0" (by everyone, hence I'm renaming back) because that is the name in the URL, eg. https://en.wikipedia.org/w/index.php?title=Foobar&action=edit&section=0
(Whereas if you click [edit] on the first H2 header, it goes to section=1)

Note on stats: According to [[Wikipedia:Database_reports/User_preferences]], at Enwiki, there are 23,691 editors who use the "edittop" Gadget, and 954 editors who use the "righteditlinks" Gadget.

I don't know how or since when, but nowadays mediawiki.org articles feature an [edit | edit source] combo next to "Edit lead section".

Resolved? If so, by whom?

PS: fyi, this is the oldest assigned open task in Phabricator.

EDITED: meh, I should have read above. This comes from this setting in my Gadgets preferences

• Add an [edit] link for the lead section of a page

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-Backlog.

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"