[Smart Collections] "Cancel" button is not localized.

VERIFIED FIXED in 2.1 S4 (12sep)


4 years ago
4 years ago


(Reporter: tchevalier, Assigned: kgrandon)



2.1 S4 (12sep)

Firefox Tracking Flags

(b2g-v2.0 ?, b2g-v2.1 fixed)


(Whiteboard: [systemsfe])


(2 attachments)

Created attachment 8481973 [details]
Screenshot Flame, 2.1

"Cancel" button not localized in Smart Collections.

Switch to Accented English
Connect to Internet
Add a SC
Open the SC
Long press on one of the icons

"Cancel" button is localized

"Cancel" button is not localized

Flame 2.1
Gaia      2be78d83a760fa3b9638fe51c266b442d14597f1
Gecko     https://hg.mozilla.org/mozilla-central/rev/1db35d2c9a2f
BuildID   20140831040205
Version   34.0a1
ro.build.date=Fri Jun 27 15:57:58 CST 2014

Comment 1

4 years ago
Seems we are running into a lot of problems with this button localization. I think we fixed it in bug 1045151, but appears to have regressed again.
See Also: → bug 1045151


4 years ago
Assignee: nobody → kgrandon
Target Milestone: --- → 2.1 S4 (12sep)

Comment 2

4 years ago
Created attachment 8481979 [details] [review]
Github pull request

We have the strings, we set the l10n-id, but we just don't include the strings in the HTML. Rather simple fix.
Wondering if we can improve discovery of that. In the multilocale mode, we report strings that are in the UI but are not present in the resource files.

We could do the same in the non-multilocale mode, just for en-US.

It would look sth like:

[/apps/settings/index.html: [l10n] [en-US]: 13 strings missing in the visible DOM: search, navigation, homescreens, fxa-accounts, findmydevice, screenLock, browserPrivacy, ums-confirm, is-warning-head, newSetting, is-warning-message, oldSetting, enable

The limitation is that it may create an illusion of safety because it cannot help with the strings requested from JS and not present in the resource files.

But it would cover this case.

Comment 4

4 years ago
If there were a way of detecting this stuff during runtime I think it would be awesome, I do think useful runtime detection of this stuff is pretty tricky though. It this goes back to what we were discussing over dev-gaia before about ways to automate this testing.
Well, it's not that hard. At runtime we know when the resource is not available and in if DEBUG is true [1] we do report it in the console log [2].

[1] https://github.com/l20n/l20n.js/blob/10c1855238251e6aac267f16fa0ba232aece1e3e/bindings/l20n/runtime.js#L11
[2] https://github.com/l20n/l20n.js/blob/10c1855238251e6aac267f16fa0ba232aece1e3e/bindings/l20n/runtime.js#L85

We did this because we didn't want to fire console.* at all in the production mode. But if developers are using some dev mode, we can bind it to switch DEBUG to on and then we'll report missing entities and missing resource files in the console.

Comment 6

4 years ago
Comment on attachment 8481979 [details] [review]
Github pull request

Fairly trivial patch that seems to fix the issue for me. Going to r=me this to save people's time on the review process.

Definitely looking forward to investigating some testing approaches for this with you guys in the future.
Attachment #8481979 - Flags: review+

Comment 7

4 years ago
Master: https://github.com/mozilla-b2g/gaia/commit/78686e0467dda06e5dc43daf9b139823dd231cb1
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [systemsfe]
Verified fixed on latest 2.2
Comment on attachment 8481979 [details] [review]
Github pull request

Nuking one English string on 2.1 and doesn't seem risky, I'd like to uplift this one.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): -/-
[User impact] if declined: English string displayed when long press on App in a Smart Collection
[Testing completed]: tested on device 2.2
[Risk to taking this patch] (and alternatives if risky): very low
[String changes made]: none
Attachment #8481979 - Flags: approval-gaia-v2.1?
Attachment #8481979 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
This made it on to master before the uplift.
status-b2g-v2.1: affected → fixed
You need to log in before you can comment on or make changes to this bug.