Page MenuHomePhabricator

AddCategory bot uses default language instead of site lang
Closed, ResolvedPublic

Description

Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1371/
Reported by: tgr_
Created on: 2011-10-31 16:55:07
Subject: AddCategory bot uses default language instead of site lang
Assigned to: xqt
Original description:
This might be a more general problem, I did not check. I created a custom generator and used it to construct the AddCategory bot from category.py. Apparently the bot uses the default settings for language purposes instead of either accepting such options in the constructor or \(more conveniently\) checking the site of the first page returned by the generator and using the language of that. For example, running the bot on Commons resulted in edits like this:
http://commons.wikimedia.org/w/index.php?title=File:Ungar-Mayer-palace\_Szeged.jpg&diff=prev&oldid=61856537
\- both the summary and the category namespace name are in Hungarian.

version:
Pywikipedia \[http\] trunk/pywikipedia \(r9710, 2011/10/31, 05:19:34\)
Python 2.7.2+ \(default, Aug 16 2011, 09:23:59\)
\[GCC 4.6.1\]
config-settings:
use\_api = True
use\_api\_login = True
unicode test: ok


Version: core-(2.0)
Severity: minor
See Also:
https://sourceforge.net/p/pywikipediabot/bugs/1371

Details

Reference
bz55229

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:28 AM
bzimport set Reference to bz55229.

This message is from "category-adding" and the code for i18n.twtranslate\(\) comes from self.site attribute which is assigned with pywikibot.getSite\(\) by constructor. getSite\(\) gives the site your start the bot. For commons you must run the -lang:commons -family:commons options which gives an english text by default. Since this is your own script, could you check whether your lang code isn't commons on commons site?

  • assigned_to: nobody --> xqt
  • status: open --> pending

xqt, I understand that's how it works, but that seems like bad design to me. The category adder bot is constructed with a generator which yields Page objects. A Page object already references a Site object; it makes no sense to do something with it and use the settings from a different site. Also, I think it is a reasonable expectation that upon creating an object, you can pass all the relevant settings to it in the constructor, or maybe a few additional function calls, and it will not be influenced by \(the lack of\) command line arguments which are handled by a totally different module.

Yes, you are correct it's a bad design. However, this is what happens when software grows ;-\)

If you can fix it, you are vey welcome to submit a patch. For now, you could use the setSite\(\) workaround, which should be OK \(but ugly\) as long as you're running a single-threaded app.

>>> wikipedia.getSite\(\)
wikipedia:en
>>> wikipedia.setSite\(wikipedia.getSite\('nl', 'wikipedia'\)
>>> wikipedia.getSite\(\)
wikipedia:nl

you can get the site from a page object:
>>> p = wikipedia.Page\(wikipedia.getSite\(\), 'nl:test'\)
>>> p.site\(\)
wikipedia:nl

Change 118943 had a related patch set uploaded by Ricordisamoa:
Bug 55229: make i18n for AddCategory independent from default site

https://gerrit.wikimedia.org/r/118943

Change 118943 merged by jenkins-bot:
Bug 55229: make i18n for AddCategory independent from default site

https://gerrit.wikimedia.org/r/118943