ubuntu-phone team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

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)