[Wikitech-l] MediaWiki user survey and un-reachable users

We haven't announced this survey on wikitech-l yet, so if you run a wiki outside of those run by the WMF, please take the time to fill out the survey at . More information about the survey and its purpose can be found at

Re: [Wikitech-l] Provide a well-performing API to rotate an image

Updated https://gerrit.wikimedia.org/r/225097 with some partial infrastructure for tracking the status of pending updates (not quite done yet). ... also a little prep work for future crop and trim transformations. Comments on the patch or the attached phab ticket please. :D -- brion On Thu, Jul

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

I posted the query results at https://phabricator.wikimedia.org/T104942#1458981. I _believe_ there wasn't significant skew on particular days that would taint the initially reported number, although there were small variations as expected. On Thu, Jul 16, 2015 at 9:33 AM, Adam Baso wrote: > No p

Re: [Wikitech-l] Provide a well-performing API to rotate an image

On Thu, Jul 16, 2015 at 3:45 PM, MZMcBride wrote: > Brion Vibber wrote: > >Allowing override of the thumb rotation would provide you real time > >rotation... > > > >I'm not sure about the need to rotate the original file; ideally original > >files should be left as-is and kept archival. > > In my

Re: [Wikitech-l] Provide a well-performing API to rotate an image

Brion Vibber wrote: >Allowing override of the thumb rotation would provide you real time >rotation... > >I'm not sure about the need to rotate the original file; ideally original >files should be left as-is and kept archival. In my opinion, we need to solve image rotation as part of a larger proje

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

Hi, If you look at https://phabricator.wikimedia.org/T104942#1436332 (linked from this thread, before Adam posted his own data) an analysis was done on a file called "per-domain-count" which we previously extracted from sampled 1:1000 logs for approximately 25 days for all kinds of domain-populari

Re: [Wikitech-l] Phabricator tag for bugs in local projects

It's very simple: this is what #Wikimedia-General-or-Unknown has always been used for. Just makes sure there is a way for relevant/interested people to eventually find (and understand) the report. Relevant quip: domas: "who are you, and on what did you base your opinion? in the end, everything

Re: [Wikitech-l] Provide a well-performing API to rotate an image

> You would still need to rewrite the bot though, even if there was a > rotation API, wouldn't you? No need to rewrite then because Rillke will fix the rotate link java-script. :-) > Date: Thu, 16 Jul 2015 12:21:10 -0500 > From: gti...@wikimedia.org > To: wikitech-l@lists.wikimedia.org > Subject:

Re: [Wikitech-l] Provide a well-performing API to rotate an image

Ok, I've thrown together a preliminary patch to move the actual rotation for ApiImageRotate to the job queue: https://gerrit.wikimedia.org/r/#/c/225097/ Haven't had a chance to test it yet, so there's probably a typo or two still hiding in there. Steinsplitter, will there be a (more limited) bot

Re: [Wikitech-l] Provide a well-performing API to rotate an image

You would still need to rewrite the bot though, even if there was a rotation API, wouldn't you? On Thu, Jul 16, 2015 at 11:19 AM, YiFei wrote: > >> That doesn't really answer Brion's question. What would prevent it from > >> continuing to run while it is being rewritten? > > lack of time. > (com

Re: [Wikitech-l] Provide a well-performing API to rotate an image

>> That doesn't really answer Brion's question. What would prevent it from >> continuing to run while it is being rewritten? > lack of time. (commenting on this as I tried to debug the code previously) The code currently: * is independent from any maintained mw api libraries * use self defined api

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

No problem, I'll run some extra queries. On Thu, Jul 16, 2015 at 9:04 AM, John wrote: > 1 day isnt much to base a decision on, especially on a global level. > Normally I would use a sample set of at least a week, to a month of values. > Sorry if I seem like im being a pain, I have just seen a lo

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

1 day isnt much to base a decision on, especially on a global level. Normally I would use a sample set of at least a week, to a month of values. Sorry if I seem like im being a pain, I have just seen a lot of bad choices made based off limited data sets. With a wider data set we might find that Tue

Re: [Wikitech-l] Failed jobs will never run again

Hi, yes this works but only together with 'maxTries' which is by default 3. But even if I set this to something very big it still might happen that a job gets deleted. In my case I can't risk that any job gets deleted. So I'll stick with cloning. Regards Henning Am 08.07.2015 um 11:50 schri

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

Hi John -- What do you think would be a better sample? My feeling is that a 24 hour period captures global usage and we're currently at about .01% of page views come to these domains is a pretty good indicator. Keep in mind we're doing this for a legitimate technical reason and not arbitrarily. Lo

[Wikitech-l] Wikimedia Foundation quarterly reviews for April-June 2015

Hi all, the Wikimedia Foundation's quarterly reviews of teams' work in the past quarter (April-June 2015) took place last week. Minutes and slides for those meetings are now available: Community Engagement, Advancement (Fundraising and Fundraising Tech): https://meta.wikimedia.org/wiki/WMF_Metric

Re: [Wikitech-l] Provide a well-performing API to rotate an image

