gangleri wrote:

changed to WORKSFORME
follow versions beginning with
http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&oldid=18707450#Jayjg

Regards Reinhardt [[user:gangleri]]

gangleri wrote:

P.S. to comment 1 (WORKSFORME with Windows XP and Firefox)

regarding last note in comment 0

I've also noticed a problem with having duplicated heading titles. The second

heading title in the TOC, when clicked, jumps to the first section name.
this is bug 111 - "Bug 111: Return to page after edit of section (where section
name occurs multiple times)"

gangleri wrote:

Hallo!

I think the original bug report relates to return after edit sections.

after edit (maybe just edit, preview without changes) you will return to
http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#.5B.5BUser:Jayjg.7CJayjg.5D.5D_-_.5B.5BUser:TShilo12.7CTshilo12.5D.5D

The anchor in the TOC is just #Jayjg_-_Tshilo12 - see
[[en:Wikipedia:Administrators%27_noticeboard#Jayjg_-_Tshilo12]] .

Changed subject to "return after edit sections using headings with wikilinks
returns to other anchors then the ones used in TOC".

This bug is quite old and has been seen in earlier versions too. This might be a
duplicate.

Best regards Reinhardt [[user:gangleri]]

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

gangleri wrote:

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

gangleri wrote:

for impact on pages history see
bug 2346: Special characters break section links in page history

zigger wrote:

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

robchur wrote:

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

robchur wrote:

This one depends upon someone developing an effective function to turn wikitext
back into plaintext, which would, in a sense, be a mini-parser. Assigning to
self, but this is going to be ongoing.

dbenbenn wrote:

(In reply to comment #9)

This one depends upon someone developing an effective function to turn wikitext
back into plaintext, which would, in a sense, be a mini-parser. Assigning to
self, but this is going to be ongoing.

That seems wrong to me. MediaWiki ''already'' knows how to turn the wikicode
of a section title into an anchor; that's what is used in the actual ToC links,
and in the section anchor names. All that's required is for the section-editing
code to use the same method. Avoid duplicating code!

robchur wrote:

(In reply to comment #10)

Shockingly, I was already scouting round and checking for things to avoid that.

gangleri wrote:

(In reply to comment #9)

... Assigning to
self, but this is going to be ongoing.

Thanks Rob for taking this bug!

If you change TOC issues please see if you can fix also:
Bug 4039: BiDI: please preserve dir="ltr" and dir="rtl" in TOC

Bug 4050: BiDi: orientation and numbering inside a TOC should be left aligned if
placed in a LTR block and RTL if not
is very complex. Please keep it in mind when change TOC issues.

best regards reinhardt [[user:gangleri]]

gangleri wrote:

Dear Rob!

Created
http://test.wikipedia.org/wiki/User:Gangleri/tests/bugzilla/section_links/wiki_syntax
with many unusual sections using all kind of wiki syntax.

Please take a look also at the "→" ("autocomment") links:
http://test.wikipedia.org/w/index.php?title=User:Gangleri/tests/bugzilla/section_links/wiki_syntax&action=history
Many of them are broken. Breaking "Return after section" does *not* correspond
one to one with breaking "autocomment"

best regards reinhardt [[user:gangleri]]

robchur wrote:

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

wikt.3.connelm wrote:

Worksforme.
http://en.wiktionary.org/w/index.php?title=MediaWiki:Monobook.js&diff=prev&oldid=1144333

chrislb wrote:

You forgot
.replace(/^:/g, "")
in case of a linked category.

dbenbenn wrote:

(In reply to comment #16)

You forgot
.replace(/^:/g, "")
in case of a linked category.

Well, not quite. You don't want to break

:[[Foo]]

which should become #:Foo

Also,

[[Foo

currently doesn't work, since the Javascript turns it into #Foo when it
should remain #:.5B.5BFoo. This workaround is better than nothing,
but I guess it isn't feasible to make it perfect. You'd have to
build in a complete MediaWiki parser to fix all possible cases. (Actually,
you could just copy whatever part of MediaWiki makes the section IDs.)

robchur wrote:

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

wmahan_04 wrote:

Proposed fix

Here is a simple patch that seems to fix the problem.
This uses the same code as my proposed fix to bug 2346,
only in a different place.

I didn't write a mini-parser as described in
comment #9, and things like italics in headings
still break.

attachment 2831.diff ignored as obsolete

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

This has *finally* been fixed by TimLaqua in r25573. All hail Tim ;)

ayg wrote:

This has not been fixed fully, only some of the simplest cases have been. Try, for instance:

{{CURRENTTIME}}

This cannot be fixed until either we make section anchors based on raw wikitext and not the parsed version, or we run the full parser every time we want to make a section anchor. (The latter is almost certainly impractical.)

Not all the simple cases have even been fixed. Try this:

'''Foo'''

t.laqua wrote:

I'll work on refining the pseudo-parsing for simple/common cases.

There's more that doesn't work. For instance:

Hello

Anchor: Hello
Redirect: Hello
Edit summary: ->Hello

[http://www.mediawiki.org]

Anchor: [1]
Redirect: [http://www.mediawiki.org]
Edit summary: ->[http://www.mediawiki.org]

Hello

Anchor: Hello_2
Redirect: Hello
Edit summary: ->Hello

The third one is tricky, as we can't go around doing /* Hello 2 */, which would show ->Hello 2 in the edit summary. The second one should be fixed more easily, perhaps by changing the generated anchor to [http://www.mediawiki.org] as well.

t.laqua wrote:

Fixed the simple wikitext quote parsing in r25598.

Looking in to the anchor generation for headings (R.E. Case 2)

With regard to case 3 - multiple sections with the same name - Unless we ram the entire article through the parser, there's no way to know. The only option I can think of would be some predictive logic where we apply some simple regex work to the base article text - but we cant rewrite the entire parser and we really shouldn't run EVERY anchor link through the parser - those solutions are simply wasteful.

(In reply to comment #25)

With regard to case 3 - multiple sections with the same name - Unless we ram
the entire article through the parser, there's no way to know. The only option
I can think of would be some predictive logic where we apply some simple regex
work to the base article text - but we cant rewrite the entire parser and we
really shouldn't run EVERY anchor link through the parser - those solutions are
simply wasteful.

Can't we just regex for section titles (something like '^=+ ?(.*?) ? =+$' I believe, not very good at regexes though), pseudo-parse them all and see if there are dupes?

t.laqua wrote:

(In reply to comment #26)

(In reply to comment #25)

With regard to case 3 - multiple sections with the same name - Unless we ram
the entire article through the parser, there's no way to know. The only option
I can think of would be some predictive logic where we apply some simple regex
work to the base article text - but we cant rewrite the entire parser and we
really shouldn't run EVERY anchor link through the parser - those solutions are
simply wasteful.

Can't we just regex for section titles (something like '^=+ ?(.*?) ? =+$' I
believe, not very good at regexes though), pseudo-parse them all and see if
there are dupes?

Where are we at on this one? I while back Tim Starling refactored a bit - can we come up w/ a new list of things that aren't working w/ regard to new section anchor links?

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

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

+need-review since Will Mahan's contribution in comment 19 hadn't been reviewed. Thank you for the patch, Will.

(In reply to comment #31)

+need-review since Will Mahan's contribution in comment 19 hadn't been
reviewed. Thank you for the patch, Will.

It looks like that patch is obsolete now per comment 21?

sumanah wrote:

Comment on attachment 2272
Proposed fix

Patch no longer applies to trunk, so marking obsolete (checked by Rusty per http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html ).

sumanah wrote:

Chris, if you are still encountering this problem in more recent versions of MediaWiki, please let us know.

Will, if you'd like to revise your patch to work with the current codebase, please do and resubmit. Thanks!

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

I would link (as good workaround fallback) to the very bottom #footer, because this auto summaries are always talkpages (and you know where the newest post are...)

Is this bug fixed? It seems the TOC generates the correct link.