Commons talk:Commonist/Archive 1

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Customization Question

I would like to use commonist to upload multiple pictures to a personal wiki. Since my wiki is my own, it doesn't show up on the list of servers for upload. How can I customize this part of the program? Thanks!

-penf0ld

Hi the relevant parts are in the mwapi plugin you can find the project definitions inside lib/mwapi-src.jar of the commonist package. Have a look at the sub directory source/net/psammead/mwapi/config and the various definition files in there (Families.bsh and the single project defintion files). I haven't played with them on my own so I can't give you further details. Simply have a look there and as they're beanshell text files I think after playing a little bit around with it you will be able modifying it in the way you like. Arnomane 19:13, 19 April 2006 (UTC)
have a look at the website, this changed a bit. support for new wikis can be added without altering mwapi.jar and there's no beanshell code involved any more. -- 84.153.77.157
I have a similar request. I want to upload images to fr.wikisource.org and it is not in the list. The file mentioned above doesn't exist in my version of Commonist I downloaded today (0.2.7). Yann 19:17, 6 August 2006 (UTC)
fr.wikisource.org is supported since version 0.2.8. -- 84.153.77.157


Nested licensing templates

I just learned (Commons:Help desk#New user feedback request (and questions)) that it's preferable to have the license template come after, rather than nested inside, {{information}}. The permissions field would have text only, according to the responses I'm receiving there. Would it be useful for me to try to submit a patch? -- JVinocur 12:36, 21 April 2006 (UTC)

Yes just go ahead sending a patch. I'm sure it will be appreciated. Arnomane 22:15, 21 April 2006 (UTC)
Okay, this turned out to be easy to fix, even though I don't quite understand what mixture of programming languages is even being used here! For comparison, look at the Permission fields:
And here's the patch: [elided, see old version of this page if necessary -- JVinocur 15:05, 25 April 2006 (UTC)]
-- JVinocur 03:30, 23 April 2006 (UTC)

Ookay for those of us that aren't even programming novices how do we get this into the version of commonist we are now using Gnangarra 04:52, 23 April 2006 (UTC)

Well, read at Wikipedia:diff and Wikipedia:patch (Unix). (Very briefly, start at a commandline and get yourself into the "script" subdirectory inside your commonist source tree, save the above into a text file called commonist-license.patch, and run the command patch < commonist-license.patch.) -- JVinocur 06:18, 23 April 2006 (UTC)

Resolution

A new version of commonist (site - download 0.1.18 - changes.txt) was released to fix this issue. Thanks to the author for being so quick.

Gnangarra, that should save you from having to learn how to apply patches...for now :-) -- JVinocur 15:05, 25 April 2006 (UTC)

Very nice. Thanks a lot for your improvement. :-) Arnomane 22:31, 25 April 2006 (UTC)

Feature request: info from EXIF tags

I just put a lot of effort into putting authorship & licensing info and extensive description into EXIF tags in files I want to upload. Now I'll have to put all the info again into Commonist fields for each image. There are free packages to read EXIF info, could you please add this feature? Helix84 14:00, 6 June 2006 (UTC)

Please email this idea directly to the Commonist programmer. I am just a user that wrote this tutorial here. ;-) Arnomane 15:38, 6 June 2006 (UTC)
OK, I did. ~~helix84 20:33, 6 June 2006 (UTC)

Automatic gallery

For every upload session the software automatic creates a gallery under a headline in the User:XXX/gallery directory. But I would like to be able to define what Commonist writes in these headlines and maybe disable the feature completely. --|EPO| 16:06, 10 September 2006 (UTC)

Yes, indeed a nice feature. I would like to go one step further and to be enabled to create a subpage on my like User:me/%mygalleryname%. --Wendelin 19:22, 10 September 2006 (UTC)

This feature is buggy, though. Templates should not be put included in the text box. Because of that, you cannot use any templates that contain categories (i. e. all "Creator:"-Templates), since your Gallery page then shows up in all these categories. I have to manually delete my gallery after every commonist upload because of that, which is a great nuisance. Personally, I would like to disable the feature altogether (no use IMHO, since we now have the toolserver tools). Any idea how to do this? --AndreasPraefcke 20:03, 9 April 2008 (UTC)

No security with java

I'm sure, that this program is sure, but my firewall sends warn messages if I use Java, 'cause other programs can cause damge on your system, Jlorenz1 12:38, 7 January 2007 (UTC)

Can't install Java 1.5

Other programmes on this machine require JSEE 1.4. Is there any way to get an older version to work? --Flominator 14:59, 23 May 2007 (UTC)

Commonist does not work

Commonist does not work anymore (can't log in). Is that connected to the captcha forms that Common uses? --AndreasPraefcke 10:49, 18 June 2007 (UTC)

Works for me since a couple of weeks. (novice user, worked first time right (I was amazed)) --Foroa 13:11, 4 July 2007 (UTC)

Miraculously (or not: i finally was able to download the long-broken latest zip archive and re-install), it works again. Thanks to everybody who tried to help. --AndreasPraefcke 11:04, 6 July 2007 (UTC)

redirect problem

when uploading files to my local wiki installation (german) i get the following output in the commandline-window.


INFO: Redirect requested but followRedirects is disabled
debug   net.psammead.mwapi.MediaWiki    HTTP POST http://localhost/wiki/index.php HTTP/1.1 301 Moved Permanently
error   net.psammead.commonist.task.UploadFilesTask     upload failed: Amethyst.jpg
net.psammead.mwapi.UnexpectedAnswerException: unexpected response data (SimpleAction)
status  HTTP/1.1 301 Moved Permanently

file-pages are created,but no files uploaded. what is the problem here?

--FLAIMO 2007-07-09 The preceding incompletely signed comment was added by Flaimo (talk • contribs) at 13:15, 9 July 2007 (UTC)

You probably have to enable "followRedirects", but I don't know how do do that. Please try contacting the author via Commons:Tools/Commonist#Bugs and feedback.   — Jeff G. (talk|contribs) 00:08, 11 July 2007 (UTC)

So how does this work

I unpacked it, I have Java installed. Where the heck is the program? It won't start, there doesn't appear to be an obvious icon to click to start it, it doesn't appear to function at all. Can anyone tell me what I did wrong. I try to open the file titled commonist (which my computer doesn't register as a recognized file type) and it does nothing, asks me what to open it with, I say Java and nothing happens. What do I do? IvoShandor 20:01, 26 August 2007 (UTC)

Never mind, I will just try the other program. IvoShandor 20:05, 26 August 2007 (UTC)
This is explained at the fourth point at Installation:
  • On Unix/Linux/Mac-OSX you can run Commonist by executing bin/commonist below the commonist-x.x.x directory, on Windows start it with bin\commonist.bat below the commonist-x.x.x directory.
--|EPO| da: 07:59, 27 August 2007 (UTC)

Upload problem

I have had some problems uploading photos since yesterday. The last photo I successfully uploaded was 2 days ago. I have since been getting these errors. On the hardware end, I am using the exact same computer with no new hardware or software installed, but I am located at a different physical location and am therefore hooked onto a different wireless network. I don't see how that would affect anything, though. I went to try to upload manually but noticed that my preferred license (CC-BY-SA-2.5) no longer exists all its own -- they all require GFDL, which I do not necessarily favor (it's too wordy and not as user-friendly as CC). Is that the problem, or can anyone identify another possible cause for my errors? Thanks! --Bossi (talkgallerycontrib) 16:35, 8 September 2007 (UTC)

Have you tried {{self2|GFDL|cc-by-sa-2.5,2.0,1.0}} and the latest version?   — Jeff G. (talk|contribs) 06:12, 10 September 2007 (UTC)
I run it via webstart and prefer not to use GFDL. Has anything on Wikimedia's end changed recently over the last couple days that would require GFDL? --Bossi (talkgallerycontrib) 02:21, 11 September 2007 (UTC)
Also, no luck trying out GFDL w/ cc-by-sa-2.5,2.0,1.0. --Bossi (talkgallerycontrib) 02:32, 11 September 2007 (UTC)
It looks like the Filename Prefix Blacklist may be the culprit, per my post in the Village Pump. Can Commonist find a way to bypass the warning message? --Bossi (talkgallerycontrib) 00:44, 14 September 2007 (UTC)
I am having the exact same problem, i was uploading 37 files last week and it only uploaded 14 of them, since then, i have not been able to upload anymore files. I have not touched anything of my system's configuration or anything. I have upgraded to the latest version of commonist available 0.3.15 and it keeps telling me that uploading a file with this name is forbidden, while if i upload it manually its ok. ¿any ideas? Thanks for your help.-rafax 13:10, 7 November 2007 (UTC)

Adding your own site

Here are the confusing original directions at: http://www.djini.de/software/commonist/


adding a wiki
this works with the webstart version and the zipfile version.
unpack lib/mwapi.jar from the unpacked binary zip into a new directory
look for commons.family and commons.site in this directory
create a directory $HOME/.commonist/family
copy commons.family to $HOME/.commonist/family/NAME.family
copy commons.site to $HOME/.commonist/family/NAME.site
adapt these two files.


Here are my instructions which at this point are probably very wrong, but are a little easier to understand than the insturctions above. With a little help, we can rewrite these directions for everyone to understand.

FIRST Find the file: mwapi.jar located in the folder lib (bin/lib/mwapi.jar)

SECOND

Unpack this file using winrar or winzip, into a new folder

THIRD

In these new unpacked folders (org, net, META-INF), search for:
commons.family
and
commons.site

FOURTH

Create a new folder in your commonist folder called "family"
FIFTH copy commons.family to your new family folder
copy commons.site to your new family folder
SIXTH "adapt these two files." <<< ??? HOW ?????

I changed the name of the files, and also replaced the word "common" with my site name. what next?


Example of what I did:

commons.site to newwebsite.site
and
commons.family to newwebsite.family

It simply doesnt work. Nothing new shows up on the list of sites which you can upload too.

According to this listserv:

commonist and can be used to mass upload files into a wiki application. It took me a while to get it running because you need a special editor (like vi) on Windows systems to edit the .family and .site files.

True?

Text of commons.sites:

## configuration for a single wiki site

# identification
family	commons

# network
protocol	http://
hostName	commons.wikimedia.org
rawPath	/w/index.php
prettyPath	/wiki/
apiPath	/w/api.php

# config
charSet	UTF-8
titleCase	first-letter
uselang	nds

# nameSpaces
nameSpace	-2	'Media'
nameSpace	-1	'Special'
nameSpace	0	''
nameSpace	1	'Talk'
nameSpace	2	'User'
nameSpace	3	'User talk'
nameSpace	4	'Commons'
nameSpace	5	'Commons talk'
nameSpace	6	'Image'
nameSpace	7	'Image talk'
nameSpace	8	'MediaWiki'
nameSpace	9	'MediaWiki talk'
nameSpace	10	'Template'
nameSpace	11	'Template talk'
nameSpace	12	'Help'
nameSpace	13	'Help talk'
nameSpace	14	'Category'
nameSpace	15	'Category talk'
nameSpace	100	'Creator'
nameSpace	101	'Creator talk'

# specialPages
specialPage	'Blockip'	'Blockip'
specialPage	'Filepath'	'Filepath'
specialPage	'Movepage'	'Movepage'
specialPage	'Upload'	'Upload'
specialPage	'Userlogin'	'Userlogin'
specialPage	'Userlogout'	'Userlogout'

# messages
message	addedwatch	'To de Oppasslist toföögt'
message	badfilename	'De Bildnaam is na „$1“ ännert worrn.'
message	cannotdelete	'De Software kunn de angevene Siet nich wegsmieten. (Mööglicherwies is de al vun en annern wegsmeten worrn.)'
message	confirmrecreate	'De Bruker [[{{NS:2}}:$1|$1]] ([[{{NS:3}}:$1|talk]]) hett disse Siet wegsmeten, nadem du dat Ännern anfungen hest. He hett as Grund schreven:\n: \'\'$2\'\'\nWist du de Siet würklich nee anleggen?'
message	delete_and_move_text	'==Deletion required==\n\nThe destination article "[[$1]]" already exists. Do you want to delete it to make way for the move?'
message	fileexists	'En Datei mit dissen Naam existeert al, prööv $1, wenn du di nich seker büst of du dat ännern wullst.'
message	filetype-badmime	'Datein vun den MIME-Typ „$1“ dröfft nich hoochlaadt warrn.'
message	filetype-badtype	'\'\'\'".$1"\'\'\' is an unwanted file type\n: List of allowed file types: $2'
message	filetype-missing	'The file has no extension (like ".jpg").'
message	filewasdeleted	'A file of this name has been previously uploaded and subsequently deleted. You should check the $1 before proceeding to upload it again.'
message	large-file	'It is recommended that files are no larger than $1; this file is $2.'
message	largefileserver	'This file is bigger than the server is configured to allow.'
message	loginsuccess	'Du büst nu as „$1“ bi {{SITENAME}} anmellt.'
message	logouttext	'Du büst nu afmellt. Du kannst {{SITENAME}} nu anonym wiederbruken oder di ünner en annern Brukernaam wedder anmellen.'
message	nosuchuser	'De Brukernaam „$1“ existeert nich.\nPrööv de Schrievwies oder mell di as niegen Bruker an.'
message	removedwatch	'De Siet is nich mehr op de Oppasslist'
message	spamprotectionmatch	'Dit Text hett den Spamschild utlöst: $1'
message	successfulupload	'Datei hoochladen hett Spood'
message	talkexists	'Dat Schuven vun de Siet sülvst hett Spood, aver dat Schuven vun de\nDiskuschoonssiet nich, vun wegen dat dor al en Siet mit dissen Titel existeert. De Inholt muss vun Hand anpasst warrn.'
message	talkpagemoved	'De Diskuschoonssiet is ok schuven worrn.'
message	talkpagenotmoved	'De Diskuschoonssiet is <strong>nich</strong> schuven worrn.'
message	uploadcorrupt	'De Datei is korrupt oder hett en falsch Ennen. Datei pröven un nieg hoochladen.'
message	uploaddisabled	'Dat Hoochladen is deaktiveert.'
message	uploadnologintext	'Du musst [[Special:Userlogin|anmellt wesen]], dat du Datein hoochladen kannst.'
message	uploadscripted	'In disse Datei steiht HTML- oder Skriptkood in, de vun welk Browsers verkehrt dorstellt oder utföhrt warrn kann.'
message	uploadvirus	'In de Datei stickt en Virus! Mehr: $1'
message	wrongpassword	'Dat Passwoort, wat du ingeven hest, is verkehrt. Kannst dat aver noch wedder versöken.'

