I think tags are a nice addition and allow our users to discover the very functionality of tags which is explained nowhere. I showed that idea to dozens of current Nightly users and Mozilla employees over the last 4 months and they *all* liked the idea, you and marco are the first people that give me negative feedback on the idea of adding tags by default to our default bookmarks to make them more discoverable. After I put significant work on it, after the patch got a r+, after the patch landed...
I'm sorry, the scope is clearly not to break your work or make you feel frustrated, I'm honestly just trying to understand the reasoning behind the addition. While I knew we were changing defaults, I didn't know these bare details. I could even be wrong about the fact users using tags prefer having their own rather than ours, we'd need telemetry to be able to answer the question properly. And it's easy to remove them, so it may be ignorable. But you didn't solve the localization problem, that is a real bug. The added tags are english only and have no value in any other locale. Not many locales provide nightly translations, but some do.
Let's see what Francesco thinks about this
These days we only have a very small number of locales working on Nightly. One thing that I don't like is that these strings will bleed into aurora/beta/release, riding the trains, but it's a small number of strings, so I can live with that. I honestly didn't realize we were adding tags, given the audience and the tags used I don't think that we need to localize them: the only problematic one is 'issue', the rest are terms that should be familiar to the target of Nightly. To summarize, I don't think localization is a problem for this specific feature. Side question: are these added only to new profiles? Because I see them in a new profile, but not in my existing one. If that's the case, it doesn't sound like an invasive feature.
Thanks. At this point I guess we might take this as an "experiment" since it only affects Nightly population, and check feedback to figure out if it's working as intended (I suspect most won't even notice considering the tags usage in the wild). I won't insist on the removal.
Created attachment 8802038 [details] [diff] [review] patch If we're serious about promoting bookmark tagging, we need a proper plan, including how to measure success, and it probably shouldn't be limited to Nightly. We don't have anything close to a plan. As mentioned earlier, the idea of setting default tags is already flawed even for users who do tag bookmarks, because they will want to pick their own tags.
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Attachment #8802038 - Flags: review?(mak77)
Comment on attachment 8802038 [details] [diff] [review] patch One side I agree. On the other side, this has a so tiny impact and still goes towards the direction of making tags more known. It's not a plan, but it's still a tiny step towards that direction. We don't have a clear situation regarding tags, but I'm also getting pressure from the web-ext team to increase their support, so I have to assume we won't drop them shortly and we should rather fix them. It would be great to have a plan that is not just some words up in the air. I don't feel like I can take this decision lightly, I'm going to forward to Dolske who reviewed the original change, now he has more data for an informed decision at an architectural level.
Attachment #8802038 - Flags: review?(mak77) → review?(dolske)
Comment on attachment 8802038 [details] [diff] [review] patch Sorry, I didn't even notice the tags got added. I agree it would be an L10N issue, although since it's Nightly-only it's not too big of a deal. (I'd expect Nightly users to be used to getting untranslated strings as new things land, anyway.) Best to just remove them.
Attachment #8802038 - Flags: review?(dolske) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e3a51d041edd Remove tags from default Nightly bookmarks. r=dolske
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox52: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
I have reproduced this bug with Nightly 47.0a2 (2016-10-17) on Windows 10, 64 bit! The Bug's fix is now verified on Latest Beta 52.0b8 Build ID 20170220070057 User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 [bugday-20170222]
You need to log in before you can comment on or make changes to this bug.