> > The first three we can get from pretty much either API, or extract
>> directly from
>> > a dump file. The latter is eluding us though, for two reasons. One is
>> that a
>> > file, like 30C3_Commons_Machinery_2.jpg, is actually in the /b/ba/
>> directory -
>> > but where this /b/ba/ comes from (a hash?) is unclear to us now, and
>> it's not
>> > something we find in the dumps - though we can get it from one of the
>> APIs.
>>
>
> Yes, /b/ba ist based on the first two digits of the MD5 hash of the title:
>
> md5( "30C3_Commons_Machinery_2.jpg" ) -> ba253c78d894a80788940a3ca765debb
>
> But this is "arcane knowledge" which nobody should really rely on. The
> canonical
> way would be to use
>
> https://commons.wikimedia.org/wiki/Special:Redirect/file/30C3_Commons_Machi…
>
> Which generates a redirect to
>
> https://upload.wikimedia.org/wikipedia/commons/b/ba/30C3_Commons_Machinery_…
>
> To get a thumbnail, you can directly manipulate that URL, by inserting
> "thumb/"
> and the desired size in the correct location (maybe Special:Redirect can
> do that
> for you, but I do not know how):
>
>
> https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/30C3_Commons_Mach…
>
If I am not mistaken you can use thumb.php to get the needed thumb?
<https://commons.wikimedia.org/w/thumb.php?f=Example.jpg&width=100>
(That’s what I used in my CommonsDownloader [1])
[1] <
https://github.com/Commonists/CommonsDownloader/blob/master/commonsdownload…
>
Hope that helps,
--
Jean-Frédéric
Hi Jonas,
Awesome project!
I’m cc-ing the WMF Multimedia team, who might have some more answers :)
2014-09-04 12:26 GMT+02:00 Jonas Öberg <jonas(a)commonsmachinery.se>:
> Dear all,
>
> some of you may have been at our presentation during Wikimania and you'll
> find this familiar, but for the rest of you, I'm working with Commons
> Machinery on software that will hope to identify images on the web, even
> when they are used outside of their original context, to provide automatic
> attribution and a referral back to its origin. Imagine a blogger using a
> photo from Commons, visiting that blog and having a browser plugin overlay
> a small icon showing that the image is from Commons and inviting to find
> out more - even if the blogger forgot to attribute.
>
> We're currently working on an addon for Firefox to do just this, and we've
> previously worked out a backend to store the information we need to make
> these matches, some utilities for perceptual image hashing etc. We would
> love to work with images from Wikimedia Commons as a first dataset to
> explore how this will all work in practice.
>
> But in order to do so, we need information from Commons, and we want to
> make this as easy on the WMF servers as possible, so we'd appreciate some
> help and pointers. What we're looking at retrieving is information about
> (1) title, (2) author, (3) license, and (4) thumbnails of medium size.
>
> The first three we can get from pretty much either API, or extract
> directly from a dump file. The latter is eluding us though, for two
> reasons. One is that a file, like 30C3_Commons_Machinery_2.jpg, is actually
> in the /b/ba/ directory - but where this /b/ba/ comes from (a hash?) is
> unclear to us now, and it's not something we find in the dumps - though we
> can get it from one of the APIs.
>
> The other is thumbnail sizes. We need to retrieve a reasonably sized image
> (but in many cases less than the original size) of about 640px wide, so
> that we can then run a perceptual hash algorithm on this file.
>
> From what we can understand, you can request any size thumbnail on an
> image simply by prefixing it with the size you want (like
> 123x-Filename.jpg). But it seems really silly to always request 640x for
> instance, since that would mean the WMF servers would need to generate that
> for us specifically if the resolution doesn't exist.
>
> What we'd find much more appealing is to be able to determine before
> making the call what sizes already exist and which can be retrieved without
> the WMF servers needing to rescale them for us. And while the viewer on
> Commons do seem to offer thumbnails in various sizes, we can't seem to get
> that information from any API.
>
> We can scrape the Commons web page for this information, but we figured
> that people here might have good ideas for how we approach this with
> minimal impact on the WMF servers :)
>
> Sincerely,
> Jonas
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>
>
--
Jean-Frédéric
thanks for the list email, I must have typed it wrong and it bounced, so I
emailed you guys directly.
Things I'm interested in…
- Abandon rate (and where a user is in the process)
- browse button vs drag and drop usage
- frequency that the page returns an error, and what that error is (we
still don't have all required fields marked as required)
- frequency of users expanding/adding additional information beyond the
defaults (extra languages, additional categories)
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M +1 415 609 4043 \\ @jaredzimmerman <http://loo.ms/g0>
On Wed, Sep 3, 2014 at 11:19 AM, Mark Holmquist <mholmquist(a)wikimedia.org>
wrote:
> On Wed, Sep 03, 2014 at 10:49:54AM -0700, Jared Zimmerman wrote:
> > I this done? anything interesting to report? if not done, when is is
> > scheduled for?
>
> Hi, Jared. It would be super if you could contact the Multimedia team via
> our mailing list, multimedia(a)lists.wikimedia.org, it's much more reliable.
>
> UW is only partially EventLogging'd right now, but we have a few
> in-progress
> patches that should add more data.
>
> Is there anything in particular that you'd like to know?
>
> --
> Mark Holmquist
> Software Engineer, Multimedia
> Wikimedia Foundation
> mtraceur(a)member.fsf.org
> https://wikimediafoundation.org/wiki/User:MHolmquist
>
Task filed for UW and MediaViewer:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/854
---------- Forwarded message ----------
From: Timo Tijhof <ttijhof(a)wikimedia.org>
Date: Wed, Sep 3, 2014 at 2:41 AM
Subject: [Engineering] [BREAKING CHANGE] Deprecated JavaScript methods
removed in MediaWiki 1.25
To: engineering Wikimedia List <engineering(a)lists.wikimedia.org>
TL;DR:
* Several deprecated methods in MediaWiki's JavaScript modules will be
removed
in a few weeks' time.
* Check your code to ensure it won't break with these changes, and update it
if needed.
* Check and fix any gadgets or scripts you or your wikis rely upon, to
prevent
breakage.
As part of the regular update cycle, a number of deprecated methods in our
JavaScript modules will be removed in the MediaWiki 1.25 release. This is an
announcement to give people notice they should update any extensions,
gadgets
and scripts they have written, maintain, or rely upon.
Usually we don't give this much attention to removal of deprecated methods,
but due to this being our first proper development cycle for our front-end
code base, I want to make sure this reaches everyone. You're likely not yet
in
the habit of updating front-end code between MediaWiki releases.
Deprecated methods to be removed in MediaWiki 1.25:
* Remove mw.user.name() method. [1]
Deprecated since MediaWiki 1.20. Use mw.user.getName() instead.
* Remove mw.user.anon() method. [1]
Deprecated since MediaWiki 1.20): Use mw.user.isAnon() instead.
* Remove mediawiki.api methods' "ok" and "err" callback parameters. [2]
Deprecated since MediaWiki 1.23. Use the returned Promise interface instead.
* Remove mediawiki.api.category "async" parameter. [2]
Deprecated since MediaWiki 1.23. The ability to override $.ajax() to not be
asynchronous has been removed. The default (asynchronous) behaviour remains.
Use the Promise interface to retreive the fetched data from the API.
* Remove jquery.json module.
Deprecated since MediaWiki 1.24. [3] Use standardised JSON.stringify and
JSON.parse methods. And depend on the "json" module to ensure a polyfill is
lazy-loaded for cross-browser support.
## Timeline
These removals will land in MediaWiki 1.25alpha in early October 2014, being
deployed to Wikimedia wikis in October 2014 (probably 1.25wmf2 or 1.25wmf3).
The MediaWiki 1.25.0 stable release is expected to come out around April
2015.
You should make sure that your code is updated before your wiki upgrades to
MediaWiki 1.25. If you know code you rely upon will be affected but don't
know
how to fix it, please check with your wiki's community for local experts. If
none of them can help, you can ask for assistance on the the
wikitech-ambassadors mailing list. [5]
## Reminders
In case you've missed the previous announcements:
* The migration period for jQuery core is still on-going and is also
scheduled
for MediaWiki 1.25. [4] More about that in the mail from June 2014:
https://www.mail-archive.com/mediawiki-l%40lists.wikimedia.org/msg13651.html
* Learn about deprecation notices and how you can see them in your browser.
https://www.mail-archive.com/wikitech-l%40lists.wikimedia.org/msg72198.html
[1] https://gerrit.wikimedia.org/r/#/c/111422/
[2] https://gerrit.wikimedia.org/r/#/c/118733/
[3] https://gerrit.wikimedia.org/r/#/c/140560/
[4] https://gerrit.wikimedia.org/r/#/c/137168/
[5] https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
– Timo
PS: You can get a sense of the progress on our different migrations, past
and
present, via these graphs: http://codepen.io/Krinkle/full/zyodJ/
PS2: This will soon be sent to wikitech-l, mediawiki-l and
wikitech-ambassadors as well.
_______________________________________________
Engineering mailing list
Engineering(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/engineering
Greetings!
We invite you to join a discussion about Structured Data on Commons, to help us plan our next steps for this project.
The Structured Data initiative proposes to store and retrieve information for media files in machine-readable data on Wikimedia Commons, using Wikidata tools and practices, as described on our new project page (1).
The purpose of this project is to make it easier for users to read and write file information, and to enable developers to build better tools to view, search, edit, curate and use media files. To that end, we propose to investigate this opportunity together through community discussions and small experiments. If these initial tests are successful, we would develop new tools and practices for structured data, then work with our communities to gradually migrate unstructured data into a machine-readable format over time.
The Multimedia team and the Wikidata team are starting to plan this project together, in collaboration with many community volunteers active on Wikimedia Commons and other wikis. We had a truly inspiring roundtable discussion about Structured Data at Wikimania a few weeks ago, to define a first proposal together (2).
We would now like to extend this discussion to include more community members that might benefit from this initiative. Please take a moment to read the project overview on Commons, then let us know what you think, by answering some of the questions on its talk page (3).
We also invite you to join a Structured Data Q&A on Wednesday September 3 at 19:00 UTC, so we can discuss some of the details live in this IRC office hours chat. Please RSVP if you plan to attend (4).
Lastly, we propose to form small workgroups to investigate workflows, data structure, research, platform, features, migration and other open issues. If you are interested in contributing to one of these workgroups, we invite you to sign up on directly on our hub page (5) -- and help start a sub-page for your workgroup.
We look forward to some productive discussions with you in coming weeks. In previous roundtables, many of you told us this is the most important contribution that our team can make to support multimedia in coming years. We heard you loud and clear and are happy to devote more resources to bring it to life, with your help.
We are honored to be working with the Wikidata team and talented community members like you to take on this challenge, improve our infrastructure and provide a better experience for all our users.
Onward!
Fabrice — for the Structured Data team
(1) Structured Data Hub on Commons:
https://commons.wikimedia.org/wiki/Commons:Structured_data
(2) Structured Data Slides:
https://commons.wikimedia.org/wiki/File:Structured_Data_-_Slides.pdf
(3) Structured Data Talk Page:
https://commons.wikimedia.org/wiki/Commons_talk:Structured_data
(4) Structured Data Q&A (IRC chat on Sep. 3):
https://commons.wikimedia.org/wiki/Commons:Structured_data#Discussions
(5) Structured Data Workgroups:
https://commons.wikimedia.org/wiki/Commons:Structured_data#Workgroups
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi opsen,
I'm currently working on this changeset:
https://gerrit.wikimedia.org/r/#/c/157157/ whose goal is to pre-render
commonly used thumbnail sizes at upload time, in order to avoid the delay
experienced by users who are the first to view a particular image at a
given size (particularly in media viewer).
So far I've implemented it as a job (in the job queue sense of the term).
Which implies that the server(s) picking up this job type would need to
have the whole stack of image processing software installed on them. The
idea being that we could the resources for this prerendering separately
from the existing pool of on-demand image scalers. Does this approach make
sense from an Ops perspective? Basically having one or more servers with
the same software as image scalers installed on them, configured as job
runners for that particular job type.
The alternative is that the job would cURL the thumbnail urls to hit the
image scalers. I'm not sure that this is a desirable network path, it might
not be the most future-proof thing to expect job runners to be able to hit
our public-facing URLs. Not to mention this makes it a very WMF-specific
solution, whereas the job type approach is more generic. Maybe there's a
better way for a job runner to make the image scalers do something, though.
That alternative approach of hitting thumbnail urls would imply the job
running on the regular pool of job runners. And it would mean that we
probably wouldn't be able to tell apart the resource usage of the
prerendering compared to the regular on-demand thumbnailing that's
happening at the moment.
Mixins in OOjs UI have always had, shall we say, "strange" names.
Popuppable is my personal favorite, but the most strange thing about them
has always been the lack of correlation between their name and what it is
that they actually do. Furthermore, Alex came across a situation where the
convention of providing an element to a mixin at construction is not always
possible.
I've written a patch[1][2][3] which does the following:
- Mixins are now named according to what they do[2], using the "ed"
suffix if the mixin adds/manages attributes, "able" if it adds/manages
behavior and no suffix if it adds content.
- Mixins no longer take a required element argument, but do still allow
the element to be passed through the config options
- Mixins use a set{Type}Element method to set and even change the
element being targeted by the mixin - this is called in the constructor
with an overridable default, but can also be called again and again
Attribute and behavior mixins always operate on this.$element by deafault.
Content mixins always generate an element to operate on by default. Again,
in both cases the element being initially targeted can be configured using
the config object.
This division was made specifically to reduce or eliminate the need for
using this.$( '<{tagName}' ); when invoking the mixin constructor, and
instead doing what was being done most of the time automatically.
The rename will hopefully not cause too much confusion. It's important to
note that both the JavaScript and CSS classes have been updated.
Roan is reviewing the patches and they will probably be merged shortly. If
you know of any code that may be affected by this change but has not been
considered in the patches mentioned, please let me know.
- Trevor
[1] https://gerrit.wikimedia.org/r/#/c/157274
[2] https://gerrit.wikimedia.org/r/#/c/157286
[3] https://gerrit.wikimedia.org/r/#/c/157285
[4] Table of classes that have been renamed
ButtonedElement ButtonElementIconedElement IconElementIndicatedElement
IndicatorElementLabeledElement LabelElementPopuppableElement PopupElement
FlaggableElement FlaggedElement
Heja,
I think mtraceur pinged me on IRC a while ago, proposing an UploadWizard
bug triage. If I remembered correctly:
Any specific aspects or topic in mind? Some general "let's retry random
reports if they are still valid"? Or more looking at priorities of
tickets?
If retesting reports: Would retesting take place on
http://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadWizard , I
assume that the broken first image and the missing templates exposed in
the summary are "alright"? (Asking because this might confuse potential
volunteers trying to reproduce issues there.)
Severity x priority table of open tickets (might come handy):
https://bugzilla.wikimedia.org/report.cgi?x_axis_field=priority&y_axis_fiel…
Cheers,
andre
[Please CC me on replies; I'm not subscribed to multimedia@]
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Thanks, Gerard!
This seems like a great idea.
I believe that Liam Wyatt and Andrew Lih are reaching out to the project leader, to see if he needs help uploading some of that content to Commons.
Music to my ears :)
Fabrice
On Aug 29, 2014, at 2:34 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:
> Hoi,
> This article is of both interest to Commons and Wikipedia.. It is awesome.
> Thanks,
> GerardM
>
> http://www.bbc.com/news/technology-28976849
> _______________________________________________
> Commons-l mailing list
> Commons-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/commons-l
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hello friends of multimedia,
We would like to invite you to join a global community consultation about Media Viewer.
Please take a moment to join the discussion and add your suggestions for improvement here:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Media_Viewer…
The goal of this consultation is to review the status of this project and identify any critical issues that still need to be addressed -- so we can plan our next steps based on your feedback.
The consultation will be open until September 7th. If agreed upon critical issues cannot be resolved in the near term, the Wikimedia Foundation will temporarily move the feature back into opt-in beta globally.
Here’s our latest Media Viewer Improvements plan, where our team will post regular updates on our planned development tasks:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Improvements
Note that the proposed tasks on that page are still preliminary, and may be adjusted based on community feedback and ongoing user studies.
We look forward to hearing from you on the consultation page.
Regards as ever,
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
