Betreff: Aw: Re: [Pywikipedia-l] drop support for python 2.6
> Currently user-agent _is_ included (by pywikibot/comms/http.py)
>
> xqt
>
Ah, no! Its the framework release, not the py version.
Sorry disturbing you
xqt
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?
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
-------- 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
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
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
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
>
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?