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
Hi all,
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. [1]
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?
[1]: list of bugs:
https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&bug_id_type=anyexact…
Best
--
Amir
Hi.
Is there a way to avoid having these to file to always show up as
non-staged?
$ 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
directory)
#
# 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.
Bye
Mpaa
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
function?
(see also
http://lists.wikimedia.org/pipermail/pywikipedia-bugs/2014-January/007200.h…;
I think we need site.loginABC() there instead of site.logged_in())
--
Sorawee Porncharoenwase
I think we need to change pwb in order to make it compatible. anyone
interested?
---------- 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
RevDel support
To: mediawiki-api-announce(a)lists.wikimedia.org
Gerrit change 107389[1] 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=revisions.
- 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.
[1]: https://gerrit.wikimedia.org/r/#/c/107389/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
--
Amir
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
https://www.mediawiki.org/wiki/Pywikibot/mitmproxy
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.
Merlijn
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 [1][2] 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.
Greetings
xqt
[1] https://gerrit.wikimedia.org/r/#/c/77555/
[2] https://gerrit.wikimedia.org/r/#/c/77554/
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.
--
Bináris
Have you ever searched for anniversaries to put on the main page of
Wikipedia?
Or do you know users who deal with this?
I had a dream to find possible anniversaries with bot and this weekend I
did it.
The bot goes through articles and collects data in connection with the
given date.
In huwiki editors began to use it in the first minutes. :-)
It is hard to write it generally in a form suitable for all Wikipedias, so
I choosed to make localization easy with code and description.
Bot v0.8:
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/anniversary.py
Documentation:
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/anniversary.py/doc
Sample product:
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/%C3%89vfordul%C3%B3pr%…
It is not ready as the date must still be set in code (main()), but it
works and I am working on it further.
--
Bináris