Asa, Gavin, For a current snapshot of Persona... Here is what I just plunked down in #picl, compliments of ozten:
For what is currently supported in Persona Production: https://github.com/mozilla/browserid/blob/train-2013.07.17/config/l10n-prod.json For a more general look at Persona localization via the l10n community: https://localize.mozilla.org/projects/browserid/ James ----- Original Message ----- From: "Lloyd Hilaiel" <[email protected]> To: "Asa Dotzler" <[email protected]> Cc: "Mom Hilaiel" <[email protected]>, [email protected] Sent: Friday, August 16, 2013 1:43:01 PM Subject: Re: Implementation approaches for Create Account / Sign In We have extensive experience in leveraging the fantastic l10n community for Webby projects, persona included. Slight cost delta, but not a deciding factor imo . Lloyd Asa Dotzler <[email protected]> wrote: I'm concerned about client localization. I'm sure this has come up, but I didn't see it in my reading through this thread. How will our localization community, which I understand has a solid process for localizing Firefox features in XUL, deal with localizing HTML? - A On 8/9/2013 7:31 AM, Lloyd Hilaiel wrote: > Chris Karlof and I were talking yesterday, and I was noting how awesome the > implementation approach of Persona on FirefoxOS has been. The, the relevant > code that ships with the device is limited to a container capable of running > web content, and some setup code which invokes a function within the context > of that web content when necessary. Further, the navigator.id. apis are > intercepted by firefoxos, and cause raising of the "trusted" content window > and relaying parameters into it. > > All of the code inside the persona dialog is still loaded live from our > servers. > > This approach has saved us a number of times, and is the thing that allows us > to fix issues related to persona or roll out changes that land on all > firefoxos devices instantly. The other nice thing that this does is provide > a tiny contract between the firefoxos codebase and persona (both of which are > still very dynamic at the moment). > > So as I look at the UX mocks that we need to implement, I wonder why we > wouldn't use the same approach here? Namely, the "setting up sync" window > could be entirely implemented in HTML, and the only desktop client work would > be to raise a container. > > We could still get native key stretching by mapping a couple functions into > that environment, and the client could use them if available. > > Is there any really good reason not to explore this option? > > Gavin / Dolske, how would you guys react to this approach as a way to draw a > clear line between the client and the cloud and accelerate this thing? > > lloyd _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
