Re: [Pywikipedia-l] UnicodeError: ASCII [decoding, encoding] error: ordinal not in range(128)

> textForm = """%(municName)s è un [[Comuni della Svezia|comune]]
> [[Svezia|svedese]] situato nella [[Contee della Svezia|contea]] di
> %(countyName)s."""

I suppose textForm needs to be u"""(...)""" then, but I am not completely
sure. And instead of using your own regexps to find templates and their
parameters, use page.templatesWithParams() and process that. I'm not
completely sure what you want to do though.

--valhallasw

(yes, again, reply instead of reply to all >_<)

Re: [Pywikipedia-l] UnicodeError: ASCII [decoding, encoding] error: ordinal not in range(128)

Please ignore my last mail. Has someone got some coffee for me? >_<

--valhallasw

Re: About publishing lists of deleted edits

I wonder whether it the replication of this data is made purposely
available to toolserver users. Deleted revisions should not be visible
to non-admins of a projects. Also, last time I checked, the table for
deleted images was not available. I think this 'd better be gone as
well.

Bryan

On 7/28/07, Daniel Bryant <dbwiki <at> gmail.com> wrote:
> Yes, I second Draicone, it should require an opt-in process
> of some description.
>
> On 7/28/07, draicone <at> gmail.com <draicone <at> gmail.com> wrote:
> > Any system like this should require opt-in. It isn't hard to code, and it
> avoids legal issues. Just require the user to make a dummy edit to their
> user page while logged in with a specific, self-explanatory edit summary,
> and check for it with the API, then maintain a database of verified users.
> Heck, we could even do this in a toolserver-wide process, with one opt-in
> system for all tools, and a centralised system with an API for checking if a
> user is verified.
> >
> > --
> > Draicone
> >
> > _______________________________________________
> > Toolserver-l mailing list
> > Toolserver-l <at> lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/toolserver-l
> >
> >

Re: new s1 server

River Tarnell:
> i have
> borrowed a Wikimedia server (vandale) to act as s1/enwiki server for the
> moment.  i am currently importing s1 there, so replication is halted.  i
> will restart it after this is done.

this is now done, and the new server is replicating.  i have changed
sql-s1 to point at the new server.

user databases are available, but you will need to create them yourself
(CREATE DATABASE u_whatever).  i'll put commons there a bit later.

	- river.

_______________________________________________
Toolserver-l mailing list
Toolserver-l <at> lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/toolserver-l

Re: new s1 server

River wrote:

> this is now done, and the new server is replicating.  i have changed
> sql-s1 to point at the new server.

Cool, thanks.

I have made available the toolserver db on vandale, using the same
view-of-federated-tables schema as on yarrow.

> user databases are available, but you will need to create them yourself
> (CREATE DATABASE u_whatever).  

err, normal users can create databases on vandale? really? oh... because they
have ALL PRIVILEGES for their db, before it exists? I didn't know that included
creation....

> i'll put commons there a bit later.

Yea, that would be good.

Thanks again
-- Daniel

filearchive table

Does anyone see a reason we can't add filearchive table to the public databases?

Filearchive lists deleted images.

If we suppress the following columns:
fa_size fa_width fa_height fa_metadata

                              fa_bits fa_media_type fa_major_mime
fa_minor_mime fa_description

the only piece of data it will disclose which isn't already public is
the cryptographic hash of the file content (fa_storage_key). This data
is already available through the UI to admins.

I'd like to put up a tool that lets users find deleted images by their
content hash. This would also require carrying an index on
fa_storage_key.  The tool would be used by the automated upload
scanning IRC bots to flag bit identical duplicates of previously
deleted uploads.

Re: filearchive table

Hello,

Am Samstag 04 August 2007 23:03 schrieb Gregory Maxwell:
> Does anyone see a reason we can't add filearchive table to the public
> databases?

I saw no one and created the views. The only field not visible by users is 
fa_description.

Perhaps a few fields in recentchanges were created too, if some databases 
didn't have they yet.

Sincerly,
DaB.

--

-- 
wp-blog.de

_______________________________________________
Toolserver-l mailing list
Toolserver-l <at> lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/toolserver-l

Re: filearchive table

On 8/4/07, DaB. <WP <at> daniel.baur4.info> wrote:
> I saw no one and created the views. The only field not visible by users is
> fa_description.

Fantastic. I already have a tool up using it, it's not user friendly..
it's really just a tool meant for other tools to use.

http://tools.wikimedia.de/~gmaxwell/cgi-bin/deletedimage.py?hash=f85b9e4a40434e664209f2a8e2ff106b4f636db8\&wiki=enwiki

hash= sha1 hash of the content of an image file. Wiki is a comma split
list of databases to check.

If a file with that hash has been previously deleted the tool will list it.

There is a IRC bot which uses this now. It is in both
#wikipedia-en-image-uploads and #wikimedia-commons-uploads2 which
watches new uploads and will alert if a file which is bit-identical to
a previously uploaded image is uploaded.

Its output looks like:

Aug 04 22:46:32 <wimb>  [[User:Bladez636]] {1255} uploaded
[[Image:Butters Fall.gif]] <50 × 50> <7 KB> (Tag {{PD-self}})  : This
i
s an Image of Butters falling from ''[[South Park]]'' this was edited
using several scenes from ''[[South Park]]''. This is a Free
 Image for me creating them. Copyright 1997 [[Trey Parker]] and [[Matt
Stone]]. Copyright 2007 Ian McCormick (created Image owns n
othing of ''[[South Park]]'')
Aug 04 22:46:32 <wimb>  [[Image:Butters Fall.gif]] has an identical

Re: filearchive table

Gregory Maxwell wrote:
> Fantastic. I already have a tool up using it, it's not user friendly..
> it's really just a tool meant for other tools to use.
> 
> http://tools.wikimedia.de/~gmaxwell/cgi-bin/deletedimage.py?hash=f85b9e4a40434e664209f2a8e2ff106b4f636db8\&wiki=enwiki
> 
> hash= sha1 hash of the content of an image file. Wiki is a comma split
> list of databases to check.

It gives a Content-Type: text/text; charset=UTF-8, which is not a valid 
MIME (Did you mean text/plain?)

Also, i'm being unable of getting an output from it :(
http://tools.wikimedia.de/~gmaxwell/cgi-bin/deletedimage.py?hash=0t8kj4820en59u9axvnb4eu90supe5jf\&wiki=commonswiki

Re: filearchive table

On 8/5/07, Platonides <platonides <at> gmail.com> wrote:
> It gives a Content-Type: text/text; charset=UTF-8, which is not a valid
> MIME (Did you mean text/plain?)

heh. Thanks. I'll fix that once eagle gets online and I can confirm
that the change won't break his tool.

> Also, i'm being unable of getting an output from it :(
>http://tools.wikimedia.de/~gmaxwell/cgi-bin/deletedimage.py?hash=0t8kj4820en59u9axvnb4eu90supe5jf\&wiki=commonswiki

It takes base-16 input. So you want:
http://tools.wikimedia.de/~gmaxwell/cgi-bin/deletedimage.py?hash=fa4d4ef5024534bc6ac146d480d9f27f19f0c48b&wiki=commonswiki
which is what you were trying to do, and it works fine.

Would base 36 input actually be useful to you? I could add a base 36
interface easily enough.

I made the interface base-16 because most SHA-1 APIs output base-16
and I was told that doing conversion is hard. ;)

I'm planning on adding the deletion reason and the image view URL (for
sysops) next.