To people with shell access, especially Shai: please note that the
force(0) in Setup.php is there for a reason. Just because a query is
slow doesn't mean you can send it to Ariel. It also has to be acceptable
for the data retrieved to be seconds, or quite often, several minutes
out of date. This is most certainly not the case with the link table
select statements, which cause link table corruption as it is due to
being non-locking.
-- Tim Starling
Did anyone look at [[Category:Stub]] lately? Well, "There are 10483
articles in this category." And they are all on one page.
Seems we need to break down large categories into several pages after
all. What would be a good number of article links per page? 500? That
would make 21 pages and counting, for this special case.
I'm still fighting with my Linux setup, so it might be a few days before
I can get back into business ;-)
Magnus
The Wikimedia Board would like to announce that Tim Starling has been
appointed to the official position of developer liaison.
Brion Vibber is currently on a wikibreak, but it is expected than he
might also hold an official position related to development tasks when
he is back.
The Board would like to encourage the creation of a developer
committee whereby certain developers are assigned responsibility for
ensuring that tasks, such as buying servers, are carried out in an
efficient and timely way. It is expected that a number of non-official
positions will be created by this committee, and that particular
developers can be named in certain roles if the committee feel that
would be beneficial.
Tim Starling's role would include documenting the activities of this
committee so the community are aware of who to contact about different
issues, and to ensure smooth communication between developers.
The title is not meant to imply they Tim Starling does, or is expected
to do, more development work than anyone else. He will be the first
point of contact between the developers and the Board. The aim of this
position is to improve communication, both within the development
team, and between them, the Board and the community.
Angela Beesley
On behalf on the Wikimedia Foundation
Hi there...Sheldon Rampton here, at Disinfopedia. After some
irritating and time-consuming encounters with trolls, we have decided
that we want to be able to require contributors to register and to
provide a confirmed email address when they do so. I realize that
this is a more restrictive policy than the Wikipedia has been
following, but I think the additional inconvenience to users will be
offset by the reduced troll-aggravation. I'd like to know how we can
get this capability added to the software. The organization for which
I work, the Center for Media and Democracy, has some funding
available with which we would be able to pay a programmer for the
necessary work (provided the cost is within reason), and of course we
would be happy to have the resulting code included in the standard
open source distribution so that other MediaWiki sites can use it
also if they so choose.
Currently the capacity we want is not built into the MediaWiki
software. Although it is possible to flip a switch that makes
preregistration necessary before posting, there's no way to require
users to supply a verified email address as a condition of
registration.
We'd like to be able to use a registration system like the one that
comes with vBulletin:
http://www.vbulletin.com/forum/register.php
After a new user submits their email address, vBulletin displays a
message that says something such as:
>Thank you for registering, Sheldon Rampton. An email has been
>dispatched to sheldon.rampton(a)verizon.net with details on how to
>activate your account. Click here to return to where you were
>previously. You will receive an email in your inbox. You MUST follow
>the link in that email before you can post on these forums. Until
>you do that, you will be told that you do not have permission to
>post.
In addition, we would like to be able if necessary to turn on a
higher level of security that says,
>All membership requests must be approved by the moderator. You will
>receive a confirmation email when your membership has been approved.
If someone here is willing to work with on this, please get in touch
with me at <sheldon.rampton(a)verizon.net> or <sheldon(a)prwatch.org>.
A neat request. I have been using directory-level password-protection
to obtain similar restrictions, but would much prefer a system like this which
is built into the wiki software... and I imagine the offer to fund
this work will be
much appreciated. Perhaps the bounty distribution system will get a
workout before any WM funds have been allocated to it !
+sj+
ps - I just saw somewhere on meta that you were the one to suggest the name
'wikiMedia' for an umbrella organization. thank you for that. ^ ^
On Thu, 8 Jul 2004 10:09:45 -0500, Sheldon Rampton
<sheldon.rampton(a)verizon.net> wrote:
> Hi there...Sheldon Rampton here, at Disinfopedia. After some
> irritating and time-consuming encounters with trolls, we have decided
> that we want to be able to require contributors to register and to
> provide a confirmed email address when they do so.
< ...
> In addition, we would like to be able if necessary to turn on ...
>
> >All membership requests must be approved by the moderator. You will
> >receive a confirmation email when your membership has been approved.
I'm interested in starting a Wiki-based project, and I'm wondering if Wikimedia
has the capabilities I'm looking for (or if it can be made to). Like most
people, I discovered Wikimedia through Wikipedia, and I enjoyed using it enough
to consider it for my own project.
My project will consist of one or more data sets, each split into pages (like
Wikipedia). There will also be a set of "overlays" or "diffs" that provide
alternate views of one or more pages within a data set. Each diff should be
editable like an ordinary Wiki page, including having its own diffs and
changelogs.
When I get done, a user should be able to view Page, be able to view Overlay 1
(which modifies Page 1 and Page 2, for example), be able to edit Page and
Overlay 1, and be able to track the changes to both Page and Overlay 1.
>From my experiences with Wikipedia, it appears to me that Wikimedia would do
well with a Page and a Changelog, or a Page and an Overlay (which would be a
changelog), but not with all three of those types.
Any thoughts?
--
Joel Konkle-Parker
Webmaster [Ballsome.com]
E-mail [jjk3(a)msstate.edu]
Phone [662-518-1636]
I am an admin on en:, but I hardly ever read this mailing
list, and only subscribed today. The reason I subscribed is
because I am really quite upset and fed up about the
ridiculous treatment Holopedia@Wikipedia received -- the
free encyclopedia in the Taiwanese language
"http://en.wikipedia.org/wiki/Taiwanese_%28linguistics%29".
I came up with the idea of Holopedia
"http://weblog.holopedia.org/archives/holopedia.jpg".
The Most Serene Fellows Pektiong and Henry
"http://www.digitas.harvard.edu/cgi-bin/wiki/ken/ThoanKhe"
submitted an application to create Holopedia@Wikipedia. The
intention was to prevent forking -- we could easily have run
MediaWiki somewhere else (and indeed we did, as a means of
testing -- but to prevent forking, I will not let you know
where we ran it).
We requested the hostname 'zh-min-nan', per RFC 3066
"http://www.iana.org/assignments/lang-tags/zh-min-nan". I
registered the tag, so I should know. Some silly person did
not honour our request, but created a syncretic monster
'zh-cfr' without consulting the community (to prevent
forking (and to prevent giving it any authority), I will not
let you know where the letters CFR came from). Then, some
(other) silly person dictated 'minnan'. Then, yet some
other person suggested the meaningless 'poj'.
Please honour our original, simple request and give us
"http://zh-min-nan.wikipedia.org/". We are holding back
from editing at the moment because we still want to prevent
forking. All the silly manoeuvre described above only works
against the non-forking -- a fundamental value of Wikipedia.
Please,
CHANGE IT NOW to zh-min-nan!
CHANGE IT NOW!
CHANGE IT NOW!
Let's waste no more time. Thank you very much.
CHANGE IT NOW!
CHANGE IT NOW!
CHANGE IT NOW to zh-min-nan! Have you changed it?
(Sorry for crossposting, but I found soon after sending to
mediawiki-l(a)Wikimedia.org that I should have sent it here.)
Hello,
I'm a software engineer for the Creative Commons and am working on our
on-line license/RDF validator. We're currently working on adding <link>
support for RDF retrieval, due in large part to Wikipedia's decision to
use CC metadata to describe the FDL license. We have intial support
working, but when we test with Wikipedia, we get a 403: Forbidden.
Our system parses the page and attempts to retrieve the metadata file
seperately; specifically,
http://en.wikipedia.org/w/wiki.phtml?title=Main_Page&action=creativecom…
for the Main_Page.
Does Wikipedia have non-browser requests for the metadata blocked? Is
there something we need to do in order to retrieve the metadata? Thanks
for any help you can provide.
Nathan R. Yergler
Hello.
We, Spanish Wikipedia users, have recently approved in election
[[es:Wikipedia:Elecciones#UTF-8]] the will to switch to the UTF-8 encoding.
I have read the messages regarding the possible conversion of en: to
UTF-8. Es: is smaller (~24700 articles) and I hope it would be easier to
do the change.
We miss currently a person with database access so we would thank very
much to any developer making the conversion on es.wikipedia.
Would it be possible?
--
ManuelGR, administrator at es.wikipedia.
Hi folks,
I'm using a wiki for writing (preparing) articles and several similar
stuff. To make it easier, I'm currently writing an wiki-syntax parser
for my Website-Kit, so it can directly read wiki articles (otherwise
I would have to rewrite it to some XML schema).
But my article schema supports a little bit more than just text
and headlines, i.e. outline, title, ext.linklists, etc.
So I'm planning to extend the common wiki syntax by some additional
elements, i.e. some block/section tags (as used by some template engines).
An extendet wiki article could probably look like:
{--ATTR--}
Language: de
Translation-en: foo
{--TITLE--}
Article Title
{--OUTLINE--}
This is the article outline
{--TEXT--}
...
The traditional wiki syntax would in fact be a subset of the new (extendet)
syntax. We could now store also some metadata, i.e. changelog, editor-flags
(i.e. for non-public areas), etc.
Any comments ?
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(a)metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
