Lokalization for KDE AppStream AppData files

[Albert Astals Cid]

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.

Cheers,
  Albert

> 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).