ubuntu-phone team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

Rodney Dawes [2014-04-16 13:02 -0400]:
> > 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.

Yes, sure. But then it's 200 * very_short_time vs. 3 * 200 *
very_short_time, so still a total factor of 3 :-)

> We're talking about one app loading the translations for all apps.

FWIW, that might be too slow regardless of which approach we use.
That's fairly similar to what gnome-menus did back then to read all
the *.desktop files in the system to build the start menu. We've had a
patch there which created a cache of all available translations which
got updated automatically via a dpkg trigger whenever there was a
change in /usr/share/applications. If even parsing 200 ini files takes
too long for a fluid UI experience, this might be something to consider.

> 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).

Yes, we agree (that's what I wrote as well). As I said, the langpack
concept makes a lot less sense on system images where it doesn't
matter which "package" the bit you update (a .mo file) came from.

> 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.

Agreed. We regularly update the system anyway, so each build would
automatically have the latest langpacks.

> We could theoretically have clicks that are just langpacks for the
> core system, but it would be complex to build them

Yes, agreed. That's not really what clicks should be for.

> 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.

Well, it's going to be two different systems no matter what, unless we
want to abolish the langpacks for desktop as well. But we have lived
with two ways of shipping translations since breezy or so :-)

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)