Talk:New requirements for user signatures

Welcome! Please use this page to ask questions and share information.

Whole hearted support

Signatures should be in a proper format. This is long overdue. ~ 156.57.13.33 (talk) 18:27, 4 March 2020 (UTC)

I'm OK with the proposal, and I would explicitly give communities the option to enforce the requirement on existing signatures. My guess is that some communities would be willing to enforce the requirement on existing signatures after a grace period and after providing notifications to affected users who have noncompliant signatures. ↠Pine (✉) 19:46, 9 March 2020 (UTC)

The software should not allow any changes to a signature that leaves a signatures with any External links, line breaks, horizontal rule, unescaped pipe character, images, or lint error including font tags, or lacking a link to some user page. Users with signatures not in compliance with any of these should be given 60 days to fix their signature and after that the signature should be wiped and they get the default signature. There should be a link to a help desk where you can ask, among other things, "Please help me create a signature string that renders like my existing string but is in compliance with the new rules." On wipe-noncompliant-signature day, non-compliant signatures should be stored in an "Old Sig" field to help those on Wiki-breaks to develop a compliant signature when they return. Anomalocaris (talk) 01:02, 15 April 2020 (UTC)

Presumably, if you have a custom sig, you have also signed a comment. That means that you could find a copy of your custom sig in Special:MyContributions. Whatamidoing (WMF) (talk) 19:54, 16 April 2020 (UTC)

I am fine with Anomalocaris' proposal. ↠Pine (✉) 06:47, 17 April 2020 (UTC)

Should non-compliant signatures be invalidated?

A few existing (and not blocked) editors probably have signatures that don't meet these criteria. The current proposal is to ignore those signatures. Do you think that's a good idea?

Opinions I've personally heard so far are:

• Leave them alone
• Leave them alone now, and remove them later (maybe next year)
• Remove them later

(If your signature got removed, then the software would use the default sig instead.)

What option do you prefer? Whatamidoing (WMF) (talk) 18:32, 4 March 2020 (UTC)

Leave them alone for now. Notify editors with invalid signatures, and set a fixed date after which their invalid signatures will be replaced with plain uncustomized signatures.

Before doing this, make sure that resources are available to enforce each of these steps. Jonesey95 (talk) 20:10, 4 March 2020 (UTC)

I like this idea. Basically phase them out. Start by forbidding new invalid signatures, put warnings in preferences for old ones (alongside maybe site notice / watchlist notice for logged in editors with custom sigs / invalid sigs) and give some time for people to voluntarily update. Then after 3/6/12 months, kill the stragglers. Headbomb (talk) 22:27, 4 March 2020 (UTC)

I'd say don't invalidate them. Why force people to change if they don't want to? InvalidOS (talk) 17:37, 5 March 2020 (UTC)

Re "Why force people to change if they don't want to?"

Because every time someone adds an invalid signature to a talk page, it creates a new error that someone else will later need to fix. Jonesey95 (talk) 17:53, 5 March 2020 (UTC)

Support idea but be cautions. I'm copying a copying this edit here where it belongs:

Great idea, but allow projects and third-party users of MediaWiki software to opt out. For example, if the English Wikipedia or WikiData or some third party web site that uses the software wants to keep the current behavior, they should be able to do so. For community-run Wikimedia projects, it would presumably be a community decision to accept any software that imposed requirements stricter than existing ones. For the English Wikipedia and others where the software would merely be enforcing the existing requirements, this change should be accepted as routine. I say it should be routine for the English Wikipedia, if any existing users have grandfathered-in exceptions that would break under the new code, then an en-wiki discussion would have to be held before accepting the changed code.

Davidwr (talk) 18:37, 4 March 2020 (UTC)

Are you aware of any community that prefers looser requirements than these? (These changes are less restrictive than the English Wikipedia's.) Most small wikis don't bother writing rules about signatures, but if any community actively prefers something different from this, then I'm sure they'd want to accommodate them, too.

(Changes to MediaWiki core (which this is an example of) are the purview of the MediaWiki community, rather than any of the user communities.) Whatamidoing (WMF) (talk) 19:08, 4 March 2020 (UTC)

I am not aware of any. However, announcing it on each project's equivalent to the English Wikipedia's Village Pump or Centralized discussion should give you an answer in short order if the answer is "yes." Davidwr (talk) 20:03, 4 March 2020 (UTC)

i honestly have no idea why.... people can fork the software if they want to maintain something difficult for their own enjoyment. —TheDJ (Not WMF) (talk • contribs) 09:10, 5 March 2020 (UTC)

It usually causes less hassle to let the projects make their own choices rather than having changes thrust upon them. Even with things that are an obvious improvement to most people. If they really are an improvement, the projects will probably accept them Pbsouthwood (talk) 15:39, 5 March 2020 (UTC)

less hassle on who ? Im hassled as a dev every week by having to account for everyone wanting their own little sandbox to play around in.

Just because people dont experience my hassle nor rly care about the sanity of their developers. Its a world of two truths. We just need to decide which one is more important. —TheDJ (Not WMF) (talk • contribs) 15:58, 5 March 2020 (UTC)

Less hassle as in less pushback from those people who will get the impression that this is another thing that WMF has arbitrarily decided they will have whether they like it or not.

If you are saying this is a thing that is broken and must be fixed, produce a convincing explanation of what is broken and why it must be fixed. The communities are more likely to accept the proposed solution if it can be shown to be both necessary and desirable.

I personally don't see any need for fancy formatting of sigs at all, and would not have a problem with default only, but I may be in a minority on that point. All I look for is the ability to easily spot my own sig on a page without having to do a search, which can be done by highlighting. Pbsouthwood (talk) 05:32, 8 March 2020 (UTC)

Here's a demonstration of what an unclosed font tag, an unclosed s tag, and an unclosed pre in a signature can do to a talk page:

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox3&oldid=944557608

This is a dramatic example, but unclosed tags exist in WP by the millions (literally; see https://tools.wmflabs.org/fireflytools/linter/enwiki for a count that is a lower bound due to undercounting), and they break the formatting of talk pages. Jonesey95 (talk) 15:48, 8 March 2020 (UTC)

Give users with grandfathered signatures a limited time to change their signature to a different non-compliant signature. You don't want everyone trying to "get in under the wire" though, so limit this "limited change window" to people with non-compliant signatures by some cutoff date, say, March 1, 2020. Davidwr (talk) 18:40, 4 March 2020 (UTC)

I agree with Davidwr: Notify editors with non-compliant signatures and allow them a limited amount of time to modify it. I don't think it makes any sense to allow them in perpetuity. (adding manual timestamp since sig isn't working) Schazjmd (talk) 19:12, 4 March 2020 (UTC)

@Schazjmd: To clarify: The proposal on the table says editors CAN keep a non-compliant signature in perpetuity, which I agree with. My proposal goes further and says that IF you have such a signature today and the software will change, say, in June, you will have a few months, say, until the end of the year, to change it to a different non-compliant signature without the software stopping you. After that, you can either keep the one you had at the end of the year or change it to a compliant one.

Of course, some languages and some projects may prefer the proposal as-written, in which case the this additional leeway can be disabled. Davidwr (talk) 20:10, 4 March 2020 (UTC)

Thanks for the clarification, I did miss that subtlety. My opinion is the same, it's just not the same as Davidwr's. :) ~ Schazjmd (talk) 20:14, 4 March 2020 (UTC)

@Davidwr: I think disallowing to set a non-compliant signature should happen in one step. It’s highly confusing if a user complains that they can’t set a non-compliant sig, and another user answers they can. As for the disabling existing non-compliant signatures: I support having a notification (e.g. using Echo) and giving users some time, probably a month or two. I don’t think the past cutoff date is important as long as the non-compliant signatures will be disabled anyway (and especially if even non-compliant ones can be changed only to compliant ones after deploying this feature); but it doesn’t seem to be possible, either—I don’t think the date when a preference has been set is stored anywhere, so it cannot be queried whether this date is prior to March 1. Tacsipacsi (talk) 21:14, 4 March 2020 (UTC)

@Tacsipacsi - if the choice is limited to the three things in the list, I would say that on the projects I participate in heavily (English Wikipedia and Commons), "leave them alone" then wait a year to see if it's a big enough problem to force grandfathered users to change their signatures. Davidwr (talk) 21:23, 4 March 2020 (UTC)

I agree with the others (not David) in favoring something like option 2, with notification/warning on talk pages or similar. I am 0% a fan of "never change/remove these". I am a fan of 6 months to a year, but one to two months is also reasonable. No more than a year of grandfathering, however. Izno (talk) 21:33, 4 March 2020 (UTC)

In any case, a notification for affected users would be beneficial. (I think the vast majority of the affected users have non-compliant signatures by accident, so notifying them would probably significantly drop the count of non-compliant users.) Tacsipacsi (talk) 21:35, 4 March 2020 (UTC)

Warn first, then if still not valid, reset them to the default signature instead of them having a custom signature (also do this for 'no longer active' users). —TheDJ (Not WMF) (talk • contribs) 09:09, 5 March 2020 (UTC)

@TheDJ, have you thought about how to identify who to notify about non-compliant sigs? Most editors are inactive, so most invalid sigs are likely to be inactive, so I don't think we want to notify everyone with a non-compliant custom sig somewhere in the database. If we could get a list of active editors with non-compliant sigs, it might be possible, as @Tacsipacsi suggests, to use Notifications to alert them. Otherwise, we could send MassMessages to their user talk pages (SUL-style). Whatamidoing (WMF) (talk) 17:09, 5 March 2020 (UTC)

I got bored today and wrote a script to go through the signatures of enwiki editors that have edited in the last and approximate the proposed new rules. It identified 8308 editors with problematic signatures, but I know that there are false positives and false negatives in that dataset. The most common error is not linking to a user page, with 7193 problematic signatures. Most of these errors are caused by editors ignoring the warnings around the "Treat the above text as wikitext" checkbox and only putting in a nickname. After that, as we probably expected, is font tags, with 1108 editors. The full dataset is available here as json lines and here as a json object with the statistics included. AntiCompositeNumber (talk) 00:58, 6 March 2020 (UTC)

