Lokalization for KDE AppStream AppData files

[Matthias Klumpp]

2014-02-23 16:37 GMT+01:00 Kevin Krammer <krammer at kde.org>:
> On Sunday, 2014-02-23, 16:31:37, Matthias Klumpp wrote:
>> 2014-02-23 16:28 GMT+01:00 Kevin Krammer <krammer at kde.org>:
>> > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote:
>> >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid <aacid at kde.org>:
>> >> > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias Klumpp va
>> >> >
>> >> > escriure:
>> >> >> 2014-02-21 2:02 GMT+01:00 Aleix Pol <aleixpol at kde.org>:
>> >> >> > [...]
>> >> >>
>> >> >> I have a compromise to offer, which will be necessary anyway in a way,
>> >> >> since to-be-localized entries in our XML files would have to be
>> >> >> prefixed with an underscore, so merging stuff back into the original
>> >> >> file does not work (unless we duplicate data there, which is ugly).
>> >> >>
>> >> >> So, new suggestion:
>> >> >>  * Project author creates file project.appdata.xml.in, containing the
>> >> >>
>> >> >> raw data which has to be translated.
>> >> >>
>> >> >>  * Scripty processes that file and commits a project.appdata.xml file
>> >> >>
>> >> >> in the same directory where the previous one was, containing all
>> >> >> localizations. If one is already there, the file is updated.
>> >> >>
>> >> >>  * We simply install the localized file and keep the other one as
>> >> >>  template
>> >> >>
>> >> >> That solution would work, I would be happy with it and hopefully
>> >> >> Albert as well :-) If not, please make an alternative suggestion.
>> >> >
>> >> > Why do you need two files instead of one file like we do for .desktop
>> >> > files?
>> >>
>> >> All translatable items are prefixed with an underscore, for example:
>> >>     <_p>
>> >>
>> >>       Software allows you to find and install new applications and system
>> >>       extensions and remove existing installed applications.
>> >>
>> >>     </_p>
>> >
>> > Which part of the chain causes this requirement?
>> > Is the database builder looking for this to check which parts of the
>> > document it has to check for translations?
>>
>> It is used as fallback if there is no translation available for the
>> current language. If there is no localized description, the original
>> English one is added to the database instead.
>
> I see.
> If you don't mind, what was the reason for chosing this approach? Wouldn't it
> have also been possible to fall back to the <p> sibling without the lang
> attribute as a base instead?
Ah, I think we are talking about different things ;-)
The process is:
 1) Developer writes XML with some tags prefixed with an underscore
 2) intltool scans the input-XML for stuff with an underscore,
localizes the tag and adds both the localized tag as well as the
original tag (without underscore!) to the output XML
The result is a file which is localized. The underscore is just used
in the template to select elements which are translated (because some
aren't, for example the icon name).
The database builder (or the AppStream data generator in that case)
checks for the output file, not the template to generate it.