Wikitech-l February 2013

wikitech-l@lists.wikimedia.org

161 participants
170 discussions

Page view stats we can believe in
by Lars Aronsson 13 Feb '13

13 Feb '13

I stumbled on the Danish Wiktionary, of all projects. Danish is the 68th biggest language of Wiktionary, and has a little more than 8,000 articles in total. Most of these articles are very short and provide no value to a reader. There is no reason to link to them, and so very unlikely that the next user should stumble upon them unless they are me. Yet, wikistats tries to make be believe that this tiny project has 400,000 or 500,000 page views each month, and has had so for a long time, http://stats.wikimedia.org/wiktionary/EN/TablesPageViewsMonthly.htm (I'm not talking about January 2012, which seems to have been an error, and reports 2-3 times that many views.) My guess is that da.wiktionary has 4,000 page views per month, not 400,000. It's more likely that 400,000 is some background noise, an offset number that should be subtracted from the number of page views for any project. If you look at the log files for just one day, you should see my IP address (85.228.something) and 3-4 other users who have been editing lately, and not many more people, but perhaps a bunch of interwiki bots. We need an explanation to these vastly inflated page view statistics. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

3 3

URLs for autogenerated documentation
by Antoine Musso 13 Feb '13

13 Feb '13

Hello, We have historically generated MediaWiki documentation on the Subversion server known as formey: https://svn.wikimedia.org/doc/ That the result of running doxygen once per day against the master branch of mediawiki/core.git. We would like to move the documentation to another host and I think it is a good time to change the URL as well to something a bit more meaningful than svn.mediawiki.org :-] We also have auto generated documentation for our puppet manifest at: http://doc.wikimedia.org/puppet/ Timo and I kind of disagree on the URL scheme to use to publish the documentation, so instead of starting a revert war in Gerrit, I thought it would be a good idea to ask some more people to participate in. For the context: We would like to have documentation generated for: - puppet - mediawiki branches and tags (PHP + JS + CSS) - mediawiki extensions (PHP + JS + CSS) The hosts doc.wikimedia.org and doc.mediawiki.org points to the same machine. I guess puppet could land at doc.wikimedia.org/puppet For MediaWiki we need the following parameters: - project (core / extension name) - version (tag / release branch / master) - type of documented source (php / js / css) What kind of magic ordering can we agree on? A) http://doc.wikimedia.org/mediawiki-core/<branch|tag>/php Would bring: doc.wikimedia.org/mediawiki-core/master/php doc.wikimedia.org/mediawiki-core/master/js doc.wikimedia.org/mediawiki-core/1.20.2/php doc.wikimedia.org/mediawiki-core/REL1_20/js doc.wikimedia.org/mediawiki-AbuseFilter/1.20.2/php B) doc.mediawiki.org/<project>/<type>/<version>/ Would bring: doc.mediawiki.org/core/php/master doc.mediawiki.org/core/js/master doc.mediawiki.org/core/php/1.20.2 doc.mediawiki.org/core/js/REL1_20 doc.mediawiki.org/AbuseFilter/php/REL1_20 Other thoughts? I would prefer having the MediaWiki doc hosted on the mediawiki.org domain. As for the ordering I guess we can bikeshed for a long time but most probably some ordering will seem natural for most people there :-] Thanks! -- Antoine "hashar" Musso

5 4

deployment of the first phase of Wikidata on enwp
by Lydia Pintscher 13 Feb '13

13 Feb '13

Hey :) Guillaume just reminded me that I have not yet posted this here but only on the village pump and Signpost. Sorry. I'll fix that now with this email. Later today (evening UTC) we'll deploy the first phase of Wikidata on the English language Wikipedia. We've already deployed the first phase on the Hungarian, Hebrew and Italian Wikipedias and things there went rather smoothly. We hope this is the case here too. What is going to happen exactly? * Language links in the sidebar will come from Wikidata if they exist there. * Existing language links in the wiki text will continue to work and overwrite links from Wikidata. * For individual articles language links from Wikidata can be supressed completely with the noexternallanglinks magic word. * Changes on Wikidata that relate to articles on this Wikipedia will show up in Recent Changes if the option is enabled by the user * At the bottom of the language links list you will see a link to edit the language links that leads you to the corresponding page on Wikidata. * You can see an example of how it works at http://it.wikipedia.org/wiki/Marie_Curie * The second phase of Wikidata (which is about Infoboxes was started on Wikidata but can't yet be used on any Wikipedia. This will follow later. Please let me know if you have any questions. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

4 7

What's our Bus Factor?
by Jay Ashworth 13 Feb '13

13 Feb '13

It's the new year, and in light of the recent poll about which devs are working on what, let me make another, albeit vaguely macabre, suggestion: If you're a developer, or other staffer, can the people around you pick up the pieces if you get hit by a bus? How badly will it impact delivery and delivery scheduling of what you're working on? Is the institutional knowledge about our architecture and plans sufficiently well documented and spread out that we don't have anyone with an unreasonably high bus factor? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

3 2

Same wikicode - different outcomes
by Tuszynski, Jaroslaw W. 13 Feb '13

13 Feb '13

Last week I run into several instances of templates on Commons not working in the predictable way. Some of them do not work properly and issues can be fixed by changing order of arguments in the template. For example http://commons.wikimedia.org/wiki/Creator:Auguste_Angellier does not show the content of the "name" field and template is in Category:LangSwitch_template_without_English_version <http://commons.wikimedia.org/wiki/Category:LangSwitch_template_without_ English_version> , which is added automatically to incorrect uses of Template:LangSwitch. I copied the exact copy of Creator:Auguste_Angellier wikicode to http://commons.wikimedia.org/wiki/Creator:Just_a_test, and this template works as it supposed to do. The problem is not unique, another template was "fixed" by http://commons.wikimedia.org/w/index.php?title=Creator:Paul_Acker&diff=p rev&oldid=90023607 edit which mostly changed order of the arguments. There are more of those like http://commons.wikimedia.org/wiki/Creator:Derick_Baegert. When unexplainable things happen with templates on Commons it is often a problem with expansion limit, however this time that is not an issue. Any ideas what might be causing same wikicode to work differently at different places? Jarek T. User:Jarekt

3 2

Belated welcome to Christian Aistleitner
by Rob Lanphier 12 Feb '13

12 Feb '13

Hi everyone, I'd like to give an extremely belated welcome to Christian Aistleitner. Christian is working as a contractor for Wikimedia Foundation specializing in Gerrit work, who started working with us in mid-January. Christian was very helpful in getting the Gerrit 2.6pre upgrade to happen, and is working on the backlog of features that we'd like for Gerrit (e.g. project renames, project deletions, better Bugzilla integration). He'll be working with us through the end of April. Welcome Christian! Rob

2 1

Gerrit 2.6 - coming to a server near you
by Chad 12 Feb '13

12 Feb '13

Hi, After much delay, Gerrit 2.6 will be coming to our servers. This release brings a *lot* of really cool features and fixes, but I'd like to outline a couple of the major ones: * A stable, documented RESTful api * Plugin support: ** We'll be replacing Gitweb with Gitblit once the initial dust of the upgrade settles ** We've got a plugin to let us delete projects ** We're working on plugins for renaming projects, as well as providing some Bugzilla integration * IE9 & IE10 are now supported * The code formatter got some updates, which should solve some of the ArrayIndexOutOfBounds errors you saw in some diffs. * Ability to leave comments on a whole file (instead of just a line in a file) * Search suggestions * More unicorns! We're planning to do this on 1:00-2:00UTC on February 12th (that's 17:00-18:00 PST on February 11th) -- that's one week from today. -Chad

9 19

Announcement: Ed Sanders joins Wikimedia as Visual Editor Software Engineer
by Terry Chay 12 Feb '13

12 Feb '13

Everyone, I'm delighted to announce that Ed Sanders has joined the VisualEditor[0] team as a software engineer from today. He will be focussed on the data structures and APIs inside the VisualEditor, and in particular its "data model" component. Ed will be working remotely from the UK. Ed has worked as a Web front-end software engineer for several years, most recently working for TripAdvisor. He received his MA in Computer Science from Clare College at the University of Cambridge. Ed is a long-term contributor to Commons and the English Wikipedia, where he has been a sysop since 2004.[1] In his spare time, Ed enjoys photography, watching his local football team (real football, not handegg), Arsenal,[2] and sometimes doing both at the same time. He'll be in the SF office for the next few weeks so be sure to stop by and say hi! Please join me in welcoming Ed! terry [0] - https://www.mediawiki.org/wiki/VisualEditor [1] - https://commons.wikimedia.org/wiki/User:Ed_g2s [2] - https://en.wikipedia.org/wiki/Arsenal terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tchay(a)wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay

5 5

Bugzilla use by development teams
by Andre Klapper 12 Feb '13

12 Feb '13

Hi, recently I've collected info on the usage of Bugzilla by Wikimedia's development teams, listing each team's * Bugzilla components (projects), * bug tracking and development planning tools, * criticism and wishes about Bugzilla specifically, * use of Bugzilla's "Priority" field. There are still many blank fields and it's work in progress. I'm sharing it here as it might be useful for others, plus you are of course welcome to correct or add any data: https://www.mediawiki.org/wiki/Bug_management/Development_teams_usage andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Fwd: [Gerrit] API PageSet allows generator for non-query modules - change (mediawiki/core[master])
by Tyler Romeo 12 Feb '13

12 Feb '13

Currently our coding conventions have major prohibitions on the use of isset() and empty(). I can understand isset(), because sometimes it makes more sense logically to have boolean casting or strict type checking, but in the case of empty(), it's significantly faster than boolean casting and is more readable. If you're checking for *whether an array is empty*, which is more intuitive: if( !$array ) // If the boolean value of the array is false if( empty( $array ) ) // If the array is empty Functionally, they're almost equivalent, as any value that evaluates as false will also be treated as empty. The sole difference is 1) empty() first checks if the variable is set and 2) empty() is faster. I understand that there is a slight risk here due to empty()'s error suppression, but in many cases it's obvious that a variable exists and it's not necessary to sacrifice the logical readability of the code just because a developer might make a typo and not realize it even though the same variable is on the line above. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com ---------- Forwarded message ---------- From: Brad Jorsch <bjorsch(a)wikimedia.org> Date: Tue, Feb 5, 2013 at 5:43 PM Subject: Re: [Gerrit] API PageSet allows generator for non-query modules - change (mediawiki/core[master]) To: tylerromeo(a)gmail.com On Tue, Feb 5, 2013 at 5:03 PM, Parent5446 (Code Review) <gerrit(a)wikimedia.org> wrote: > Yeah, I see the page, but it doesn't tell me anything interesting. The only disadvantage of using empty() is for the off chance that you mispell a variable name and the error is hidden, but it's obviously not the case here. And in terms of readability, it makes a lot more sense to have if( empty()) Then perhaps you should raise the question of changing the coding standards on https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP Until then, let's not use empty() unless we explicitly want the "isset" check.

5 8

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2013