Wikitech-l July 2006

wikitech-l@lists.wikimedia.org

96 participants
149 discussions

Start a nNew thread

New SVN committer
by Brion Vibber 02 Jul '06

02 Jul '06

Added Jimmy Collins (collinj), German localization updates & misc patches. -- brion vibber (brion @ pobox.com)

1 0

Making Group Names Longer
by Gregory Szorc 02 Jul '06

02 Jul '06

I am implementing a group synchronization feature in my custom authPlugin and noticed that the ug_group field in the user_groups table is only 16 characters long, which is not nearly long enough! A quick audit of the code revealed no problem with simply modifying the database schema to increase the field length (I hope). Anyway, I was curious if the devs would entertain increasing the group name length to something less restrictive, say 64 or 128 characters. Also, can someone confirm that modifying the field length in the database won't cause any irregularities? Thank you, Gregory Szorc gregory.szorc(a)gmail.com

1 0

MediaWiki automated test run failure 2006-07-02
by brion＠pobox.com 02 Jul '06

02 Jul '06

An automated run of parserTests.php showed the following failures: Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED! Running test Link containing double-single-quotes '' (bug 4598)... FAILED! Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED! Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED! Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED! Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED! Running test HTML bullet list, unclosed tags (bug 5497)... FAILED! Running test HTML ordered list, unclosed tags (bug 5497)... FAILED! Running test HTML nested bullet list, open tags (bug 5497)... FAILED! Running test HTML nested ordered list, open tags (bug 5497)... FAILED! Running test Parsing optional HTML elements (Bug 6171)... FAILED! Running test Inline HTML vs wiki block nesting... FAILED! Running test Mixing markup for italics and bold... FAILED! Passed 394 of 407 tests (96.81%) FAILED!

1 0

swedish MediaWiki deafult messages
by lejoneln 01 Jul '06

01 Jul '06

A very big update was made to the Swedish language file a some weeks ago. On the swedish Wikimedia projects many older unupdated messages in the MediWiki namespace were edited only by a user called MediaWiki_default (some script run on the servers?). Many of those messages are now old and "blocks" the updated messages in the language files. Can User:MediaWiki_default update or delete the messages on swedish Wikibooks and Wikisource were MediaWiki_default is the only contributor? (on the other swedish projects administrators has already manually deleted those messages, but that seems to be unnecceary work if a script can do it automatically). /~~~~ ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

2 1

New SVN committer
by Brion Vibber 01 Jul '06

01 Jul '06

Added Ilmari Karonen (vyznev); has been working on misc fixups and patches. -- brion vibber (brion @ pobox.com)

1 0

New diff feature for Wikipedia
by Roman Nosov 01 Jul '06

01 Jul '06

