Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Keywords" to "Fallback localization" #109

Open
humdingerb opened this issue Aug 15, 2016 · 6 comments
Open

Add "Keywords" to "Fallback localization" #109

humdingerb opened this issue Aug 15, 2016 · 6 comments

Comments

@humdingerb
Copy link
Sponsor Collaborator

Comma-separated keywords could help finding packages that don't have those keywords used in title, summary or description. Of course, HaikuDepot will have to be taught to look there as well.

@diversys
Copy link
Contributor

How about adding another field where admins can add supported MIME types to packages so that HD can query those? Tracker can launch HD when opening unsupported file with filters applied to list apps that can be used to open this format.

@humdingerb
Copy link
Sponsor Collaborator Author

I was thinking... Would it simplify things, if we just use a magic marker in the description field (and therefore "Fallback localization") like "%@Keywords@%", followed by a comma-separated list of keywords.

The HaikuDepot app then just has to ignore the whole line when outputting the description of a package. The listed keywords will still be found by the search function, but won't appear in the GUI.

@andponlin
Copy link
Collaborator

Hi Humdinger; something like this extra use of the field seem like an easy option, but will lead to a messy situation in the long term and can be time consuming to migrate out of. I would prefer to model the data properly in the database, query it in this way and relay the data back over to HD in a structured API. I'm currently working on other C++ side changes with a bug, but will try to come back to this after I have finished that.

In the meantime, can you let me know;

  • Do the keywords need localization?
  • Are the keywords a discrete set of values or can they be anything?
  • Case insensitive?
  • actual words or also phrases?

@humdingerb
Copy link
Sponsor Collaborator Author

You're right, parsing magic keywords is quite ugly...

Do the keywords need localization?

Yes. People will look for certain terms in their own language, if they run their system in their non-English locale.

Are the keywords a discrete set of values or can they be anything?

Can be anything. Any words associated with a package that isn't already in Summary/Description can be listed.

Case insensitive?

Yes.

actual words or also phrases?

Words should do. I imagine people normally enter the first word they associate with the app they're looking for, then enter additional words if the result list is too large and needs more trimming.

I was also wondering if it were possible to intruduce some "fuzzying", so if people look for "themes" they also get a result if there's only the singular "theme" in keywords/summary/description. I suppose this would need to be language-specific, though...
Definitely something that can come at a later stage if possible, I think...

@andponlin
Copy link
Collaborator

I think for fuzzing or stemming etc... a more modern version of Postgres database server may need to be used. Otherwise Elastic, but that will also take a while to sort out. I will take a look later on.

@humdingerb
Copy link
Sponsor Collaborator Author

No hurry. Plain keyword support alone would fantastic already. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants