Here's an example at the English Wikipedia: http://en.wikipedia.org/wiki/RFC_3377

In case someone changes the page, here's the relevant part (called by the
template {{Compu-network-stub}}):

''This [[computer network]]-related article is a [[Wikipedia:Perfect stub

article|stub]].

[[Wikipedia:Find or fix a stub|Help]] Wikipedia by
[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} expanding it]''

Since RFC's are autolinked, this is rendered on-screen like this:

This computer network-related article is a stub. Help Wikipedia by
RFC 3377&action=edit">expanding it.

The text "RFC 3777" is linked to:

http://en.wikipedia.org/w/index.php?title=RFC_3377&action=edit

and so actually works (in Windows Firefox 1.0 and IE 5.5, anyway), but a check
of the HTML source reveals a little more about what's happening:

by <a href="http://en.wikipedia.org/w/index.php?title=RFC_3377&amp;action=edit"
class='external'
title="http://en.wikipedia.org/w/index.php?title=&lt;ahref='http://www.ietf.org/rfc/rfc3377.txt'
class='external' title=">RFC 3377</a>&amp;action=edit"&gt;expanding it

I hope that gets displayed correctly when I save this comment! Anyway, the
software is still trying to autolink the RFC to the page at ietf.org, as it
would if you just had the string "RFC 3377" in running text. But obviously it
shouldn't be doing that since it's inside of a URL.

Note: As far as I can tell, the HTML source shown above is correct.

chrislb wrote:

ISBN passages are also highlighted. Generaly software shouldn't be to intelligent here, as it
can complicate text editing. Could be integrated with some thing a la {{isbn|...}}.

zigger wrote:

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

zigger wrote:

(In reply to comment #1)

...
Since RFC's are autolinked, this is rendered on-screen like this:

This computer network-related article is a stub. Help Wikipedia by
RFC 3377&action=edit">expanding it.

...

This problem has been reported as bug 3415.

jra wrote:

This bug also surfaces when one tries to force a single-bracket out-link around
an RFC NNNN text string: the result is a null-text link pointing to the
specified site, followed by the magic link as usual.

EG: [http://baylink.pitas.com RFC 2100]

The required workaround is currently [http://baylink.pitas.com <nowiki>RFC
2100</nowiki>]; thanks to robchurch@IRC for suggesting it. This is indeed a low
priority bug, but if anyone's crawling around inside the parser... :-)

But it's not an RFE; it's a bug. Changing severity.

robchur wrote:

(In reply to comment #6)

but if anyone's crawling around inside the parser...

...then I pity their eternal soul ;-)

wmahan_04 wrote:

Parser test cases

It looks like Tim Starling fixed the problems in r15976. Here are a couple of
parser test cases for this and bug 3415 (both pass).

Attached:

ayg wrote:

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