Wikitech-l April 2008

wikitech-l@lists.wikimedia.org

100 participants
97 discussions

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32782] trunk/phase3/includes/api/ApiEditPage.php
by Bryan Tong Minh 11 Apr '08

11 Apr '08

On Fri, Apr 4, 2008 at 3:49 PM, <catrope(a)svn.wikimedia.org> wrote: > Revision: 32782 > Author: catrope > Date: 2008-04-04 13:49:56 +0000 (Fri, 04 Apr 2008) > > Log Message: > ----------- > Actually, let's have that commit() call there anyway, the way it currently works relies on the fact that internalAttemptSave() schedules deferred updates, which may change. > I think we should implement our own update mechanism for the API. ApiMain::requestWriteMode() should call $dbw->begin() and $bdw->commit() should be called by some finalizer method. Bryan

2 2

Interwiki updates/ bugzilla
by Andrew Cates 11 Apr '08

11 Apr '08

Just a reminder that its six weeks and ten changes since the last interwiki update. Does this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=12763 about the updates need closing since there was an update 10 Feb, or should we keep until the process is an automated monthly task say? Keep up the good work BozMo

1 1

Accessibility/Usability improvements for blind users
by Per 10 Apr '08

10 Apr '08

Hi. I need your help. I would like to search for sponsors for a project which shall increase the accessibility and usability of the Mediawiki user interface for blind screen reader users. I collected my first thoughts at http://blind.wikia.com/wiki/Accessibility_and_Wikis I would be glad if some of you could post comments, suggestions or useful links to the talk page. For example: I would like to learn why it is not possible to use the Mediawiki extension from reCAPTCHA for Wikipedia. This would allow the use of an alternative audio CAPTCHA, but there are surely important arguments against this idea. Don't worry, I am not an accessibility hawk. I just want to inform about the needs of blind Wiki users. There should be lots of potential sponsors for the suggested accessibility/usability development project. If one or more parties would give money, a professional Wiki programmer could be hired to optimize the monobook CSS and JS for screen reader software. After that, the results and experiences could be used for a screen reader skin or gadget for the MediaWiki software. Organisations and companies such as the Mozilla Foundation, the GNOME Foundation, Sun Microsystems, IBM, Canonical, Novell, Google and many other parties already support open source accessibility projects. Why shouldn't we find similar help for MediaWiki and thereby for the great and well known Wikipedia? The costs would be low and the benefits significant. The WikiMedia Foundation and the global blind community will surely appreciate sponsored accessibility improvements. I would like to search for sponsorship opportunities for such an development project. I don't want the Wikimedia Foundation to pay for anything, but I need interest and supporting words from Mediawiki experts first. Accessibility improvements for blind users could be used as another argument for the PR of Wikimedia Foundation and thereby for future fundraisings. What do you think? Best regards from Germany, Per

8 10

Allowing bots and botstatus for SUL
by Gerard Meijssen 10 Apr '08

10 Apr '08

Hoi, There are several bots who work on almost all projects of a kind. Particularly on the smallest projects where there is no bureaucrat, it is not easy to get a bot status. The consequence is that on these small projects it is harder then necessary to establish if there has been some regular activity. When an account with more then existing 10 profiles and bot flags is allowed to be a SUL account, this would make vandalism and regular activity a lot more visible. Thanks, GerardM

4 8

Category intersections, yet again
by Magnus Manske 10 Apr '08

10 Apr '08

I saw this blog entry from freebase: http://blog.freebase.com/2008/04/09/a-brief-tour-of-graphd/ Quote: "We recently demonstrated sustained throughput of about 200,000 simple queries per minute on a single AMD64 core. Simple queries are things like "show me all people who are authors with names containing 'herman'" " Maybe something worth looking into? Cheers, Magnus

3 2

Re: [Wikitech-l] [Foundation-l] Allowing bots and botstatus for SUL
by Gerard Meijssen 10 Apr '08

10 Apr '08