text of commons.family

## configuration for a whole wiki family

# identification
name	commons
shortcut	c

# languages
multilingual	false

So far, is this correct? thanks 68.90.182.17 22:05, 21 September 2007 (UTC)

Thanks you helped me, but there are some steps you got wrong. I've been able to refine it and I posted my experiences here Commons:Tools/Commonist/Other_Wikis. --Michael180 16:06, 21 January 2008 (UTC)

Geocoding

I have been asking the Geocoding crowd, on an acceptable way of using Commonist to upload images with location information. The discussion is here : Commons talk:Geocoding. ClemRutter 21:29, 24 September 2007 (UTC)

I just started tagging my photos with geocoding -- I stick the template into the description area. It's a tad messy, but I figure that someday a bot will come by and fix it (all hail bots!). It would definitely be handy to have a field where we could enter in coordinates, but there are just so many different formats out there: there'd have to be some coordination of some sort to find formats that could translate easily into Commonist. For example, would the input field understand template brackets {{}}, or would I have to manually enter in every coordinate number? Commonist would have to make sure that more work doesn't become necessary. --Bossi (talkgallerycontrib) 22:53, 24 September 2007 (UTC)
I am doing the same. I have one window open with Google Earth and another with commonist. I cut and paste a {{location dec|lat|long}} fom one description to the next, then check the new coord on GE, and edit it in. Oh for a control key or a right click in commonist that would insert the location template tag. Oh for a control key or a right click in Google that would save the coordinate to the clipboard in Commonist format/. ClemRutter 13:47, 27 September 2007 (UTC)
Get the placemark mentioned here -- sounds like it'll help cut down your alt-tabbing. --Bossi (talkgallerycontrib) 21:29, 27 September 2007 (UTC)

Login problems

I cannot get to Commonist to log in anymore, this despite having no problems logging in manually. Any ideas what the deal is here? IvoShandor 21:07, 5 November 2007 (UTC)

It didn't like me, because of router for some reason, All fixed. IvoShandor 21:08, 5 November 2007 (UTC)

Uploads from catalogues or museum visits

I often upload images from museum catalogues or pictures taken at the museum itself. This creates the problem, that each individual image has an individual author, was created at a different date and has, in addition to the common source, i.e. the book I scanned from, or the museum I visited, individual source informations, i.e. the place where the picture scanned usually hangs. So therefore it would come handy if the information "source", "date", "author" could also be repeated in the individual image block. Also is it possible to copy and paste when working within the commonist frame? --Wuselig 09:38, 26 November 2007 (UTC)

In response to your last sentence: with Windows you can use CTRL-C and CTRL-V to copy/paste; and CTRL-X to cut. --Bossi (talkgallerycontrib) 23:37, 26 November 2007 (UTC)
Thanks. I thougt it was CTRL-C and CTRL-P. So naturally it wouldn't work. Let's hope somebody comes up with just as easy an answer for the first sentences. --Wuselig 23:55, 26 November 2007 (UTC)
Your first question- the answer is no. But there are ways to make life easier. I have a text file called "Scraps". It has an icon at the bottom right of my desktop- so it is always there. Click the icon and Wordpad or Notepad or TextEdit opens the file. When I am working I Copy text from Commonist (or any program) and paste it to "Scraps" (de:Stückchen), so that when I have entered a Museum Name, or a Artists name in the common area- I cut and paste it to 'scraps' and I can use it later that night, or next week or next year. This saves a lot of typing- as all your regular sources- etc are reusable.
Another tip is that CTRL-Z is the undo key and Ctrl-Y is the redo key.
Ahh yes, I do that same thing... hoorah for Notepad! :) --Bossi (talkgallerycontrib) 01:59, 27 November 2007 (UTC)

Thank you. Now that copy and paste is no problem anymore I will test this with the next upload. --Wuselig 08:17, 28 November 2007 (UTC)

Feature Request:Stamping

I would like a button, that would take all the text I have typed, and stamp it into a textfile on the local disk. The reasons being:

  • gives me a index of my photo collection in a format I understand
  • Commonist could be used offline for adding metadata to my photo collection
  • when Microsoft 'helpfully' installs a security update at 4 in the morning and restarts my machine, I can recover the Commonist session that I was working on, and had left open.

This also implies having button called restore. Data format should be csv, and the save process will save first generic details(left data)-blank field for other fields(right data). Then all the photos would be processed. Selected photos would aggregate Leftdata with rightdate and write both. Unselected photos would just write right-data. Saves would be data time stamped, so wouldn't overwrite each other. Recovers would give file choice using a combobox select in reverse date order. I can also imagine the addition of a print button, but am unsure of the format of the output. This would take the csv file and convert it to paper for those of us, who use the stuff. ClemRutter 14:16, 21 December 2007 (UTC)tweaked ClemRutter


I wouldn't mind it for all the times I mis-click onto that happy little "X" at the top right of the window. Another aid may be to issue a prompt when you click on the X whilst text is entered into the individual image boxes. The prompt could basically be just "Are you sure you wish to quit?" --Bossi (talkgallerycontrib) 03:16, 22 December 2007 (UTC)
I am still hoping.ClemRutter 10:41, 20 February 2008 (UTC)
Yes still.--ClemRutter (talk) 15:10, 23 March 2009 (UTC)

Could not login to commons

I just spent the last couple of hours installing, learning about this program and entering all of the requested information for 16 pictures. When I click the Upload button, I get "could not login to commons". I'm able to login just fine to the website, so I know I'm using the correct user and password. I'm not behind a proxy. Could it be because this is a new account? I just signed up at Commons a couple of days ago. Any suggestions? I really hate to lose all this work I did. Sanfranman59 08:47, 20 February 2008 (UTC)

Copy and paste the metadata to a textfile ( a pain- I know ) and try again with one picture on another machine. It should work eventually. ClemRutter 10:45, 20 February 2008 (UTC)
Thanks for the reply. I left Commonist running on my system last night and tried uploading again this morning. This time it worked but it had the message "could not update gallery (store secondy [sic] try not successfulstatusHTTP/1.0 200 OK)". I have no idea what that message means but my photos are out there. What does the message mean? Is it common for it not to be able to connect? Sanfranman59 16:47, 20 February 2008 (UTC)
I am not an expert on the servers that commons use, but I have seen several warnings and error messages so I am building up a mental model of what may be happening. Imagine that you have 20 servers- with many disks holding the images- one holding details of users- and one holding indexes (indices) and the tags etc. One server's data will be duplicated on other servers. If one drive goes down, the system switches in another drive, rescuing what it can. This takes time and a backlog builds up. You tried to log in, the user database server was failing to cope- so it ignored you. First error message. When it had handled the backlog- it saw you and logged you in. But the server holding your gallery hadn't caught up so it didn'r update your gallery- throwing an error message- it tried a second time throwing error message- another server confirmed that it had successfully received the error message using the HTTP protocol ie Code 200. So we have two servers talking to each other. I would be very surprised if this explanation is vaguely accurate but it does convey a vague idea of the complexity of server network- and as I said yesterday It should work eventually! Commonist is addictive; uploading is speeded up 10 fold.ClemRutter 01:34, 21 February 2008 (UTC)
Sorry if this sounds like a typical response from tech support, but I can't begin to say how many times I overlook the obvious: make sure you are entering your account password before clicking on the upload button. Next, turn off torrents or any other bandwidth-hungry applications. Commonist seems pretty touchy about having all the bandwidth for itself. --Bossi (talkgallerycontrib) 05:26, 21 February 2008 (UTC)

Ignore warnings

Can we get an option to ignore warnings during upload? I just got a 12 MP camera and a the photos skirt around 5 MB, which is where the warning begins for file sizes. The warning fails my uploads through Commonist, so it'd be nice if Commonist could automatically ignore warnings. --Bossi (talkgallerycontrib) 06:32, 23 March 2008 (UTC)

Can't login to commons

Can't login due to the following issue: net.psammead.mwapi.ui.UnexpectedAnswerException: unexpected response data (UiSimpleActionBase). I'm sure it's not a CAPTCHA problem. Any ideas? Ilya Voyager 12:29, 8 April 2008 (UTC)

Try restarting the program. I've found that I can upload just once and then I have to reopen it. Yes, it's very annoying and it's only started doing this within the past week or so... all I can offer is this short-term fix; I'd dearly love for someone to figure out what broke. --Bossi (talkgallerycontrib) 23:01, 10 April 2008 (UTC)

Exactly the same problem here. The first batch works ok, after that you get the error message mentioned above. Closing and restarting works, but nothing else. --AndreasPraefcke 08:50, 11 April 2008 (UTC)

Same here. I already emailed the author. --Flominator 05:44, 21 April 2008 (UTC)
Very annoying problem, since restart deletes all entries made under the specific images. So I learned the hard way not to do multiple batches at the moment. --Wuselig 07:23, 21 April 2008 (UTC)
Whenever I forget about this, I open a second Commonist while my first one is still open. I resize them so I have both windows beside each other, then I just cut/paste from the first to the second. I'll post this in the Village Pump to see if any of them recognise what might be happening... I don't think anyone's changed anything with Commonist; rather I think it might have been something that changed with Wikimedia itself. --Bossi (talkgallerycontrib) 11:35, 21 April 2008 (UTC)
I agree with the last assumption that it is a Wikipediaproblem. When I try to safe changes in Wikipedia in 2/3 of the time I get an error warning that changes can't be made at the moment, because the servers have to match up, or something to this respect. Than you have to hit your browser back button and hope your changes are still there to be able to try to safe anew. I have resorted to copy my changes into the temporary memory as in copy and paste in order to be able to paste should the change get lost. As Thisisboss pointed out, such an all over copy paste isn't possible with commonist. You have to do this with the entry of each single image. I hope they get this server problem fixed fast.--Wuselig 12:35, 21 April 2008 (UTC)

Commonist forces UI language of Mediawiki to nds (Plattdüütsch), as you can see in file commons.site at preference "uselang nds". Messages in the file are in this language also. Commonist uses the messages to recognize success of actual action. And there is the problem. First login page is correctly in desired language. But second attempt to log in is proceed in situation, when user is already logged in! Therefore second login page is returned in language determined by user's preferences. And Commonist is not able to handle pages in such language.

Workaround: When commonist fails to login, don't restart him. Set language in preferences of your commons account to nds (Plattdüütsch). Start again the upload at commonist. --RuM 00:35, 25 April 2008 (UTC)

I am no programming nerd and what you say may be a way to get around the problem for all users. But I believe most users here will agree that nds (Plattdüütsch) is not the most commonly used prefered language around here. So I think it will be eassier to solve the problem by choosing a more widely used language (hey, how about English?) in the Commonist code. Your approach seems to be the usual way of programmers to solve bugs: Don't solve the problem, but find an add-on to get around the problem. Which of course creates new problems which again will have to be circumnavigated. Do I have to go on? --Wuselig 07:25, 25 April 2008 (UTC)
As I said, it is only workaround, temporary fix, not a real one. It can only help people to bypass the problem and continue actual uploading (user can change language to nds and change it back after the upload). I agree, that more serious solution is needed, but I am not a programmer of Commonist nor Mediawiki so I cannot do much more. --RuM 13:28, 25 April 2008 (UTC)
Platdüütsch od Plätdenglisch- the problem is worse now. I cannot login at all.ClemRutter 23:20, 25 April 2008 (UTC)

the commonist adds a uselang=nds-parameter for all requests so it can parse the resulting HTML. this is broken since [1] because the page returned after logging in now is displayed in the default language of the user and the uselang-parameter is ignored. -- 84.152.119.35 23:48, 26 April 2008 (UTC)

this should work again with [2] active. -- 84.152.123.158 14:26, 27 April 2008 (UTC)

Well. I can now do an initial login- but not a repeat login. ClemRutter 15:11, 27 April 2008 (UTC)

@RuM: thank you very much, the workaround does work perfectly for me. It's even kind of fun to have that user interface... Has anyone opened a bug report for this (IMHO wrong) behaviour of the Commons to overwrite the language requested in the login dialogue? I'd like to vote for it to have it fixed ASAP. --AndreasPraefcke 19:49, 29 April 2008 (UTC)

SUL issue and solution

Don't know if I'm unique on this but Commonist and the Single-User-Login have a slight issue.
Login to wikipedia -> open commons (SUL has me logged in here now) -> run commonist -> uploads fail as I'm not logged into commons. The solution is to logout and back in on commons the rerun commonist. Just information for anyone else who runs into the same problem - Peripitus 11:16, 1 June 2008 (UTC)

Same here. Commonist seems to upload, but the file is not on the Commons afterwards. Only if I logout and login on Commons, Commonist seems to work ok (in the nds-language version). It's about time we find some other way to upload multiple files, since Commonist doesn't work more often than it does. --AndreasPraefcke 10:19, 2 June 2008 (UTC)

Just checked again - this is not a commonist error but a mediawiki error. Tried the same steps but using the "Upload file" link....end up logging me out and uploading does not work - Peripitus 13:20, 2 June 2008 (UTC)

Well, the Commonist part of the error is that Commonist does not notice that nothing has been uploaded at all. --AndreasPraefcke 16:52, 2 June 2008 (UTC)
i'll look into this. in the mean time, please vote for bug 14210 and then press the devs to add file upload to the API. without a machine friendly interface it's quite difficult for any upload tool to work reliably without constantly fixing problems. btw, is the login-bug mentioned above already fixed or do you still need to change your language to nds to login a second time? -- (talk) 03:09, 15 June 2008 (UTC)

Yet another login problem

Once again, there's a problem with logging into Commons using this. I type in the password correctly, but I get "could not log into commons." I try logging into Commons manually, that works fine, but I think this may have to do with the fact you need to look at and type what's in a picture. Anyone have a workaround this? ——Mr. Matté'pedia talk 16:41, 15 June 2008 (UTC)

this should work now, even for multiple consecutive uploads. -- 84.152.58.226

Please, do not use the date of my computer for uploadet gallerys

I try some progs... ;-P --84.141.221.42 00:16, 25 July 2008 (UTC)

Documentation edit

I have done a heavy edit of the project page, trying to simplify the English so it is clear and not ambiguous. I hope I haven't offended. After months of use, I finally discovered that you can and are encouraged to rename files, a task I had always done using a third party program. I had missed the description totally. So I set about rewriting it. The previous writing style was elegant but with commas and stripping out modal constructions and conditionals it is now shorter and easier to understand. Further simplifications are still possible.ClemRutter (talk) 00:11, 4 November 2008 (UTC)

