812956 - Implement FFOS Privacy Policy

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect, P2)

Description

[Jishnu Menon :jishnu]

Bug to implement the FFOS privacy policy

Comment 1

[Jishnu Menon :jishnu]

Attachment: UI Mock for privacy policy

Comment 2

[Jishnu Menon :jishnu]

Proposed text for privacy policy:

Firefox OS is an operating system for your mobile device, made by Mozilla. Mozilla is an open organization dedicated to internet freedom. We've built Firefox OS with your privacy in mind.

+ When Firefox OS sends information to Mozilla, [our privacy policy] says how we handle that information.
====================================================================================

+ Firefox OS connects to others in order to provide Firefox OS updates and location services. 
===============================================================

++ Firefox OS automatically connects to your device's manufacturer to stay up to date.
-----------------------------------------------------------------------------------
     
+++ Mozilla will make available OS updates to the manufacturer of your device who will deliver updates to you. 
     
+++You can [disable update checking] under the Settings application.

++When you ask Firefox OS to tell an app or site your location, Firefox OS uses various services to determine where you are.
------------------------------------------------------------------------------------

+++Firefox OS uses multiple data points to estimate your location, including GPS satellites and other GPS service providers when you turn location services on. You can [edit your preferences] for location based services.

+ The device you are using, like most mobile devices, is created by multiple parties. This document only covers how Mozilla handles your information for Firefox OS.
============================================================================

++ For example, if you use third party Apps, their privacy policies will apply.
------------------------------------------------------------------------

++ For example, when you swipe left on the home screen, you are using the Everything.me service and its privacy policy applies.
------------------------------------------------------------------------------------

+++Everything.me is a third party who provides this service to you.  Everything.me has their own [privacy policy]. You can [reset your Everything.me ID].

+ You can get [help with Firefox OS] in our FAQs. [Link to SUMO with tages FFOS and 
Privacy]
===================================

+ Contact us with your privacy questions [link to or be a form]
====================================

Comment 3

[Peter Dolanjski [:pdol]]

I'm happy with the privacy policy mockup.  
Implementation of this is blocking basecamp.

Comment 4

[Gervase Markham [:gerv]]

Jishnu: comment 2 is not entirely clear to me. What do the ---, === and ++ represent? Is the implementer supposed to know what URLs to put in all these links? E.g. if this is the privacy policy, where does the "our privacy policy" link go?

Gerv

Comment 5

[Gervase Markham [:gerv]]

Comment on attachment 682978 [details]
UI Mock for privacy policy

Vivien: what are you asking for my feedback on? The styling is a question for our design team, not me. And the text in this mockup is not the same as that in comment 2, which I assume will be the actual text...

Gerv

Comment 6

[Josh Carpenter [:jcarpenter]]

cc'ing Dietrich for timeline awareness. Clee and I previously called this out as needing to land for C1, and we're past that deadline now. Need to establish a timetable for delivery.

Comment 7

[Josh Carpenter [:jcarpenter]]

<puts on UX hat>

Looks sexy, btw. Patryk are you on board with the look and feel here? Ideally we'd build this with our FxOS building blocks and styles, IMO.

Comment 8

[Patryk Adamczyk [:patryk] UX]

The attached mock up is from Firefox for Android. We need one from Firefox OS. Victoria is working on it.

Comment 9

[Alex Keybl [:akeybl]]

Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.

Comment 10

[Jishnu Menon :jishnu]

Hi Patryk and Victoria,

Do you think you'll be able to get us a mock this week? Just to be clear, top level content has double underlines.

Thanks
Jishnu

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Gervase Markham [:gerv] from comment #5)
> Comment on attachment 682978 [details]
> UI Mock for privacy policy
> 
> Vivien: what are you asking for my feedback on? The styling is a question
> for our design team, not me. And the text in this mockup is not the same as
> that in comment 2, which I assume will be the actual text...
> 
> Gerv

I thought you were the guy to ask for privacy policy!

On the design side I also have no idea what to do here? Also where is supposed to go this page, in the settings app? And if yes, where?
 
What are the missing links and where are they supposed to points to?

Clee? Victoria?

