DevHeads.net

AppStream Upstream Metadata: The next steps

Hi there!
It has been a while simce the last AppStream metadata thread, and I
have been busy upstream with adjusting the spec for future needs.
But now I have some good news for you!
I finally managed to create an initial draft of the metadata spec for
KDE on the Techbase Wiki:
<a href="http://techbase.kde.org/MetaInfo" title="http://techbase.kde.org/MetaInfo">http://techbase.kde.org/MetaInfo</a>
It is not yet complete and I expect some changes in future, but it
would already be great if you could comment on it, so we can clarify
possible problems. Especially KDE-specific guidelines would be nice (=
how do we want KDE applications to be presented?)

I also worked a bit on the translation side - to be honest, that stuff
has been ready for quite some time, but I have problems to integrate
it with Scripty (l10n-script) at the proper place, because I simply
don't know to integrate it properly. Scripts is a confusing collection
of scripts, and if you don't use it, it's hard to understand it.
So far, I created two small bash scripts to translate AppStream
upstream metadata:

extract_metainfo.sh: This script generates .pot files from metadata
XML files found in a project. Just cd to the directory you want the
resulting pot files to be stored in, then call the script and point it
at the project's source tree you want to be searched for the XML
files.

merge_metainfo.sh: The script merges translation back into the XML
files. Simply cd to a directory which stores .mo files with the
translated data and call the script with the project's source dir as
first parameter.

These scripts illustrate how translation of the XML can be done in
KDE. I would kindly ask the l10n-script developers to take a look at
it any maybe integrate it at the proper places, because they know the
code way better than I do.
The scripts can be found at:
<a href="http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz" title="http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz">http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz</a>
(I also included a demo XML file)
I wanted to post that to Reviewboard, but couldn't find a project for Scripty.

To answer a few questions before they arise:
~~~
"Why does the XML specification described at the KDE Wiki look
different from what I have seen in GNOME before?"
The KDE pages use the new specification described in AppStream 0.6,
which has a much bigger scope than the previous specification, which
was just designed for applications.
GNOME started with the old application-only spec and will soon migrate
to the new one. At KDE, we can start of 0.6 directly. Implementation
of this is going on quickly and will soon be complete.

~~~
"I am confused about the AppStream metadata naming!"
No worries, here's some information that might help:

AppStream distro metadata: This metadata is shipped by distributions
as substrate for software-center applications. It is a XML spec
defined in AppStream, and often referred to as "AppStream data".
The data is generated from

AppStream upstream metadata: This is the stuff we ship in KDE. It is
small XML files stored in /usr/share/appdata which describe software
components shipped with the individual software package. It contains
lots of metadata to present an application or component to the user.

AppData: AppData is upstream metadata. Simple as that.

Component: A component is the basic unit AppStream works with. A
component can be an application, a font, a codec etc. Most components
are things we want to show in a software-center, but it is also
possible to define metadata which just helps the operating system to
find missing software components in the archives in a distro-agnostic
way.

"Can we have a component-type for KDE specific things? For example to
show Plasmoids in a software-center, or even display them as
downloadable in GHNS?"
Of course! If someone wants to help with defining additional
components, please get in touch with me.

~~~~
And that's it for now :-)

Cheers,
Matthias

Comments

Re: AppStream Upstream Metadata: The next steps

By =?utf-8?q?Burkh... at 04/18/2014 - 14:50

Am Freitag, 18. April 2014, 16:25:40 schrieb Matthias Klumpp:

Quoting my comment on <a href="https://git.reviewboard.kde.org/r/117609/" title="https://git.reviewboard.kde.org/r/117609/">https://git.reviewboard.kde.org/r/117609/</a>

Please have a look at the recent changes in <a href="http://websvn.kde.org/trunk/l10n-kde4/scripts/?sortby=date#dirlist" title="http://websvn.kde.org/trunk/l10n-kde4/scripts/?sortby=date#dirlist">http://websvn.kde.org/trunk/l10n-kde4/scripts/?sortby=date#dirlist</a>

extract-xml.sh
update_translations
fillxmlfrompo.py

These changes are about a similar problem, ectracting strings for translation
from mimetype xml files and fill the xml files with the translations.

Re: AppStream Upstream Metadata: The next steps

By Matthias Klumpp at 04/18/2014 - 15:11

2014-04-18 20:50 GMT+02:00 Burkhard Lück <lueck@hube-lueck.de>:
[1]: Maybe long-term it would make sense to attempt a Python rewrite
of this? (there are currently bits of C++, Python, Perl, Sh and Bash
in this - Esp. calls like "g++ -O2 -march=nocona -o apply
scripts/applycontext.cpp" in the generation code make me wonder...)

Re: AppStream Upstream Metadata: The next steps

By =?utf-8?q?Burkh... at 04/21/2014 - 15:05

Am Freitag, 18. April 2014, 21:11:10 schrieben Sie:
Thanks.

Re: AppStream Upstream Metadata: The next steps

By Matthias Klumpp at 04/21/2014 - 15:38

2014-04-21 21:05 GMT+02:00 Burkhard Lück <lueck@hube-lueck.de>: