https://bugzilla.wikimedia.org/show_bug.cgi?id=57303
Web browser: ---
Bug ID: 57303
Summary: replace.py doesn't consider the namespace
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: l.rabinelli+bugzilla(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
In compact when run:
python replace.py -xml:itwiki.xml.bz2 -namespace:0 -fix:<name>
the script works only in main namespace article.
In core, with the same arguments, works in pages of all namespaces.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55298
Web browser: ---
Bug ID: 55298
Summary: self-interwikis shouldn't be removed
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: interwiki.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/984/
Reported by: mcknol
Created on: 2009-07-17 00:02:21
Subject: self-interwikis shouldn't be removed
Original description:
Interwiki.py removes every internal link which refers to the own language site.
For example, in en.wiki a link like \[\[en:article\]\] would be removed by the
bot. This seems logical \(the main syntax for non-interwiki interlanguage links
would be \[\[:en:article\]\]\), but the wiki-software doesn't interpret
self-links as interwiki-links, so the pywikipedia-bot should neither do that.
Here is an example:
http://en.wikipedia.org/w/index.php?title=Help:Parser\_function&diff=290795…
Pywikipedia \[http\] trunk/pywikipedia \(r7065, 2009/07/14, 19:34:51\)
Python 2.6 \(r26:66721, Oct 2 2008, 11:35:03\) \[MSC v.1500 32 bit \(Intel\)\]
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54537
Web browser: ---
Bug ID: 54537
Summary: Pagegenerator: follow redirects, intersection,
exclusion
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/patches/625/
Reported by: andreasjs
Created on: 2013-08-24 21:57:56.794000
Subject: Pagegenerator: follow redirects, intersection, exclusion
Original description:
I added three new arguments:
-followredirects
Used with other arguments that specify a set of pages.
If a specified page is a redirect page, work on its
target page.
-intersecting
Argument to be used between two other arguments.
Work only on pages normally specified by both the
previous and the next argument.
-excluding
Argument to be used between two other arguments.
Work only on pages normally specified by the
previous argument but not by the next argument.
For example, one could want to find the pages edited by a specific user that
contain a certain keyword in a title.
A few other suggestions:
Exclude sections, even on files.
Compare pages via the Page.\_\_cmp\_\_ property to exclude duplicate pages
instead of
u"%s:%s:%s" % (page._site.family.name, page._site.lang, page._title).
(more transparent and easier to maintain).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55882
Web browser: ---
Bug ID: 55882
Summary: The order of parameters is lost when using
templatesWithParams
Product: Pywikibot
Version: core (2.0)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: crangasi2001(a)yahoo.com
Blocks: 55880
Classification: Unclassified
Mobile Platform: ---
In compat, templatesWithParams from class Page used to
provide a pair containing the template name and a list of parameters,
with the full "key=value" string. Nowadays, we're getting a dictionary
instead of that list. Normally there is nothing wrong with that,
except that in Python 2 the dictionary is unordered, which means that:
* the order of the parameters is forever lost - this can be easily solved using
OrderedDict instead.
* the original text cannot be reconstructed (because of the above and
the missing whitespace information) - this means there is no easy way
to identify and/or replace a particular instance of the template in a
page with many identical templates.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=54560
Web browser: ---
Bug ID: 54560
Summary: archivebot.py edit summary i18n improvement
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/patches/561/
Reported by: acstroe
Created on: 2012-08-16 07:18:55
Subject: archivebot.py edit summary i18n improvement
Original description:
The edit summary of archivebot explains how old archived messages are, by using
the configuration string, e.g. 45d or 24h. On request from some users on ro.wp,
I have added a function that interprets these strings in accordance with the
local wiki settings. It uses the MediaWiki:Hours and MediaWiki:Days messages to
obtain the local language string. Since all wikis I tries use the PLURAL parser
function and parser functions are not interpreted in the wiki edit summary, I
parsed the PLURAL function to obtain the actual string. If the PLURAL function
is not supported, then the exact text of the MediaWiki:Hours and MediaWiki:Days
is used \(after replacing $1 with the actual number\). If the MediaWiki:Hours
or MediaWiki:Days messages are not found, then the initial configuration string
is used.
See also
https://ro.wikipedia.org/wiki/Wikipedia:Sarcini\_pentru\_robo%C8%9Bi\#Arhiv…
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55128
Web browser: ---
Bug ID: 55128
Summary: Non-fatal error starting interwiki.py in Windows
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1654/
Reported by: malafaya
Created on: 2013-08-19 11:05:10.022000
Subject: Non-fatal error starting interwiki.py in Windows
Original description:
It seems that some changes were made to version.py because of git. Under
Windows at least, now git.exe seems to be required to be in the PATH.
But, even with git.exe in the PATH, I always get the following error on
startup:
'%an' is not recognized as an internal or external command,
operable program or batch file.
It seems to be related to line 122 of version.py, which doesn't seem to work
under Windows:
info = subprocess.Popen("git log --pretty=format:'%ad|%an|%h|%H|%d'
--abbrev-commit --date=iso -1 | cat -",
shell=True,
stdout=subprocess.PIPE).stdout.read()
Another problem is that everytime I launch a script, a git.exe process runs and
gets stuck. After some few instances, the interwiki.py scripts block and I have
to start killing git's.
And, BTW, I don't always have access to the git repository when running scripts
(due to some block rules here)
D:\Work\pywikipedia>version.py
'%an' is not recognized as an internal or external command,
operable program or batch file.
Pywikipedia wikipedia.py (r-1 (unknown), 976a310, 2013/08/19, 11:40:07,
OUTDATED
)
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]
config-settings:
use_api = True
use_api_login = True
unicode test: ok
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55201
Web browser: ---
Bug ID: 55201
Summary: password not remembered?
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: login.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1435/
Reported by: warddr
Created on: 2012-04-11 16:23:05
Subject: password not remembered?
Original description:
If I run login.py -all I get for every language:Should be logged in now
but every time I start a new robot command \(like for example to move a
category\) it asks for my password again.
I also tried this on an ubuntu pc with python 2.7.2 but same result.
Here is my version.py:
Pywikipedia \[http\] trunk/pywikipedia \(r10103, 2012/04/10, 07:18:22\)
Python 2.6.6 \(r266:84292, Dec 27 2010, 00:02:40\)
\[GCC 4.4.5\]
config-settings:
use\_api = True
use\_api\_login = True
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55279
Web browser: ---
Bug ID: 55279
Summary: interwiki -ignore misbehaviour
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: interwiki.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1159/
Reported by: Anonymous user
Created on: 2010-04-11 22:10:50
Subject: interwiki -ignore misbehaviour
Original description:
When working in -force mode, pages read from -ignorefile are not just ignored
\(as the option name suggests and it would be an expected behaviour\) but are
deleted from wherever they're found, so that the bot works the same way as in
-neverlink for the given page titles. It would be more logical if the
-ignore/-ignorefile option just ignored \(skipped\) these pages. We should have
some other option for forced remove, something like -neverlink not only for a
language, but also for lang:title combinations.
Pywikipedia \[http\] trunk/pywikipedia \(r8074, 2010/04/10, 23:12:44\)
Python 2.5.1 \(r251:54863, Apr 18 2007, 08:51:08\) \[MSC v.1310 32 bit
\(Intel\)\]
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=55204
Web browser: ---
Bug ID: 55204
Summary: Link identify errors
Product: Pywikibot
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: interwiki.py
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: legoktm.wikipedia(a)gmail.com
Classification: Unclassified
Mobile Platform: ---
Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1427/
Reported by: yfdyh000
Created on: 2012-03-30 18:49:19
Subject: Link identify errors
Original description:
Script mistakenly identify interwiki link, see:
http://en.wikipedia.org/wiki/User\_talk:YFdyh-bothttp://en.wikipedia.org/w/index.php?title=Template%3ANon-free\_video\_sampl…
At the time I run the command:
2012-03-24 04:32:09 r10024 \(wikipedia.py\) Python 2.7.2 interwiki.py
"-warnfile:logs\warning-wikipedia-en.log" "-lang:en" "-cleanup" "-autonomous"
"-async"
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.wikimedia.org/show_bug.cgi?id=60749
Web browser: ---
Bug ID: 60749
Summary: catlib.py: _parseCategory's startFrom parameter
doesn't work
Product: Pywikibot
Version: compat (1.0)
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Unprioritized
Component: General
Assignee: Pywikipedia-bugs(a)lists.wikimedia.org
Reporter: mail(a)putnik.ws
Classification: Unclassified
Mobile Platform: ---
As documented startFrom parameter should be a string, but cmstartsortkey and
cmendsortkey in API are for binary keys like
'5cba0a9424348eceba340307045c0a6cba347cff5d330115018f7c8f0900'.
Maybe API was changed.
I think it's need to change in _parseCategory:
cmstartsortkey -> cmstartsortkeyprefix
cmendsortkey -> cmendsortkeyprefix
--
You are receiving this mail because:
You are the assignee for the bug.