← Back to team overview

ubuntu-phone team mailing list archive

Re: Internationalizing scopes

 

On 16/04/14 06:29, Martin Pitt wrote:
David Planella [2014-04-15 17:20 +0200]:
- Create a cmake rule to generate the .pot file, based on [3] and add
another rule that calls intltool-merge to put the translations into the
final .ini file at build time
For scopes in click apps this seems fine to me, as they should be
self-contained, are created by third parties, and aren't covered by
language packs.

For scopes in the Ubuntu archive I think it would be better to just
reference the translation domain in the .ini file, similar to our
.desktop files. Then they can be covered by langpacks and we wouldn't
need to update all click apps for new translations.

Same story as for Ubuntu classic really :-)

Agreed, having a common langpack makes sense here, afterall the same .mo would probably be already loaded by something else. But I'd consider this an exception rather than the rule.

We think using this option (inline translations in the ini files vs reading
the translations from .mo files) is the best solution in terms of
performance when reading the list of scopes, but we'd like to hear other
comments/views too.
I think the performance question is largely irrelevant. You are going
to open both files at runtime anyway, you most likely have other parts
of your click package than the ini file which have translatable
strings). Also, the disk space for inline vs. .mo translations for a
few strings isn't going to reach a significant size.

I don't think the perf question is irrelevant, yes, for the apps/scopes themselves it is (afterall they don't even have a reason to read the ini file), but for processes that actually list all the installed scopes/apps, it does mean mmapping 100 extra files (if you have 100 apps). Was there ever a measurement how these types of apps are affected?


So I think which approach to use should be decided based on how we
want the translation lifecycle/rollout to look like only.

Martin




References