Currently neither editor supports this, as far as I know. You can only provide a default edit summary, using &summary=, in both editors.

There is no way in MediaWiki for a user to add change tags when saving an edit using a normal editor. MW's core editor supports a wpChangeTags parameter, but this is only supported when added to the POST-ed form, not as a GET query parameter (it is intended to be used by tools/gadgets that extend the core editor). There are also restrictions on who can add tags and which tags can be added in this way. The API has a tags parameter with the same intended use and restrictions.

@matmarex - For this project, support would only need to be added to VisualEditor. Just to clarify, is it currently possible to create a specific tag that anyone (even anonymous editors) can add (via the API)? I assume so, but would like to double-check.

I didn't know either, so I investigated, and it looks like applying tags with your edit requires the 'applychangetags' user right, which is only granted to registered users (not anonymous/IP).

Note that there are two kinds of change tags, as seen on https://en.wikipedia.org/wiki/Special:Tags:

• "Applied manually by users and bots": These tags are applied by software running entirely client-side, using the parameters I mentioned earlier – mostly by gadgets and user scripts, but also some desktop software. Applying these tags with your edit requires the aforementioned user right.
• "Defined by the software": These tags are applied by server-side code, including MediaWiki and its extensions. They can't be applied manually by users, only when the software decides to add them – e.g. AbuseFilter can mark edits with its tags regardless of who and how is making that edit.

So to solve this, given these limitations, you'd need to write some server-side code to detect these edits and mark them with some software-defined tag. Maybe some client-side code too to forward the URL parameters to the API queries used by VisualEditor.

We haven't discussed this yet, but personally I would rather see this code added somewhere else than the VisualEditor repos, maybe in mw/ext/WikimediaEvents. If existing MediaWiki hooks don't make it possible, we could add some hooks for it (in MW or in VE).

@Reedy should know the answer, since he made AWB add tags. :-)

In T209132#4750934, @Whatamidoing-WMF wrote:

@Reedy should know the answer, since he made AWB add tags. :-)

I think doing it via the api is completely different...

But I guess the AWB isn’t a normal editor, nor is the API :)

There are exactly the same limitations for adding tags via action=edit API tags parameter (AWB probably uses this, I can't imagine how else it could work) and the normal editor wpChangeTags parameter. (Actually, fun fact, the action=edit API internally calls the normal editor, and it passes the tags it receives as wpChangeTags to it.)

I think we should implement this for wikitext editor as well, since users can switch back-and-forth between the modes without really leaving the editor. Luckily, this should be the easy part, as I just realized we already implement that with the 'veswitched' URL parameter used to set the "Visual edit: Switched" tag.

On second thought… Considering the multitude of configurations regarding which editors can be enabled and how you can switch between them, I'm not sure if we can commit to supporting this. We probably can't do that urgently (and I still don't know what the deadline is here…). So I am going to assume that you know what you are doing when you request that this feature only work in VisualEditor.

Change 475896 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/WikimediaEvents@master] Allow VE edits to be tagged based on '&campaign=...' URL parameter

https://gerrit.wikimedia.org/r/475896

@matmarex - For now, it's fine if this only works in VisualEditor. Thanks for your quick work on this!

Change 475896 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Allow VE edits to be tagged based on '&campaign=...' URL parameter

https://gerrit.wikimedia.org/r/475896

@Pginer-WMF - This is ready to go now. All we have to do at this point is register the campaign via a config change so that e.g. https://en.wikipedia.org/wiki/Lion_taming?veaction=edit&campaign=toledo sets the corresponding revision tag. Should we go ahead and do that?

In T209132#4832140, @kaldari wrote:

@Pginer-WMF - This is ready to go now. All we have to do at this point is register the campaign via a config change so that e.g. https://en.wikipedia.org/wiki/Lion_taming?veaction=edit&campaign=toledo sets the corresponding revision tag. Should we go ahead and do that?

Great!
Regarding the specific name, given the more general scope of ExternalGuidance, I'd propose external-machine-translation for the name of the campaign and tag. With that change everything should be ok to go ahead with this.

@matmarex - Can you go ahead and register the campaign (external-machine-translation) per Pau's note above, and then schedule it for SWAT deployment in January?

I guess I can do it, although I’m a little uncomfortable suddenly becoming responsible for a mystery project I know next to nothing about.

@matmarex - Sent you some info on the project. Also, I forgot to mention that we only need to register the campaign for Indonesian Wikipedia (idwiki).

@kaldari does this mean that we'll need to manually turn on for other
languages when they become available? Just want to make sure, as this is
likely to come.

@atgo - Yes, we'll need to register the campaign for each language wiki as they become supported by the project. We can also register it for all wikis by adding it to the default config, but I wouldn't advise doing that until we have a significant number of languages coming online.

Thanks @kaldari. Will flag this to the project team.

(From the point of view of Editing team, this is done? Please file another task if you need to coordinate the project that needs this)

In T209132#4841157, @kaldari wrote:

@atgo - Yes, we'll need to register the campaign for each language wiki as they become supported by the project. We can also register it for all wikis by adding it to the default config, but I wouldn't advise doing that until we have a significant number of languages coming online.

I made a test for which the tag was not added (details in T216123). Content creation was happening in Indonesian Wikipedia (where the campaign is expected to be enabled), but the original article used for the translation was from Simple English Wikipedia (not sure if that makes a difference in terms of the campaign and tagging)

In T209132#4839006, @kaldari wrote:

@matmarex - Can you go ahead and register the campaign (external-machine-translation) per Pau's note above, and then schedule it for SWAT deployment in January?

I did some testing for the tag (T216123#5011052) and noticed that it was finally implemented for Visual Editor as "campaign-external-machine-translation" instead of the proposed "external-machine-translation" (which is what Content Translation uses for content created in the same circumstances).

I think it would be better for the tag to be the same across tools. Is there a reason for the "campaign-" prefix?

@chelsyx may need to be aware of the current situation of the content tags or any possible changes since this can affect the analytics she is working on.

In T209132#5015968, @Pginer-WMF wrote:

In T209132#4839006, @kaldari wrote:

I think it would be better for the tag to be the same across tools. Is there a reason for the "campaign-" prefix?

It seems that the "campaign-" prefix is used as part of a system, so we can keep it. We'll adopt the same approach in Content. So for the record, the campaign name for contributions originated from External Guidance is campaign-external-machine-translation

Sorry, I did not expect the prefix to be problematic, and I didn't know at the time what tags you were planning to use. I see in the other task that you've changed CX to match VE, so thank you for that. But for future uses of this feature, we could get rid of the prefix in VE if needed.

@chelsyx may need to be aware of the current situation of the content tags or any possible changes since this can affect the analytics she is working on.

Thank you @Pginer-WMF ! I just verified that the tags are logged correctly in the databases.