On Thu, Nov 19, 2015 at 10:52 PM, Andrew Sutherland < [email protected]> wrote:
> On 11/19/2015 04:39 PM, [email protected] wrote: > >> 1) No l10n on back-end. All l10n on front-end[0]. >> [0] Exceptions may exist, they are rare. You case is probably not one of >> them. When in doubt, ni? me or stas :) >> > > What's the plan for this and service-workers? Specifically, background-y > APIs are all moving to targeting service workers, replacing our system > message mechanism that wakes up content pages directly. Specifically, it > seems like the push API (https://w3c.github.io/push-api/), background > sync API (https://wicg.github.io/BackgroundSync/spec/), and others are > intended to be processed in service workers and notifications generated ( > https://notifications.spec.whatwg.org/) without necessarily waking > up/creating a front-end/content page. > > It's not a problem right now for most of the special cases because we > always have to have a content-page around, but it seems like it will be an > architectural problem if we need to spin-up content pages once service > workers are more fleshed out and we start to move over to standardized APIs. > Thanks for bringing this up, Andrew. I don't have specific answers right now, but we've been thinking about this for a while now. We've also run into this problem in some capacity when migrating the Music app to NGA: the localized name of the current view comes from the view itself but needs to be shown in the container's gaia-header. In such scenario we need to send the localized string from the view to the container, because the container doesn't have the necessary strings to make do with an l10n id. There are two main reasons for preferring the l10n id approach over the 'send the translation and let the consumer code insert it into the DOM': - l10n/l20n.js is generally better at inserting things into the DOM: it knows how to handle localizable attributes and also supports some HTML in the translation in a secure manner, - by using the l10n-id we can make sure the element is re-translated automatically when the user changes the language. With system messages, the second benefit isn't very important: we'll usually want to just show the notification once and be done with it. It's still interesting to consider the question of the language in which the notification should be displayed. If we're sending the translation verbatim, we need to know the user's preferred language upfront, when the payload is created. As for the first benefit, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1228021 to explore an API that would allow us to apply a resolved translation value to an element, using the same logic that is used when the localization is done declaratively with data-l10n-id or with l10n.translateFragment. -stas
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
