2013/11/2 Richard Hughes <hughsi...@gmail.com>: > On 2 November 2013 11:00, Yuri Chornoivan <yurc...@ukr.net> wrote: >> 1. AppData files are tailored for intltool/its-tool processing (tags with >> underscores). What do you think about adding untranslatable by design >> appdata files like it was done for Audacity [1]? > > Well, this is fine if you speak en_GB or en_US, but that's only a tiny > proportion of the desktop Linux users these days. It's certainly > better than nothing, but if you don't speak English it's not helpful > at all. > >> 2. AppData in GNOME packages is filled with translations while >> compiling/packaging the application. Can it be somehow aligned with KDE idea >> of storing translations in separate repo? > > I'm not sure how KDE does this on a technical level, but I'm sure you > could merge the XML file together somehow if you didn't want the > xml.in intltool method. This would indeed be an issue for KDE...
>> 3. Is it technically possible to have appdata.xml in repo translated by >> scripty based on KDE desktop- POs (just like KDE .desktop files)? > > No clue on this, sorry. Yes, scripty could do that. It would make the files less readable an probably very huge, but it is certainly possible. I could imagine allowing PO files as translation sources, which are referenced from the XML, as long as Richard doesn't have objections ;-) This might solve all translation issues, but it's not XML-ish, of course. Ubuntu does this for their .desktop-file-based Software Centers. >> 4. What is planned to do with Debian/Ubuntu DDTP translations [2, 3]? Is >> there any plans to adopt it for Canonical Software Centre/Muon with some >> kind of backend? > > No, packages are a different problem to applications. In the case you > have multiple applications shipped in one package you want separate > descriptions, not one description that's a mix of the two. Plus, if we > want non-packaged applications (for instance listaller, glick2 or > click bundles) then the concept of a package description looses all > meaning. ... they're of course used as fallback though PackageKit, but that's it ;-) >> Is it yet another almost-standard for RPM/GNOME distributions? > > There's nothing inherently GNOME or RPM specific about this at all in > my opinion. I can confirm that :-) Cheers, Matthias