On Wed, 2014-04-16 at 18:37 +0200, Martin Pitt wrote: > 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.
Just like on full Ubuntu, only some langpacks are installed by default. If I want to use a language that is not covered by those langpacks, how do I get that language? And how do you propose it gets updated if there is a change in it? We can't possibly ship every langpack that exists in the default image. That would make the default image way too large. > 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. For click packages, shipping the translations in langpacks makes no sense at all. It's not worth the complication; even for click packages where Ubuntu/Canonical is the upstream. > > 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. It's not an extra mmap for a single string lookup. It's at least one stat and one mmap for EVERY SINGLE APPLICATION that is is installed. If falling back to a more generic version of the locale is required, it adds at least one more stat. We're not talking about a click package itself loading the translations. We're talking about one app loading the translations for all apps. It is not an exaggeration at all. It is a fairly close estimate. And the convenience of lang packs would only be for things where we are the upstream (and probably only things that are in the image itself, rather than updated via clicks). I don't think the convenience is worth the trade-off of disk IO as relates to performance, or battery consumption. > 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. Indeed. And I don't see a convenient way to have langpacks which aren't debs, which means they'd have to be part of a system update. We could theoretically have clicks that are just langpacks for the core system, but it would be complex to build them, and it would mean doing the same thing in two different and conflicting ways; clicks for the phone images, and debs for full Ubuntu installs. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