Comment 12

[Sergi]

Attachment: Privacy Policy - 320x480 version

Comment 13

[Sergi]

Attachment: Privacy Policy - Full Version

Comment 14

[Gervase Markham [:gerv]]

Not sure who is the right guy for privacy policy; it may well be Jishnu, who filed this bug, or it could be Tom or Alex.

Gerv

Comment 15

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Sergi from comment #13)
> Created attachment 685687 [details]
> Privacy Policy - Full Version

Thanks for the visual.

a few questions about the underline links (i assume those are links).
Where is supposed to bring:
 - our privacy policy (we are already policy no?)

 - disable update checking (there is no way to disable OS update checking right now. Apps update can be disable on a per-ap basis. Is is what you mean?)

 - edit your preferences. (Where does the privacy policy lives? If it is in the Settings App, is it an internal link to the root page?)

 - privacy policy. (Link to e.me policy? If yes, what url?)

 - reset your everything.me ID (First time I heard about a e.me ID...)

 - help with Firefox OS (Internal link to an other Settings section?)

 - Contact us with your privacy questions


Once those questions are answered it would be easier to implement this :)

Comment 16

[Borja Salguero [:borjasalguero]]

When I was talking with UX we agreed that there will be no links in FTU... Why? Because you could run FTU without Internet (no Data plan with your carrier, no Wifi available), and the user should be able to read this info (overall privacy policy and so forth). So IMHO (and as we agreed) we should have this info available in l10n strings, and show it properly in FTU App as we are doing now.

Comment 17

[Sergi]

What i've attached are some visual references for the privacy policy (PP) based on the copy provided in this same bug. I totally agree it makes no sense to place links here and/or interrupt the FTU with further navigation, but i assumed all the text in brackets where links so that's why i placed them in the visuals. My recommendation is to use plain text in PP and alike pages,  as well as don't let the user to further navigate or open new web views.

I think it would be also needed to treat this screen as a kind of "overlay" view that interrupts the main FTU flow. That means that, when the user clicks on the PP link while in the FTU, a new screen is displayed using an animation from bottom to top, When the "X" in the header is clicked the overlay screen goes away using the same animation in reverse (from top to bottom). We should not be using the "Activation Progress" component or any button. 

Anyway i'm not the IA who designed this, and maybe we'd need some feedback and/or a new copy without the links.

Comment 18

[Sergi]

@jmenon can you provide a new copy for the Privacy Policy without links so i can replace it on the reference visuals i created?

Comment 19

[Jishnu Menon :jishnu]

Hi Sergi,

So the policy is not going to live on the phone but rather on the web - can we do a call to discuss look and feel - it should approximate the mock I sent you?

Thanks
Jishnu

Comment 20

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Jishnu Menon from comment #19)
> Hi Sergi,
> 
> So the policy is not going to live on the phone but rather on the web - can
> we do a call to discuss look and feel - it should approximate the mock I
> sent you?
> 
> Thanks
> Jishnu

It will be complicated to go from the firstrun to the web directly. Please provide a local link. Also you still want people to be able to see the policy if people does not have configure internet on the First Run Experience, right?

Comment 21

[Jishnu Menon :jishnu]

Hi Vivien,

We're meeting with Clee on this early next week - update soon.

Thanks
Jishnu

Comment 22

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Jishnu Menon from comment #21)
> Hi Vivien,
> 
> We're meeting with Clee on this early next week - update soon.
> 
> Thanks
> Jishnu

That would be perfect! This bug is a C2 blocker. Which means it needs to be fixed before the 10th of December, so I would say if the definitive version of the text needed to solve this issue is not here by monday/tuesday it would be at risk for the C2 deadline. 

Thanks :)

Comment 23

[Sergi]

@Jishnu when you say it should approximate the mock you sent what do you mean? it should be visually similar or it should have the same information architecture? 

I think Privacy Policy should be consistent with the rest of the UI, so it should be using the components we have already designed. The screen you provided is really different in that terms. If you're talking about IA, of course we can design the info and group it so it looks similar to what you sent

I agree with Vivien that PP should live in the phone rather in the web, because the user may not have connection to the internet and the page should still be accessible. 