By the way, as the biggest concern is probably <font> in signatures, which is fairly straightforward to fix, what’s about instead of disabling such signatures, simply fixing them (i.e. the ones that are compliant except for the use of <font> tags) after the grace period? Tacsipacsi (talk) 22:24, 6 March 2020 (UTC)

The word "simply" is doing a lot of heavy lifting in that sentence. Modifying existing signatures without editors' consent is a lot of extra, risky work for no benefit, especially if their invalid custom signatures can be deleted (edited to add: or disabled; see next comment by AntiCompositeNumber) instead, leaving the editors with perfectly valid, visually neutral signatures. Jonesey95 (talk) 01:10, 7 March 2020 (UTC)

The only thing I'd suggest leaving open is disabling fancysig (the "Treat the above text as wikitext" checkbox) for users with no formatting characters in their signatures. Otherwise, if they've been warned and don't fix it, just drop it. AntiCompositeNumber (talk) 01:33, 7 March 2020 (UTC)

OK, this was just an idea, it’s not crucial for me. Tacsipacsi (talk) 13:24, 7 March 2020 (UTC)

I have the impression that editing the prefs database is tricky, and it might cause the Technology folks to break out in a bad rash. Whatamidoing (WMF) (talk) 23:17, 6 March 2020 (UTC)

I would have thought that we can get some creme for the rash and at least replace those sigs that have no links with a default sig. That single job would eliminate close to 90% of the problems sigs on the enwiki (thanks to AntiCompositeNumber for the stats), leaving a much more manageable job for the remaining issues. RexxS (talk) 19:33, 9 March 2020 (UTC)

If they disabled the non-compliant sigs (e.g., after six months or a year), I understand that MediaWiki would leave the old code sitting untouched in the prefs database and simply ignore it, so 100% of them would use the default sig then.

(You're thinking about a topical antihistamine to deal with stress-induced hives? Do you have a MEDRS-compliant source for that suggestion? ;-) ) Whatamidoing (WMF) (talk) 20:07, 9 March 2020 (UTC)

When we were making nl.wiktionary html5 compliant, we did find between 10 and 20 signatures that contained Linter errors. We explained to each user in question in a personal message what the problem was, and showed them how they could easily resolve it, like this example. If we got a reaction, it was a positive one. Of course there were also a number of users who were no longer active. In all cases we were able to make the desired adaptations. Maybe this approach could be useful in this case too. My guess in the present situation invalidating non-compliant signatures on nl.wiktionary wouldn't be problematic. MarcoSwart (talk) 20:21, 9 March 2020 (UTC)

@MarcoSwart Survey says you'd be correct in that guess: only 5 nl.wiktionary editors have problematic signatures. All of them are either using interwiki links or redirects instead of a direct link to a local user/user talk/contribs page. AntiCompositeNumber (talk) 05:11, 10 March 2020 (UTC)

That is great to hear. I expect that we will eventually have a similar outcome on en.WP, but everything there is at a larger scale, which can result in a little more pain, and more "edge cases". Jonesey95 (talk) 20:25, 9 March 2020 (UTC)

I’d say the idea that makes more sense is to invalidate those signatures after the user has been somehow informed by the software for some time (a week?) and didn’t make their signature valid. I think it is doable from the technical standpoint and will be the most seamless for users. After all, signatures that don’t get used aren’t really a problem. stjn^[ru] 21:15, 9 March 2020 (UTC)

• If an existing fancy signature will affect subsequent contributions, that one might be marked as invalid and can be ignored.
  • That goes for lack of closing tag, perhaps subst: business (never seen), inappropriate MediaWiki elements.
  • If ignored and falling back to non-fancy the input field needs to get red background and an explaining label.
• If not, keep in effect what is in preferences now to avoid riots.
  • Leave that to local projects.
  • They will visit most disturbing code producers anyway and help to fix the individual syntax problem.
  • Users might be offwiki for half a year, and will be overburdened when they return and password is too simple, signature is bad and interface appearance changed in many ways.
  • The input field might get a red border and an explanation.
• Obsolete HTML5 like <tt> does not influence readability of HTML document. It will be supported for many decades, might become official code again in some HTML.6, and even if not interpreted next century it does not change the meaning, text is just less decorated. Even <font> which is obsolete since HTML.4 in 1998 (and not HTML5) would cause less decoration only, if ever. Do not bother users.
• On attempting to change or introduce a signature, you may linter it right now and reject any undesired code as you like.
• If a user is not active, nothing is signed. If returning 12 months later, this is the earliest point to deal with that change. However, many things are to be learned again and new behaviour in various situations is to be learnt. PerfektesChaos (talk) 11:06, 10 March 2020 (UTC)

Do you have an example signature?

Is there a custom sig that you think should be accepted, or rejected, or you're just curious whether it would be accepted? You can post it here if you want to. Whatamidoing (WMF) (talk) 18:34, 4 March 2020 (UTC)

For the requirement for a link to user/talk/contribs: can the link be an interwiki or interlanguage link? For example, users @GB fan and @DerSpezialist on enwiki currently use the signatures [[:en:User talk:GB fan|~ GB fan]] and [[:de:Benutzer:DerSpezialist|Spezialist]]<sup>([[:de:Benutzer Diskussion:DerSpezialist|talk]])</sup>, respectively. AntiCompositeNumber (talk) 22:43, 5 March 2020 (UTC)

@Matma Rex, what do you think of this? It's not unusual for a MassMessage to be sent "from" m:User:Whatamidoing (WMF). Although that's done manually per-message, it's possible that some people might set their prefs that way, especially outside their home wiki. Whatamidoing (WMF) (talk) 18:51, 6 March 2020 (UTC)

Note: I did see one editor in my dataset with an interlanguage link like [[en:User talk...]]. If IWLs/ILLs are allowed, an unprefixed ILL like that (which would show up in the sidebar, not as an inline link) should generate an error. AntiCompositeNumber (talk) 19:04, 6 March 2020 (UTC)

@AntiCompositeNumber, is your dataset from enwiki? Whatamidoing (WMF) (talk) 19:48, 6 March 2020 (UTC)

Yes (the one mentioned here). That specific link works, since it's already on enwiki. However, when that exact signature is copy-pasted to another wiki (or set globally), it might not work (depending on how the interwikis are set up). AntiCompositeNumber (talk) 20:13, 6 March 2020 (UTC)

I'm wondering whether we might see more interwiki links at Meta. Whatamidoing (WMF) (talk) 23:18, 6 March 2020 (UTC)

@Whatamidoing (WMF) They are more prevalent on Meta, but there are fewer signatures overall and 36 times fewer potentially problematic signatures of recently-active Meta users. data AntiCompositeNumber (talk) 23:45, 6 March 2020 (UTC)

The main problem with these is that namespace names are translated, so we'd have to load localisation data for all the hundreds of languages, which is actually way slower in MediaWiki than you'd think (once upon a time I tried to do that in some unit tests, it took several seconds).

If folks really want this, then I suppose we could add an exception so that any signature with an interwiki link is valid, but we realistically can't validate that the link points to a user page (and DiscussionTools, Echo etc. won't be able to detect this signature).

I'm not sure if having a signature like this makes much sense these days. We have cross-wiki notifications, so why ask other users to reply to you on another wiki? (I actually used to have a signature like that on en.wp, e.g. [1]… good times.)

Note also that you could easily have both a local and an interwiki link, which to me seems like the best of both worlds. Matma Rex (talk) 01:51, 7 March 2020 (UTC)

Another question: what about links to redirects? On nl.wiktionary.org, @~riley uses -[[User:Riley Huntley|Riley Huntley]] [[Meta:SWMT|(SWMT)]]. That page is a redirect created during renaming, and I expect that there are plenty of similar signatures on other wikis. AntiCompositeNumber (talk) 05:19, 10 March 2020 (UTC)

DiscussionTools would not follow the redirect, so it will detect the "wrong" user as the author of a comment. Right now that doesn't really cause any problems, but in the future we might want to send notifications about the reply or something. (And remember that after an account is renamed, a new account can be registered under the old name, so I don't think it would be correct for us to just follow the redirect.)

I think we should treat this as invalid. Matma Rex (talk) 20:35, 25 March 2020 (UTC)

that doesn't really cause any problems, except that the Navigation Popups gadget will be showing the credentials of the previous account (either a non-existent account, or zero if the user created a new account there to block misuse), and tools which highlight users based on their permissions won't work.

Perhaps the change username process should also blank non-default sigs to ensure they use the new username? Cabayi (talk) 11:15, 2 April 2020 (UTC)

The most user-friendly option would be to automatically replace User:OldUsername with User:NewUsername in fancy signatures, but that is likely to take the most development effort. Blanking the signature from an active user isn't going to be a great idea (I think we could just about get away with it with old accounts, but someone who just had their account renamed is likely to notice and complain), but the "ignored until fixed in preferences" state proposed by others here would work. Adding a message to the rename complete notification for users with fancy signatures would also be a good idea. AntiCompositeNumber (talk) 12:58, 2 April 2020 (UTC)

As tools read existing signatures, the biggest problem is the comments signed before the renaming. This is a problem also for the vast majority of users who don’t use fancy signatures. This may be out of the scope of this project, but I think it has a much bigger impact than fancy signatures placed after the renaming. The latter will, in fact, be disallowed if the current proposal gets implemented, as not updated fancy signatures no longer contain a link to the new user page. Tacsipacsi (talk) 18:57, 2 April 2020 (UTC)

None of ~riley's contributions there have been signed... nl:wikt:Special:Contributions/~riley. Where are you seeing a sig AntiCompositeNumber? Cabayi (talk) 11:08, 2 April 2020 (UTC)

I honestly just don't have time to change my signature across 800 wikis. There should be technical support from Mediawiki to make this possible through preferences, a special page or a user script. ~riley (talk) 16:37, 2 April 2020 (UTC)

Or a Toolforge tool. There is a grant named editmyoptions, which allows OAuth tools to change preferences. Tacsipacsi (talk) 18:59, 2 April 2020 (UTC)

Wondering, we have global user pages, global js, global css, why not global sigs? Cabayi (talk) 16:41, 2 April 2020 (UTC)