Hi all, I've been directed here by Brion, Robchurch and others on #wikimedia-tech. So I propose a new feature for Wikipedia which people on #wikimedia-tech mostly refer as blame page or blame map. I would prefer to call it something like "Track contributions mode" (because of similarity with MS Word track changes mode) or "Hall of fame" but whatever. I have live prototype written in PHP&MySQL at http://217.147.83.36:9000/ Example of "blame map" can be seen at http://217.147.83.36:9000/history::171 two blame maps compared http://217.147.83.36:9000/history::171=169 For some reason folks at #wikimedia-tech. were mainly concerned with speed and almost nothing else so I'll try explaining performance issues as best as I can. First of all, I DO NOT propose to recalculate diffs for all zillions of edits Wikipedia already has. Diffs would only be calculated for a new edits. Next, I want to explain in detail how I see this working. So first I propose to modify revision table and add a flag with following possible values: "Revision is too old to be diffed", "Revision is awaiting to be diffed", "Revision has been diffed". Also another table should be added that will store blame maps for each revision. Blame map for each subsequent revision will be calculated incrementally. So it doesn't really matter whether article has 10 or 1000 revisions. We would only need last blame map. I also propose to have separate dedicated diff server(s) with sole job to calculate diffs in background. I.e. diff server grabs revision with "Revision is awaiting to be diffed" flag and last blame map from database, calculates diff and finally stores new blame map in the database and also changes revision flag to "Revision has been diffed". Repeat. In addition, article display logic should be altered. The module that displays article should check diff flag. If diff flag is set to "Revision is too old to be diffed" no further changes needed. If diff flag is set to "Revision is awaiting to be diffed" then Credits section should be created that only contains message "Calculation in progress". If diff flag is set to "Revision has been diffed" then Credits section should be created that contains list of contributors ordered by contribution size. The list of contributors in correct order can be generated with a single select to blame map table. In addition this select can be cached. Direct link to blame map should be displayed too. If user clicks on this blame map link corresponding blame map should be presented. Every blame map can be generated with a single select and can be placed in cache. Yawn If you are still awake by now more thoughts on fault tolerance here. Should diff server die, crash, fail or whatever the only side effect end user will see is "Calculation in progress" message right after article body. That's it. No slowdown or anything. If user still wants see some kind of diff he/she can still use old diff engine. Because blame maps aren't calculated in real time this feature is impractical target for DoS attacks. However I should point out that any real time diff algorithm is one big fat target for DoS attacks on other wikis which are run on single server without some sort of acceleration. There is also small Unicode issue. Due to crappy utf-8 support in PHP all non-latin characters are currently ignored. I believe this could be solved either by enabling proper Unicode support in PHP or writing custom code to separate words. But before that I propose to test on English Wikipedia first because if it will works for English it should work for other languages. So I offer following practical steps. Dedicate one of servers to be diff playground. I will need a shell account on this server. Install mediawiki on it alongside with diff logic running in background. Create read only mysql account on live database server. So as a result this diff server can grab new revisions from live database, diff them and store results locally. This way we can find out how many edits single server can process and see how many servers this feature will require in total (I don't think it will be more than 2-3 though). In conclusion, I'd like to say that in my opinion this feature will be useful and practical if implemented. It also can be crucial building block for other interesting features. However, I want to stress that I'm not interested in doing this *unless* it is used in English Wikipedia and I'm given appropriate credit. I can give a reason why I want that in private e-mail. Thank you for reading this long and boring e-mail.

18 46

OpenDocument file format
by Jakob Voss 01 Jul '06

01 Jul '06

Hi! It has been asked multiple times at [[commons:Commons talk:File types]] to enable OpenOffice.org 2.0 formats (=OASIS OpenDocument Format) for file upload. Any objections? Can you please enable it? Filename extensions are .odt (text), .ods (spreadsheet), .odp (presentation), and .odg (graphics), then there is .odc (chart), .odf (formula), .odb (database), .odi (image), and the according templates .ott, .ots, .otp, .otg, .otc, otf, .oti and finally .odm (text-master) (see http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf appendix C, page 697f.) Greetings, Jakob

4 3

MediaWiki automated test run failure 2006-07-01
by brion＠pobox.com 01 Jul '06

01 Jul '06

1 0

Ligurian counter
by Claudi Meneghin 01 Jul '06

01 Jul '06

Hello, many thanks. Maybe in some papers internal links are still missing. I'm going to check, but almost surely this is the matter. If so, I will fix it as soon as possible. Sincerely yours, Claudi Date: Fri, 30 Jun 2006 17:34:54 +0100 From: "Rob Church" Subject: Re: [Wikitech-l] paper counter at lij.wikipedia.org To: "Wikimedia developers" Message-ID: Content-Type: text/plain; charset=UTF-8; format=flowed On 30/06/06, Claudi Meneghin wrote: > Hello, > the counter of articles at Ligurian wikipedia seems not to run properly: it shows some delay (not depending on the cache of the browser), and it counts only 33 papers, instead of about 45. Could you please take a look? Many thanks, First, let's check you're not misinterpreting a value. For a page to count towards the "article total" in Special:Statistics, MediaWiki has to acknowledge it as an article. For this, it must meet three criteria: 1. Be in the main namespace, or another designated content namespace 2. Not be a redirect 3. Contain at least one internal [[link]] Please confirm pages matching these criteria are not affecting the article total. Rob Church --------------------------------- Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.

1 0

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 July 2006