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:

The actual markup of the "English" labels here is:

<a title="Property:P3" href="/mediawiki/index.php?title=Property:P3" lang="en">color</a><sup class="wb-language-fallback-indicator">English</sup>

So really what we are seeing is an un-styled "language fallback indicator" that's getting returned from the API (specifically, it is included in the HTML returned from the formatProperty and formatValue methods of the new QualifierWidget). Currently we are dumping the markup and just keeping the plain-text version of the resulting label, which is why this looks so weird.

By making a small change in how we display information in the QualiferWidget, we can show the user this when there is no label available in the languages they have specified:

That's probably closer to the actual intention here. @Ramsey-WMF and @PDrouin-WMF any thoughts?

I thought that if a property or item has no label in a particular language, the P or Q number will show instead (and now that labels are linked). Is that not the case any more?

I think what we're seeing here is just default Wikibase behavior that we were not handling correctly. Showing P or Q numbers in place of labels when that fallback-indicator is detected should be possible here too.

On a related note, studying this issue has brought another bug to my attention – when the user adds new qualifiers to a statement and clicks "publish", the new qualifier is (at least sometimes) not shown until a full page reload has taken place. I'm pretty sure this was working last week so this may be some sort of regression. I'll open another ticket for this if I can reproduce the behavior consistently.

Looking at the source code on beta, it does look like we're just not handling the Wikibase fallback superscripts in multiple areas (it seems to be true for top level statement values and property names as well).

If the fallback code comes for "Free" though, I wonder if we'd prefer to move away from showing Q and P numbers and just use this functionality instead. There are pros and cons to that though:

• Pro: We avoid showing Q and P numbers (a sore spot, as you all know)
• Con: We'd need to show additional text (the fallback language) which messes things up a bit, especially on mobile. Alternatives to this con include a.) just showing the English word with no fallback language or b.) showing the word, with a fallback language, but only the two letter language code instead of the whole string (there's precedent for this)

For the short term, I'd say we should just enable whatever Wikibase is already doing to help in these kinds of situations.

Longer-term, it might make sense to override this with our own custom behavior if we decide on a different approach.

Upon further inspection, it seems we have the following situation:

• If we don't have an English label for the item in question AND we don't have a label in the user's language, the code doesn't give us a fallback and simply provides us with a Q number (see this in action here)
• If we have an English label but don't have a label in the user's non-English language (Spanish for instance), we get the fallback functionality with the superscripts and all that (as we see in the original link for this ticket).

So, essentially, the way it's working on production is the same as it is working on Beta, just different situations. Looks like we just need to make the fallback superscript stuff work for now and consider alternatives for a later date when we have more time/brain power.

@Ramsey-WMF I'll have a patch up to get superscripts working properly shortly.

Change 525174 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Handle additional markup returned by requests to wbformatvalue

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

Here's a current screenshot corresponding to that patch:

Change 525174 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Handle additional markup returned by requests to wbformatvalue

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

Did this actually make it to production? If so, it's not working.

This release is currently blocked mid-deployment (unfortunately due to another problem with how Wikibase and MediaInfo are interacting: https://phabricator.wikimedia.org/T229482). The update is live on beta however, so the original link at the top of this ticket should now demonstrate the correct behavior.

That ticket is here: https://phabricator.wikimedia.org/T229602