The user research tells us that users are not totally clear on whether they need Firefox or not to click the Hello links. The current e-mail text says: ------------------------ Hello! Join me for a video conversation using Firefox Hello: You don't have to download or install anything. Just copy and paste this URL into your browser: https://hello.firefox.com/ufujrgQFEQM If you want, you can also learn more about Firefox Hello at https://www.firefox.com/hello/ Talk to you soon! ------------------------ Can we find a way to make it more obvious that despite the product name, this will work on any supported browser?

Matej, I NI you as I assume you're the person in charge of the copy here but feel free to redrect if I'm wrong!

I would suggest changing this line: "You don't have to download or install anything. Just copy and paste this URL into your browser:" To this: "You don't have to download or install anything. You don't even have to use Firefox. Just copy and paste this URL into your browser:" I think getting into any more detail opens up the question of which browsers are and aren't compatible. Does the above satisfy the request?

It does, thanks!

RT, Sevaan -- Is this ok for Fx38 or do you want to see it in Fx37?

If it's just a simple string change, let's just get it in there. There are currently no plans to redo the email as an HTML invite until we get over the technical challenges involved in passing HTML to a users email client. One suggestion, instead of "Just copy and paste this..." maybe we should add "Just click or copy and paste this..."

(In reply to Sevaan Franks [:sevaan] from comment #5) > If it's just a simple string change, let's just get it in there. There are > currently no plans to redo the email as an HTML invite until we get over the > technical challenges involved in passing HTML to a users email client. > > One suggestion, instead of "Just copy and paste this..." maybe we should add > "Just click or copy and paste this..." How about "Just click or paste this…"? I think "paste" already implies "copy."

Yeah, that's great. One more thought...should we simplify "URL" by calling it a "link"? "You don't have to download or install anything. You don't even have to use Firefox. Just click or paste this link into your browser:"

Clearing NI as marked as Fx37 item already.

(In reply to Sevaan Franks [:sevaan] from comment #7) > Yeah, that's great. > > One more thought...should we simplify "URL" by calling it a "link"? > > "You don't have to download or install anything. You don't even have to use > Firefox. Just click or paste this link into your browser:" Yes, you're probably right. Thanks.

OK so just to recap, the new e-mail body will be: ------------------------ Hello! Join me for a video conversation using Firefox Hello: You don't have to download or install anything. You don't even have to use Firefox. Just click or paste this link into your browser:: https://hello.firefox.com/ufujrgQFEQM If you want, you can also learn more about Firefox Hello at https://www.firefox.com/hello/ Talk to you soon! ------------------------

That looks right to me, just wondering if those links need all that leading information to work. It would look nicer if they could just be hello.firefox.com/ufujrgQFEQM and firefox.com/hello

Given that the text is passed through mailto and that afaiu mailto won't support href tags it seems we have to put the full link.

Arcadio can you OK this change in the e-mail invitation?

moving out to Fx38 as this wording is going to miss Fx37 uplift. emailing arcadio to get approval for 38.

Thanks for the NI. I think it would be good for the email recipient if we told them what Hello is? - Something like: Hello is the easiest way to connect by video with anyone anywhere. You don't have to download or install anything. I also worry about users on IE or Safari getting links and it not working for them. Should we say something like: - You don't even have to use Firefox. If you have Firefox, Opera or Chrome you're ready to start. [I cringe at suggesting putting Chrome on a Firefox email but the reality is that we need those "B" callers to make the connection successful. One little nit: do we need colons for a technical reason or tracking reason? - link into your browser:: <-- - Join me for a video conversation using Firefox Hello:<-- Also, it would be great to get this into 37 although it would be **ideal for 36** where we really start promoting Hello.

Thanks Arcadio, essentially my understanding of the text you want is: ------------------------ Hello! Join me for a video conversation using Firefox Hello. Hello is the easiest way to connect by video with anyone anywhere. You don't have to download or install anything, you don't even have to use Firefox. If you have Firefox, Opera or Chrome you're ready to start. Just click or paste this link into your browser: https://hello.firefox.com/ufujrgQFEQM If you want, you can also learn more about Firefox Hello at https://www.firefox.com/hello/ Talk to you soon! ----------------------- Matej is this fine with you? ------------------------(In reply to alainez from comment #15) > Thanks for the NI. > > I think it would be good for the email recipient if we told them what Hello > is? > - Something like: Hello is the easiest way to connect by video with anyone > anywhere. You don't have to download or install anything. > > I also worry about users on IE or Safari getting links and it not working > for them. Should we say something like: > - You don't even have to use Firefox. If you have Firefox, Opera or Chrome > you're ready to start. > [I cringe at suggesting putting Chrome on a Firefox email but the reality is > that we need those "B" callers to make the connection successful. > > One little nit: do we need colons for a technical reason or tracking reason? > - link into your browser:: <-- > - Join me for a video conversation using Firefox Hello:<-- > The "::" was a bad copy/paste from me, I'll let Matej comment whether we need ":" as part of "Just click or paste this link into your browser:" > Also, it would be great to get this into 37 although it would be **ideal for > 36** where we really start promoting Hello. This involves string changes so my understanding is that even Fx37 will be hard now that 37 is in Aurora. Shell is this correct?

If we're changing this copy more substantially, I'm going to add Troy, who has been working on the other components. Troy, please have a look at the copy at the top of comment 16. I just want to make sure it lines up with what we're using and saying elsewhere. I think you can also smooth out the two lines about browser compatibility. It would be good to consolidate that information so we don't have to repeat "Firefox" twice like that. Thanks.

(In reply to Matej Novak [:matej] from comment #17) How's this: ---------- Hello! Join me for a video conversation on Firefox Hello. It’s the easiest way to connect by video with anyone anywhere. With Hello, you don't have to download or install anything. Just click or paste this link into your Firefox, Opera or Chrome browser to join the conversation: https://hello.firefox.com/ufujrgQFEQM If you want, you can also learn more about Firefox Hello at https://www.firefox.com/hello/ Talk to you soon! ---------- I changed the opening line to be "on Fx Hello" instead of "using Fx Hello" — I think this might help clarify whether or not Firefox is required. I also moved "Hello" back a bit in the copy to avoid repeating it three times so closely together.

Thanks Troy, looking good to me. Arcadio is atht good with you too? Just noticing "With Hello" - do we need to say "With Firefox Hello" instead or is that fine?

Thanks, Romain. This looks good to me. I think starting the 2nd line in the 2nd para using "With Hello.." is OK because we follow the rule of first mention. We also have several Firefox : Hello tie-ins in the URLs and other places. Firefox Hello is also very visible in the subject line. WFM Thanks, Everyone.

Dan's feedback is that "If you want, you can also learn more about Firefox Hello at https://www.firefox.com/hello/" sounds weak and he suggested we instead use "Find out more about making easy video calls with Firefox Hello https://www.firefox.com/hello/". Arcadio do you OK that?

My flag is that it uses the word "call," which we're avoiding. Here's what I would say: "Find out more about starting free video conversations with Firefox Hello at https://www.firefox.com/hello/"

Thanks, updated the new version in the user story field

Hey Guys. So I thought the purpose of the email is to provide some background about what this link to someone who may not know about Hello and what it's used for. It's about instilling confidence to click that link that some one sent you. I think we did a good job of that with the "learn more" line. Dan's suggestion sounds too promotional and salesy for this medium. As someone who has never been exposed to the Hello message and this is my **first** touchpoint, I want to be reassured that what I'm about to do is safe and leads to something desirable - > a call with my friends. It might be small degrees but "Learn more" feels better to me that "Learn how to be a customer" As a suggestion and attempt to thread the needle, how about: Learn more about Firefox Hello and find out more about starting free video conversations at https://www.firefox.com/hello/

Hey everyone, I'm going to throw one more option into the mix, based on what Arcadio has. I think that direction feels right for this, I just wanted to try smoothing out a bit. CTA If you’d like to learn more about Hello and how you can start your own free video conversations, visit https://www.firefox.com/hello/

(In reply to Troy Palmer from comment #25) > Hey everyone, > > I'm going to throw one more option into the mix, based on what Arcadio has. > I think that direction feels right for this, I just wanted to try smoothing > out a bit. > > CTA > If you’d like to learn more about Hello and how you can start your own free > video conversations, visit https://www.firefox.com/hello/ Love this. Thanks, Troy. And great points, Arcadio.

cool. this works for me.

Shell...can you try to pull it into the current sprint? I think we're all set on our end here.

very belated reply to RT's question... sting changes that need to go into the desktop client at all - can only go into Fx38 (no uplift to 37). If this is on the Link Clicker side- it can go in as soon as ready and will be taken with the next localization.

Thanks all - updated US above based on Troy's Comment 25. This is desktop client so sounds like we have to wait until Fx38.

Comment on attachment 8554664 [details] [diff] [review] Change Loop email to clarify that other browser are compatible Review of attachment 8554664 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/locales/en-US/chrome/browser/loop/loop.properties @@ +5,5 @@ > # Panel Strings > > ## LOCALIZATION NOTE(clientShortname2): This should not be localized and > ## should remain "Firefox Hello" for all locales. > +clientShortname=Firefox We shouldn't use clientShortname because it was used previously and may still exist in a locale. Please use a new entity name for safety. I believe before it might have been clientShortname=Loop

jaws: how about browserShortname?

Yeah, that will be fine. I don't recall browserShortname being used by Loop before.

Comment on attachment 8554693 [details] [diff] [review] Change Loop email to clarify that other browser are compatible Review of attachment 8554693 [details] [diff] [review]: ----------------------------------------------------------------- Pike, what is your stance on the trailing slashes in the properties files? ::: browser/locales/en-US/chrome/browser/loop/loop.properties @@ +3,5 @@ > # file, You can obtain one at http://mozilla.org/MPL/2.0/. > > # Panel Strings > > ## LOCALIZATION NOTE(clientShortname2): This should not be localized and Please keep this localization note next to clientShortname2 @@ +46,3 @@ > ## LOCALIZATION NOTE (share_email_body4): In this item, don't translate the > ## part between {{..}} and leave the \r\n\r\n part alone > +share_email_body5=Hello!\r\n\r\nJoin me for a video conversation on \ I'm worried about localizers accidentally removing one of these trailing slashes and causing their properties files to go invalid. Perhaps we should just keep this all on one line.

Personally I'm not a big fan of multi-line strings in .properties file. Having said that, if a localizer removes one of the "\" by mistake it will generate an error in compare-locale, and it will be displayed in their locale dashboard. I think that external localization tools like Pootle will simply ignore the fact that a string is multiline http://mozilla.locamotion.org/cy/firefox/translate/browser/chrome/browser/loop/loop.properties.po#unit=7616862 But it also seems that these tools are not able to digest the \r\n part of this string http://hg.mozilla.org/releases/l10n/mozilla-aurora/cy/file/d31dcb9f223d/browser/chrome/browser/loop/loop.properties#l68 On the rest of the patch: do we actually need 2 extra strings for "Firefox" and "Hello"? Do we plan to use them elsewhere outside of the email text?

(In reply to Francesco Lodolo [:flod] from comment #37) > Personally I'm not a big fan of multi-line strings in .properties file. The advantage for developers is that they are less error-prone when handled with tools that wrap at 80 columns. > Having said that, if a localizer removes one of the "\" by mistake it will > generate an error in compare-locale, and it will be displayed in their > locale dashboard. > > I think that external localization tools like Pootle will simply ignore the > fact that a string is multiline > http://mozilla.locamotion.org/cy/firefox/translate/browser/chrome/browser/ > loop/loop.properties.po#unit=7616862 It's unclear to me what you mean by "ignore". My hope is that's going on with that link is that the tool is handling the backslashes correctly, since they are an implementation detail that localizers shouldn't have to really touch. > But it also seems that these tools are not able to digest the \r\n part of > this string > http://hg.mozilla.org/releases/l10n/mozilla-aurora/cy/file/d31dcb9f223d/ > browser/chrome/browser/loop/loop.properties#l68 These strings were there before this patch; I haven't edited those at all. If they were causing problems in the real world, I'd somewhat expect the localization process to already have been broken and noticed. Since this patch doesn't change that, I'd suggest spinning that off into another bug. > On the rest of the patch: do we actually need 2 extra strings for "Firefox" > and "Hello"? Do we plan to use them elsewhere outside of the email text? I _think_ you're asking if we should bother splitting them out for the main text of the email body. Not sure what the other UX plans are, I'd be ok with doing that until we have an actual need to split them out. Jaws, what do you think?

(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #38) > > On the rest of the patch: do we actually need 2 extra strings for "Firefox" > > and "Hello"? Do we plan to use them elsewhere outside of the email text? > > I _think_ you're asking if we should bother splitting them out for the main > text of the email body. Not sure what the other UX plans are, I'd be ok > with doing that until we have an actual need to split them out. Jaws, what > do you think? By which I meant, "I'd be ok with folding them back into the main text, if jaws is cool with that".

(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #38) > It's unclear to me what you mean by "ignore". My hope is that's going on > with that link is that the tool is handling the backslashes correctly, since > they are an implementation detail that localizers shouldn't have to really > touch. "Ignore" as in: localizers will see a normal string. It's correctly parsed by the tool – which is expected since it's part of the .properties format – exposed for localization, and then exported as a string on a single line. > These strings were there before this patch; I haven't edited those at all. > If they were causing problems in the real world, I'd somewhat expect the > localization process to already have been broken and noticed. > Since this patch doesn't change that, I'd suggest spinning that off into > another bug. That came as a surprise to me as well. I went to Pootle to check how it deals with multiline .properties, and found this. I'll file another bug and CC the tool's author.

(In reply to Francesco Lodolo [:flod] from comment #40) > "Ignore" as in: localizers will see a normal string. It's correctly parsed > by the tool – which is expected since it's part of the .properties format – > exposed for localization, and then exported as a string on a single line. Just to avoid confusion for someone else reading the bug: share_email_body4 is not currently multiline, legal_text_and_links3 is and it's correctly managed by Pootle. http://hg.mozilla.org/releases/l10n/mozilla-aurora/cy/file/d31dcb9f223d/browser/chrome/browser/loop/loop.properties#l262 Filed bug 1126171 for the other \r\n issue.

Comment on attachment 8554693 [details] [diff] [review] Change Loop email to clarify that other browser are compatible Review of attachment 8554693 [details] [diff] [review]: ----------------------------------------------------------------- I don't have much to add to what flod said. I'd prefer to keep the specifics of line endings of emails out of the l10n ecosystem, and format the code like foo = Hi\n\ \n\ I invite you to foo\n\ \n\ See you soon. And then normalize newlines to \r\n in the code. That's kinda easy to read and only somewhat awkward to edit for those folks localizing the source. Add a comment that \n to generate newlines in the actual string is important.

(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #39) > By which I meant, "I'd be ok with folding them back into the main text, if > jaws is cool with that". I'm not sure I understand the question here, but I would prefer to keep "Firefox" and "Hello" as separate strings in the properties file that are then replaced in the longer email body text. In prior conversations with Gavin I got the feeling that this is not, in practice, that big of an issue since we shouldn't spend large amounts of time worrying about what forks of Firefox may want to do (they could also update the strings like these in the locale files). I prefer pulling them out to separate strings because I feel that it promotes reusability and makes it easier for people who want to fork Firefox, but I also don't see the likelihood of us changing the name or people forking it to be that high.

Just a note: for standalone, I'd suggest using "brandShortname" as the string id for "Firefox" as this would match the equivalent for within desktop.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #43) > I'm not sure I understand the question here, but I would prefer to keep > "Firefox" and "Hello" as separate strings in the properties file that are > then replaced in the longer email body text. That's why we have branding http://hg.mozilla.org/mozilla-central/file/b2b10231606b/browser/branding/official/locales/en-US But I don't think you want this email to refer to "Nightly Hello", and that's why I didn't suggest to use brandShortname. Maybe we need strings in branding instead, but I have no idea if that would work for Hello helloBrandFullName=Firefox Hello helloBrandShortName=Hello

Yeah, we can use brand.dtd/brand.properties here, but elsewhere within loop (standalone), we can't access the brand locale files.

Jared, I'd like you to run through this once more to check if the changes I made are correct. Thanks!

Comment on attachment 8566571 [details] [diff] [review] Patch v2: change Loop email to clarify that other browser are compatible Review of attachment 8566571 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/components/loop/content/shared/js/utils.js @@ +154,2 @@ > learnMoreUrl: navigator.mozLoop.getLoopPref("learnMoreUrl") > + }).replace(/\n/g, "\r\n"), Localizers that fail to update from the old values that included \r\n will now get \r\r\n due to this regex. What do you think about doing the following (along with a comment): string.replace(/\r\n/g, "\n").replace(/\n/g, "\r\n"); This would convert any pre-existing \r\n to \n and then back to \r\n. Although, maybe it's OK to have \r\r\n here, because the effects are not going to be noticeable and they can be fixed by localizers. ::: browser/locales/en-US/chrome/browser/loop/loop.properties @@ +3,5 @@ > # file, You can obtain one at http://mozilla.org/MPL/2.0/. > > # Panel Strings > > +brandShortname=Firefox This came up in an earlier comment in the bug. Can you look at including the branding strings here so we don't need to duplicate this?

Pushed with the requested changes in comment 48 to fx-team: https://hg.mozilla.org/integration/fx-team/rev/9cb1667fd7f0

I was able to reproduce this issue on Firefox 38.0a1 (2015-01-23) using Windows 8.1 32-bit. Verified fixed on Firefox 40.0a1 (2015-04-02) and Firefox 39.0a2 (2015-04-02) using Windows 8.1 32-bit and Ubuntu 14.04 32bit.

I have also verified this issue on Firefox 38 Beta 1 (20150330154247) using Windows 8.1 32-bit and Ubuntu 14.04 32bit.