Good question. We have some experience localizing web content, but maybe not for a feature so closely tied to the browser. Web content often ends up being handled by separate localization teams, with different processes. I think web localization has also often historically been treated as "less imporant" than in-product localization, with a higher tolerance for "en-US fallback", fewer resources dedicated by the localization teams, and fewer teams/locales participating.
So proper l10n in this setup is not impossible, but may indeed be harder. Gavin On Fri, Aug 16, 2013 at 12:46 PM, 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
