Page MenuHomePhabricator

allow anchor name to be defined independent of section header text
Closed, DeclinedPublic

Description

Author: jra

Description:
MediaWiki currently generates A (anchor) tags in pages at the beginning of
sections with both NAME and ID properties based on the text of the section
label/separator.

This can be problematic, since the purpose of those tags is to be linked to --
which means that if someone links to them, and you then change them, external
markup (that you don't even know about) breaks.

One possible solution would be to extend the vertical-bar semantics, currently
used for [URL|text link] and [[page_name|substitute text]] cases, to work in
section headers as well, like so:

TV|Television Coverage

Which would render as

<p><a name="TV" id="TV"></a></p>
<h2>Television Coverage</h2>

This would break any current section headers which happen to contain a vertical
bar character as text, but those are likely not to be too common, and the issue
could be dealt with for outstanding instances by a striping process, if necessary.


Version: unspecified
Severity: enhancement

Details

Reference
bz1521
ReferenceSource BranchDest BranchAuthorTitle
repos/phabricator/phabricator!32T352170debugwmf/stableaklapperAdd temporary debug output for T352170
repos/data-engineering/superset!23add_app_to_pythonpathmainbtullisAdd /app to the PYTHONPATH for superset
repos/data-engineering/superset!22add_wmf_requirementsmainbtullisAdd our customisation to the WMF superset build
repos/data-engineering/superset!9config_npmmainbtullisConfigure the npm proxy settings
repos/data-engineering/superset!8test_https_proxymainbtullisTest the use of the https_proxy environment variable
repos/data-engineering/superset!7use_node_installmainbtullisUse a plain node builder
repos/data-engineering/superset!6use_node_buildermainbtullisUse a node builder for the npm ci step
repos/data-engineering/superset!4fix_npm_proxymainbtullisSet the npm proxy on the trusted runners
repos/data-engineering/superset!3fix_publish_configmainbtullisFix the location of the blubber file
repos/data-engineering/superset!2publish_supersetmainbtullisAdd a publish stage to the superset image
repos/releng/gitlab-trusted-runner!52add_superset_projectmainbtullisAdd the data-engineering/superset project to trusted-runners
repos/data-engineering/superset!1begin_superset_buildmainbtullisAdd initial files for building superset
Show related patches Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:13 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz1521.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

Hmm, that's an interesting idea. I'm changing the summary to better reflect the
actual *feature* being requested; the suggested syntax for achieving it is not
central to the concept (and it's a bit misleading to talk about "the '|'
semantics", given the completely arbitrary nature of wiki syntax; note also that
[URL link text] uses no '|', only *internal links* do).

That said, your suggested syntax does indeed seem pretty elegant, and I agree
that there are unlikely to be all that many existing headings with a pipe in the
middle - and in order to be a problem, they would have to have a pipe in the
middle *and* be linked to directly.

Of course, in order to have the desired effect, the change would have to be
followed by awareness and agreement by wiki users of how to use this feature -
pretty much the first person to introduce it onto a page needs to choose
something that won't be confusing later on. But your example makes me think that
this could just work.

jra wrote:

WRT your observation about user training, please remember that "not all
mediawiki's are wikipedia" -- this is as much an external feature as it is for
WP. But I'm glad that you think it's practical. It doesn't *seem* to me that
it would be all that much work to code, but I haven't looked at the code yet.

rowan.collins wrote:

Yes, I tried to pick my words to imply that in order to be effective, the
community of *any* wiki using this feature would have to use it effectively -
unless you're using [abusing?] MediaWiki as a single-user system, there is a
community who need to "get it". But like I say, I'm optimistic that they would.

As for easer or otherwise of coding - never underestimate the hideous complexity
of Parser.php ;)

jra wrote:

Certainly. In a new installation, it's just one more thing to learn, and I
tried to choose my suggested implementation to generalize a rule they'd already
be learning.

