Lokalization for KDE AppStream AppData files

[Albert Astals Cid]

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?

Cheers,
  Albert