Lokalization for KDE AppStream AppData files

[Albert Astals Cid]

El Diumenge, 23 de febrer de 2014, a les 19:50:56, Matthias Klumpp va 
escriure:
> 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.

http://websvn.kde.org/trunk/l10n-kde4/scripts/

http://websvn.kde.org/*checkout*/trunk/l10n-kde4/scripts/notes/scripty-map.xmi 
contains a 4 year old umbrello file by Chani that gives a high level overview 
of how it works.

Any question you have, just ask me.

Also, since this is related to XML<->po extraction/merging you may want to 
read http://lists.kde.org/?t=138772245400006&r=1&w=2 since it seems your and 
Burkhard's goals are pretty similar and we could perfectly use the same tool 
here.

Cheers,
  Albert

> Cheers,
>     Matthias