I think that there is something to be said for the visual tidiness of this approach, and that using a consistent placement of label elements might allow users to figure out what is going on here more quickly. I find this approach to be more intuitive, personally.

Here is a follow-up question about the layout of the Captions panel contents themselves, when both RTL and LTR languages are present.

Thanks @matthiasmullie for putting me on the right track. I was able to do exactly what you suggested to prepend the captions HTML to the rest of the tab1 contents, so that it comes before #mw-imagepage-content and #mw-parser-output. As far as I can tell, that solves the initial problem here – the Captions panel is now correctly oriented in an RTL page. Here's what it looks like in my local dev environment:

I'm willing to give that a try and see what the results are locally. Would pulling Captions out of the content block mean that it no longer gets included in the parser cache?

This is running in a local development environment on my machine. I just switched the language to Hebrew using the menu at the top of the page. But adding “uselang=he” to the URL creates the same results. Haven’t been looking at debug mode yet.

There is a lot I don't know about the way that Mediawiki handles RTL language mode. It seems like the first problem here – the fact that the Captions panel remains aligned to the left side of the screen, even when most other things align to the right – is visible even when Javascript is disabled:

Right now I'm just centering it horizontally and vertically on top of the form.

Hey @PDrouin-WMF: I spent some time poking around in UW yesterday. I'm afraid that the solution you proposed above (placing a spinner to the right as in previous steps) is not feasible for the "Add Data" screen. That's because this step can accommodate multiple files at once, in which case there is a "booklet" layout (you can click which image you want to add details to on the left-hand submenu, and the right-hand area is filled with information about that file).

I'm pretty sure that some of the recent mobile-related patches we have merged on master will fix this once we deploy a new release.

@PDrouin-WMF I can take a stab at this if using the already-existing spinner element is ok. Haven't done much in the UW codebase yet, this would be a good excuse to dig a bit deeper.

Ok, I've updated the patch to make footer behavior consistent between the panels. The footer buttons share a row when there is sufficient space, but stack otherwise. Here's what that looks like now:

Basic patch for this is up. Here's what the Captions panel looks like now at various sizes & states:

I think that this is doable with some flexbox tweaking, but the trash-can button will probably need to be appended to the .wbmi-entityview-caption div, as opposed to the child .wbmi-caption-value div as it is now. That would allow you to achieve this:

@Ramsey-WMF was able to grant increased privileges on Beta Commons to the fake user account we are using here, which gets around the Abuse Filter problem for testing logged-in edits. Anonymous edits will still be thwarted by that filter.

One additional issue here:

Update to the above – I've re-worked this patch to focus on testing against beta-commons; everything that would run in the normal CI process (tests in the Selenium "specs" folder, for instance), has been moved into a beta-commons-specific folder instead.

I'm trying to determine if this task is still blocked or not. Our attempts to get some Selenium tests working have faced a couple of problems, but several of them seem to have been fixed:

Oh – good catch! I think that was a side-effect of something else I did. I'll switch those back and update the patch.

Hey @PDrouin-WMF, how does this look – it's mostly what we talked about with some small adjustments:

Thanks for clarifying. I've added some info around this in the README for the related ticket at T221480, closing this one.

Here's a related question – what are the type requirements for valid qualifiers if the user is creating them locally?

Tangentially related to T221717

That works, thanks – I thought my problem was with the Entity types for some reason, not the type of the depicts Property.
Incidentally, the distinction between Property: type property (what I had defaulted to) and Property: type item is not very clear to me at all.

I think that this issue can be addressed as part of T221658 and T221228. The fact that the Captions panel separates the label (top of panel) from the cancel/publish controls (bottom of panel) means the layout functions better on small screens. On the Statement Panel, the panel label and the controls widget both exist in the top region of the panel, and on small screens they collide.

Looks like this is a CORS error: when I attempt to add statements in mobile view on production, I get this error in the JS console:

Ok, this should be a simple fix (just made one change from width to max-width in the CSS.
@PDrouin-WMF this is not on Labs/Beta yet (maybe someone can push there so you can verify), but here's a screenshot from my local instance:

This feature seems to be working correctly on both Beta and Test commons; moving to "Verify on Production".

It is my understanding that the text is always going to depend on the way the Wiki in question has been configured. I think this is the correct behavior, even if some sites have been configured to display text different than what we are expecting.

Even the brokenness is broken...

In my case the panel ended up in a frozen disabled state, where some captions had been submitted and others not – no error message or failed requests, just UI freeze: