GNOME Bugzilla – Bug 723760
Automatic star ratings
Last modified: 2014-02-28 10:20:50 UTC
Yesterday we discussed a plan for ratings for 3.12, and agreed to: * Remove the control for manually rating apps. * Automatically generate a 5 star rating for each app, using information on: 1. Integration level. 2. Whether it is featured/recommended. 3. If it has a recent release. 4. Whether the application is available in the user's language. 5. One other thing that I can't remember. :) * Indicate the star rating on tiles (when browsing categories [1]), in search results, the installed list and application description pages. If we can't get this done for 3.12, my suggestion would be to remove the existing star rating UI and revisit for 3.14. [1] https://raw.github.com/gnome-design-team/gnome-mockups/master/software/version2/hi-res-category.png
commit 044ef3d41d3fb78d5666ab03b65c62ecf1070f53 Author: Richard Hughes <richard@hughsie.com> Date: Tue Feb 25 16:29:01 2014 +0000 Do not show the ratings stars in the UI Disable this until we can automatically generate a 5 star rating for each app. Resolves: https://bugzilla.gnome.org/show_bug.cgi?id=723760
...and sadly, thats not 3.12 material
(In reply to comment #0) > 4. Whether the application is available in the user's language. I've sent email to the bug-gettext mailing list asking if it's okay to extend the gmo file format with information that lets us access this data. If they agree, I'd have to write the patch, get a new upstream release, then rebuild everything with a new version of gettext just to be able to get these kind of numbers. Just this one item is a huge amount of work. Richard
I don't think this is the fasted way forward, fwiw. Why stuff this information in the binary gmo format, when you already extract app data at build time ? All you need to do is write a little utility that can run in po/, take a good look at the .pot and the .pos, and put out 2 numbers for each locale. Then you fold that information in the app data file, and - voila - all set !
project=$1 make $project.pot total=$(grep "^msgid" $project.pot | wc -l) for f in $(cat LINGUAS); do this=$(msgfmt --statistics $f.po 2>&1 | cut -f1 -d' ') percentage=$(($this * 100 / $total)) echo "$f: $percentage" done -- run as follows in the build tree: cd po; stats gnome-software produces output like this: $ . ./stats gnome-software make: `gnome-software.pot' is up to date. ar: 6 ca: 37 cs: 98 da: 62 de: 84 el: 93 en_GB: 49 es: 93 fi: 80 gl: 89 he: 45 hu: 89 id: 65 it: 63 ja: 61 ko: 82 lv: 74 nb: 55 pa: 6 pl: 63 pt_BR: 83 ru: 6 sk: 76 sl: 78 sr: 89 sr@latin: 89 th: 7 uk: 63 zh_CN: 84 zh_HK: 84 zh_TW: 84
Yup, that's the easiest thing to do, but for Fedora we have to generate the appstream info from the *built* binary rpm at createrepo time, we can't actually rebuild every rpm to get this data. Getting the various upstreams to add this info to po/Makefile.am would be tricky indeed. The alternative is we try to do something using a rpm script run at build time, although that's not super friendly to ubuntu and friends. I was going to spend an hour or two trying to work out if we can get the total number of strings from the hash table entries in the gmo file. If that fails, I'll look at the rpm script thing.
If you have to work purely on the .mo files, then the options are limited: - get upstream gettext to add a header field for completion percentage (the mo file format looks like it has an extensible header) - get a lower bound for the number of translatable strings by collecting the translated message ids for all languages (this will not give perfect results, since some messages may not be translated in any language).
(In reply to comment #0) > 1. Integration level. Can we define this a bit more. Would "uses gtk3" be good enough for 3.12? We can raise the bar a little more later if required. > 2. Whether it is featured/recommended. I've added support for this. > 3. If it has a recent release. Can you define "recent" please? In the last year? > 4. Whether the application is available in the user's language. I've added support for this in the upstream AppStream spec and implemented it in fedora-appstream and in gnome-software. It's a rough metric that uses the gmo files, no modifications to gettext, and seems to be accurate to +/- 10%. i.e. good enough. I'm considering any app with better than 50% coverage of the specific locale to have support -- but I don't know if I should do fall backs, e.g. is US English good enough for en_GB? What about pt for pt_BR? > 5. One other thing that I can't remember. :) Any ideas? We've got 5 stars to fill :) Richard.
(In reply to comment #8) > (In reply to comment #0) > > 1. Integration level. > > Can we define this a bit more. Would "uses gtk3" be good enough for 3.12? We > can raise the bar a little more later if required. Here are some criteria I could come up with (note that not all of these will be usable in our situation): + uses gtk3 - uses gtk2 + has app menu - has a status icon + has a search provider + installs help in /usr/share/help - app icon is a xpm or in /usr/share/pixmaps + desktop file indicates that the app is using notifications + DBusActivatable + has keywords in the desktop file > > 3. If it has a recent release. > > Can you define "recent" please? In the last year? I would look at two levels here: 1. 'was fresh when the OS was released' 2. 'newer that the OS' This would roughly map to 'within the last year' and 'within the last 6 months', I guess. > > 4. Whether the application is available in the user's language. > > I've added support for this in the upstream AppStream spec and implemented it > in fedora-appstream and in gnome-software. It's a rough metric that uses the > gmo files, no modifications to gettext, and seems to be accurate to +/- 10%. > i.e. good enough. > > I'm considering any app with better than 50% coverage of the specific locale to > have support -- but I don't know if I should do fall backs, e.g. is US English > good enough for en_GB? What about pt for pt_BR? I wouldn't worry about it for now. > > 5. One other thing that I can't remember. :) > > Any ideas? We've got 5 stars to fill :) web page comes up high in a google search for the app name ? we've talked about reliability and fitness for purpose as criteria, but those may be hard to automate,
(In reply to comment #9) > + uses gtk3 What about uses Qt4 as well? > + has app menu Can we detect that from looking at a filelist, or do I have to ask app authors to add something manually to the appdata file? > + has a search provider Done. > + installs help in /usr/share/help Done. > - app icon is a xpm or in /usr/share/pixmaps Rather than a (-) what about adding a (+) for shipping symbolic/high contrast versions? > + desktop file indicates that the app is using notifications Done. > + DBusActivatable Is this a sign of quality? > + has keywords in the desktop file Done. > This would roughly map to 'within the last year' and 'within the last 6 > months', I guess. Okay, I'll work on this today and see if I can get some half-decent data out of rpm/fedora. > we've talked about reliability and fitness for purpose as criteria, but those > may be hard to automate, Reliability could tie into the abrt data, but we'd also need usage data for that too.
(In reply to comment #10) > (In reply to comment #9) > > + uses gtk3 > > What about uses Qt4 as well? Maybe ? I know too little about qt apps to say for sure, so rather wanted to leave that out. > > + has app menu > > Can we detect that from looking at a filelist, or do I have to ask app authors > to add something manually to the appdata file? Not 100%. nm -D /path/to/binary | grep gtk_application_set_app_menu should be something like 90% for gtk apps that are written in C. But a) that might change (say, if we added a way to set the app menu from .ui files) and b) doesn't work if you are using a binding. > > > - app icon is a xpm or in /usr/share/pixmaps > > Rather than a (-) what about adding a (+) for shipping symbolic/high contrast > versions? yes, but.. we may change things a little bit around app icons and icon themes, and then this would not apply in the same way anymore. The xpm thing on the other hand is a sure sign of staleness. > > + DBusActivatable > > Is this a sign of quality? No, its a sign of integration ;-)
(In reply to comment #11) > nm -D /path/to/binary | grep gtk_application_set_app_menu Done. > should be something like 90% for gtk apps that are written in C. But a) that > might change (say, if we added a way to set the app menu from .ui files) and > b) doesn't work if you are using a binding. I guess in that case the app can always add a hint in the appdata file. > > > > > - app icon is a xpm or in /usr/share/pixmaps > > > > Rather than a (-) what about adding a (+) for shipping symbolic/high contrast > > versions? > > yes, but.. we may change things a little bit around app icons and icon themes, > and then this would not apply in the same way anymore. The xpm thing on the > other hand is a sure sign of staleness. Okay, lets switch this around, what about a (+) for an app that installs into /usr/share/icons/hicolor/? Richard.
(In reply to comment #12) > > Okay, lets switch this around, what about a (+) for an app that installs into > /usr/share/icons/hicolor/? Again, not 100% sure we really want to count 'leaves its app icon and identity open for raiding by themers' as a definitive plus.
I've committed this: commit 0333391db8f975d3015ffdd75feb88a70b7b4c45 Author: Richard Hughes <richard@hughsie.com> Date: Thu Feb 27 12:00:02 2014 +0000 Re-enable the star widgets Resolves: https://bugzilla.gnome.org/show_bug.cgi?id=723760 We can tweak the relative weights given to each thing, and the ratings seem to be working well. I've got to clean up some hacks in the metadata parser today although the output should be the same.