← Back to team overview

ubuntu-phone team mailing list archive

Re: Internationalizing scopes

 

On Wed, 2014-04-16 at 19:11 +0200, Martin Pitt wrote:
> 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 :-)

I think it will more often than not be more than 3, I don't think
very_short_time will be anywhere near constant, and I don't think it's
going to be linear. But I do think the performance and battery
consumption as a result of disk IO are real things we need to be
concerned about here. The difference is not negligible. :)

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

A cache might help, but I'm not sure it would be the best solution. It
would have to be a bit more complex than just the translations. There
are some technical challenges with the way the scopes API and Unity8
work, that make it a bit hard to be as fast as we should be, though. 

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

Perhaps for now, but at some point that will have to converge so that
they aren't two entirely separate systems. If they always remain two
separate systems, we'll have failed at the convergence story. :)




Follow ups

References