Commons-l March 2008

commons-l@lists.wikimedia.org

37 participants
32 discussions

Fwd: [Bug 1459] search for images/files by hash
by Brianna Laugher 19 Mar '08

19 Mar '08

For anyone who didn't know yet... Apparently there is a hash thingy in the API, but it doesn't seem to be documented. I am checking that out. cheers, Brianna ---------- Forwarded message ---------- From: bugzilla-daemon(a)mail.wikimedia.org <bugzilla-daemon(a)mail.wikimedia.org> Date: 19 Mar 2008 10:17 Subject: [Bug 1459] search for images/files by hash To: brianna.laugher(a)gmail.com https://bugzilla.wikimedia.org/show_bug.cgi?id=1459 --- Comment #4 from Brion Vibber <brion(a)wikimedia.org> 2008-03-18 23:17:21 UTC --- Note there is now a properly-indexed SHA-1 hash field on the image table in recent versions. I have the vague recollection that there's a way to do lookups by hash in the API, but not in the UI at present. Dupe file warnings are also not currently made. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are a voter for the bug. -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

2 1

Some cool new things
by Brianna Laugher 15 Mar '08

15 Mar '08

1) There is now a template {{published}}, which can be used on the talk page of Commons images that are used by third parties. This is neat. They will appear in [[Category:Commons as a media source]]. 2) Thanks mainly to Adam Cuerden we have a brand-new help page: <http://commons.wikimedia.org/wiki/Help:Scanning> 3) If you use the Konqueror browser and have some idea about how to track down JavaScript bugs, please contact Lupo <http://commons.wikimedia.org/wiki/User_talk:Lupo>. Your help is needed in testing the planned new upload form. For your interest there is a current screenshot here: <http://commons.wikimedia.org/wiki/Image:Commons_javascript_enhanced_upload_…> cheers, Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

4 4

For COA fans: Blazonry Server
by Brianna Laugher 15 Mar '08

15 Mar '08

Hi, This may be a useful site for people who create coats of arms. I don't know, maybe it is too simplistic? <http://web.meson.org/blazonserver/> You describe a COA using some restricted terminology (on that page) and then it generates an SVG of it. cheers, Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

2 1

Search plugins & thumbnails
by Brion Vibber 14 Mar '08

14 Mar '08

I finally got sick of bug 2815 (search results should show thumbnails), and added thumbnail display for image results in MediaWiki's core search results display. Rather than try to port it to the LuceneSearch plugin, I've started rolling out the MWSearch plugin on http://test.wikipedia.org and http://commons.wikimedia.org -- this uses MediaWiki's core search front-end together with our custom Lucene back-end. This is definitely an improvement for Commons, where search results are now beginning to be actually useful. ;) But there are definitely some UI elements we should improve on the core interface before rolling it out on other sites -- pretty it up a bit, include the search relevance results from Lucene, etc. Possibly additional thumbnails for pages that _contain_ images but are not themselves image pages. Some of this will need to be changed in Special:Search; some may need some tweaks to the SearchEngine base class and the MWSearch extension. -- brion vibber (brion @ wikimedia.org)

4 6

GFDL-1.2 only - deletion discussion
by Nilfanion 13 Mar '08

13 Mar '08

{{GFDL-1.2}} was nominated for deletion on the grounds it is not actually that free. I'm not trying to express an opinion on whether it is worth keeping or not, but feel that COM:DEL should not be used as the primary discussion venue for the validity of a template. I've closed the debate (though I may end up getting overturned), and moved the discussion to the (previously empty) talk page - http://commons.wikimedia.org/wiki/Template_talk:GFDL-1.2 This post is just to notify of the discussion and to see if this approach (establish validity and determine strategy on the template's talk as opposed to COM:DEL) is more appropriate than on a deletion discussion - which with high-use templates tends to generate badly.

5 12

Categories and the TOL
by Nilfanion 12 Mar '08

12 Mar '08

I hate to bring up what I know is a repeating drag on the project, but our most important sub-project (COM:TOL of course) advocates removal of content categorisation from useful imagery. I think this misrepresents the broader lack of consensus on the issue - nevermind that its contrary to what I think should be done. I'd like to see the project brought to heel and just use the usual "keep image in most precise category" methodology. The totally different method is harmful to the project (merely by being different) and by its existence is causing confusion at best (like what I'm reporting now) and downright antagonism at worst. In fact as far as I can tell *lots* of effort is being wasted by some users doing one thing (according to the TOL rule) and some doing the exact opposite. Is there any way we can get this mess over and done with?

8 11

Wikiwix image search
by Brianna Laugher 10 Mar '08

