On Mon, Dec 13, 2010 at 1:52 AM, Milan Bouchet-Valat <nalimi...@club.fr> wrote: > What "high maintenance"? With a Keywords field, each app should just list > the main words that come to mind when looking for it, there aren't hundreds > of them: photo, photos, camera, cameras, possibly manager, album, gallery.
I think the high maintenance part is that “camera” and “webcam” are different, when they should be synonymous (with an overlap between categories) if we want consistent search results. I'm afraid of expecting every localization team to worry about globally consistent keywords for each application on an individual basis, and I'm worried about making application developers repeat themselves more than they already do. (Granted, the source language is the one that has too many synonymous words). > As s translators, we do more painful things than correctly translating > this kind of list and check there are no language specifics to add. A > translator comment explaining this is enough. I am glad you're here! Having the translation perspective is very helpful, because I can only really guess at it myself :) > Sure, stemming would make the list less ridiculous, but one would have > to find an algorithm that works for all languages and doesn't take too > much processing power (e.g. doesn't walk over the full dictionary). > Porter's could be a good candidate as it's available as free software in > Snowball[1]. But is it worth the result? Thanks for pointing out Snowball. Come to think of it, all the new application search things do instant search, so stemming shouldn't be a major issue in English at least (and probably most others, if my limited language knowledge is accurate…). Once good results appear, it's probably safe to assume people will stop typing rather than continuing to add suffixes to their words. > Showing a category would be confusing: for now, we only show individual > apps. We could show the list of apps that are in a category that matches > the keyword, but apps can as well add "photography" as a keyword: that's > more flexible and hasn't real drawbacks. I'm thinking categories would map to keywords. So, developers just list some categories, which they have already done for the most part (with some bugs here and there). Things usually have multiple categories (like “GNOME;Development;Debugger;” and “GNOME;GTK;Graphics;Scanning;”), and just a few of those are directly exposed to the user. The full list of known categories is in the FD.org desktop menu specification [1]. All the user sees is that searching for “camera” gives Shotwell, though there may be a case for showing the list of keywords (with matches underlined), too. I do agree there is still a strong case for application-specific keywords. For example, the categories don't cover everything (Notes, Todo and Tasks, spring to mind). Empathy might want a list of common protocols it (hopefully) supports and a game might want an abbreviated version of its name. That kind of thing probably _should_ be solved by an open-ended Keyword field. However, I think for the bulk of this stuff it would be good to start with what we have already in order to make the transition to search seamless :) Dylan [1] http://standards.freedesktop.org/menu-spec/latest/apa.html _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
