Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
148 discussions

Re: [Wikitech-l] those Jimbo pics are scaring me
by jidanni＠jidanni.org 18 Nov '11

18 Nov '11

Why can't they sign somebody who doesn't scare children, like http://en.wikipedia.org/wiki/Pee-wee_Herman . Why does the best person for the campaign have to be the most logical person? Haven't they got any advertising sense? I bet Pee-wee would love to help. Why don't they give him a call?

2 1

1.18RC verification -- does it work for you?
by mhershberger＠wikimedia.org 18 Nov '11

18 Nov '11

Now that Sam has announced the 1.18 Release Candidate, we'd like to make sure that we've created a tarball that will work. Please give 1.18RC1 a try and add your experience to <http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.18/Upgrade_reports>. I just upgraded one of the wikis I maintain from 1.15 and recorded my experience. Of course, as Sam writes in his announcement, you should probably not do this on a production wiki "unless you are both very brave and very confident in your MediaWiki administration skills." So, maybe you'll want to try it in a test installation. That said, let us know of your successes! Of course, we'd like to know about failures, too, and that page is an appropriate place to report them (in addition to bugzilla), but we really need to know if this release is as good as we think it is. Thanks, Mark.

1 0

MediaWiki Release Candidate 1.18.0rc 1
by Sam Reed 18 Nov '11

18 Nov '11

