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
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
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
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
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
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
>
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.
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
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
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