Use Commonist on arwikisource

Hi. I would like to use Commonist on AR wikisource but it is not included in the drop list, what should i do? please give me a hint. --Ciphers (talk) 15:17, 20 February 2009 (UTC)


Use Commonist on localhost

Hello, I need help, don't get commonist working for for my localhost MyWiki. More here: Commons_talk:Tools/Commonist/Other_Wikis--WikipediaMaster (talk) 10:27, 24 May 2009 (UTC)

Please update

Very helpful tool but can you add the license option {{self|GFDL|cc-by-sa-3.0}}?--Tlrmq (talk) 20:36, 16 August 2009 (UTC)

Hi, it's very easy to do that by yourself: you just have to add this template to commonist-0.3.40/etc/licenses.txt (just copy/paste another line and make the change you wish). Hope this helps. Peter17 (talk) 16:36, 28 August 2009 (UTC)

Overwriting

Does this tool allow overwriting/updating of previously uploaded images? I keep getting an error when I try..see User:Smallman12q/gallery.Smallman12q (talk) 22:42, 2 September 2009 (UTC)

Is it broken?

I have a tone of images to upload with Commonist, but uploading function on Commons seemed broken yesterday, and Commonist does not currently work. --Caspian blue 15:35, 17 September 2009 (UTC)

UnexpectedAnswerException unexpected response data

Using latest version, got this: UnexpectedAnswerException unexpected response data (UiSimpleActionBase) status HTTP/1.0 200 OK. Look here for details.--Kozuch (talk) 16:07, 17 September 2009 (UTC)

Here the Same. Willow (talk) 17:33, 17 September 2009 (UTC)

Does anyone have a link to older version of program (0.3.40 or older)? I suspect this problem came with the new version???--Kozuch (talk) 20:16, 17 September 2009 (UTC)

Does not work with 0.3.28 either. Something seems broken. --89.244.184.237 08:48, 18 September 2009 (UTC)

Wikimedia rolled some updates to all sites just about two days ago, that might be the problem.--Kozuch (talk) 15:33, 18 September 2009 (UTC)
I have 0.3.32, and that also doesn't work today, but did before. It's not a Commonist problem. There is something going on with uploading at the moment. Reuploading files is also broken at present. Inductiveload (talk) 22:24, 20 September 2009 (UTC)

I have been experiencing the same problems for days already. It would be nice to get some feedback here from the side of the developers if the problem is beeing looked at and if a solution is in sight. Or if there is an alternative for mass-uploads to Commonist that we should be looking into. --Rainer Halama (talk) 21:43, 21 September 2009 (UTC)

Is there anyone to inform? Have they been informed?--JIrate (talk) 11:27, 22 September 2009 (UTC)
Brion is informed [3]. He is the right person for server side problems. The developer of commonist seems difficult to contact. --Kolossos (talk) 17:26, 22 September 2009 (UTC)
Seems to be fixed.--JIrate (talk) 13:10, 23 September 2009 (UTC)
Yes it is fixed, and I like to thank everybody that helped to get the job done. --Wuselig (talk) 07:09, 24 September 2009 (UTC)
No, for me. I have this message «UnexpectedAnswerException unexpected response data (UiSimpleActionBase) status HTTP/1.0 200 OK » and «could not log from Commons ». Vi..Cult... (talk) 09:54, 25 September 2009 (UTC)

localization

A Bot is going through changing the files that I have uploaded via commonist, as far as I can tell to conform to the latest standard. Is any update likely? Here is the bots msg. (BOT - Changes to allow localization: Licensing: → Licensing:; Summary → Summary;) Also is there any chance of a save function so that I can save half way through setting up a batch? --JIrate (talk) 18:59, 1 October 2009 (UTC)

"Uploaded with Commonist" category or Commonist template

Hey there, seems like we need to promote this tool still - seems like people still dont know about it (see this for example). It would be nice if someone comes accross a photo uploaded by Commonist that he/she could see it was uploaded with the tool - this would help a lot IMO.--Kozuch (talk) 10:36, 28 October 2009 (UTC)

Well, I did create a cat: Category:Uploaded with Commonist. Could the cat be added as a default category for all uploads???--Kozuch (talk) 10:45, 28 October 2009 (UTC)

I'm not sure that this is really useful. Our description pages are full with babels and the category will be so huge that nobody can use it. I would prefer a babel for my user-page: "This user use Commonist for upload." --Kolossos (talk) 18:08, 31 October 2009 (UTC)

Full ack. --Flominator (talk) 16:20, 2 November 2009 (UTC)
How about a link to the tool on the Commons:Upload page? I still think the tool needs to improve its usability (easier installation). mahanga (talk) 03:57, 3 November 2009 (UTC)
You dont need to install it, just run it remotely (link provided on project page). Regarding category, it is not as important as a template {{Commonist}} that I created. Regarding the Upload page, I made a request here already.--Kozuch (talk) 07:07, 3 November 2009 (UTC)

Could not update gallery

I just uploaded File:Phila frankford00.png with Commonist, and I received a message that Commonist "could not update gallery (cannot use template:jar... etc.).

Can someone tell me what I did wrong?--Davidt8 (talk) 18:26, 4 December 2009 (UTC)

I am afraid you did nothing wrong. I am afraid we have another communist bug. Because my communist uploads also don't load into my gallery. Which is very regrettable, because one of the main reasons I use communist is to keep my mass uploads manageable in an easy to access archive,i.e. my gallery sorted by upload time and context of upload. --Wuselig (talk) 22:25, 4 December 2009 (UTC)
Does every image upload fail, or only large images? All the images I uploaded today were PNG format and greater than 4 Megabytes. Usually my uploads are JPG and a lot smaller than that. Perhaps I will try some other uploads, but not right now. --Davidt8 (talk) 23:31, 4 December 2009 (UTC)
The uploads do go through, only the gallery update fails. Check your contributions.--Dodo bird (talk) 23:42, 4 December 2009 (UTC)
True enough, but having the gallery updates makes finding images I have contributed much easier.--Davidt8 (talk) 03:57, 5 December 2009 (UTC)
It seems to be fixed. --Flominator (talk) 10:45, 6 December 2009 (UTC)
Silly question. What is the gallery- where do I find it. I know that I am not updating it, but I have never used it. --ClemRutter (talk) 22:55, 6 December 2009 (UTC)
It is the page User:YourUserName/gallery. Commonist inserts one row per upload there. Mine is at User:Flominator/gallery. Regards, --Flominator (talk) 06:42, 7 December 2009 (UTC)
Mmmm: User:ClemRutter/gallery should look similar? I think there is a little problem here too. Thanks for trying.--ClemRutter (talk) 11:40, 8 December 2009 (UTC)


What is the problem??

What is the problem?? I cannot upload by commonist. I have re-installed Java but nothing. Quahadi Añtó 10:37, 10 December 2009 (UTC)

What happens, specifically? Is that screen capture the result of clicking on an icon on your desktop? --Davidt8 (talk) 02:54, 11 December 2009 (UTC)


The commonist main screen does not appear.

I have downloaded commonist from the official website . I have unpacked it. Then I have go to unpacked folder:

bin-->Commonist (MS DOS batch file)

I click that file . The black screen shows but not the main screen. Why???--Quahadi Añtó 08:02, 11 December 2009 (UTC)

Program stops during upload

Great proram. But the program stops during upload. Sometimes after 10 files, sometimes already after 1 file. What can be the problem? I started the program with commonist.jnlp. Rudolphous My photo's are usually between 3 - 5 Mb. (talk) 23:05, 31 January 2010 (UTC)

have a look at the log output, is there any interesting messages? -- (talk) 13:55, 25 February 2010 (UTC)

Can't log in

Didn't install anyting as clicking on the weblink works straightway, the screen upload comes up, but it says can't log in. Help please YellowMonkey (talk) 04:43, 10 February 2010 (UTC)

have a look at the log output, is there any interesting messages? -- (talk) 13:55, 25 February 2010 (UTC)

Data layer

Would it be possible to save data layer on hardisk? Last time my friend came to my home and closed Commonist. I was happily jumping that I have lost all that work for one day. Or if I start to prepare images in the evening, I am only lucky that I have a notebook, I can leave it in the kitchen not to disturb me when I am sleeping (i.e. I am too tired to finish the work the same day, so I cant swich it). What is taking so lonk? E.g. geodata.--Juan de Vojníkov (talk) 07:42, 24 March 2010 (UTC)

"could not login to commons"

I get the message "could not login to commons". The Terminal window says:

info	net.psammead.commonist.task.UploadFilesTask	logging in
debug	net.psammead.mwapi.MediaWiki	HTTP POST http://commons.wikimedia.org/w/index.php HTTP/1.0 200 OK

I can log in fine with my web browser. The problem occurs with commonist-0.3.40 and commonist-0.3.43.

Thanks, Walter Siegmund (talk) 02:47, 7 April 2010 (UTC)

At 00:16 UTC a security hole in the login section of MediaWiki was fixed on all Wikimedia projects. The API login is affected too and I assume that the Commonist uses the API login. Therefore the login is broken until Commonist is updated. For details read Bugzilla:23076. Raymond 08:49, 7 April 2010 (UTC)
  • From some of the notes, I got the impression that this was no longer maintained, despite being widely used. Is there a way to know how many users are affected/how many uploads are done with this tool? For Commons, it might be more of any issue than a few minor aesthetic tweaks for vector. -- User:Docu at 16:53, 8 April 2010 (UTC)
  • Totally agree. I was in the process of adding 200+ images when the server changed the protocol. I regularly do uploads of 50+. It is obvious that the security wonks have no idea how to prepare to do a major upgrade, and having broadcast their reasons cannot do a rollback. So we are faced with a picture archive that it is impractical to add to.
Commonist doesn't appear to be supported- the source code was last edited 18 Dec 2009- so we are faced with two choices.
  • Bugfix the bugfix to pass commonist through as an exception to allow it to upload but not to spawn.
  • Rewrite Commonist. The source code is available at http://djini.de/software/commonist/commonist-0.3.43.zip if the security wonks can supply us with acceptable logon procedures: a java programmer should be able to patch it in.
Quo vadis? --ClemRutter (talk) 20:55, 8 April 2010 (UTC)
If you are into python, you could try upload.py (sample). I could help you with that, but not with Java. -- User:Docu at 22:21, 8 April 2010 (UTC)
I tried upload.py with the following result. I get the same with login.py. What am I doing wrong?[4] Walter Siegmund (talk) 03:54, 9 April 2010 (UTC)
Password for user Wsiegmund on commons:commons: 
Logging in to commons:commons as Wsiegmund
Login failed. Wrong password or CAPTCHA answer?
It needs "use_api = True" in "user-config.py" as the standard version has the same problem as Commonist. -- User:Docu at 04:46, 9 April 2010 (UTC) -- Read: "use_api_login = True" -- User:Docu at 17:36, 9 April 2010 (UTC)
I did that. I followed the instructions as carefully as I could.[5] Can you confirm that it works for you, please? I'd like to get this to work because it looks like a good alternative to Commonist. Walter Siegmund (talk) 05:38, 9 April 2010 (UTC)
I just did another test and it looks like it's just category-bot that works. I will keep you updated. -- User:Docu at 05:54, 9 April 2010 (UTC)
That is kind. Thank you. Walter Siegmund (talk) 06:00, 9 April 2010 (UTC)
There might still be a bug in the fix applied on the 7th (trunk version). Possibly, the token is sent, but not the corresponding cookie. I asked Multichill to look into it. -- User:Docu at 09:56, 9 April 2010 (UTC)
Source for sample

Update: 14:19, 11 April 2010 (UTC) see Commons:Tools#Python_Wikipedia_Bot instead.

# -*- coding: utf-8  -*-
import wikipedia, upload
import config

url = u"filename-01.jpg"
title = u"imagetitle-01.jpg"
description = u"""{{Information
|Description    = {{en|1= test description }}
|Source         = 
|Author         = 
|Date           = 
|Permission     = 
|other_versions = 
}}
"""
targetSite = wikipedia.getSite('commons', 'commons')

bot = upload.UploadRobot(url, description=description, useFilename=title, keepFilename=True, verifyDescription=False, targetSite = targetSite)
bot.upload_image(debug=False)
In the meantime, the bug was reopened and the missing cookie added. I tested it with the lines above. Extensive code for uploads can be found here. -- User:Docu at 17:29, 9 April 2010 (UTC)
I downloaded the latest version of pywikipedia and I can log in now. Thank you. Walter Siegmund (talk) 20:23, 9 April 2010 (UTC)
  • I just had a look at the source. I don't think any editing is required. Commonist relies on a MediaWiki function to login. I think it just needs a rebuild with the latest version of MediaWiki. I may get a chance to download NetBeans and MediaWiki tomorrow.--JIrate (talk) 22:50, 8 April 2010 (UTC)
anyone fixing this? Deror avi (talk) 21:36, 9 April 2010 (UTC)

Honestly, I don't see what "rebuilding" will change, except creating new .class, the new logic needs to be implemented, either in commonist, either inside mwapi.jar, which sources are provided with commonist. They don't seem to rely directly on mediawiki. Of course, they use the mediawiki function, but it was changed, so there is a changed needed there. Esby (talk) 06:00, 10 April 2010 (UTC)

Yep you are right. I had assumed that the Login was part of MediaWiki and that as such if the authors chaned the library they would change the supporting code. --JIrate (talk) 09:29, 10 April 2010 (UTC)

The new version of Commons - Commonist is not working

I am not sure if this the right place to write about the new version of Commons, but it is horrible. The major problem is that now the Commonist is not working. Please Help!!!!!. I went back to the old and better version but the Commonist is still not working. Who is responsible to fix it? Hanay 03:24, 9 April 2010 (UTC)

