Hi there,
I was notified that ComeOn! was discussed here. I'm the author :-) Thank
you for your intereste in my humble tool.
ComeOn! used to work with OpenJDK. I did not check lastly though, but it
has no dependency on Oracle's proprietary parts of the JDK and works with
Oracle's JDK 8. Java Web Start might be a pain
I'm aware the most interesting part of the documentation part is missing.
It was not such a problem as long as I was the only user, but times are
changing. I'll do my best to write this part soon, but time is the critical
resource. I'll try to send you later an exemple of how to use the feature.
BR,
Édouard
Hi all,
I was wondering if anyone has ever used the ComeOn! upload tool to
batch-upload images to Commons? It does not have a separate page on Commons
but the page on GitHub is https://github.com/edouardhue/comeon and it seems
quite useful for smaller uploads.
Best,
Arne Wossink
Projectleider / Project Lead Wikimedia Nederland
Tel. +31 (0)6 11000505
(di, wo, do)
*Postadres*: * Bezoekadres:*
Postbus 167 Mariaplaats 3
3500 AD Utrecht Utrecht
@Arne and experts:
We can overwrite a file with GWToolset provided no other user has edited
the file. Perhaps experts are aware of further options with GWT for
overwriting files.
Examples:
1. GWToolset overwriting with a different resolution succeeded for
https://commons.wikimedia.org/wiki/File:Naturalis_Biodiversity_Center_-_RMN…
checking the box "Reload media from URL" down the page. The new resolution
is considered a new version. (Here a downgrade as a test.) The old version
remains available.
2. GWToolset overwriting failed for
https://commons.wikimedia.org/wiki/File:Naturalis_Biodiversity_Center_-
>> _RMNH.MOL.216649_-_Mitra_aurantia_aurantia_%28Gmelin,_1791%29_-_Mitrida
>> e_-_Mollusc_shell.jpeg
with or without that box checked because
"A media file with the identical title "File:Naturalis Biodiversity
Center - RMNH.MOL.216649 - Mitra aurantia aurantia (Gmelin, 1791) -
Mitridae - Mollusc shell.jpeg" already exists in the wiki. It was edited
or created by someone other than you"
- another user had edited the categories.
Best regards, hans muller
https://commons.wikimedia.org/wiki/User:Hansmuller
Op Do, 17 december, 2015 12:39 pm schreef Arne Wossink:
> @Hans,
>
>
> Thanks for the input so far. Please keep me updated on that overwrite. If
> anything, it is once again a reminder that these things must be done
> right the first time around ;)
>
> Best,
>
>
>
> Arne Wossink
>
>
> Projectleider / Project Lead Wikimedia Nederland
>
>
> Tel. +31 (0)6 11000505
> (di, wo, do)
>
>
> *Postadres*: *
> Bezoekadres:*
> Postbus 167 Mariaplaats 3
> 3500 AD Utrecht Utrecht
>
>
> 2015-12-17 12:34 GMT+01:00 Hans Muller <j.m.muller(a)hccnet.nl>:
>
>
>> We're talking about
>>
>>
>>
>> https://commons.wikimedia.org/wiki/Category:Media_contributed_by_Museum
>> _Catharijneconvent
>>
>>
>> ? Main uploader there was HuskyBot i think.
>>
>>
>> I made a mistake some months a go while uploading photographs of dead
>> bird skins for Naturalis with GWToolset with various views for the same
>> specimen uploaded under the same filename. So that is like uploading a
>> higher resolution, an image with a different checksum under the same
>> name. You see the result here:
>>
>>
>>
>> https://commons.wikimedia.org/wiki/File:Naturalis_Biodiversity_Center_-
>> _RMNH.AVES.101712_-_Corvus_enca_compilator_Richmond,_1903_-_Corvidae_-_
>> bird_skin_specimen.jpeg
>>
>> (scroll down)
>> Later uploads under the same filename by GWToolset were accepted as new
>> versions. Caveat: the uploader was the same user for these various
>> "versions".
>>
>>
>> Best regards, hansmuller
>>
>>
>> PS At the end of my present batch (18/12 morning?) GWToolset is
>> requested to overwrite medium resolution
>>
>>
>> https://commons.wikimedia.org/wiki/File:Naturalis_Biodiversity_Center_-
>> _RMNH.MOL.216649_-_Mitra_aurantia_aurantia_%28Gmelin,_1791%29_-_Mitrida
>> e_-_Mollusc_shell.jpeg
>>
>> with large, so we'll see. I can put up a test image to test if another
>> GWToolset user can overwrite
>> it (?). I don't think so, this might be Arnes problem.
>>
>>
>>
>>
>> Op Do, 17 december, 2015 11:30 am schreef Jesse de Vos:
>>
>>> Hi Arne,
>>> I actually don't think this can be done. It is an action in which an
>>> existing file on Commons must be updated, this is not supported by the
>>> toolset. We had a similar issue with higher res. Video files. We
>>> decided to stick with the current resolution. Alternatively, a
>>> volunteer could do this update using a script. Best, Jesse
>>>
>>>
>>>
>>> verzonden vanaf mijn smartphone|sent from my smart phone Op 17 dec.
>>> 2015
>>> 11:03 schreef "Hans Muller" <j.m.muller(a)hccnet.nl>:
>>>
>>>
>>>
>>>> Dear Arne,
>>>>
>>>>
>>>>
>>>> Yes, this is a modest batch that can be done with the GW toolset,
>>>> most easily if the images each have a (temporary) individual URL and
>>>> so are accessible on the internet.
>>>>
>>>> Groeten, hans muller
>>>>
>>>>
>>>>
>>>> Op Do, 17 december, 2015 10:57 am schreef Arne Wossink:
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Museum Catharijneconvent has approached us that they would like
>>>>> to make higher-resolution versions available of images that are
>>>>> already available on Commons. Around 800-1500 images are involved.
>>>>>
>>>>>
>>>>> Is this something that can be handled by the GW toolset, or are
>>>>> there better ways to do this?
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Arne Wossink
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Projectleider / Project Lead Wikimedia Nederland
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Tel. +31 (0)6 11000505
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Postadres*: *
>>>>> Bezoekadres:*
>>>>> Postbus 167
>>>>> Mariaplaats
>>>>> 3
>>>>> 3500 AD Utrecht Utrecht
>>>>> _______________________________________________
>>>>> Glamtools mailing list
>>>>> Glamtools(a)lists.wikimedia.org
>>>>> https://lists.wikimedia.org/mailman/listinfo/glamtools
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Glamtools mailing list
>>>> Glamtools(a)lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/glamtools
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Glamtools mailing list
>>> Glamtools(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/glamtools
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Glamtools mailing list
>> Glamtools(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/glamtools
>>
>>
> _______________________________________________
> Glamtools mailing list
> Glamtools(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/glamtools
>
>
Hi all,
Museum Catharijneconvent has approached us that they would like to make
higher-resolution versions available of images that are already available
on Commons. Around 800-1500 images are involved.
Is this something that can be handled by the GW toolset, or are there
better ways to do this?
Best,
Arne Wossink
Projectleider / Project Lead Wikimedia Nederland
Tel. +31 (0)6 11000505
*Postadres*: * Bezoekadres:*
Postbus 167 Mariaplaats 3
3500 AD Utrecht Utrecht
We published a learning pattern in english and german with a focus on the
GWToolset. Share it if you think it's useful:
https://meta.wikimedia.org/wiki/Grants:Learning_patterns/Data_transfers_to_…
Regards Nico
--
Nicolas Rück
Ideenförderung
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
So about a week ago, there was a thread about tiff files not working
as well as they should. Here's a status update:
The good news:
The 16-bit greyscale tiff files not rendering bug (T116947) is now
fixed and the fix is live on commons. This affected a lot of images
from the library of congress. Previously they showed up as either all
black, or mostly white with a couple black lines. Now they work.
The more meh news:
We've identified a fix for the issue where pages after the first page
of a large tiff do not render (T117349). This is a good step forward,
but the fix is currently stuck pending review and I'm not sure what
time frame the fix will be reviewed in.
Tiff (and djvu) files on the beta cluster do not render (T116816). The
people who maintain the beta cluster have put it on their list of next
things to do. So hopefully it will be fixed soon. In the mean time, if
you really need to see what a tiff would look like uploaded but don't
want to put it in real commons, you can use test.wikipedia.org (but
alas, gwtoolset does not work in that domain)
--
-bawolff
p.s. Fun fact that might interest the Basel University Library folks -
If you order all the tiffs on commons by file size, 18 of the top 20
are from Basel University Library.
Hi everyone,
We’re trying to get a clearer picture of what material we have on Wikimedia
Commons so that our next batch upload doesn’t duplicate with material that
is already on Commons. The category: Media from Open Beelden contains all
the files and we would like to have all the metadata on Commons for that
category (specifically the 'source' URL) to match against our new content
upload.
Does anyone know how to gather this using the Commons API? Basically, a
call to the API with the “File:title
<file:///Applications/Colloquy.app/Contents/Resources/Styles/Standard.colloquyStyle/Contents/Resources/title>”
field that would return a JSON object with all the metadata is exactly what
we need. Help would be much appreciated!
Best,
Jesse
--
Met vriendelijke groet,
*Jesse de Vos*
Researcher Interactive and New Media
*T* 035 - 677 39 37
*Aanwezig:* ma t/m do
<http://www.beeldengeluid.nl/>
*Nederlands Instituut voor Beeld en Geluid*
*Media Parkboulevard 1, 1217 WE Hilversum | Postbus 1060, 1200 BB
Hilversum | *
*beeldengeluid.nl* <http://www.beeldengeluid.nl/>
Link: https://commons.wikimedia.org/wiki/Commons:Bureaucrats'_noticeboard#Rights_for_GLAM_group_accounts
I have raised this question on the Bureaucrat's noticeboard. As not
that many people watch that page, I'm flagging it on this email list,
though if you would like to join in with discussion on how GLAM group
accounts ought to be accountable, especially for GWT access, it would
probably help to respond on commons even if you want to email about it
first here. :-)
Here's the text of my post:
== Rights for GLAM group accounts ==
Hi, though on Commons we (the community) can accept group accounts
being run, my understanding is that the intention is that there must
be ''a responsible and accountable individual'' that runs the account
at the time specific edits are made. By granting significant rights to
apparent group accounts, we run a far greater risk that later
inexperienced users will inherit the account for later projects
without this being publicly declared, and without a chance for the
community to ask questions about their intentions, or to double check
whether new projects are still in-scope, or that appropriate thought
has been given to the policies that apply (such as for the best
licenses or templates to use). There is a risk that later "account
owners" will not be responsible for past projects/edits by earlier
owners; when they accept rights for the account it probably would be
beneficial to spell out that the community will expect them to remain
responsible for all edits made, and be prepared to answer questions
that arise from earlier projects.
I am not suggesting that we should stop allowing group accounts asking
for rights, but there appears to be no questioning before handing out
significant rights as to how they will be managed by the institution
long term. If the intended projects are time-limited (as GWT uploads
have invariably been in the past), then I see no harm in encouraging a
''project'' based name, or even better ''project manager + project
name'' account in preference to a permanent and open-ended institution
account. This way if later projects pop up, the institution
representative or new project managers need only ask for further
accounts to have similar rights on the same basis as the original
request.
(Tangent) It is worth considering that our norm for being tolerant of
anonymity is rarely an issue for official representatives of
institutions and may even be confusing or detrimental if issues arise
with edits from such accounts.
Thanks
Fae
--
faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae
_-_Mitridae_-_Mollusc_shell.jpeg){kind=link}
