ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

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.