-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Church wrote: Special:Export and Special:Import do not handle images at this time. There's some specs for it in the XML format but currently it's only used by the OAI feed system. - -- brion vibber (brion @ pobox.com)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Church wrote: That's pretty much how it would work if you implemented the spec. I stashed an example in docs/export-demo.xml: <page> <title>Image:Some image.jpg</title> [snip] <upload> <timestamp>2001-01-15T20:34:12Z</timestamp> <contributor><username>Foobar</username><id>42</id></contributor> <comment>My awesomeest image!</comment> <filename>Some_image.jpg</filename> <src>http://upload.wikimedia.org/commons/2/22/Some_image.jpg</src> <size>12345</size> </upload> </page> Probably not too hard to hack up, actually, if someone wants to give it a try. - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

On 18/12/06, Magnus Manske &lt;magnusmanske(a)googlemail.com&gt; wrote: No, I think it makes more sense if Special:Import handles the full, proper import itself. Rob Church

On 12/19/06, Mark Clements &lt;gmane(a)kennel17.co.uk&gt; wrote: OK. So, how do we handle the user ids from the other project? Do we assume single login is in place? Or do we create dummy users like "en:someguy", user_id=0? (I didn't bother to look how it's handled in Special:Import right now, easier to ask here;-) Also, if we plan to do mass-moving, of images, should we add this function to the api? What about handling the deletion of the images on the "source wiki"? If these functions were available using "name=xxx&password=yyy" on the api, it would save a lot of clicks with a decent front-end (which I then would volunteer to develop;-) A checkbox/option won't hurt. Except when people set up a wikipedia mirror and leech the images from wikimedia servers that way... Magnus

On 19/12/06, Magnus Manske &lt;magnusmanske(a)googlemail.com&gt; wrote: Put the username in image.img_user_text and set image.img_user to 0. The API is none of my business; I gather a separate group has taken the responsibility for designing and implementing it. Rob Church

In SpecialUserlogin.php, it looks like after $wgAuth->updateUser( $u ) is called $u->saveSettings() is not called. This is not the same behavior as before (in MediaWiki 1.6). Is this the correct behavior, or should I put this into the bugzilla? If this is the correct behavior, are plugin authors supposed to manually call saveSettings in updateUser(), but not in initUser()? V/r, Ryan Lane

On 12/19/06, Magnus Manske &lt;magnusmanske(a)googlemail.com&gt; wrote: These images need to be reviewed by a human.. many of them obtained a free tag through license roulette and are obvious violations to even the most cursory examination. A move to commons is a good time to perform such a check. This isn't an argument against the API allowing deletion, but just a factor pointing out that the dream of fully automated moves should never be made real. :)

"Magnus Manske" &lt;magnusmanske(a)googlemail.com&gt; wrote in message news:fab0ecb70612191032s4db8b922h4e121b4413b6c3ba@mail.gmail.com... wrote: a This is copy, is a Because you are changing the trust model. PersonA is an admin on WikiA and has been trusted enough to delete articles and to perform a transwiki import. WikiB has not made PersonA an admin - they (implicitly) do not trust PersonA to delete articles. However, PersonA is allowed to delete articles by using the transwiki import + delete. Admins at WikiA have full delete rights at WikiB, even if they are non-admins and explicitly blocked at WikiB! I understand that you qualified your statement with "If I'm an admin on that remote wiki...", but I don't see how that can be done without explicitly requiring a username/password each time a user wants to delete (plus, you are then giving your remote details to the local wiki sysadmin - an unscrupulous sysadmin or maybe even a badly behaved extension would be able to access these). - Mark Clements (HappyDog)

On 12/19/06, Bence Damokos &lt;bdamokos(a)gmail.com&gt; wrote: Exactly. You'll need upload rights at WikiB to upload/import there, and admin rights at WikiA to delete there. The only potential problem could be from an evil admin who deletes thousands of images through the api. But they'd all be recoverable (maybe through the api); also, we could limit the number/speed of api-based deletions. Magnus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Clements wrote: Yes. - -- brion vibber (brion @ pobox.com)

On 22/12/06, Mark Clements &lt;gmane(a)kennel17.co.uk&gt; wrote: [snip] The problem is that someone took the "let's support true image importing" ball and ran with it, off to the "ooh, let's enable moving" camp. I am of the opinion that while making the import process easier for Commons admins is going to end up being more or less essential, it is just as essential that a human has the final say over whether or not the image is deleted from the source wiki. There are cases where you wouldn't want to be performing a *move*, anyway; the import process as it stands implies copying, rather than moving, and that is I how I think it should remain. Rob Church

On 12/21/06, Mark Clements &lt;gmane(a)kennel17.co.uk&gt; wrote: I don't understand the difficulty. 1) You log in on Wiki A. Your username and password are the same as on Wiki B, since SUL is implemented, so no security breach occurs. 2) You say, through Wiki A's interface, that you would like to delete an image from Wiki B. Wiki A passes your username and password to Wiki B for authentication; since they're the same on both wikis, Wiki B will accept them and check if you're a sysop on Wiki B. 3) If you are, the image is deleted, and Wiki B tells Wiki A to acknowledge the deletion. Otherwise it tells Wiki A to return an error. There can't be any security breach if the two wikis share the same database for usernames and passwords (i.e., SUL). If they don't, this doesn't have to work, but if it did, you could directly (but invisibly) connect to Wiki A and give it your cookie if you're already logged in there.

On 12/22/06, christoph.huesler(a)css.ch &lt;christoph.huesler(a)css.ch&gt; wrote: Random wikis will not be able to delete anything from Wikipedia under this scheme. Only wikis linked to it through SUL would be able to. I should have thought that was obvious from my clearly-stated premises. I don't think allowing admins of Uncyclopedia (or any other random wiki) who are also Wikipedia admins to delete remotely from Wikipedia would be terribly useful. Allowing Commons/Wikipedia admins (or just Wikipedia admins who are autoconfirmed on Commons) to delete remotely from Wikipedia when moving to Commons would be, and that's what this feature is aimed at.

On 12/23/06, Mark Clements &lt;gmane(a)kennel17.co.uk&gt; wrote: The most obvious application (and probably the only significant application) of this feature (deleting the file from the source wiki) would be for transwikiing media to Commons from other Wikimedia projects. As such I think it would be safe to confine the feature to our specific conditions, which include a central location for media files, regardless of which wiki they are on (so requiring no moving of files), and in the near future SUL. -- Stephen Bain stephen.bain(a)gmail.com