Last modified: 2009-05-06 20:52:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17575, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15575 - action=edit&section=NAME not NUMBER is smarter
action=edit&section=NAME not NUMBER is smarter
Status: RESOLVED DUPLICATE of bug 9239
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.14.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-12 09:55 UTC by Dan Jacobson
Modified: 2009-05-06 20:52 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2008-09-12 09:55:51 UTC
(Here is a wishlist item for year 2015, so don't hit WONTFIX so fast,
thank you.)

Offline (or perhaps various cached states) users of MediaWiki often
queue links like ...&action=edit&section=6 on their PDAs etc. devices
with the intention to edit when they later attach to the network,
which might even be several days later.

The problem is links like &action=edit&section=6 might now refer to
the wrong section, as in the meantime, the sections might now have
been somewhat changed by other editors activity.

A much more successful scheme would be
&action=edit&section=The_Nurdsburg_Tales,
corresponding to the anchor #The_Nurdsburg_Tales.
Just use the same string that you would when safely encoding this
anchor for use in URLs.

One might say "but what about subsections with the same name? That's
why we use section numbering. Case closed."

However, MediaWiki already deals with this case by appending _1, _2,
... so no problem.

Indeed, this is identical to the wisdom and stability of Pie#Apple vs.
Pie#12345 where 12345 is a byte offset, or Pie#11 where 11 is the 11th
section.

I only found some slightly related bugs, e.g., bug #9239, but no exact
duplicates.
Comment 1 Roan Kattouw 2008-09-12 12:56:16 UTC
(In reply to comment #0)
> (Here is a wishlist item for year 2015, so don't hit WONTFIX so fast,
> thank you.)
>
> (snip)
>
> I only found some slightly related bugs, e.g., bug #9239, but no exact
> duplicates.
> 

Weird, I thought there had to be dozens of duplicates of this one. It's been a wishlist item for ages. The reason this bug hasn't been fixed is probably that there are too few people who understand both the parser and EditPage well enough to implement this is one go. So ideally, someone who knows the parser well enough should write some code that gets a section by name, and let some else handle the front-end part (or do it themselves, of course, if they can).
Comment 2 Huji 2008-09-12 18:26:33 UTC
(In reply to comment #0)
> The problem is links like &action=edit&section=6 might now refer to
> the wrong section, as in the meantime, the sections might now have
> been somewhat changed by other editors activity.
I assume they won't be able to save to the wrong section of the article then, because they will instead get a notice that the page has changed since they started editing it. Then, they can go back and try to fix the correct part of the page. This is not an issue for PDA users only; PC users also experience this if they keep an edit page open for a while before submitting it.
Comment 3 Dan Jacobson 2008-09-13 00:42:54 UTC
Though I am mainly frustrated that section=7 is now something
different before I pull it in to my computer to edit it, maybe fixing
this bug will also fix the case Huji mentioned when what section=7
refers to changes while one is editing it.
Comment 4 Roan Kattouw 2008-09-13 11:18:13 UTC
(In reply to comment #3)
> Though I am mainly frustrated that section=7 is now something
> different before I pull it in to my computer to edit it, maybe fixing
> this bug will also fix the case Huji mentioned when what section=7
> refers to changes while one is editing it.
> 

It probably will, but it'll also introduce a new issue: section names can change too, so section=foo can suddenly point nowhere because someone else changed its name to bar. If there were multiple sections called foo, section=foo will now point to the second foo section (which is now the first one).
Comment 5 Dan Jacobson 2008-09-13 11:35:29 UTC
OK, but that is probably worth it vs. the much more common event that
somebody has slid in or removed a section above us. Reminds me of
http://jidanni.org/geo/house_numbering/ here in Taiwan when a new
house ruins every thing: 11, 13, 15, 15-1, 17, 19.
Comment 6 Roan Kattouw 2008-09-13 11:53:05 UTC
(In reply to comment #5)
> OK, but that is probably worth it vs. the much more common event that
> somebody has slid in or removed a section above us. Reminds me of
> http://jidanni.org/geo/house_numbering/ here in Taiwan when a new
> house ruins every thing: 11, 13, 15, 15-1, 17, 19.
> 

We just use 15a in that case. Has led to some very confusing numbering schemes, though, like 15A-15-15C-15B-16B-16A-16-...

But you're right about the fact that section renames are rarer than section insertions and deletions.
Comment 7 Dan Jacobson 2008-09-18 13:41:03 UTC
Also if one has the preference set to show section numbers,
"[*] Auto-number headings", I believe, then with e.g.,
[edit] 10 External links
there is a good chance they will not match the section= numbers.

(So if one insists on using numbers for section=, then one at least
should go the section=1.3.2 route.)
Comment 8 Chad H. 2009-05-06 20:52:32 UTC

*** This bug has been marked as a duplicate of bug 9239 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links