The new appearance is unrelated to the reason why Commonist is "not working". Until the developer of Commonist fixes the software, it won't work. guillom 05:12, 9 April 2010 (UTC)
Or anyone who can & cares. Guess why the dev ships the sourcecode with the binary :) malenki 08:06, 10 April 2010 (UTC)
Read the thread above! --ClemRutter (talk) 08:37, 9 April 2010 (UTC)
I do not understand, until 2 days ago I used the Commonist a lot, and I had no problems. Yesterday 2 things happened: New version of Commons and The Commonist can not be logged on. I do not believe that this is incident Hanay (talk) 18:50, 9 April 2010 (UTC)
The program on the server was changed. This was to make it more secure. The small piece of code for remote logon changed- so Commonist could no longer connect to the server. This piece of code lies in the mediawiki library. All that we need to do is wait for someone with Java progamming experience to recompile (or rebuild) Commonist, and it will automatically include the new code, thus fixing the problem. We have a volunteer but we must wait until he has a little free time to do the task. See the thread above.
The new appearance is unrelated to the reason why Commonist is "not working". I used commonist under the new looks for 20+ hours, before it broke. I hope this helps.--ClemRutter (talk) 23:23, 9 April 2010 (UTC)
Thank you for the explanation. I am not a programmer, but as I see it, this is not a good way to update version of any software. First you need to be sure that everything is working and than you update the version. You never update half. For me as a user I only know that I can't use Commonist as I used to Hanay (talk) 04:29, 10 April 2010 (UTC)

Version 0.3.43 worked properly at least until April, 1. I had my last upload on Foto-Wiki then. On April, 2 I got error HTML 301 (moved permanenently). I contacted Avatar and was informed that security updates for the Mediawiki login have been made on Wikia and Wikimedia which might cause the troubles. --Eva K. is evil 10:41, 10 April 2010 (UTC)

Well, this was a security update to avoid (iirc) cross site scripting attacks. I had a look into the commonist source code. The problem is not in commonist but in a library called mwapi that does all the communication. This library uses not Mediawikis api.php but mimics the communication as you do with the webbrowser. This access is deprecated since years and makes it now (at least for me) hard to fix. --Prolineserver (talk) 11:03, 10 April 2010 (UTC)

Would be nice to have this fixed or at least a simple mass-uploader program was made! I've tried a perl script uploader but have issues (seems to be an issue that dates back to 2009!) and python is too complex for me to set-up on Windows 7. I now have a back log that I can't clear via the slow upload process (using the Commons upload form). Bidgee (talk) 13:20, 10 April 2010 (UTC)
Main pywikipediabot scripts

Available at: http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/ encoding: utf-8

BeautifulSoup.py
config.py
family.py
generate_user_files.py
login.py
query.py
upload.py
version.py
wikipedia.py
wikipediatools.py
xmlreader.py
families\commons_family.py
pywikibot\__init__.py
pywikibot\exceptions.py
pywikibot\textlib.py
pywikibot\throttle.py
userinterfaces\terminal_interface.py
userinterfaces\transliteration.py
I'm not sure how it works in Win7, but for a quick install, it might be sufficient to install python 2.6.5, create a subdirectory for the bot, copy the pywikipediabot scripts used by upload.py there (see list above). Create one from the sample in the previous section (call it run_upload.py referencing files etc.). From command line, first run once "..\python\generate_user_files.py" then "..\python run_upload.py" and it should be ok. -- User:Docu at 17:08, 10 April 2010 (UTC)
Yes, I've installed all that, though using the above code and it worked though I need to hit enter for every new file but now I get this!

Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. <Removed rest of the code as its not needed> Uploading file to commons:commons via API.... <urlopen error timed out> WARNING: Could not open 'http://commons.wikimedia.org/w/api.php'. Maybe the serv er or

your connection is down. Retrying in 1 minutes...

<urlopen error timed out> WARNING: Could not open 'http://commons.wikimedia.org/w/api.php'. Maybe the serv er or

your connection is down. Retrying in 2 minutes...

Bidgee (talk) 14:22, 11 April 2010 (UTC)

It needs "use_api_login = True" in the user-config.py, but not "use_api = True". I corrected what I had written above. -- User:Docu at 14:25, 11 April 2010 (UTC)

fixing the login alone seems not to be sufficient, upload still doesn't work. additionally, upload warnings for deleted files and such have been changed. to avoid this kind of problems in the future, the commonist is currently being rewritten to use api.php instead of screen scrapping. the rewrite will take a few days, though. -- 84.153.68.116 02:24, 11 April 2010 (UTC)

Login problem fixed

I have hacked up a patched version of the Commonist that fixes the login problem. The author has been notified. Enjoy.  « Saper // @talk »  19:39, 11 April 2010 (UTC)

Superb. Thanks a lot. Goodness Shamrock (talk) 19:52, 11 April 2010 (UTC)
Second that. Muchly appreciated. :) --Ebyabe (talk) 21:06, 11 April 2010 (UTC)
Great: Could someone remind me how I apply this patch to my current Linux 0.3.43 jar, and I'll add the info to the documentation. I have down loaded the patch, extracted the files to the desktop folder >commonist new-jar<- what happens next. I can't find a folder >bsh< in the old jar etc. --ClemRutter (talk) 21:14, 11 April 2010 (UTC)
Don't extract anything. Just download this file and say java -jar commonist-0.3.43-patched.jar. Some systems do this automatically when opening this file ("double-click" or something).  « Saper // @talk »  22:56, 11 April 2010 (UTC)
Thanks a lot. --Kolossos (talk) 21:28, 11 April 2010 (UTC)

Sorry, but the fix works only on Commons. I need a complete fix which works with all defined projects. --Eva K. is evil 11:05, 12 April 2010 (UTC)

Ich will, ich will.... :-) I have just tested with my accounts and I was able to upload both to the English as well as the Polish Wikipedia. No idea what is causing your problem...  « Saper // @talk »  20:44, 12 April 2010 (UTC)
However, people have still troubles with uploading images. So there's nothing where I have to be thankful and make a kowtow. Either you fix it correctly or you leave it. You've made it worse than before. AFAICS you didn't understand the Commonist's background - there's a configuration list with other projects beyond the small Wikimedia horizon. Just open your eyes and see. --Eva K. is evil 10:44, 13 April 2010 (UTC)
I am grateful for the attempt. I can login to Commons, (which is all that matters to me) but not to en:wikipedia. I successfully uploaded a test file at 08:17. While writing the documentation fix, I uploaded a second test file which I deliberately aborted. In the last few minutes I started 'work' and uploaded 10 files- log on worked- files appeared to go, and I got my usual (can't update gallery) so far all was normal. Checked My watch list- nothing. Checked my contributions- nothing. Killed commonist. Loaded commonist again- attempted to upload a single file- got all the right signs- but nothing arrived. Hope this helps locate the problem. --ClemRutter (talk) 12:09, 12 April 2010 (UTC)
I have installed Commonist on a clean machine. Modded the documentation, and tested a clean version. Same results, I can log into commons- the upload appears fine, but nothing is written to the server. There is a new hat message-'Attempts to upload files over existing files is currently completely broken. It is hoped this will be fixed shortly.' are these related? ClemRutter (talk) 17:22, 12 April 2010 (UTC)
Uploading images that have been deleted previously or overwriting is broken. It won't work. You will have to upload those images manually. However, uploading fresh files works well.  « Saper // @talk »  20:44, 12 April 2010 (UTC)
Isn't it frustrating, when you solve one problem another comes along and replaces it. Yes, I have uploaded a new file successfully. But once you have attempted to upload a file- whether successful or not- nothing by that name will upload. I am still puzzled as to why the ten testfiles failed the first time- I assume it was because there was a single file in the batch that was a reload.--ClemRutter (talk) 21:39, 12 April 2010 (UTC)
So back to my testfiles. 7 of the ten before. I renamed them all in the Commonist window- so I am now uploading 7 files with newnames. The first run- 2 uploaded, then next time 1, the next time 1, the next time 2 and then 0, then 0.. I can't get the last file to upload at all. As I have mentioned- everytime Commonist tries to update my gallery it throws an error message either 500 Internal server error or 504 Timeout but has always done this and User:ClemRutter/gallery wont load. Change machine. Take the three remaining test files and the one that refused to upload- rename them outside Commonist. Upload the three- worked. Tred the stubborn one. Still won't upload. So that's my contribution for today.--ClemRutter (talk) 23:50, 12 April 2010 (UTC)
Seems to be more stable today.--ClemRutter (talk) 12:48, 14 April 2010 (UTC)
how do I use the patch? Deror avi (talk) 20:40, 12 April 2010 (UTC)
Just run this jar file with java: java -jar commonist-0.3.43-patched.jar. No need to unpack or install anything.  « Saper // @talk »  20:44, 12 April 2010 (UTC)
I need simple instructions. Prior to the damage - I just pressed the link here and the communist ran. What do I do now and where? Where and how do I run what? I am using windows with regular explorer. Deror avi (talk) 20:48, 12 April 2010 (UTC)
I spent the afternoon writing clear documentation for Ubuntu (see Project Page), I don't have a Windows system in the house to test this on but I guess you will have to install Java Runtime (see link on Project Page) and then download the patch to your desktop, and double click on it. This way you bypass Firefox or inferior browsers. --ClemRutter (talk) 21:39, 12 April 2010 (UTC)
Dont' understand anything you said. It's simple windows explorer. And the patch is a zip file - so nothing happens when I click it exept opening a rar opener. Deror avi (talk) 15:57, 13 April 2010 (UTC)
Here's the trick: Rename it from ".zip" to ".jar" file first. Afterwards you should be able to use it by just double-clicking on it (provided that you have Java installed). Took a sec to figure that out but works for me now. Thanks Saper!
@ClemRutter: I had similar problems. Strange stuff... ;-) --X-Weinzar (talk) 01:35, 15 April 2010 (UTC)
Thanks. it worked. Deror avi (talk) 08:36, 16 April 2010 (UTC)

major rewrite

a new version of the commonist is online, see [6]. instead of screen-scrapping it uses api.php so problems and updates because of changes in mediawiki should be necessary a lot less often. furthermore, adding support for new wikis has become really simple. on the downside, custom templates have to be adapted and running startup scripts is no longer possible. -- 84.153.90.167 00:27, 17 April 2010 (UTC)

Thanks for all the effort you have put in to solve this major problem (are you any good at volcanoes?). I have tested the upload with a single file and it worked, so I see three tasks ahead
  • The Project page documentation which I will try and do this weekend.
  • Reporting back any inconsistency with the patch and with the version 0.3.0 that we were used to
  • Consider whether it is possible to integrate the requested changes particularly the backup/restore- textdump to txt function that has been requested.
A good piece of work. --ClemRutter (talk) 07:56, 17 April 2010 (UTC)
Thanks for keeping the documentation up to date! Do you think persisting all entered data even accross restarts would be enough, or is having separate buttons for loading/storing this data into a file worth the gui clutter? -- 84.153.125.73 15:03, 17 April 2010 (UTC)
Thanks for the work. I'd suggest that after a file has been uploaded it is copied locally to a gallery as is it data. The data could then be persistent between sessions until removed by a successful upload. --JIrate (talk) 21:00, 17 April 2010 (UTC)
An off thread question- why scala? Continue on my Talk Page.. --ClemRutter (talk) 21:10, 17 April 2010 (UTC)
Inconsistencies.
1: Uploads not checked to watch
2: New heading in description ==Batch==
3: Text reversed Specific comes before Batch
4: Ubuntu: Symbolic links not working from home/desktop - but launchers from toptoolbar do.
5: Change of behaviour with gallery not updating- it just keeps on trying; previously it had thrown a 500 or 504. New uploads are not possible without restarting Commonist- this could be ignored after a 504. This is a problem that I have suffered in silences for months. My gallery http://commons.wikimedia.org/wiki/User:ClemRutter/gallery appears to be blank- but Commonist refuses to update but now keeps on trying, blocking further edits
Other issues
1: Ctrl-Z/ Ctrl-Y not functioning --ClemRutter (talk) 21:10, 17 April 2010 (UTC)
1: done
2: fixed: was using the wrong template for commons
3: on purpose for other wikis, as you expected in the right template (see 2)
4: symbolic links to bin/commonist, i assume. simple to fix if realpath is installed, difficult without
5: no idea how this could happen. i'll investigate. any interesting output in the terminal?
other 1: i don't think it ever did, swing text components don't support undo/redo by default
-- 84.153.125.73 00:03, 18 April 2010 (UTC)
I have thought a lot about the need for the load/store function. It must be a balance between function and simplicity.
Persistance across edits would be better than nothing- and maybe easy to code. This would be useful when the system crashes but would not solve the other problem, that of changing folder accidentally and thus blanking prepared text that hasn't been uploaded. If the persistance were coded on a folder by folder basis I can see that coding simplicity would be lost and a clear cache button would be needed for garbage collection.
Loading/storing Is better, but raises other issues. Firstly, it is good data-entry practice to backup regularly and always 15 seconds before a crash. When I can't I get twitchy. Secondly, this leaves an audit trail. Thirdly, it allows prep work to be done offline- away from an internet connection which can be slow and expensive for certain disadvantaged users.
What I propose is a rigid file format, that stores batch information to a (image_index).txt file, followed by the image information for each image. New data is appended to the existing file which is stored in the image source folder with the images. load will copyback the last store instance allowing for a backup/restore but the file will allow all store instances to be merged manually to prove a complete record of each upload. This will allow the user to manually alter the text in the last instance offline to build a better description- but also a merge will provide a complete narrative on the local disk of each image in the folder.
Gui clutter is a price that must be paid. I see three buttons top right Store/ Reload/ Help, but these could be well known icons not text, saving screen space. But lets not turn this into a debate about vector v monobook until the functionality is sorted. With drop down menus- possibilities, and simplifications occur. A single button Help could lead to many options- Version/ Quick Help/documentation//Backup/Restore// Audit trail/Save upload log/ Write all descriptions to Upload Folder/ Printable Version// which would add functionality,simplify the coding though lengthen the code. --ClemRutter (talk) 21:10, 17 April 2010 (UTC)
i thought about persistence on a file-by-file basis accross directory changes until the file gets moved or deleted. with garbage collection, of course. data could be stored on disk almost immediately after a change in the gui. in either case i think the commonist should never write any files outside of ~/.commonist/ (except when explicitly told so by the user). it will need some thinking to get this perfect. -- 84.153.125.73 00:14, 18 April 2010 (UTC)

Problems with 0.4.0

interesting, this looks like a bug to me: the description page is not built from the template for commons, but from the template for other wikis. -- 84.153.125.73 23:29, 17 April 2010 (UTC)
  • Upload doesn't work on Foto-Wiki: wikia:foto:Benutzer:EvaK/gallery. Login works, upload seems to work, but images weren't really uploaded, an error is recorded instead. I thoroughly deleted all old Commonist entries on my disk. The only change I've done was to add my personal license tags as in former Commonist versions and to replace image_default.bpp by image_commons_bpp as in Foto-Wiki the file description page is equal to Commons. I also moved my former upload gallery to have a fresh gallery created by Commonist. A test with the defaul templates also failed. --Eva K. is evil 10:54, 18 April 2010 (UTC)
