Open Bug 1264229 Opened 6 years ago Updated 4 years ago

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

Categories

(DevTools :: Memory, defect, P3)

defect

Tracking

(firefox48 wontfix, firefox49 affected, firefox50 affected, firefox51 affected)

Tracking Status
firefox48 --- wontfix
firefox49 --- affected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: magicp.jp, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

Attached image 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.
Has STR: --- → yes
Component: Untriaged → Developer Tools: Memory
OS: Unspecified → All
Hardware: Unspecified → All
The button is localizable, shouldn't RTL languages just override it?
Priority: -- → P3
(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.
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).
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 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.
Flags: needinfo?(ntim.bugs)
(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.
Flags: needinfo?(ntim.bugs)
(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.
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.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.