Lokalization for KDE AppStream AppData files

[Matthias Klumpp]

2014-02-20 19:33 GMT+01:00 Martin Graesslin <mgraesslin at kde.org>:
> On Thursday 20 February 2014 18:54:32 Matthias Klumpp wrote:
>> Hi!
>> I am working on bringing AppData to KDE. AppData is a XML-based
>> metadata format to enhance information displayed about applications in
>> software-centers. It, for example, includes long descriptions of an
>> application, homepage links, donation-links, screenshot-info and some
>> other information about the application.
>> AppStream is a Freedesktop project enabling us to build cross-distro
>> software centers. GNOME is already making heavy use of it for their
>> GNOME-Software application, and KDE also uses it already in Apper and
>> probably Muon soon.
>> One challenge for KDE is how to handle localizations for AppData
>> information. I would propose the following:
>>  * KDE applications ship an <app>.appdata.xml.in file, containing the
>> raw, untranslated data.
>>  * We extend messages.sh to scan the XML file and return the found
>> strings to the generic pot file, which is then translated by our
>> localization teams as usual.
>>  * At build-time, we use intltool[1] to merge the translation with the
>> AppData file, then install it into it's target directory.
>> This is basically it. The only thing KDE projects need to do is to
>> edit their Messages.sh and depend on intltool to merge localization. I
>> could also provide a cmake macro for doing that to
>> extra-cmake-modules, if needed.
>> Do you have comments or suggestions on this?
>> I would later add it to the wiki page I'm doing to describe how KDE
>> projects which want to use AppData can easily use it.
>
> Why can't scripty update the xml file like it does with the .desktop files? I'm
> a little bit afraid of a more complicated build process as the translations
> life in a different repository and I assume most devs don't have them around at
> all.
Technically, this would of course work as well, but it needs work on
Scripty (should be relatively simple to implement though). Also, the
translated files can grow pretty large, because they contain
translated long descriptions, which is very messy to work with
compared to having one source file with the raw, untranslated data[1].

> Would that work for distributions? Don't they build the language data
> separately?
For applications which don't ship .po files with their release
package, we have no choince other than including the translation
directly (or shipping the Gettext data together with the application
it belongs to).

Cheers,
    Matthias

[1]: Take the GEdit AppData as an example:
http://paste.kde.org/pq2iajyku - this one contains only one translated
field.
-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/