Adopting AppData in KDE?

[T.C. Hollingsworth]

On Wed, Nov 6, 2013 at 1:40 AM, Richard Hughes <hughsient at gmail.com> wrote:
> I'm not sure how well this will work, at least in gnome-software we
> allow the user to match on a keyword cache using the "C" name, and
> also the UTF8 and normalized versions of their current locale.

Nah, I meant for the extractor tools to read in the translations into
the big giant AppStream XML; no magic needed in the software centers,
nor would there be any need for users to have to have the package that
has these .mo files installed, which kind of defeats the purpose.

> I also
> don't think the extractor tools (from desktop+appdata->AppStream
> metadata) are going to be able to switch locale like that, and reading
> the gmo files manually isn't something I'd look forward to
> implementing.

The gettext module built in to Python can read in translations from
arbitrary domains in arbitrary languages sourcing locale files from
arbitrary directories no sweat, so this would be a fairly simple patch
to fedora-appstream.  (I'm happy to resubmit this suggestion in patch
form too, BTW; just wanted to make sure it was something you were
interested in implementing, first.  ;-)

I was originally going to suggest we do something like this but with
seperate <application xml:lang="foo"> XML fragments instead of po
files, just to make things simpler in the appstream extractor, but
after looking at what it took to get such XML output from KDE po files
I discovered that the gettext goop to implement this in
fedora-appstream itself isn't really any more complicated than the
etree goop to suck it out of those XML fragments instead.  Doing it
this way also has the side effect of ensuring that translators never
need to deal with XML, ever.

In general I think being able to ship translations separately would be
a big improvement to the i18n story for all the software centers that
implement this spec.  It has more benefits than just aiding KDE in
implementing it.

For instance, in Fedora we're probably going to be stuck with having
AppData included as SourceN files in SRPMs for quite some time.  At
the moment, translation of those is pretty much impossible.  Hooking a
bunch of random SRPMs up to Transifex would suck, as would trying to
merge back translations into the XML files in Fedora dist-git in some
automated fashion.  But with something like this it would be fairly
easy to extract all the appdata.xml files shipped as additional
sources in SRPMs, dump it in Fedora's transifex instance, and get them
back out and working in GNOME Software and Apper with minimal
difficulty.

Also, I suspect that you don't want GNOME Software in other languages
to be a hairball of that language and English forever, so you're
probably going to want to turn off display of apps that aren't
translated at some point.  You could say that "hey, obviously upstream
doesn't support that language very well, so including it in the app
center in that locale is pretty useless", which would be true to some
extent, but that ignores multilingual users who prefer to use their
computer in their native language but are happy to use an app in
English if it's awesome enough.  (There are a lot of English-only dev
tools, for instance.  I'd hate to lose would-be free software
contributors just because they prefer their desktop to be in their
native tongue.)

Adding a "show me a mishmash of Esperanto and English plz" checkbox is
really a terrible option, so if we want to have complete coverage of
translated application data in the future—and I think we really
do—we're going to have to have infrastructure for distro translators
to pick up the slack, and this would be a big head start.

-T.C.