We need to be able to select at build time the languages (l10n,
dictionaries, etc). Most carriers will want to ship lower-end devices
with limited storage with a few languages at most.
If we compress l10n in a very clever way, we might actually be able to
have 70+ languages on every device, even low-end ones. Fabrice and
Vivien are working on something in this area. But even then, we must be
able to configure languages. In some countries certain languages are
illegal and we must be able to at least hide them.
As for predictive text, we should put a version of the keyboard with
more dictionaries into the marketplace so people can download what
doesn't come with the phone.
Andreas
Tim Chien wrote:
On Sat, Aug 24, 2013 at 11:16 PM, David Flanagan<[email protected]> wrote:
On 8/23/13 10:50 PM, Tim Chien wrote:
David, by build size, you mean the size of the built packaged zip
files, of the original source files?
I mean 18mb of new files are going into the keyboard app zip file. Those
data files are already fairly compressed, so I would guess that the zip file
itself increases by 12-15mb. The data is read out of the raw data file
everytime, so there is no indexeddb hit once it starts getting used.
Right. That's really a lot :-/
I am updating the Traditional Chinese IME which will increase the
zip'ed size by ~1mb (bug 908577). When enabled, the IndexedDB backend
of the IME will create results a 18mb sqlite in the profile. When
removed the zip'ed size is reduced by 2.3mb.
Removing the Simplified Chinese IME saves about 600kb (zip'ed).
Drivers, do we have a hard limit of the build size on any particular
devices?
I hope that when we ship 3rd-party keyboard framework, eventually, we
should be able to split these keyboards into different keyboard apps,
not preloading them, and make them available on Marketplace (just like
Firefox spell check dictionaries).
And for the built-in keyboard, it would be nice if there was a way for users
to add keyboard layouts and dictionaries. I don't know how that would work,
but it would be easy to modify the code to look in DeviceStorage for
auto-correct dictionaries that aren't found pre-packaged in the app. I
don't know how you'd get an autocorrect-dictionary from Marketplace to
device storage, however (unless we started treating them like wallpapers and
had the keyboard use a Pick activity to obtain them from some other app).
I mean actually split the Gaia keyboard app into many, many keyboard
apps for different regions, or even individual layouts. Then we could
simply leverage 3rd-party keyboard framework (where users are free to
install/enable multiple layouts from multiple keyboards) and select
the keyboard app(s) to include in the build.
Alternatively, if we hit the hard limit before that, we would need to
make the build script of keyboard app configureable (I hope not).
Build-time configurability is actually my plan for bug 884752, which Andreas
marked Koi+. The idea is to make the list of keyboard layouts and
dictionaries configurable at build time (like the list of locales is) so
that carriers can create builds for exactly the counties that they plan to
support.
The reason I don't like this is because it remove features from Gaia.
I would imagine when the user get a hold of a Firefox OS phone, she/he
expects a same set of features present. If we remove feature like this
then it has to be recoverable, maybe from Marketplace (hence my
previously mentioned idea).
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
