Re: [discovery] Language Detection Improvements! (preview)

atic data array, PHP file plus opcode cache is the fastest way I could find to get it. I imagine it holds for HHVM too, maybe even more so. So if we're porting it to PHP it'd make sense to make LM files PHP arrays. -- Stas Malyshev smalys...@wikimedia.org

[discovery] TextCat in PHP

welcome of course. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] Redirects not showing in search suggestions

e's exact match to what I typed it should win. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

[discovery] PrefixSearch/SearchEngine refactoring

() in SearchEngine is recommended instead. For now, these hooks will be supported by base SearchEngine implementation, but not by CirrusSearch. The task for this is https://phabricator.wikimedia.org/T121430, it also links the patches as they are now (still work in progress). -- Stas Malyshev smalys

Re: [discovery] Story point estimations

owned upon - which usually means converting to epic or something like that, for epic pretty it's ok to have a lot of points derived from subtasks. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://l

Re: [discovery] Completion suggester and pageviews

enwiki for 0 brings up a > disambig page with lots of reasonable candidate results. That may be a bug. I wonder if we don't have if ($search) somewhere that leads to it - since "0" is falsy in PHP, it may make it look like "". $a != "" would

Re: [discovery] Organisation of our work in the discovery team (mainly search)

note inside the task that it is waiting for being deployed, so nobody resolves it. Then when it's deployed it can be actually resolved. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia

Re: [discovery] [Wikimedia-l] USA elections in real time - as viewed by Wikipedia users

Hi! > We could add an extra attribute to the graph, e.g. > (number of minutes), to let graph extension update cache expiry. I think that'd be a nice addition. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list dis

Re: [discovery] New dashboard features released

t from Firefox 40 that they are essentially different browsers, but if not, it'd be nice to have this grouping maybe. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/li

[discovery] suggester mail for wikitech

Hi! I plan to send a note to wikitech about SearchEngine prefix completion refactoring we did for suggester recently. Here's how it would look like: https://www.mediawiki.org/wiki/User:Smalyshev_(WMF)/Suggester Please review and suggest fixes/additions. -- Stas Malyshev smalys...@wikimedia.org

Re: [discovery] [Ops] Wikidata Query Service (WQDS) regular deployment window

se add your window there. As I see you want a 7 hour window, >> overlapping with other windows shouldn't be a problem. But, if you ever >> plan to do work that might impact more than just your own systems, >> please do coordinate with me. >> >> Thanks, >> >> Greg >&

Re: [discovery] Data access guidelines released

Hi! > As my final hurrah, I've released the data access guidelines used by > the Discovery team in research and analysis on to Meta. It can be > found at https://meta.wikimedia.org/wiki/Discovery/Data_access_guidelines Thank you very much for getting this done! -- Stas Malysh

Re: [discovery] [Wikidata] Geospatial search for Wikidata Query Service is up

Hi! > Now impatiently waiting for AROUND implementation in wdq2sparql :-) That should work now too :) -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listi

Re: [discovery] Fwd: Request for code review and merge for wikimedia/search-repository-swift

ors are fine. -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] Terminology for search engine sidebars of Wikipedia content

Hi! > I would've called it search summary, but some people seem to use that to > refer to the snippets under the title/link for a result. DuckDuckGo calls it "instant answer". Not sure it's the best term out there, but that's what they call it. -- Stas Malyshev smalys.

Re: [discovery] Categorizing phab tickets

Hi! > Another option for personal categorization: 'flags' - it's the > phabricator equivalent of bookmarks. Flags are personal, not shared > publicly. > > A bit more info about flags is at https://phabricator.wikimedia.org/T102812 Thanks, I didn't even know it existed! --

Re: [discovery] Code review norms

of packages and see how it goes. I must note though that "Edit paths" interface is very hard to use - having one scroll box without search to locate a repo. I filed T140713 for it. Thanks, -- Stas Malyshev smalys...@wikimedia.org __

Re: [discovery] [Wiki-research-l] Looking for Wikipedia search queries

vel >> algorithms agains the currently used ones. Are there any query logs >> existing which I can use for this purpose? We do have query logs, but they are not publicly accessible for privacy reasons. You may want to check this out though: https://meta.wikimedia.org/wiki/Research:Unde

Re: [discovery] [Wiki-research-l] Looking for Wikipedia search queries

question of "where one can get logs of the search queries for public use" AFAIK is "there's no way to get it without signing papers and going through procedures". -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] [Announcement] Search improvements for file properties

, please feel welcome to share. [1] https://www.mediawiki.org/wiki/Help:CirrusSearch#filetype P.S. at least filetype:video and filetype:audio are intuitive :) -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@list

Re: [discovery] Another round of name that thing

Hi! > So, what do we call this thing? Horrible first attempts: > > * ltr-pipeline > * learn-to-rank-pipeline > * bob > * cirrussearch-ltr > * ??? rank forge? ML ranking? sorting hat? :) LTR is kind of confusing - for me it's the opposite of RTL which is handling Hebrew

Re: [discovery] Another round of name that thing

, my creativity is temporarily exhausted, but I may be back :) -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] Fwd: [Wikitech-l] Today's CREDIT demo - Wikidata Query Service update, including on federation

ant to do it for CREDIT. -- Stas Malyshev smalys...@wikimedia.org ___ Discovery mailing list Discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] [Wikitech-l] Search update: sister project snippets are now in production!

though :) -- Stas Malyshev smalys...@wikimedia.org ___ discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] AdvancedSearch beta feature available on all wikis

gories-rdf.dblist - we may consider adding more wikis to it. E.g. see: https://phabricator.wikimedia.org/T194139 So which wikis need to be added? -- Stas Malyshev smalys...@wikimedia.org ___ Discovery mailing list Discovery@lists.wikimedia.org

Re: [discovery] Hackathon ideas

actually want to do :) -- Stas Malyshev smalys...@wikimedia.org ___ Discovery mailing list Discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Re: [discovery] BlazeGraph + Elasticsearch?

ow > from OCLC, so if that's not possible, then, yeah, there's no point. Ah yes, you can combine! Just call Mediawiki API from inside SPRARQL query and combine with other clauses: https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual/MWAPI -- Stas Malyshev sm

Re: [discovery] BlazeGraph + Elasticsearch?

entially) I decided not to pursue this for now. We'd have basically to duplicate the work we've done in Mediawiki to compose proper Elastic queries, parse results, etc. and the best we'd have is the same thing we already have with Mediawiki API search. So I decided not to duplicate efforts f

Re: [discovery] Supporting researchers

esult, i.e. either open source code (with reusable license, i.e. no patents banning reuse etc.) or open publication with freely accessible algorithms and outcomes (or both?) I don't think it would make sense for us to cooperate if we'd be unable to benefit from the results. -- Stas Malyshev smaly