Bug to implement adding the localized Terms of Service and Privacy Notice to the fxa system app. The translated docs are here: https://github.com/mozilla/legal-docs/tree/master/firefox_cloud_services_PrivacyNotice https://github.com/mozilla/legal-docs/tree/master/firefox_cloud_services_ToS

Matej, what's the process for getting the localized TOS/PN files into Firefox OS correctly? I'm fine with manually creating the various locales files, but do we need to do anything for locales which don't yet have a translation? Also, do we need to somehow flag the TOS/PN so that localizers know to ignore them?

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #1) > Matej, what's the process for getting the localized TOS/PN files into > Firefox OS correctly? Unfortunately I'm not the right person to ask about that. I don't know anything about the technical side of things. Sorry. Not sure who to point you to, either. Maybe flod?

CCing a few folks from l10n + legal. The first thing to understand with legal (Mika) is if we're fine with localizers working on these strings. If we're not, don't expose the strings in .properties files for 2 reasons: * We can't land strings in their place, breaking tools and workflows, etc. * Once landed, we don't have control on what localizers do on those strings. I think the only way out here is to display an external file, not exposed to localizers, either local or remote, with external localizations provided by legal, and fallback to en-US if the translation is missing/not available. At the same time, we need to give our localizers some way to approve these translations and get them fixed. That's what we're doing for Fx OS Privacy terms, in the same Github repository listed above. If it's fine to have these strings localized by our volunteers, then just expose them in the .properties file.

(In reply to Francesco Lodolo [:flod] from comment #3) > If it's fine to have these strings localized by our volunteers, then just > expose them in the .properties file. Given the size of text to translate, I'd say please let them out of .properties files. I guess users need to have Internet access to use Fx Account in the first place, so let them land somewhere on mozilla.org to read the privacy/use terms, like we do on FTU.

(In reply to Francesco Lodolo [:flod] from comment #4) > > I guess users need to have Internet access to use Fx Account in the first > place, so let them land somewhere on mozilla.org to read the privacy/use > terms, like we do on FTU. Sounds great. I'll get the URL from the fxa-web folks. Thanks Francesco!

I filed a bug today to get the privacy notice onto www.mozilla.org/privacy so you should be able to get the URL from there. Bug is 999152. For the terms of service, I'm not sure where it will be - I'm guessing on the server for firefox accounts. Over the next few months we're working on creating a legal hub, similar to the privacy hub, where the legal docs will live and have dedicated URLs. The translations are done by a vendor, but just like with Firefox OS, we would like the community localizers to be able to review and approve the text. Thanks, Mika

(In reply to Francesco Lodolo [:flod] from comment #4) > (In reply to Francesco Lodolo [:flod] from comment #3) > > If it's fine to have these strings localized by our volunteers, then just > > expose them in the .properties file. > > Given the size of text to translate, I'd say please let them out of > .properties files. > > I guess users need to have Internet access to use Fx Account in the first > place, so let them land somewhere on mozilla.org to read the privacy/use > terms, like we do on FTU. Umm, that creates a workflow problem for App->Website->App transitions. Why can't we store that in .properties files and disable those files from being picked up by our l10n toolchain?

(In reply to Zbigniew Braniecki [:gandalf] from comment #7) > Umm, that creates a workflow problem for App->Website->App transitions. Isn't that already happening in FTU? Privacy, telemetry links. > Why can't we store that in .properties files and disable those files from > being picked up by our l10n toolchain? And where are you going to store the .properties file localized by vendors? Wouldn't that require a change in the build system too?

(In reply to Mika from comment #6) > I filed a bug today to get the privacy notice onto www.mozilla.org/privacy > so you should be able to get the URL from there. Bug is 999152. > > For the terms of service, I'm not sure where it will be - I'm guessing on > the server for firefox accounts. Over the next few months we're working on > creating a legal hub, similar to the privacy hub, where the legal docs will > live and have dedicated URLs. > > The translations are done by a vendor, but just like with Firefox OS, we > would like the community localizers to be able to review and approve the > text. > > Thanks, > Mika Awesome, thanks for the info, Mika.

(In reply to Francesco Lodolo [:flod] from comment #8) > (In reply to Zbigniew Braniecki [:gandalf] from comment #7) > > Umm, that creates a workflow problem for App->Website->App transitions. > > Isn't that already happening in FTU? Privacy, telemetry links. idk. But if it impacts the user experience, then I'd say it is bad. > > Why can't we store that in .properties files and disable those files from > > being picked up by our l10n toolchain? > > And where are you going to store the .properties file localized by vendors? > Wouldn't that require a change in the build system too? Yeah, possibly. Is that a blocker? One other option, we could just link to the l10n resources located on the server, but store the HTML on the device. That would allow us to serve the localizations directly from the vendor, bypassing the l10n storage. This would allow us to keep the in-app flow, which should be better for UX. Jared, how does it sound?

fxa-web has removed framebusting headers from their terms and privacy pages, so we should be able to open an inline iframe to close out this bug. just haven't gotten to implementing yet.

alive explained that I can use the EntrySheet to iframe the contents from within the fxa SystemDialog. Will try that in the morning.

Hi Alive, Yesterday you suggested I could use an EntrySheet to display an external page launched by a SystemDialog link click. I've gotten that working, but I can't figure out how to close the EntrySheet if the underlying app closes, for example, if the user hits the home button. (In my case, the Settings app opens the SystemDialog, then the SystemDialog opens the EntrySheet.) I've looked through the UIBase and SystemDialog code, but trying to subscribe to the FxA dialog's willdestroy signal didn't seem to work--now that I think about it, maybe because I was listening to the wrong window for the signal? I also couldn't figure out how to register the EntrySheet with the SystemDialogManager, and it wasn't clear that I should even be doing that outside the core windowing code. Any suggestions for how to make sure the EntrySheet closes if its opener closes? Thanks! Jared

Comment on attachment 8434579 [details] Github PR 20042 lol, took a 5 min break and realized I could just listen for visibilitychange. I'll clean up and resubmit in a moment.

Comment on attachment 8434579 [details] Github PR 20042 Hi again! OK, I've now gotten the EntrySheet displaying the terms/pp pages correctly, plus it dismisses itself when the parent app's visibility changes. Would you mind taking a look at the patch? Thanks very much, Jared

Thanks, Alive! Master: https://github.com/mozilla-b2g/gaia/commit/c0a5cc59d3a12ff2ce70f9b028c3a9468e58a555

Note that, until fxa deploys the required content-server change[1] to production, this might look broken. Don't panic, it works fine when pointed at the dev server :-) Once bug 1019118 lands, this should work correctly on device. [1] https://github.com/mozilla/fxa-content-server/pull/1170