Bugs item #3467493, was opened at 2011-12-30 07:30
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: xqt (xqt)
Summary: interwiki.py crashes if bot is blocked
Initial Comment:
I have python v2.7.2
I run a bot that operates on every wiki so it is painful to modify user-config file every time there is a problem.
Every now and then I get all of bots interwiki operations disrupted if a wikipedia language edition decides to block. The bot running interwiki.py crashes after trying to edit that wiki. This is a problem because any block on any wiki effectively disables the bot until that block is lifted.
I thought this was a feature (somehow) until I was told this could be a bug.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 08:56
Message:
You cannot know the reason of the blocking and indeed the bot itself
doesn't know it. New mediawiki release as could cause problems with the bot
as well as wrong python code, some python interpreters doesn't work well,
unicode errors are found etc. pp. Most of the smaller wikis doesn't have
sysops and blocking a bot is a emergency shut down. My bot is running on
all wikis with multiple continous tasks too. Where is the problem? First
ask for permission than run the job. My thought.
----------------------------------------------------------------------
Comment By: https://www.google.com/accounts ()
Date: 2011-12-30 08:12
Message:
In my case my user-config.py just loops all wikis rather than me typing
them individually so that is a lot of work. Also that is unhelpful if one
is having multiple continuous interwiki.py runs which can take weeks. It is
a logistical nightmare to try to figure out which runs crashed and etc.
The bot is blocked due to it not having a bot flag (due to wiki policy
change or oversight on my part), not because of a malfunction. Indeed it is
a serious problem but does not have a technical solution. It requires me to
apply for a bot flag locally which can be a lengthy process. The point here
is all other wikis aside from the wikis blocking should have bot continuing
with its edits.
Indeed a global block would be needed in the event of a catastrophic
malfunction of interwiki.py but this would be for all bots running
interwiki.py not just for my bot as I use the latest svn repositories.
---------------
Dump of error
Updating links on page [[it:Utente:???? robot]].
Changes to be made: Robot: Adding [[ksh:Metmaacher:???? robot]]
+ [[ksh:Metmaacher:???? robot]]
NOTE: Updating live wiki...
WARNING: Your account on wikipedia:it is blocked by False.
Reason: unauthorized bot, user contacted multiple times
Editing using this account will stop the run.
NOTE: You have new messages on wikipedia:it
WARNING: Your account on wikipedia:it does not have a bot flag. Its edits
will be visible in the recent changes and it may get blocked.
Dump en (wikipedia) appended.
Traceback (most recent call last):
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2573, in <module>
main()
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2547, in main
bot.run()
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2287, in run
self.queryStep()
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2265, in queryStep
subj.finish(self)
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 1713, in finish
if self.replaceLinks(page, new, bot):
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 1952, in replaceLinks
status, reason, data = page.put(newtext, comment=mcomment)
File "C:\Dev\SVN\pywikipedia\wikipedia.py", line 1713, in put
self.site().checkBlocks(sysop = sysop)
File "C:\Dev\SVN\pywikipedia\wikipedia.py", line 5023, in checkBlocks
raise UserBlocked('User is blocked in site %s' % self)
pywikibot.exceptions.UserBlocked: User is blocked in site wikipedia:it
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-30 07:57
Message:
If a bot is blocked on a wiki, just remove it from your user-config.py. I
find it not a good idea to run a blocked bot without checking the cause.
This indeed could be a malfunction and it is a good idea to stop it in
general until this has been veryfied.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Bugs item #3467493, was opened at 2011-12-30 07:30
Message generated for change (Comment added) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
>Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: xqt (xqt)
Summary: interwiki.py crashes if bot is blocked
Initial Comment:
I have python v2.7.2
I run a bot that operates on every wiki so it is painful to modify user-config file every time there is a problem.
Every now and then I get all of bots interwiki operations disrupted if a wikipedia language edition decides to block. The bot running interwiki.py crashes after trying to edit that wiki. This is a problem because any block on any wiki effectively disables the bot until that block is lifted.
I thought this was a feature (somehow) until I was told this could be a bug.
----------------------------------------------------------------------
>Comment By: https://www.google.com/accounts ()
Date: 2011-12-30 08:12
Message:
In my case my user-config.py just loops all wikis rather than me typing
them individually so that is a lot of work. Also that is unhelpful if one
is having multiple continuous interwiki.py runs which can take weeks. It is
a logistical nightmare to try to figure out which runs crashed and etc.
The bot is blocked due to it not having a bot flag (due to wiki policy
change or oversight on my part), not because of a malfunction. Indeed it is
a serious problem but does not have a technical solution. It requires me to
apply for a bot flag locally which can be a lengthy process. The point here
is all other wikis aside from the wikis blocking should have bot continuing
with its edits.
Indeed a global block would be needed in the event of a catastrophic
malfunction of interwiki.py but this would be for all bots running
interwiki.py not just for my bot as I use the latest svn repositories.
---------------
Dump of error
Updating links on page [[it:Utente:???? robot]].
Changes to be made: Robot: Adding [[ksh:Metmaacher:???? robot]]
+ [[ksh:Metmaacher:???? robot]]
NOTE: Updating live wiki...
WARNING: Your account on wikipedia:it is blocked by False.
Reason: unauthorized bot, user contacted multiple times
Editing using this account will stop the run.
NOTE: You have new messages on wikipedia:it
WARNING: Your account on wikipedia:it does not have a bot flag. Its edits
will be visible in the recent changes and it may get blocked.
Dump en (wikipedia) appended.
Traceback (most recent call last):
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2573, in <module>
main()
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2547, in main
bot.run()
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2287, in run
self.queryStep()
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 2265, in queryStep
subj.finish(self)
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 1713, in finish
if self.replaceLinks(page, new, bot):
File "C:\Dev\SVN\pywikipedia\interwiki.py", line 1952, in replaceLinks
status, reason, data = page.put(newtext, comment=mcomment)
File "C:\Dev\SVN\pywikipedia\wikipedia.py", line 1713, in put
self.site().checkBlocks(sysop = sysop)
File "C:\Dev\SVN\pywikipedia\wikipedia.py", line 5023, in checkBlocks
raise UserBlocked('User is blocked in site %s' % self)
pywikibot.exceptions.UserBlocked: User is blocked in site wikipedia:it
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-30 07:57
Message:
If a bot is blocked on a wiki, just remove it from your user-config.py. I
find it not a good idea to run a blocked bot without checking the cause.
This indeed could be a malfunction and it is a good idea to stop it in
general until this has been veryfied.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Bugs item #3467493, was opened at 2011-12-30 07:30
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
>Status: Pending
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: xqt (xqt)
Summary: interwiki.py crashes if bot is blocked
Initial Comment:
I have python v2.7.2
I run a bot that operates on every wiki so it is painful to modify user-config file every time there is a problem.
Every now and then I get all of bots interwiki operations disrupted if a wikipedia language edition decides to block. The bot running interwiki.py crashes after trying to edit that wiki. This is a problem because any block on any wiki effectively disables the bot until that block is lifted.
I thought this was a feature (somehow) until I was told this could be a bug.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 07:57
Message:
If a bot is blocked on a wiki, just remove it from your user-config.py. I
find it not a good idea to run a blocked bot without checking the cause.
This indeed could be a malfunction and it is a good idea to stop it in
general until this has been veryfied.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Bugs item #3467493, was opened at 2011-12-30 07:30
Message generated for change (Tracker Item Submitted) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: interwiki.py crashes if bot is blocked
Initial Comment:
I have python v2.7.2
I run a bot that operates on every wiki so it is painful to modify user-config file every time there is a problem.
Every now and then I get all of bots interwiki operations disrupted if a wikipedia language edition decides to block. The bot running interwiki.py crashes after trying to edit that wiki. This is a problem because any block on any wiki effectively disables the bot until that block is lifted.
I thought this was a feature (somehow) until I was told this could be a bug.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3467493&group_…
Bugs item #3012516, was opened at 2010-06-07 04:02
Message generated for change (Comment added) made by bewareofdoug
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3012516&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Kenrick Anggara (kenrick95)
Assigned to: Nobody/Anonymous (nobody)
Summary: cosmetic_changes.py : bot remove double interwiki
Initial Comment:
My bot :
http://id.wikipedia.org/w/index.php?title=Rangkaian_seri_dan_paralel&diff=3…http://id.wikipedia.org/w/index.php?title=Rangkaian_seri_dan_paralel&diff=3…
Other's bot but I'm sure it is the same version as mine :
http://id.wikipedia.org/w/index.php?title=Piala_Thomas_dan_Uber_2010&diff=3…http://id.wikipedia.org/w/index.php?title=Piala_Thomas_dan_Uber_2010&diff=3…
My bot (Kenrick95Bot) version :
Pywikipedia nightly:pywikipedia (r28, 2010/03/16, 11:21:32)
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
config-settings:
use_api = True
use_api_login = True
Please fix... Thanks...
----------------------------------------------------------------------
>Comment By: Doug (bewareofdoug)
Date: 2011-12-30 04:31
Message:
I agree completely, at least for now. This is the solution that has been
adopted on wikisources and implemented in a script by Candalua.
Essentially nobody else touches mainspace works which is where the multiple
interwikis show up.
Possibly in the long run Wikisources need to abandon interlanguage linking
by this method and switch to a different method of linking translations,
but that's a problem for wikisource.org and the wikimedia bugzilla world.
I will attach Candalua's solution (after I confirm with him that's it's
free licensed) for discussion/review.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-30 04:23
Message:
The currently most widely accepted paradigm is a 1:1 relationship between
pages of different sites. Multiple interwiki links means these pages does
not match exact each other. Ok some people wants links which match pages
they are quite similar. I know at wikisource this a most imported issue. As
valhallash says implementation is not trivial because a central paradigma
the bot is working with must be changed. I think there are several points:
MediaWiki too cannot deal with multiple interwiki links by returning them
via api
pwb cannot deal with multiple iw links. Changing it concerns the data
structures and most of the given methods dealing with iw links. My idea is
ignoring all source and target pages with multiple interwiki links like it
does with interwiki conflicts (if the methods are able to handle with ist)
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 10:32
Message:
The interlanguage extension exists and is stable:
http://www.mediawiki.org/wiki/Extension:Interlanguage
However, it does *not* solve this problem at all as far as I can see, it
simply replaces the interwiki language link system currently in use. It
won't help on any project it isn't adopted on and it won't likely be
adopted on wikisources unless it adds a lot more than it takes away.
Waiting on the across the board adoption of an extension to fix a bug that
can be easily avoided (by making the bot skip such pages) seems like a very
bad idea.
Interwiki.py's behavior is wrong in this case as well, which is part of the
issue.
----------------------------------------------------------------------
Comment By: Merlijn S. van Deen (valhallasw)
Date: 2011-12-29 10:23
Message:
It's not entirely trivial to fix this at the moment. Cosmetic_changes
essentially does what interwiki.py does: it only uses the *last* mention of
a certain language.
Changing this behaviour will break interwiki.py, so it has to be
implemented with some care.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-29 09:33
Message:
We are waiting for the interlanguage extension ;)
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 07:18
Message:
bug
https://sourceforge.net/tracker/?func=detail&aid=3465680&group_id=93107&ati…
has been identified as a duplicate of this bug, I don't think we should
close the other bug report yet because, although the code involved may be
the same, the actual issue is slightly different. cosmetic_changes.py
should convert [[en:Steveville|Steveville]] to
[[:en:Steveville|Steveville]] because it's in the body of the article
rather than treating it as an interwiki language link.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-27 14:01
Message:
It is open, what you see is Valhallasw changing the close_date to none when
he essentially reversed xqt's change of the same day. I've increased the
priority and removed assignment to xqt as his last action was to close it
as "Wont Fix", so there's no reason to believe that he's actually working
on this.
Last I knew interwiki.py did the same thing.
Is that the same issue? I mean does cosmetic_changes.py get the removal
function from interwiki.py or is the same code at least. We have a work
around on ws (where double and triple interwikis are common) though it
really means skipping such pages.
----------------------------------------------------------------------
Comment By: Yevhen Movsesov ()
Date: 2011-12-26 23:04
Message:
1. Is this issue is "Open" ? Ask, because on this page I see
"close_date 2010-06-09 00:36"
2. If it "Open" please increase priority, or provide workaround.
3. s this problem with "standardizePageFooter" module ?
If yes, which line should I comment as workaround ?
----------------------------------------------------------------------
Comment By: Merlijn S. van Deen (valhallasw)
Date: 2010-06-09 00:54
Message:
In no case should a bot destroy data, especially not if the reasoning
behind it is 'the software cannot cope with it'. A double interwiki might
be wrong from a MediaWiki/pwb perspective, but it is *not* wrong from a
content perspective. As such, they should simply be left alone.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2010-06-09 00:36
Message:
MediaWiki also could not handle double interwiki to the same site. It only
saves one link into its database and only one link is reachable via api or
database request. Unless this is not changed by MediaWiki's behavior I do
propose not to changed bot's behavior.
----------------------------------------------------------------------
Comment By: JAn (jandudik)
Date: 2010-06-07 07:46
Message:
Double interwiki in page is incorrect - interwiki bot cannot handle it and
it makes problem for them.
----------------------------------------------------------------------
Comment By: Kenrick Anggara (kenrick95)
Date: 2010-06-07 04:09
Message:
Update :
I have updated my Pywikipediabot into the latest version. I test it on that
Thomas & Uber Cup page and the result is :
http://id.wikipedia.org/w/index.php?title=Piala_Thomas_dan_Uber_2010&diff=3…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3012516&group_…
Bugs item #3012516, was opened at 2010-06-07 04:02
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3012516&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Kenrick Anggara (kenrick95)
Assigned to: Nobody/Anonymous (nobody)
Summary: cosmetic_changes.py : bot remove double interwiki
Initial Comment:
My bot :
http://id.wikipedia.org/w/index.php?title=Rangkaian_seri_dan_paralel&diff=3…http://id.wikipedia.org/w/index.php?title=Rangkaian_seri_dan_paralel&diff=3…
Other's bot but I'm sure it is the same version as mine :
http://id.wikipedia.org/w/index.php?title=Piala_Thomas_dan_Uber_2010&diff=3…http://id.wikipedia.org/w/index.php?title=Piala_Thomas_dan_Uber_2010&diff=3…
My bot (Kenrick95Bot) version :
Pywikipedia nightly:pywikipedia (r28, 2010/03/16, 11:21:32)
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
config-settings:
use_api = True
use_api_login = True
Please fix... Thanks...
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 04:23
Message:
The currently most widely accepted paradigm is a 1:1 relationship between
pages of different sites. Multiple interwiki links means these pages does
not match exact each other. Ok some people wants links which match pages
they are quite similar. I know at wikisource this a most imported issue. As
valhallash says implementation is not trivial because a central paradigma
the bot is working with must be changed. I think there are several points:
MediaWiki too cannot deal with multiple interwiki links by returning them
via api
pwb cannot deal with multiple iw links. Changing it concerns the data
structures and most of the given methods dealing with iw links. My idea is
ignoring all source and target pages with multiple interwiki links like it
does with interwiki conflicts (if the methods are able to handle with ist)
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 10:32
Message:
The interlanguage extension exists and is stable:
http://www.mediawiki.org/wiki/Extension:Interlanguage
However, it does *not* solve this problem at all as far as I can see, it
simply replaces the interwiki language link system currently in use. It
won't help on any project it isn't adopted on and it won't likely be
adopted on wikisources unless it adds a lot more than it takes away.
Waiting on the across the board adoption of an extension to fix a bug that
can be easily avoided (by making the bot skip such pages) seems like a very
bad idea.
Interwiki.py's behavior is wrong in this case as well, which is part of the
issue.
----------------------------------------------------------------------
Comment By: Merlijn S. van Deen (valhallasw)
Date: 2011-12-29 10:23
Message:
It's not entirely trivial to fix this at the moment. Cosmetic_changes
essentially does what interwiki.py does: it only uses the *last* mention of
a certain language.
Changing this behaviour will break interwiki.py, so it has to be
implemented with some care.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-29 09:33
Message:
We are waiting for the interlanguage extension ;)
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 07:18
Message:
bug
https://sourceforge.net/tracker/?func=detail&aid=3465680&group_id=93107&ati…
has been identified as a duplicate of this bug, I don't think we should
close the other bug report yet because, although the code involved may be
the same, the actual issue is slightly different. cosmetic_changes.py
should convert [[en:Steveville|Steveville]] to
[[:en:Steveville|Steveville]] because it's in the body of the article
rather than treating it as an interwiki language link.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-27 14:01
Message:
It is open, what you see is Valhallasw changing the close_date to none when
he essentially reversed xqt's change of the same day. I've increased the
priority and removed assignment to xqt as his last action was to close it
as "Wont Fix", so there's no reason to believe that he's actually working
on this.
Last I knew interwiki.py did the same thing.
Is that the same issue? I mean does cosmetic_changes.py get the removal
function from interwiki.py or is the same code at least. We have a work
around on ws (where double and triple interwikis are common) though it
really means skipping such pages.
----------------------------------------------------------------------
Comment By: Yevhen Movsesov ()
Date: 2011-12-26 23:04
Message:
1. Is this issue is "Open" ? Ask, because on this page I see
"close_date 2010-06-09 00:36"
2. If it "Open" please increase priority, or provide workaround.
3. s this problem with "standardizePageFooter" module ?
If yes, which line should I comment as workaround ?
----------------------------------------------------------------------
Comment By: Merlijn S. van Deen (valhallasw)
Date: 2010-06-09 00:54
Message:
In no case should a bot destroy data, especially not if the reasoning
behind it is 'the software cannot cope with it'. A double interwiki might
be wrong from a MediaWiki/pwb perspective, but it is *not* wrong from a
content perspective. As such, they should simply be left alone.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2010-06-09 00:36
Message:
MediaWiki also could not handle double interwiki to the same site. It only
saves one link into its database and only one link is reachable via api or
database request. Unless this is not changed by MediaWiki's behavior I do
propose not to changed bot's behavior.
----------------------------------------------------------------------
Comment By: JAn (jandudik)
Date: 2010-06-07 07:46
Message:
Double interwiki in page is incorrect - interwiki bot cannot handle it and
it makes problem for them.
----------------------------------------------------------------------
Comment By: Kenrick Anggara (kenrick95)
Date: 2010-06-07 04:09
Message:
Update :
I have updated my Pywikipediabot into the latest version. I test it on that
Thomas & Uber Cup page and the result is :
http://id.wikipedia.org/w/index.php?title=Piala_Thomas_dan_Uber_2010&diff=3…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3012516&group_…
Bugs item #3465680, was opened at 2011-12-26 13:47
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3465680&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Pending
Resolution: Invalid
Priority: 7
Private: No
Submitted By: Yevhen Movsesov ()
Assigned to: xqt (xqt)
Summary: Cosmetic_changes.py deletes cross wiki-links
Initial Comment:
Python 2.6.7 (r267:88850, Sep 19 2011, 13:25:28)
[GCC 4.5.2]
config-settings:
use_api = True
use_api_login = True
unicode test: ok
1. I ran in RU-wiki one command:
python /home/$USERNAME/pywiki/cosmetic_changes.py -lang:ru -always -file:/tmp/somefile
2. File "/tmp/somefile" contain list of articles for processing
Struthiomimus
QoS
3. For article "Struthiomimus" in RU-wiki I see, that it was deleted EN cross-link
[[en:Steveville|Steveville]]
https://secure.wikimedia.org/wikipedia/ru/w/index.php?title=Struthiomimus&d…
4. I think, that cosmetic_changes.py should not deletes cross-links to other wikis.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 03:58
Message:
If this link is the only iw link to another side it will be re-placed to
the bottom of the page. Otherwise it will be deleted (which is an other bug
tracker). The given issue is indeed wrong. I was not a inline interwiki
link as you proposed, it was a malformed crosswiki link. Maybe interwiki
always should start at the beginning of a new line, which must be supported
by mw software. But here are several wikis which place interwiki on one
line and/or on top of a page. See some switches in the config.py.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 10:47
Message:
It's still a bug to remove a link that isn't supposed to be removed, even
if the link is improperly formed. The bug isn't invalid, it's just not
possible to overcome by normal means (as someone pointed out to me on IRC,
users sometimes put real interwiki language links in the body because they
don't know the correct place. Though, it would probably be possible to get
the bot to avoid these.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-29 09:25
Message:
Like mediawiki software pwb interprets [[en:Steveville|Steveville]] as a
interwiki link not as a crosswiki link. These must be writen as
[[:en:Steveville|Steveville]] . I do not see anything wrong with the bot.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 07:20
Message:
This may be caused by the same code but the desired effect is slightly
different, so it's not entirely a dup - but it is obviously related. In
this case though, cosmetic_changes.py should convert
[[en:Steveville|Steveville]] to [[:en:Steveville|Steveville]] because it's
in the body of the article rather than treating it as an interwiki language
link.
----------------------------------------------------------------------
Comment By: Yevhen Movsesov ()
Date: 2011-12-26 22:59
Message:
It seems, it the same issue as
https://sourceforge.net/tracker/?func=detail&aid=3012516&group_id=93107&ati…
----------------------------------------------------------------------
Comment By: Yevhen Movsesov ()
Date: 2011-12-26 22:48
Message:
Error with "standardizePageFooter".
When I comment line
# text = self.standardizePageFooter(text)
in file cosmetic_changes.py
then I can't reproduce error.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3465680&group_…
Feature Requests item #3467116, was opened at 2011-12-29 12:09
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3467116&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
Group: None
Status: Open
Priority: 7
Private: No
Submitted By: hiw (hiw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ignore archives
Initial Comment:
Since there are sometimes interwikis on pages like it happened here:
http://de.wikipedia.org/w/index.php?title=Wikipedia:Auskunft/Archiv/2010/Wo…
Since this page is an archive, marked with the template {{Archiv}} I suggest adding all those templates to the ignore page section in the pagegenerator.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 03:51
Message:
I guess this is from the script we are acting on. pagegenerators.py should
ignore archives by default.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3467116&group_…
Bugs item #2284104, was opened at 2008-11-14 06:03
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=2284104&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: JAn (jandudik)
Assigned to: Nobody/Anonymous (nobody)
Summary: {{Delete}} and #REDIRECT
Initial Comment:
There is some bug: redirect which contains {{delete}} template is counted as new possibility and causes bot to skip interwiki or to report page without interwiki.
I think, the best would be:
==[[Article]] is marked for deleting: skipping==
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 03:37
Message:
I guess this is still valid. It depends on the way {{delete}} templates are
placed on the redirect. If it is in fron of the #redirect tag that page is
no longer recognized as a redirect page and pywikibot.Page.isredirect()
returns False.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-30 03:10
Message:
Is this still valid and if so can someone provide a greater explanation of
the issue.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=2284104&group_…
Bugs item #1924322, was opened at 2008-03-24 06:19
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=1924322&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Doug (bewareofdoug)
Summary: interwiki links on subpages in templates
Initial Comment:
In English and some other major wikipedias interwiki links are placed on /doc subpage (or whatever it's called) in templates. Interwiki bot should check if such a page exists and not place interwiki links on main template page but place/update links on that subpage. Otherwise, everytime a bot places interwiki on a template with this structure, the main template page needs to be cleaned and interwiki links moved to a subpage manually
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2011-12-30 03:33
Message:
this tracker is still valid. Bots only keeps track of these subpaces and
prevents placing iw to the main page but does not place interwiki links on
these subpage. But it should.
btw please do not assign the tracker to you until you'll fix it.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-30 03:04
Message:
Is this still valid? I thought we had fixed this behavior and interwiki.py
was now able to work with /doc links. I will test this but I'm pretty sure
it's solved so if someone has the revision number where it was fixed that
would be great to note here.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2009-12-11 02:27
Message:
{{template doc}} and the other redirects at en-wiki will be added with next
revision (might be r7762)
----------------------------------------------------------------------
Comment By: JAn (jandudik)
Date: 2009-12-10 08:17
Message:
Please, add redirects to {{Documentation}} too
http://en.wikipedia.org/w/index.php?title=Template:4TeamRR&diff=prev&oldid=…
there are 4 or 5 redirects to this template in en:
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2009-12-10 03:58
Message:
Behaviour changed. Interwiki bot doesn't change templates with
{{document}}-templates inside. This also works for the corresponding
template on de: and cs:-wiki.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2009-08-23 13:07
Message:
On dewiki templates can contain {{Dokumentation}} which will include
interwikis listed on subpage /Meta
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-04-25 14:57
Message:
Logged In: NO
A few pages in the project namespace also use subpages for headers and
interwiki links. Subpages usually have <includeonly> around the iw and
category links, interwiki bots should leave that in place.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-04-17 13:13
Message:
Logged In: NO
Every like it about his problem.
If there is a page with subpages in templates. The interwiki links on the
subpages needs to places in inside the nowiki section. So if the last word
of the page is </nowiki> the interwiki link needs to be placed before the
</nowiki> tag.
I'm the operator of the CarsracBot with its home on the nl.wikipedia.org
And I have seen this behaviour on that articles where
en:list_of_asteroides/1101-1200 is a part of.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=1924322&group_…