Andrew Lih | 19 Dec 20:06 2014

[Wikivideo-l] Opinions: Category for video?

What are your opinions of having a category for "articles with video" in WP? The one was created for en.wp is being considered for deletion. 

When the numbers were small, it made sense to try to track these, but perhaps Phoebe's suggestion that it stay a parent category and we label sub-categories may work? What have others in other WP communities been doing?


-Andrew

_______________________________________________
Wikivideo-l mailing list
Wikivideo-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Derk-Jan Hartman | 11 Dec 16:55 2014
Picon

What to do with TimedMediaHandler

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.


_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Mark Holmquist | 9 Dec 00:34 2014
Picon

CORS on betalabs

Hi all!

I have a curious mystery on my hands in the mediawiki-config repo.

In the prod settings[0], CORS is turned on for public wikis. In the labs
settings[1], CORS is enabled for all subdomains of beta.wmflabs.org. I
was under the impression that unset variables in the labs settings were
set to whatever the prod settings had them at, but maybe I'm wrong...
or maybe I'm missing something that has turned CORS off.

If anyone has any thoughts, I'd appreciate them - I'm toying with a small
gadget to test cross-domain uploading.

[0] http://git.wikimedia.org/blob/operations%2Fmediawiki-config/master/wmf-config%2FInitialiseSettings.php#L13652
[1] http://git.wikimedia.org/blob/operations%2Fmediawiki-config/master/wmf-config%2FCommonSettings-labs.php#L179

--

-- 
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur@...
https://wikimediafoundation.org/wiki/User:MHolmquist
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Dan Garry | 8 Dec 20:29 2014
Picon

CommonsMetadata API returning HTML?

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 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, and look at "artist" key. The API response has an HTML link in it.

--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Andrew Lih | 5 Dec 16:24 2014

[Wikivideo-l] Best practices for identifying video in Wikipedia/Commons?

I'm wondering what people have found to be the best practices for identifying video in Wikipedia articles.

A number of issues:

- One of the problems is the OGG is a container, so simply parsing article Wikimarkup may not be sufficient to identify video content.

- You can go by category, but this is not always fully accurate

- Are GIFs that are animated considered video? Some are, and some aren't.

Interested in hearing what people think, or whether we have a taxonomy of video types that are well defined.


-Andrew


_______________________________________________
Wikivideo-l mailing list
Wikivideo-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Shun Fukuzawa | 5 Dec 02:27 2014
Picon

[Wikivideo-l] Some problem of TimedText namespace

Hi guys,

I made Japanese subtitle for the movie on commons.

But I encountered 2 problems.
* This namespace ignores templates. So I can't put the license template to it. This template is not appeared on the movie.
* It ignores also line breaks of subtitle. Especially, Japanese sentences don't have spaces for reading, so it's hard for audience to understand it immediately. 

Anyone has a solution to this?

Thanks,
_______________________________________________
Wikivideo-l mailing list
Wikivideo-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Fabrice Florin | 5 Dec 01:57 2014
Picon

Media Viewer Last Improvements: File Names

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:


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




_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Sebastiaan ter Burg | 3 Dec 22:33 2014
Picon

[Wikivideo-l] Fwd: license needed for hosting ProRes files?

Wow, it took them over 3 months to not answer my question.
But, as I am developing on Mac OS X, it looks like there's nothing holding us back to host ProRes files.
Now who has a huge server to spare?



---------- Forwarded message ----------
From: Apple ProRes Program Office <ProRes-2kanFRK1NckAvxtiuMwx3w@public.gmane.org>
Date: 2014-12-03 22:26 GMT+01:00
Subject: Re: license needed for hosting ProRes files?
To: Sebastiaan ter Burg <terburg-AeOJrEpdGNc1IEMOdO2fEw@public.gmane.org>


Dear Sebastiaan,

Thank you for your patience. We have been inundated with ProRes requests.

If you are developing on Mac OS X, no ProRes license is needed as it is available on our platform. 

Best,
- Apple ProRes Program Office.

===

On Aug 21, 2014, at  7:07 AM, Sebastiaan ter Burg <terburg-AeOJrEpdGNc1IEMOdO2fEw@public.gmane.org> wrote:

Dear Sir/Madam,

Wikimedia Nederland is researching the options to set up a publicly available file server for uncompressed video footage. This would be a ftp server or a similar service. 

The uncompressed footage will not be played back by the server. For playback the files are client-sided - by the uploader -  compressed to smaller and open formats (WebM of OGV) and uploaded separately. 

Questions:
  1. Under the conditions mentioned above, would it be possible to use ProRes as a/the codec to share the uncompressed footage?
  2. Is a license needed to share ProRes files? 
  3. If so, are there solution where this be done without a license?
  4. Does the hardware and software of the server affect above? 
