Looks like this makes sense for the Translate extension, so I'm untagging CPT. Let us know if there's any issues with API integration.

The POST branch of PageTranslationSpecialPage::onActionMark() seems simple enough, but I assume a query API similar to showPage() will also be needed, and that looks a bit bigger. Unless it's enough to expect the client to guess the unit IDs for $noFuzzyUnits.

For API usability, I think an API request with action=markfortranslation & title=Foo should be equivalent to loading the form for that title and submitting it without changing any defaults. There's a couple of things in TranslatablePageMarker that make this inconvenient, like its need to overwrite the priority languages unconditionally. But it can be done.

For the nofuzzy checkboxes, the default is for them to be checked if only tvars were changed in that section. If the client passes an array of nofuzzy IDs, and we merge it with the defaults, then it won't be possible to uncheck a nofuzzy checkbox that was checked by default. We could override the array instead of merging it, in which case a client wishing to mark a section as nofuzzy would have to build its own defaults. Or the client could pass the changes it wishes to make in an associative format, with absent keys inheriting the default, like what we do for action=options.

Or there can be a nofuzzyunits parameter and a fuzzyunits parameter, the latter subtracting from the default set.

The primary reason I filed this was that I was thinking about writing a bot to automatically mark pages for translation when there are edits that got reverted, i.e. where the current source text is identical to the text that was most recently marked for translation, since those pages are still listed as waiting to have their changes marked for translation - either of the approaches work for me (not sure if other developers are going to use this api for anything) since the bot would just be doing the equivalent of submitting without changing the defaults

We need it for the community wishlist. The idea is to mark wishes for translation in a semi-automated way, with a gadget that runs as a translation admin (T365558). I don't think we need to override the defaults for the nofuzzy checkboxes.

Change #1052449 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/Translate@master] Add an API module to mark a page for translation

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

What about creating a first version that doesn’t allow overriding any defaults (no changes to fuzzy units, no changes to priority languages, no toggling of page title translation, no toggling of translation-aware transclusion, no syntax version updates)? If I understand correctly, neither Community Tech nor @DannyS712’s bot needs the ability to override anything.

For a feature-rich version, I think the REST API would be a better fit than the action API: you can GET the form defaults, and then POST (or PUT?) back the values you want.

In T235397#9959778, @Tacsipacsi wrote:

What about creating a first version that doesn’t allow overriding any defaults (no changes to fuzzy units, no changes to priority languages, no toggling of page title translation, no toggling of translation-aware transclusion, no syntax version updates)? If I understand correctly, neither Community Tech nor @DannyS712’s bot needs the ability to override anything.

It was easy enough to add the parameters. It was mostly done before you wrote your comment, per the gerritbot comment above. How about we just merge it and then move on to the next thing?

For a feature-rich version, I think the REST API would be a better fit than the action API: you can GET the form defaults, and then POST (or PUT?) back the values you want.

There's no framework for CRUD in our REST API, as far as I know. I don't think there's even a convention to follow. It's a blank slate.

In T235397#9964125, @tstarling wrote:

It was easy enough to add the parameters. It was mostly done before you wrote your comment, per the gerritbot comment above. How about we just merge it and then move on to the next thing?

When I wrote my comment, the patch handled none of the boolean parameters correctly (except for forcelatestsyntaxversion, which happened to have worked), causing inadvertent changes using the default parameters. It still doesn’t handle forcepriority 100% correctly (although the default parameters don’t cause inadvertent changes anymore): it’s required if one wants to change priority languages on a page that happens to force them, otherwise the forcing is removed; and priority languages are required if one wants to change the priority force status, otherwise the parameter is silently ignored.

I also don’t like the fuzzy unit handling: if a client does want to control the fuzzy status, it needs to get the default state somehow, determine the wanted state, and then compute the two arrays from these two inputs, compared to how the special page works – determine the wanted state and send that back. I don’t think the current implementation provides a good developer experience, and if it’s merged, it’s hard to back out of it, since it’s a stable interface.

There's no framework for CRUD in our REST API, as far as I know. I don't think there's even a convention to follow. It's a blank slate.

Wikibase does have a quite extensive REST API (Swagger docs), which uses the standard rest.php entry point and has CRUD operations differing only in the HTTP verb. So it’s doable and not even unprecedented.

Change #1052449 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Add an API module to mark a page for translation

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

Change #1056253 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/Translate@master] extension.json: add 'pagetranslation' to 'editpage' grant

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

Change #1056253 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] extension.json: add 'pagetranslation' to 'editpage' grant

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