Make the "first time" translation panel persist until 1st translation is complete
Categories
(Firefox :: Translations, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox139 | --- | fixed |
People
(Reporter: emilyw, Assigned: jasonjabarjones, Mentored)
References
(Blocks 1 open bug)
Details
(Keywords: good-first-bug)
Attachments
(3 files, 2 obsolete files)
Current state
Users see the "First time" version of the translation panel (with extra explanatory copy) just once. If they do nothing, the next time they encounter the translation panel they will see the "standard" version without the extra copy.
Enhancement
On the Android feature, we will be showing users the "First time/onboarding" view of the translation panel until they complete their first translation. The rationale is that it gives users more of a chance to view the value prop of translations. If they dismiss the panel initially without reading it, they will have another chance to see this later.
Once the user completes their first translation, we should then show the standard panel moving forward.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
This is gated on the "browser.translations.panelShown" pref.
The logic will need to be reworked to only change this pref after the first translation has been done:
There is some additional logic to show it on the page you are on, which can be removed.
There is probably a test as well that needs updating. You can run our test suite locally by running:
./mach mochitest toolkit/components/translations/tests browser/components/translations/tests
Or you could run it headlessly to avoid all the browser flashing.
./mach mochitest toolkit/components/translations/tests browser/components/translations/tests --headless
Updated•2 years ago
|
Kindly assign me this task . I am an Outreachy applicant and I wish to solve it.
Comment 4•2 years ago
|
||
Hello, welcome! Feel free to start working on the bug, we're assigning the bugs once a patch is attached.
Updated•2 years ago
|
Comment 8•2 years ago
•
|
||
Hi marifer,
Thank you for your patches!
One thing we do a bit differently here at Mozilla, compared to a flow that you may be more used to on GitHub, for example, is that each "commit" should effectively be a self-contained, functional change of code.
For example, if you are fixing an eslint error, you wouldn't add on a new commit for just that. You would make the changes and amend them into your single commit, and then re-publish that commit, almost as though you were force-pushing to GitHub.
The nice thing about Phabricator is that it keeps track of the changes between each "version" of the commit.
So what you should do is go into your WIP patches on Phabricator, scroll all the way to the bottom, and add an action in the dropdown to abandon that revision.
Next, locally, you'll want to pop your WIP commits off of your WIP stack and amend them (or use fixup, etc.) to then have a single commit.
At that point, you would use moz-phab to update the single revision.
Let me know if you have any questions, and thank you!
Updated•2 years ago
|
Updated•2 years ago
|
Hi Erik,
I wanted to drop you a quick note to say thanks for the explanation. It was super helpful and clarified a lot for me.
I have to admit, I was quite lost and got a bit tangled up in the process. In the end, it seemed like updating the changes after fixing the eslint error took me more time than all the steps from the initial setup to trying to squash that tricky bug. 😅
The good news is that everything looks updated on the revision now. If you could spare a moment to check it out when you have time, I'd really appreciate it. Your feedback is incredibly valuable to me.
Once again, thanks for your support and guidance.
Enjoy your evening/night!🌟
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 10•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee | ||
Comment 11•5 months ago
|
||
Assignee | ||
Comment 12•5 months ago
|
||
Hi Erik and Greg! I've submitted a WIP patch for this following the same general approach and comments discussed in D190531.
Test suite runs successfully:
./mach mochitest toolkit/components/translations/tests browser/components/translations/tests --headless
Are there any other tests to run or logic to be updated? I'm still a bit unfamiliar with the telemetry setup and want to ensure nothing was missed or broken.
Thanks!
Comment 13•5 months ago
|
||
Hi Jason,
Thank you so much for the WIP patch.
I pulled your patch down, ran the tests, and also tried it out locally.
Things look to be working correctly, so please go ahead and fully request review on your patch.
We can have follow-up discussions in the comments on Phabricator.
Updated•5 months ago
|
Updated•5 months ago
|
Assignee | ||
Updated•5 months ago
|
Comment 14•4 months ago
|
||
Assignee | ||
Comment 15•4 months ago
|
||
Thanks again for your guidance, Erik!
If another bug to remove browser.translations.panelShown
is on the table, I'll be happy to work on that as well.
Comment 16•4 months ago
|
||
bugherder |
Comment 17•4 months ago
|
||
Jason, we are celebrating the successful landing of your code over in the #Firefox Translations Matrix channel.
This is a feature that was requested by a community member, and then implemented by a community member. I think that's amazing.
Feel free to stop by and say hi if you would like.
Also, I will definitely be filing that follow-up bug, and it would be wonderful if you had the capacity to look into it.
Updated•4 months ago
|
Description
•