Wikitech-l March 2008

wikitech-l@lists.wikimedia.org

97 participants
92 discussions

Interface language defaults
by Steve Bennett 20 Mar '08

20 Mar '08

This has probably been discussed before, but why does mediawiki (or at least, wikipedia) default to showing the interface in the language of the wikipedia, rather than in the language of the browser? E.g., when I visit ru.wikipedia.org, common sense dictates that the interface should be shown in English, the language defined in my browser preferences. Sure, I can change it by creating an account and defining my preferences, but even that is difficult enough on a foreign language Wikipedia, and extremely difficult for a non-Roman script. What's the thinking here? Steve

9 11

Devoting edits to WikiProjects
by Lars Aronsson 20 Mar '08

20 Mar '08

I've been trying to compile an overview of what the various WikiProjects on the Swedish and Norwegian Wikipedias (sv,no,nn) have accomplished. The reason is that some of the best work is done within WikiProjects, and I want to find success factors and bring inspiration for other projects to improve. Most projects have a list of participants and some way to indicate which articles they try to cover. However, the people who do actual work within a project are not necessearily the same who have listed themselves as participants. And an edit in an article isn't necessarily "part of" the project. For example, if I edit [[Napoleon]] to describe a disease he had, that edit is possibly part of WikiProject Medicine, but not part of WikiProject War. To better assess the amount of activity within each project, it would really help if each edit could be tagged as belonging to a WikiProject. This is how I think it could work: In order not to make things complicated for beginners, the default behaviour will be just as it is today. But in the personal settings, I should be able to specify a list of tags for tasks, projects or teams that I'm involved in. The elements of this list would then appear as a <select><option> drop-down in the edit page. If a tag is selected, it is saved in the revision history and can perhaps be seen in RecentChanges and article history. Recent Changes and user contributions could use these tags as selectors, so you could get a recent changes per WikiProject. This is just a suggestion. I'm not about to implement this. If you think this is a good idea, feel free to use it. What I propose is just a single, free form plain text tag to be associated with each edit. I don't suggest that the system must verify that such a WikiProject exists. The scheme is not limited to WikiProjects. But there is where I see its first use. Here are two examples of team statistics on other websites, that might serve as further inspiration: On PGDP.net (Project Gutenberg's Distributed Proofreaders) volunteers proofread pages from scanned books. It's also a competition to get a high page count. But members can join teams and teams compete on the sum of their members' page counts. On LibraryThing.com, members are able to catalog their personal libraries and bookshelves. They can also join discussion groups, and each group has a list of which members have the most books. A sum of counts is also presented for each group. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

1 0

Request for Comment: Extension manager\repository
by MinuteElectron 20 Mar '08

20 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Recently I volunteered to help establish a system for providing an extension manager\repository combination for MediaWiki. During this time I have devoted some thought regarding how such a system would work, here I hope to summarize what ideas have been bounced around so far and stimulate further discussion that can be built upon. To begin with, most of my effort went into designing and building a repository, doing this first was a bad idea, however; a manager that can be used without a repository is needed first before the specification for a repository can be made. Regardless thought has already been put into this (mostly in IRC discussions on #mediawiki) so it would be worthwhile listing ideas them here. - It is *extremely* dangerous to create a system that automatically downloads files that will be executed from the Internet and installed into an environment such as MediaWiki, if the repository that is being used is compromised via DNS spoofing or similar attacks, arbitrary access to the file system the client MediaWiki is running on and any data held in the wiki could be made available (without anyone knowing, if the malicious attack was crafted carefully). - For this reason signing should be used to facilitate transferring files between the repository and MediaWiki in a way similar to aptitude (Linux package manager). Perhaps done using SSL or some other system (maybe using public\private keys). - It should be possible for multiple repositories to be hosted, even if an official one were to exist some projects might like to have one so that their wikis can access custom extension and many other reasons. Once I develop my repository system I plan to release it under an open source license in a generalized way so it could be used by third parties as well as on a pseudo-official one probably hosted on the toolserver (maybe even the stable server after a while). - Due to the high demand such a system would receive static generated information would be desirable as opposed to a dynamic API. - Support for different versions of MediaWiki would be essential, presumably from the version of MediaWiki available when the extension manager is released onwards (therefore future backwards compatibility would be essential). That's all I could think of for the repository, please add more in a reply if you can think of anything. Moving on to the client (extension manager) many more factors would have to be covered. - One of the earliest problems I encountered was providing a system for updating configuration, it would be very difficult to maintain variables in a file so moving to configuration in the database is probably the only choice here (possibly both a database based and file based choices, but this could become hard to maintain). Validation on input would be required and so more coding would need to be made by extension authors (or the repository managers, if the maintainer of the extension wasn't willing to put effort into validation functions), this could probably be done using a configuration class for each extension extend from a main configuration class. This would most likely fit best into a separate configuration file so it could be loaded without the rest of the extension. And I've gone and put all my points about an extension manager client into one bullet, discussion about this would be great; at least now I've written it out I understand better what it is I was planning so hopefully (providing someone doesn't find any flaws in my ideas) I might be able to start some coding. For now this will most likely have to stay as an extension as it will be too unstable to begin with, but hopefully once the project takes off it could be bundled in core along with a few common extension (which would then be able to be installed without configuration file editing due to this interface). Perhaps even, in the long run, the bulk of configuration could be moved into a configuration manager special page and validation classes -- this would certainly help many users. If anyone else would like to contribute to an extension manager (I've noticed a couple of other people interested on IRC) maybe we could set up an IRC channel and collaborate on it -- work out some UI mock-ups, design basic code, discuss ideas in greater detail etc. -- if not I'll work out some basic code that can then be expanded on or twisted as required by anyone who wants to help. Thanks, MinuteElectron. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfdlGoACgkQkJvUlhoE3wSEWQCgt4NQuEJuNIVKJUKo4Z9itOEk cAYAn2WMTMrfz7dtwUgI9PjFrLs6qk+P =QsBY -----END PGP SIGNATURE-----

4 5

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32214] trunk/phase3
by Simetrical 20 Mar '08

