My suspicion (unconfirmed) is that this happened when we shipped RC. Not sure how or why that would be the case though.

The listing is fixed in google play console now, the change might take a few hours to be visible on the play store.

Julien and I investigated the root cause. It turns out it's a bug in the original implementation (bug 1385401). The task that fetches strings[1] specifies: > "PACKAGE_NAME": "org.mozilla.firefox_beta" That should be "org.mozilla.firefox" on release. The kind.yml[2] is just wrong. I'm putting a patch up. [1] https://tools.taskcluster.net/groups/clifvnJKS6i8xMexCIAiIQ/tasks/PyDGYK_JSUKF_YZZUcrzIA/details [2] https://searchfox.org/mozilla-central/rev/588d8120aa11738657da93e09a03378bcd1ba8ec/taskcluster/ci/google-play-strings/kind.yml#39

AIUI after fixing this we'll end up with the right product description, and with the right whatsnew strings for dot releases, but with the wrong whatsnew strings for RC, unless stores_l10n updates its mapping beforehand?

(In reply to Julien Cristau [:jcristau] from comment #5) > AIUI after fixing this we'll end up with the right product description, and > with the right whatsnew strings for dot releases, but with the wrong > whatsnew strings for RC, unless stores_l10n updates its mapping beforehand? Does that mean that neither org.mozilla.firefox nor org.mozilla.firefox_beta contains both appropriate description + strings for publishing an RC? If so, it sounds like we may need some mozapkpublisher tweaks along with an in-tree patch.

Comment on attachment 8957564 [details] Bug 1444391 - google-play-strings: Use release strings on mozilla-release https://reviewboard.mozilla.org/r/226444/#review232598 Appoving this for follow-up RC respin during week-end.

Pushed by mtabara@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f27de9758107 google-play-strings: Use release strings on mozilla-release r=bhearsum,mtabara a=release

Comment on attachment 8957564 [details] Bug 1444391 - google-play-strings: Use release strings on mozilla-release https://hg.mozilla.org/integration/mozilla-inbound/rev/f27de9758107421b8a08d86f67f6a950280505b8 https://hg.mozilla.org/releases/mozilla-release/rev/534bbc15b9940ee0bdd25050e1b0d58fc78beb8b

(In reply to Ben Hearsum (:bhearsum) from comment #6) > (In reply to Julien Cristau [:jcristau] from comment #5) > > AIUI after fixing this we'll end up with the right product description, and > > with the right whatsnew strings for dot releases, but with the wrong > > whatsnew strings for RC, unless stores_l10n updates its mapping beforehand? > > Does that mean that neither org.mozilla.firefox nor org.mozilla.firefox_beta > contains both appropriate description + strings for publishing an RC? If so, > it sounds like we may need some mozapkpublisher tweaks along with an in-tree > patch. Landing this in-tree in the hope that we can tweak the mozapkpublisher stuff on Monday before we run the ship-rc phase.

Reopening this, we still need to conclude the conversation and potentially address some mozapkpublisher related changes.

(In reply to Ben Hearsum (:bhearsum) from comment #6) > Does that mean that neither org.mozilla.firefox nor org.mozilla.firefox_beta > contains both appropriate description + strings for publishing an RC? That is correct. Strings are fetched from locations like [1], which is updated by the L10n team. As you can see at [1], the what's new" section lives alongside the APK title. Before the 59 RC shipped, the right what's new section was attached to the beta channel, but the title is wrong there (hence, the bug). > If so, it sounds like we may need some mozapkpublisher tweaks along with an in-tree > patch. In my opinion, a workaround can live in mozapkpublisher, but the real fix should be on the stores_l10n side. More precisely, the what's new section should not mapped to a channel anymore, but to a version number instead. More specifically, I'd suggest: * links like [1] gives titles and descriptions, * and let's create a new type of link (https://l10n.mozilla-community.org/stores_l10n/api/v1/fx_android/translation/59/en-GB/), where we can get the right what's new section. That way, we don't have to bump beta to release, except if we want to redefine our description, just like we did in Firefox 57 (if I remember correctly). For reference, Google Play attaches the "what's new" strings to each APK[2]. How does that sound to you, :flod? [1] https://l10n.mozilla-community.org/stores_l10n/api/v1/fx_android/translation/release/en-GB/ [2] https://github.com/mozilla-releng/mozapkpublisher/blob/9b6e1e11f49afe154d446b9303006197946d8617/mozapkpublisher/common/googleplay.py#L139 see that you need to provide the "APK version code", which must be unique to each APK.

> In my opinion, a workaround can live in mozapkpublisher, but the real fix > should be on the stores_l10n side. More precisely, the what's new section > should not mapped to a channel anymore, but to a version number instead. > More specifically, I'd suggest: > * links like [1] gives titles and descriptions, > * and let's create a new type of link > (https://l10n.mozilla-community.org/stores_l10n/api/v1/fx_android/ > translation/59/en-GB/), where we can get the right what's new section. > > That way, we don't have to bump beta to release, except if we want to > redefine our description, just like we did in Firefox 57 (if I remember > correctly). For reference, Google Play attaches the "what's new" strings to > each APK[2]. This seems reasonable, but I haven't looked at the code yet, and I'm not sure I can commit to a timeline given the amount of projects depending on me (i.e. be ready for 60 RC). Worst case scenario, we can do the switch on stores_l10n at the last minute if a patch is not ready by next RC. Can you confirm that the request is only about separating "What's new" content from the main description in the API call, and mapping it to a release number + new API call? I assume this bug (wrong app's title) would be solved on releng's side?

(In reply to Francesco Lodolo [:flod] from comment #15) > This seems reasonable, but I haven't looked at the code yet, and I'm not > sure I can commit to a timeline given the amount of projects depending on me > (i.e. be ready for 60 RC). Worst case scenario, we can do the switch on > stores_l10n at the last minute if a patch is not ready by next RC. Sounds good to me. > Can you confirm that the request is only about separating "What's new" > content from the main description in the API call, and mapping it to a > release number + new API call? That's right! I filed https://github.com/mozilla-l10n/stores_l10n/issues/160 to track this. > I assume this bug (wrong app's title) would be solved on releng's side? Yeah this bug is now fixed on the releng side.

Tested with Samsung Galaxy Tab S3 (Android 7.0) and Google Pixel (Android 8.1.0) and I can confirm that the name is changed in Play Store: https://i.imgur.com/CA3gRER.png. Note: the build installed is 58.0.2.

Thanks for the verification, Sorina! I confirm the web interface also shows the right title: https://play.google.com/store/apps/details?id=org.mozilla.firefox&hl=en-US Marking this bug as verified.