you used one of the new templates, right? the old ones don't work any more. what's the error being recorded? -- 84.153.119.236 20:49, 18 April 2010 (UTC)
I used the new templates, I only adapted them to my former changes. --Eva K. is evil 11:57, 19 April 2010 (UTC)
the problem is: upload via api.php is supported since mediawiki 1.16. in contrast to wikipedia and commons, fotowiki still uses 1.15.3 :/ -- 84.153.119.236 00:09, 19 April 2010 (UTC)
Okay, that's what I suspected. I'll ask Avatar, who is Wikia country manager, when they will update to MW 1.16. --Eva K. is evil 11:57, 19 April 2010 (UTC)

massage " Could not upload (no json result)"

I succeed to upload images, but the commonist c'ant create the gallery. I got a massage " Could not upload (no json result)", Can someone solve the problem? Thanks Hanay (talk) 15:38, 19 April 2010 (UTC)

"no json result" either means api.php didn't return valid json code or the commonist's json parser is broken. i tend to think it's been the former. -- 84.153.117.71 23:28, 24 April 2010 (UTC)

Download hangs, webversion hangs

I went to http://djini.de/software/commonist/ but the downlooad of the zip file hanged and remained at 0 bytes. Neither did the webstart work. Vista, firefox latest version. Teun Spaans 20:37, 24 April 2010 (UTC)

works for me. does this still happen? -- 84.153.117.71 23:26, 24 April 2010 (UTC)
Yes, now it works. Thank you! Teun Spaans 04:16, 26 April 2010 (UTC)

Where are we now 25 April 2010

For over a week we have had a brilliant new rewrite of Commonist. It is now at version 0.4.4 and is a clone of the 0.3.x version, with a few enhancements. It seems appropriate to have a running wish list and a space to point out difficulties and comment on enhancements. I have copied over the changelist.

0.4.4	24apr10
;    feature     added GPS data from EXIF, not editable in the GUI yet
;    change      improved filename preset mangling: all illegal chars are 
;                replaced with '-', multiple consecutive spaces are reduced 
;                to a single one
0.4.3   22apr10
;    feature     added a date field to individual files overriding the common
;                date if not empty. the date field is preset from EXIF
;                data if available. image templates have changed to include 
;                the new upload.date
0.4.2   21apr10
;    bugfix      wouldn't start with a corrupted thumbnails.txt
;    feature     permission has an own editor now
;                section have been swapped
;    feature     added support for wikisource:ar
0.4.1   18apr10
;    bugfix      used the wrong template for image description pages on commons
;    change      uploaded images are now automatically watched
;    change      displays an uploaded file's name instead of its full path in 
;                the progress bar


  • Could we display the version number on the top bar- those of us supporting multiple computers can get confused.
  • My gallery doesn't ever update- 0.4.x keeps on retrying, so I have to do a close and restart before I can upload a second batch.
  • With 0.4.0, I had a peculiar upload. Not all files up loaded, and some that did, see File:Great Northern Manchester 4566.JPG ,had captured other images- just see the source code.
  • With a hang: more than ever, a facility to save/reload all the individual image data becomes desirable. I still have fantasies of being able to use this saved data as gallery comments on my local folders/directories.
  • Now we have an overriding image permission and date data entry field- don we need a mouse over hint to explain how and when to use each of these ¡Nightmare!

--ClemRutter (talk) 13:31, 25 April 2010 (UTC)

Now the date field for each file is set from the File Time or Date and Time in the EXIF. In my case I would have preferred the Date and Time (original). Haros (talk) 15:38, 25 April 2010 (UTC)
If there is a difference between EXIF DateTimeOriginal, EXIF DateTimeDigitized, Image DateTime, it should probably pick the earliest date. Files were the current defaults are not optimal, e.g. (some 'random' files from commons):
It might need more samples for some of the combinations. -- User:Docu at 16:09, 25 April 2010 (UTC)
BTW, if the date is in January a few years back, maybe it should display a warning. -- User:Docu at 16:21, 25 April 2010 (UTC)
Given the second sample above, maybe there should also a warning when the dates are somewhat inconsistent. -- User:Docu at 17:16, 25 April 2010 (UTC)
  1. interesting the gallery is not updated in all cases. i doesn't keep retrying, though, it just seems not to update the progress bar any more. i've never seen this behaviour, are there any useful error messages in the terminal?
Give us a clue. Where do I find the terminal that displays these messages. I am on Ubuntu 9.10?--ClemRutter (talk) 20:31, 25 April 2010 (UTC)
    1. i think i understand your problem a bit better now. your gallery doesn't load in the browser, either. it takes a long time, then an error 500 is returned. maybe because it's extremely big and contains a lot of pages. i'll try to reproduce this in the commonist and investigate what it's doing in such a case.
The error message relates to a gallery- but the damn thing keeps moving so I can't send a screen dump. Previous versions would eventually throw a 500. 0.4.4 just keeps rolling the message and I have not seen it throw a 500 even after 15 mins. The only way to re-capture the pane is to close it. I can't change folder or anything else. Yes I have been working with folders with 75 images, but only uploading 10. I have a high number of contributions. I am less sure now what hasn't been updated. I had assumed it was the User:Username/gallery folder on the server we were talking about- and the process was creating symbolic links to the raw images in the server farm. But now it appears that this 'gallery' is non existant, and we are talking about adding symbolic links / thumbnails in a category folder or doubly-linked links in a category tree- and this tree is not returning a process-completed flag to the commonist, so it fails drop down to the calling function- but only on my machines! What ever it is- it means I must close the program and start again, keeping the generic metadata- and erase all the individual images metadata.--ClemRutter (talk) 20:31, 25 April 2010 (UTC)
found something: my JSON parser was broken. i have a fix, but it's not yet tested. -- 84.153.103.93 21:05, 25 April 2010 (UTC)
the fix is live. -- 84.153.109.117 00:28, 27 April 2010 (UTC)
  1. adding the version number to the title bar and maybe the edit summary for the gallery sounds useful. i'll do it.
  2. i'm still not convinced manually loading/saving metadata is more useful than automatically.
As mentioned above- only the generic metadata is autosaved. I would be quite happy if the individual images metadata were autosaved.- and if that were in an accessible format so it could be used for other purposes that would be better too. I feel more secure if I have "Saved early, and saved often.". Autosaving should occur when ever the folder is changed.--ClemRutter (talk) 20:31, 25 April 2010 (UTC)
  1. at least the documentation should be updated to describe the date field because of the "magic" override. the permission field doesn't have any magic, it just got separated from the license
  2. could somebody explain the different EXIF date fields to me?

-- 84.153.103.93 17:47, 25 April 2010 (UTC)

    1. The "gallery" you mention is in fact a series of categories, not a "gallery". It's created by adding categories to specific images. It doesn't update at all. If only there were categories for that. The samples above happen to be in these categories as I had checked exif when adding them. Otherwise, they are not important for the question which date to fill into the information template.
    2. I will try to find some documentation on the different fields. Some cameras just set all to the same. Obviously it can still be wrong (dead battery, camera reset, etc). -- User:Docu at 18:48, 25 April 2010 (UTC)
    • At Commons:Exif#External_Resources, there is a link to the specs. Those for the dates fields seems the same in 2.1 and 2.2 (search for "DateTime", "DateTimeOriginal", "DateTimeDigitized"). The first date Mediawiki displays is DateTimeOriginal described with MediaWiki:Exif-datetimeoriginal.
    • For more date magic, checking for missing "Exposure time", "F Number" and/or "Lens focal length" could display a warning when the image (and the not helpful date) comes from a scanner (sample)
    • Exif field "ImageDescription" could be used as description for the information template (sample).
    • Hope this helps. -- User:Docu at 11:28, 26 April 2010 (UTC)

Kolossos's whishlist

On my wish list is that it should be possible to order the images in the directory by date and not only by name, because I want normally upload the latest files in my "wikipedia"-directory and start a new wikipedia-directory after I have more than 100 images or so. My other wish is to have an option to create the gallery-page without description text because this seem too long. I know this are very special (power-user) wishes and makes the program perhaps more difficult to use for beginners. --Kolossos (talk) 18:16, 26 April 2010 (UTC)

sorting by date sounds like ui-clutter. maybe i could add a configuration option to settings.properties, but i won't promise anything. leaving out the description on the gallery page can be done: copy etc/template gallery_commons.bpp to $HOME/.commonist/gallery_commons.bpp and delete the $(upload.description.replaceAll("\n", " ")) part in the copy. -- 84.153.109.117 00:11, 27 April 2010 (UTC)

Loosing Uploads

The last days I loose two images on upload, the last one was today with the newest commonist version. The uploads of images directly before and after works fine with commonist. I get no error from the commonist but it seems that nothing happen on the commons server side. I need to use the (ugly) web-interface for uploading, but this works and seems faster. I must say that the problematic image was with nearly 18 MB bigger than normal and my upload link (DSL1500) is not very fast, so the upload needs more than an hour. Goes the upload now over the API and has the API perhaps a time-out or what can be the reason? Thanks. --Kolossos (talk) 18:26, 26 April 2010 (UTC)

yes, the commonist uploads via api.php now, maybe there's some size limit or timeout. the commonist's connection code has not changed very much. there's no error message in the console output, i assume? -- 84.153.109.117 19:38, 26 April 2010 (UTC)
Console output on Windows? No. Or is this somewhere hidden? I can try it under Linux. --Kolossos (talk) 21:10, 26 April 2010 (UTC)
either the java webstart console (no idea how to open it on windows, though) or the output of bin/commonist.bat when executed in a command window (cmd). you could also have a look if there is some known bug in mediazilla. -- 84.153.109.117 00:14, 27 April 2010 (UTC)

Something is wrong

I am using the current 0.4.5. version. But look at this file: File:Rektorská chata na b-ehu rybníka -výcar.JPG. In its name some special characters are missing. Its not the first file, which has such defects, I have recognised this day. Later on this day, I have discovered another one: [7] and as its not the first one, I assume something is wrong in Commonist.--Juan de Vojníkov (talk) 18:53, 26 April 2010 (UTC)

Same crap with Polish names, see File:Kosz-cin Palace 02.jpg. Yarl 19:22, 26 April 2010 (UTC)
0.4.4 mangles filenames to ensure there are no characters disallowed by api.php. it's possible i misunderstood mediawiki's code and so the commonist replaces too many characters with dashes. it may even be a bug. -- 84.153.109.117 19:42, 26 April 2010 (UTC)

fixed in 0.4.6 -- 84.153.113.213 21:10, 27 April 2010 (UTC)

Cool! Thanks!--Juan de Vojníkov (talk) 06:49, 28 April 2010 (UTC)

OutOfMemoryError with 0.4.5

I tried to modify image_commons.bpp. (under ubuntu 9.1 64 bits) If the added code contains a 'ö', the upload will fail and an exception will be triggered: (the bug is also present in 3.4.3 patched version.)

INFO	uploading files
ERROR	Exception caught in the Event Dispatch Thread
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:2882)
	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
	at java.lang.StringBuffer.append(StringBuffer.java:320)
	at net.psammead.minibpp.Compiler.literal(Unknown Source)
	at net.psammead.minibpp.Compiler.exact(Unknown Source)
	at net.psammead.minibpp.Compiler.decorate(Unknown Source)
	at net.psammead.minibpp.Compiler.filter(Unknown Source)
	at net.psammead.minibpp.Compiler.compile(Unknown Source)
	at commonist.util.Templates$$anonfun$1.apply(Templates.scala:24)
	at commonist.util.Templates$$anonfun$1.apply(Templates.scala:23)
	at scutil.Resource.use(Resource.scala:15)
	at commonist.util.Templates.applyTemplate(Templates.scala:23)
	at commonist.task.upload.UploadTemplates.template(UploadTemplates.scala:30)
	at commonist.task.upload.UploadTemplates.imageDescription(UploadTemplates.scala:22)
	at commonist.task.UploadFilesTask$$anonfun$upload$1.apply(UploadFilesTask.scala:141)
	at commonist.task.UploadFilesTask$$anonfun$upload$1.apply(UploadFilesTask.scala:113)
	at scala.List.map(List.scala:812)
	at commonist.task.UploadFilesTask.upload(UploadFilesTask.scala:113)
	at commonist.task.UploadFilesTask.execute(UploadFilesTask.scala:55)
	at commonist.Task.commonist$Task$$run(Task.scala:59)
	at commonist.Task$$anon$1.run(Task.scala:15)
	at java.lang.Thread.run(Thread.java:619)

Do you wish bugs to be reported here or somewhere else by the way? Esby (talk) 18:15, 27 April 2010 (UTC)

wow. if this bug really is in the template compiler, it has gone unnoticed for years. was this an UTF-8 "ö"? -- 84.153.113.213 20:47, 27 April 2010 (UTC)
nice find! this will be fixed in 0.4.7 -- 84.153.113.213 22:00, 27 April 2010 (UTC)

Yes, I was trying to add some template linked to the Nyköping place ... I guess I could use some proxy template for that... Esby (talk) 16:30, 28 April 2010 (UTC)

0.4.7 is online, this should work now. -- 84.153.85.65 18:33, 28 April 2010 (UTC)
Confirming that the bug is fixed. Esby (talk) 19:51, 28 April 2010 (UTC)

verification-error

what am I doing wrong? Im getting verification-error after commonist seemingly uploaded my files, see: User:Robek/gallery, am I forgetting some crucial parameter? --83.27.214.233 22:40, 3 May 2010 (UTC)

i guess it's the missing filename extension. try adding ".jpg" -- 84.153.65.35 01:39, 4 May 2010 (UTC)

Bug

Commonist used to work great for me, however with the current version the program crashes on loading some files. It lookes like it only happens with files with gps-data in the exif. Here's a a part of the stacktrace:

 INFO    found EXIF data 
 S:\tmp\NaarWikipedia\ijsselstein\P1000232-1.JPG
 ERROR   Exception caught in the Event Dispatch Thread
 java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
 at java.math.BigDecimal.divide(Unknown Source)
 at scala.BigDecimal.$div(BigDecimal.scala:168)
 at commonist.util.EXIF$.commonist$util$EXIF$$decimal(EXIF.scala:90)
 at commonist.util.EXIF$$anonfun$commonist$util$EXIF$$part$1.apply(EXIF.scala:81)
 at commonist.util.EXIF$$anonfun$commonist$util$EXIF$$part$1.apply(EXIF.scala:80)
 at scala.Option.flatMap(Option.scala:77)
 at commonist.util.EXIF$.commonist$util$EXIF$$part(EXIF.scala:80)

