On 18.09.2012, 5:04 MZMcBride wrote:
Hi.
There's a fairly straightforward request to add an API/Developer/Developer
Hub link to the footer of Wikimedia wikis, near the Disclaimers, Mobile
view, etc. links:
https://bugzilla.wikimedia.org/show_bug.cgi?id=33464.
This should be fairly trivial
Why shouldn't end users know? Some end users are able to use an API. I
prefer to not take the pedantic 'dont break your pretty little head on our
API' route
On Sep 18, 2012 8:15 AM, Max Semenik maxsem.w...@gmail.com wrote:
On 18.09.2012, 5:04 MZMcBride wrote:
Hi.
There's a fairly
How to load up high-resolution imagery on high-density displays has been an
open question for a while; we've wanted this for the mobile web site since
the Nexus One and Droid brought 1.5x, and the iPhone 4 brought 2.0x density
displays to the mobile world a couple years back.
More recently,
On Tue, Sep 18, 2012 at 3:04 AM, MZMcBride z...@mzmcbride.com wrote:
Hi.
There's a fairly straightforward request to add an API/Developer/Developer
Hub link to the footer of Wikimedia wikis, near the Disclaimers, Mobile
view, etc. links: https://bugzilla.wikimedia.org/show_bug.cgi?id=33464.
On Tue, Sep 18, 2012 at 5:31 PM, Brion Vibber br...@pobox.com wrote:
* adds $wgResponsiveImages setting, defaulting to true, to enable the
feature
Shouldn't experimental features be defaulting to false till it gets
tested a bit?
___
Wikitech-l
On Tue, 18 Sep 2012 00:56:46 -0700, K. Peachey p858sn...@gmail.com wrote:
On Tue, Sep 18, 2012 at 5:31 PM, Brion Vibber br...@pobox.com wrote:
* adds $wgResponsiveImages setting, defaulting to true, to enable the
feature
Shouldn't experimental features be defaulting to false till it gets
how about here :
http://www.mediawiki.org/wiki/Manual:Contents
... and add in any resources that may be missing to those pages.
with kind regards,
dan
On Sep 18, 2012, at 9:37 AM, aude wrote:
On Tue, Sep 18, 2012 at 3:04 AM, MZMcBride z...@mzmcbride.com wrote:
Hi.
There's a fairly
On Tue, 18 Sep 2012 00:31:49 -0700, Brion Vibber br...@pobox.com wrote:
How to load up high-resolution imagery on high-density displays has been
an
open question for a while; we've wanted this for the mobile web site
since
the Nexus One and Droid brought 1.5x, and the iPhone 4 brought 2.0x
dan entous d_ent...@yahoo.com wrote in message
news:75e303e6-3ec7-4a17-824e-c3d8d3378...@yahoo.com...
how about here :
http://www.mediawiki.org/wiki/Manual:Contents
... and add in any resources that may be missing to those pages.
with kind regards,
dan
I would much rather it went to a new
Le 18/09/12 09:31, Brion Vibber a écrit :
More recently, tablets and a few laptops are bringing 1.5x and 2.0x density
displays too, such as the new Retina iPad and MacBook Pro.
Please excuse my noobiness, but what 1.5x / 2.0x densities are referring
to? IIRC most computers used 72dpi and
DPI started to go a little crazy when mobile devices were introduced. This
is a good history:
http://www.html5rocks.com/en/mobile/high-dpi/
And you can see that iDevices have screens with varied ppi:
http://stackoverflow.com/questions/1365112/what-dpi-resolution-is-used-for-an-iphone-app
As
Hoi,
The default watchlist is 37 words ... these words are probably en.wikipedia
measurements. To what extend have different scripts and different languages
been considered ?
Thanks.
GerardM
On 18 September 2012 00:09, Steven Walling steven.wall...@gmail.com wrote:
On Sat, Sep 15, 2012 at
Awesome!
Correct me if I'm wrong but the way this is currently written an image for
foo.jpg will first load foo.jpg then replace the src attribute for this
element then load the image foo-2.0.jpg ?
In which case we probably need to think more abut minimising this initial
load. I'd suggest not
This is a great idea but we would really need to build several new pages
ideally with links to the API sandbox, code samples. This is a big project
in itself. The landing page should be close to something like Flickr [1]
and should detail why someone would want to be a developer, the sort of
In VisualEditor we ended up putting all CSS rules that include images in
*.icons-raster.css and *.icons-vector.css files, which are loaded
dynamically based on the window.devicePixelRatio property.
It has it's flaws, but the good thing is that it spares the device from
loading both versions. I
Jon, if you want to take the lead on this, go ahead.
https://www.mediawiki.org/wiki/User:Sumanah/ApiDocsImprovement has some
thoughts that Ben Lobaugh had put together (including the Flickr
example) in case you find those useful.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia
This is a great idea but we would really need to build several new pages
ideally with links to the API sandbox, code samples. This is a big project
in itself. The landing page should be close to something like Flickr [1]
and should detail why someone would want to be a developer, the sort of
On 09/18/2012 12:44 PM, Derric Atzrott wrote:
It should definitely link to the Annoying little bugs page as well. It
contains
a decent selection of bugs that new developers can fix.
Not 100% sure the scope of this page though. Was it meant to attract just
extension, gadget, et. al
Just wanted people to know so they don't reinvent the wheel. :)
Along that vein, there are the ever popular skin manual [0] and
extension manual [1].
[0] http://www.mediawiki.org/wiki/Manual:Skins
[1] http://www.mediawiki.org/wiki/Manual:Extensions
--
Mark Holmquist
Software Engineer,
On Tue, Sep 18, 2012 at 9:38 AM, Trevor Parscal tpars...@wikimedia.orgwrote:
In VisualEditor we ended up putting all CSS rules that include images in
*.icons-raster.css and *.icons-vector.css files, which are loaded
dynamically based on the window.devicePixelRatio property.
It has it's
Sending more data to primarily empower mobile devices sounds rather
counter-intuitive
On Sep 18, 2012 7:06 PM, Brion Vibber br...@pobox.com wrote:
On Tue, Sep 18, 2012 at 9:38 AM, Trevor Parscal tpars...@wikimedia.org
wrote:
In VisualEditor we ended up putting all CSS rules that include
On Tue, Sep 18, 2012 at 10:15 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
Sending more data to primarily empower mobile devices sounds rather
counter-intuitive
Amount of data, and *when that data comes in*, are distinct things. One
other change we've got brewing up for the mobile
It's important to separate supporting retina display mobile and desktop
devices. Apple's web site uses the load both method to show off the retina
display MacBook - which is more likely to have a faster internet connection
and is a more powerful machine in general.
- Trevor
On Tue, Sep 18, 2012
I hate derailing threads, bit doesn't the mobile skin already do this? I
always notice fast loading of articles on my cell phone, and slow section
opening (I figured it was quite clever to defer loading of sections to a
later point in time. For a quick lookup on my cell phone I rarely need to
load
On Tue, Sep 18, 2012 at 10:22 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
I hate derailing threads, bit doesn't the mobile skin already do this
Nope.
I
always notice fast loading of articles on my cell phone, and slow section
opening (I figured it was quite clever to defer
On Tue, Sep 18, 2012 at 10:19 AM, Trevor Parscal tpars...@wikimedia.orgwrote:
It's important to separate supporting retina display mobile and desktop
devices. Apple's web site uses the load both method to show off the retina
display MacBook - which is more likely to have a faster internet
On Tue, Sep 18, 2012 at 12:31 AM, Brion Vibber br...@pobox.com wrote:
Here's my first stab:
https://bugzilla.wikimedia.org/show_bug.cgi?id=36198#c6
https://gerrit.wikimedia.org/r/#/c/24115/
I've made a couple changes in patchset 2:
* fix for images that specify width but not height (whoops!
Gerrit-users,
All repositories that were pending creation on either[0] list[0] have
been created. If you were waiting for a repository, please check
out those lists to make sure I got you :)
My sincere apologies to anyone who has been waiting. Between
the Gerrit downtime and travelling, I had
On Tue, Sep 18, 2012 at 9:51 AM, Sumana Harihareswara
suma...@wikimedia.org wrote:
And to help new
developers discover various cross-Wikimedia tech projects, there is
https://meta.wikimedia.org/wiki/Wikimedia_developer_hub .
Just wanted people to know so they don't reinvent the wheel. :)
My
On Mon, Sep 17, 2012 at 12:14 PM, Ryan Lane rlan...@gmail.com wrote:
At peak we can get between 100,000 - 140,000 requests per second. The
number provided by Diederik isn't very surprising.
Diederick later wrote
...
sampled-1000.log-20120916.gz,57763
sampled-1000.log-20120917.gz,65775
Hi,
On Tue, Sep 18, 2012 at 1:11 PM, Rob Lanphier ro...@wikimedia.org wrote:
My 2c: the Wikimedia developer hub page on meta should be the
starting point. Let's not create yet another central page.
If the primary target are app developers then
http://www.mediawiki.org/wiki/API:Main_page +
On Tue, Sep 18, 2012 at 01:30:14PM -0700, S Page wrote:
I imagine mobile users on IPv6 might be more aggressively cached by
their providers, and they aren't requesting as many resources per page
view, so Wikimedia's share of IPv6 users might be higher.
I wouldn't count on mobile devices having
At the danger of derailing/forking the conversation...
My preference with bugzilla is to only raise bugs when the outcome is
clear. The test I use is if I gave a bug to a newbie could they pick it up
and fix it without any questions. If it's not clear I'd start a mailing
list conversation with
I haven't had a chance to check this out yet, but has anyone else?
Any reports good/bad/indifferent?
Rob
On Sun, Sep 16, 2012 at 5:08 PM, Mark A. Hershberger m...@everybody.org wrote:
I found some minor problems with the tarball put up yesterday, so I'm
releasing an update.
Here are the
On Tue, Sep 18, 2012 at 5:11 PM, Jon Robson jdlrob...@gmail.com wrote:
There is a huge usability issue with the current implementation.
I just watched an article on commons and got a notification bubble, I then
tried to use the down arrow to click global usage and couldn't actually get
to the
Not sure if this is a known issue, but the notification is at the top of the
document regardless of where you are on the page. Meaning if I'm at the bottom
of a long article, I have to scroll up to the top to see the bubble. Should it
not be relative to the scroll position?
I noticed this
On Commons it seems to take 5 seconds to disappear which is too long as at
this point I'm wondering how to dismiss it.
A good ui pattern would be for it to fade out over those 5 seconds to show
me what is happening and when I hover over it go back to no transparency to
signal that it will fade
On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson jdlrob...@gmail.com wrote:
On Commons it seems to take 5 seconds to disappear which is too long as at
this point I'm wondering how to dismiss it.
I think the time should depend on the length of the message.
The watchlist notification in Portuguese has
Ariel T. Glenn wrote:
So it's time to have this discussion again. At least, I think we're
having it again, though I could not find previous threads on this list
about the subject.
In short, scaled media is currently generated on the fly for any size
and for any user. The resulting files
On Tue, Sep 18, 2012 at 5:28 PM, Rob Moen rm...@wikimedia.org wrote:
Not sure if this is a known issue, but the notification is at the top of
the document regardless of where you are on the page. Meaning if I'm at
the bottom of a long article, I have to scroll up to the top to see the
On Wed, Sep 5, 2012 at 6:40 PM, Jon Robson jdlrob...@gmail.com wrote:
I just wanted to clarify something... is there any protection in place in
the thumbnail generator to prevent denial of service attacks? For instance
if someone wanted to they could run a script which uploaded photos then
Is there a bug open for this yet? If not there probably should be...
(apologies if there is.. scanning through I cannot see one)
In terms of supporting non-standard files - there is no reason why to get
an obscure size e.g. 224px you could get for example the 240px image and
resize it with css...
42 matches
Mail list logo
