Topic on Talk:New requirements for user signatures

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.

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.

@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.

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, is your dataset from enwiki?

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).

I'm wondering whether we might see more interwiki links at Meta.

@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

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. … 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.

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.

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.

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?

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.

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.

None of ~riley's contributions there have been signed... nl:wikt:Special:Contributions/~riley. Where are you seeing a sig AntiCompositeNumber?

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.

Or a Toolforge tool. There is a grant named editmyoptions, which allows OAuth tools to change preferences.

Wondering, we have global user pages, global js, global css, why not global sigs?

phabricator:T188200

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.

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.

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.

The reply tool handles my signature correctly. Is there a problem with it?

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.

@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.

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!

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.

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.