Wikitech-l March 2008

wikitech-l@lists.wikimedia.org

97 participants
92 discussions

Re: [Wikitech-l] [Foundation-l] Wikimedia Projects Growth Animated
by Domas Mituzas 27 Mar '08

27 Mar '08

Hi! this may sound as a heresy, but for some jobs, that are short in time- span, but need lots of CPU capacity we could try using Amazon's EC2 or any other grid computing service (maybe some university wants to donate cluster time?). That would be much cheaper than allocating high-performance-high- bucks hardware to projects like this. Really, we have a capable cluster that has extra-CPU capacity for distributed tasks, but anything what needs lots-of-memory in single location simply doesn't scale. Most of our tasks are scaled out, where lots of smaller machines can do lots of big work, so this wikistats job is the only one which cannot be distributed this way. Eventually we may run Hadoop,Gearman or similar framework for statistics job distribution, but really, first of all the actual tasks have to be minimized to smaller segments, for map/reduce operation, if needed. I don't see many problems (except setting the whole grid up) allocating job execution resources during off peak, on 10, 20 or 100 nodes, as long as it doesn't have exceptional resource needs on a single node. It would be very nice practice for many other future jobs too. BR, -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]

2 1

GSoC proposal - visual diff
by Guy Van den Broeck 26 Mar '08

26 Mar '08

Hi, I want to get some feedback on a possible Summer of Code project proposal. For last year's GSoC I created an HTML diffing library for Daisy CMS. The algorithm has proven to work well and I'm thinking of porting it to mediawiki. What the algorithm does is take the source of 2 pages and merge them to visualize the diff. The code I have already does something like this: http://users.pandora.be/guyvdb/wikipediadiff.jpg Is this a feasible project for wikimedia? I'm personally not very impressed with the current "diff pages". I think a visual diff would bring that part of mediawiki up to par with the rest of the software. Thanks Guy

10 18

hate catching up with sidebar translations
by jidanni＠jidanni.org 26 Mar '08

26 Mar '08

For each new MediaWiki version, there is casual shifting back and forth of what the translations of the names for the pages like the community portal page, the disclaimers page, the current events page, etc. are. Each upgrade we have to repair our wikis to connect the previous page name back up to its latest and greatest translation.

3 3

SUL caveats
by Tim Starling 25 Mar '08

25 Mar '08

Some lucky people might be able to create global accounts at the moment, but please note the following caveats: 1. Local access control on account creation is largely broken. The new user log, IP blocks on account creation, and AntiSpoof conflict checking are broken. Only private and fishbowl wikis are still protected. 2. Email address changes are local and don't propagate properly to the other wikis. 3. There's no cookie sharing so you have to log in to each wiki separately. 4. There's no shared preferences except password 5. You can't rename a global account. I intend on fixing items 1 to 3, in that order. I won't make any guarantees for 4 or 5, maybe someone else is interested in them. -- Tim Starling

15 24

MediaWiki 1.12.0 released
by Brion Vibber 25 Mar '08

25 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No problems reported with 1.12.0rc1, so here's the final release. Enjoy! Full release notes: http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_12_0/phase3/RELEASE-NO… Download: http://download.wikimedia.org/mediawiki/1.12/mediawiki-1.12.0.tar.gz GPG signature: http://download.wikimedia.org/mediawiki/1.12/mediawiki-1.12.0.tar.gz.sig SHA-1 checksum: 48bf1877f60c317cbe93c072187dfe9c1aa3b857 mediawiki-1.12.0.tar.gz MD-5 checksum: MD5 (mediawiki-1.12.0.tar.gz) = 117a1360f440883a51f0ebca32906ea0 Before asking for help, try the FAQ: http://www.mediawiki.org/wiki/Manual:FAQ Low-traffic release announcements mailing list: (Please subscribe to receive announcements of security updates.) http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Wiki admin help mailing list: http://lists.wikimedia.org/mailman/listinfo/mediawiki-l Bug report system: http://bugzilla.wikimedia.org/ Play "stump the developers" live on IRC: #mediawiki on irc.freenode.net - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfi4fcACgkQwRnhpk1wk46HEACaAvMj2oHe0stHrXdhKWUR2fF8 CosAoKvS5oWuitWIgT7rTh+N06kNNmqt =j1cY -----END PGP SIGNATURE-----

