[Go Faster] updating and localizing system add-ons
chofmann at mozilla.com
Wed Sep 2 23:28:54 UTC 2015
On Wed, Sep 2, 2015 at 3:53 PM, Robert Helmer <rhelmer at mozilla.com> wrote:
> I've changed the subject line since we're not really talking about the
> challenges of moving Hello to an add-on anymore (those have been
> More below.
> On Tue, Sep 1, 2015 at 9:33 AM, Mike Connor <mconnor at mozilla.com> wrote:
> > We've done locale-limited features in the recent past ("Flare" search UI
> > rolled by locale through 34/35/36), via a locale-driven pref. There's
> > absearch, which could be trivially extended/duplicated to roll out other
> > settings by language/region/etc.
> > In an ideal world, system add-ons will be able to embed some sort of
> flag to
> > indicate locale/region compatibility, and Firefox will determine whether
> > load the add-on at all based on that flag. If the add-on strings get
> > updated, we push a new update, Firefox sees that the locale is now
> > supported, and we can then load for those users. We could supplement
> > an absearch-like microservice if we want to do a phased rollout. (And I
> > think we'll want to be able to do a non-binary rollout of potential new
> > features.)
> System add-ons update info comes in as a set (according to the PRD and
> patches under review). Current discussions are leaning toward this set
> coming from the update service. We could customize the set on the
> server side according to product/version/locale if necessary just like
> we can for MAR updates - I think we want to avoid dealing with a
> combinatorial explosion here so we probably don't want to use this
> capability normally, but it's available.
> Add-ons can certainly check the locale and gracefully degrade features
> if desired - I think if we want to make such fine-grained decisions
> then the add-on itself is probably in the best position to make them.
> From a quick look at the code, I believe the current Pocket
> implementation does this. It checks the list of enabled locales (which
> is in a pref) on startup to determine if it should show up in the UI:
Yes, pocket ifdef'ed locales but its a generally poor way to
build any feature. this was a hack for pocket and soon to be removed
needing to write code to list which locales to ship, or needing to copy in
strings to the code as pocket does is a pretty labor and time intensive
activity and prone to error.
[Bug 1163645] Pocket only enabled on en-US, hard-coded locales aren't
picked up[Bug 1161138] localization of pocket doesn't use gecko l10n systemfor
the very trying and overly complex interactions in those bugs that actually
slow down main development work and localization and are counter to good
practices for managing projects in fast and effective ways.
> Right now to me it feels like the server-side should be used for
> things like phased roll-out (ensuring that the rollout itself is
> working and not busting users), and the client side should be used for
> things like localization and a/b testing (this puts the team working
> on the add-on, who presumably are the most informed and have the most
> to gain, in control without dependencies on other teams).
> All that said - I think we have the ability to mix and match
> client/server logic here, and we have the latitude to change our minds
> if we don't like how things are going. Using existing systems and
> services gives us a way to reduce dependencies and gives us some
> immediate benefits (like shipping features faster) , but there's no
> reason we can't for example later change the set to come from a
> microservice that exerts more fine-grained control if we decide we
> don't like having these decisions made on the client.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gofaster