Chrome and FF seem to be somewhat smart about the date and are rendering it properly in RTL

This has confused me to no end while I was looking at it, since, honestly, the date *should* have been completely backwards if it's not translated and not surrounded by <bdi> tags.

Since you're pointing out that this works well in Chrome/FF but not in Safari, I suspect that (a) it probably isn't working as well in *older* versions of Chrome/FF, though I haven't tested that, and (b) that Chrome and FF have probably implemented some "magic" to auto recognize dates and force-fix those. I couldn't find an update to Unicode with this (this is simliar to the parentheses fix that matched end-parenthesis properly in RTL, but that fix started with a Unicode algorithm correction and only afterwards implemented in the browsers).

In this case, as you wrote, you should have the dates translated (I believe we've been using momentjs that does that automatically, though since it's being deprecated we may be switching to another library (?)) -- but I'd consider adding <bdi> regardless. The <bdi> tags will make sure the date renders properly (with and without timestamp) whether it's translated or not. Fortify, I say ;)

Change 637815 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Improve language support in QuickView panel

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

Change 637816 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Provide formatted, translated date in QuickView panel

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

Change 637815 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Improve language support in QuickView panel

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

Change 637816 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Provide formatted, translated date in QuickView panel

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

Checked in commons betalabs and commons wmf.20.
@AnneT - only one (and a quite minor, in my opinion) issue is still present (Safari displays time) - everything else looks good.
Please also review the issues under Notes - they are also minor. I was hesitant to file them separately since they are technically in the scope of this task. Let me know whether a separate task is needed.

In Safari, the date format is different, and the time is included and moved to the wrong side

It seems that the issue is present on Safari (iPhone also)- checked in commons betalbs and in 'commons wmf.20`.

	Chrome/FF	Safari 13/14
betalabs
commons wmf.20

Notes:
The following can be separated into a different phab task:
(1) The file https://commons.wikimedia.org/wiki/File:Munku-Sardyk_modified.jpg includes bullet points in the Author field that cause minor display issues in RTL; LTR accommodates additional formatting correctly:

(2) The File name - if a file name is LTR, the direction should be in LTR too? Interesting - Chrome/FF do flip File name, but Safari doesn't - that's why in the above screenshots the direction of the File field is correct.

LTR	RTL

Re your notes, in reverse order:

2. Yeah, this has no good answer and depends which of the edge cases you want to have, but since wiki, in general, treats titles as "interface" (ughh) rather than content, even in articles themselves, that means they are flipped in general -- so you are keeping this as the norm is on the wiki, even if it's arguably not great. At least it's consistent in it's "not greatness". :)

1. This is what I see in RTL:

Honestly, that's the best you can do, considering all users can add anything they want to anywhere they want, so it's hard to actually expect any content structure. I wouldn't align this right, and since this is English, I wouldn't RTL it. This display happens because you've correctly wrapped this with <bdi> tags, which is really the only reasonable thing you can do with a field that should generally be expected to be a username, rather than a rich rendered html/wikitext.

I wouldn't change this.

Change 646867 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Support dates with a space before time in Safari

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

Thanks for your response, @Mooeypoo.

Good catch on the Safari time bug @Etonkovidova; I've just pushed a patch to fix this!

Thx, @Mooeypoo for the review of my comments! I'll just check the fix for the dates display in Safari and run a quick check in production, then the task can be Resolved.

Change 646867 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Support dates with a space before time in Safari

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