So for a while now, I have been toying a bit with
TimedMediaHandler/MwEmbed/TimedText, with the long term goal of wanting it
to be compatible with VE, live preview, flow etc.
There is a significant challenge here, that we are sort of conveniently
ignoring because stuff 'mostly works' currently and the MM team having
their plate full with plenty of other stuff:
1: There are many patches in our modules that have not been merged upstream
2: There are many patches upstream that were not merged in our tree
3: Upstream re-uses RL and much infrastructure of MW, but is also
significantly behind. They still use php i18n, and their RL classes
themselves are also out of date (1.19 style ?). This makes it difficult to
get 'our' changes merged upstream, because we need to bring any RL changes
etc with it as well.
4: No linting and code style checks are in place, making it difficult to
assess and maintain quality.
5: Old jQuery version used upstream
6: Lot's of what we consider deprecated methodologies are still used
upstream.
7: Upstream has a new skin ??
8: It uses loader scripts on every page, which really aren't necessary
anymore now that we can add modules to ParserOutput, but since I don't
fully understand upstream, i'm not sure what is needed to not break
upstream in this regard.
9: The JS modules arbitrarily add stuff to the mw. variables, no
namespacing there.
10: The RL modules are badly defined, overlap each other and some script
files contain what should be in separate modules
11: We have 5 'mwembed' modules, but upstream has about 20, so they have
quite a bit more code to maintain and migrate.
12: Brion is working on his ogvjs player which at some point needs to
integrate with this as well (Brion already has some patches for this [1]).
13: Kaltura itself seems very busy and doesn't seem to have too much time
to help us out. Since some of the code is however highly specific to their
use cases, it becomes difficult to validate changes.
Oh and the file trees are disjunct between us and upstream, making git
merging a lot more troublesome than it should be (anyone got tips ?).
This is maintenance hell, we need to come up with a plan here or we are
going the way of getting so far out of sync that the cheapest solution will
be to start from scratch...
So my questions:
1: Is there anything in upstream that we actually want ? I've been hearing
about the 'update' that was still coming from there for over a year now,
but due to how far both trees are now out of sync, i'm not really holding
my breath for that anymore. The last 'proper sync' seems to have been
'Kaltura 1.7' in july 2012.[2] They are now at v2.21.9
2: Who can think of a strategy to fix this ?
3: Or should we just split off our modules and let upstream sort this out ?
4: Should we consider starting something from scratch ?
DJ
I have done a bit of cleanup [3] with jshint and jscs on the modules that
we use. There are some remaining problems [4], some of which are true bugs
in the code. I don't intend to propose these changes for merging any time
soon, since it will probably make consolidation of the two variants even
more complicated, but I'll try to keep it up to date and maybe try to fix
some of these bugs upstream or in MW.
[1] https://gerrit.wikimedia.org/r/#/c/165477/https://gerrit.wikimedia.org/r/#/c/165478/https://gerrit.wikimedia.org/r/#/c/165479/
[2] https://gerrit.wikimedia.org/r/#/c/16468/
[3] https://github.com/hartman/mwEmbed/compare/jscleanup
[4] https://phabricator.wikimedia.org/P147
Greetings, Multimedia Team!
*Background:* The Mobile Apps Team is working on a restyling of the way
content the first fold of content is presented in the Wikipedia app. You
can see this image <http://i.imgur.com/dxqfJKd.png> to see what this looks
like. Having a high-resolution image so prominently at the top of the page
will likely drive a lot of clicks, so we're working on a lightweight image
viewer to deal with file pages, which are poorly styled monstrosities on
the mobile app. We're going to use the CommonsMetadata API to help us out.
:-)
*Problem:* The CommonsMetadata API can sometimes return HTML [1]. Having
HTML in the API response is a bit problematic for us. Native apps make next
to no use of HTML when creating links or layouts, so we have to strip the
HTML from every API response, lest it be displayed as plaintext to the
user. In the short term this is fine, we can strip it and throw the
information away. But in the long run it'd be better if the API didn't
return HTML.
*Our ask: *Can the CommonsMetadata API please not return HTML in its
responses? :-)
Thanks,
Dan
[1]: Run this query
<https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&format=….
>,
and look at "artist" key. The API response has an HTML link in it.
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi folks,
We're happy to let you know that our multimedia team has completed all the requested 'must-have' improvements to Media Viewer for this year’s release, based on community feedback.
These improvements have now been released on all Wikimedia-hosted sites, as described here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Improvements
We would appreciate your advice on one last community request, which seems important to address before we wrap up.
Many editors have asked for a quick way to copy and paste the full file name from Media Viewer, so they can use that file in an article without extra clicks.
They can already copy the file name from the URL, or from the Share or Embed panels, but have to remove extra characters, which slows them down. And now that we have replaced the file name with a caption right below the image, there is no easy way to copy it in Media Viewer.
To address this issue, we propose to show the file name right below the license label, as illustrated here:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/798 <https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/798>
Here are a few questions we’d love your feedback on:
1. Is this file name feature useful for editors?
(We know it’s not that useful for readers, which is why we propose placing it below the fold — but we wanted to offer it for editors who requested it, if it’s helpful.)
2. Is the placement below the license practical?
(Note that you have to scroll down to see the file name; but that seemed faster than placing it in the Share panel, which would be one click away and may be harder to find.)
3. Should we include ‘File:’ before the file name?
(Does it help editors if we display ‘File:Chamonix flowers.jpg’ — instead of just ‘Chamonix flowers.jpg’, as shown in the mockup above?)
4. Any other suggestions for improvement?
Please let us know what you think, so we can make any final tweaks based on your feedback. You can respond by email to the list or just to the me and the four team members in the Cc: line.
We will post one last project update in a few weeks, to share our research findings.
Best regards,
Fabrice — on behalf of the Multimedia Team
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi Jesse,
Thanks for sharing this nice success story!
I’m really happy to hear that over 400 videos were added to articles within three weeks of your event.
This is a great accomplishment, given that there is still not a lot of video on Wikipedia at this time. Nicely done!
I just tweeted it here, if you’d like to retweet:
https://twitter.com/fabriceflorin/status/539847861178212353
I also recommended it to our social media team, and am sharing it with our multimedia and commons mailing lists.
Keep up the great work :)
Be well,
Fabrice
> On Dec 2, 2014, at 5:24 AM, Jesse de Vos <jdvos(a)beeldengeluid.nl> wrote:
>
> Hi all,
>
> I have written a blogpost about our positive(!) experiences with organizing a video-challenge on the UNESCO World day for Audiovisual Heritage. You can find it here:
>
> http://www.beeldengeluid.nl/en/blogs/research-amp-development-en/201412/vid… <http://www.beeldengeluid.nl/en/blogs/research-amp-development-en/201412/vid…>
>
> Most notably, over 400 videos were added to articles within three weeks.
> We're very open to suggestions how we can improve these type of 'contests' and perhaps there are people who would like to join in for next years' World Day of Audiovisual Heritage (7th October 2015)? :)
>
> Best,
> Jesse
> --
> Met vriendelijke groet,
>
> Jesse de Vos
> GLAM-wiki coördinator
>
> T 035 - 677 39 37
> Aanwezig: ma, di, 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/>
> _______________________________________________
> Wikivideo-l mailing list
> Wikivideo-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