Hoi, When a user has 10 bot flags to start with, I would trust such a user to do well. Mind you ten bot flags within one project... Hmmm that makes it less easy ... darn. Thanks, GerardM On Thu, Apr 10, 2008 at 2:47 PM, Aphaia <aphaia(a)gmail.com> wrote: > On Thu, Apr 10, 2008 at 9:36 PM, Gerard Meijssen > <gerard.meijssen(a)gmail.com> wrote: > > Hoi, > > There are several bots who work on almost all projects of a kind. > > Particularly on the smallest projects where there is no bureaucrat, it > is > > not easy to get a bot status. The consequence is that on these small > > projects it is harder then necessary to establish if there has been > some > > regular activity. > > True. > > > When an account with more then existing 10 profiles and bot flags is > allowed > > to be a SUL account, this would make vandalism and regular activity a > lot > > more visible. > > Seems fine as long as it doesn't mean to grant the account bot flag > automatically. We recently saw it not always a good idea. (cf. > http://meta.wikimedia.org/wiki/Requests_for_comments/-jkb- for further > information: despites of its title, it was rather an issue of rejected > bot flag and its operator). > > -- > KIZU Naoko > http://d.hatena.ne.jp/Britty (in Japanese) > Quote of the Day (English): http://en.wikiquote.org/wiki/WQ:QOTD > > _______________________________________________ > foundation-l mailing list > foundation-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l >

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32993] trunk/phase3/includes/LogEventsList.php
by Simetrical 09 Apr '08

09 Apr '08

On Tue, Apr 8, 2008 at 6:40 PM, <aaron(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Don't set $this->pattern unless it is allowed > - $this->pattern = $pattern; > $ns = $title->getNamespace(); > if( $pattern && !$wgMiserMode ) { > # use escapeLike to avoid expensive search patterns like 't%st%' > $safetitle = $this->mDb->escapeLike( $title->getDBkey() ); > $this->mConds['log_namespace'] = $ns; > $this->mConds[] = "log_title LIKE '$safetitle%'"; > + $this->pattern = $pattern; > } else { Does this need to look at $wgMiserMode at all? A prefix search should be fine efficiency-wise.

3 3

Enabling Xcache after MediaWiki installation
by Etienne Toffin 09 Apr '08

09 Apr '08

Hi, I've installer MediaWiki several weeks ago, and I installed Xcache on the server today. Do I have to configure it on MediaWiki ? Thanks, Etienne Toffin

3 4

new search backend test
by Robert Stojnic 09 Apr '08

09 Apr '08

After much delay, I've completed a new release candidate for our internal search engine. The testing site where you can see it action is same as before [1], with indexes rebuilt from latest dumps. Here are some highlights: * spell checking (aka did you mean...) * ajax prefix suggestions (reimplemented Julien's engine) * nicer highlighting * improved scoring * fuzzy queries, e.g. sarah~ thomson~ will give you all the variations of both of the words * suffix wildcards (works on title words only), e.g. *stan will give you all the -stan countries of central asia - for performance reasons it won't work nicely on huge sets of words It also has some other features that might or might not be included in final release. For instance, "related articles" - if you click the Related link next to the article you will get a list of other articles that occur frequently together with it. This list is internally used to provide context for every article, but I figured it might be interesting for end users as well... I've also documented some of the algorithms I developed at [2]. There you can find out more about how scoring and spell checking works. Search is a bit slowish, especially on enwiki, since I've crammed all of its revision text, spellcheck indexes, search indexes and other stuff on a single host. According to my tests, typical search should be in 150-180ms range (of CPU time), which is much slower than current (25-30ms). Most overhead comes from spell checking and highlighting. I was thinking of trying to use some of the 8-cpu boxes... The ajax suggestions (when properly cached in RAM) are pretty fast (0.2-0.4ms), so we could probably enable it side-wide on search boxes and such. Initially it would be update once a day, but we could cut that down, depending on number of servers and actual number of requests. Comments & suggestions are welcome! [1] http://ls2.wikimedia.org/ [2] http://www.mediawiki.org/wiki/User:Rainman/search_internals

6 6

position of the edit link
by Marcus Schäfer 09 Apr '08

09 Apr '08

hi @all, since upgrading to 1.11.0 I've got the problem, that the edit link to change sections within an article is shown directly left of the subtitle. What can I do to modify it in the way, that it appears right-aligned or at least directly right of the subtitle? greets...Marcus

2 1

← 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 April 2008