20 Mar '08

On Thu, Mar 20, 2008 at 5:20 AM, <vasilievvv(a)svn.wikimedia.org> wrote: > * cat_hidden doesn't work. why? Because it was added for future use. I've noted this in tables.sql.

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32218] trunk/phase3/includes/ChangesList.php
by Simetrical 20 Mar '08

20 Mar '08

On Thu, Mar 20, 2008 at 7:20 AM, <raymond(a)svn.wikimedia.org> wrote: > - $r = '<table cellpadding="0" cellspacing="0" border="0"><tr>'; > + $r = '<table class="mw-cl-cbg" cellpadding="0" cellspacing="0" border="0"><tr>'; As a general rule, cryptic abbreviations like "mw-cl-cbg" are probably not the best choices for this kind of thing. We're not going to run out of letters if you use 15- or 20-character class names. Something like "mw-changes-block" would probably be better, and something like "mw-changes-item" for "mw-cl-rci".

1 0

Outage info
by Brion Vibber 18 Mar '08

18 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We had some sort of network outage starting a bit after midnight UTC; heavy packet loss (33%-39% range) was visible on a number of networks, and the Tampa servers became difficult to reach for a time. Additionally, there was some DST packet overload on our primary load balancer, making the wikis inaccessible through it. Packet loss was largely reduced by about 01:05 UTC; some poking at the load balancer apparently reset things to where it was happy with the network again by around 01:18 UTC. Sites are accessible and seem reasonably happy at this time. - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkffGwsACgkQwRnhpk1wk47FGQCg0zfrzTU4A8UTq3dKMhu+NDN2 0c8An01aTNr+oWq+M4/m66PVRTC+YJmc =DaL1 -----END PGP SIGNATURE-----

5 9

<noinclude>{{:Page}}</noinclude> Proposal
by drew einhorn 18 Mar '08

18 Mar '08

I'd like to see this generate the TOC for {{:Page}}, but not include the content. Links in the TOC should go to the original location in Page. This would enable me to drastically reduce the giant wiki page at http://wiki.laptop.org/go/VistA_Monograph_Wiki to a more reasonable size. Something along like: http://wiki.laptop.org/go/WV_VM -- Drew Einhorn

8 12

MetaVidWiki Open Beta
by Michael Dale 17 Mar '08

17 Mar '08

Just wanted to mention that MetaVidWiki is now in Open Beta: http://metavid.ucsc.edu/blog/2008/03/13/metavidwiki-open-beta/ feedback, participation, and ideas for future are welcome :) peace, michael

1 0

SUL pilot
by Tim Starling 17 Mar '08

17 Mar '08

Brion and I are planning a pilot of the CentralAuth (account merging and unification) extension on Wikimedia wikis. The general idea is to enable it for admins only for the duration of this pilot. Admins make good beta testers for this extension because: * They're responsible enough to report bugs instead of ignoring them * They're more likely to use their first hand experience to write documentation or otherwise pass on their knowledge to others * Allowing admins first choice of username reduces the potential for name-squatting by trolls Access to global usernames is generally on a first-come, first-served basis. We can deal with imposters when we have to, but it's going to be a pain so it's best if we can keep the number of incidents a minimum. Also, we hope that limiting it to admins will make the volume of support requests more manageable. I don't think we'll need to schedule an exact time, or set a site notice or anything like that. When we accidentally enabled it for a brief period last week, hundreds of people knew about it within half an hour. It appears on the first page of your preferences when it's enabled, and word spreads fast. For general information about CentralAuth, please read the documentation at: http://meta.wikimedia.org/wiki/Help:Unified_login -- Tim Starling

2 1

Re: [Wikitech-l] How to globally set global variable via specialpage
by 65s.mg＠atlas.cz 17 Mar '08

17 Mar '08

Hello. I tried many hooks, but I cannot find any, with which I can use for overwriting variale, that is defined in the LocalSettings.php. Any suggestions? Thanks. -MGrabovsky

8 12

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 March 2008