The Settings app contains a page titled 'Improve Firefox OS'. The title banner for this page does not display correctly. Instead of saying 'Improve Firefox OS', the title banner reads: 'Improve {{brandShort...' Repro Steps: 1) Updated Buri to Build ID: 20131213004002 2) Launch Settings App. 3) Navigate to 'Improve Firefox OS'. 4) Observe title banner. Actual: Title banner reads: 'Improve {{brandShort...' Expected: Title banner reads: 'Improve Firefox OS'. Environmental Variables Device: Buri v1.3 Moz RIL Build ID: 20131213004002 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/dfae9c83bfbc Gaia: 888f9df5515a47d2f5806efee77485e05e1e5416 Platform Version: 28.0a2 Firmware Version: V1.2_20131115 Notes: Repro frequency: 100% See attached screenshot, logcat.

Issue does not occur in 1.2 Environmental Variables Device: Buri v1.2 COM RIL Build ID: 20131213004002 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/a2b69b561d9b Gaia: 1aca7c4860e39b1a9969807d335dcf9f070ea9b3 Platform Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: V1.2_20131115

Regression Window: Last Working Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131211004003 Gaia: 7a2ccae2a546ac4d981d250272dafa630c926422 Gecko: 6bb84d0bc170 Version: 28.0a2 Base Image: V1.2_20131115 First Broken Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131212004003 Gaia: 588a3e02c4ace3b3341ba1f6bb7274120b53b2b3 Gecko: 031270be3702 Version: 28.0a2 Base Image: V1.2_20131115

Also in ### ENV: Gaia=59b89715c92d0383fb3d09941db93af5dfd05bc8 Gecko=http://hg.mozilla.org/mozilla-central/rev/0fdbcbffc79e BuildID=20131215040201 Version=29.0a1 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu=Nov=14=10:58:33=CST=2013

Triage: +'ing, label misplacement. EJ, could you help and see what's wrong here? Maybe we messed up the locale file or some issue with the build script?

ok I will take a look ! :)

It seems that this bug happens because of "double substitution". Mark dependency to bug 944749.

Not sure why this is blocking 1.3, considering the patch in bug 944749 landed only on master after 1.3 branch.

(In reply to Francesco Lodolo [:flod] from comment #7) > Not sure why this is blocking 1.3, considering the patch in bug 944749 > landed only on master after 1.3 branch. A closed and 1.3+ bug with patch will get automatically daily-ish. This regression will hit 1.3 too so we should keep both bug +'d. (Sorry for not closing that bug correctly. :-/)

s/automatically daily-ish/automatically uplifted daily-ish/

Hi Kaze, as @flod mentioned on bug 944749, is it possible to do duplicate substitution on l10n ? If not, I think the quick way to fix is to change the l10n-id with a new string. Just want to clarify the problem before doing the fix. Thanks

Hi EJ, I just remembered that l10n.js does not support double substitution on purpose, in order to avoid infinite loops like that: string1 = {{ string 2 }} string2 = {{ string 1 }} We could modify l10n.js to support substitution sequentially but not recursively, e.g. for this example: support-button = support {{ brandShortName }} support-header = {{ support }} it could work because `brandShortName' is already defined when `support-button' is set, and `support-button' is already defined when `support-header' is set. But in the following example would not work: support-header = {{ support }} support-button = support {{ brandShortName }} I’d think it would be worth the trouble implementing this behavior in l10n.js, but in the short term we can just modify the header string.

(In reply to Fabien Cazenave [:kaze] from comment #11) > Hi EJ, > > I just remembered that l10n.js does not support double substitution on > purpose, in order to avoid infinite loops like that: > > string1 = {{ string 2 }} > string2 = {{ string 1 }} > > We could modify l10n.js to support substitution sequentially but not > recursively, e.g. for this example: > > support-button = support {{ brandShortName }} > support-header = {{ support }} > > it could work because `brandShortName' is already defined when > `support-button' is set, and `support-button' is already defined when > `support-header' is set. But in the following example would not work: > > support-header = {{ support }} > support-button = support {{ brandShortName }} > > I’d think it would be worth the trouble implementing this behavior in > l10n.js, but in the short term we can just modify the header string. Ok, I will try to update with new id to fix this quickly. Thanks for your quick comments, Zac. :)

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #8) > A closed and 1.3+ bug with patch will get automatically daily-ish. This > regression will hit 1.3 too so we should keep both bug +'d. Ah sorry, I missed that the other bug received a 1.3+, was still waiting for approval in my head. Stealing this bug, since I'm the one who caused it in the first place.

:eragonj Not sure if you can/want to review the patch.

Thanks for you taking, Francesco. I am not peer / owner of Settings App so you may have to ask Arthur or Evelyn's help to review your code. By the way, they look nice to me. :P

Comment on attachment 8350528 [details] Remove double sostitution and change string ID Stealing the review while I’m still a Settings owner. :-)

Merged on master: https://github.com/mozilla-b2g/gaia/commit/b3baaadf40db67d8e5812de7a7bb0cdea26844b1

Thanks Kaze, you were the suggested reviewer with the longest queue, so I didn't want to nag you ;-)

I forgot Kaze can review Settings App too xD.

I was not able to uplift this bug to v1.3. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1.3, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1.3 git cherry-pick -x -m1 b3baaadf40db67d8e5812de7a7bb0cdea26844b1 <RESOLVE MERGE CONFLICTS> git commit

Imported patch. fixed conflicts in my fork on v1.3. Is this OK? https://github.com/flodolo/gaia/commit/1a5b5d779c5482124b4887cc40c7b853fcd4759a

(In reply to Francesco Lodolo [:flod] from comment #22) > Imported patch. fixed conflicts in my fork on v1.3. Is this OK? > https://github.com/flodolo/gaia/commit/ > 1a5b5d779c5482124b4887cc40c7b853fcd4759a This looks reasonable to me, provided that the resulting code works!

No problem about that, both this bug and bug 944749 just introduce new string entities for header to avoid reusing of strings in different contexts, I also compared the original diff with the new one to be sure.

[v1.3 5f71a97] Merge pull request #14884 from flodolo/bug950171