Here's the gps part of the exif:

 GPS information: - 
 GPSVersionID - 0.0.2.2
 GPSLatitudeRef - N
 GPSLatitude - 52  1  9.69
 GPSLongitudeRef - E
 GPSLongitude - 5  2  42.88
 GPSAltitudeRef - Sea level
 GPSAltitude - 4.10 m

I hope there's an easy fix! Cheers, China Crisis (talk) 17:42, 4 May 2010 (UTC)

thanks for finding this (rather stupid) bug. i think i have a fix, but i need to do some testing before going live. could you please upload the above mentioned image so i can use it for testing? -- 84.153.46.142 01:25, 5 May 2010 (UTC)
Sure, here it is: File:Havenstraat.28.IJsselstein.jpg - China Crisis (talk) 17:46, 5 May 2010 (UTC)
thanks. the bug seems indeed to be fixed and 0.4.10 is online now. -- 84.153.115.171 19:54, 5 May 2010 (UTC)
Works like a charm! Thanks, China Crisis (talk) 16:09, 6 May 2010 (UTC)

Small feature request

Do you think it could be possible to add a field for content to be added at the end of the description (eg: template or category in wiki format) , either fot all images or a single given images ? I know this is possible by modifying the etc files, but this is rather unpractical. Esby (talk) 13:27, 13 May 2010 (UTC)

hm. do you think a lot of users need this or is it just a few? if it's the latter i'd prefer not to add more fields to the GUI. maybe you don't need the description field for all images and could put that text at the end of every image description page instead? you know you can have a modified copy of an etc-file in the settings directory, even for the webstart version, right? -- 84.153.49.46 00:56, 14 May 2010 (UTC)
Usually this serves for adding user / various informative template like {{Hugin}} or {{Personality rights}}.
I honestly don't like much the user interface of Commonist, as I feel like a monkey filling boxes. If it was for me, i'd prefer to be able to edit the full description of all images in a big text area. So there would be no mouse click needed to describe all pages. I guess this cannot be done easily, and this would probably scare some users. Esby (talk) 01:23, 14 May 2010 (UTC)
you mean a single text editor containing lots of Template:Information or similar, one for each image and nothing else? then where would you put the thumbnails? -- 84.153.49.46 01:48, 14 May 2010 (UTC)
Well I was half dreaming: Please consider I am not the average end user: Multiple box looks cool and securing for the neophyte, but they require mouse clicks, especially when you don't need half of these. So in the end, you are slower to produce content. One idea to remedy to that would be to implement navigation like if you would be in a big notepad: By using up and down key, you should be able to change focus of each text area.
Could you set the arrow keys (up and down) to allow to go from one edit area to another edit area, I see two cases: Simple line area should trigger a focus to the upper or lower component all the time. Multiple lines area (the description for now) should trigger a change of focus if the cursor is on the first or last line of the area. With that we could easily edit all the description.
With these facilities, adding one more text area for 'bottom template' should not cause a problem, as soon the user understands he can navigate with the arrows.
Esby (talk) 02:45, 14 May 2010 (UTC)
more input fields or less of them - a lot of users want to have one added for their special purposes which most of the other users don't need at all :/ you can skip input fields with the keyboard, though: like in most applications, TAB switches the focus to the next field, SHIFT-TAB to the previous. there are only two drawbacks: first, in multiline-textboxes you need to use CTRL-TAB and CTRL-SHIFT-TAB because the TAB key inserts a TAB character. considering mediawiki-markup doesn't make use of the TAB character, this special behavious is completely unnecessary. second, the image list doesn't scroll if the focus leaves the visible area. i'll see if i can fix that. -- 84.153.55.91 11:02, 16 May 2010 (UTC)
I don't agree with you here: While I agree that adding / removing fields is a problem, I don't think the ergonomy should be ignored: I know I can use tabs, but this is not logical and easy: to advance you have to use tabs or ctrl+tabs depending the type of field you are, while we have no use of tabulation for editing a description. To go back we must use shift + tab (+ctrl). This is just silly as the arrow keys for now are serving no purpose, of course you can use them to look your image list, but it is still unpractical to type. Also, if you bring down the ergonomy issue, you can add a few more field without problems. Anyway, I'll just use mw for now to fix the description after upload. Esby (talk) 14:42, 16 May 2010 (UTC)
since 0.4.12, TAB and shift-TAB shift the focus to the next/previous input field uniformly. the CTRL key is no longer neccessary. i agree it's not intuitive, but it's a de facto standard for form-based applications. i can't use the cursor keys for this - they are still needed for moving the cursor in the multiline description fields. additionally the image list is scrolled automatically to the input field having the focus now. -- 84.153.103.195 20:14, 19 May 2010 (UTC)
Thanks for the improvement. Esby (talk) 21:30, 19 May 2010 (UTC)

Other issues

I also see a few bugs / problems: When the connexion fails and closes, commonist stops, this includes when the api connexion fails temporary. This causes two 'problems':

  • the gallery is not updated.
  • upload already done have to be unchecked.

Could there be a way to get log windows, which would contain:

  • the usual log message.
  • the gallery information, with a possibility to send this information manually when a problem arises during the upload.

If the program could unset the checked box for each files that were uploaded it would be also good. Esby (talk) 18:48, 13 May 2010 (UTC)

in 0.4.11 i added a new status field to every image telling you if an image upload has been successful or did fail. there's a new button to select failed uploads only. a log window seems unnecessary to me: there's either the webstart console or the terminal you started the commonist in. the gallery text is written to a file named "gallery.txt" in the settings directory before updating the gallery now. -- 84.153.49.46 01:00, 14 May 2010 (UTC)
good enough then Esby (talk) 01:12, 14 May 2010 (UTC)

Please add a lizenz

Template:PD-GDR stamps is often in use. I am waiting to upload 500 pictures... Sorry for my poor english. Greeetings --Nightflyer (talk) 21:40, 21 May 2010 (UTC)

hi Nightflyer! the new license will be included in the next release, in the mean time you use your own license list:

  1. find the commonist's settings directory: $HOME/.commonist on linux and os x, on windows look for a directory named .commonist containing files named settings.properties and thumbnails.txt
  2. put a textfile named licenses.txt in this directory containing lines like this for every license you need:
{{PD-GDR stamps}} For German stamps released as Deutsche Post der DDR.

if you want to use the default licenses again, just delete the file. -- 84.153.119.41 00:49, 22 May 2010 (UTC)

Thanks a lot. It works. Greetings --Nightflyer (talk) 08:55, 24 May 2010 (UTC)

Move to mediawiki svn and host at the toolserver

That's what we should do with Commonist. Anyone willing to help? Multichill (talk) 11:21, 28 May 2010 (UTC)

so when toolserver is down, people can't download commonist? imo, For code hosting, any platform is good. I don't see any particular reason to move it to the toolserver, unless if there are issues currently. Esby (talk) 17:03, 28 May 2010 (UTC)
It's now hosted at someone's personal webserver ( http://djini.de/software/commonist/ ) by someone who is very hard to reach. Not the best situation imho. Multichill (talk) 18:40, 28 May 2010 (UTC)
Well you need to convince this someone first. Using subversion or any revision control tool is usually done by the developer. Esby (talk) 19:25, 28 May 2010 (UTC)

Commonist 0.4.13 doesn't work

I use Windows Vista Home Premium SP2 and Commonist 0.4.13. I can logged in without problems but upload after it doesn't start.

Dialog window under it write:

INFO logging in 
DEBUC HTTP POST http://commons.wikimedia.orgw/api.php HTTP/1.0 200 OK
DEBUG HTTP POST http://com.bons.wikimedia.org/w/api.php HTTP/1.0 200 OK 
INFO login successful: Ria
ERROR Exception caught in the Event Dispatch Thread 
java.lang.NoSuchMethodError: scala.collection.immutable.Range$ByOne.foreach$mVc$ 
sp (Lscala/Function1;)V 
	at scutil.ext.StringExt.splitAround(StringExt.scala:22) 
	at commonist.Parser$.parseCategories(Parser.scala:38)
	at commonist.task.UploadPilesTask.execute(UploadPilesTask.scala:61)
	at comonist.Task.comnonist$Task$$run(Task.scala:73) 
	at comonist.Task$$anon$1.run(Task.scala:29) 
	at java.lang.Thread.run(Unknown Source)</nowiki>

Can you help me please? Thanks, --Ria (talk) 09:31, 29 May 2010 (UTC)

I have the same problem. --Mike Krüger (talk) 11:56, 29 May 2010 (UTC)

i'll have a look what's wrong there. -- 84.153.61.114 13:49, 29 May 2010 (UTC)

sorry, 0.4.13 was compiled against a newer scala version, but still contained the old library. this is fixed now, 0.4.14 is online. -- 84.153.61.114 14:03, 29 May 2010 (UTC)

Login doesn't work corectly

Several weeks, I can't upload photos to commons. Commonist tells me "Could not login to wikimedia:commons." But I'm more than sure, I typed my username and password correctly. I tried c. 0.3.43-patched, 0.4.11 and 0.4.14 but any of that doesn't work correctly. --Daniel Baránek (talk) 22:06, 30 May 2010 (UTC)

interesting! 0.3.xx and 0.4.xx use completely different methods for login (screen scraping vs. api.php). did this work with any 0.4.xx version before? there should be a line like "login failed: ..." or "login error: ..." in the console window. could you post it here? -- 84.153.63.129 22:36, 30 May 2010 (UTC)

My last upload was 2010-04-21, I think with 0.3.43-patched. Console window:

...
INFO apple quithandler not installed
...
INFO logging in
DEBUG HTTP POST http://commons.wikimedia.org/w/api.php HTTP/1.0 200 OK
DEBUG HTTP POST http://commons.wikimedia.org/w/api.php HTTP/1.0 200 OK
INFO login failed: WrongPass

-- Daniel Baránek (talk) 23:04, 30 May 2010 (UTC)

0.3.xx doesn't output the line i talked above, sorry. however, it looks like apache's commons-codec library gets url-encoding your user name wrong: the "á" should afaik be encoded as %C3%A1, but in reality it is encoded as %EC%8E%A1 . the interesting part: this must have been wrong for years and i have no idea how it could have worked at all. i'll investigate further. -- 84.153.63.129 23:24, 30 May 2010 (UTC)
back to square one. my test-code was faulty and i have no idea what's going on here :( maybe your password contains some characters swing's textfield understands differently than your browser - are you on a mac? you could try changing your password to something less secure and try again. or you could try typing your password into another field (the username, for example) and see if it looks correct. in any case use 0.4.xx for further tests. -- 84.153.63.129 00:09, 31 May 2010 (UTC)

The problem was with the password, which contained asterisk. I have Ubuntu and it was no problem before 2010-04-21... So I changed my password. Thank's for your help :) --Daniel Baránek (talk) 07:50, 31 May 2010 (UTC)

Commonist doesn't load in Command Prompt

I've tried all other ways as I have in the past with Commonist but is this a different computer (the one which I have Commonist working is currently powerless[broken adapter])

This is what I get when I try to run it in Command Prompt (doesn't matter what dir it's [Commonist] in nor running [CP] it under an Admin) on Windows 7 (64 bit) with the latest stable JDK.

C:\Users\bidgee\Desktop\commonist-0.4.14\bin>commonist.bat

C:\Users\bidgee\Desktop\commonist-0.4.14\bin>rem change into the project direct
ory

C:\Users\bidgee\Desktop\commonist-0.4.14\bin>cd /d C:\Users\shirley\Desktop\com
monist-0.4.14\bin\

C:\Users\bidgee\Desktop\commonist-0.4.14\bin>cd ..

C:\Users\bidgee\Desktop\commonist-0.4.14>rem remove the -Xmx option if your VM
does not understand it

C:\Users\bidgee\Desktop\commonist-0.4.14>java -Xmx192m -cp build\classes;lib\sc
ala-library.jar;lib\bsh-2.0b2-fixed.jar;lib\minibpp.jar;lib\sanselan-0.97-incuba
tor.jar;lib\commons-httpclient-3.1.jar;lib\commons-logging-1.1.jar;lib\commons-c
odec-1.3.jar commonist.Commonist
'java' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\bidgee\Desktop\commonist-0.4.14>

Bidgee (talk) 09:31, 31 May 2010 (UTC)

This is from my desktop (rarely used for online use these days) using Windows Vista (32 bit) with the latest stable JDK. Unlike the laptop it does open Commonist but it is not showing images but only displays .recently-used.xbel.

H:\Windows\system32>cd H:\Users\Bidgee-PC\Documents\commonist-0.4.14\bin

H:\Users\Bidgee-PC\Documents\commonist-0.4.14\bin>commonist.bat

H:\Users\Bidgee-PC\Documents\commonist-0.4.14\bin>rem change into the project direc
tory

H:\Users\Bidgee-PC\Documents\commonist-0.4.14\bin>cd /d H:\Users\Bidgee-PC\Documents\c
ommonist-0.4.14\bin\

H:\Users\Bidgee-PC\Documents\commonist-0.4.14\bin>cd ..

H:\Users\Bidgee-PC\Documents\commonist-0.4.14>rem remove the -Xmx option if your VM
 does not understand it

H:\Users\Bidgee-PC\Documents\commonist-0.4.14>java -Xmx192m -cp build\classes;lib\s
cala-library.jar;lib\bsh-2.0b2-fixed.jar;lib\minibpp.jar;lib\sanselan-0.97-incub
ator.jar;lib\commons-httpclient-3.1.jar;lib\commons-logging-1.1.jar;lib\commons-
codec-1.3.jar commonist.Commonist
INFO    settings directory: H:\Users\Bidgee-PC\.commonist
INFO    using user language: en
INFO    apple quithandler not installed
INFO    starting up
INFO    loading
INFO    setting file does not exist: H:\Users\Bidgee-PC\.commonist\settings.propert
ies
DEBUG   clear
INFO    running
DEBUG   listFiles
WARN    could not read original: H:\Users\Bidgee-PC\.recently-used.xbel
DEBUG   cannot read file
        H:\Users\Bidgee-PC\.recently-used.xbel
        Can't parse this format.

Bidgee (talk) 16:14, 31 May 2010 (UTC)

"'java' is not recognized as an internal or external command, operable program or batch file." means there is no java executable in your PATH. either extend the PATH to include ht binary directory of your JRE, or replace the java command in bin/commonist.bat with the full path to the java.exe in this directory. or you could try to run the webstart version. just klick the "start" link on the website. about the old machine: i'm not sure what's wrong there. it should either display all files in H:\Users\Bidgee-PC\ or at least print some error message in the console. -- 84.153.51.130 20:24, 31 May 2010 (UTC)


Suggestion for changes

As I always add the missing headlines to image_wikimedia_commons.bpp manually, I'd like to suggest that the lines == {{int:filedesc}} == and == {{int:license}} == should be implemented in the next version.

#
#// encoding: UTF-8
#// in: common:Common, upload:Upload
#
# if (!upload.description.startsWith("{{Information")) {
== {{int:filedesc}} ==

{{Information
|Description=$(common.description)
$(upload.description)
|Source=$(common.source)
|Date=$(upload.date.trim().equals("") ? common.date : upload.date)
|Author=$(common.author)
|Permission=$(upload.permission)
|other_versions=
}}
# } else {
$(upload.description)	
#}
# if (upload.latitude != null && upload.longitude != null) {
{{Location dec|$(upload.latitude)|$(upload.longitude)|}}
# }

== {{int:license}} ==

$(common.licenseTemplate)
$(common.categories)
$(upload.categories)

I also like to suggest that it should be possible to change the licences.txt as easy as the wikis.txt. I know that many users have their own license templates or want to have templates from Commons:Copyright tags which are not listed. It's always somewhat embarassing to add personal license templates and for unexperienced users that's nearly impossible. So I did the job serveral times for other users but I consider it helpful if they were able to help themselves.

In addition I realised that the duplicate error isn't caught. It creates only an error note in the upload gallery but no request to upload the image anyway. So it is impossible to upload an image undet a correct name after it has been uploaded with a bad name and is still waitung for deletion. Greetings --Eva K. is evil 22:20, 29 May 2010 (UTC)

int:filedesc and int:license will be there in the next version. duplicate and duplicate-archive warning can be ignored in the next version. licenses.txt already can be changed just like wikis.txt by putting an own file in $HOME/.commonist/ -- 84.153.61.114 00:24, 30 May 2010 (UTC)
Thanks for the information. But in licences.txt in version. 0.4.11 you still have X'0A' as line feed which makes it difficult to edit with a standard text editor like Notepad. --Eva K. is evil 15:54, 1 June 2010 (UTC)
within $HOME/.commonist/licenses.txt or $HOME/.commonist/wikis.txt all three standards for line endings (LF, CRFL and CR) are supported. i just happen to use the linux/unix standard for internal files in etc/ which no user should have to change anyway. -- 84.153.127.192 23:42, 2 June 2010 (UTC)

Save/restart

I uploaded a bunch of images yesterday, but when my net-connection disappeared for a moment, Commonist had to be restarted. That meant I had to remove again some 70 dates that were wrong (date processed by renrot or Gimp instead of the date the picture was taken) as well as adding back some 70 coordinates. This would have been much easier if there was some kind of save/restart functionality in Commonist. Haros (talk) 09:19, 3 June 2010 (UTC)

I wish I had the ability to write and suggest a patch. It is important to me too. --ClemRutter (talk) 12:55, 3 June 2010 (UTC)
I would like to have this feature too. Rudolphous (talk) 19:17, 28 September 2010 (UTC)

Adding co-ordinates

Where it says "Specify geocoordinates here as comma-separated decimal values to put a Template:Location_dec template on the image description page", I don't understand what it means. How do you enter the values? Arriva436talk/contribs 10:10, 26 June 2010 (UTC)

I can't start it right now, but I'd guess as "28.2121,-177.3788"
- without the quotes ;)
Both values would be positive if the location is in Europe (and East of Greenwich)
This would generate {{location dec|28.2121|-177.3788|heading:SE}}
and displays as:
Camera location28° 12′ 43.56″ N, 177° 22′ 43.68″ W  Heading=135° Kartographer map based on OpenStreetMap.View all coordinates using: OpenStreetMapinfo
Hope this works.
It might be easier to use another tool to geocode the images before uploading them though. -- User:Docu at 10:42, 26 June 2010 (UTC)
OK, thanks for that. I shall give it a try next time. Arriva436talk/contribs 21:25, 27 June 2010 (UTC)
docu is right, this is how it works. or at least should work. -- 84.153.91.218 20:35, 28 June 2010 (UTC)

