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?
>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?
PS: wiki userpage is http://en.wikipedia.org/wiki/User:Hannes_R%C3%B6st
There are 294 bugs that are unsolved, unprioritized, and unconfirmed, in
other words we have almost 300 bugs that no one has even touched it yet. 
I thought about another bug triage but I have an idea, let's split it up
the list and work on them. What do you think? a triage or a marathon?
: list of bugs:
Is there a way to avoid having these to file to always show up as
$ git status
# On branch cat
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
# modified: externals/httplib2 (new commits)
# modified: scripts/i18n (new commits)
I found this suggestion online (can't remember where):
Some files in a repository, which are versioned (i.e. they can't be
git-ignored), are often changed,
but rarely committed. Usually these are various local configuration files
that are edited,
but should never be committed upstream.
Git lets you ignore those files by assuming they are unchanged. This is
done by running the
git update-index --assume-unchanged path/to/file.txt
but it is not a permanent solution.
I think that we should have a function which tries to login and return the
status whether that logging in is successful. What we currently do (for
example in APISite.deletepage()) is that we "try: site.login(sysop=True)
except pywikibot.NoUsername: blah blah" Isn't it better to have something
like "if site.loginABC(sysop=True): blah blah else: blah blah"
So, I write this email to ask two things.
First, should we have site.loginABC()?
Second, if we should have that function, what should be the name of that
I think we need site.loginABC() there instead of site.logged_in())
I think we need to change pwb in order to make it compatible. anyone
---------- Forwarded message ----------
From: Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>
Date: Sat, Jan 18, 2014 at 4:12 AM
Subject: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Improved
Gerrit change 107389 adds RevDel support to various API query modules,
so for example a user with the 'deletedhistory' right will be able to
retrieve the user and summary from prop=revisions.
This will cause some changes:
- list=deletedrevs, list=filearchive, list=recentchanges, and
list=watchlist formerly would not return any information at all for entries
where any field was revision-deleted. These entries will now be returned.
"hidden" indicators will be provided as is done for modules such as
- prop=imageinfo, list=logevents, prop=revisions, and list=usercontribs
will now return field values in addition to the "hidden" indicators, if the
user has the necessary user rights.
- When "hidden" indicators are returned, a new indicator "suppressed"
may also be returned to indicate whether suppression was activated.
- prop=imageinfo will now return info for revision-deleted files.
- list=logevents, when searching by user or title, will no longer skip
revisions where the user or title was revision-deleted if the requesting
user has the deletedhistory right.
- list=usercontributions will now look at the correct user rights
(deletedhistory and suppressrevision, not hideuser) to determine whether to
hide revision-deleted contributions.
All clients should be updated to expect rows with hidden fields for
deletedrevs, filearchive, recentchanges, and watchlist, and clients with
advanced permissions should be updated to properly handle (and to not
publicly reveal) the data for revision-deleted fields from these modules as
well as imageinfo, logevents, revisions, and usercontribs.
These changes will be deployed to WMF wikis with 1.23wmf11, see
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.
Brad Jorsch (Anomie)
Mediawiki-api-announce mailing list
Mediawiki-api mailing list
Hello all, mainly co-developers,
mitmproxy is a tool that allows you to sniff network traffic -- which is
incredibly useful for debugging pywikibot network issues. Of course, there
are other tools to do this (e.g. ethereal), but those are not usable
anymore now that the WMF switched to HTTPS. In addition, mitmproxy allows
you to /manipulate/ the traffic, which can be useful for tricking pywikibot
into thinking there are network issues.
This weekend, I finally got mitmproxy to work for pywikibot/core -- the
version available in ubuntu did not correctly forge SSL certificates yet.
For other interested developers, I put up a guide at
Unfortunately, the internet seems to suggest it doesn't work that well for
Windows users. http://honeyproxy.org/ is supposed to be better, but I
haven't tested it.
Von: Bináris <wikiposta(a)gmail.com>
An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org>
Datum: 15.01.2014 13:47
Betreff: Re: [Pywikipedia-l] Version numbers
> The old version number HAD some meaning. It gave a sort order, some help
> where to put a script in my mind. This new system is only useful for
> computers. Well, we can live together with that, but if there is any chance
> to install some human readable version, I would appreciate it.
I also wished a serial number in past and we discussed a patch for git in past  during review which would enable an additional number like id$. But unfortunately this would not have the same meanung as in svn before. I found serial numbers usefuff for annotate/blame the code and debugging purposes which then leaded directly to the svn CR page where the patch was submitted. But these patches given above did not give that result I wanted and has been abandoned then. SVN repository from github still comes with a serial number but this diverges form the git counter due to merging process I guess and the github server does not support custom revprops via log. So we have to have git as it is.
Is there a way to get human readable version numbers again, like in the SVN
times? This is a small annoying thing that is really unimportant compared
to other newborn problems.
Earlier we had a decimal number that had some meaning. Now there is a long
hexa string that informs only machines.