Wikitech-l April 2010

wikitech-l@lists.wikimedia.org

64 participants
46 discussions

Request for comments: New Message class
by Niklas Laxström 04 Apr '10

04 Apr '10

^demon, Happy-melon, ialex, ashley and I have been preparing a new class. It is intended to be replacement for the old wfMsg* functions that many seem to dislike. The most important reasons why we want to replace them are below. There is some more at [1]. * There is too many functions with too many parameters * It is easy to do the wrong thing * It is difficult to do the right thing The new class is in my opinion now ready enough for comments and criticism. The full source code is at [2] and formatted documentation at [3]. It should be possible form the documentation to see how it is meant to be used. Few examples are below. More examples and how they compare to old wfMsg* functions can be found at [2]. # $button = Xml::submitButton( Message::key( 'submit' )->text() ); # Message::key( 'welcome-to' )->params( $wgSitename )->parse(); # Message::key( 'bad-message' )->rawParams( '<script>...</script>' )->escaped(); # Message::key( 'file-log' )->params( $user, $filename )->inContentLanguage()->text(); It should be noted that it is not our intention to replace OutputPage::addWikiMsg() and ::wrapWikiMsg(). Things I'd like to have comments for: (1) Is it easy to use this class? Have we solved the three main issues given above? (2) The primary entry point is Message::key(). The syntax is little more verbose than wfMsg*'s, but much more readable imho. Do we want to use even short wrapper for the entry point? If yes, how should it be called? For example _() (often used in Gettext projects) and Msg::key() have been suggested. (3) Anything else with regards to the documentation, the code or other issues. In the current state the class should be able to cover almost all use cases wfMsg-functions had, with some exceptions. I'd like to have some tests for this class, can somebody help with that? Obviously this quite a small change itself, but it will have a big impact when we start converting code to use these new methods. For that reason I want to get it right. I think we should proceed slowly during 1.17 cycle, for example using these only in new code and iron out all problems. Like ^demon pointed out at bug 16026 [4], we should perhaps review HTML-safety of any message we convert to use these new methods. [1] http://www.mediawiki.org/wiki/New_messages_api [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Message.php [3] http://svn.wikimedia.org/doc/classMessage.html [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=16026#c8 -- Niklas Laxström

14 34

Uploads on small wikis
by Erik Moeller 04 Apr '10

04 Apr '10

Hello all, together with Frank Schulenburg and Naoko Komura, I just participated in a video-conference with the winners of the Google Kiswahili Wikipedia challenge ( http://www.google.com/events/kiswahili-wiki/ ), and we talked about some of the challenges they encountered when contributing to the Swahili Wikipedia. One of the issues was that it was very hard for them to upload files. Specifically, when you're a new user on a small wiki like sw.wp, you _cannot upload_ locally due to a restriction of uploads to autoconfirmed users. The upload link isn't even visible in the sidebar until you're autoconfirmed, and you get a confusing error message if you happen to call up Special:Upload. >From a user experience standpoint, this is horrible. For the immediate future, I suggest lifting this restriction for wikis between 1,000 and 50,000 articles in size (large enough to have a few active users, small enough to not yet have lots of policy around these issues). Ultimately we'll want to integrate Commons better into the user experience, but until then, IMO we should eliminate artificial impediments like this which prevent people from growing their communities and frustrate them -- unless there's a proven issue of large scale abuse. Does that make sense? Thanks, Erik -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

21 46

Mediawiki extensions and Windows 2003 server
by Makelesi Kora-Gonelevu 03 Apr '10

03 Apr '10

Hi I've tried installing a number of extensions on a Windows 2003 server but they dont seem to work. Although i've successfully installed it onto Linux. I think this has to do with the Read-only attribute thats inbuilt into the Windows 2003 server. Anyone out there ever come across this problem? If yes how did you work your way around it? Looking forward to any responses. Thanks.

2 1

RTL problems with Vector skin on Commons
by Amir E. Aharoni 03 Apr '10

03 Apr '10

Hello, Vector skin specialists, There are serious RTL (right-to-left) problems with the Vector skin on Commons. Please see: * http://commons.wikimedia.org/wiki/Commons:Village_pump#Directionality_of_He… * http://commons.wikimedia.org/wiki/User_talk:Slomox#RTL_css * http://commons.wikimedia.org/wiki/MediaWiki:Rtl.css * http://commons.wikimedia.org/wiki/MediaWiki:Rtl.js Thanks in advance for any assistance. -- אָמִיר אֱלִישָׁע אַהֲרוֹנִי Amir Elisha Aharoni http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore

6 8

Extensionless files (bug 4421)
by Rob Lanphier 02 Apr '10

02 Apr '10

Hi everyone, Yesterday on IRC, I suggested that I should start checking in the safer portions of the extensionless-files branch, so as to make the eventual merge of the feature easier. Tim suggested that I put together a design doc and post that here for wider review first. Here's the design doc: http://www.mediawiki.org/wiki/Requests_for_comment/Extensionless_files The branch with the code in it is here: http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/path&path… Ongoing discussion on this topic is in Bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 Rob

3 3

New committers
by Tim Starling 01 Apr '10

01 Apr '10

Extension/branch access: * Lucas Garczewski (tor): Wikia-related extensions such as EditSimilar * Tisane: RPED extension, possible core branch * Svemir Brkic (svemir): SphinxSearch extension * Svippong (svip): NaturalLanguageList * Meadowlark Bradsher (mbrad): Quiz extension * Fabian Howahl (fabianh): SemanticMediaWiki, SemanticResultFormats Core access: * Ryan Bies (yaauie): hiphop branch, MSSQL support Access upgraded from extensions to core: * Bawolff -- Tim Starling

1 0

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 April 2010