phabricator:T188200 ~riley (talk) 16:46, 2 April 2020 (UTC)

My tool retrieves signatures directly from the user properties table on the Toolforge replica databases. Currently, users with any edit on the wiki within the last 30 days have their signatures checked when a site-level report is run. AntiCompositeNumber (talk) 12:45, 2 April 2020 (UTC)

Yeah, I've got another one. On de.wikipedia.org, @Doc Taxon has <small> {{ers:#timel:H:i, j. M Y (T)}}</small> at the end of their signature and appears to sign with ~~~ instead of the usual four tildes. This creates a correctly formatted (for dewiki) timestamp, but surrounds it with <small> tags. Looking for a properly-formatted date is one of the current methods for signature detection, and the extra markup might confuse that method. AntiCompositeNumber (talk) 23:03, 17 March 2020 (UTC)

That's an interesting one. I don't know whether the Reply tool is looking for the timestamp to be at the very end of the line, but other tools might. Whatamidoing (WMF) (talk) 15:32, 19 March 2020 (UTC)

The reply tool handles my signature correctly. Is there a problem with it? Doc Taxon (talk) 09:39, 24 March 2020 (UTC)

In terms of this product, I don't know.  @Matma Rex would be the best person to answer that question. In terms of other tools (e.g., an archiving bot), it's possible that some of them are confused, but if you're not getting complaints, then it's likely that the more popular tools at the German-language Wikipedia can handle it. Whatamidoing (WMF) (talk) 22:00, 24 March 2020 (UTC)

@AntiCompositeNumber @Doc Taxon I tried a similar signature locally and it doesn't seem to work with DiscussionTools (there is no "Reply" link for it). Are you talking about a different reply tool?

The code in DiscussionTools is intentionally quite strict to avoid incorrectly matching random userpage links as if they were signatures; we pretty much expect exactly the output of ~~~~. I don't think we should be adding special cases for other things, except possibly auto-signing bots with thousands of edits.

In general I'm not a fan of customizing the timestamp. I guess <small> is harmless, but I've seen user signatures that put the timestamp inside of the userpage link, or where the timestamp has a different date format, and I'd personally consider those disruptive. And it would be difficult to draw a line between those.

For the record, the proposed new validation here would not reject your signature or any of those I mentioned, though. Matma Rex (talk) 21:00, 25 March 2020 (UTC)

Oh, because I have been mentioned above to this topic, I thought, you're talking about tools like Ping or Replyto. I think it was a misunderstanding. Sorry! Doc Taxon (talk) 21:22, 25 March 2020 (UTC)

I think any tool should allow some closing HTML tags after the signature, as they might appear for several reasons: for example, when I post a side comment, I usually write it in small, including my signature ~~~~, or when someone reconsiders their opinion, they might strike through the old one ~~~~ and underline the new one ~~~~. In all these cases, the comment ends with a closing HTML tag, which doesn’t come from the preferences, by the way. Tacsipacsi (talk) 19:06, 2 April 2020 (UTC)

French Wikipedia's equivalent of sinebot wraps the date in a link to the revision. That could be reformatted to work with Discussion Tools, but @Tacsipacsi's use cases are something that hadn't occurred to me.

Ideally we'd have some explicit start-of-comment &/or end-of-comment markup, but whilst we rely on detecting timestamps, anything that doesn't end in Pelagic (talk) 21:54, 7 May 2020 (UTC) ~~~~ [good grief, I wasn't expecting Structured Discussions to translate the tildes!] has the potential to misbehave.

As @Matma Rex pointed out, sig. validation won't affect these, though. Pelagic (talk) 21:54, 7 May 2020 (UTC)

Support, but not sure about font

<font face="Helvetica">

is a lot shorter than

<span style="font-family: Helvetica"> Headbomb (talk) 18:34, 4 March 2020 (UTC)

The font tag is deprecated in HTML5, which means that browsers could remove support for it at any time. For more details, see:

https://www.mediawiki.org/wiki/Help:Lint_errors/obsolete-tag

https://html.spec.whatwg.org/multipage/obsolete.html#non-conforming-features Jonesey95 (talk) 20:08, 4 March 2020 (UTC)

I am on the same page as Jonesey. It is nice that it is short but browsers may stop supporting it at any time, in which case all those beautiful customized signatures will not be beautiful anymore. Izno (talk) 21:30, 4 March 2020 (UTC)

I definitely agree that <font> shouldn't be used anymore, but I'm also aware that there are probably still editors that are a) still using it, b) close to the character limit, and c) would run to the dramaboards because the evil WMF banned their personal signature out of spite. If anyone has any sort of data to say how prevalent font tags are in signatures, it would probably help guide this decision. AntiCompositeNumber (talk) 23:37, 4 March 2020 (UTC)

Alright, I ran the numbers: there are 6705 enwiki editors with a font tag in their signature already. Some of them clearly haven't been changed in a while, since they predate the software-enforced 255 character limit. There are 1916 enwiki editors with a font tag and a signature longer than 200 characters. Nothing would break immediately for these editors if they did not change their signature, but many would be unable to make any edits to their signature without removing the existing formatting (because the span tags are too long). AntiCompositeNumber (talk) 00:07, 5 March 2020 (UTC)

Do you have a way of knowing how many of those 1,916 editors have made an edit in the last year? That would give us an idea of how many people may actually be affected by font tags being deprecated.

And FWIW, changing a font tag to a span tag if you are setting the font face, as in Headbomb's example above, adds 14 characters, but if you are just setting the color, it adds only 7 characters. The vast majority of editors should be fine, and a few might have to make do with a bit less customization. Jonesey95 (talk) 00:29, 5 March 2020 (UTC)

It would probably also be a good idea to post suggested fixes to the signatures. For example a bot message like

Blah blah blah, linter error, html 5 blah blah blah, which is bad because of explosions, murder, and possibly jaywalking

• Current signature: <b>[[User:Example]]</b>, which renders as User:Example
• Suggested signature: '''[[User:Example]]''' which renders as User:Example

A message from FIX-YO-SIG Bot 00:41, 5 March 2020 (UTC)

Headbomb (talk) 00:40, 5 March 2020 (UTC)

I think I would tend toward a "see Project:Signature fix page for a list of common optimizations and feel free to ask on the talk page if you need help changing your signature."; even in your example, there might be context such as <span> elements with styling that could instead be turned into <b> elements with styling.

But, that's implementation details. Izno (talk) 01:53, 5 March 2020 (UTC)

That's also a good potential workflow. Possibly with a bot posting basically a similar message and pointing them to that signature fixing page. Headbomb (talk) 19:24, 5 March 2020 (UTC)

Well lint fixing experiences of the past show that you can't even write a bot for some of these things, so either we need a really smart AI, or we just have a page where some humans help out. —TheDJ (Not WMF) (talk • contribs) 09:17, 5 March 2020 (UTC)

363 editors have font tags and have made an edit since 2019-03-04T00:00:00Z. AntiCompositeNumber (talk) 00:46, 5 March 2020 (UTC)

I do not think 363 is really a sufficient quantity to support font, and eyeballing the majority of the cases pulled up in that query, I don't really think the signature lengths I'm seeing need it either given a number of optimizations I can see being made to most of those signatures. For the others, I don't think they should really be running around with such individuality as I'm seeing.

(But thank you for the tasty data.) Izno (talk) 01:38, 5 March 2020 (UTC)

Also this editing interface is garbage. ~ Headbomb (talk) 18:35, 4 March 2020 (UTC)

