Many wikis have requirements for custom user signatures.TheEditing team is seeking your input on a proposal to codify some of these requirements in Wikipedia's software.This will make it easier toreply to specific comments on talk pages and to use some other tools.
You can find more details about what is being proposed, and why, below:
The team wants your feedback about this proposal.
Please post your comments about these questionson the talk page:
Please do not feel limited by the questions above. The team wants to hear any feedback you have to share.
In 2019, volunteers from20 Wikimedia projects and usergroups, along with staff from the Wikimedia Foundation, participated in theTalk pages consultation. It was an effort to define better tools for on-wiki communication.
One of the outcomes of this consultation wasa request for an easier way to reply to specific comments on talk pages.
In order forthis feature to work well, the software needs signatures to be "machine-readable", so it can reliably detect users' comments and allow replying to them.
The trouble is, while many wikis already have the necessary signature requirements in place, these requirements are not included in the software itself.This increases the chances someone will set a signature that breaks the wiki's conventions and potentially, make it more difficult for people to participate in conversations.
This additional consistency in the format of signatures would improve existing features, like"mention" notifications, which are only sent if the signature can be detected in your edit.
If no significant obstacles are identified, this change could happen in April 2020.If the team needs to make significant changes as a result of your feedback, then it will take longer.
The three proposed checks are described in this section. These would be applied to user signatures in Preferences when a user saves a modified signature.Under the Editing team's proposalexisting signatures will *NOT* be affected.
Most importantly, this change would disallow unclosed formatting tags, like<i> or the corresponding wikitext markup,'', without a matching closing tag (in this case,</i> or'', respectively).Signatures containing invalid markup can affect the entire discussion page, when the formatting continues into subsequent comments.
The check would also identifymisnested tags, like<b>foo<i>bar</b></i> (either both of thei, or both of theb, tags should be on the outside), andstripped tags, which are closing tags without a corresponding opening tag (the opposite of the "unclosed formatting tag" listed above).
Signatures that contain some less critical problems would also be disallowed, e.g., obsolete HTML tags like<tt>...</tt> and<font>...</font>. While these do not cause immediate issues, doing this would prevent the spread of obsolete code to new wiki pages, which is an annoyance for editors cleaning up Linter errors.
A full list of syntax features that would not be allowed, along with links to pages that explain how to update or fix code with Linter errors, is available atthis address.
Unclosed formatting tags were already supposed to be prevented by the software, but due to limitations of the current wikitext parser, this worked only in some cases. A more robust solution has become possible thanks toParsoid.
Various tools don't work correctly when a signature does not contain at least one of the following links: a link to the user's user page, user talk page, or contributions page.(The link must be for a page on the wiki the signature is used on;interwiki orinterlanguage links – e.g., to a different language of Wikipedia – are not sufficient.)For example,"mention" notifications are not sent, and forthcomingDiscussionTools will not allow replying to comments with these invalid signatures.Gadgets and other tools that interact with signatures also may not work as expected.
This requirement has been present for a long time in many Wikimedia wikis' policies, but it has not been enforced by the MediaWiki software.[1]
Some use ofsubst: markup and tildes would also be disallowed in signatures.Previously, it was possible to use these features to set a signature that would cause a subsequent editor's name to be placed on your comments.All forms of signature forgery have long been banned by policy at the larger wikis, and this type of forgery will now be prevented in software.Simple subst: markup is still allowed.
The signature must consist of a single line of wikitext. Line breaks can result in incorrect formatting when the signature is used in a nested comment. They can also cause problems with tools used on discussion pages. This affects the literalcarriage return andline feed characters, not<br> and<p>.
At this time, you cannot add these characters to a custom signature inSpecial:Preferences. This proposal will prevent them from being added via a substituted signature template or by editing your preferences programatically.
Any existing signatures that would become invalid under the new rules are still allowed (grandfathered in).When viewing your preferences, you would see a warning message about this, and if you try to change the signature, the new one must be valid.But if you don't change it, the old invalid signature will continue to be used when you sign, and you'll be able to change your other preferences without affecting it.
We're looking for feedback as to whether you would like existing invalid signatures to be disallowed.If invalid signatures are disallowed, the default signature would be inserted when affected users sign their comments, until they correct their personalized signatures.
Please comment before 31 March 2020.The Editing team will make decisions about this project in early April.The results will be posted on the talk page.
If no obstacles are identified, this change would happen no earlier than April 2020. This date could be pushed back if the team needs to implement significant changes as a result of your feedback.
We'll include another notice inm:Tech/News when this change is about to be deployed.
The HTML/lint errors include links to existing documentation about lint errors, such asHelp:Extension:Linter/missing-end-tag, and a button to highlight the problematic part of the signature.
The required link errors include example wikitext syntax to use.
The proposal was largely accepted. In response to comments from volunteers, a few small changes were made and a few points were clarified.
<tt>...</tt> and<font>...</font> will not be banned at this time. This decision does not prejudice any future decision for or against removing these obsolete HTML tags.[[User:Example|Example]] ([[m:User talk:Example]]) would be acceptable (one local link, one link to another wiki), but a signature that includesonly links to another wiki, oronly redirects from a former username, will be invalid. This is for technical reasons.The process for implementing this change is:
Done A general announcement will be made inTech News when the new requirements are deployed.Done Once the software change has been made on the servers, users will no longer be able to save invalid custom signatures. However, existing signatures will remain.
In progress Active editors with invalid signatures will be encouraged to change their signatures. This process will likely take some months.Third-party wikis will be able to enable this change manually.
The line break characterscarriage return andline feed (but not the HTML codes for them, e.g.,<br/> and<p>) are disallowed.