Pywikipedia-l

pywikipedia-l@lists.wikimedia.org

6393 discussions

archivebot-older-than
by Ricordisamoa 09 Aug '14

09 Aug '14

The format should be changed to "older than $1" to avoid i18n issues. Should the edit happen on TranslateWiki.net, or in our i18n files directly?

3 6

Gerrit notification
by info＠gno.de 07 Aug '14

07 Aug '14

Hi folks, couldn't we reduce the gerrit notification mails please. Getting hundreds a day of them is time consuming and not helpful. Greetings xqt

5 6

Two issues
by Amir Ladsgroup 07 Aug '14

07 Aug '14

Hello all, 1- Don't forget about the bug triage. The blog post just published <https://blog.wikimedia.org/2014/07/10/pywikibot-will-have-its-next-bug-tria…> so you can read and use it to advertise. 2- As our talk in here <https://www.mediawiki.org/wiki/API_talk:Client_code/Evaluations/Pywikibot> I want to make a patch to add username in user-agent in header of API calls. but only ISO 8859 is being supported and usernames can be anything (utf-8). For usernames that might not compatible, people need to put e-mail address in user-config.py. Is it okay for you? Any comments? Best -- Amir

8 22

Manual:Pywikibot/i18n_conversion on MediaWiki.org
by Ricordisamoa 06 Aug '14

06 Aug '14

I've cleaned it up <https://www.mediawiki.org/w/index.php?diff=1089478&oldid=788068>. Please feel free to make additional improvements.

2 1

21 easy script fixes to help our build system
by John Mark Vandenberg 04 Aug '14

04 Aug '14

The following shows a list of 21 easy fixes to scripts, which will help our build system be able to do basic sanity checks on these scripts after each patch is merged. https://bugzilla.wikimedia.org/showdependencytree.cgi?id=69069&hide_resolve… The only 'hard' one in there is 68797, as it requires setting up lua. This will be easy for people using platforms that have a 'lunatic-python' package they can install with yum/apt. Plain old patches can be submitted without using Gerrit, or even Git. https://tools.wmflabs.org/gerrit-patch-uploader/ -- John Vandenberg

1 0

Re: [Pywikipedia-l] The build is broken
by info＠gno.de 03 Aug '14

03 Aug '14

Ah, maybe. I just saw your "fixes" at my Talk page(s). xqt ----- Ursprüngliche Nachricht ----- Von: Amir Ladsgroup Gesendet: 26.07.2014 23:22 An: Pywikibot discussion list Betreff: Re: [Pywikipedia-l] The build is broken it was another bug that John and Ricordisamoa are talking about. On 7/27/14, info(a)gno.de <info(a)gno.de> wrote: > This is not a bug in testing. The test detects a bug for archivebot.py which > fails for unsigned threads. > > xqt > > ----- Ursprüngliche Nachricht ----- > Von: John Mark Vandenberg > Gesendet: 26.07.2014 18:21 > An: Pywikibot discussion list > Betreff: Re: [Pywikipedia-l] The build is broken > > On Sat, Jul 26, 2014 at 10:39 PM, Ricordisamoa > <ricordisamoa(a)openmailbox.org> wrote: >> >> The build is still broken, but because of this edit, that breaks the >> timestamp detection of the ArchiveBot. >> Maybe a fictitious, write-protected talk page should be used? > > That is being tracked on > > https://bugzilla.wikimedia.org/show_bug.cgi?id=67663 > > An alternative test page would be a good solution. > > Or maybe the unit test could allow unsigned sections to be added to > the talk page. > > -- > John Vandenberg > > _______________________________________________ > Pywikipedia-l mailing list > Pywikipedia-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l > -- Amir _______________________________________________ Pywikipedia-l mailing list Pywikipedia-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l

5 7

reflinks.py under GPL?
by Ricordisamoa 01 Aug '14

01 Aug '14

I found this in the source code of scripts/reflinks.py: Distributed under the terms of the GPL This seems to be the single case in the whole repository. Is it compatible with our license conventions? It even doesn't have a full GNU-style license header.

8 10

API query
by Sorawee Porncharoenwase 31 Jul '14

31 Jul '14

Why do we prefer "generator=" to normal query? The disadvantage of generator is that API might ignore some parameters. For example, we can't do generator=categories&gclprop=sortkey, while we can do prop=categories&clprop=sortkey. -- Sorawee Porncharoenwase

1 0

best place for general feature requests?
by Frances Hocutt 31 Jul '14

31 Jul '14

Hello all, I'm finishing up the evaluation portion of my API client library internship project. As a part of that, I'm making sure that feedback/bug reports/feature requests end up where they should be. I made several suggestions at the end of the pywikibot-core evaluation,[1] and have been linking bugzilla issues to some of the criteria. I also left comments on the documentation RFC [2] with the documentation-related suggestions. This leaves a handful of larger-scale/general/structural suggestions for change: * As of 25 July 2014, there are 105 open patches in gerrit. The patch review process should be streamlined and/or prioritized to reduce the backlog of unreviewed patches. * Iterating over a list and calling the API for each item is an inefficient use of API calls. Pywikibot could be made more efficient by combining API calls as much as possible (e.g. using generators and combining resultstitle=title1|title2|...). One option may be a constructor method that collects Page requests and enables larger, less frequent API calls. * The initial installation process features a series of obscure options and confusing installation documentation. Redesign the initial installation/configuration process to be lighter-weight, soliciting and valuing feedback from new or one-time users in the redesign process. Is it necessary to be logged in before `import pywikibot` will not cause an error? * Foster a hospitable attitude on pywikipedia-l, especially to new and/or inexperienced users. Consider agreeing on community standards for interaction; the Hacker School social rules[3] may be a useful starting point. Is Bugzilla the best place for these? Would these be useful to discuss at the pywikibot hackathon at Wikimania? Is there somewhere else these suggestions ought to go? -Frances [1] https://www.mediawiki.org/wiki/API:Client_code/Evaluations/Pywikibot#Sugges… [2] https://www.mediawiki.org/wiki/Manual:Pywikibot/Documentation_RFC#Suggestio… from pywikibot gold-standard evaluation [3] https://www.hackerschool.com/manual#sec-environment

3 3

Minimum supported mw versions
by John Mark Vandenberg 29 Jul '14

29 Jul '14

What is the minimum supported mw version for core and compat? It looks like the lowest family version() are.. core: lockwiki with 1.15.1 (not confirmed as special:version requires registration) compat: wesolve with 1.5.7, loveto with 1.8.2, and then wikitravel_shared with 1.10.1 and mozilla with 1.10.2, wikibond with 1.11alpha and twcareer & celtic & botwiki with 1.11.0, wekey & ubuntutw & openttd with 1.12.0 & krefeldwiki with 1.12alpha Re wesolve, wordsandmore.org is no longer a wiki. Re loveto, lovetoknow.com/1911encyclopedia.org/webguru.com are in various states of 'no longer a wiki'. wikitravel shared, it is now 1.22 (http://wikitravel.org/shared/Special:Version) mozilla, it is now 1.19.11 Re wikibond & twcareer & celtic & ubuntutw, they appear to be dead. botwiki is now 1.17 wekey is now 1.16 openttd is now 1.19.1 krefeldwiki is still 1.12alpha! So, 1.12alpha is the lowest living mw that we have a family file for. -- John Vandenberg

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
640
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Pywikipedia-l