Created attachment 8481973 [details] Screenshot Flame, 2.1 "Cancel" button not localized in Smart Collections. STR: Switch to Accented English Connect to Internet Add a SC Open the SC Long press on one of the icons Expected: "Cancel" button is localized Actual: "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.version.incremental=110 ro.build.date=Fri Jun 27 15:57:58 CST 2014 B1TC00011230
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
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Target Milestone: --- → 2.1 S4 (12sep)
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.
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  we do report it in the console log .  https://github.com/l20n/l20n.js/blob/10c1855238251e6aac267f16fa0ba232aece1e3e/bindings/l20n/runtime.js#L11  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 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+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Verified fixed on latest 2.2
Status: RESOLVED → VERIFIED
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.