Closing because we have T209621 to use for the job queue speed issue.

Adding James and Cormac for their expertise and elucidation :)

We're quickly approaching the point where we need this up on Beta because we're about to start doing dev on statements after testing file captions on Beta.

Confirmed. I've seen this bug earlier, but hadn't had time to record it happening. It happens on languages like Japanese too, where you can alternatively see the Japanese name of the language "日本語" and "Japanese" in English.

Assigning low priority since there are ways for the user to intuitively work around the problem. Still, it would be great to have this fixed :)

This particular bug seems to be fixed. Will create a new Epic based on the other issues mentioned above.

This is working now, but the speed of the job queue might be a problem. Could we hasten it a little bit? :)

Thanks @matthiasmullie , that was exactly what I was looking for. Closing.

No new namespaces on Beta.

Stick a fork in it. It's done.

Looks okay to me, although maybe the text could be a teeny bit lighter? Pinging @PDrouin-WMF for final sign-off.

Thanks for the update and additional points, @Jdforrester-WMF . For the question of the larger tasks and changes to search, I'm gonna ping @EBjune . Fodder for our usual meetup next Wednesday?

Updated bug notes:

@Cparle What's blocking this currently?

Is this still blocked with the current state of completion of Wikibase and MCR?

The GIF starts with the default text because I'd already added the text, viewed the history, and hit back before I started recording it :)

Added the caption in the same window. I just tried it again and it happened reliably. Try:

any thoughts on this, @MarkTraceur ? If Volker is right, the patch in question happened a couple years ago (before my time)

Since we still have a large concern about differences in configuration between beta and production, I think we should keep this as a potential warning sign until we know the exact reason it happens on labs. If someone can 100% guarantee that it's not going to be a problem on production, then I'll close it.

This is not critical now, but will need to be addressed soon. There is the question of how this should work because, unlike the keyword box, the depicts field is not plain text (it's for "tags" that point to Q items). Is it possible to trigger the Wikibase autosuggest when the user switches from Keyword to Depicts and there's text in the textbox?

Proper mobile design is not possible given how the items are rendered on the page right now, sadly. :-(

Tested multiple times and confirmed as fixed.

This is low priority for us now, so I'm fine with putting on the back burner. But I do think there's some room to find a design solution overall that looks better. This is the current situation on mobile and it just looks jarring at first glance.

Changing priority to reflect the need for this before we launch file captions on SDC.

The first security review is done and fixes implemented. Waiting for follow-up review, which is scheduled to be in by Nov 12th.

Uploads are working, future engineering work will be done on this but for now we're good.

Tested and confirmed as fixed.

Welp, spoke to soon. Just saw the same problem on a different box with a fully updated Chrome browser. Not a big deal at all, but it is apparently a real thing.

Yeah. Tested it in other browsers and it looks fine (although there are other problems) :)

I'm on Windows and Chrome. But my Chrome was several versions old on both computers (Version 69.0.3497.100). After the update things appear fine.

Additional note: this behavior seems to be inconsistent across files.

Update on this bug: it is more serious than simple display. It seems the language name is actually being prepended to the caption string.