@dobey said in Language packs as click packages: call to arms!:
We just got rid of gdbserver/libc-dev, which freed up a huge amount of space. The only reason we have size problems with the image now, is because it's never really been optimized, and we just keep adding new things to it.
Sure, and soon we'll get rid of Oxide, I guess, so the future is at least a bit rosy. But having this lot of data which I don't need in the rootfs is a waste, you'll agree.
My aversion to langpacks stems from the fact that they are an anti-feature, and a premature optimization. How they are done is implementation details. One doesn't have to install any extra packages on Android to get foreign language keyboards. Core apps may be fully translated, but vast majority of 3rd party apps will be missing translations. To me, langpacks are just another way to sweep some problems under the carpet, so we end up ignoring them, rather than fixing the real problems.
It's not a premature optimization, it's a way to get rid of 307 MB (and more, in the future). The way that this feature is exposed in the user interface matters a lot: it can range from the ideal situation (the user doesn't notice, and all the langauges he needs are already on the device) from the worst one (the user needs to open a terminal and type some obscure commands to install the language packs, after which the device enters a reboot loop).
The way I see it, we are close to ideal situation, for the very simple reason that (unless everybody agrees otherwise) downloadable images having all the language data preinstalled are not going away. As long as the device can accomodate them and users don't complain about lack of space, that's undoubtly the best solution.
Now, what I want to do is part of a greater and much more evil plan: customizable images (and also, possibly, changing the way that clicks are preinstalled on the device). The idea would be that the flasher tool would offer you an option:
- Download and install default image
- Download minimal image + select individual click packages
Case #1 is like nowadays: all languages will be preinstalled. In case #2, the flasher tool would let the user select among click packages to be added on top of the base image: language packs, sure, but also ordinary applications and other click packages types that will appear in the future (I've a plan to add click packages with regional map data and wifi information for location lookup). I haven't yet thought how these will be installed on the device, but thinking out loud, I see these possibilities:
- The flasher tool downloads and install the clicks itself
- The flasher tool simply writes the list of clicks into a configuration file on the device, which will download and install them during the first boot
- Something in between (downloading the clicks from the PC, copying them over, but installing them on first boot)
The nice thing about this, no matter how we implement it, is that the flasher tool could remember the list of clicks the user has selected, and use it as a default selection for the next time. Or it could also try to read the list of the click packages installed on the connected device and prompt to use that, instead. And I bet there are more possibilities for making users' lives easier that I haven't thought of.
Anyway, the main idea is to let the user select the extra packages, and remember this list across installations and backups. And I believe that if this is done in the right way, users will on the contrary appreciate the feature (and they could see the device boot up in their own language on the first use, imagine that! )