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?
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
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)?
Hi,
My name is Travis Briggs and I'm a software developer who currently works
at Google in California. I've always had a soft spot for Wikipedia and
wondered how I could get more involved and contribute more. Today, I was
thinking about how it's a shame that Media Wiki is written in PHP, as that
is a language that I'm not really interested in hacking on in my spare
time. Then I found pywikibot. Python is probably the language I have the
most current experience in, besides maybe Javascript, and I'm familiar with
web API usages.
All this to say, I'd like to see if I can help out on the pywikibot project
itself, though I don't have a specific wiki that I work on or a specific
bot that I'd like to write.
I've gotten as far as installing a vagrant instance of Media Wiki and
cloning the "core" branch of pywikibot, though I haven't gotten them
talking to each other just yet.
Thanks!
-Travis
The performance searching in a list or a tuple is both the same and both bad. Better performance has searching inside a string or in indexed types like set and dict whereas instantiating them is time consuming.
Using list may lead to unexpected side effects because they are mutable objects whereas tuples are immutable. I remember bugs with lists as parameters to methods or setting a view to lists inside family file content and change them instead of copy its values.
That's the reason why I prefer tuples when the content never has to be changed.
For the given example there is no difference.
Greetings
xqt
----- Original Nachricht ----
Von: Merlijn van Deen <valhallasw(a)arctus.nl>
An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org>
Datum: 07.06.2014 00:13
Betreff: Re: [Pywikipedia-l] lists vs tuples
> On 6 June 2014 23:49, Ricordisamoa <ricordisamoa(a)openmailbox.org> wrote:
>
> > Should we always use tuples when instantiating them only once? E.g.
> > *if* abc *in* ('e', 'f'):
> > instead of
> > *if* abc *in* ['e', 'f']:
> >
>
> Performance-wise, I don't think it matters much; after all, most time is
> spent inside the loop, not in instantiating a list or tuple. Conceptually,
> a list often makes more sense (a list would be different items of the same
> type, while a tuple represents different properties of the same item).
>
> Merlijn
>
>
> --------------------------------
>
> _______________________________________________
> Pywikipedia-l mailing list
> Pywikipedia-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
>
Should we always use tuples when instantiating them only once? E.g.
*if*abc *in* ('e', 'f'):
instead of
*if* abc *in* ['e', 'f']:
They appear to be slightly faster sometimes.
Ive been waiting for core to get usable, and Im tired of waiting. In the
next month or two Ill be taking a good look and probably end up re-writing
half the code, and implementing quite a bit more new code so that we can
actually make core into a respectable, non-crapy product that people can
actually use. Hopefully we can get the changes merged without too much
headache. Ive been sitting on a large amount of code that Ive written over
the years and extended which extended the old compat branch into a
powerhouse.
Ive just done a SVN checkout from git and will start the process over the
weekend, If anyone has any areas that they know that core currently sucks
at and wants me to focus on that let me know
John