Update

Well, I tried, and it nearly worked, but unless the town of Redhill is now in the middle of a field, then it didn't quite work!

Can anyone tell me how to convert this {{Location|51|14|26.8|N|0|10|1.1|W}}, into something that I can put into Commonist so it uploads it properly? Arriva436talk/contribs 18:02, 7 July 2010 (UTC)

If you click on the link it creates when used without "nowiki", you should get two numbers, just below "WGS84". Otherwise, I think you could also paste that template in one of the boxes.  Docu  at 18:23, 7 July 2010 (UTC)
Oh, I forgot to say, I tried what you said and it worked perfectly. Thank you! Unfortunately, pasting the {{Location|51|14|26.8|N|0|10|1.1|W}} doesn't work, Commonist just ignores it and it doesn't get uploaded. Arriva436talk/contribs 18:11, 20 July 2010 (UTC)

Caution

When you enter decimal coordinates in Commonist, the result in the description is the camera location. For example, 39.943333|-75.19169 creates

Camera location39° 56′ 36″ N, 75° 11′ 30.08″ W Kartographer map based on OpenStreetMap.View all coordinates using: OpenStreetMapinfo

but if you want the location of the object photographed, go into edit after loading images and change it to Object location dec rather than Location dec, resulting in

Object location39° 56′ 36″ N, 75° 11′ 30.08″ W Kartographer map based on OpenStreetMap.View all coordinates using: OpenStreetMapinfo

. Object Location with the capital L does not work, so change it to lower case l when editing.--Davidt8 (talk) 14:21, 21 July 2010 (UTC)

heading

What's with the heading parameter (|heading=NNW)? If there is no support for this parameter I don't will use the commonist for geocoding. --Kolossos (talk) 11:02, 22 July 2010 (UTC)

Where does the heading parameter go? It does not appear in Template:Location/doc.--Davidt8 (talk) 12:25, 22 July 2010 (UTC)

Could not upload (null) error

Ive recently done some mass image editing and wanted to mass re-upload the images, however I am getting this error and dont know how to get around it. Any suggestions/advice to help me is welcome. Δ 04:44, 27 June 2010 (UTC)

I figured out this issue, but there should be an option when re-uploading to just upload and keep the licenses/page text the same. Δ 05:05, 27 June 2010 (UTC)
what exactly have you done, and where can i see the error message? -- 84.153.91.218 20:36, 28 June 2010 (UTC)

Missing coordinates

Yesterday, I have uploaded some files, but coordinates are missing. Whats wrong? See: User:Juan de Vojníkov/gallery.--Juan de Vojníkov (talk) 06:48, 13 June 2010 (UTC)

Using and on-line version for Windows setting cords via location template generated via GeoLocator.--Juan de Vojníkov (talk) 06:48, 13 June 2010 (UTC)
which files, and did the coordinates show up in the textfield? -- 84.153.91.218 20:33, 28 June 2010 (UTC)

For example all files from here: User:Juan de Vojníkov/gallery#Mon Jun 28 21:39:28 CEST 2010. And as you can see, they are not in the textfield.--Juan de Vojníkov (talk) 21:14, 29 June 2010 (UTC)

ok. since the images don't seem to contain GPS metadata themselves, you'll have filled the location field manually. what exactly did you put in there? the commonist does not accept an arbitrary string in the location, but only latitude and latitude as decimal values, separated by a comma. for example if you put -1,1 in the textfield it generates a {{Location dec|-1|1|}} template in the image description page. -- 84.153.59.167 12:06, 3 July 2010 (UTC)

Well, I dont know what happened, but before I have no problem with coords. The problem rose when I reported it. My coords looks like {{location dec|50.106206|14.428439|region:CZ_heading:S}} or {{location|50|6|22.39|N|14|25|42.4|E|region:CZ_heading:S}}.--Juan de Vojníkov (talk) 07:06, 6 July 2010 (UTC)

try putting 50.106206,14.428439 instead of {{location dec|50.106206|14.428439|region:CZ_heading:S}} into the coordinates field -- 84.153.106.4 23:16, 6 July 2010 (UTC)
I have just tested to put geodata in brackets into a description line and it went well (eg. this image: File:Autobusy na autobusovém nádraží v Gdansku.JPG. So there might be a wrong imput for coord line.--Juan de Vojníkov (talk) 16:55, 13 July 2010 (UTC)
Huh and as you recomended, I tried just the numbers (here: File:Trains at Danzig train station.JPG) and it worked. But would it be possible that this line also accepts the template? Or should we ask on GeoLocator they change their output?--Juan de Vojníkov (talk) 17:32, 13 July 2010 (UTC)

see below, putting a template into the coordinates field should work now. -- 84.153.127.89 23:08, 22 July 2010 (UTC)

OK, thx very much.--Juan de Vojníkov (talk) 12:36, 23 July 2010 (UTC)

IPTC data inside JPG files

Hello.

Commonist should be able to read IPTC data included in JPG files.

--ComputerHotline (talk) 15:02, 6 July 2010 (UTC)

and then do what with it? -- 84.153.106.4 23:16, 6 July 2010 (UTC)
Support IPTC data should complete all fields "name" and "description" automatically, like "coordinates" field. --ComputerHotline (talk) 07:30, 7 July 2010 (UTC)
i'll see what i can do, this may take a while. -- 84.153.127.89 22:58, 22 July 2010 (UTC)

Feature request

I only took my eye off the ball for a few minutes and suddenly- the server has been upgraded- and my beloved v 0.3.4 won't work! Naturally I found this out after doing 3.4 hours work- geo-tagging and describing etc, I then went to upload. So comrades, I would like to propose a new feature- on invoking the program- the first thing it attempts to do is logon (with a fictitious user-name ) to check the server hasn't been upgraded. On success, it will logoff and allow you to work.. on failure it will report either 'Server not accepting uploads from this client- do not edit' or 'Offline- proceed at you own risk'. But, also there will be a save to local option, and a reload from local option, to allow editors to save their draft work if the ip connection fails, and to recover it later. Have I said all this before-- yes but that was before the world changed in April 2010.--ClemRutter (talk) 23:49, 11 July 2010 (UTC)

local save of metadata is quite at the top of my todo-list. checking for server upgrades, though, seems a lot less important to me than it was before 0.4.x: the api.php is made for computers and as such incompatible changes should be rare, at least in contrast to the Special:Upload which is made for humans. -- 84.153.127.89 23:04, 22 July 2010 (UTC)

Feedback 0.4.15

Adding a raw location tag which I have set up on a bookmarklet- fails. I still have to post the location in the text box.

My gallery was bust. Eric Baas believes I had too many gallery tags so the server fell over. (Yes, using Commonist too much). I uploaded a file- it worked- but sent a 500 error message and couldn't update gallery.

  • I uploaded another file- it worked- but sent a 500 error message and couldn't update gallery.
  • I just saw the error message and uploaded it again. It told me the file existed- did I wish to overwrite. I probably said no- it said but sent a 500 error message and couldn't update gallery. And a FAILED message appeared on the UI.
  • I followed Erics advice and moved the gallery to gallery0, and tested to see if the Commonist would now write to gallery and not throw a 500.
  • I uploaded a third file- 30% through the upload, I realised that the file name was wrong. I pressed the abort button. THE FILE WAS UPLOADED BUT the gallery was not- but I didn pull an error message.
  • I renamed the file and uploaded it. I got a message saying the file was a duplicate- did I wish to proceed. I said no- the file was not uploaded, but a error message was written to my gallery- then the entry for the file I hadn't uploaded with a redlink.The UI said the upload failed.
  • I added a new file, and uploaded the renamed file and the new file. I got a message saying the file was a duplicate- did I wish to proceed. I said YES. Both files uploaded and updated the gallery

From this I conclude.

  • ABORT doesn't work
  • gallery updating can only be done a limited number of time and datestamped gallerys may be better ie /gallery2010-06 /gallery2010-07
  • The UI uploaded/failed messages still need some work


/gallery issue

I include the dialog from Help Desk

For some years my /gallery has been blank. This has not worried me: I don't do vanity, but it is now confusing Commonist uploads so if I can fix it perhaps I should. User:ClemRutter/gallery is the file- can anyone say how I can clear the glitch- or what caused it? --ClemRutter (talk) 11:40, 17 July 2010 (UTC)

I think the page contains too many "gallery" tags and the server can not process it anymore. You can see the data here, so you could split it up into smaller pages. A simpler solution is to change the title so Commonist can use the new (now blank) page. ;-) - Erik Baas (talk) 13:34, 17 July 2010 (UTC)
Thanks, I have done a rename- /gallery0. It works and Commonist is happy. I still fail to load edit hint using Firefox 3.5.9 on Ubuntu but wont try again. --ClemRutter (talk) 16:25, 17 July 2010 (UTC)

if abortion doesn't work, this is a bug. i'll have to investigate. overflowing galleries are at least a nuisance, but littering a users with a separate page for every upload would be worse. maybe the commonist could move away gallery pages automatically if they grow above a certain limit. -- 84.153.127.89 23:07, 22 July 2010 (UTC)

coordinates copied verbatim

since 0.4.16 if the coordinates are not in the number,number format, the content of the field will be copied verbatim to the image description page. this means you can copy a complete location_dec or object_location_dec template into the coordinates field. -- 84.153.127.89 22:55, 22 July 2010 (UTC)

Commonist failing to upload 8 images.

I tried to upload 8 images today which I haven't yet uploaded with Commonist or otherwise and instead of uploading them it simply tagged them all in an instant as "uploaded" and stated that my gallery page has been updated (it wasn't).

I tried removing all Commonist files from my computer and thus sort of "restarting" it but it still refuses to upload my files.

One thing that I can think of is that there was some kind of "update" done when I run Commonist today and I think it has something to do with it not working. I remember that this update had the same web address as Commonist but the publisher name was different (unfortunately I didn't pay enough attention to remember it and didn't take any screenshots). Suspicious I canceled it but Commonist refused to run without completing this "update".

Regards. - SuperTank17 (talk) 17:48, 23 July 2010 (UTC)

sorry, i left a debug flag set which disables uploads for testing purposes. this is fixed in 0.4.17 now. -- 84.153.127.89 18:50, 23 July 2010 (UTC)

