[Go Faster] Hello-as-addon challenges
mconnor at mozilla.com
Tue Sep 1 16:33:31 UTC 2015
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 also
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
to 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 with
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
On 1 September 2015 at 09:40, Armen Zambrano Gasparnian <armenzg at mozilla.com
> Can we deliver features to locales only if they have been localized and
> signed off?
> In other words, make a feature available only if we have marked that the
> localization for it is ready for it.
> It would be great if the browser would be able to determine at what point
> a a feature has been localezied and signed off, fetch the strings for that
> feature and enable it.
> I believe this would give us all the ability to move forward and
> localizers to catch up.
> On 31 August 2015 at 17:50, Axel Hecht <axel at mozilla.com> wrote:
>> On 8/31/15 11:36 PM, Toby Elliott wrote:
>>> On Aug 26, 2015, at 12:13 PM, Chris Hofmann <chofmann at mozilla.com>
>>>> Yes, that's theortically possible, but leads to trying to manage 80+
>>>> releases for each of the locales that we serve, and a very complex
>>>> release management process in terms of commuication and execution.
>>>> Ben, locales 4, 8, 10, and 22 are ready to go... please build and push
>>>> Ben, locales 25, 41, and 15 are ready to go... please push those.
>>> Couldn't this be "Ben, enough locales are in to ship this, please push"
>>> followed by out-of-band string updates for those other localizations as
>>> they come in?
>> So, 'enough' is undefined, see below ...
>>> Do we simply refuse to ship a feature to a locale if the translation
>>> hasn't come in? Or is it acceptable to have fallback strings in parts of
>>> the browser when a more obscure language hasn't been localized yet?
>> This is the real question: Is it OK to ship a string in English in ... X?
>> The answer is gated on the question, really.
>> If the question is "are we gonna learn something useful out of shipping
>> this?", then the answer is only going to be yes if the translations of that
>> test are awesome. Otherwise you'll just measure "oh my god, this isn't in
>> my language", followed by "oh my gosh, this is horrible grammar". The
>> latter is actually real feedback I just read the other day. You're not
>> going to see any signal in our data that's related to the patch in question.
>> If the question is "is this feature good to ship in English?", that's a
>> VERY complicated question. Depends on culture, and beyond that, user
>> population within that culture. Can you say "hey, buddy", literally, to me?
>> Sure. Can you say that to my mom? Hell no. Which brings us back to the
>> question of what's there to gain, and what's there to loose.
>> And lastly, there's some concrete lessons we've learned in the past few
>> years. If UI sucks and survives, it'll suck. If it dies, it dies. The
>> expectation that we'll "ship things as they come in" doesn't match our
>> real-life experience. And the lack thereof makes total sense to me, at
>> least in my cynical way of thinking about human beings.
>> Gofaster mailing list
>> Gofaster at mozilla.org
> Zambrano Gasparnian, Armen
> Automation & Tools Engineer
> Gofaster mailing list
> Gofaster at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gofaster