On 10/15/2013 12:06 PM, Benjamin Smedberg wrote:
With the landing of bug 853301, we are now shipping ICU in desktop
Firefox builds. This costs us about 10% in both download and on-disk
footprint
I'm going to try and summarize the discussion and indicate next steps.
==
First, I want to be clear that I am approaching this question for
desktop Firefox only. B2G has different adoption requirements and a
different localization strategy than desktop.
==
Several people thought that it would be a bad thing to include only one
or some subset of language data in Firefox as shipped by default, on the
grounds that there should be one web platform. Anne brought up the use
case of a computer in a hotel/hostel.
Axel points out that ICU locales are more analogous to language
dictionaries. Users can choose to install dictionaries independent of
the UI locale of Firefox.
Jeff is worried that any sort of dynamic system would cause the Intl.*
methods to return different results over time, which is surprising to
platform developers.
Jeff also said that Chromium may not be shipping the full language list,
but perhaps only a subset of languages. I tested Chrome's behavior, and
it appears to be shipping a fairly full set of language data, including
languages such as Amharic which I'm pretty sure it doesn't ship.
I'll also mention that this came up in the previous discussion last
December, and at the time we discussed whether it would be better for
websites to provide their own implementation of these intl functions and
download whatever data they needed; the obvious disadvantage of this is
that each site would be downloading the data separately without sharing,
which is not a good experience for developers.
==
jwatt mentioned that he has a dependency on DecimalFormat for parsing
numbers from <input type="number">. What locale data does this actually
require?
==
mbrubeck wonders why this particular feature is being questioned based
on its size, when in general the Firefox package size has gotten larger
with other features but without a lot of fuss.
I am questioning this feature now because it is a sizeable jump even by
historical standards, and because I was made aware of data that shows
that download size affects both initial adoption and update rates.
Perhaps we have been adding features to the platform too liberally and
affecting adoption. Perhaps we need to set an absolute cap on download
size, and figure out how to work within that cap. I don't really know
the answers, but we should all be worried about our adoption and market
share numbers; death by a fairly small set of 10% increases is still a
big deal.
==
There was a technical discussion about how we could implement dynamic
download of more languages, and whether the spec made that easy or hard.
It is clear that the current spec is synchronous and doesn't have a way
to request additional languages and wait for them. We could do the
download and start showing results later, but we can't really block on
that data.
My only other thought here is whether we should propose for the Intl
draft an additional async API to request new languages and get a promise
back for when they are ready.
==
cpeterson asked whether we have funnelcake data to actually measure the
effects of additional download weight.
I had been pushing this with out stats/UR group, and this is now filed
as bug 928017. I don't have commitments to make this happen yet, but I'm
working on it.
==
Bill provided more details about the user research data about connection
speeds and update rates. The summary seems to be that update rates are
much lower for users with slower connection speeds.
==
I don't think that there is enough data yet to make a decision.
Hopefully funnelcake results which help make a more informed choice. If
it turns out that that Firefox wants this decision reconsidered, what
groups and goals would be affected by asking for ICU or at least the
number-format and date-format APIs to be disabled for download weight
reasons in 27?
To be clear, the final decision is definitely not mine to make: I just
want to make sure that we know what we're trading off and that it's
clearly what we ought to be doing.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
