Hi!
In replace.py, current version 8920, line 444:
if not page.canBeEdited():
should change to
if not self.articles and not page.canBeEdited():
The reason is that with the new -save/-savenew options (introduced in rev
8700) we may use replace.py for gathering titles, and that's what I am doing
in the minute. I want to collect titles from* fr, es, de* Wikipedias rather
than my home wiki, but they seem not to allow edits without botflag. I don't
need a flag and I won't change anything there, only save titles from those
wikis, but the current line 444 prevents me of doing that. self.articles is
not None iff -save or -savenew option is used, which means we don't edit the
wiki.
Another issue is with line 843,
titlefile = codecs.open(filename, encoding='utf-8',
mode=(lambda x: x and 'a' or
'w')(append))
I tested my original version which had an IF here as far as I remember, and
you turned it to lambda function. But somehow the -save option behaves now
just as -savenew does, i.e. overwrites the old file instead of appending.
Could you please help?
--
Bináris
Hello,
On latest versions, pywikipediabot is ignoring the hints I give either by
using -hint:lang:page, or -askhints and typing them manually afterward. It
should work as usual according to the documentation in interwiki.py, though.
Did any recent change on the code affect this behavior? It seems that the
list of hints is emptied at same point.
Best regards,
Arkaitz / TXiKiBoT
Hello all,
hi Merlijn,
here is my comment:
I also suggest reverting purodhas changes of cause we got a lot of messy bugs and side effects and it is hard to debug that problem. As descibed [1] bug #3136444 was introduced which disables removing wrong interwiki links. But just uncommenting the corresponding lines causes errors in some special cases when new is not None but empty while self.originPage is None (sorry but I was not investingating the whole stuff). Two other known follow-up bugs are #3134802 and #3140832 and maybe there are other misbehaviors.
It is not unusual to implement new features but it should be long time tested in test and real environment. And I guess this was not.
Greetings
xqt
[1] http://www.mediawiki.org/wiki/Special:Code/pywikipedia/8765#code-comments
----- Original Nachricht ----
Von: Merlijn van Deen <valhallasw(a)arctus.nl>
An: pywikipedia-l(a)lists.wikimedia.org
Datum: 21.12.2010 01:26
Betreff: Re: [Pywikipedia-l] [Pywikipedia-svn] SVN: [8785] trunk/pywikipedia
> Hello all,
>
> I'd just like to note that I'm really not happy with this:
>
> On 21 December 2010 01:11, <valhallasw(a)svn.wikimedia.org> wrote:
> > Follow-up to r8784: introducing iwkeys
> >
> > The changes by purodha seem to have some more side effects due to tight
> > coupling inside the library code. This commit fixes some additional
> > interwiki mess [1], but I am *uncertain* of any new introduced side-
> > effects.
> >
> > If any more issues arise, I suggest reverting purodha changes and
> > first applying the changes in a feature branch. Or, possibly, only
> > in the rewrite branch.
> >
> > [1]
> http://commons.wikimedia.org/w/index.php?title=Category:Tre_kronor_af_Stockh
> olm&diff=prev&oldid=47268067
>
> I am aware there is too much tightly-coupled code in the library,
> which means changes like this can have consequences in an entirely
> different part of the framework. Combined with a lack of automated
> testing, making large -or even small- changes in framework code is
> dangerous, to say the least. Especially since the code *will* be used
> throughout wikipedia, possibly causing botwars and an enormous mess.
>
> As such, I would like to suggest - *strongly* suggest - not to
> implement new features into trunk any more. The much cleaner rewrite
> should be the place to put these features. This means only bugfixes
> and family/language updates should go into trunk.
>
> Comments welcome.
>
>
> Best regards,
> Merlijn
>
> _______________________________________________
> Pywikipedia-l mailing list
> Pywikipedia-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
>
Dear Friends!
Could you please help/guide me in details (or you can show me what pages
mention it) how to use the tool *importer* from enwiki into local wiki.
Thank you so much!
--
Trantu
Hello! I gathered a lot of new interwiki bot summary translations and
transfered them into translatewiki
http://translatewiki.net/wiki/Special:Contributions/Hugo.arg but only few of
them were transfered to pywikipedia. This new system seems to be very
bureaucratic =/ Can anyone transfer them to pywikipedia or just take diectly
from here ( http://lt.wikipedia.org/wiki/Naudotojas:Hugo.arg/Vertimai )?
Also, I have a problem to put arabic writting translations to pywikipedia
(pnb, ps, arz) so I would be very glad if anyone could help me with them.
Greetings, Sarunas (user:Hugo.arg)
Hello xqt!
Hello all!
Sorry I was not able to attach a file to [1] or change 'Assigned' or
something else. This is the reason why I post this patch here.
Could you please commit it? This would be nice... :)
Thanks a lot and Greetings
Dr. Trigon
[1]
https://sourceforge.net/tracker/?func=detail&aid=3108403&group_id=93107&ati…
(cross posted to wikitech-l)
Hello,
Recently we have found a case of incorrect interwiki entry linking [[:pl:Aktywizm]]
describing philosophical concept with family of the articles on other Wikipedias
regarding political activism.
This was a human mistake and it was reverted later. However, there seems
to be no way to tell all the interwiki bots running to stop re-adding this
removed link to articles.
I have added {{nobots}} on the Polish and English Wikipedia to prevent
spreading of incorrect linking. I have tried from time to time to use
my own pywikipedia bot to remove the link (using -localright option)
and the result is the following:
https://secure.wikimedia.org/wikipedia/ro/wiki/Activism?action=history
(Saperka is my script)
I spoke with the owner of WikitanvirBot and we have stopped it for
a while completely to allow the "undo" script run and remove the links.
Unfortunately, some other bot (https://secure.wikimedia.org/wikipedia/ro/w/index.php?title=Activism&diff=5…)
changed the link again.
It seems like it is not possible to revert one mistake unless
ALL running interwiki bots will be stopped by their owners.
Sounds like an overkill (and imagine coordinating this!).
Is there some way interwiki.py could be improved (I know it should be
all different architecture) or some other way to handle this
- one could imagine - simple case?
Or are we now overtaken by robots beyond our control? :)
//Saper