Just wanted to add that I can reproduce this locally. My own dev instance only has a few Wikibase items/properties defined, and none of them have multi-language labels. So if I go to a file page and add &uselang=fr to the URL params, I get this:

I'm trying to imagine the full scenario here:

This sounds like a lot of conditions to account for :)

I think all the "queue" would have to keep track of is: all qualifying images (prominent/ above minimum size/ not nsfw/ etc): that:

• do not have structured data currently
• possess one or more "machine-aided depicts statements" (at or above a given confidence threshold, if that is factored in)
• have not had their machine-aided suggestions rejected by user action

@Ramsey-WMF if a user downvoted a suggestion on an image, and then someone "reverted" that downvote, I'd assume the image could go back into the queue with all of the original suggestions back in place – assuming no other structured data existed for it yet. We could treat it as if they had made an edit to Special:ConfirmDepicts/File:Foo.jpg. That would be in keeping with https://www.mediawiki.org/wiki/Everything_is_a_wiki_page.

Would we want to store the entire "Depicts: Dog" statement (P180: Q12345) at the DB level (as opposed to just the label/Q-number), in case this tool was ever re-purposed to work for other properties beyond Depicts?

Here's a current example of how the links message appears. Styling just follows the UI defaults. Clicking the "X" removes the message and saves the user's decision.

Looks like this has been merged – is this ticket good to close?

@PDrouin-WMF thanks – I'll add the notice bar in a separate patch.

There are two tasks here, and it may be good to separate them.

@Aklapper part of this issue has been resolved with the merger of this patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/512435. That took care of the problem where the entire Captions panel remained stuck on the left side when it should flip along with the text orientation (LTR or RTL).

Per our design/dev conversation today, I can take a stab at a "spike" patch to enable frameless tabs and see how it works on the file page. This could happen once work related to Other Statements is out of the way (so maybe in 1-2 weeks from now). If we are happy with how this works we could push to Beta or Test Commons and get some wider user feedback.

@Cparle and @matthiasmullie there are two stages to this process if I understand correctly – let me know if I'm really off the rails here.

I can look at this in the next couple of days, I'm poking around in Qualifier widget stuff anyway.

Ah, ok, thanks for the clarification.

Are we sure that we want an auto-suggest UI for the data type selection? I imagine that many users will not be familiar with the Wikibase data-types in advance – typing in an autocomplete widget might feel like taking a shot in the dark when they don't really know what they are looking for. Also, if there are only a small number of data types for them to choose between, being able to see all the available types in a dropdown menu may be useful. Will there eventually be lots and lots of options available here? Even if we supported every data type currently listed here, there are only 17 currently, which is still potentially within the limit of what someone could select from an options list.

Whoops, just saw that @Cparle has already created a ticket for this at T224461 – closing this in favor of that one.

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. This should mean that the patch is safe to merge.

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:

Do you mean the P# for depicts, or the Q# for the individual statements? I moved the depicts number over with its label in attempt to consolidate things and save space. They could also be stacked on top of one another, which I think was what you originally had in your mock-up.

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: