pywikibot

pywikibot@lists.wikimedia.org

3 participants
6830 discussions

[Pywikipedia-l] Pywikibot mailing list page redesigned
by Amir Ladsgroup 16 Jun '14

16 Jun '14

Hello, As you may now, the pages of pywikibot mailing lists (*Pywikipedia-l* <https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l>, *Pywikipedia-bugs* <https://lists.wikimedia.org/mailman/listinfo/pywikipedia-bugs>, *Pywikipedia-announce* <https://lists.wikimedia.org/mailman/listinfo/pywikipedia-announce>, *Pywikibot-commits* <https://lists.wikimedia.org/mailman/listinfo/pywikibot-commits>) have changed. It's based on one of templates that has been written by Quim Gil with some small changes. What do you think about it? Is any further changes needed? Best -- Amir

5 7

[Pywikipedia-l] querying only some properties for WikibasePage
by Ricordisamoa 16 Jun '14

16 Jun '14

I still can't find a way to query only some item properties (e.g. claims) from the Wikibase API using pywikibot. I've tried all of them: .get('claims') .get(True, 'claims') .get(force=True, 'claims') .get('claims', force=True) .get('claims', True) but without success. Bots often don't need all of the items' data, so such feature should be implemented (or, if present, documented better!) PS: is it worth to implement the 'wbgetclaims' action in our framework?

3 4

[Pywikipedia-l] Secret management
by John Mark Vandenberg 15 Jun '14

15 Jun '14

We have four sets of cleartext passwords (http & proxy & db), and secrets such as various API keys and mw cookies and edit tokens. The passwords are stored in two files in clear text (user-config.py and. passwd). Other secrets are in cached api files, etc. I would like to introduce an optional dependency on a library to manage (some of?) these secrets. The current secret storage would continue to work correctly. The keyring package is the obvious candidate. Any objections or improvements on that? -- John Vandenberg

2 2

Re: [Pywikipedia-l] Secret management
by Jitse Niesen 15 Jun '14

15 Jun '14

-------- Original message -------- From: John Mark Vandenberg <jayvdb(a)gmail.com> Date: 15/06/2014 08:19 (GMT+00:00) To: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org> Subject: [Pywikipedia-l] Secret management We have four sets of cleartext passwords (http & proxy & db), and secrets such as various API keys and mw cookies and edit tokens. The passwords are stored in two files in clear text (user-config.py and. passwd). Other secrets are in cached api files, etc. I would like to introduce an optional dependency on a library to manage (some of?) these secrets. The current secret storage would continue to work correctly. The keyring package is the obvious candidate. Any objections or improvements on that? -- John Vandenberg

1 0

Re: [Pywikipedia-l] (core) Adding code in scripts/i18n to gerritreview
by info＠gno.de 13 Jun '14

13 Jun '14

The i18n dict file must be committed first and you have to update submodules before your script works well. For your working copy you may c&p the dict file into the scripts/i18n folder for testing purposes. Greetings xqt ----- Ursprüngliche Nachricht ----- Von: Travis Briggs Gesendet: 12.06.2014 19:30 An: Pywikibot discussion list Betreff: Re: [Pywikipedia-l] (core) Adding code in scripts/i18n to gerritreview Okay, so my follow up question is about this line: comment = i18n.twtranslate(pywikibot.Site(), "selflink-remove") Will that somehow work properly before the scripts/i18n code is submitted? Or do I have to submit the i18n code first and then make the core scripts change? Thanks! -Travis On 12 June 2014 09:22, <info(a)gno.de> wrote: ----- Original Nachricht ---- Von: Travis Briggs <audiodude(a)gmail.com> An: pywikipedia-l(a)lists.wikimedia.org Datum: 12.06.2014 02:41 Betreff: [Pywikipedia-l] (core) Adding code in scripts/i18n to gerrit review > Hi, > > I've sent my first patch for code review ( > https://gerrit.wikimedia.org/r/#/c/138661/) > > As part of the review, it was noted that I should move a 'msg' variable > into scripts/i18n. I have done so, however now I'm wondering what the > review process for code in that submodule? > > Is there a way to add my i18n code to the same gerrit review? Conceptually > it is one change, though I'm not sure if maybe the way the i18n works is > that the script can function with the corresponding i18n script missing. Is > that possible? > > Thanks, > -Travis > > You can't. You must not use scripts/i18n directly but you have to commit the messages dict to pywikibot-i18n repository Greetings xqt _______________________________________________ Pywikipedia-l mailing list Pywikipedia-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l

1 0

[Pywikipedia-l] (core) Adding code in scripts/i18n to gerrit review
by Travis Briggs 12 Jun '14

12 Jun '14

Hi, I've sent my first patch for code review ( https://gerrit.wikimedia.org/r/#/c/138661/) As part of the review, it was noted that I should move a 'msg' variable into scripts/i18n. I have done so, however now I'm wondering what the review process for code in that submodule? Is there a way to add my i18n code to the same gerrit review? Conceptually it is one change, though I'm not sure if maybe the way the i18n works is that the script can function with the corresponding i18n script missing. Is that possible? Thanks, -Travis

2 2

Re: [Pywikipedia-l] site.lang and site.code
by info＠gno.de 12 Jun '14

12 Jun '14

in core branch site.lang is reserved for i18n translations from twn and other language based issues where as site.code is for site related issues like L10N etc. Because i18n was backported to compat branch and compat does not distinguish between site.code and site.lang the i18n dictionary uses code not lang key. The "right" key is catched by a codemap inside translatewiki which also maps languages like "sr-ec" to "sr" or "tt-cyrl" to "tt" etc. when the dictionaries are exported. I agree if we went back to site.lang language code for i18n translations. The mapping at compat could easily done by i18n._altlang() (btw. its parameter is called "code" leftover from compat) Best xqt ----- Original Nachricht ---- Von: Ricordisamoa <ricordisamoa(a)openmailbox.org> An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org> Datum: 04.06.2014 14:44 Betreff: [Pywikipedia-l] site.lang and site.code > I am not sure it's always better to use site.code instead of site.lang. > If TranslateWiki uses language codes, 'be-tarask' should be used instead > of 'be-x-old', etc. > > _______________________________________________ > Pywikipedia-l mailing list > Pywikipedia-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l >

2 2

[Pywikipedia-l] mwparserfromhell
by Ricordisamoa 12 Jun '14

12 Jun '14

Since gerrit:131263 <https://gerrit.wikimedia.org/r/131263/> , it seems to me that the excellent mwpfh is going to be used more and more extensively within our framework. Am I right? For example, the DuplicateReferences detection and fix in reflinks.py could be brightly refactored without regular expressions. Or are we supposed to do the opposite conversion, where possible?

4 7

[Pywikipedia-l] Wikidata API function "wbsetclaim" not available in pywikibot?
by Frank Wein 11 Jun '14

11 Jun '14

Hi, do I see it correctly that there is no function in pywikibot-core (yet?) to call the Wikidata API function "wbsetclaim" (see http://www.wikidata.org/w/api.php for some docu)? I wanted to use that function to insert a new claim at a certain index position when a claim with the same property already exists. I found out there was(?) a patch for a setClaim function, but looks like it was backed out again (http://www.gossamer-threads.com/lists/wiki/mediawiki-cvs/384671?do=post_vie… Someone on IRC said I could use https://gerrit.wikimedia.org/r/#/c/125575/ as soon as it has been checked in to overwrite the whole item/entity with editEntity as some kind of workaround (not sure yet what the overhead of this compared to using wbsetclaim would be). Frank

2 2

[Pywikipedia-l] getters and setters
by Ricordisamoa 09 Jun '14

09 Jun '14

It seems to me that the current trend is to use the same attribute as both a getter and a setter, e.g. Page.text. Is this true? Should we convert Claim.getTarget() and .setTarget() to just "target" (which is already used internally)?

6 16

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

pywikibot