Adopting AppData in KDE?

[Matthias Klumpp]

2013/11/2 Richard Hughes <hughsient at gmail.com>:
> On 2 November 2013 11:00, Yuri Chornoivan <yurchor at ukr.net> wrote:
>> 1. AppData files are tailored for intltool/its-tool processing (tags with underscores). What do you think about adding untranslatable by design appdata files like it was done for Audacity [1]?
>
> Well, this is fine if you speak en_GB or en_US, but that's only a tiny
> proportion of the desktop Linux users these days. It's certainly
> better than nothing, but if you don't speak English it's not helpful
> at all.
>
>> 2. AppData in GNOME packages is filled with translations while compiling/packaging the application. Can it be somehow aligned with KDE idea of storing translations in separate repo?
>
> I'm not sure how KDE does this on a technical level, but I'm sure you
> could merge the XML file together somehow if you didn't want the
> xml.in intltool method.
This would indeed be an issue for KDE...

>> 3. Is it technically possible to have appdata.xml in repo translated by scripty based on KDE desktop- POs (just like KDE .desktop files)?
>
> No clue on this, sorry.
Yes, scripty could do that. It would make the files less readable an
probably very huge, but it is certainly possible. I could imagine
allowing PO files as translation sources, which are referenced from
the XML, as long as Richard doesn't have objections ;-) This might
solve all translation issues, but it's not XML-ish, of course. Ubuntu
does this for their .desktop-file-based Software Centers.

>> 4. What is planned to do with Debian/Ubuntu DDTP translations [2, 3]? Is there any plans to adopt it for Canonical Software Centre/Muon with some kind of backend?
>
> No, packages are a different problem to applications. In the case you
> have multiple applications shipped in one package you want separate
> descriptions, not one description that's a mix of the two. Plus, if we
> want non-packaged applications (for instance listaller, glick2 or
> click bundles) then the concept of a package description looses all
> meaning.
... they're of course used as fallback though PackageKit, but that's it ;-)

>> Is it yet another almost-standard for RPM/GNOME distributions?
>
> There's nothing inherently GNOME or RPM specific about this at all in
> my opinion.
I can confirm that :-)

Cheers,
    Matthias