1264229 - [RTL] pop-view-button has wrong direction in RTL locales

Status: NEW

(DevTools :: Memory, defect, P3)

Description

[magicp]

Attachment: rtl-pop-view-button.png

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160412050029

Steps to reproduce:

1. Start Nightly with RTL locales (e.g. Arabic version)
2. Go to any sites (e.g. about:home)
3. Open DevTools > Memory
4. Switch view to "Aggregate"
5. Take snapshot
6. Click "⁂" in any row
7. Confirm pop-view-button


Actual results:

The arrow direction of pop-view-button is wrong.


Expected results:

Back arrow should be "→" in RTL locales.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

The button is localizable, shouldn't RTL languages just override it?

Comment 2

[magicp]

(In reply to Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] from comment #1)
> The button is localizable, shouldn't RTL languages just override it?

Hi Nick ! In case of RTL, the left arrow [←] is go forward. So pop-view-button should be the right arrow [→] as go back.

Comment 3

[Tim Nguyen :ntim]

The arrow is defined in the locale here: https://dxr.mozilla.org/mozilla-central/source/devtools/client/locales/en-US/memory.properties#61

That means it should be fixed for RTL languages (but not fixed with Force RTL enabled).

Comment 4

[Tim Nguyen :ntim]

RTL localizers can override the ← string, so if it's still an issue, it should be fixed at locale level, but not at devtools level I think.

Comment 5

[Tomer Cohen :tomer]

(In reply to Tim Nguyen :ntim from comment #4)
> RTL localizers can override the ← string, so if it's still an issue, it
> should be fixed at locale level, but not at devtools level I think.

In the Hebrew locale, this is exactly what we've done (thanks Itiel for spotting this issue), but I am not fan of l10n hacks. 
https://transvision.mozfr.org/string/?entity=devtools/client/memory.properties:toolbar.pop-view&repo=aurora

I see here two options: 
a. Add a comment for the entity in question, asking RTL locales to use the "→" instead of "←".
b. Get rid of this entity, and replace it with an image file.

I'd prefer having the seconds option, although it is a bit more difficult to implement. In the meantime, I'd suggest having the AR/FA/UR people to follow the workaround we have in HE. 


I'm adding affected localization communities to this bug, in an hope that they could land the workaround right away.

Comment 6

[Tim Nguyen :ntim]

(In reply to Tomer Cohen :tomer from comment #5)
> (In reply to Tim Nguyen :ntim from comment #4)
> > RTL localizers can override the ← string, so if it's still an issue, it
> > should be fixed at locale level, but not at devtools level I think.
> 
> In the Hebrew locale, this is exactly what we've done (thanks Itiel for
> spotting this issue), but I am not fan of l10n hacks. 
> https://transvision.mozfr.org/string/?entity=devtools/client/memory.
> properties:toolbar.pop-view&repo=aurora
> 
> I see here two options: 
> a. Add a comment for the entity in question, asking RTL locales to use the
> "→" instead of "←".
> b. Get rid of this entity, and replace it with an image file.
> 
> I'd prefer having the seconds option, although it is a bit more difficult to
> implement. In the meantime, I'd suggest having the AR/FA/UR people to follow
> the workaround we have in HE. 
Sounds good, we can hardcode the string "→" (as an image or text) and rotate it for RTL locales.

Comment 7

[Tim Nguyen :ntim]

(In reply to Tim Nguyen :ntim from comment #6)
> Sounds good, we can hardcode the string "→" (as an image or text) and rotate
> it for RTL locales.

Meant "←" of course.

Comment 8

[Tomer Cohen :tomer]

Recent Aurora builds introduced yet another arrow on devtools/client/debugger.properties (functionSearchSeparatorLabel). These strings are risky, so I suggest removing all of them and replacing with graphical equivalent that can be controlled easier using CSS.