Last modified: 2005-06-24 19:28:09 UTC
When ~~~ is expanded for User:X, it produces [[User:X|X]] by default. However, if the user changes their signature to contain internal links (for example, by changing it to [[User talk:X|]]), the code for the User:X link continues to be included, so that ~~~ expands to [[User:X|[[User talk:X|]]]], which is fortunately still parseable, though it is functionally identical to [[User talk:X|]]. This exposes odd bugs in the parser depending on what exactly the signature contains, particularly when normal text is included with links.
The sig is meant to be a link to the user page; the nick is plaintext. It's a cute thing that you can make funky links with it by breaking the rule, but it's just a cute plaything, not an intended or desired feature.
Including a link to the talk page is useful enough that it should be possible without hackery.
(In reply to comment #2) > Including a link to the talk page is useful enough that it should be possible > without hackery. If that's so, then this request, which is for such hackery, should be denied.
How is it a request for hackery?
Changed summary to the actual feature that's being requested, and which is widely used. It would be even nicer if we could entirely disallow wikitext in signatures and just use a username or nickname and optional talk page. BTW, you can omit the [[ and ]] in your signature as a temporary workaround. I use "<nowiki></nowiki>]]— [[User:Kate|Kate Turner]] | [[User talk:Kate|Talk" which produces correct wikitext and renders correctly.
Note that the implementation of this feature in MediaWiki 1.4 also messed up old signatures by adding coding to them.
Option for 'raw' signatures added: you can put whatever you want in the nick field and have that inserted without the surrounding automatic user page link. Resolving as fixed. Regarding comment #6: 'correct' hackery was *not* affected by parser fixes in MediaWiki 1.4 -- but a few people had incorrectly set their nick fields in a way which produced invalid code which happened to look right previously due to parser bugs in 1.3. Correct hackery would have been a nick that looked something like "name]] [[User_talk:Name|talk", producing as final output "[[User:Name|name]] [[User_talk:Name|talk]]" The sig is inserted at edit time, so the parser can't "undo" your old, invalid sigs.
(In reply to comment #7) > Option for 'raw' signatures added: you can put whatever you want in the nick field > and have that inserted without the surrounding automatic user page link. Resolving > as fixed. > Regarding comment #6: 'correct' hackery was *not* affected by parser fixes in > MediaWiki 1.4 -- but a few people had incorrectly set their nick fields in a way > which produced invalid code which happened to look right previously due to parser > bugs in 1.3. Correct hackery would have been a nick that looked something like > "name]] [[User_talk:Name|talk", producing as final output "[[User:Name|name]] > [[User_talk:Name|talk]]" Please check my edits from yesterday or before at the Wikipedia Help desk and Votes for deletion for proof of old signatures changing. > The sig is inserted at edit time, so the parser can't "undo" your old, invalid sigs.
See English Wikipedia Help desk for old bugs (even from November 11) changing with new signature implementation.
This is explained above. Your old nick generated invalid code, which due to a bug turned out in a fashion that you found acceptable. With the parser bugs fixed, you can now see that your code was, indeed not correct. You can now check an option in your preferences to produce the _correct_ output for that type of signature.
(In reply to comment #10) > This is explained above. Your old nick generated invalid code, which due to a bug > turned out in a fashion that you found acceptable. With the parser bugs fixed, you can > now see that your code was, indeed not correct. As I have noted on bug 1142, the invalid code is present in uncountably many talk pages and their archives. It is entirely unhelpful to declare the old behavior buggy; do you expect somebody to hunt down all occurrences of the bug and fix the old signatures? > You can now check an option in your preferences to produce the _correct_ output for > that type of signature. Thank you.