I'm happy to announce the availability of the first release candidate of the new MediaWiki 1.18 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.18 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES file for the full list of changes in this version. ********************************************************************* What's new? ********************************************************************* MediaWiki 1.18 brings the usual host of various bugfixes and new features. jQuery 1.6.4 is now included as standard, along with numerous more jQuery plugins. Breaking changes: * action=watch / action=unwatch now requires a token As of 1.18, some extensions are now being bundled with the released tarball. The following extensions are bundled with MediaWiki as of 1.18. All are currently in use on Wikimedia sites. * ConfirmEdit - Various CAPTCHA techniques to try to prevent spambots and other automated tools from editing your wiki. * Gadgets - A system to allow users to enable or disable JavaScript or CSS tools made available to users site-wide. * Nuke - A special page allowing administrators to mass-delete content added by a spammer or vandal. * ParserFunctions - Additional parser functions (like #if and #switch to supplement the "magic words" present in MediaWiki. * Renameuser - A special page which allows authorized users to rename user accounts. * Vector - Enhancements to the Vector skin. * WikiEditor - An improved and customizable editing toolbar developed along the Vector skin. Major features - -------------- Better gender support -- --------------------- Until version 1.17, MediaWiki used neutral nouns to address and identify users on their user page. In English, this was not an issue since "User" matches both genders, but in some languages the neutral gender is always masculine; for example, this would cause French-speaking female Wikipedia users to be referred to as "Utilisateur" (male user) instead of "Utilisatrice" (female user). With version 1.18, user pages reflect the user's gender, if they have specified it in their preferences. More gender support (for instance in logs and user lists) will be available in MediaWiki 1.19. Improved file metadata support -- ----------------------------- MediaWiki now detects the camera orientation from Exif metadata, and rotates the picture preview accordingly. The original file remains unchanged. The overall metadata support in MediaWiki has been greatly extended. Previously, MediaWiki could only extract limited Exif metadata, and showed a subset of it on file description pages. Since 1.18, MediaWiki can extract IPTC and XMP metadata from uploaded files, and more Exif information. This includes an embedded description, author information, GPS coordinates, or copyright statement. Improved directionality support -- ------------------------------- A lot of work has been done to fix directionality bugs (Left-To-Right, Right-To-Left). Most notably bug 6100 is fixed, which allows to display an RTL interface on an LTR wiki properly (and vice versa). This was developed under $wgBetterDirectionality, which is now no longer used because the improvements are merged with the core code. A positive consequence is that the page content on wikis with multiple scripts is aligned according to the direction of the selected variant. For example, on a Kazakh language wiki, selecting the Arabic script variant will align the text as RTL, while selecting the Latin or Cyrillic variant will align it as LTR. Easily find where to customize interface messages -- --------------------------------------------- MediaWiki allows you to customize the user interface by editing pages in the MediaWiki namespace. However, even though they can be viewed at Special:AllMessages] the sheer number of these messages makes it difficult to find which one needs to be customized. In MediaWiki 1.18, a new pseudo-language is introduced (qqx) to help people find such messages, by displaying the messages' key instead of the actual messages. All one has to do is append ?uselang=qqx to the page's index.php/ URL (see https://www.mediawiki.org/w/index.php?title=MediaWiki_1.18&uselang=qqx as an example). New plugin for collapsible elements -- ----------------------------------- The new jQuery.makeCollapsible allows you to create collapsible tables, lists and so on, by adding the class mw-collapsible to the elements. See the manual for details: https://www.mediawiki.org/wiki/Manual:Collapsible_elements Protocol-relative URLs -- ---------------------- MediaWiki now supports protocol- relative URLs in links, interwiki targets and $wgServer. Protocol-relative URLs look like //example.com/wiki/Foo ; the browser will recognize this as http://example.com/wiki/Foo when following a link from an HTTP page, and https://example.com/wiki/Foo when following a link from an HTTPS page. This way, protocol-relative URLs enable a wiki to support HTTP and HTTPS while serving the same HTML for both, which means the parser cache doesn't have to be split. More personalisable styles and scripts -- -------------------------------------- MediaWiki now automatically loads javascript and stylesheets more specific to each user. There is a separate CSS and JS file for each usergroup (MediaWiki:Group-sysop.css, MediaWiki:Group-autoconfirmed.js, etc), and also a CSS file for users viewing without JavaScript (MediaWiki:Noscript.css). Other changes -- ------------- $wgEnableDublinCoreRdf and $wgEnableCreativeCommonsRdf no longer work in core, and the functionality has been moved to the relevant extensions. See http://www.mediawiki.org/wiki/Extension:DublinCoreRdf and http://www.mediawiki.org/wiki/Extension:CreativeCoreRdf as appropriate Math - ---- $wgUseTeX has been superseded by the Math extension. To re-enable math conversion after upgrading, obtain the Math extension from SVN or from http://www.mediawiki.org/wiki/Extension:Math and add to LocalSettings.php: require_once "$IP/extensions/Math/Math.php"; Language support - ---------------- As with every release, MediaWiki 1.18 brings improved support for languages in MediaWiki, with improved translation and features for the many supported languages. New languages: * Angika (anp) * Brahui (brh) * Central Dusun (dtp) * Jamaican Creole English (jam) * Khowar (khw) * Liv (liv) * Kichwa (qug) API - --- API bug fixes and new features have been added to 1.18, providing more options for input and output. * API modules were added to access QueryPage based special pages, to Compare pages, Revert files, and to be able to access other special pages such as Special:UnwatchedPages, Special:MimeSearch and Special:ActiveUsers * The output of the generated help page has been improved The API contains a breaking changes against previous releases: * action=watch now requires POST and token. Other - ----- Our thanks go to everyone who helped to improve MediaWiki by testing the beta release and submitting bug reports and patches. Release notes - ------------- Complete release notes are at http://www.mediawiki.org/wiki/Release_notes/1.18 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.tar.gz Patch to previous version (1.18.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0rc1.patch. gz GPG signatures: http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0rc1.patch.gz.si g http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0rc1.patch. gz.sig Public keys: https://secure.wikimedia.org/keys.html

1 0

Re: [Wikitech-l] Validator extension.
by Jeroen De Dauw 18 Nov '11

18 Nov '11

Hey, (Full replied to message can be found here: http://pastebin.com/J0aLk2t9) > Please respond to appropriate mail list -- either WikiTech-L Might be interesting to people here :) > But I found terminology used in Validator frustrating and misleading. Well yeah, I agree, the names parameter and argument are used pretty loosely through the extension. > However, it will break compatibility with existing Validator… What do you think? It is possible? How manage compatibility? Create incompatible Validator2? In general I agree with your remarks, but it's not really possible to just change this on the fly, as it would break a lot of compatibility. I suggest creating a new alternate system while keeping the old one, so things can gradually be migrated, and then have the old thing go when it's no longer used. In particular, I'd like to split the param definition from the parameter (with value) handling functionality. Since the Parameter class is used all over the place to define parameters, changing this one would be hard. I also thing it's not that bad of a name, and clearer then Descriptor. So maybe it's better to find an alternate name for the "parameter with value" class, which is only used in Validator itself anyway. And I'd like to have a more lightwight way of defining parameters, rather then creating a Parameter object for each. In most cases an associative array suffices, which can then be turned into an object later on. And I think the current way parameter criteria and manipulations are defined sort of sucks. You need a class for each, while often you want to do very simple stuff. Passing in a function should also work. In PHP 5.3+, anon functions would make a lot of sense here. If a separate parameter definition class is cerated, it might actually make a lot of sense to have doValidation and doManipulation methods in there. This does not allow to share criteria and manipulation objects like the current system, but is probably less of a hassle and less over engineered. Also, I'd like to get rid of the evil LSB hack in the ParserHook class, but guess it's still to early to do that (since you'd need PHP 5.3+). Any such changes would contribute to a new mayor release, version 0.5. The last big changes, those for 0.4, where made over a year ago, and although I see a bunch of stuff that could be made better architecture wise, the current system works. So I'm not that keen on making these changes now and deal with all the compatibility issues. (Maybe after SMW 1.7 has been released.) But if you feel like poking at it or writing up a proposal for a new architecture, please do, I'll happily provide feedback. > BTW, in many languages positional arguments are allowed before the first named argument. Validator allows: > {{ #func: pos1… | namedA=… | pos2… | namedB=… }} Yeah, it does allow this. Originally it did not, but I figured some users might not understand or think about the difference, so I just added this because it works. I don't see what your issue with this is. I don't know how this is called, but don't see how that matters :) > I am sure Validator is a great idea and really helps. I used it in few my extensions. I also wrote parser function `#validate' to validate template arguments and use it in almost all my templates! Well, please share your code - sounds like this could be useful to other people as well ;) Although the current architecture might need some tweaking to become really nice, I think having a declarative system for parameters is very powerful as it allows for a whole range of cool things, which is why I created the extension in the first place. Since then I've only become more convinced of this, and would really like to see such functionality get put into core at some point, in one form or another. Any comments on this are appreciated. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

1 0

Coding Convention: Method chaining
by John Du Hart 16 Nov '11

16 Nov '11

Right now our coding conventions manual never touches on method chaining, nor have I personally seen this practice in core. So I'm interested in what the rest of the community feels about adapting this practice more, and if there are trade offs I'm not aware of. Let's make an example, take this code from Abuse Filter: $out = $this->getOutput(); $out->setPageTitle( wfMsg( 'abusefilter-examine' ) ); $out->addWikiMsg( 'abusefilter-examine-intro' ); So, instead of writing it like that, it could be written $this->getOutput() ->setPageTitle( wfMsg( 'abusefilter-examine' ) ) ->addWikiMsg( 'abusefilter-examine-intro' ); It's just another style I've encountered on other projects and I personally like. -- John Du Hart

12 13

HTTPS-Everywhere
by Raimond Spekking 16 Nov '11

16 Nov '11

Hi, it seems, that the latest stable version of HTTPS-Everywhere 1.2.1 fully supports the new HTTPS structure of Wikimedia wikis \o/ Raimond.

3 3

Fwd: Old English Wikipedia image dump from 2005
by emijrp 16 Nov '11

16 Nov '11

Forwarding... ---------- Forwarded message ---------- From: emijrp <emijrp(a)gmail.com> Date: 2011/11/11 Subject: Old English Wikipedia image dump from 2005 To: wikiteam-discuss(a)googlegroups.com Hi all; I want to share with you this Archive Team link[1]. It is an old English Wikipedia image dump from 2005. One of the last ones, probably, before Wikimedia Foundation stopped publishing image dumps. Enjoy. Regards, emijrp [1] http://www.archive.org/details/wikimedia-image-dump-2005-11

2 1

page view stats redux
by Ariel T. Glenn 16 Nov '11

16 Nov '11

I think we finally have a complete copy from December 2007 through August 2011 of the pageview stats scrounged from various sources, now available on our dumps server. See http://dumps.wikimedia.org/other/pagecounts-raw/ Ariel

9 16

Making developer access easier to get
by Yaron Koren 16 Nov '11

16 Nov '11

Hi, I think developer accounts on the Wikimedia SVN repository should be easier to get. I say this because a consultant of ours at WikiWorks, Ike Hecht, asked for a developer account last week and was rejected. He created his first major MediaWiki extension, Ad Manager, recently, which I added to the repository a few weeks ago - you can see it here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/AdManager/ When he requested access, this was the relevant part of the response from Sumana: "Right now, we are not approving your request for commit access. I'm sorry. We'd like for you to get more practice writing code for MediaWiki, submit patches for review via Bugzilla attachments, and ask us for comments... Please come back and request access again in a few months." I don't know whether this is WMF policy now, or a personal decision from Sumana, or a decision made by someone else, but in any case I don't understand it. It seems to me that there are two valid reasons for not simply allowing everyone to get a developer account: the first, and major, reason is to prevent malicious users from vandalizing or deleting code. The second is to prevent well-intentioned but incompetent developers from checking in buggy and/or badly-written code that requires lots of fixes and review time by the reviewers. In both cases, the person's presence in SVN would cause more harm than good. Neither of those cases apply here - the Ad Manager code was well-written, and it works. If you're curious, you can see for yourself the kinds of fixes and changes that were made to the code after it was checked in - all minor stuff, the only major thing being that the extension originally included support for MediaWiki 1.15, which people thought was unnecessary. Clearly a higher bar is being applied here than what's spelled out in the mediawiki.org documentation - which only says that "we don't have time to train programmers from scratch": http://www.mediawiki.org/wiki/Commit_access#Prerequisites Note, by the way, that if there's a more stringent policy in place now, it's not being applied consistently, because the students in this year's Google Summer of Code got developer access after much less proof of programming ability. It seems to me that if someone writes an extension that basically matches the MediaWiki guidelines, works, and does something useful, they should pretty much be granted automatic access to an account, because they will have proved that their presence will be a net positive overall. Any thoughts on this? And out of curiosity - is there a new policy in place? -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com

12 26

New committer
by Sumana Harihareswara 16 Nov '11

16 Nov '11

Just granted extensions access to Remco de Boer as remco (User:Rcdeboer on mediawiki.org) to work on various extensions, especially those in the semantic bundle. Welcome! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2025

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 November 2011