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
Réf.: 0090 Sigma
Dear Colleagues,
I represent the Jura Cantonal Archives in Switzerland and we are are currently collaborating with Wikimedia CH and the Swiss federal Archives to upload a set of 3000 pictures with their metadata.
We need to upload the set by the end of the year.
So as I am following the guidelines for using the GWToolset I am asking the community of users the rights to use the toolset on the Beta server for testing.
Thank you in advance fort he quick answer
Best regards
G. Yildirim
République et Canton du Jura
Office de la culture
Archives cantonales jurassiennes (ArCJ)
Mme Gülsen Delia Yildirim
Archiviste cantonale adjointe
T +41 32 420 8418
www.jura.ch/ArCJ<www.jura.ch/occ/ArCJ>
Adresse :
Hôtel des Halles
Case postale 64
CH-2900 Porrentruy
Hi,
We are currently uploading old maps (2000 already uploaded total of 8000).
We found out that there are some changes we would like to make in their
metadata.
Is it ok to fix my own uploads with my own bot *without* bot account? Or
should I start the process of getting a bot account?
Sorry if this is not right place to ask. I tried to ask this in IRC but I
didn't know who to ping.
Regards,
Ari Häyrinen
Wikimedia Finland
user: artturimatias
Sent from my Debian.
http://www.opendimension.org/