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 <aa...@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 <aa...@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 <kram...@kde.org>: > >> >> > On Sunday, 2014-02-23, 16:31:37, Matthias Klumpp wrote: > >> >> >> 2014-02-23 16:28 GMT+01:00 Kevin Krammer <kram...@kde.org>: > >> >> >> > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote: > >> >> >> >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid <aa...@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 <aleix...@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