With kind regards,

Sebastiaan ter Burg
 

--
Sebastiaan ter Burg
Projectleader Cultural Cooperation
Wikimedia Nederland
________________________________
tel.: +31 30 32 00 238
gsm: +31 6 480 88 615
wiki: Ter-burg 
________________________________
________________________________
Postadres:                         Bezoekadres:
Postbus 167                      Mariaplaats 3
3500 AD  Utrecht               Utrecht
________________________________






--
Sebastiaan ter Burg
Projectleider Culturele Samenwerking
Wikimedia Nederland
________________________________
tel.: +31 30 32 00 238
gsm: +31 6 480 88 615
wiki: Ter-burg 
________________________________
________________________________
Postadres:                         Bezoekadres:
Postbus 167                      Mariaplaats 3
3500 AD  Utrecht               Utrecht
________________________________


_______________________________________________
Wikivideo-l mailing list
Wikivideo-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Jesse de Vos | 2 Dec 14:24 2014
Picon

[Wikivideo-l] Results of video-challenge on Wikipedia

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/video-challenge-wikipedia-way-stimulate-reuse

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

Nederlands Instituut voor Beeld en Geluid
Media Parkboulevard 1, 1217 WE  Hilversum | Postbus 1060, 1200 BB  Hilversum | beeldengeluid.nl

_______________________________________________
Wikivideo-l mailing list
Wikivideo-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Oliver Keyes | 25 Nov 22:59 2014
Picon

Re: False anchors

Actually, I'd argue it's not equivalent at all, for two reasons:

  1. it doesn't present all of the same data. In fact, it presents very little data, compared to a pageview of the "File" page;
  2. The argument behind MMV is, as I understand it, that people are focusing on the images. It is designed so that people do so, on the basis that people clicking on images probably want those images. As such, it'd be inaccurate to weight it as equivalent to say https://az.wikipedia.org/wiki/Mar%C3%A7ello_Malpigi in textual value - we believe (correct me if I'm wrong) that someone clicking for an image wants a media file, not a wall of text.

And, of course, even if we do include it, it's Yet Another URL Scheme to take into account when extracting "page" from "URL". I don't think mobile pageviews are a valid equivalency because our design pattern there does not assume a user has a !text intended outcome of the request.




On 25 November 2014 at 16:05, Brion Vibber <bvibber-AeOJrEpdGNeGglJvpFV4uA@public.gmane.org> wrote:
On Tue, Nov 25, 2014 at 12:52 PM, Bryan Davis <bd808-AeOJrEpdGNeGglJvpFV4uA@public.gmane.org> wrote:
I'm pretty sure this should be counted as a page view. As Brion notes
this is the equivalent of a page view of the
/wiki/File:Marcello_Malpighi_large.jpg page. If this doesn't count as
a page view then mobile page views shouldn't count either as they are
transformations of the canonical page as well.


AFAIK, the hash is generally not sent to the server so it (and thus the image name) won't be seen by log-based data crunching.

As such I think the issue Oliver is raising is that it would likely be counted as a page view for the article page, even though we don't know whether or not the article will actually be seen or read. However there's no way offhand to know that that page view won't result in a read of the article as well once the media viewer is dismissed. And in general, simply seeing that a data transfer was made tells us nothing about how much attention a human paid to the contents...

-- brion

_______________________________________________
Multimedia mailing list
Multimedia-RusutVdil2jCeO+0kHIy+g@public.gmane.orga.org
https://lists.wikimedia.org/mailman/listinfo/multimedia




--
Oliver Keyes
Research Analyst
Wikimedia Foundation
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia
Oliver Keyes | 25 Nov 21:21 2014
Picon

False anchors

(Hat-tip to Nemo for noticing this)

We're writing up and redefining the pageview definition. Amongst other things, it uses MIME type filtering and folder-level filtering to exclude non-pageviews.

Problem: the multimedia viewer false anchor (an example is https://az.wikipedia.org/wiki/Mar%C3%A7ello_Malpigi#mediaviewer/File:Marcello_Malpighi_large.jpg is both text/html (one of the recognised and appreciated MIME types) and /wiki/ (one of the recognised and appreciated domains).

The result of this is that it's currently going to be counted as a pageview, even though it's...well, not.

Is there any way you lot could avoid the false anchor strategy and pick a URL scheme that won't trigger this? If not, we can just write an exception - but I'd rather that we not have to do that every time anyone decides to make software.

Thanks,

--
Oliver Keyes
Research Analyst
Wikimedia Foundation
_______________________________________________
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia

Gmane