Regarding the addition of links, letting the user navigate from here may drive him to odd navigation scenarios, like trying to activate/deactivate components that have not been yet showed to him.

Comment 24

[Jishnu Menon :jishnu]

Hi Sergi and Vivian -

The FFOS PP is likely weeks away from being finalized because the product keeps morphing so Clee and I made a decision to have it live on the web for v1 launch. In an ideal world, we would agree with you and have it live on the device. Given this, how should we proceed?

Comment 25

[Jishnu Menon :jishnu]

Attachment: Interaction

Hi Sergi - your mocks look great. To note - the (+) are the top level navs, and it would be great if all the rest of the text was hidden under different layers (+ is top level, ++ one more down and +++ is lowest level). Here's a quick image with the interaction since I don't know the words to use

Comment 26

[Sergi]

> Here's a quick image with the interaction since I don't know the words to use

Thanks for the visual reference, Jishnu. It's really useful.  

We don't have any collapsable component at the moment, but let me check and find a solution for this.

Comment 27

[steve]

As was requested a while back. We just need the AI who worked on the FTE to decide exactly what the interaction within this privacy policy is. Because:
1/ I'm not sure it works well sitting in the FTE
2/ If it is in the FTE surely you do not want the user to go off on tangents while in the middle of the stepped process.
3/ If they do go off on tangents, surely the extra content should not sit on the web as the user won't have access yet.
4/ If the links are on the phone the AI needs to decide how that is accessed as we no longer have any drop downs in the the entire system because we changed to the use of value selectors throwing up overlays rather than drop downs.

So if the AI responsible could sort this out, that would be great. IS that Ayman or Rafa or other?

Once this is decided, Sergi can create all assets. Thanks guys, I think this is the best way to minimise rework.

Comment 28

[steve]

Or it may be Larissa or Josh

Comment 29

[ayman maat :maat]

Hey steve

I hear what your saying and yes this is the most efficient way to minimise rework. Larissa is responsible for the information architecture and UX of the Privacy Policy section of FTU. No one else had input/review, therefore i am going to pass this to Larissa a she has complete understanding of her design/UX intention and should be able to efficiently give you clarification.

Larissa could you please address Steve's questions in comment 27. 

Thanks

Comment 30

[Peter Dolanjski [:pdol]]

The key here, overall, is that we need to be able to pull the information from the web, as the policy will be in flux for some time, and we also don't want to break the workflow of the FTE (ie. taking the user off to load the browser).  This necessitates some component to retrieve and embed the policy webpage (http://mozilla.org/privacy/firefox-os/) as part of the FTE.  If the user does not have coverage, the best option is probably to display the url for them to be able to look up the policy elsewhere.
Without new feature work, what are our options to facilitate this?

Comment 31

[Fernando Campo (:fcampo)]

