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.

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

(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.

(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.

(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.