Happy Monday,
There are strange people who make such links (kindof urlencoded?):
[[Második világháború#Partrasz.C3.A1ll.C3.A1s Szic.C3.ADli.C3.A1ban
.28Huskey hadm.C5.B1velet.29|Huskey hadműveletben]]
So the section title must have been copied from the URL.
Do we have a ready tool to fix these?
--
Bináris
Hello all
>From one of my assignments as a bot operator I have some code which
does template parsing and general text parsing (e.g. Image/File tags).
It is not using regex and thus able to correctly parse nested
templates and other such nasty things. I have written those as library
classes and written tests for them which cover almost all of the code.
I would now really like to contribute that code back to the community.
Would you be interested in adding this code to the pywikibot
framework? If yes, can I send the code to someone for code review or
how do you usually operate?
Greetings
Hannes
PS: wiki userpage is http://en.wikipedia.org/wiki/User:Hannes_R%C3%B6st
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
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.
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
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
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