And it's also a fairly low-odds collision item.

And, since I'm diving into MW->DocBook as we speak, I'm told I'm about to
discover the wonders of that parser... :-)

gangleri wrote:

Hallo!

(In reply to comment #0)

TV|Television Coverage

Which would render as

<p><a name="TV" id="TV"></a></p>
<h2>Television Coverage</h2>

What about generating both anchors?

<p><a name="TV" id="TV"><font id="Television_Coverage" /></a></p>
<h2>Television Coverage</h2>

or an equivalent construct.

This would help shorten url's using Unicode characters or characters converted
to ".XX".

At wikies using transcription one would use Latin characters for foo at

foo|bar ==. see

http://yi.wiktionary.org/w/index.php?title=project:bugzilla/01521#.D7.B0.D7.90.D6.B7.D7.A1.D7.A2.D7.A8
which is 99% equivalent to
http://yi.wiktionary.org/w/index.php?title=project:bugzilla/01521#vaser

*note*
Automatic replacement of spaces to underscores in section ancors is made. This
should be the case also for == foo bar|bar == .

*question*
Are the following links valid?
http://yi.wiktionary.org/w/index.php?title=project:bugzilla/01521#foo.20bar
http://yi.wiktionary.org/w/index.php?title=project:bugzilla/01521#foo.5Fbar
http://yi.wiktionary.org/w/index.php?title=project:bugzilla/01521#bar.20foo
http://yi.wiktionary.org/w/index.php?title=project:bugzilla/01521#bar.5Ffoo

They all fail.

best regards reinhardt [[user:gangleri]]

gangleri wrote:

(In reply to comment #0)

This would break any current section headers which happen to contain a vertical
bar character as text, but those are likely not to be too common, and the issue
could be dealt with for outstanding instances by a striping process, if necessary.

The *first* "nonescaped" "|" should be relevant for rendering:

a) a section which is using today

TV|Television Coverage

could be changed to

TV<nowiki>|</nowiki>Television Coverage

and renders as before

b)

A<nowiki>|</nowiki>B<nowiki>|</nowiki>C|Alphabet

would render
<p><a name="A|B|C" id="A|B|C"></a></p>
<h2>Alphabet</h2>

c)

A<nowiki>|</nowiki>B<nowiki>|</nowiki>C|foo|bar

would render
<p><a name="A|B|C" id="A|B|C"></a></p>
<h2>foo|bar</h2>

The syntax would obsolete complicated constructs which generated bug 04039, bug
04987 etc.

best regards reinhardt [[user:gangleri]]

wikimedia wrote:

Because this should not be hard to implement and adds a lot of functionality,
I'd even be willing to spend some hours to get into the source and provide a patch.

Is this wish considered to be "design-complete"?

I often wished that this has been already implemented, but now it's really
needed, because I want to link to sections from another (web) application (help
links). There it would be the best to have the anchors named after the
internal's setting name, e.g. "param_foo", but a "human readable" text for the
header.

The workaround seems to be, to manually insert "<div id="param_foo"></div>" tags
into the wiki source.

gangleri wrote:

(In reply to comment #7)

The workaround seems to be, to manually insert "<div id="param_foo"></div>" tags
into the wiki source.

"<div id="param_foo"></div>" would generate a new line.
"<span id="param_foo"></span>" would *not* generate a new line.
see
http://test.leuksman.com/view/User:Gangleri/tests/bugzilla/01521

In comment 5 I used "<font id="Television_Coverage" />"; probably it is not
recommended to use HTML.

best regards reinhardt [[user:gangleri]]

happy.melon.wiki wrote:

This seems very stale, and also of dubious utility; the suggested syntax is certainly not viable, we already use bare pipes for far too many other things.

I'm going to agree and go ahead and mark this WONTFIX.

Custom anchors can be done with <span id="foo"></span> (or a template wrapping them) placed near the heading; this is fairly standard and already gets used in places.