Well, the privacy screens are displayed after the 3g-data and wifi ones, so there might be a chance that the user have connectivity at that specific moment. If not, you can always ask the user to go back and set up a connection. If this is not happening, or the url is down for some reason, you could:
- display a static version (shouldn't we update the app as the text evolves in the web?)
- tell the user to visit Settings > Privacy later for specific details
- show the url to the web.

From this option, last one is the one I would most hate as an user, as it would make me write or memorize the url, then finishing the ftu, go and open the browser, type the url, and visit the web to read the document.

Comment 32

[Peter Dolanjski [:pdol]]

Larissa, in the case where the user is not online at the point of the privacy policy, what is your recommendation?

Comment 33

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

On the technical side we can use an <iframe> to point to the remote content if needed instead of moving to a different app (which we should not).

Comment 34

[Peter Dolanjski [:pdol]]

(In reply to Vivien Nicolas (:vingtetun) from comment #33)
> On the technical side we can use an <iframe> to point to the remote content
> if needed instead of moving to a different app (which we should not).

Great.  Once Larissa chimes in on the details (included expected offline functionality), please move forward with this approach.

Comment 35

[Larissa Co [:lco]]

Hi everyone,

tl;dr: Current design is the best we can do given v1 limitations. I recommend providing a message when no Wi-Fi is available, and removing URLs from the privacy policy, however.

I'm going to address the two big concerns that people have on this thread:

1. What happens when the user isn't connected to Wi-Fi during the First Run Experience?

Obviously, my preference is to keep as much content internal to the phone, for the reasons others have pointed out on the thread. But if Jishnu and Chris says this is not feasible for v1, then we need to find ways to live with an external URL for now. 

In the case of the Privacy Policy, I don't think an external URL is a large concern at all. Not many people are *actually* going to access the privacy policy from the FRE. (In fact, how many people are even going to read the privacy policy?) At the same time, we need to include the privacy policy for the small population that really does care about seeing it. The chance that a user who really cares doesn't get to see it because he's not connected to the Internet is probably very small.

We can also make the non-connected scenario more usable by displaying a custom message instead of a standard browser "not connected" one, as Peter mentioned. The message can be something like:

"You are currently not connected to the Internet. You can view the Firefox OS Privacy Policy by visiting the Privacy page in the Setting App or by going to <URL>."

Peter, I wouldn't worry so much about the user not remembering the URL because chances are, if they care about seeing it before they start using the phone, they will use another device to view it first.


2. Why are we taking the user out of the FRE flow?

The interaction is more nuanced than this. To be clear, people are not involuntarily being taken out of the phone set up flow and forced to read the privacy policy. The privacy policy comes up only when the user taps the link from the About Firefox screen in the FTE. Therefore, we are allowing users who have voluntarily elected to step out of the setup flow to get the information they want. The user understands this, and won't feel that we're misdirecting him.

Honestly, it's the same as setting up wi-fi or importing your FB contacts. Not every user will want to do those right when they set up their phone. But for the users who do want to do those things, we provide ways to let them do so.

It is imperative that we allow the user to get back to the setup flow from the privacy policy though. This is why I've argued that the URLs *cannot open in a browser frame*. They must open in what looks like a system panel with a close button (as Sergei already has in his design). Tapping the close button will bring the user back to the FTE screen he was on.

The implication of this is that we should really avoid links within the Privacy Policy text because there is no way to navigate forward and back within the window. Jishnu, if these are links that we can remove *for the FTE only*, can we do this? If we don't do so, we'll have to live with a design where the user cannot navigate within the Privacy Policy (unless you have your own page navigation system, which requires thinking) and only has the option to close the page.

Comment 36

[Jishnu Menon :jishnu]

I agree with Larissa with a few comments.

(In reply to Larissa Co from comment #35)
> Hi everyone,
> 
> tl;dr: Current design is the best we can do given v1 limitations. I
> recommend providing a message when no Wi-Fi is available, and removing URLs
> from the privacy policy, however.

We shouldn't remove URIs from the PP - it is a layered notice so a legal requirement to be able to click through. The floating iframe + cancel sounds good - it's important that users only need to delve deeper (not nav back and forth).

> 
> I'm going to address the two big concerns that people have on this thread:
> 
> 1. What happens when the user isn't connected to Wi-Fi during the First Run
> Experience?
> 
> Obviously, my preference is to keep as much content internal to the phone,
> for the reasons others have pointed out on the thread. But if Jishnu and
> Chris says this is not feasible for v1, then we need to find ways to live
> with an external URL for now. 
> 
> In the case of the Privacy Policy, I don't think an external URL is a large
> concern at all. Not many people are *actually* going to access the privacy
> policy from the FRE. (In fact, how many people are even going to read the
> privacy policy?) At the same time, we need to include the privacy policy for
> the small population that really does care about seeing it. The chance that
> a user who really cares doesn't get to see it because he's not connected to
> the Internet is probably very small.
> 
> We can also make the non-connected scenario more usable by displaying a
> custom message instead of a standard browser "not connected" one, as Peter
> mentioned. The message can be something like:
> 
> "You are currently not connected to the Internet. You can view the Firefox
> OS Privacy Policy by visiting the Privacy page in the Setting App or by
> going to <URL>."

This is a fantastic idea.

> 
> Peter, I wouldn't worry so much about the user not remembering the URL
> because chances are, if they care about seeing it before they start using
> the phone, they will use another device to view it first.
> 
> 
> 2. Why are we taking the user out of the FRE flow?
> 
> The interaction is more nuanced than this. To be clear, people are not
> involuntarily being taken out of the phone set up flow and forced to read
> the privacy policy. The privacy policy comes up only when the user taps the
> link from the About Firefox screen in the FTE. Therefore, we are allowing
> users who have voluntarily elected to step out of the setup flow to get the
> information they want. The user understands this, and won't feel that we're
> misdirecting him.
> 
> Honestly, it's the same as setting up wi-fi or importing your FB contacts.
> Not every user will want to do those right when they set up their phone. But
> for the users who do want to do those things, we provide ways to let them do
> so.
> 
> It is imperative that we allow the user to get back to the setup flow from
> the privacy policy though. This is why I've argued that the URLs *cannot
> open in a browser frame*. They must open in what looks like a system panel
> with a close button (as Sergei already has in his design). Tapping the close
> button will bring the user back to the FTE screen he was on.
> 
> The implication of this is that we should really avoid links within the
> Privacy Policy text because there is no way to navigate forward and back
> within the window. Jishnu, if these are links that we can remove *for the
> FTE only*, can we do this? If we don't do so, we'll have to live with a
> design where the user cannot navigate within the Privacy Policy (unless you
> have your own page navigation system, which requires thinking) and only has
> the option to close the page.

I think the user only needs to delve deeper - the notice will be layered. I've set up time for us to talk tomorrow morning and we can update the bug once we have talked.

Comment 37

[Jishnu Menon :jishnu]

Hi All,

Larissa and I touched base - she will upload new mocks. 

For the FFOS PP - it will live online like the other privacy policies linked from the phone. It should have the same look and feel as the other Mozilla privacy policies, which we are revamping to the sandstone look and feel. There are other privacy policies linked from the phone that will not be Mozilla's (page 9 - "Your Privacy" settings screen that is linked to from FTE), like TEF and E.me whose look and feel we do not control and do not want to control since they are independent entities with independent practices. The text is not complete, but Patryk, I'd love a mock with the sandstone look and feel (like the one I uploaded) if possible. I'll find someone on CMore's team to help with implementation. The URL for the FFOS PP from the "Your Privacy" page should be: https://www.mozilla.org/privacy/firefox-os/ or, with locale: https://www.mozilla.org/en-US/privacy/firefox-os/

Comment 38

[Larissa Co [:lco]]

The updated wireframes (v8) are here: http://people.mozilla.com/~lco/Legal_and_Privacy_B2G/ (refresh the page if you don't see the v8 document)

I had a long discussion with Jishnu, Alina, and Peter about the trade-offs here, and we generally agreed on a path for v1 (mostly Jishnu and Alina when Peter left, so don't blame Peter!).

To address concerns about users who are not connected to the Internet:
- All URLs are going to be short and spelled out for people (e.g. www.mozilla.org/privacy) so that the user has an alternative way of accessing them.
- I designed a prompt that will be displayed whenever the user clicks on a weblink and he's not connected to the Internet.

To address concerns about taking users away from the First Run Experience:
- Jishnu will provide revised text for the FFOS Privacy Practices in which he will remove any links that take the user to a Settings Page
- Even though the user can navigate to a weblink from another screen, the back button will always take him back to the First Run Experience (this is explained in more detail in my spec).

In addition, Jishnu would like the visual design to be similar to our web properties, not to Gaia. He's explained why this should be the case in comment 37, and the reasoning makes sense to me (even if my designer brain is a bit sad about it :p)

We settled on these compromises for v1 because we need these privacy policy links to be flexible enough to accommodate our partners' privacy policies, which will come with all manner of weird web links, revision requirement, and ugly UI. This v1 design makes the most of those challenges without providing an inconsistent user experience.

Comment 39

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Who is going to implement that?

Comment 40

[Jishnu Menon :jishnu]

Good question - there are implementation changes in the device as well as design work + implementation for the web PP. I'll ask for help with the web team for the online piece - Vivien, can you or your group implement the changes for the device per the mock?

Comment 41

[Julien Wajsberg [:julienw]]

Just to be clear, is this bug only about the First-Run-Experience, or is there also some work to be done in the Settings app ?

It seems that most of the work is already done in the Settings app (except maybe some URLs), maybe you should open specific bugs for what is missing in it.

Comment 42

[Chris Lee [:clee]]

Reviewing the updated UX spec, my understanding is that this impacts both the FRE and the Settings page.

IF the 'Your Policy' and the 'About Firefox OS' sections in the Settings app are implemented to spec, this should ideally just point to those areas within Settings while going through the FRE flow.  (I'm not sure how it was implemented in that manner or if we're actually building this in both places.)

David/Vivien -- who can work on this?  My feedback from the team is that this is necessary for ship and bb+.

Comment 43

[Julien Wajsberg [:julienw]]

clee> I'm currently working on the FRE part, should have a patch and (hopefully) land on Monday.

It seemed to me that the Settings part was either already done or planned in other bugs.

Comment 44

[Julien Wajsberg [:julienw]]

I'll need the various final URLs to Mozilla's website (FFOS telemetry and privacy policies). I'm externalizing them to l10n properties but because we need to change the key each time we change a value, i'd prefer having the final values now.


They'll also need to be without the X-Frame-Options header unlike most new Mozilla.org's pages.

Comment 45

[Julien Wajsberg [:julienw]]

Attachment: patch v1

You can try this patch using "git am <patch>".

There is a lot of information at the beginning of the patch as well.

Comment 46

[Julien Wajsberg [:julienw]]

Comment on attachment 690367 [details] [diff] [review]
patch v1

r? for l10n stuff

Comment 47

[Julien Wajsberg [:julienw]]

Comment on attachment 690367 [details] [diff] [review]
patch v1

r? kaze for the l10n.js change

Comment 48

[Fabien Cazenave [:kaze]]

Comment on attachment 690367 [details] [diff] [review]
patch v1

Review of attachment 690367 [details] [diff] [review]:
-----------------------------------------------------------------

r=me for the l10n.js part.

Comment 49

[Axel Hecht [:Pike]]

Comment on attachment 690367 [details] [diff] [review]
patch v1

Review of attachment 690367 [details] [diff] [review]:
-----------------------------------------------------------------

::: apps/communications/ftu/locales/ftu.en-US.properties
@@ +110,5 @@
> +learn-more-at = Learn more at
> +external-telemetry-text = www.mozilla.org/telemetry/
> +external-telemetry-title = Telemetry
> +learn-about-information = Learn how Mozilla handles your information at
> +external-privacy-text = www.mozilla.org/privacy/

Please don't put URLs into localized content. AFAICT, they're plain text, but legally bound to be the URLs we're linking to, so we should hard-code them, I think.

@@ +132,5 @@
> +privacy-b2g.title={{brandShortName}}
> +privacy-marketplace=Marketplace
> +privacy-marketplace.title={{privacy-marketplace}}
> +privacy-e-me=everything.me
> +privacy-e-me.title={{privacy-e-me}}

Both privacy-e-me and -marketplace should have comments to not translate either brand name.

@@ +172,5 @@
> +
> +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> +# Offline Error Dialog
> +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> +offline-dialog-title=This device must be connected to the Internet to view the page.

This sentence feels weird to me, get a copy review on that?

"This device" sounds like it's only this device that can't access the internet without access to the internet. Turn this into something actionable, or move that part into the dialog text?

Comment 50

[Julien Wajsberg [:julienw]]

Comment on attachment 690367 [details] [diff] [review]
patch v1

Review of attachment 690367 [details] [diff] [review]:
-----------------------------------------------------------------

::: apps/communications/ftu/locales/ftu.en-US.properties
@@ +110,5 @@
> +learn-more-at = Learn more at
> +external-telemetry-text = www.mozilla.org/telemetry/
> +external-telemetry-title = Telemetry
> +learn-about-information = Learn how Mozilla handles your information at
> +external-privacy-text = www.mozilla.org/privacy/

We can also localize the href, would this be better to you if we would localize both ? Actually we can already localize the href without any change in the code.

I don't know if we will have different URL for different locale. I don't know either if the final text will still be the URL as it was in the mock up.

What do you think ?

@@ +132,5 @@
> +privacy-b2g.title={{brandShortName}}
> +privacy-marketplace=Marketplace
> +privacy-marketplace.title={{privacy-marketplace}}
> +privacy-e-me=everything.me
> +privacy-e-me.title={{privacy-e-me}}

actually I wans't sure for the Marketplace.. are you sure we won't translate the Marketplace name ?

@@ +172,5 @@
> +
> +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> +# Offline Error Dialog
> +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> +offline-dialog-title=This device must be connected to the Internet to view the page.

i'm not a native english speaker, I used the exact words specified in http://people.mozilla.com/~lco/Legal_and_Privacy_B2G/Legal%20and%20Privacy%20wireframes%20v8.pdf page 9. Please propose a better sentence and I will implement it.

Comment 51

[Axel Hecht [:Pike]]

(In reply to Julien Wajsberg [:julienw] from comment #50)
> Comment on attachment 690367 [details] [diff] [review]
> patch v1
> 
> Review of attachment 690367 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: apps/communications/ftu/locales/ftu.en-US.properties
> @@ +110,5 @@
> > +learn-more-at = Learn more at
> > +external-telemetry-text = www.mozilla.org/telemetry/
> > +external-telemetry-title = Telemetry
> > +learn-about-information = Learn how Mozilla handles your information at
> > +external-privacy-text = www.mozilla.org/privacy/
> 
> We can also localize the href, would this be better to you if we would
> localize both ? Actually we can already localize the href without any change
> in the code.
> 
> I don't know if we will have different URL for different locale. I don't
> know either if the final text will still be the URL as it was in the mock up.
> 
> What do you think ?

Language negotiation for the linked content should be done server side, and we're pretty good at doing that on mozilla.org now. We shouldn't touch that, and use language-agnostic links in the product.

> @@ +132,5 @@
> > +privacy-b2g.title={{brandShortName}}
> > +privacy-marketplace=Marketplace
> > +privacy-marketplace.title={{privacy-marketplace}}
> > +privacy-e-me=everything.me
> > +privacy-e-me.title={{privacy-e-me}}
> 
> actually I wans't sure for the Marketplace.. are you sure we won't translate
> the Marketplace name ?

Yes, it's frowned upon. I was sooooo close to ask you to remove those, but I'm not sure if some languages might need some modifier on the link.

> @@ +172,5 @@
> > +
> > +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> > +# Offline Error Dialog
> > +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> > +offline-dialog-title=This device must be connected to the Internet to view the page.
> 
> i'm not a native english speaker, I used the exact words specified in
> http://people.mozilla.com/~lco/Legal_and_Privacy_B2G/
> Legal%20and%20Privacy%20wireframes%20v8.pdf page 9. Please propose a better
> sentence and I will implement it.

I'm not a native speaker myself, but Matej is. Matej, do you have comments on the following two strings in combination?

offline-dialog-title=This device must be connected to the Internet to view the page.
offline-dialog-text=You can also view this page from the settings app or by entering {{url}} in any browser.

Comment 52

[Matej Novak [:matej]]

(In reply to Axel Hecht [:Pike] from comment #51)
> (In reply to Julien Wajsberg [:julienw] from comment #50)

> > @@ +172,5 @@
> > > +
> > > +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> > > +# Offline Error Dialog
> > > +#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
> > > +offline-dialog-title=This device must be connected to the Internet to view the page.
> > 
> > i'm not a native english speaker, I used the exact words specified in
> > http://people.mozilla.com/~lco/Legal_and_Privacy_B2G/
> > Legal%20and%20Privacy%20wireframes%20v8.pdf page 9. Please propose a better
> > sentence and I will implement it.
> 
> I'm not a native speaker myself, but Matej is. Matej, do you have comments
> on the following two strings in combination?
> 
> offline-dialog-title=This device must be connected to the Internet to view
> the page.
> offline-dialog-text=You can also view this page from the settings app or by
> entering {{url}} in any browser.

Looks good. I just made a couple of small changes (I don't think we refer to it as the settings app in other places, but we do capitalize the names of apps).

offline-dialog-title=This device must be connected to the Internet to view the page.
offline-dialog-text=You can also view the page from Settings or by entering {{url}} in any browser.

Comment 53

[Julien Wajsberg [:julienw]]

What do you think of :

title : You must be connected to Internet to view the page.
text : Please go back and connect to internet, or you can also view the page later from Settings or by entering {{url}} in any browser.

Comment 54

[Julien Wajsberg [:julienw]]

Attachment: patch v2

please use |git am| to apply this patch.

Follow up to fcampo and pike's remarks.

Comment 55

[Matej Novak [:matej]]

(In reply to Julien Wajsberg [:julienw] from comment #53)
> What do you think of :
> 
> title : You must be connected to Internet to view the page.
> text : Please go back and connect to internet, or you can also view the page
> later from Settings or by entering {{url}} in any browser.

Slightly tweaked:

title : You must be connected to the Internet to view the page.
text : Please go back and connect to the Internet. You can also view the page later from Settings or by entering {{url}} in any browser.

Comment 56

[Julien Wajsberg [:julienw]]

Attachment: patch v3

follow up to Matej's comments.

Comment 57

[Axel Hecht [:Pike]]

Comment on attachment 690430 [details] [diff] [review]
patch v3

Review of attachment 690430 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, with a nit, please make the string in the html the same as in the .properties.

::: apps/communications/ftu/index.html
@@ +272,5 @@
> +           data-l10n-id='external-telemetry'
> +           href='http://www.mozilla.org/telemetry/'
> +           title='Telemetry'>
> +             www.mozilla.org/telemetry/
> +        </a>

The whitespace of "Learn more at " will be lost after l10n.js replace, but the whitespace inside the anchor will stay, so that's OK.

Trying to add trailing whitespace to the ftu.en-US.properties isn't going to work, really, as l10n.js treats the properties incompatibly, and you might get an escaped blank back from tools, which, AFAICT, l10n.js can't read.

Thus I think it's better to leave it like this. Also, you mentioned that on the phone, this is all sepearate lines anyway, so folks won't see it.

@@ +503,5 @@
> +      <h1 data-l10n-id='offline-dialog-title'>This device must be connected
> +        to the Internet to view the page.</h1>
> +      <p><small data-l10n-id='offline-dialog-text'>You can also view this
> +        page from the settings app or by entering
> +        {{url}} in any browser.</small></p>

This string doesn't match the one in .properties.

Comment 58

[David Scravaglieri [:scravag]]

Chris, Julien did the Gaia part, now we need privacy to move forward.

Comment 59

[Julien Wajsberg [:julienw]]

Attachment: final patch

carrying r=pike r=arcturus r=kaze

We'll need a follow up for the correct URL. We'll also need to understand how to properly use the l10n.js library to keep the spaces before nested elements.

Comment 60

[Julien Wajsberg [:julienw]]

https://github.com/mozilla-b2g/gaia/commit/57b9bb79f43bccd9ca2540a10d60bf0d9a7443f4

Comment 61

[Julien Wajsberg [:julienw]]

please open new bugs if anything is not correct per the spec, esp. in the settings.

Comment 62

[Jeni]

verified it on Unagi build 201301140703222

Comment 63

[Jishnu Menon :jishnu]

Hi All,

I just checked the FFOS build and the URL for the FFOS privacy policy appears to be wrong - it should resolve to: https://www.mozilla.org/en-US/privacy/firefox-os/. Can someone please make this change - I consider this a legal TEF+ request.

Thanks
Jishnu

Comment 64

[Jason Smith [:jsmith]]

(In reply to Jishnu Menon from comment #63)
> Hi All,
> 
> I just checked the FFOS build and the URL for the FFOS privacy policy
> appears to be wrong - it should resolve to:
> https://www.mozilla.org/en-US/privacy/firefox-os/. Can someone please make
> this change - I consider this a legal TEF+ request.
> 
> Thanks
> Jishnu

Can you file a followup bug and link it as a dependency on this bug? It helps with tracking blockers and followups to blockers.