10 Mar '08

Wikiwix search engine now has an image search function. <http://www.wikiwix.com/?img=true&action=&lang=en> They wrote a bit about some special features it has on the VP <http://commons.wikimedia.org/wiki/Commons:Village_pump#Wikiwix_for_Commons> Give it a try, report if you find anything very useful or very broken. (Best to report on the VP I think) For my part, I find it much less useful than Mayflower because there's no metadata display, and also it seems to show lots of thumb results to images that don't actually exist. cheers Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

3 2

Re: [Commons-l] Category intersection: New extension available
by bawolff 10 Mar '08

10 Mar '08

> Message: 4 > Date: Thu, 6 Mar 2008 21:16:09 +0000 > From: "Magnus Manske" <magnusmanske(a)googlemail.com> > Subject: [Commons-l] Category intersection: New extension available > To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>, > "Wikimedia Commons Discussion List" <commons-l(a)lists.wikimedia.org> > Message-ID: > <fab0ecb70803061316x3963e31ag950b47803fe1864f(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > (cross-posting wikitech-l and commons-l) > > I created a new extension ("CategoryIntersection") that allows for > quick lookup of pages (and image) in intersecting categories. That > would enable wiki(m|p)edia sites to use categories as tags, > eliminating the need for oh-so-specialized categories. > > Intersection of two categories works very fast, but intersecting more > categories is possible, and already implemented; the maximum number > can be limited. > > I tried it on my (mostly empty) MediaWiki test setup, and it works > peachy. However, *I NEED HELP* with > * testing it on a large-scale installation > * integrating it with MediaWiki more tightly (database wrappers, caching, etc.) > * Brionizing the code, so it actually has a chance to be used on > Wikipedia and/or Commons > > > Techinical notes: > * This was recently discussed on wikitech-l > * More than two intersections are implemented by nesting subqueries > * Hash values are implemented as VARCHAR(32). Could easily switch to > INTEGER if desirable (less storage, faster lookup, but more false > positives) > * The hash values will only give good candidates (pages that *might* > intersect in these categories). The candidates have then to be checked > in a second run, which will have to be optimized; database people to > the front! > * Table to store hash values has to be created manually; SQL is in the main file > * I didn't implement code to fill the table for an existing > installation; however, since hash table updates solely hang on the > LinksUpdate hook, this should be easy > * There is no code covering page moves and deletions yet; do those > hang on LinksUpdate as well? > * SQL queries are currently "plain text" and not constructed through > the DB wrappers; I wan't sure how to do that for the subqueries > > Cheers, > Magnus You may want to spam the wikinews people about this. While I believe we're are fairly happy with DPL+toolserver thingys for all are category intersection needs, I'm not 100% sure what you're talking about , so someone on wikinews might be intrested in this. Cheers, bawolff

1 0

hola
by mario1519＠angel.ijv.sld.cu 08 Mar '08

08 Mar '08

hola como esta bueno queria consultarle...y ahora como puedo acceder a la pagina y que benificios tiene la dicha pagina? ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

4 5

Category intersection: New extension available
by Magnus Manske 08 Mar '08

08 Mar '08

(cross-posting wikitech-l and commons-l) I created a new extension ("CategoryIntersection") that allows for quick lookup of pages (and image) in intersecting categories. That would enable wiki(m|p)edia sites to use categories as tags, eliminating the need for oh-so-specialized categories. Intersection of two categories works very fast, but intersecting more categories is possible, and already implemented; the maximum number can be limited. I tried it on my (mostly empty) MediaWiki test setup, and it works peachy. However, *I NEED HELP* with * testing it on a large-scale installation * integrating it with MediaWiki more tightly (database wrappers, caching, etc.) * Brionizing the code, so it actually has a chance to be used on Wikipedia and/or Commons Techinical notes: * This was recently discussed on wikitech-l * More than two intersections are implemented by nesting subqueries * Hash values are implemented as VARCHAR(32). Could easily switch to INTEGER if desirable (less storage, faster lookup, but more false positives) * The hash values will only give good candidates (pages that *might* intersect in these categories). The candidates have then to be checked in a second run, which will have to be optimized; database people to the front! * Table to store hash values has to be created manually; SQL is in the main file * I didn't implement code to fill the table for an existing installation; however, since hash table updates solely hang on the LinksUpdate hook, this should be easy * There is no code covering page moves and deletions yet; do those hang on LinksUpdate as well? * SQL queries are currently "plain text" and not constructed through the DB wrappers; I wan't sure how to do that for the subqueries Cheers, Magnus

5 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Commons-l March 2008