Il giorno dom, 27/11/2011 alle 18.47 +0100, Björn Persson ha scritto: > Giovanni Campagna wrote: > > We also need translations (that are in .desktop files > > but not in .spec files), > > Looky here, a spec file with translations: > http://pkgs.fedoraproject.org/gitweb/?p=mine_detector.git;a=blob;f=mine_detector.spec;h=294bcf4148789afb1ba7bb7b11971e231e001061;hb=master > > Making lots of translators co-maintainers of all packages just to let them > translate the spec files wouldn't scale of course, but there also exist > translated package descriptions which do not originate from the spec files – > even for packages without desktop files. At least some Swedish translations > exist; I don't know about Italian. I can't tell you exactly how those > translations are produced and distributed, but someone who works with > translations presumably could. Well, I'm happy to see that some spec files are translated. In fact, I found out some packages have translations, but those are only visible from yum, not PackageKit (no matter how you insist). In any case, I would consider spec files as somehow complementary to desktop files. As you point out in an other mail, we currently don't have good user visible titles in rpm metadata, but for most of our packages this is not an issue, as most of the users should not even notice their existance. On the other hand, a .desktop file has the property that the very same file, when the package is installed, will end up in /usr/share/applications and thus in the app launcher (gnome-shell, kmenu). This means that the categories exposed in the .desktop file actually reflect the position of the application as installed, that the name and the command are exactly the same, etc. Also, it becomes possible to have multiple applications in the same package, without the user knowing that one app is part of a bigger collection. > > we need screenshots, we need reviews, we need > > ratings. > > OK, then I'm starting to understand what you want. You might want to find a > better term for that than "application installer", as it apparently does a lot > more than just install applications. Ubuntu settled with Software Center, and explicitly says translations should not use the equivalent of Application Center in the guidelines. We could do the same, although for the GNOME case we may want to keep Add/Remove packages (gpk-application), even if shipping the software-center, because, as the implementations stands, packages without a .desktop files are not shown. (The KDE case is different, as apper handles both app search and package search) > How much new server infrastructure do you think would be needed? Is a > hierarchy of FTP mirrors with a round-trip time of a day or two satisfactory > for distributing reviews and ratings? Tricky question. There are various services here to consider: 1) repo metadata. I've prepared a small python script that explodes rpm and generates suitable appdata.xml and app-icons.tar.gz. Once built, they can be distributed like every other .xml file in repodata. Since appdata.xml is the primary source of information for software-center (even before primary.xml), it must always be in sync with mirrors (otherwise it may try to download non existing packages) 2) rating/reviews. I don't know exactly what infrastructure Ubuntu uses, but it seems to be a single server with django; maybe it's possible to get away without mirroring. In any case, the rating/review API is RESTful but requires special knowledge in the server; FTP or HTTP alone are not enough. (debian has reviews disabled, opensuse uses ubuntu's infrastructure) 3) we need screenshots. Currently all the three distros use the same servers (shared between debian and ubuntu); this is going to be a large amount of data (on avg., 4 large jpgs per app), so perhaps we could agree with the other distro and use the same imgs. This said, if screenshots are stale for a bunch of days (or weeks, even), I wouldn't care. Giovanni PS: to be honest, there is a 4th item in the list: a server for accepting app store payments. I don't think this would be appropriate for Fedora, at least now.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
