Page MenuHomePhabricator

Force LTR for filenames
Closed, DeclinedPublic

Description

In RTL languages, the filename looks like this:

Screen Shot 2020-10-08 at 2.59.25 PM.png (77×444 px, 10 KB)

This is how it appears on the filepage, but not in the URL:

image.png (520×2 px, 123 KB)

We should force LTR for the filename to avoid confusion since the prefix and extension are always English.

Acceptance criteria:

  • Anywhere in the mediasearch UI where a filename appears, it is rendered LTR.

Event Timeline

With all due respect, I strongly oppose.

For better or worse, we have many files whose name (not extension, but name) is in an RTL language. Take, for instance, پرونده:ایوری در کنار سفره هفت سین.jpg (where "پرونده" is the localization of the "File" namespace), which is one of tens of thousands of such files (perhaps even more). With our current setup, the filename is show correctly:

Screen Shot 2020-10-08 at 7.34.14 PM.png (110×1 px, 22 KB)

But if we force an LTR display, this is what we get, where the "پرونده" prefix is incorrectly displayed right next to the file extension (".jpg")

Screen Shot 2020-10-08 at 7.33.58 PM.png (98×1 px, 22 KB)

You might say: well let's keep it RTL for files with an RTL name, but force it to be LTR for all other cases. But that introduces inconsistency while not gaining anything.

PS: If the idea is not general, but only for Commons and only when the user interface language is an LTR language (such as English) then maybe this is worth exploring further. But for RTL wikis (or even for LTR wikis, when the user selects an RTL interface language in their preferences) this can mess things up.

With all due respect, I strongly oppose.

For better or worse, we have many files whose name (not extension, but name) is in an RTL language. Take, for instance, پرونده:ایوری در کنار سفره هفت سین.jpg (where "پرونده" is the localization of the "File" namespace), which is one of tens of thousands of such files (perhaps even more). With our current setup, the filename is show correctly:

Screen Shot 2020-10-08 at 7.34.14 PM.png (110×1 px, 22 KB)

But if we force an LTR display, this is what we get, where the "پرونده" prefix is incorrectly displayed right next to the file extension (".jpg")

Screen Shot 2020-10-08 at 7.33.58 PM.png (98×1 px, 22 KB)

You might say: well let's keep it RTL for files with an RTL name, but force it to be LTR for all other cases. But that introduces inconsistency while not gaining anything.

PS: If the idea is not general, but only for Commons and only when the user interface language is an LTR language (such as English) then maybe this is worth exploring further. But for RTL wikis (or even for LTR wikis, when the user selects an RTL interface language in their preferences) this can mess things up.

Oh that's a great point, thank you, @Huji ; the reason I proposed a strong-LTR fix here is because in Commons I've never seen a translated prefix. I know that RTL wikis -- on wiki -- have translated namespaces, and so does hewiki (which is where I usually lurk) but I have never seen it on Commons and have (potentially naively?) assumed that Commons does not have that translation in place.

Is that assumption wrong? I'm not sure, are these files available like that on Commons?

In any case, I think that this complication is added to the fact that image names appear as page-titles which are considered "interface language" (don't get me going on that one :| ) so the bottom line is that the image title seems to consistently flip (the way we see it in the screenshot) if you use an RTL interface whether you're on the new search interface *or* looking at the commons file page name.

Given that fact and the translated-prefix @Huji is raising, I think it's probably better to leave this as-is. There's no great solution anyways, so it might as well be consistent with the rest of the wiki.

Commons is harder than other places because it's multilingual, so it's a bit more difficult to find the "common behavior" when there can be so many languages living together without RTL//LTR flippage.

... but it is consistent in its confusion. So... maybe the Structured Data Engineering team should save yourselves the headache and leave it as-is.

PS: If the idea is not general, but only for Commons and only when the user interface language is an LTR language (such as English) then maybe this is worth exploring further. But for RTL wikis (or even for LTR wikis, when the user selects an RTL interface language in their preferences) this can mess things up.

By the way, just to clarify, my understanding is that this interface is in Commons, and Commons only.

That said, wikis in general treat page title as interface (even though it's content...) so this looks consistent with the rest of the way these titles would render on Commons if you're on an rtl interface. I guess you can just stay consistent :)

Thanks very much for weighing in, @Huji and @Mooeypoo. Given this information I think it's best we decline this task and stick with the status quo on commons.