-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aaron(a)svn.wikimedia.org wrote:
> + # Check the text if not in rev_len for the entry's text size
> + if( !$size ) {
> + $text = $dbw->selectField( 'text', 'old_text', array('old_id' => $textId ) );
> + $size = $text ? strlen($text) : 'NULL';
> + }
This will give incorrect results for compressed text, external storage
entries, and batch compression entries.
You need to also fetch old_flags and run the row through the
Revision::getRevisionText() function to expand such rows.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGZrtvwRnhpk1wk44RAnznAKDHql/GH+4Dmy5JIIa0P6O4YqYxkACfc5t+
9JX6+zT/Q77ynoXUeAEjLec=
=v70C
-----END PGP SIGNATURE-----
Just thinking out loud here, but are we using our photographs in Commons to maximum advantage?
Reason I ask is that there is more and more geographic tagging of pictures starting to
happen (e.g. http://www.panoramio.com/ ). If we take a large repository of images
like Commons, and add geographic tags (long + lat) to those images (maybe with a bot
based on the that articles that include them, and that in turn have geographic tags included),
then you could very quickly build a very large and powerful repository of images, that are
tied to specific points on the globe .... which could be, y'know, be kinda cool, because
then you could potentially search for images on Commons based on location, and it could
come back with a whole list of images, in progressively increasing distance from the point
that you just specified.
So using London as an example, say you search for a point near Big Ben (by clicking on a
map or something), and you'd get back pictures of Big Ben, then the Houses of Parliament, and
the Thames River, then the London Eye, and so forth - so you would get an immersive image
search, perhaps in some ways more powerful than what we have currently.
But that's just half of it - because then you could do it the other way around
too, and you could add a geographic tag to articles, and then it could suggest some pictures
that you might want to add to your article, because they're close to the point you just
specified. And the best bit: No language or translation problems - because Longitude and
Latitude are universal, language-neutral things - so it would help _every_ Wikipedia.
Of course, to do this stuff, it would be nice to have some sort of structure to specifying
Long + Lat, possibly something more low-level than just a template, because you'd want it
to be readily and quickly searchable & indexable. And if you're going to do it for images,
maybe it should be done for articles too - that way you could say "find me other articles that
are about somewhere close to the article that I am currently looking at", and it could work
automatically, without having to manually add links. _Maybe_ you'd be looking at extra columns
in the database, which gets tricky, because it's extra baggage that might not relevant to
some wikis or some articles (although it is _very_ relevant to many articles in an encyclopedia,
in my opinion, and it's exceedingly relevant to images because every image was taken somewhere
on earth, or looking at something on earth, apart from the 0.0001% taken in space exploration).
This starts to get bogged down in some of the questions related to Semantic wikis, but I'm
thinking of something much simpler - longitude + latitude only.
Thoughts?
-- All the best,
Nick.
Hi all,
there will be a meeting to discuss audio/visual streaming/recording
during Wikimania, including about remote participation for those
unable to attend the conference - this meeting will be in irc.freenode
#wikimania @ 23:00 UTC Wednesday (which is Thursday, 7am, Taiwan
time).
Details at: http://wikimania2007.wikimedia.org/wiki/Audio/Video_Streams/Meeting
- please add ideas or suggestions - especially if you will not be able
to make the meeting. (Also, if the #wikimania IRC channel is
inconvenient, please suggest another.)
Cheers,
Cormac
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
I'm trying to understand Math.php to fix a bug, but I don't
understand why math_inputhash and math_outputhash are being
stored as binary values. It appears that Math.php is simply
coverting the original hex values to a binary upon store to
the database, and then doing the inverse when it is read back
out. What's the reason for this as opposed to simply storing
the hex values directly in the database?
- --
Greg Sabino Mullane greg(a)turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200706021603
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFGYc2GvJuQZxSWSsgRA3K5AJ91qQalP0PAdhhDDHMjyfa/vXDQewCfWJgG
wL0PJm0Pm16S1XBwLjj/mgU=
=0dIO
-----END PGP SIGNATURE-----
Well, no sysadmins have been found in the last two hours -- I suppose I'll
try posting here to see if someone comes across it.
We're having massive db lag on enwiki, including a lag on usercontributions
of several hours. At present, it appears that every server servicing enwiki
is down except for ariel. Tim mentioned something about botched code from
the last scap that killed samuel -- is this related to our current problems?
In any case, we need a server admin quite desperately, as enwiki is
teetering on death at the moment ...
--
Daniel Cannon (AmiDaniel)
http://amidaniel.com
cannon.danielc(a)gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A number of Apache, memcache, and external storage boxes went down a bit
ago, presumed due to a breaker flip or other power failure. As a result
we've temporarily put the site to read-only, since there's intermittent
failures and massive slowness.
They seem to be coming up now since we contacted the colo, and Rob's
going in now to do a final check on things.
Postmortem will come when we know more.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGY/1WwRnhpk1wk44RAvHTAKCUcRWnv8vdjNBawzrqblKoEcnECACgjpvy
ACOoy56dMzdepOj5zt4noeU=
=0yyo
-----END PGP SIGNATURE-----