This community prefers that people start in visual mode. The pencil icon in the corner by the "Reply" button will let you switch to wikitext mode (automatic sticky preference, so make it in your next reply, and it'll remember it until you change it). Whatamidoing (WMF) (talk) 19:01, 4 March 2020 (UTC)

I'd definitely agree that prohibiting <font> tags will cause unnecessary complaints. The other requirements seem to be reasonable and enforced by policy and/or angry editors in many places already. The overall decision to deprecate and remove font tags as lint errors is probably outside the scope of this proposal though. AntiCompositeNumber (talk) 19:12, 4 March 2020 (UTC)

It's not only the familiarity of the font tags themselves, but also the length saving. The difference between font/span example above is a whopping 14 characters.

Everything else seems kosher. Headbomb (talk) 19:17, 4 March 2020 (UTC)

It's really not evident in the least that a pencil icon switches between different editing interface. Headbomb (talk) 19:13, 4 March 2020 (UTC)

It is the standard button for it throughout OOUI. AntiCompositeNumber (talk) 19:15, 4 March 2020 (UTC)

I'd say it's equally confusing everywhere it's used then. Anyway, that's irrelevant to signatures, so let's stop here. Other fun fact about VE discussions, you can't collapse/archiving side discussions or re-indent them to make them follow one another. Yaaayyyy. Headbomb (talk) 19:18, 4 March 2020 (UTC)

(Technically, this is Flow, which happens to use a version of VisualEditor as one of its editing environments. I'm not sure that there's even a name for Flow's wikitext mode. I think that both desktop and mobile use the same tools in Flow, so you should only have two, rather than four, editing systems here.) Whatamidoing (WMF) (talk) 17:27, 5 March 2020 (UTC)

I'd definitely get rid of ‎<font>...‎</font> tags. All too often you get something like <font face="Helvetica">''' ... '''</font>, which translates to <b style="font-family:Helvetica"> ... </b>, which is only one character more. It's often possible to use style="font:Helvetica" if the other font property defaults are okay at that point, and that actually saves six characters net. When you get colour changes at the same point, you increase the savings, and because styles can be applied to ‎<i>...‎</i>, ‎<sup>...‎</sup>, ‎<small>...‎</small>, etc. there are lots of opportunities for applying a style without adding a span. That very often results in a net decrease instead of a net increase in sig length. RexxS (talk) 22:48, 9 March 2020 (UTC)

Can you provide an example where style="font:Helvetica" actually works? Anomalocaris (talk) 00:39, 15 April 2020 (UTC)

It has to be "font-family:Helvetica", not "font:Helvetica". You probably won't see any difference with Helvetica anyway, since there's a good chance that it is or is very similar to your default sans-serif font. If we use "font-family:serif", like this, there is a clear effect. AntiCompositeNumber (talk) 01:14, 15 April 2020 (UTC)

In other words, when RexxS said,

It's often possible to use style="font:Helvetica" if the other font property defaults are okay at that point, and that actually saves six characters net.

this was entirely incorrect. Anomalocaris (talk) 01:22, 15 April 2020 (UTC)

No? font is shorthand. Izno (talk) 01:30, 15 April 2020 (UTC)

Izno: That shorthand requires a font size. Examples:

• <font face="Times">The quick brown fox jumps over the lazy dog.</font>

The quick brown fox jumps over the lazy dog.

• <span style="font:14px Times">The quick brown fox jumps over the lazy dog.</span>

The quick brown fox jumps over the lazy dog.

• <span style="font: Times">The quick brown fox jumps over the lazy dog.</span>

The quick brown fox jumps over the lazy dog.

Without a font size, the markup doesn't work. In English Wikipedia, rather than 14px, I need 12.7px to make the lines the same, and although English Wikipedia uses a default font size=small, using "small" instead of 12.7 results in a slightly larger-than-default font size, unlike <span style="font-size:small">, which has no effect on size. Anomalocaris (talk) 01:54, 15 April 2020 (UTC)

Entirely incorrect - apart from all the documentation on the CSS font property, of course.

For example:

https://developer.mozilla.org/en-US/docs/Web/CSS/font

"The font CSS property is a shorthand for font-style, font-variant, font-weight, font-stretch, font-size, line-height, and font-family. Alternatively, it sets an element's font to a system font.

Nevertheless, as you say, it doesn't work if you only specify the name(s) of the font-family. Oddly enough, style="font:1em serif" actually works.

This is serif text

So I can only save 2 characters net (unless you also want to change the font size at that point). I have no idea why some combinations of properties work and others don't. RexxS (talk) 02:02, 15 April 2020 (UTC)

because css AntiCompositeNumber (talk) 02:13, 15 April 2020 (UTC)

Indeed RexxS (talk) 02:20, 15 April 2020 (UTC)

Support link, oppose linter

First I want to note that I'm not a fan of putting this on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the Leopard. I only saw it because it accidentally turned up in the middle of a list of Phab search results.

The link requirement is helpful to users, the error message would be clear and simple, and it's surely in line with policy or practice at probably every wiki.

The linter portion is not remotely supported by the why rationale offered for the proposal. It would pointlessly disrupt users with confusing error messages on perfectly valid wikitext. It would be insane to suggest things like <small><sup>this</small></sup> could or would ever be banned. @Whatamidoing (WMF) Please ping me if linter is dropped from the signature proposal. In that case I can skip incorporating this signatures item in a linter-related discussion planned for the new EnWiki Village Pump page. Alsee (talk) 07:34, 8 March 2020 (UTC)

@Alsee That example isn't perfectly valid wikitext though. It's a side effect of a old, broken parsing system that is being replaced, and shouldn't be used. If you've got a suggestion about where this proposal should be further publicized, I'm sure we'd all be glad to hear it. AntiCompositeNumber (talk) 15:58, 8 March 2020 (UTC)

@AntiCompositeNumber your argument is completely unrelated to the rationale given for this proposal.

Instead of trying to push through the linter issue under a deceptive rationale, how about we allow the Require a link to user page, talk page or contributions portion sail through uncontroversially. Then you or anyone else can make a separate linter proposal with the authentic rationale. Then I can more neatly wrap the linter topic inside a discussion I plan to open on the Foundation's broader strategy around VisualEditor. There has been too much conflict between the Foundation and the community, too many failed products, and it primarily traces back to the strategy around VisualEditor. The Foundation and the community need to get in better alignment on our broader strategy, and one possible outcome is that the rationale you just gave for linter vanishes. Alsee (talk) 22:04, 9 March 2020 (UTC)

I don't see what this proposal has to do with VisualEditor. Regardless of whether the WMF uses VE or Parsoid for talk page replies, they will still need to be able to reliably detect signatures in order to reliably add reply buttons, which is impossible right now. Requiring signatures to use sane HTML makes detection much easier. Of course it also has lots of other nice side-effects like making signatures render consistently regardless of HTML doctype and making it easier to migrate to Parsoid (or any sort of modern DOM-based parser), but that's not really the point. Kaldari (talk) 00:52, 10 March 2020 (UTC)

Setting aside the other issues, you can't actually impose any constraints at all on signatures. Anyone can type anything as a signature - or even automate it with a userscript. -- Main (talk) 25:68, 44 March 4130 (UTC)

Sure -- and people can just not sign their messages at all. That's like saying Wikipedia shouldn't have verifiability standards because anyone can edit. AntiCompositeNumber (talk) 04:55, 10 March 2020 (UTC)

It was included today in Tech News: Tech/News/2020/11. Matma Rex (talk) 17:31, 9 March 2020 (UTC)

In general, I'm in favour of grandfathering in signatures when the rules change. However, there really is no excuse for having linter errors in a sig, and I'm speaking as someone who had errors in my sig for years until it was pointed out. They might still be there in wikis I visit only rarely.

Unclosed bolding, italics, small etc can cause enormous problems on pages that are transclusions of many other discussions, messing up the entire page. Examples are Wikipedia's DYK and AFD log pages. It is annoyingly time consuming to track down which discussion caused the problem and which post in that discussion, let alone find the actual error. SpinningSpark 13:16, 1 April 2020 (UTC)

Disable "fancy" signatures entirely

Per en:WP:SIGRANT. ToBeFree (talk) 18:54, 9 March 2020 (UTC)

I wish. AntiCompositeNumber (talk) 18:59, 9 March 2020 (UTC)

I disagree. Computers work for humans, not the other way around, and I enjoy the diversity of user signatures on ENWP which already has several guidelines in place at https://en.wikipedia.org/wiki/Wikipedia:Signatures. ↠Pine (✉) 19:35, 9 March 2020 (UTC)

On the other hand, ‘diversity of user signatures’ makes our wikis less welcoming to people with colour blindness and disabilities that require using a screen reader to edit (since, I imagine, they have to go through a lot of useless code to know, say, who to ping in a discussion). You have to wonder what kind of diversity we should value. stjn^[ru] 21:30, 9 March 2020 (UTC)

Four years ago I wrote a script that removes most of signature clutter it can detect (only possible to use in Russian wikis, but I can probably fix it), so obviously I concur. stjn^[ru] 21:33, 9 March 2020 (UTC)

Imagine that a postal service started demanding we sign our letters in a particular way. Don't be so restrictive. It is unnecessary and condescending to volunteers SpinningSpark 13:26, 1 April 2020 (UTC)

No imagination needed: Emails sent via Wikipedia are text-only ToBeFree (talk) 15:09, 1 April 2020 (UTC)

Maybe you can't imagine the difference between w:mail and w:e-mail SpinningSpark 15:25, 1 April 2020 (UTC)

How many is "a few"?

The WMF is conceding that there are a few signatures that would be non compliant, but has not quantified this, notified those whose signatures would need to change, or told those individuals what change they might need to make. Most wikipedians are reasonable. I believe that many would simply change their signature if they received a polite request "Hi, the developers are looking to change the signature rules slightly. If this goes ahead you would need to change your signature from "this bunch of text" to "this bunch of text", there is a discussion "here". The rest of us would probably relax if we knew that it was being handled this way. WereSpielChequers (talk) 09:52, 10 March 2020 (UTC)

By my count, about 8200 enwiki editors with edits in the last year. Most of those editors are new contributors who put plain text into the signature box and clicked "Treat this as wikitext" without reading the warnings around it. The original proposal was to leave these signatures in place, but there has been (at least initial) support for a process of depreciation and removal. AntiCompositeNumber (talk) 13:44, 10 March 2020 (UTC)

To be clear, with the plans we have right now, no one will need to make any changes to their signature. Even if your existing signature would be invalid under the new rules, it will still be allowed, and you'll only need to make changes if you're trying to change your signature anyway.

We're considering doing something about existing signatures (see the discussion other sections on this page), but right now we have no plans, and if we end up doing anything, we should notify the individual users as you suggest. Matma Rex (talk) 21:17, 12 March 2020 (UTC)

Even though there is no plan to invalidate signatures yet, I think that some users would like to be able to check whether theirs (or their friends') are "on the list". When Tidy was removed, I remember that @Anomalocaris talked to a lot of individual editors about fixing their signatures, and I think most people were cooperative about it.

@AntiCompositeNumber, do you think it would be worth turning that into an editor-friendly list with sections like "These people should untick that button" or "These people should add a link", and post it on the relevant wiki? Whatamidoing (WMF) (talk) 16:45, 13 March 2020 (UTC)

A tool to check a single person's signature wouldn't be very difficult. I'll work on that. AntiCompositeNumber (talk) 18:06, 13 March 2020 (UTC)

I started my effort to ask enwiki editors to fix their signatures on October 15, 2017. I tracked this effort in multiple spreadsheets, and there may be some names that appear in more than one. I estimate that by now I have made signature requests of about 990 editors. In descending order, the four most common issues were (1) obsolete font tags; (2) Tidy bug affecting font tags wrapping links, now known as Old behaviour of link-wrapping font tags; (3) enlargement with font size or big markup; (4) other lint issues including misnested tags, missing end tags, other obsolete HTML, and stripped tags. In no particular order, there were also (5) use of subst to exceed the 255-character limit; (6) excessive text shadow; (7) use of the unescaped pipe character; (8) signatures with images. I never observed a signature that lacked a link to user page, talk page or contributions. I never observed a signature with nested substitutions.

About 1% refused to comply. About 9% ignored my request and continued to use their non-compliant signature. About 15% may have fixed their signatures, but I never saw and recorded that they used their signature after my request. About 75% I recorded as having fixed their signatures.

"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." Yes, let's notify users that this change is coming, and then use default signatures in place of existing invalid signatures. Is this the right place for me to put this comment? Anomalocaris (talk) 19:08, 13 March 2020 (UTC)

> Is this the right place for me to put this comment?

Yes. Pretty much any place on this page is the right place to put your comments. MediaWiki.org isn't a bureaucratic place. :-) Whatamidoing (WMF) (talk) 00:21, 14 March 2020 (UTC)

@AntiCompositeNumber You might look closer to the time of the most recent edit or editcount when informing projects about a list of problematic signatures.

• I took your analysis and did inform the 8 most seriously affected users at dewiki.
  • These were missing end tag and 1 nested-subst.
  • The nested-subst has been an experiment by a user who made one article edit and never showing up again, obviously just playing around.
  • 4 users are editing on a daily base, they did change the signature immediately.
  • 4 users made their last edit 2, 5, 8, 10 month ago, some with lower total count.
  • All were actually misnested and remedied anyway by REMEX (tidy) cleanup. They did not harm to subsequent contributions.
• In general it is a very good idea to feed a short list to communities in order to support people in fixing and explaining in their own language and by local techies.
  • However, the list should be as short as possible to keep the task feasible.
  • I would limit myself to 1 or 3 months; who is off for a longer period does not sign and will not respond on talk page notifications.
  • Only most disturbing effects should be listed (non-empty without link, closing tag missing, subst etc.).
  • You may provide a JSON list offline with complete data, but many projects might be unable to derive conclusions from that.
• Decorative issues, styling, obsoleted HTML which will work for decades should not be mentioned in first place project information. It is up to projects to check that with their local guidelines.
• If someone is using an inappropriate signature, other users will note that and start reminding and demanding earlier or later.
  • Affecting subsequent contributions is not obvious to the user itself, but will be observed by the next editor at the last section of thread. Here it is really helpful to get early notification and rejecting storing that preference. PerfektesChaos (talk) 14:16, 15 March 2020 (UTC)

Hey, I don't write the requirements, I'm just trying to help everyone make a more informed decision. I do agree that most of the users in the initial lists were just experimenting and have now left. A potential bot making notifications would be in a better position to evaluate the activity of users before notifying, as total run time is less of a concern.

Anyway, I put https://tools.wmflabs.org/signatures together. It allows you to check a single user's signature (with basic explanations of the problems) or view a nicer form of the aggregate listings. Those lists now only cover editors with an edit in the last 30 days. Remember that this tool still only shows preliminary findings, and may not totally represent what future MediaWiki developers may implement. (This is especially the case for nested substitution, as I don't have a reliable way of implementing it without many false positives or false negatives). PRs/suggestions/bug reports are of course welcome. AntiCompositeNumber (talk) 03:57, 16 March 2020 (UTC)

User:AntiCompositeNumber: Your wmflabs tool looks great! Questions and comments:

• Nested substitution (5) include 4 that have single tildes (~) and 1 that has double tildes (~~) and none with more than 2 consecutive tildes. I don't think single and double tildes are a problem. (Experimentally, in enwiki, it does not seem to be possible now to create a signature string with more than 2 consecutive tildes, with or without checking the "treat as markup" box.) What say you?
• There are no counts of various lint errors such as Misc Tidy replacement issues. I assume you checked for all lint errors, yes?
• Did you check for unescaped pipe characters, and if not, can you add this?
• enwiki user Anomalocaris 500 recently established a signature that unintentionally impersonates another user, viz:

  [[User:Anomalocaris 500|Anomalocaris]] ([[User talk:Anomalocaris 500|talk]]): Anomalocaris (talk)

  Would it be possible to add a check that signatures don't display another existing user's name? Maybe that should be a separate project altogether.

• Note that the site report link meta.wikimedia.org does not work. Anomalocaris (talk) 05:59, 16 March 2020 (UTC)

I have improved the nested substitution check, and it shouldn't have false positives anymore. (Originally, the check was only "has three tildes anywhere". I later wrote a function to evaluate subst:, but never improved the nested check. It now uses recursive substitution on signatures with templates.) There is no filtering for lint errors: all errors returned by the Linter API are reported. I have not written checks for unescaped pipes or impersonation, as they are not part of this proposal. Both would require a wikitext-aware parser, which could slow things down. I've added it to my list. The meta.wm.o report hadn't been updated yet, that's fixed. AntiCompositeNumber (talk) 18:10, 16 March 2020 (UTC)

User:AntiCompositeNumber: I went to your GitHub page. I don't want to join GitHub, so I'll just share that other things that could be wrong with signatures include:

• External links
• Zero characters in Latin script (or the native script of the Wiki)
• enlargement
• line breaks
• too small to read
• horizontal rule
• insufficient contrast between foreground and background color
• insufficient contrast between text and text shadow
• text shadow extends above or below signature into surrounding text Anomalocaris (talk) 20:20, 16 March 2020 (UTC)

@AntiCompositeNumber

1. I created a German docpage for your lovely tool.
2. There may be more than one alias for user namespace.
   • In German and Portuguese there is a female word for “user”.
     • The tool is blaming our female editors Benutzerin: for missing link.
   • There might be shortcuts; BD: is legally abbreviating Benutzer Diskussion: which works: w:de:BD:PerfektesChaos.
3. Pointless but valid spaces after colon might be ignored; see: Benutzer: Cham xxx Eleon PerfektesChaos (talk) 11:09, 17 March 2020 (UTC)

Doh! There's a second API endpoint to get the rest of the namespace aliases, and I forgot to include it. I also accidentally left test data in the single-user form, which limited the sites available in the form. All fixed now. AntiCompositeNumber (talk) 00:00, 18 March 2020 (UTC)

Yeah, fine.

I have notified a dozen of users and suggested a change.

For a future Global Signature Policy I would recommend:

• Do not permit substitution since no persistent evaluation possible.
• Do not harm subsequent contributions:
  • Closing tags (including '' and ''') required.
  • Valid tag nesting to simplify checks and supervising.
• Valid HTML.4 (as of 1998), postponed goal
  • That will say: Fade out <font> but leave <tt> until further decisions next decade.
  • <font> might be replaced by CSS with no big deal, and signatures consuming the last byte of some permitted 255 and do not fit with CSS are much too long anyway.
  • <font> has gone forever, and it always needs attributes; so it might be span style= instead.
  • <tt> might be re-established by HTML6 or MediaWiki, and replacement is not very comprehensive and would start exhaustive debates.
• A link to any page of this user is mandatory.
  • Might be either talk or main user page.
  • Might be in another project, but the identical nick.
  • Some global accounts may be contacted better at their home wiki than as rare visitor on some small wikis.
  • I am in doubt whether subpages of main user and main talk page should fulfil that requirement. That will say, whether a slash / shall be permitted. German Wikipedia has special rules on main talk page, which must not be deleted ever (and moving will be logged), and it is much easier to extract user name from one link type than stripping off subpages.
  • Possible rule: No other user or user talk link than signing user may occur, but any other project page may be linked. Reason: machine-readable identification of the signing user rather than multiple hits for several nicks. PerfektesChaos (talk) 20:29, 19 March 2020 (UTC)

PerfektesChaos, would it be fair to say that your proposal, regarding HTML validity, is, "No lint errors allowed except stripped tags and obsolete HTML, and also no <font> tags"? You are OK with <tt>. The other two obsolete HTML tags are <strike> and <center>. Perhaps <strike> (and <s>) should be prohibited because not because of obsolete HTML but because it's just confusing to other users if there is strikeout text in a signature. And <center> (or any alignment markup) should be prohibited because not because of obsolete HTML but because it would generate one or more line breaks, which are already prohibited by AntiCompositeNumber's Extended validation criteria and by implication in en:WP:SIGAPP and presumably its equivalent in every other project. I have verified that the Preferences page does accept signatures with markup including <center>...</center> and <div style="text-align:right">...</div>. Anomalocaris (talk) 23:14, 19 March 2020 (UTC)

• On <center> (never seen in a signature) yes, to be blamed, but not for obsolete but for block element.
• The same goes for <div> if not made inline, and <gallery> or <syntaxhighlight> are inappropriate as well.
• I do not think that it is the business of global signature management to enforce in 1000 WMF wikis and external world recent HTML standards.
  • That should be left to local authorities.
  • Some have simply no management power and technical experts.
  • Many users would need a lot of explanation and help, which is not provided by global blaming.
  • Many users will feel patronized by WMF.
  • Browsers are obliged to render old HTML for decades.
  • This is a slow process which needs to grow over many years.
• I would ignore obsolete HTML5 on global level.
  • <font> has gone in 1998 with HTML.4; this one is now ready for stronger reduction. The attributes are unique for this element, they are not matched by any other HTML element. This causes confusion and requires special education in a 1990s concept, which requires resources.
  • <big> is deprecated by HTML5, but as well as <tt> replacement is large and it is hard to convince thousands of users to change their signature right now for no strong reason. Why is <small> still permitted? (I guess I know why) In HTML6 <big> might be rehabilitated, as done by HTML5 with <i> and <b> which HTML.4 had deprecated.
  • <strike> is self-explaining, while <s> is very reduced. Do not mess with users for that.
• HTML in signatures will be improved when article space raised conformity for many years and authors learnt from article sources how it should be done. As long as there are many bad examples everywhere nobody can be convinced to take action and modify their signatures.
  • German Wikipedia has wiped out <font> and <source> in major spaces for several years now, but we get frequently contaminated by C&P and bad examples from enWP.
• The total number of complaints must not exceed capacity of local experts who help to remedy. Keep the number low and narrow cases to most disturbing problems, otherwise people will not deal at all with thousands of warnings.

@AntiCompositeNumber How often do you intend to update reports? I would regard a weekly recollection sufficient. PerfektesChaos (talk) 17:56, 20 March 2020 (UTC)

Everything is still manual at the moment, I'm not planning to run them more than once a week. AntiCompositeNumber (talk) 18:32, 20 March 2020 (UTC)

Questionnaire

The feedback call is starting with three questions.

For ages, German Wikipedia is demanding core requirements (mandatory link, no invalid HTML, no influence to following contributions) or is enforcing now Linter proof signatures by active users, rearranging historical element sequence within old archives if affecting following text. Furthermore, template transclusion is not permitted to avoid eternal maintenance burden, and use of images is strongly discouraged.

On the three questions:

1. Causing any Problems? No.
2. Team preservations? Be careful with communities and keep impact on existing prefs low. Good communications: announcing and explaining.
3. Current signatures? I answered in the section on Should non-compliant signatures be invalidated? and recommended no action or disabling only if affecting subsequent text. Which is undisputable and could not be argued, but would be really helpful. PerfektesChaos (talk) 14:04, 11 March 2020 (UTC)

Out of curiosity, I ran my detection script for dewiki, and they're definitely in a better place than enwiki. Only about 730 total editors active in the last year have potentially problematic signatures, and as with most other wikis, the biggest problem is people turning on fancysig when they shouldn't. Data (If anyone would like data for another wiki, ping me and I'll run it). AntiCompositeNumber (talk) 20:17, 11 March 2020 (UTC)

Thanks for that offer, AntiCompositeNumber. I hope that anyone who's curious or worried will take you up on it. Whatamidoing (WMF) (talk) 18:28, 12 March 2020 (UTC)

Timeline

Tracked in Phabricator
Task T244519

I've just talked to the Editing team, and they plan to make decisions in early April. While comments seem to be slowing down a bit right now, there's still plenty of time to share your ideas. Whatamidoing (WMF) (talk) 18:00, 11 March 2020 (UTC)

Existing signatures

At a minimum, you need to send a wiki notification to all existing users that their "your signature contains markup errors" and "use the verification tool for your signature in the settings." Such verification and sending a wiki notification should be done every time a user logs in to an account or when a signature is automatically inserted. I had to send a lot of messages on user talk pages with the text "your signature contains errors. Because of this, the pages where you leave the signature fall into the lists of pages with errors. Here is a variant of your corrected signature." This should be automatically notified to all old users with a custom signature before they leave a new copy of their signature. Sunpriat 14:58, 19 March 2020 (UTC)

https://tools.wmflabs.org/signatures/ lets editors check their signatures, if they're interested. Getting a list of invalid signatures seems feasible, and we can use MassMessage to leave notes on their User_talk: pages. It's probably only worth notifying active editors, though. Whatamidoing (WMF) (talk) 15:31, 19 March 2020 (UTC)

Role of auto-assigned User ID?

I think that the entire discussion around signature formatting could be set aside if the identification and reply functionality were based on the User ID. On my page https://en.wikipedia.org/w/index.php?title=User:Ceyockey&action=info my User ID is 150564 . It is my belief that this auto-generated ID is a) unique for every newly created account and b) independent of the signature. I would suggest that functionality be put in place that would embed the User ID into the signature, as hidden text, upon use of any of the 3, 4 or 5 tilde signature indicators. I am not familiar with the details of the wikimedia software, so my understanding of the feasibility of this is 0. Thanks for considering, nonetheless. --~ Ceyockey (talk) 02:17, 20 March 2020 (UTC)

This id is different across all wikis. The nickname is the same in all wikis (upon request it is possible to make a different name for one of the wikis, for example, there is "nickname (xxwiki)", but there are not many such cases). Signing with an id on one wiki, on another wiki it will be the id of another person. When registering a nickname, software guarantees uniqueness and discrepancy with old nicknames. So id can be embarrassing, they are less croswiki universal and some will think with prejudice towards someone whose number is less. Sunpriat 12:56, 20 March 2020 (UTC)

Maybe this is an area where WikiData can help: Use WikiData as a place to store the UserID-nickname matrix for each user. Is a UserID created for a person if they have never visited a wiki? For instance, I don't think I've ever visited the Thai wikipedia (th) and just went to https://th.wikipedia.org/w/index.php?title=User:Ceyockey&action=info which shows my user ID as 380,192; I confirmed after checking the ID that I have no contributions on that wiki. I then looked at the Statistics page and found that the number of registered users is listed as 378,272. This - by a looong stretch - leads me to speculate that my ID was not created until I first visited the site, assuming that the Statistics page is not updated in real-time and assuming that User IDs are created in sequence. So, a routine could be added that would append a user page in WikiData with a newly created User ID when they first visit a particular wiki. Thoughts on this noodling? Ceyockey (talk) 01:28, 4 April 2020 (UTC)

Oh -- and I just took a look and I got a Notification that a bot has just put a new user welcome on my talk page on the Thai wiki. So there are already routines in place which could be exploited as I noted above. Ceyockey (talk) 01:31, 4 April 2020 (UTC)

Wikidata is a freely editable database of mostly data interesting for the public. The user ID–user name connection is not interesting for the public, and certainly not freely editable (what if I change the enwiki entry for Jimbo Wales to point to my user ID?). By the way, I don’t understand why is it worth using the cryptic user ID instead of the user name. The user name can be added as a hidden text just like the user ID, and software will be unable to understand it if the wikitext is so broken, just like if the user ID was there. (And the link requirement is not only for software’s benefit, but also for users’—if I want to contact the comment’s author, I’d like to click a link and get there, not search in page history or—in case of your proposal—comment wikitext.) Tacsipacsi (talk) 16:09, 4 April 2020 (UTC)

There have been similar ideas in the past (most recently: T230653). This would be possible to do, but:

• it would be a change to the syntax of all signatures and so we're a bit wary of making it
• it isn't clear what should be embedded (as you've already realized here) and it would be difficult to change in the future, since the results are saved as wikitext

We might come back to this at some point, but we're not planning to work on it at the moment. Matma Rex (talk) 19:13, 7 April 2020 (UTC)

Status update

It's the end of March. I think the Editing team has all the information they need for this stage, but they are not in a hurry. If you've got comments/questions/ideas, please keep posting. Expect to see a bit more (e.g., perhaps a timeline) in the next few weeks.

On the community side, I think the main tasks will be:

• updating any help pages (if your community has a page saying that you can do something that will no longer work), and
• asking editors with soon-to-be-invalid signatures to update them. In some wikis, this is just a couple of people, and in others, we'll want to use Special:MassMessage.

Also, Thank you. There's a lot of good information in these discussions, and I really appreciate it. Whatamidoing (WMF) (talk) 22:54, 31 March 2020 (UTC)

I've only just been notified about this (through the WP Administrators' Newsletter) today, 1st April. I see comments are required before 31st March. How was that meant to work? SpinningSpark 13:04, 1 April 2020 (UTC)

