Adopting AppData in KDE?

[Richard Hughes]

On 6 November 2013 03:49, T.C. Hollingsworth <tchollingsworth at gmail.com> wrote:
> Unfortunately, the schema says the latter is invalid.  Is the schema
> wrong or intltool wrong?

This is what we do in GNOME:
https://git.gnome.org/browse/gnome-software/tree/data/appdata/org.gnome.Software.appdata.xml.in
gets translated by intltool into
http://people.freedesktop.org/~hughsient/temp/org.gnome.Software.appdata.xml
-- so we have a document structure like:

<description>
<p>
Software allows you to find and install new applications and system
extensions and remove existing installed applications.
</p>
<p xml:lang="cs">
Aplikace Software umožňuje vyhledávat a instalovat aplikace a
systémová rozšíření a odebírat stávající nainstalované aplikace.
</p>
</description>

> If we have to do it by paragraph, having scripty merge the
> translations back into the original XML is going to be ugly...

The reasons I chose to do it this way were mainly because most
translators hate translating XML tags. And if one translator does
something slightly wrong, the whole document becomes invalid. For
instance, asking the translators to translate this source string:

<p>This is the list of features:</p><ul><li>Massive color database</li></ul>

If they translate this as:

<p>This is the list of features:</p><ul><<li>Massive colour database</li></ul>

This fails hard when the document is installed (as in, fails to parse,
and so doesn't get used). Most translators won't validate the
resulting XML document before translating. In GNOME we'd ask them to
translate "This is the list of features:" and "Massive color database"
which is much more sane and basically impossible to get wrong.

If you have a translation tool that is able to somehow rebuild the tag
structure and only ask the translators to actually translate the prose
then I suppose supporting something like <description xml:lang="cs">
in AppData makes sense, but only if it takes more than one translator
replacing <p> with «p»  to screw things up.

> Could we just ship the .mo files in /usr/share/app-info/locale or so
> and just have the extractors copy those files unconditionally (e.g.
> regardless of the existence of a .desktop file) when trawling through
> packages?

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

Richard.