Last modified: 2014-11-17 10:36:46 UTC
When an article consists of different sections and the first section does not contain a header (== header ==) it can not be edited seperately but you have to edit the complete article to change the section. This is especially bad if the page is very large where the complete page has to be loaded and saved back to the database. Suggestion: let Mediawiki check if there are sections, if so and there is no heading in the first one craeate a link to edit this first section (if there is a header there is no problem). For examples take a look at http://de.wikipedia.org/wiki/Wikipedia:Mailinglisten and you see what I mean.
As far as I can tell, the "Classic" skin does have this link for editing the "0th" section. However, people found it annoying because it interferes with other right floating elements. Hence, I suppose, it was removed in Monobook. You can still edit the "0th" section by clicking the "edit" link for the first section (or any other section) and then manually changing the URL, replacing the number with a 0. > This is especially bad if the page is very large where the complete page has to > be loaded and saved back to the database. The complete page has to be loaded from the database and saved the back to the database anyway. Section editing only reduces the amount of data sent to and from browsers, not to and from the database.
(In reply to comment #1) > As far as I can tell, the "Classic" skin does have this link for editing the > "0th" section. However, people found it annoying because it interferes with > other right floating elements. Hence, I suppose, it was removed in Monobook. Unfortunately, it was also removed from Cologne Blue, where it caused no such problems. Perhaps we can consider replacing it in Cologne Blue? > You can still edit the "0th" section by clicking the "edit" link for the first > section (or any other section) and then manually changing the URL, replacing the > number with a 0. Yes, but this really isn't a useful/workable solution. > Section editing only reduces the amount of data sent to and > from browsers, not to and from the database. This makes having to load the entire page just to edit section 0 hard on users with slow internet connections.
on extremely long non-article pages you could always put an edit intro section link in the page text itself using external link syntax.
Would it be possible to create an "Edit first section" tab next to the "Edit this page" tab at the top of the screen (at least thats where it is in monobook) to avoid disruption to the page layout. This would will be useful for reducing edit conflicts on articles like the 7 July 2005 London Bombings that are getting rapid-fire editing. Chris
Please note that using the section-edit links does *nothing* special to avoid edit conflicts. Conflicts are merged (or not) from the full text, precisely the same way whether using section edit mode or not.
I don't believe an extra tab would work. It's too specific, and a little obscure. Use prinicipal of least surprise and have an edit link at the top of the first section, like for all the other sections. I can see the problem of the edit link interfering with right floating elements, but this happens throughout the page, not just at the top. Perhaps if we made sure that the edit links were in a narrow margin to the right (or left!) of the text and that this margin contained no other content, it would be clearer. Not sure whether that would be possible using CSS though.
Can the top edit link be placed on the same line as "From Wikipedia, the free encyclopedia." ?
That would not be consistent with the rest of the page. I think it should go on the same line as the article title.
*** Bug 3166 has been marked as a duplicate of this bug. ***
See http://commons.wikimedia.org/w/index.php?title=User:Alphax/monobook.js&action=edit (not mine, I just found it) for a per-user way to add an edit tab for section 0.
*** Bug 4257 has been marked as a duplicate of this bug. ***
[[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.
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.
> Status|ASSIGNED |RESOLVED > Resolution| |WONTFIX This is disappointing. Not being able to edit the first section is (a) irritating (b) confusing and (c) un-workroundable for 'non-technical' users.
Yarg, that was destined to send another bug to hell.
(In reply to comment #14) > > Status|ASSIGNED |RESOLVED > > Resolution| |WONTFIX > > This is disappointing. Not being able to edit the first section is (a) > irritating (b) confusing and (c) un-workroundable for 'non-technical' users. First decide what you would like the placement to be. Then it can be added to whatever wiki you would like by its local admins, after appropriate community discussion. That's the workaround for non-technical users.
Maybe to put this in users preferences, but default set off. So, if user want, he can turn on this option in his preferences and if he think that this is stupid he can leave it turned off. I think that this is best way of solving this bug request. Sasa
(In reply to comment #7) > Can the top edit link be placed on the same line as "From Wikipedia, the free > encyclopedia." ? (In reply to comment #8) > That would not be consistent with the rest of the page. I think it should go on > the same line as the article title. Actually I like the idea very much. If you place it on the same line as the article title, this would imply that you're editing the "entire article" by placing it underneath, you indicate that this edits something else, in this case section 0. This visual cue would indicate to the editor that this edit link may not work exactly as the others. Also, I do think "WONTFIX" is rather disappointing.
I also really want to have an "Edit intro" link at the article title.
*** Bug 9208 has been marked as a duplicate of this bug. ***
I think I suggested a button like that in a bug report perhaps half a year ago. I also made a related suggestion that I'd like to make again here: After the last section in the article, before end matters like some templates, categories, and interwiki links, one might be allowed to enter a text - say a dummy heading like ==endmatter==, or a template - not to be displayed, but producing an edit link to edit the (usually unprintable) stuff following the last section - with a corresponding automatic edit summary /* Endmatter */. - I suppose, as with the "topmatter" edit link suggested in this bug report, placement is an issue.
(In reply to comment #21) > I also made a related suggestion that I'd like to make again here: . . . Different issues should go in different bugs, please. In this case, the bug in question was bug 9100 and any discussion should be there.
(reply to comment #22) Yes different issues should go in different bugs. However, I made ONE bug report with both suggestions back then, and I still think one might consider it to be ONE issue: How to edit a part of an article in an orderly fashion through an Edit link producing a relevant brief edit summary. There are currently two parts of an article causing problems: The lead (which you cannot edit at all without opening the whole article), and the end matters (which you can only edit by editing whatever section happens to be the last one before the end matter). When evaluating a suggestion for placing the edit link for the lead, one might consider whether an end matter edit link could be made in a similar way. Of course, actually MAKING the last edit link would require some further discussion, in this or in a separate bug. As the issues are closely connected, I think it is most orderly to have a brief "show of hands" here - if I am the only one missing the last edit link, there's really no need for that second bug report.
Yes need very badly a link at the top of the page to edit section 0! No need to send the whole page down the phone lines to the user where it can only get mangled. Yes we can craft the URL by hand but that isn't just a click away. Anyway, one looks and wonders what happened to the [edit] link at the top, of a page. It looks just plain missing.
"Yes need very badly a link at the top of the page to edit section 0!" This is becoming increasing bothersome as more stuff is _exactly_ in the area where this link would be, especially (bot not only) in the English Wikipedia. if,for whatever reason, a Featured article is protected, it's outright impossible to use the section edit link added via script. And now there is talk of adding a GA icon again. This issue needs to be properly settled ASAP so angst and annoyances at such a fuzzy situation can be cleared out!
(In reply to comment #25) > more stuff is _exactly_ in the area where this link would be All I know is with stylesheets and javascript turned off, everything falls into its proper place... That's what I do when all those goofy templates start overprinting each other. > impossible to use the section edit link added via script. The fix should be made to whatever .php program adds those [edit] links: you've got a bug: the array starts at 0, not 1! So don't forget the first [edit] link. There, I've stepped back and given you the totally surface examination of the problem, with out looking under the hood and seeing what the big deal is.
"without looking under the hood and seeing what the big deal is." Indeed, although I admit I wasn't too clear. I use this script ([[Wikipedia:WikiProject_User_scripts/Scripts/Add_edit_section_0]]) to add a 0th section edit link where it would be if it was active. However, there are at least 3 templates that cover it in part and, at least in Firefox, may thoroughly interfere with the link and make clicking it complicated at best: [[Template:Protected2]], a popular alternative to the so-perceived obnoxious protection banners, [[Template:Featured article]] and its variants for lists and portals, and 2 non-template icons that areused by the Japan and videogames projects. See e.g. [[Wikipedia:WikiProject Digimon]]. Assuming the link ever comes in default, all those will have to be moved out of the way. It is pertinent for users of scripts to know whether there is hope for these icons to ever be out of the way.
Note that this script is now installable as a 'gadget' on Wikimedia sites, so users are able to enable this feature via their user preferences if they choose to. I don't know if that is considered sufficient to mark this bug as either FIXED or WONTFIX...
Please do not mark it as fixed. This is an issue for all MediaWiki sites, not just the English Wikipedia.
I didn't realise it was only enabled on some sites. I stumbled across it on Simple English, and then on En - I therefore assumed that it was available on all WMF sites.
This bug is for MediaWiki (thus Product: MediaWiki), *not* any particular site. It cannot be fixed unless the fix is in the default, core software, with no extensions.
It can be WONTFIXed though - I've seen that happen before, and for more deserving bugs than this.
The change does not the same as the javascript hack. There should not be any visual changes (not even in RTL languages), if it does. Why should the bug be WONTFIX'd if there allready was a try to fix it, but there where minor faults?
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.
You might say that buttoning the top button of your shirt makes your "skin" uncomfortable, but I say this move toward section button uniformity is a step in the right direction, and it's the skins' fault for making whatever assumptions they make. As for CSS/JS to repair the first button, why not instead allow those who object to repairing the first button to use CSS/JS to "break" their favorite button(s): more flexible.
Sorry, Minute Electron; I agree with jidanni. Uniformity of editing tools would be a big step in the right direction. MediaWiki has several features that are available but aren't very user-friendly. The fact that one has to edit the whole page in order to edit the top section without modifying URLs manually is a big usability mistake. If some people don't like the new links, they should just be given IDs (as most skin links are anyway) so they can be hidden with site CSS. Or there can be configuration variables, or a UPO. If 0th section edit links are added, I could see a sub-preference to the current "Enable section editing via [edit] links" that would be enabled and disabled depending on whether the main option was checked, labeled "Include intro section [edit] link" or something like that. Yes, we know how much Brion hates adding preferences, but I think this one would be justified.
> "Include intro section [edit] link" or something like that. > Yes, we know how much Brion hates adding preferences, but I think this one > would be justified. The fact that a page will now have e.g., 28 edit links instead of 27 I am sure will disturb no user, so no new preference should be added.
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 #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.
For the interface, it's worth mentioning that (via a site javascript) Malay Wikipedia apparently does this as a tab.
This preference seems to have been enabled on en:, why is the bug still open?
(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.
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.
(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.
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.
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.
(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.
(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. >
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.
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. ***
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 !== "" ) { # This is the [edit] link that appears for the top block of text when # section editing is enabled # Disabled because it broke block formatting # For example, a bullet point in the top line # $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...
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§ion=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.
