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

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[Théo Chevalier]

Attachment: 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

Comment 1

[Kevin Grandon :kgrandon]

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.

Comment 2

[Kevin Grandon :kgrandon]

Attachment: 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.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

[Kevin Grandon :kgrandon]

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.

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

[Kevin Grandon :kgrandon]

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.

Comment 7

[Kevin Grandon :kgrandon]

Master: https://github.com/mozilla-b2g/gaia/commit/78686e0467dda06e5dc43daf9b139823dd231cb1

Comment 8

[Théo Chevalier]

Verified fixed on latest 2.2

Comment 9

[Théo Chevalier]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

This made it on to master before the uplift.