I have another question on pageimages:
I can't get it work with list=search:
could you please help in understanding if i am doing wrong smtg?
also, is there any planned release of api 2.0 ?
What about the legacy and normalization of continue parameters?
On Wed, May 1, 2013 at 10:46 AM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
> On 29.04.2013, 22:26 Luigi wrote:
> > Thank you Max!
> > quick, neat and clear.
> > Just a note: I'd see useful the possibility to re-size an image not
> > only by largest dimension, but also by width (or height)
> > so that one could have all img with same width/height, very yuseful
> > for formatting on mobile handsets.
> > Do you think it could be useful and would you consider to modify the
> code for this feature?
> It will produce weird results for images with unusual dimensions: very
> wide or very narrow. We use pithumbsize with good results for mobile.
> Best regards,
> Max Semenik ([[User:MaxSem]])
Skype contact: oggigigi
I am trying to retrieve the templates associated to a page:
So in this scenario, I am able to get a list, but I noticed some of the
listed templates here are marked as protected. I am not able to see any
attribute in the results that shows this flag.
Any ideas on how can I filter those out?
On 04/29/2013 05:27 PM, Quim Gil wrote:
> On 04/29/2013 02:18 PM, Aayush Sharma wrote:
>> Please review my GSoC application.
> Hi Aayush, please write more specific emails in a mailing list. It will
> help getting more people looking at your proposal.
> You could also have pasted the summary here, so people can have a look
> and decide whether they want to check more or not.
> For instance, in your proposal you say
> GSoC Project Idea: MediaWiki API 2.0
> I will be working and modifying MediaWiki API to solve the following
> * Avoiding client to update every time API changes
> * Developers will develop extensions from the single default API
> * Reduce the cost of making a change in MediaWiki.
> * Organize feature changes - if the client asks for ver X, API
> guarantees the capabilities of X and result in format X.
> * Avoid cluttering of parameters.
> * All API capabilities should return only the data requested to
> minimize bandwidth and improve speed.
> Good luck!
Hi, Aayush. I'm cc'ing the mediawiki-api mailing list.
* Do you plan on working in a branch for a few weeks or months and then
merging it into master on September 10th? It seems to me that it would
be better to write improvements one by one and have a lot of smaller merges.
* What kind of documentation will you be writing? A walkthrough of the
code so future developers can understand it? Some kind of user-facing
manual? Other things?
* Have you already reviewed
https://www.mediawiki.org/wiki/API/REST_proposal , read the last few
months of the mediawiki-api mailing list
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api , and looked
at the recent changes to the API code
https://gerrit.wikimedia.org/r/#/q/message:api+status:merged,n,z to see
what the current trends are?
* Can you tell us how long it has taken you to do similar projects in
* Who are your mentors?
Engineering Community Manager