4 4

Proposal: Extension information files
by MinuteElectron 25 Mar '08

25 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, In the past few days I've been making good progress on the ExtensionManager extension, and am at the stage where information regarding extensions needs to be stored and polled. In the long term I hope for these files to become widespread (perhaps in nearly all extensions), therefore I'd like to open a discussion about the format -- once implemented it will be difficult to remove features from it, and backwards compatibility would have to be retained indefinitely so a good starting point would be essential. My idea is to use an XML file for each extension, this would be fairly easy to parse (XML support is a requirement for installing MediaWiki) and is easy to write. My suggestion as an example format is (using CategoryStepper as the example) is: <extension> <name>CategoryStepper</name> <version>1.5</version> <description>categorystepper-desc</description> <mediawiki>1.11.0</mediawiki> </extension> While this original version is quite concise it would be easy to expand upon if any further features were needed (for example, there is a possibility of compatibility verification by checking class names etc.). The extensions i18n file will also be loaded within the special page's scope so the <description> tag correlates to a message name allowing for internationalization. The <mediawiki> tag correlates to the minimum MediaWiki version required, the rest are probably self explanatory. Any input on this matter is greatly appreciated. Thank you, MinuteElectron. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfi1VwACgkQkJvUlhoE3wSDxACcDT39xPH7RK4A3gjcg15qmcKz /RMAn0E/StcNnTVGQ89D8qX+Aw4VHY3s =t4Yc -----END PGP SIGNATURE-----

6 17

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32409] trunk/phase3/languages/messages/MessagesEn.php
by Simetrical 25 Mar '08

25 Mar '08

On Tue, Mar 25, 2008 at 9:57 AM, <siebrand(a)svn.wikimedia.org> wrote: > * Prettification of quotes (by Jon Harald S?\195?\184by) > -'tog-showjumplinks' => 'Enable "jump to" accessibility links', > +'tog-showjumplinks' => 'Enable "jump to" accessibility links', > [etc.] Do we want this? I've always been of the mind that straight quotes are the more normal thing on the Web, and there's no point in trying to use curly quotes. Curly quotes look a bit odd on the Web, and they're also hard to type and copy, which makes it annoying for anyone editing messages (either developers or local sysops).

2 3

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32179] trunk/phase3/includes/Category.php
by Roan Kattouw 25 Mar '08

25 Mar '08

simetrical(a)svn.wikimedia.org schreef: > Revision: 32179 > Author: simetrical > Date: 2008-03-19 15:53:48 +0000 (Wed, 19 Mar 2008) > > Log Message: > ----------- > Fix an error for categories named literally "Project:" or some similarly weird thing. I thought that's not a legal title, but I'm told otherwise. Is there a better way to do this than manually prefixing "Category:"? The second parameter to newFromText is ignored if there are any prefixes, according to the docs. You could try Title::newFromText(":$foo", NS_CATEGORY); , which uses the category namespace as the default mainspace, which is then forced by the leading colon. I haven't tested this and I'm not 100% sure this works, but you could try (it'd still be hackish, but it'd be cleaner than the alternative). Roan Kattouw (Catrope)

4 3

Bug 167 for GSoC
by Roan Kattouw 25 Mar '08

25 Mar '08

Yesterday, Tim Johansson (I'll call him Joti from now on, we have too many Tims already) asked me to mentor him for this year's Google Summer of Code. I accepted. The project he proposed was fixing bug 167 [1] (separating category and interlanguage links from the article text in the interface). I've read through the comments, and the issue looks controversial. Several approaches have been suggested in the past and there has been debate as to which one is best. Of course, I'd like to hear from Joti what his plans are so we can discuss them here, but I'd also like to hear opinions as to whether we should actually implement bug 167 in the first place. Roan Kattouw (Catrope) [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=167

8 11

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

24 Mar '08

On Mon, Mar 24, 2008 at 1:17 PM, <vasilievvv(a)svn.wikimedia.org> wrote: > /** > - * Experimental feature still under debugging. > + * If enabled, MediaWiki checks redirects in Image: namespace. > */ > -$wgFileRedirects = false; > +$wgFileRedirects = true; If this is no longer experimental, the config option should be removed entirely, not just enabled by default.

1 0

← 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