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. Cheers, Matthias
-- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/