Rodney Dawes [2014-04-16 11:37 -0400]: > No, instead of a simple update to the click, which can be installed from > system settings and only take a few seconds for the user to accomplish, > we'd have to build an entirely new image, and require the user to do a > full system update
Why would that be? The langpacks should already be installed, and if not, you don't choose a new language when installing an app, but in the settings app. This would be an issue for updating the translations themselves, but I would have assumed that we just fold them into regular system image updates. For non-Ubuntu click packages the langpack approach is obviously not working (but I wrote that already), for this case I don't see any option other than shipping the translations (either .mo files or inline, not much difference) within that click package. > Or is there some plan to ship those language packs as click packages > that the user has to install separately, and then update? (It's not > clear to me how the user is supposed to enable alternate languages > on the phone images, given they can't install .debs.) At the moment our system images can't install additional debs, so we ship the langpacks for the most common languages pre-installed and in system settings you can only choose between those. But FTR, I'm not aware of any existing discussion/plan how this should look like in the future. > I don't think that's true. See my other reply for more details, but > inline translations can be orders of magnitude less disk access. This needs to be measured first. "Orders of magnitude" is certainly a big exaggeration; it's an extra mmap() for a single string lookup and maybe three extra stat calls. It can surely take a factor of about three (of a very short time), so whoever designs this needs to decide whether the easier rollout of translations is worth that cost, and measure how much time either approach actually takes. > I don't think that's right. AFAIK, we don't even have a solid plan > for how alternate system (not click packaged apps or scopes) > languages are made available to the user, and how the user would > enable them. They can't be .debs, because the user can't install > them. For sure this question needs to be addressed at some point. This is orthogonal to the original question here where to ship translations of .ini files. I. e. even with inline translations there is currently no way to select languages other than the already installed ones as we currently can't install .debs on the phone. That's one of the major outstanding tasks for a converged system. For the record, I have no big emotional attachments to langpacks on the phone -- if we don't want them, that's entirely fine to me. If we are fine with shipping new translations through rebuilding/reuploading the corresponding (click/deb) packages, or we don't care about updating translations separately, let's avoid the hassle completely. In the "update whole system as an image" the reasons for having langpacks in the first place are much smaller than for the classic .deb based desktop. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
