A few tools for consideration in comparative review:

excellent catch 👍

Should no longer be an issue in our latest Talk implementation.

A couple of technical notes about the format of the URL that gets shared:

Based on the excellent notes in the google doc, as well as the blog post, I'll try to digest and reiterate all the specific APIs and other technical details for use in our implementation of image recommendations.
@kostajh Would you mind answering just a couple more minor questions (see inline below)?

In T318039#8359966, @scblr wrote:

@Dbrant which color group from the theme guidelines are we using?

@Sharvaniharan I've added the necessary new actions to the schema, and have wired up the Sharing feature branch to use it. Once the Exporting pull request is rebased onto the feature branch, you can hook into the updated funnel, as well.

In T318039#8358094, @JTannerWMF wrote:

@Dbrant Has @scblr weighed in on the color that was chosen to highlight where the edit here is? This orange follows OOUI?

In T316834#8352176, @scblr wrote:

@cooltey – I followed these instructions multiple times:
But didn’t get the popup that you get in the video.

In T306349#8340839, @kostajh wrote:

...for product purposes, it would be hard to use that to reproduce the existing filtered, curated list of results that we get by combining ElasticSearch hasrecommendation:image keyword alongside various other search filters

To answer a couple of questions:

The suggestions for files requiring captions are coming from a service. It looks like it's possible for the service to return a File that has since been renamed and turned into a redirect. We'll investigate either updating the service logic, or adding some logic to the app that will need to check explicitly whether the suggested File is a redirect.

Hi @Al12si,
It is true that the mobile site does not show editnotices. Please see T201595 for the corresponding task and conversation.

All issues related to keyboard input in the Wikitext editor should be fixed via T313223

Bringing this back to refine a bit further. There seems to be a lot of device-specific weirdness when trying to scroll programmatically to a location in an EditText.
The present solution is an improvement, but not a complete fix.

Here are some test cases that involve "write" operations on wikis and databases.
Note that not all of these test cases are actually done today as part of our routine testing. This is just a list of potential tests that could benefit from, or indeed might require, production access.

Tagging the appropriate team.
Also I should note that AFAIK the mobile-sections api is no longer supported/maintained, and should no longer be used. I would suggest switching to a more stable api, such as the Parsoid html output:
https://de.wiktionary.org/api/rest_v1/page/html/sch%C3%BCtten
https://de.wiktionary.org/api/rest_v1/page/mobile-html/sch%C3%BCtten

I can totally see how the idea of doing it this way raises an eyebrow, but like you say, this is a consequence of our project constraints.

@cooltey To clarify this task a bit:

@scblr Can this be closed as a duplicate of T296952?