Lokalization for KDE AppStream AppData files

[Matthias Klumpp]

2014-02-23 17:35 GMT+01:00 Albert Astals Cid <aacid at kde.org>:
> El Diumenge, 23 de febrer de 2014, a les 17:04:22, Matthias Klumpp va
> escriure:
>> 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
>
> Why? is this an intltool limitation?
>
>>  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.
>
> So you plan to integrate intltool with scripty? And we're basically
> accomodating the workflow to intltool limitation?
Yes to the first one, to the second one I think it's actually an
advantage to have the non-localized source separated from the
localized result. But if you can't live with that at all, I could also
look into itstool, which can handle a definition for translatable
elements (which would have to be included in Scripty).

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/