Closed Bug 650998 Opened 15 years ago Closed 15 years ago

Remove and/or l10n bookmark tags

Categories

(Cloud Services :: Share: Firefox Client, defect)

Product:
Cloud Services
Component:
Share: Firefox Client
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: clarkbw, Assigned: philikon)

References

Details

(Whiteboard: [has patch])

Attachments

(1 file)

implement (b) v1
1.99 KB, patch
mixedpuppy
: review+
Details | Diff | Splinter Review
For any strings that reference F1 or Mozilla F1 we should be changing to use "Share" or "Firefox Share". This bug will track those changes necessary in the Firefox client code.
The "F1" name does not appear anywhere the Firefox UI. The only place where it still exists is the bookmark tag. Right now we tag with "shared", "f1" and whatever the service name is. That's actually a small l10n disaster right there. The easy way out is to not tag at all or just tag it with the service name. In any other case, we need a l10n strategy involving localizers. On that note, we want to figure out what the l10n strategy for Share should be. This ended up being a clusterfuck in Sync which in some locales isn't translated (which I think is correct since it's a product name, see bug 596381 comment 11) and in some locales is translated. I should also point out that the prefs mockup in attachment 524721 [details] suggests the "Sharing" name for the pref pane. I think it makes sense there, I just wanted to point it out.
Some guidance on when to use "Firefox Share" vs. "Share" from Mayumi Matsuno: Generally, speaking in the browser UI using "Share" is fine since it's implied that it's part of Firefox however if there's a sign-up window then add I'd recommend using "Firefox Share". Also, if you end up using Firefox Share in the copy, the full name only needs to be mentioned once and then using "Share" for the rest of the time is fine i.e., "To use Firefox Share, click the "Share" icon and enter your username/password. To access Share after logging in,..." (Obviously not real copy but wanted to give an example). Let me know if you have specific examples you want to have reviewed.
Regarding attachment 524721 [details] it should be "Share" (versus "Sharing") with the new icon which is currently being developed.
Blocks: 651668
(In reply to comment #3) > Regarding attachment 524721 [details] it should be "Share" (versus "Sharing") Thanks, Mayumi. I have fixed my patch for bug 645802 accordingly. I believe the only remaining issue in the Firefox code are the "f1" and "shared" tags that we add to bookmarks. I think the "f1" tag can go away, should we keep the "shared" tag? If so, it needs to be translated! CCing Axel for the l10n, CCing Marco for the tagging.
Can we discuss the UX in .l10n? At least in German, "Share" is literally translated "Teilen", which is ambiguous with "chop into pieces". I didn't find any good term, and this might be cultural: There's no good word for "share with somebody and you and they will have something both". It's either "split" or "take". Maybe there's an alternate UX to achieve the same thing that doesn't use the "share" concept.
the name "share" was not meant to be literal and is not a brand name so it does not need a direct word-for-word translation. if there is a better way to convey the idea of friendly sharing, distributing, giving, or bestowing then that's fine. We trying to convey the concept of sharing with "Share".
I agree that the branding/l10n discussion should move to mozilla.dev.l10n. This bug is purely about the Firefox UI implementation, and there's only the tags left. Renaming the bug accordingly. Sensible solutions I could come up with: a) Don't tag at all. b) Just tag with the service name. No l10n needed. c) Get rid of the 'f1' tag, but keep the 'shared' tag (which needs to be l10n'ed) I'm leaning towards (b), but I don't care that much. Just need a decision!
Summary: change to using "Share" or "Firefox Share" → Remove and/or l10n bookmark tags
I vote C. With b would that mean that German users would see the word "Share", that seems really random and not that useful if I did't speak English.
My: No, b) would mean that things would be tagged w/ "gmail" or "twitter" or "facebook" (or "xing" in de-DE someday ;-). My only concern w/ b) is that people may not realize that it was auto-tagged. Unfortunately the only alternative I can come up with is to tag with "shared-twitter" or something, but the l10n there is likely horrendous. My vote is b, because until we provide a history mechanism, we're at least telling people where they may find a record of what they did with that link.
(In reply to comment #8) > I vote C. > With b would that mean that German users would see the word "Share", that seems > really random and not that useful if I did't speak English. Sorry, I should clarified what "service name" meant in (b). It would mean "twitter" or "facebook" or "gmail" etc.
Oh, in that case I think C as well since I think the service names are more explanatory than "Shared".
I meant, I vote B now(geesh)
Alex, I'd love to get your opinion on comment 7 I think (b) is a good option to start with and then we could develop that more in the future if we wanted to integrate more information into places.
>is literally translated "Teilen", which is ambiguous with "chop into pieces" Looks like we'll have to update the icon to a large knife then :) >Alex, I'd love to get your opinion on comment 7 >I think (b) is a good option to start with and then we could develop that more >in the future if we wanted to integrate more information into places. what if we included three tags: "shared" (localized by the community to match the semantic meaning) "twitter" (or any other service name, not localized) "@username" (the user name or email address used if sent directly, not localized) placing the username/email in a different tag is useful since, many shared items won't have this additional piece of information (if they were just put directly into a public feed). Also, we're going to want to have this information stored ahead of time if we later build meta-pages for people that you can navigate to in the location bar, that display all of the information that has been shared with and from them. The service name in a separate tag could additionally be used later if we detected that the user received a link through a particular service, but they didn't share it themselves.
(In reply to comment #14) > what if we included three tags: > > "shared" (localized by the community to match the semantic meaning) > "twitter" (or any other service name, not localized) > "@username" (the user name or email address used if sent directly, not > localized) So that'd be (c) with a twist (tag the DM username/email address as well) > placing the username/email in a different tag is useful since, many shared > items won't have this additional piece of information (if they were just put > directly into a public feed). Also, we're going to want to have this > information stored ahead of time if we later build meta-pages for people that > you can navigate to in the location bar, that display all of the information > that has been shared with and from them. I understand the value in storing this information ahead of time, long before we build a UI for this. I just fear that Places tags is the wrong hammer for this. To be honest, I'm not even sure bookmarks are the right hammer for keeping a sharing history. In fact, I'm pretty sure they're not. Given the large design-for-the-future burden Sync has had, I'd prefer we do not write code for anything that we actually can make use of right now.
I care less about how we choose to store this data and much more about that we start storing it from the very beginning. This will allow us to later create features that already work at time we launch them, and the user won't think "odd, I know I shared a lot of stuff with this person earlier, but it isn't listed," which is like some kind of strange ex post facto dataloss.
Very good points, but we're slowly drifting out of the scope for this bug (which is purely about fixing the current tag situation). Recording a sharing history feels like a separate feature that we'd probably want to carefully spec out (and in doing so, coordinate with the Places team). At this point I don't think it deserves to block the minimal Share feature landing.
(In reply to comment #14) > >Alex, I'd love to get your opinion on comment 7 > > >I think (b) is a good option to start with and then we could develop that more > >in the future if we wanted to integrate more information into places. > > what if we included three tags: > > "shared" (localized by the community to match the semantic meaning) > "twitter" (or any other service name, not localized) This looks good to me. > "@username" (the user name or email address used if sent directly, not > localized) > > placing the username/email in a different tag is useful since, many shared > items won't have this additional piece of information (if they were just put > directly into a public feed). Also, we're going to want to have this > information stored ahead of time if we later build meta-pages for people that > you can navigate to in the location bar, that display all of the information > that has been shared with and from them. I think this is a bit of a privacy problem and in certain instances could actually violate our terms of use. On the privacy level we'll be exposing who you share with and what you share with them while not giving people the controls they need to manage that. I'm sure you could imagine possible problems with a bunch of bookmarks tagged with your ex-girl/boy-friend's username. If we had ways to manage what gets saved then I think this could make a lot of sense. It's possible for us to (in the future) actually pull down the shares you've made with all the meta data of recipients for later interfaces. And the terms of service agreements could have privacy and data retention controls we may have to implement to allow this. I'm not sure the lawyers would be happy I was more specific in a public bug, feel free to email me directly if you'd like to get lawyered. :)
Attached patch implement (b) v1 — — Splinter Review
Here's a patch to implement (b) since that seems to be the consensus.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #528139 - Flags: review?(mixedpuppy)
Whiteboard: [has patch][needs review mixedpuppy]
Attachment #528139 - Flags: review?(mixedpuppy) → review+
Comment on attachment 528139 [details] [diff] [review] implement (b) v1 So far this only tags with "service" and not with l10n("shared"), is there another patch coming?
(In reply to comment #20) > So far this only tags with "service" and not with l10n("shared"), is there > another patch coming? This tags it with "twitter" or "facebook" or whatever data.service is (given to us by the web code). This is what option (b) entails, so there won't be another patch, unless you disagree with implementing option (b).
Whiteboard: [has patch][needs review mixedpuppy] → [has patch]
(In reply to comment #21) > This tags it with "twitter" or "facebook" or whatever data.service is (given to > us by the web code). This is what option (b) entails, so there won't be another > patch, unless you disagree with implementing option (b). Ok, I got confused. I thought Alex was asking that we go with (c). I'm ok with that even though I think (b) is fine as well.
(In reply to comment #22) > Ok, I got confused. I thought Alex was asking that we go with (c). Now *I'm* confused. I took your comment 18 as a response that Alex's suggestion won't work, so I assumed we'd go back to the previous consensus which as (b). Obviously (c) would work for me too, and I might as well round up a patch for it so y'all can land whichever one you prefer while I'm on PTO later.
IMHO, we shouldn't tag with l10n-dependent names, as those won't deal well with changing language. I'd make a l10n-dependent tag name depend on an RFE on places to have dynamically localizable tag names, i.e., you tag with an abstract name, which is localized at display time, not at tag time.
(In reply to comment #23) > (In reply to comment #22) > > Ok, I got confused. I thought Alex was asking that we go with (c). > > Now *I'm* confused. I took your comment 18 as a response that Alex's suggestion > won't work, so I assumed we'd go back to the previous consensus which as (b). Let me just clarify. I was objecting to including the recipient data as a tag because it has privacy implications I don't think we're ready yet to handle. Future designs could do this and possibly build the data from previous shares. I'm ok with l10n("shared") tag though I think it could be complicated (people might want options related to what language is used for the tag) and I'm not sure the gain is worth it. > Obviously (c) would work for me too, and I might as well round up a patch for > it so y'all can land whichever one you prefer while I'm on PTO later. (b) is fine for me as it's straightforward and simple; and it's already done. :) If we think (c) is better then I'm ok with that as well I'd just like to get faaborg's opinion since he originally suggested more. (In reply to comment #24) > IMHO, we shouldn't tag with l10n-dependent names, as those won't deal well with > changing language. > > I'd make a l10n-dependent tag name depend on an RFE on places to have > dynamically localizable tag names, i.e., you tag with an abstract name, which > is localized at display time, not at tag time. And this makes me feel we should just stick with (b); unless faaborg objects lets just stick with what we have.
>Let me just clarify. I was objecting to including the recipient data as a tag >because it has privacy implications I don't think we're ready yet to handle. I'm not sure what the privacy implications are, since the user's bookmarks are already considered to be private and protected data. If we can't store the shared recipients in places, then I would like us to store it somewhere else so that we can later use the data.
Alex, while I agree 100% that better UI around sharing history is a great goal to have, I also don't think we have time to really think through the right way to store and manage this history, let-alone design and implement a stable data model that will actually meet future needs. Given that, I think we should split that discussion and planning off into a new bug, and fix the immediately critical issue now. Does this make sense?
>I think we should split that discussion and planning off into a new bug yeah, a new bug is fine. >I also don't think we have time what's the overall timeline for sharing?
(In reply to comment #28) > >I think we should split that discussion and planning off into a new bug > > yeah, a new bug is fine. Filed bug 652738. > >I also don't think we have time > > what's the overall timeline for sharing? We're shooting for a minimal feature set for Firefox 6 (due to go on the Aurora channel on 2011-05-24).
Landed the (b) patch: https://hg.mozilla.org/users/pweitershausen_mozilla.com/fx-share/rev/0b89e51cab1c
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: