<div dir="ltr"><div>Thanks Dave for bringing it up.</div><div><br></div><div>This has been on my mind a lot lately as I'm trying to plan localization strategy for non-privileged content.</div><div><br></div><div>Fluent is slowly getting introduced into Firefox via Preferences first, but soon we'd like to start opening it up to other areas of code and non-privileged showed up on multiple occasions.</div><div><br></div><div>We know we want to provide very similar experience there to what we provide in privileged - same declarative API, same imperative API.<br></div><div><br></div><div>In the context of localization, there are three major questions:</div><div><br></div><div>1) Where do data come from (l10n resources)<br></div><div>2) Where does the parsing/formatting code live?<br></div><div>3) Where do additional data come from? (Intl APIs, regional preferences and settings etc.)<br></div><div><br></div><div>What I mean by this is that we first have to somehow fetch the localization resources (1). In case of Fluent we use asynchronous generator to get a lazily resolved iterator of fallbacks.</div><div><br></div><div>It works really well when Localization.jsm can directly call L10nRegistry.generateContexts. Things get a bit tricky when you want to do the same in non-privileged.</div><div><br></div><div>We can either move all the code to the non-privileged side and have special version of Localization.jsm and L10nRegistry.jsm that only fetches I/O from the privileged side over some postMessage, or try to reuse as much as possible of the privileged side and use the postMessage to call for particular l10n-ids and get formatted messages back.</div><div><br></div><div>The latter seems tempting, but carries cost - it means that for each non privileged document we need to maintain its localization context on the privileged side and make sure we destroy it when the document goes away.</div><div><br></div><div>We would love to ask for help in deciding what strategy to use here, and if there's an effort to unify the strategy around the priv/non-priv, to make localization part of it.</div><div><br></div><div><br></div><div><br></div><div>There's also another interesting question around localization and non-priv.</div><div><br></div><div>In Fluent, when we localize messages in the web context, we can only access the publicly available APIs (Intl.*) which have been designed to minimize fingerprinting and are by nature fairly limited.</div><div><br></div><div>When we localize Firefox UI, we have access to the same APIs on steroids (mozIntl.*) which can do additional tricks like looking into Operating System Regional Preferences Settings, or retrieving some other customizations.</div><div><br></div><div>When localizing non-privileged content, we can either send the request to the privileged side and format the message there using all the goodies, or format the message in the unprivileged context.</div><div><br></div><div>The user visible consequences are potentially significant. Lets say that someone turns on resistFingerprinting. It's pretty obvious why the person may expect that their timezone be set to UTC when they browse Web Content. But would they expect parts of Firefox UI to show up with UTC timezone?<br></div><div>Will they understand why Downloads UI uses different date/time formatting than Web Payments?</div><div><br></div><div>Is it ok that most of the Firefox UI will follow users preferred hour cycle to be 24h, but video controls or Web Authentication UI will use the default for their locale (12h) because it cannot access the privileged information?</div><div><br></div><div>If we add a special localization exposed information on the privileged side that uses AppConstants, or some other Gecko specific data, should this data be available for localization purposes on unprivileged side or not?<br></div><div><br></div><div>This part of the issue boils down to - do we expect the non-privileged to act like web content, or do we expect it to have limited privileges for security reasons, but still stay consistent UI wise with the privileged UI?</div><div><br></div><div>The decision here has some serious consequences on the first topic, and I'm not sure who should make the call here.</div><div><br></div><div>I have some draft of an API here: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1407418">https://bugzilla.mozilla.org/show_bug.cgi?id=1407418</a> - and would appreciate any and all feedback and help I can get to figure out the final design of this feature.</div><div><br></div><div>Thanks!</div><div>zb.<br></div></div>