Lokalization for KDE AppStream AppData files

[Matthias Klumpp]

2014-02-23 18:34 GMT+01:00 Albert Astals Cid <aacid at kde.org>:
> El Diumenge, 23 de febrer de 2014, a les 18:11:14, Matthias Klumpp va
> escriure:
>> 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.
>
> I'm not going to argue if it's and advantage or not [note that i could ;-)]
>
> We have a workflow for .desktop files where the english and translated strings
> are in the same place.
>
> I think that consistence (specially in these kind of files that you are
> arguing are very similar in purpose) is more important than any advantage your
> suggestion solution may have.
>
> So unless you want to implement a similar workflow for .desktop files (and
> convince us it's better), yes please, let's have the english text and the
> localized strings in the same file.
As long as trabslations are there, it's good for now - I didn't know
that itstool could handle templates as well.
Where is the Scripty source code, by the way? All I could find was
code which hasn't been touched since 2009.
Cheers,
    Matthias

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