> That doesn't really answer Brion's question. What would prevent it from > continuing to run while it is being rewritten? lack of time. > Date: Thu, 16 Jul 2015 09:05:11 -0500 > From: dga...@wikimedia.org > To: wikitech-l@lists.wikimedia.org > Subject: Re: [Wikitech-l] Provide a well-performing A

Re: [Wikitech-l] Provide a well-performing API to rotate an image

On Thu, Jul 16, 2015 at 9:00 AM, Steinsplitter Wiki < steinsplitter-w...@live.com> wrote: > > Out of curiosity what is the problem with the bot that prevents it from > > working? > It is very old and bad written and needs a complete rewrite. > That can be said of many things in our stack. ;) What

Re: [Wikitech-l] Provide a well-performing API to rotate an image

Hi Steinsplitter, On 16 July 2015 at 09:00, Steinsplitter Wiki wrote: > > Out of curiosity what is the problem with the bot that prevents it from > > working? > It is very old and bad written and needs a complete rewrite. > That doesn't really answer Brion's question. What would prevent it from

Re: [Wikitech-l] Provide a well-performing API to rotate an image

> Out of curiosity what is the problem with the bot that prevents it from > working? It is very old and bad written and needs a complete rewrite. > It's entirely possible that fixing the bot is easier than hacking an > internal rotate and reupload feature that runs on the image scalers. It would b

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

Can we look at a wider sample? using a single day as judgement factor is a bad idea. However if the data supports your position I dont see any serious problems. You might want to take a look at either the UA's or refering sources to see if there is a primary source for the traffic and mitigate that

Re: [Wikitech-l] Provide a well-performing API to rotate an image

Perhaps this should go to Community Tech or Multimedia. Copying to the Multimedia list. Pine On Jul 16, 2015 6:27 AM, "Steinsplitter Wiki" wrote: > Hi, > > I am not sure if this is the correct mailinglist to write. > > Every week on commons a bot is rotating hunderts of files, however this > bot

Re: [Wikitech-l] Provide a well-performing API to rotate an image

Out of curiosity what is the problem with the bot that prevents it from working? It's entirely possible that fixing the bot is easier than hacking an internal rotate and reupload feature that runs on the image scalers. Or... Just making it possible to mark images as needing to be rotated correctl

Re: [Wikitech-l] Provide a well-performing API to rotate an image

On Thu, Jul 16, 2015 at 8:26 AM, Steinsplitter Wiki < steinsplitter-w...@live.com> wrote: > I am wonder if it is possible to enable and code review this feature asap. > For clarification, it's not just a matter of "enable and code review". The existing code, if enabled, will run the rotation on t

[Wikitech-l] Provide a well-performing API to rotate an image

Hi, I am not sure if this is the correct mailinglist to write. Every week on commons a bot is rotating hunderts of files, however this bot will stop working soon. In the last years tens of thousands files has been rotated. Rotating files is a vital feature on commons and therefore indispensabl

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

Looks like the user pageviews for wap.wikipedia.org and mobile.wikipedia.org subdomains are approximately 0.02% of the size of pageviews for m.wikipedia.org subdomains based on a recent one day check. hive> select count(*) from wmf.webrequest where year = 2015 and month = 7 and day = 14 and access

Re: [Wikitech-l] Wikimedia authentication on an external website?

Gergo Tisza wikimedia.org> writes: > Please don't do that, it's a horrible violation of password security, it > will make most people avoid your site, and it will probably get your site > blocked from interacting with Wikipedia. Use OAuth, as Florian explained. Okay, we'll use OAuth then. Thanks

Re: [Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

... Have we done any analysis on usage of those subdomains? On Thu, Jul 16, 2015 at 8:34 AM, Adam Baso wrote: > There's a ticket for removing mobile.wikipedia.org and wap.wikipedia.org > domains/subdomains, which are legacy domain names superceded by > m.wikipedia.org and its subdomains. > > htt

[Wikitech-l] Removal of mobile.wikipedia.org and wap.wikipedia.org in support of browser HSTS preload

There's a ticket for removing mobile.wikipedia.org and wap.wikipedia.org domains/subdomains, which are legacy domain names superceded by m.wikipedia.org and its subdomains. https://phabricator.wikimedia.org/T104942 The rationale for the removal of these legacy domain names is to help support HSTS

Re: [Wikitech-l] Phabricator tag for bugs in local projects

On Thu, 2015-07-16 at 01:00 -0500, Alex Monk wrote: > A single gadgets project that just tracks an issue with any MediaWiki > gadget out there is just going to create a completely useless mess. +1. > > On Jul 15, 2015 10:16 PM, "Jon Robson" wrote: > > > On phabricator should there be a gadgets p

Re: [Wikitech-l] Phabricator tag for bugs in local projects

On Thu, 2015-07-16 at 07:27 +0300, Amir E. Aharoni wrote: > In the past it happened to me a few times that I opened bugs about > something wrong that happened on a Wikimedia site, and it was closed as > invalid because the issue was not in MediaWiki code, but in a local gadget, > style or template