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/
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/
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/
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)
{{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.
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?
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/
> 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
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.
(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
