Hello all,
together with Frank Schulenburg and Naoko Komura, I just participated
in a video-conference with the winners of the Google Kiswahili
Wikipedia challenge ( http://www.google.com/events/kiswahili-wiki/ ),
and we talked about some of the challenges they encountered when
contributing to the Swahili Wikipedia.
One of the issues was that it was very hard for them to upload files.
Specifically, when you're a new user on a small wiki like sw.wp, you
_cannot upload_ locally due to a restriction of uploads to
autoconfirmed users. The upload link isn't even visible in the sidebar
until you're autoconfirmed, and you get a confusing error message if
you happen to call up Special:Upload.
>From a user experience standpoint, this is horrible.
For the immediate future, I suggest lifting this restriction for wikis
between 1,000 and 50,000 articles in size (large enough to have a few
active users, small enough to not yet have lots of policy around these
issues). Ultimately we'll want to integrate Commons better into the
user experience, but until then, IMO we should eliminate artificial
impediments like this which prevent people from growing their
communities and frustrate them -- unless there's a proven issue of
large scale abuse. Does that make sense?
Thanks,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
FYI - I am seeing a lot (10-20% of queries) on secure.wikimedia.org
return proxy errors, since the recent outage. I had been hoping it
would just go away, but the rate is still high...
---
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET
/wikipedia/en/wiki/User_talk:Foobar.
Reason: Error reading from remote server
Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 PHP/5.2.4-2ubuntu5.7wm1 with
Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at
secure.wikimedia.org Port 443
---
--
-george william herbert
george.herbert(a)gmail.com
Are these the servers that wikipedia no longer require due to the
increasing number of
deletions being made recently?
As of today, I will no longer be contributing to MediaWiki through
bugfixes.
The reason for this being that: the amount new content is decreasing,
and the amount of articles being deleted is increasing.
Even recently I noticed that there is proposals for deletions on
Wikipedia of article about the Australian National University and its
colleges, as apparently they are not notable enough and all should be
merged into one article.
Regards
Karun
>
> On Tue, 15 Sep 2009 15:00 -0300, "Mike.lifeguard"
> <mike.lifeguard(a)gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hello,
> >
> > I wanted to let folks know that WMF is decommissioning some 35 servers,
> > and is willing to accept requests from users interested in using them
> > for Wikimedia-related purposes. If you can ship a server from Tampa to
> > where you are, and if you can put it to good use, please see
> > http://tinyurl.com/r3xhp7 and send your request in.
> >
> > Many thanks to the tech team (in particular RobH - looks like he's
> > handling most or all of this) for reaching out to community members
> > first. I'm sure we can find happy homes for lots of this hardware, which
> > will help community members be productive in helping achieve Wikimedia's
> > mission.
> >
> > - -Mike
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAkqv1iAACgkQst0AR/DaKHtN8gCdEMaFLzmPRQQcz0f3d2vCajJI
> > woIAn1PV0fN9uvoKoobFMmB/kt0LmxYJ
> > =VrGB
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
Please be patient for my question.
We (into it.source) are faced with Vector skin, and all our beloved editing
js gadgets are lost. My question is: is it technically possible to imagine a
*js floating box as a container for buttons, menus and so on*? It would be
great since customable buttons & menu are often unconfortable for their
fixed location into the edit window.
If it's impossible.... simply tell me "It's impossible". :-)
--
Alex (User:Alex_brollo)
Hi all,
DBpedia [1] is a community effort to extract structured information from
Wikipedia and to make this information available on the Web. DBpedia allows
you to ask sophisticated queries against Wikipedia knowledge [2]. DBpedia
also plays a central role as an interlinking hub in the emerging Web of Data
[3].
The DBpedia Team at Freie Universität Berlin [4] is looking for a
developer/researcher who wants to contribute to the further development of
the DBpedia information extraction framework, investigate approaches to
annotate free-text with DBpedia URIs and participate in the various Linked
Data efforts currently advanced by our team.
Candidates should have
+ good programming skills in Java, in addition Scala and PHP are helpful.
+ a university degree preferably in computer science or information systems.
Previous knowledge of Semantic Web Technologies (RDF, SPARQL, Linked Data)
and experience with information extraction and/or named entity recognition
techniques are a plus.
Contract start date: 15 May 2010
Duration: 1 year
Salary: around 40.000 Euro/year (German BAT IIa)
You will be part of an innovative and cordial team and enjoy flexible work
hours. After the year, chances are high that you will be able to choose
between longer-term positions at Freie Universität Berlin and at neofonie.
Please contact me via email (chris(a)bizer.de) until 15 April 2010 for
additional details and include information about your skills and experience.
The whole DBpedia team is very thankful to Neofonie GmbH for contributing to
the development of the DBpedia project by financing this position. Neofonie
is a Berlin-based company offering leading technologies in the area of Web
search, social media and mobile applications (http://www.neofonie.de/).
Cheers,
Chris
[1] http://dbpedia.org/
[2] http://wiki.dbpedia.org/FacetedSearch
[3] http://esw.w3.org/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
[4] http://www.wiwiss.fu-berlin.de/en/institute/pwo/bizer/
--
Prof. Dr. Christian Bizer
Web-based Systems Group
Freie Universität Berlin
+49 30 838 55509
http://www.bizer.de
chris(a)bizer.de
Hi
i have a list of people that i would like to allow to edit my wiki pages but
i want to review them before they are published. Is there a way that i can
be notified that this page has been updated and is waiting for my approval
before being published?
Similar to moderating a list i suppose.
Thanks.
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /wikipedia/en/w/index.php.
Reason: Error reading from remote server
Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 PHP/5.2.4-2ubuntu5.7wm1 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at secure.wikimedia.org Port 443
Hello all.
For those of you who have tried to get mediawiki running under hiphop, I've
run into a block.
After applying the patches from Domas and converting a few e-flagged
preg_replace functions to preg_replace_callback, I have it running
successfully, hitting the database as many times as it needs to, invoking no
errors, and generally being very fast. I get a 200 response on my requests
(very quickly), no errors raised, but no matter the request, the body is
completely blank and the content-length header is 3. I suspect that the skin
is not getting loaded properly, but as I'm not deeply familiar with the
codebase I'm wondering if any of you can see anything obviously wrong. This
happens on api requests and requests to the index after a 301 to MainPage.
Thanks for your help!
Ryan
I have applied the following patch from Domas against svn rev 63062:
http://stafford.wikimedia.org/current-patch.txt
I replaced a couple e-flagged preg_replace functions with
preg_replace_callback and did some type interference:
http://projects.yaauie.com/hphp/mediawiki/hphp-yaauie.patch
I'm using the following file list:
http://projects.yaauie.com/hphp/mediawiki/hphp-files.list
My environment variables are set by source-ing this file:
http://projects.yaauie.com/hphp/mediawiki/hphp.env
I'm compiling with the following string:
$HPHP --input-list=files.list --force=1 --k 1 --log=3 --program=mediawiki
I'm running the resulting application with the following string:
sudo /tmp/hphp_abc123/mediawiki -m server -c hphp-runtime-config.hdf
The config file I'm loading is:
http://projects.yaauie.com/hphp/mediawiki/hphp-runtime-config.hdf
I'd like to discuss the proposed change to the authentication plugin
system (http://www.mediawiki.org/wiki/ExternalAuth). As proposed, I
don't see how I'll be able to keep most of the functionality in the
LDAP extension.
I don't disagree that policy and implementation shouldn't be mixed,
but core shouldn't be making all policy decisions. For instance, there
is an option in the LDAP extension ($wgLDAPDisableAutoCreate) that
disables auto-creation, but still allows auto-authentication.
Essentially, it says, if the user exists in LDAP, but not in the local
directory, don't automatically create the local account. Some
administrators want to create accounts for users in the wiki locally,
even though they already have accounts in LDAP.
Will getGroups() assign users to whatever groups the backend returns?
The way I'm currently doing this is adding users to groups if they are
available groups in the wiki (if they've been defined in
$wgGroupPermissions). I don't use auto-promote at all.
The LDAP plugin can add users to the LDAP database. Is this also going
to support that?
The LDAP plugin allows a user to authenticate with one username, but
have the username created be something else. This is absolutely a
must-have for auto-authentication, where a user might authenticate
with Kerberos or an SSL certificate. If a user authenticates with an
SSL certificate, their username may be something insane, like a
numeric ID with special characters. The LDAP plugin would search the
LDAP directory for another attribute that should be used for the
username. Notice that you don't necessarily want to treat the
auto-auth name as an ID either. You may pull both a new username, and
a unique ID from the LDAP server; this is an especially likely
scenario in a large organization, where a user may have a global
unique ID, but in some places they may have a locally unique ID (think
mergers).
There are situations where newFromId( $id ) and getId() won't work.
Active Directory (AD) is a case where it is unlikely to work for most
people. By default AD does not allow anonymous searches. There are two
ways to handle this:
1. Use a proxy agent (AD administrators *hate* this)
2. Bind as the user first
In the second case, newFromId( $id ), and getId() will only work if
authenticate( $password ) is called first. In fact, many things
require the user to be authenticated before another action can happen.
>From the LDAP server's perspective, MediaWiki *is* the user binding.
A few things I'd really like to see fixed with any new system are:
1. Extensions being able to display error messages (bug 16524)
2. Ability to rename a local account when the external account is renamed
3. Local group name size increased in the schema (bug 11057) so that
all external groups can be synced properly
Respectfully,
Ryan Lane