This was announced in Tech News, and on your home wiki, at the Village pump (technical) and the bot operators' noticeboard. If you are interested in technical matters, including software changes that affect non-technical users, I recommend subscribing to (and then actually readinng) Tech News each week. I appreciate the help of anyone who decided to share the links further, but naturally the WMF doesn't control their publication schedule.

As for the stated deadline, it was an estimate of when the devs would actually be able to work on this. As you can see from my earlier comment, they're busy with other things this week, so there's no need to stop providing information just because of the earlier estimate. The "real" deadline is a few seconds before they start coding. Whatamidoing (WMF) (talk) 23:35, 1 April 2020 (UTC)

This is not a technical matter. It potentially affects all users. The issue may have a technical solution, but that is no reason to hide it in tech related venues. I'm not going to sign up to tech newsletters just in case something comes up. When you are at the stage of calling for comments, a watchlist notice would be appropriate. SpinningSpark 23:55, 1 April 2020 (UTC)

Solutions to almost all technical problems have the potential to affect all users, e.g., by making it harder, easier, faster, or slower to use the sites. The problems addressed here are:

1. invalid HTML,
2. accurate machine detection of signatures, and
3. how to parse signatures that contain certain characters (i.e., how to turn what's stored in the database into HTML that your web browser can understand).

These all sound like technical problems to me. Whatamidoing (WMF) (talk) 19:33, 2 April 2020 (UTC)

Only link to your own userspace

I don't know how hard this could be, or if I'm potentially late to the party, but I think we shouldn't be able to include links to someone else's userspace; since it will mostly be used for signature forgery or other bad-faith matters. ToxiBoi (talk) 15:20, 11 April 2020 (UTC)

I'm sure I have seen people link a signature from their alternate account to their main account. Plus when people change their username all their old signatures still link to their old name. As for signature forgery and other badfaith stuff, if and when that happens our admins can deal with it. No need for a software solution until and unless something becomes such an issue that a software solution is needed. WereSpielChequers (talk) 15:40, 11 April 2020 (UTC)

Agree with WereSpielChequers. Some alternate accounts, such as bots, might be better linked to the main account than to themselves. ~~~~

Jonathunder (talk) 21:09, 11 April 2020 (UTC)

Outcome

Just a quick heads-up to say that the team decided to implement most of this, but not all of it. Official announcements will be forthcoming, but the overall notion is this:

• They will not disallow all obsolete HTML tags. That could be done later, but they wanted to keep it simpler at this stage.
• Most of the work will happen during 2020.
• After they make the initial changes to MediaWiki, we'll notify active editors if their signatures need to be updated.
  • I think that the most likely approach is a MassMessage for each separate problem ("you need to un-tick that box" to one list, "you need to get the template out of your sig" to another list, etc.). @AntiCompositeNumber has a good system for generating these lists, which means that anyone can start this work at any point, or you can wait for me to send messages.
  • If you can help with translation and localization of these messages, please watch this thread (click the star in the upper corner of *this* thread to make it blue, even if you're watching the whole page [which I recommend, too]). Whatamidoing (WMF) (talk) 20:59, 15 May 2020 (UTC)

It would be good if you could composite media messages where editors are going to get multiple messages, alternatively phase the messages apart so that someone with three problems gets their messages a month or more apart - that would also spread the support side of this. But I do hope you change the signature box validation process first - so any new or changed signatures have to be fully compliant. We don't want a situation where people can fix one problem in their signature by replacing it with something that is about to be a problem WereSpielChequers (talk) 08:48, 17 May 2020 (UTC)

Yes, I agree that the software changes come first.

Are you aware of any editors with three separate problems in their signatures? Whatamidoing (WMF) (talk) 20:11, 18 May 2020 (UTC)

Hi WhatAmI, I would predict that if you make three changes to the software as to what is a valid signature there will be some editors to whom you cause three problems, but i don't know - I would hope the people who want to make these changes would know. However I would suggest a slightly more editor friendly approach re this - remember the foundation is making changes that are causing a problem to these people's signatures, not that these are editors with problematic signatures. A subtle nuance, but a very important one. WereSpielChequers (talk) 20:32, 18 May 2020 (UTC)

Some of these editors *do* have signatures that cause problems, like unclosed tags that cause the whole rest of the page to be rendered in a smaller font, or with strikeout text. I provided links on this page or a related page. Jonesey95 (talk) 20:34, 18 May 2020 (UTC)

Hi Jonesey, I don't know about all other projects, but on the wikis where I am most active, if you use a signature that causes the sorts of problems that you describe, people will point out that you have an invalid signature. Dealing with such signatures is not the problem area, the problem is with signatures that are currently valid, and have been valid for some years. Telling people that a change has been made that requires them to make a change to their signature is different than telling people they have made an invalid signature. WereSpielChequers (talk) 07:14, 19 May 2020 (UTC)

I think we agree then. This page is only about signatures that are invalid in some way. Jonesey95 (talk) 13:55, 19 May 2020 (UTC)

One of the problems is ticking a box to say how you want your custom signature interpreted, without having a custom signature for the software to interpret. This obviously won't be found in combination with any of the other problems, since the existence of any custom signature, including a problematic one, would make this non-problematic. (Now that I think of it, those messages could go out at any time.)

Nested substitution has been banned in policy since before any of us were baby editors, so I don't expect to find many unblocked/unbanned accounts with that problem. I can imagine the other two problems being combined in the same sig, but I don't remember anyone actually reporting an example of it.

Whatamidoing (WMF) (talk) 20:44, 18 May 2020 (UTC)

To clarify, is this change being rolled into the publicly-available software, or is it an internal revision for Wikimedia? If it's being rolled in, will it be a configurable option? MaxHarmony (talk) 09:39, 25 May 2020 (UTC)

This will affect WMF wikis, e.g., the English Wikipedia. I am not certain if it will affect the default MediaWiki core for anyone who upgrades their private MediaWiki servers, but I believe that it will be. Do you have your own wiki? Whatamidoing (WMF) (talk) 16:57, 26 May 2020 (UTC)

I think this should certainly be configurable for non-WMF wikis. I’ve had hard time disabling all password complexity rules, so that I can have 1234 as a sysop password in my own wiki, running on my own computer, in my own local network—nobody will ever try to hack that account, as only my family has even a chance to access the wiki. Similarly, different wikis may have different rules and customs; most wikis will probably never use DiscussionTools, so this change is not technically needed on them etc. (Just to reassure: I have a much stronger password than 1234 here on MediaWiki.org, as it’s a real possibility that someone tries to hack into my Wikimedia account.) Tacsipacsi (talk) 18:03, 31 May 2020 (UTC)

Case of differences between the real username and the displayed username

I wonder if your work will cover the case when someone displays a different username than theirs in their signature. Example: [[user:Foo|Bar]].

This shouldn't be allowed since it is very confusing for everyone. I've already seen people being wrongly pinged, or seeing Foo complaining because someone pinged user:Bar instead of them.

The counterargument "my username is already taken, I want to display my real identity" is a false one. No one complains because they get a phone number they don't like. When one wants to change their username, they can if the account is not taken, or if the account is not in use any more. It is done often. Already used and active usernames simply follow the "first arrived first served rule" and it is clearly not much of a big deal. It happen to me back in the days: my current username was my backup nickname on the Internet. I had the opportunity to built a new identity which was a great experience. Trizek ^{from FR} 10:44, 18 June 2020 (UTC)

I’ve seen various creative solutions that aren’t confusing IMO, including [[User:Foo|foo]] (lower case), [[User:Foo Bar|Foo_Bar]] (underscore instead of space), or [[User:FooBar|Foo]][[User talk:FooBar|Bar]] (user name spanning over the user page and talk page links); Tgr’s signature was at a time roughly [[User:Tgr|TG]][[User talk:Tgr|<sup>®</sup>]] (“registered trademark” logo instead of “r”). [[User:Foo|Bar]] is confusing indeed, but I’m not sure if allowable and non-allowable names can be differentiated using software. Tacsipacsi (talk) 12:13, 18 June 2020 (UTC)

User:Foo using the signature <code>[[User:Foo|Bar]]</code> is not covered by these changes. That's something best enforced by local signature policies and guidelines, not by technical methods as Tacsipacsi described. AntiCompositeNumber (talk) 16:45, 18 June 2020 (UTC)

[[User:Foo|Bar]] will be accepted, as long as your username really is "Foo". I agree that this can be confusing.

Whatamidoing (WMF) (talk) 00:41, 19 June 2020 (UTC)

Local policies need to be enforced. But honestly, who cares about them? Even on Meta, displaying a different username is perfectly accepted.

An a minima requirement would be to highlight the risk of confusion.

At least, we can expect to have a mention button like we have here on Structured Discussions, that would help quoting participants in the discussion. Hoping that would raise questions like "why this user is not listed?". And hoping that people won't tell themselves "I could change my name too". And lead to more confusion. Trizek ^{from FR} 10:46, 19 June 2020 (UTC)

Outcome posted

And one of the devs kindly looked it over to make sure that I got the details correct. :-D

Please take a look at New requirements for user signatures#Outcome and let me know if you have any questions.

The first stage (the point at which people will stop accidentally creating broken signatures) could happen on the normal wikitech:Deployments train that will happen from Tuesday, June 30th to Thursday, July 2nd. The end of "grandfathering" (when invalid signatures will stop being added to pages) is at least several months from now. Whatamidoing (WMF) (talk) 00:48, 19 June 2020 (UTC)

What I'd really appreciate from you: Please tell your local communities about this, especially:

• your local Village Pump (technical) or similar tech forums,
• editors who follow your wiki's signature policy, and
• the people who will get questions about how to fix signatures.

I'll be making some general announcements, but specific messages to individuals and relevant pages would be helpful. Whatamidoing (WMF) (talk) 00:51, 19 June 2020 (UTC)

Template transclusion

Do you plan to avoid templates in signatures?

I recently came across a case on an archived page, where a user used a personalized template. this template changed overtime and the page was really confusing. Trizek ^{from FR} 19:09, 2 July 2020 (UTC)

No, that should still be allowed under the new requirements (as long as the output of the template has the links, doesn't have broken markup, etc.).

It's probably not a good idea to do that, and it's forbidden by policy on at least some wikis (e.g. English Wikipedia's signature policy), but we're not doing anything about that right now. Matma Rex (talk) 01:56, 3 July 2020 (UTC)

Thank you! Maybe adding it on a future release, for safety purposes? Trizek ^{from FR} 10:13, 3 July 2020 (UTC)

Talk page link as image link

AntiCompositeNumber’s report for huwiki lists the following signature as not having a user/user talk link (the user page is Szerkesztő:HoremWeb):

[[kép:horemweb.png|HoremWeb|link=Szerkesztő:HoremWeb]] <sup>[[kép:dd-mdw-jn.png|14px|ḏd md.w jn: szavaknak mondása|link=Szerkesztővita:HoremWeb]]</sup>

Is this invalid according to MediaWiki as well, or it’s just the Toolforge tool that doesn’t recognize it? The resulting HTML has a proper <a> tag in it, so I don’t think that the reply tool (or any other tool) should have issues with it. Tacsipacsi (talk) 23:20, 5 July 2020 (UTC)

You know, I have actually never considered that someone's entire signature might be images…

I tested it and it looks like the MediaWiki code recognizes the links, and this signature is valid. Matma Rex (talk) 13:43, 6 July 2020 (UTC)

Thanks, I thought for some reason that the deprecation period will start tomorrow, so I didn’t test this myself. So it’s up to AntiCompositeNumber to recognize it in his tool, but this might be quite tricky… Is there a way for Toolforge tools to call a real MediaWiki? It would be a lot easier to simply check for

$validator = new \MediaWiki\PreferencesSignatureValidator(
 $user,
 $context,
 ParserOptions::newFromContext( $context )
);
$signatureErrors = $validator->validateSignature( $signature );

If not, probably this could be exposed as an API (which could be used on Special:Preferences as well to provide nearly real-time feedback about invalid signatures, instead of only on save). Tacsipacsi (talk) 22:52, 6 July 2020 (UTC)

I'd be able to fix it by switching my parsing code from parsing Wikitext to parsing rendered HTML, but I don't really have the time/energy for that at the moment. As a personal opinion, I don't think it should be valid, but that obviously didn't make it into this round. AntiCompositeNumber (talk) 03:33, 9 July 2020 (UTC)

No more new broken signatures

It is no longer possible to save an invalid custom signature in Special:Preferences#mw-prefsection-personal-signature.

Some volunteers have already started encouraging editors at their home wikis to update their signatures. Please let me know if you are doing this, or if you would like to do this. Anyone is welcome to do this – it's very helpful! – but we should not accidentally contact the same editors multiple times. Whatamidoing (WMF) (talk) 22:20, 6 July 2020 (UTC)

Status

This change was made about three weeks ago, and the number of active editors with errors seems to have declined during this time. I suspect that this is mostly about new accounts, which can no longer make these mistakes.

I decided today to wait another ~10 days before trying to contact anyone else about fixing their sigs. Especially on the biggest wikis, I don't want to flood RecentChanges with hundreds of messages.

I've started a central help page at New requirements for user signatures/Help. Please put that page on your watchlist (and help me figure out the simplest, easiest ways to explain all of this). Whatamidoing (WMF) (talk) 21:43, 27 July 2020 (UTC)

If you use MassMessage to send the notice, RC won't be any more flooded that with, eg, Signpost publications, and the edits should be marked as bot edits and hidden DannyS712 (talk) 04:32, 28 July 2020 (UTC)

Why "Some use of subst: markup" ?

Subst is now totally useless because it cannot be used to provide the required links to user and talk pages. -- ◄ David L • discuter ► 16:39, 5 December 2020 (UTC)

Originally posted by DavidL at Talk:New requirements for user signatures/en * Pppery * _{it has begun} 17:28, 5 December 2020 (UTC)

@DavidL "it cannot be used to provide the required links to user and talk pages." is incorrect. You can still substitute a template as your signature, provided that the post-substitution text complies with the technical requirements.

The added requirements around substitution refer to uses of substitution that cause the page text to change in subsequent edits after the signed edit. See phab:T230652. AntiCompositeNumber (talk) 19:32, 5 December 2020 (UTC)

So there is a bug because it doesn't work.  ◄ David L • discuter ► 23:33, 5 December 2020 (UTC)

Works for me. AntiCompositeNumber (talk) 03:32, 6 December 2020 (UTC)

Thanks for replies.

I found why it doesn't worked for me: I was using user namespace in French "Utilisateur".

Sorry for this.  ◄ David L • discuter ► 10:06, 6 December 2020 (UTC)

But the error message was about the missing link to user page and talk page. It would be more helpful to report error about the non-existence of the page used in subst, to figure out what is the problem.  ◄ David L • discuter ► 10:09, 6 December 2020 (UTC)

I think it'd be most helpful if MediaWiki.org recognized all the languages, instead of insisting that its namespaces be written in English. :-) Whatamidoing (WMF) (talk) 01:39, 7 January 2021 (UTC)

What about links to subpages?

My sig (on en:wp) is a link to a subpage of my userpage, which then redirects to my userpage. I was advised that it is probably against the new rules, but it is unclear. It states "but a signature that includes only links to another wiki, or only redirects from a former username, will be invalid". But my signature does not contain only links to another wiki or username, and in fact contains no links to another wiki or username. It is a local link to a subpage of my userpage. So it is not clear to me that this runs afoul of the new rules. Please advise. --w:User:Lethe 2601:19B:C00:A55:9492:14C4:BD6A:3D09 18:23, 26 January 2021 (UTC)

@Lethe Your signature must contain a link to User:Lethe, User talk:Lethe, or Special:Contributions/Lethe. You can add links to whatever else you would like, but it must link to one of those pages. I do not believe MediaWiki considers redirects when validating signatures, but I haven't tested it. You can test it yourself by making a change to your signature and trying to save it. For best results, you should link directly to your user page, user talk page, or contributions. Oh, and by the way, you're editing logged-out. AntiCompositeNumber (talk) 20:32, 26 January 2021 (UTC)

You can check what the software thinks about your existing signature in your preferences – if it would become invalid, you'll see a warning message in the Signature section.

My practical advice (after reading the message on your talk page where you explain that this is for tracking your mentions on Special:WhatLinksHere) is to have one "normal" link (perhaps the talk page one) to satisfy these requirements, and one link through the redirect to do your tracking. Matma Rex (talk) 21:13, 26 January 2021 (UTC)

I have edited my signature to include a link to my contributions page, which I believe makes it comport with the rules. I'll note that the existence of subst'ed signatures makes the software-imposed compliance check circumventable even for users who are not grandfathered in, like I would've been. If you want a noncompliant signature, simply save your signature preferences with a compliant template, and then edit the template afterwards. Why anyone should want to do this is beyond me, so it may not be worthwhile to make the software check rule it out. w:User:Lethe ~ 2601:19B:C00:A55:1DED:7E09:624B:B99 (talk) 16:11, 31 January 2021 (UTC)

The requirements are mostly meant to prevent mistakes (e.g. forgetting to link your user page, or messing up the HTML syntax) rather than intentional abuse, so I don't think that's a problem.

Also, in the unspecified future when "all signatures will need to conform", the validity will be checked whenever the signature is used rather than only when it's changed in preferences, so this method won't let you circumvent it. Right now it is only done when changing preferences, since that was the easiest way to "grandfather-in" old signatures. Matma Rex (talk) 17:30, 31 January 2021 (UTC)

I see. Thanks for explaining. w:User:Lethe 2601:19B:C00:A55:FC7C:894D:1494:2E8D 18:49, 3 February 2021 (UTC)

New proposal: No line breaks

Tracked in Phabricator
Task T272322

Hello, all:

To make the Reply tool more reliable, they'd like to introduce another requirement: Signatures should not include a line break.

This mostly appears in messages with fake signatures posted by Extension:MassMessage, but those generally shouldn't be replied to.

I plan to post a description on the main page, but for right now: Do you know of any editor who uses a multi-line signature? I've seen very few, and almost all of those have turned out to be a typo/accidental stray character. Whatamidoing (WMF) (talk) 19:20, 8 March 2021 (UTC)

I can't recall ever seeing one. I'm assuming that this is related to T272667. Jonesey95 (talk) 20:39, 8 March 2021 (UTC)

Me neither. If this requirement gets accepted/implemented, it would be nice if AntiCompositeNumber’s signature checker checked it. Tacsipacsi (talk) 20:25, 9 March 2021 (UTC)

I've added a description at New requirements for user signatures#Additional proposal (2021). On my end, there's no rush. Whatamidoing (WMF) (talk) 01:01, 11 March 2021 (UTC)

Signatures now includes a default check for line breaks, defined as \n <br> <div> <p>. There are 23 occurrences on enwiki. Most seem to be accidental or otherwise what we're trying to prohibit, but there are a few like Ahecht who are using it to stack text inside their signature. That's still probably problematic, and should be done differently. AntiCompositeNumber (talk) 03:47, 11 March 2021 (UTC)

@Matma Rex will correct me if I'm wrong, but I think that <br> (if it's typed as the HTML code, not if it's typed by pressing ↵ Enter) is okay. Whatamidoing (WMF) (talk) 20:16, 12 March 2021 (UTC)

Yes Matma Rex (talk) 22:36, 12 March 2021 (UTC)

Should it be though? AntiCompositeNumber (talk) 23:22, 12 March 2021 (UTC)

Maybe it shouldn't, but it's not causing any issues for DiscussionTools or other existing software. There are many stupider things you can put in your signature, and I don't want us to get bogged in discussions about what should or shouldn't be allowed, which is bound to happen if we propose anything remotely controversial. Matma Rex (talk) 00:00, 13 March 2021 (UTC)

We went ahead with making this change, and it will be deployed this week. If your signature contains a line break, you'll see a warning message in preferences, similar to how the other requirements are handled right now:

Your current signature is invalid. Although you can still use it, you won't be able to change it until you correct it.

Your signature must consist of a single line of wikitext.

This change is included in 1.37.0-wmf.3, which is being deployed this week. It'll reach Wikipedias this Thursday, 29 April, assuming everything goes well. Matma Rex (talk) 17:07, 28 April 2021 (UTC)

Enforcing length in templates

From w:en:Wikipedia talk:Signatures#Length section:

Right now, the maximum length for a custom signature is 255 characters (or 255 bytes?). This is already enforced by the software.

However, if your custom sig is {{subst:my-sig-template}}, then right now, that's "25 characters", even if the template contains the entire text of Homer's Odyssey.

My question for you: Do you all want me to ask for them to start checking the length of signature templates? There's no software need for this (that I know of), but if this is something that editors want, then I'm willing to make the request. Whatamidoing (WMF) (talk) 16:56, 2 April 2021 (UTC)

A template that contains the entire text of Homer's Odyssey will break the page. So yes, please ask to check the length of signature template. Dyolf77 (WMF) (talk) 10:05, 13 April 2021 (UTC)

Using someone else's signature template

@Matma Rex and @AntiCompositeNumber, please see https://signatures.toolforge.org/check/it.wikipedia.org/Francesco%20Ippolito I don't know whether this is wrong or just appears wrong, but if feels like a bad idea even if it should be "legal". Whatamidoing (WMF) (talk) 18:44, 19 April 2021 (UTC)

Looks like the user was renamed, see [2]. Everything redirects to the current username, but it boils down to the same old problem of renamed users not updating their signatures. AntiCompositeNumber (talk) 18:49, 19 April 2021 (UTC)

That seems like a local issue to me. This might be a renamed user and hence valid. It does appear wrong, though, and I would not personally encourage it. Jonesey95 (talk) 18:50, 19 April 2021 (UTC)

Is there ever a use case for this? Maybe I have two accounts, and use the same sig template for both? Whatamidoing (WMF) (talk) 02:15, 4 May 2021 (UTC)

Invisible links are fine

Just a note that the link to your user/talk/contributions page can be invisible, and this works fine and is accepted. Maybe this can be added to the main text. See my signature here, which visibly only links to my home wiki, but contains an invisible link to my local user page to satisfy the needs of MediaWiki: – gpvos (talk)User:Gpvos 16:38, 2 February 2024 (UTC)

We have an essay on the English Wikipedia called en:Wikipedia:Don't stuff beans up your nose that covers potential instructions like this. I do not think that putting information like this on the page would be helpful. Jonesey95 (talk) 23:47, 2 February 2024 (UTC)

I agree that this is a bug rather than a feature, and as such, it shouldn’t be documented as a feature. I’m not sure if it can reasonably be fixed, but at least we shouldn’t advertise it. Tacsipacsi (talk) 13:38, 3 February 2024 (UTC)

A similar method has been mentioned on nl:Wikipedia:Gepersonaliseerde handtekening since August 2020. The recommendation there is to use [[User:YourName|‍]]. So there is at least one more editor who doesn't consider this to be stuffing beans up one's nose. – gpvos (talk)User:Gpvos 12:10, 29 February 2024 (UTC)

What is the status of this page?

I don't understand. The lead discusses this page as an on-going proposal. Yet there is an "Outcome" section. So what is the status of this page? Are new proposals still accepted? JWBTH (talk) 14:30, 10 November 2024 (UTC)

The validator in Special:Preferences was implemented, but it was determined that it was not necessary at this time to require that existing signatures be changed. I am not aware of any ongoing work in this area, nor any intentions to do any work in this area. AntiCompositeNumber (talk) 14:34, 10 November 2024 (UTC)

The proposal is accepted and closed, but the project to implement it is still on-going, or at least not finished. New requirements for user signatures#Outcome says that non-conforming signatures will be disabled, but this was not done yet (T248632), except in two projects where local community volunteers led that work (T355462, T364769). See also current state of the relevant config here.

The page could probably be cleaned up a bit, it stayed in limbo after the Editing team has moved on to other work.

If you wanted to propose more signature requirements, I suppose you'd do that in a Phabricator task instead. Matma Rex (talk) 21:42, 10 November 2024 (UTC)