Page MenuHomePhabricator

Add image - image inspector flips filenames for RTL
Open, Needs TriagePublic


  1. On arwiki go to an article with add image suggestion.
  2. The image inspector will show the suggested image file name as RTL even though a filename is in LTR language.

e.g. the following file name File:Hubble Deep Field South full mosaic.jpg will be displayed flipped by the image inspector:

Screen Shot 2021-12-01 at 7.11.44 PM.png (1×818 px, 271 KB)

When the image details link is clicked - the file name displayed correctly:

Screen Shot 2021-12-01 at 7.13.08 PM.png (1×836 px, 283 KB)

Event Timeline

When the language of the description and the filename are in LTR language, I think the entire block should be left aligned (both in the inspector and in the image details dialog).

I'm not totally sure what to do for these instances though, where the label is in RTL and the content is LTR.

Screen Shot 2021-12-02 at 8.22.15 AM.png (446×474 px, 166 KB)

I'll let @RHo confirm.

tagging @Prtksxna due to his recent work on similar issues

tagging @Prtksxna due to his recent work on similar issues

Thanks @MRaishWMF! I think @Mooeypoo would be the best person to ask about mixed RTL/LTR content.

Looking at wikidata in ar as an example, I would have English and other LTR language content display left-aligned. IOW, I agree with @Etonkovidova's filing of this task in that the start of the filename and description should be displayed in the image inspector.

image.png (1×1 px, 181 KB)

Ah, localizing filenames on wiki, yes. One of the toughy questions, honestly.

There's a lot of issues when you try and figure out how filenames should be displayed when they're RTL/LTR. Notable, some of them are dependent on --

  • the file suffixes (.jpg / .png etc) are always latin
  • but the NAME of the file could be any language or a mix of languages
  • The "File:" prefix is a namespace, which is localized/aliased. <-- I think this is likely the culprit of *this* specific bug.

However, there's also (it seems like?) a clear RLT-fixed alignment in the second screenshot; if the file in that situation was ALL-ENGLISH then it would've also been presented the same way as the previous screenshot (self-align itself to be LTR) but since the context of that second screenshot is RTL, and the namespace is translated (meaning the 'filename' is mixed, and STARTS with RTL) the alignment is slightly different.

I can't even tell you which one is "correct", because it depends on the context. Also, once we figure out which one is "correct" this isn't the only place it's "acting up" in.

In this case, I'd try to check why there's no consistency -- whichever consistent state you'd pick (likely the translated namespace one, I imagine?) and I'd try to make sure both endpoints at least present the same state (translated or not) so they both render the same.

I am speaking a bit blindly here since I didn't have the chance to fully examine the components or code, but I wanted to make a point here about the inconsistencies - in general - of filenames on commons, especially when dealing with translated namespaces.