On Mon, Jan 28, 2019 at 12:22 PM Brion Vibber via Commons-l <
commons-l@lists.wikimedia.org> wrote:
> IE 11 users will receive low-resolution, slow JavaScript-based video
> playback instead. If you find this is troublesome, the recommended solution
> is to switch to any other browser.
>
Will they
(Filed https://phabricator.wikimedia.org/T166797 for the message handling
problem.)
___
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
-- Forwarded message --
From: Gergo Tisza
Date: Sat, Dec 17, 2016 at 5:43 PM
Subject: List of clients which try to guess MediaWiki thumbnail URLs
To: Wikimedia developers
The current format of MediaWiki thumbnail URLs is very ad hoc: it depends
on the media handler, the
On Fri, Nov 25, 2016 at 6:11 AM, Hugo Manguinhas <
hugo.manguin...@europeana.eu> wrote:
> In particular, given a File page like this one:
> https://commons.wikimedia.org/wiki/File:African_Dusky_
> Nightjar_(Caprimulgus_pectoralis)_(W1CDR386_BD28).ogghttps://commons.
> wikimedia.org/wiki/File:A
On Thu, Dec 4, 2014 at 1:49 PM, Daniel Kinzler wrote:
> This is happening automatically: the SHA1 hash of every file is computed on
> upload, and placed in the img_sha1 field on the database. I believe this
> is used
> to warn users who try to upload an exact duplicate, but I'm not sure this
> is
On Wed, Oct 1, 2014 at 1:37 AM, Gnangarra wrote:
> ok I'm a little late to the party but why doesnt media viewer just use the
> same very effective layout of the category slide show thats currently
> operating on Commons given it has already solved all these issues
>
I am even more late but just
On Fri, Sep 5, 2014 at 4:53 PM, Daniel Schwen wrote:
> > use the API in batches. You can retrieve the information (including
> thumbnail URL) for 500 files in a single request (5000 if you get a bot
> flag):
>
> Its actually 50 and 500 with bot flag.
> Unless the api docs aren't up to date and th
On Fri, Sep 5, 2014 at 1:54 PM, Jonas Öberg
wrote:
> That's a neat idea - I didn't know that the API took multiple file
> names in one query. If we could do 500 files per request, 10-12 per
> minute, that's a more than adequate - but it feels that this is
> something that we should be talking to
On Fri, Sep 5, 2014 at 10:21 AM, Jonas Öberg
wrote:
> It's possible to use Special:Redirect or thumb.php to get the
> thumbnail/URL, but both are actually PHP scripts that need running. So
> while perhaps not ideal, it seems to make the most sense here to
> generate the thumbnail URLs ourselves a
On Thu, Sep 4, 2014 at 10:38 PM, Daniel Schwen wrote:
> I'm wondering if thumb.php (although it internally reuses existing
> thumbnails) play nicely with the varnish cache layer. If you get to a
> point where you have to execute a PHP script you are already
> generating more load than necessary.
On Thu, Sep 4, 2014 at 5:56 PM, Daniel Schwen wrote:
> > I'm not sure there is a difference (both hit PHP and neither will
> recreate
> > the image if it exists already), but thumb.php will result in an error if
>
> Well, here is what Krinkle wrote me
>
> http://commons.wikimedia.org/w/index.php?
On Thu, Sep 4, 2014 at 12:26 PM, Jonas Öberg
wrote:
> 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) aut
On Thu, Sep 4, 2014 at 3:05 PM, Daniel Schwen wrote:
> I was told thumb.php is evil (for lack of caching).
> I'm using special:redirect with the width=640 parameter.
>
I'm not sure there is a difference (both hit PHP and neither will recreate
the image if it exists already), but thumb.php will re
On Thu, Aug 7, 2014 at 10:13 PM, Federico Leva (Nemo)
wrote:
> If I'm reading this correctly:
> *
> <
> https://web.archive.org/web/20140807205406/http://stats.wikimedia.org/wikimedia/squids/SquidReportRequests.htm
> >
> *
> <
> https://web.archive.org/web/20140719114013/http://stats.wikimedia.or
On Wed, Jun 4, 2014 at 1:45 PM, Brian Wolff wrote:
>
> > 4. Roadmap
> > We plan to spread out these activities throughout the coming year, as
> > proposed in this rough timeline:
> > • Q1: metrics, upload wizard fixes, structured data planning, bug fixes
>
> From the linked page, "Multimedia Metr
On Mon, May 19, 2014 at 2:09 AM, dan-nl wrote:
> this is may be a long-shot, but what about allowing all files from the
> /images/ directory and excluding images from any other directory? the
> assumption being that icons and other "helper" images will come from
> directories other than /images/.
On Sun, May 18, 2014 at 9:13 AM, rupert THURNER wrote:
> The main page seems to be such an obscure case that it might be adressed
> when we have a better idea than forcing millions of exception edits what
> you think?
>
Obscure in what sense? I would expect mainpage images to get more clicks
than
On Sat, May 17, 2014 at 6:00 AM, rupert THURNER wrote:
> Instead of introducing complicated syntax, would it not be better that
> media viewer only displays thumbs?
>
Quoting from earlier:
There are images that do not use that syntax but we want to display them,
> for example infobox main images,
On Wed, May 14, 2014 at 5:50 AM, Krinkle wrote:
>
> Making it specific to the idea of a "viewer" (e.g. "no-viewer",
> "viewer-exclude", or "for-page-only") is better in my opinion, but only
> marginally so. I'd recommend aiming for something that reflects what it is
> and
> allows separation of co
On Mon, May 12, 2014 at 4:22 PM, Gnangarra wrote:
> just reading through and one issue that stands out with (e.g.:
> [[file:foo.png|thumb|no-viewer|…]]). format is that many of the small image
> files are embedded within infoboxes, templates and tables would it be more
> efficient to restrict med
On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke wrote:
> Another option is to make this a property of the image rather than it's use
> site. That should cover the typical icon well, and with minimal editor
> effort.
>
Most images are hosted on Commons, so that would mean the Commons community
wou
On Mon, May 12, 2014 at 2:54 PM, bawolff wrote:
> Probably much harder to implement... but it might be more consistent to
> have it as part of the file embedding syntax. E.g. [[file:foo.png|thumb|no-
> viewer|...]]
>
This would make our file inclusion syntax, which is an atrocity that should
not
On Mon, May 12, 2014 at 2:47 PM, dan-nl wrote:
> i may be mis-understanding the goal …
>
> 1, it looks like you want to distinguish between elements on a web page
> that should be viewable in mediaviewer vs those that should not.
>
> 2. you want to use a css class to distinguish these elements.
>
23 matches
Mail list logo