Great feature request

HI, I always spend more time for renaming files than uploading it... It could be really great if Commonist enable massive rename. Otourly (talk) 15:46, 25 July 2010 (UTC)

If you use Linux, there is a tool - renrot - that can do that, and much much more. I use it, and let it add a copyright section to the exif. All renaming is one command in a terminal for all of the files needed. It is probably possible to install it on windows too, but I have not tried. Haros (talk) 18:49, 25 July 2010 (UTC)
So, how renrot work ? Otourly (talk) 20:48, 25 July 2010 (UTC)
My last usage of it consisted of this line:
renrot -n 'Skivholme Kirke %Y%m%d-%c' -e jpg --tag Copyright:'Hans A. Rosbach/CC-BY-SA-3.0' IMG* --counter-start 1
Some of the resulting files were uploaded to Category:Frescos in Skivholme Kirke. Note that the history of the terminal let me change only the relevant part each time, I don't have to remember the complete sentence. renrot --help will give you information. The suggestion by ClemRutter below is another one you should consider. Haros (talk) 07:10, 27 July 2010 (UTC)
Look at Thunar Bulk Rename (Linux) a simple but effective tool that runs under Gnome.--ClemRutter (talk) 23:17, 26 July 2010 (UTC)

Win7 problems

Has compability with Windows 7 been confirmed? Uploaded the latest version, tried to launch, nothing. It launched a small window with black bg and some text, but it was only a flash and way too quick for me to see what it was. Pitke (talk) 08:04, 3 August 2010 (UTC)

i've never tried it, but the commonist should run anywhere a suitable java vm is available. did you try using webstart? -- 84.153.46.53 22:34, 3 August 2010 (UTC)
Yeah, and it offered to be saved or run. Couldn't run it though. Pitke (talk) 05:21, 4 August 2010 (UTC)
sounds like a broken or misconfigured java installation. if you call java -version in a cmd window, what does it say? and what does it say if you execute bin\commonist.bat in a cmd window? -- 84.153.53.12 14:07, 5 August 2010 (UTC)
It doesn't know anything about that Java command. Same with the launch command. Attempted to launch commonist.bat as the admin, but it did the same as always. I reinstalled Java after I saw http://www.javatester.org/version.html didn't recognise my version, and now it does. Commands still no working though. Commonist.bat acting the same way as ever. Webstart works now! Thanks for your help. Pitke (talk) 15:33, 5 August 2010 (UTC)
it should. you could add the path of the directory containing the the java command (whereever it is located on your system) to the environment variable named PATH. or replace the java command in the bin/commonist.bat with the full path of the java command. -- 84.153.51.223 21:54, 6 August 2010 (UTC)
Yet one more question. The software's in Finnish of all languages! It's my native tongue, yes, but I've always used the Commons in English and all the Finnish-ised terminology fries my brain. Is there a way to change the user surface's language...? Pitke (talk) 15:36, 5 August 2010 (UTC)
yes, but it's a dirty hack. first, find the so-called "settings directory" as described on http://djini.de/software/commonist/ . then copy the file etc/messages_en.properties from the zipfile into the settings directory and rename it to messages_fi.properties. -- 84.153.51.223 21:54, 6 August 2010 (UTC)

Very small fix request

Thanks for the new version, it works fine. Could you please change it so that categories that are entered manually in the right area are placed on a single line each in the Wiki source code? Now, it looks like this:

[[Category:Houses]][[Category:Berlin]][[Category:2010]]

It should look like this:

[[Category:Houses]]
[[Category:Berlin]]
[[Category:2010]]

Also I'd like an option to overwrite the chosen license on the left, by another licence (much more than the "Permission" field, which is mostly unused anyway.). --AndreasPraefcke (talk) 14:12, 11 August 2010 (UTC)

done and done, 0.4.18 is online now -- 84.153.70.55 23:13, 11 August 2010 (UTC)
Wow. Great, thank you very much. --AndreasPraefcke (talk) 18:10, 16 August 2010 (UTC)

Automatic date retrival is bad

Hi, I have just noted that automatic date retrival works bad, because it takes to commonist the date of modification, not the date of creation. Could it be fixed?--Juan de Vojníkov (talk) 21:49, 19 August 2010 (UTC)

Or was it an intetion?--Juan de Vojníkov (talk) 12:09, 22 August 2010 (UTC)
With that caveat- that feature has just saved me hours! I think it is good practice- not to modify your master image- but to change a copy of that image, then the real date is retrieved from the master. I can't think of a situation where the modification date of the image will be useful as it will always be the date of creation that will need to be reported.--ClemRutter (talk) 13:06, 24 August 2010 (UTC)

Doesn't work

Hi, I've tried for hours to start this but it just doesnt seem to work. I've tried this link: http://djini.de/software/commonist/ws/commonist.jnlp and to install it at http://djini.de/software/commonist/ . I use both Firefox and Explorer, Windows 7, and I have Java installed. Can you explain how to do it, so a computer dummy understands it too? 78.79.2.143 22:21, 27 August 2010 (UTC)

in theory it should suffice to click the link to the jnlp-file. if it doesn't, i need more information, for example if there are any error messages in the console. -- 84.153.97.229 00:40, 7 September 2010 (UTC)

template artwork

User:Thesupermat asked me if {{Artwork}} could be used with Commonist. Can it ? If not, would it be difficult to make Commonist accept alternative infoboxes ?--Zolo (talk) 15:41, 13 September 2010 (UTC)

it's possible, but not in a very userfriendly way: you'd need to put a copy af the the image_wikimedia_commons.bpp template into the "settings directory" $HOME/.commonist and adapt it to use {{Artwork}} instead of {{Information}} -- 84.153.47.47 13:02, 18 September 2010 (UTC)

Commonist does not work in Spanish language Windows

I've tried to download at least two versions of Commonist, but it refuses to work on my Spanish-lang version of Windows. What can I do? Diego Grez return fire 21:36, 21 August 2010 (UTC)

Check that you have the right version of java already installed on your machine. --ClemRutter (talk) 13:13, 24 August 2010 (UTC)
Nope. I got the latest version from Java, and this is what the command line says: --Diego Grez return fire 00:08, 6 September 2010 (UTC)
Microsoft Windows XP [Versión 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrador>D:\Descargas\commonist-0.4.15\bin\common
ist.bat

C:\Documents and Settings\Administrador>rem change into the project directory

C:\Documents and Settings\Administrador>cd /d D:\Descargas\commonist-0.4.15\bin\


D:\Descargas\commonist-0.4.15\bin>cd ..

D:\Descargas\commonist-0.4.15>rem remove the -Xmx option if your VM does not und
erstand it

D:\Descargas\commonist-0.4.15>java -Xmx192m -cp build\classes;lib\scala-library.
jar;lib\bsh-2.0b2-fixed.jar;lib\minibpp.jar;lib\sanselan-0.97-incubator.jar;lib\
commons-httpclient-3.1.jar;lib\commons-logging-1.1.jar;lib\commons-codec-1.3.jar
 commonist.Commonist
INFO    settings directory: C:\Documents and Settings\Administrador\.commonist
INFO    using user language: es
ERROR   cannot start program
java.lang.IllegalArgumentException: can't parse argument number e
        at java.text.MessageFormat.makeFormat(Unknown Source)
        at java.text.MessageFormat.applyPattern(Unknown Source)
        at java.text.MessageFormat.<init>(Unknown Source)
        at java.text.MessageFormat.format(Unknown Source)
        at commonist.util.Messages.getMessage(Messages.scala:33)
        at commonist.util.Messages$.message(Messages.scala:22)
        at commonist.ui.ImageListUI.updateSelectStatus(ImageListUI.scala:115)
        at commonist.ui.ImageListUI.<init>(ImageListUI.scala:90)
        at commonist.CommonistMain.<init>(CommonistMain.scala:84)
        at commonist.Commonist$$anonfun$main$1.apply$mcV$sp(Commonist.scala:16)
        at scutil.SwingUtil$$anon$2.run(SwingUtil.scala:11)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

D:\Descargas\commonist-0.4.15>
ah, together with the stacktrace your report made sense: there has been a typo in messages_es.properties. the bug should be fixed in 0.4.19 now. -- 84.153.97.229 00:39, 7 September 2010 (UTC)
Thanks! --Diego Grez return fire 20:08, 18 September 2010 (UTC)

geocoding and date extraction not working

Sadly the author is not respond to emails. So I post this here:

  1. GPS-Koodrinates are not read at all in many cases. See this commonist 0.4.17 uploaded file which got localized by dschwenbot afterwards: File:Serengeti_Kongoni2.jpg
  2. Commonist puts the actual date instead of the date when the image was taken. It would be nice if Commonist would read this info from exif:DateTimeOriginal or exif:DateTimeDigitized

. --Ikiwaner (talk) 18:14, 16 September 2010 (UTC)

i'll have a look into the missing coordinates. using a different source for the date should be simple. -- 84.153.47.47 20:35, 17 September 2010 (UTC)
the commonist now reads exif:DateTimeOriginal or exif:DateTimeDigitized in addition to exif:DateTime. the first one found is used. additionally, the exif:ImageDescrption tag is now read to fill the description field. the GPS problem should be fixed now. -- 84.153.47.47 00:08, 18 September 2010 (UTC)
Thanks a lot! The picture mentioned above now works correctly. The reading of the file description is really a huge improvement. --Ikiwaner (talk) 07:55, 18 September 2010 (UTC)

Support GFDL-1.2

Please add {{GFDL-1.2}} to the list of licenses. --Ikiwaner (talk) 07:55, 18 September 2010 (UTC)

i've added it. if you need it before 0.4.21 is out, you can of course copy licenses.txt into $HOME/.commonist/licenses.txt and add the license there. -- 84.153.47.47 13:06, 18 September 2010 (UTC)
Thanks --Ikiwaner (talk) 16:54, 18 September 2010 (UTC)

2 additions to the general upload settings

Is it possible to add the permission field, which is currently only in the upload forms, to the general upload settings and have {{PD-USGov-Military}} as one of the licenses? BrokenSphere (Talk) 14:40, 8 October 2010 (UTC)

{{PD-USGov-Military}} is available in 0.4.21 -- 84.153.46.16 20:01, 11 October 2010 (UTC)
Thanks! How efficacious would it be to have all the specific PD templates for all US military service branches (Army, Navy, Air Force, Marines, Coast Guard)? All of these (except the Coast Guard) would fall under the overall US military PD tag, but personally I like to be specific as to who was the original author. BrokenSphere (Talk) 20:42, 11 October 2010 (UTC)
add another permission field, or would it make sense to move it from the individual upload to the general upload settings? i'd prefer the latter -- 84.153.46.16 20:02, 11 October 2010 (UTC)
I am fine with a move. I use a customized permission template and having to copy it for each individual upload is tedious. BrokenSphere (Talk) 20:13, 11 October 2010 (UTC)
ok, done in 0.4.22 -- 84.153.58.197 20:57, 12 October 2010 (UTC)

ML Wiki

Will you able to add ml wiki (Malayalam) to the list of wiki's for upload...--KALARICKAN | My Interactions 20:29, 8 October 2010 (UTC)

ml.wikipedia.org is available in 0.4.21 -- 84.153.46.16 20:01, 11 October 2010 (UTC)
How can i download webstart for mac...any link..seems that its not working..--KALARICKAN | My Interactions 08:23, 12 October 2010 (UTC)
webstart should be preinstalled with OSX. i'm sorry, but 0.4.21 did not work with java 1.5 at all; this would explain your problem. a new 0.4.22 build is online, could you try if it works now? -- 84.153.58.197 20:57, 12 October 2010 (UTC)
OK its working now--KALARICKAN | My Interactions 12:27, 15 October 2010 (UTC)

Commonist reporting errors to MediaWiki.org

Please tweak it not to post error logs (example: page title User:<username>/gallery, edit summary commonist 0.4.22, 4 errors) to MW.org, it's offtopic there. Meanwhile I'll block it with AbuseFilter. Max Semenik (talk) 09:57, 15 November 2010 (UTC)

Please be a good bug reporter and include one or more examples of this behaviour. Multichill (talk) 21:52, 15 November 2010 (UTC)
yeah, i'd like to see an example, too. <username> did upload images to mediawiki.org, right? -- 84.153.44.212 21:37, 16 November 2010 (UTC)
No uploads, just the gallery. For example, at mw:User:Miva85/gallery there was the following content:

Problem to start commonist under java 1.6.0_22 and windows vista

A french user is reporting to me that is unable to start commonist under java 1.6.0_22 and windows vista. http://www.pastebin.com./kFxwQqiv Any hint to solve the issue? Esby (talk) 09:57, 20 November 2010 (UTC) : from the paste i conclude this was with version 0.4.20, can you try to reproduce this error with the current version 0.4.22, please? -- 84.153.45.144 16:55, 20 November 2010 (UTC) :: It works, thanks a lot prosopee (talk) 10:57, 25 November 2010 (UTC)

Installing commonist

:Any help you give me I will add to the mediawiki commonist page, which will help countless others! :My two computer systems which I tried this on: ::Windows Vista 32 bit (terrible program) and Windows 7 I already have an updated 6.0 version of java. 1. Download the two files. (not mentioned in the mediawiki tutorial): * commonist-0.4.23-bin.zip binary * commonist-0.4.23-src.zip sourcecode 2. Extract both the binary and sourcecode files to your desktop. [8] :The mediawiki instructions on this are incomplete and I need to rewrite. Combining both the commonist page and mediawiki instructions I did the following 3. Open Start >> run [9] 4. Type cmd.exe and click OK [10] 5. Change the directory to c:\ by typing chdir c:\ [11] 6. Find the location of the bin folder. [12] 7. In the cmd window, change the directory to the folder where you located the bin folder. Type cd followed by the location of commononist.bat on your computer. [13] 8. Type in bin/commononist.bat and press enter. [14] This is where I commonist.bat and myself get stuck. What next? There are obvious errors in what is displayed. Adamtheclown (talk) 20:07, 21 November 2010 (UTC) : the problem is the blanks in your wiki name as the WARN from the parser, some lines before the ERROR, says. try using "DeadRisingWiki" instead of "Dead Rising Wiki". the ERROR only occurs because i didn't properly handle the case where a wikis.txt does not contain even a single valid entry. and, as i wrote in the above section, if you get the wikis.txt right you should be able to use the webstart version, too. -- 84.153.81.225 01:51, 25 November 2010 (UTC)