Add support for change tags, remove summaryAd

[Amorymeltzer]

See individual commits for details, but basically:

• Defines Twinkle.changeTags = 'twinkle' in twinkle.js and applies that across the board
  • Applied to Morebits.wiki.page via setChangesTags(), and manually to Morebits.wiki.api via tags
• Excludes PageTriage (T252980) and FlaggedRevs (T247721) (and other
• Remove customization of summaryAd preferences (they options remain hidden as backups, including for use in the above)

There's some precedence for at least being polite and asking before creating a tag like this; I'll post at VPT at some point. cc @MusikAnimal since this would be a notable change. Closes #265

[Amorymeltzer]

This could be nicer to situations where no tag is desired, thus summaryAd would be. I'm open to ideas for handling that nicely. One way I suppose would be to change setChangeTags to adjust ctx.editSummary if given a second parameter, so that it'd look something like:

this.setChangeTags = function(tags, summary) {
	if (!summary) {
		ctx.changeTags = (!!tags && (typeof tags === 'string' ? tags : tags.join('|'))) || '';
	} else {
		ctx.editSummary = ctx.editSummary + summary;
	}
};

pageobj.setChangeTags(Twinkle.changeTags);
pageobj.setChangeTags(null, Twinkle.getPref('summaryAd'));

That's really not ideal. It'd also require having setChangeTags after setEditSummary every time.

A quick survey (grep -n -B 1 setChangeTags *|grep -v setChangeTags |grep -v setEditSummary|sort|uniq) suggests only a few items would need to change, namely the places in things like tag and xfd where setChangeTags is used before the callback so that it applies down the line, although that's a nice behavior.

[Amorymeltzer]

@Xi-Plus IIRC you already have a tag, but I wonder how other folks (@Huji?) feel about the above idea re: adding appending to the edit summary if no tag is defined: #969 (comment)

[MusikAnimal]

Just now seeing this. Exciting! Change tags are much easier to query than edit summaries :) Especially because users can alter or blank the summaryAd, making it difficult or impossible to identify when Twinkle was used.

Change tags don't apply to logged actions like deletion, right? I think we should continue to use summaryAd on those. You might consider removing the ability to configure it too, if people don't care. The point is to be able to identify semi-automation, and if we allow the "ad" to be configurable then we could lose that.

[Amorymeltzer]

@MusikAnimal Thanks, and they do! You've basically identified all the reasons for it, but inclusion for actions and in log entries is another big one. Noted in the commits, but, for things we care about, only PageTriage and FlaggedRevs don't allow them yet.

I do kind of like the idea of hardcoding it, even beyond presence in prefs.

[Amorymeltzer]

Having thought about it for a bit, I don't think we should try to auto-edit edit summaries. It's a lot of extra overhead and using a changetag simplifies and improves a lot of things greatly.

Rebased, etc. I've incorporated @MusikAnimal's suggestion above, the two remaining uses of Twinkle.getPref('summaryAd') (FlaggedRevs and PageTriage, which don't currently allow for revision tags) now use the hardcoded Twinkle.summaryAd (for emotional continuity, although I'd prefer clarity taglessAd). The deprecated summaryAd, deletionSummaryAd, and protectionSummaryAd remain in Twinkle.defaultConfig but not in twinkleconfig.js, so they should be available for anyone relying on them for a bit (atm, I think just Belle's arb.js) but not customizable.

Any final objections or suggestions? I'll be notifying WT:TW/WP:VPT tomorrow.

[Amorymeltzer]

Leaving morebits tag blank per feedback, but the option remains.

[Amorymeltzer]

🎉 🏷️ 🎉