When I try to check the
http://www.wikipedia.org/wiki/Wikipedia%3AUpload_log Upload log page, I'm
getting timeouts and "connection close" messages. Is that one of the ones
that needs to be cleared out from time to time, or is that just the
Deletion log? If it is, it's probably time to clear some out. If not, then
why IS it behaving this way?
--
John R. Owens http://www.ghiapet.homeip.net/
I will confess that I look forward to the day when we have cleansed the
universe of the Centauri and carved their bones into little flutes for
Narn children. 'Tis a dream I have.
--G'Kar
In the process of writing some standards documents for the Wikipedia
content model (some lower level behind-the-scenes stuff that needs to
be done before working on the syntax and to beef up the test suite),
I've come to the point were I need to decide exactly what characters
are and are not allowed in page titles. I'd like to solicit input on
this. Keep in mind here that what I'm specifying is what set of
characters can a page title be chosen from; that is, what strings
will be allowed between the brackets of a link, and displayed at the
top of a page, regardless of whatever URL-encoding tricks we have to
use to make that happen. _After_ we specify that, then we can specify
exactly how to construct URLs from them. Here are my current thoughts:
* Cannot allow: # (sharp), | (pipe), " (quote), [] (brackets),
{} (braces), <> (greater,less), + (plus), \ (backslash) because
allowing them would interfere with link syntax and make the
software more tricky to write. I can live without these, though
I think + might be handy in some places (like C++), and might be
worth the effort to allow.
* Should allow anything Unicode calls a letter, numeral, syllable,
or ideograph.
* Should not allow Unicode diacriticals, combining forms, display
forms (ligatures), controls, and other specials.
* Should allow most ASCII punctuation that might appear in a name
or title in text, specifically - , . ( ) ' & : ; % ! ? / $ *
(Note that some of these, like *, are not currently alowed,
and that : is a special case that's allowed but only when the
text before it doesn't match a namespace, etc.)
* Should not allow non-ASCII punctuation like em dash, curly
quotes, etc., because they cause problems on machines with
strict ISO character sets.
* Space is allowed. Underscore is allowed, but indistinguishable
from space. No other controls (tab, etc.) are allowed.
Anyone have other ideas/suggestions?
--
Lee Daniel Crocker <lee(a)piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
I was just looking at [[test:]] (because of that new disambiguation thing),
and I wasn't logged in, so I logged in, and there was no such user.
I thought that I'd created one there ... but apparently not,
so I went ahead and created a new [[User:Toby Bartels]] there.
But then I looked on my watchlist, and there was stuff there!
(Stuff that should have been there, since I'd added it before.)
This may just be a known side effect of some previous change to [[test:]],
perhaps even announced once ("Everybody must recreate their account.")
and forgotten. But if the developers don't understand how this happened,
then perhaps somebody should look into it.
Summary: My account existed, complete with watchlist,
but I couldn't log on until I created it anew.
-- Toby
--- Brion Vibber <brion(a)pobox.com> wrote:
Brion.
Aoineko suggested that it is my police which is wrong
and not my browser (err...browsers) in supporting
unicode. I understood from what you told me it was my
browser. I don't care I can't see international links,
but I do care when I can't read the content of
articles, or even the title of the articles.
So...perhaps I understood nothing, but do you think
Opera 5 is not accepting unicode because of missing
polices or does it just not tolerate it at all ?
Netcape 4.7 is not working either
Mozilla is better (I can see Lech Walesa), but still I
can't see the international links. IE is writing ?
Is that worth that I try to import some polices ?
Ant
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
To sum up the current state of the deletion topic.
Several users think it is a good idea that every user
be able to see a deleted page.
The reasons given are 1) transparency (as we claim
Wikipedia respects) and 2) possibility to reuse some
edits in deleted pages.
As already mentionned, it so happens that some banned
users edits are deleted very quickly, without going
through the process of vfd. However, I read several
times (or saw it myself) that parts of the edits of
banned users were good and might be of interest to
keep.
(see for example for Lir
http://mail.wikipedia.org/pipermail/wikien-l/2003-May/003689.html)
I suggested that edits of banned users be kept for a
temporary time, either in a boilerplate, or in a
blanked page history...but for the reasons given by
Eloquence and others, I see this proposition is not
good (too much strain on sysop cleaning, not fitting
the requirements of either soft and hard banning). So,
this option can not be kept. And even if the edits
might be good, it is probably better to wait for a
while until picking the stuff up (until the vandal is
gone) and perhaps to put it back under another author
name.
Consequently, because of the good arguments given
against keeping stuff in the article space for longer
than necessary, the only option left, is, to permit
users to see the content of a deleted article.
In short, I think if Wikipedia wants to stay open and
transparent, the deleted stuff should be visible. That
is part of a feedback control which is important in
every system.
-----------
Three persons expressed negativity toward this
proposition.
Jimbo and JeLuf indicated it was not a good idea
because copyrighted material should not be seen from
outsiders. Eloquence indicated it was not good -
probably for this copyright reason, as well as for the
reason it has been already discussed ad nauseum (where
?).
(see
http://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004028.htmlhttp://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004132.htmlhttp://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004143.html)
As far as copyrighted material is concerned, I plainly
agree it should not been seen by others than trusted
people (hence, developers and sysops). I agree it
would be potentially very damaging for Wikipedia that
such an information be visible by others, as it could
lead to legal troubles.
Then, I agree it is not a good idea that non-sysop
users see material that has been deleted because of cp
infringements.
However, as Toby mentionned, copyrighted material is
*not* the only material deleted. Far from it. No good
reasons were, till now, given to justify other-than-cp
deleted pages not to be seen by non-sysop users.
Besides, quite a number of people, including Toby,
Martin, Brion, Oliver, and I, think it would be good
that users see deleted pages
(See
http://mail.wikipedia.org/pipermail/wikien-l/2003-May/003490.html
or
http://mail.wikipedia.org/pipermail/wikien-l/2003-May/003755.html
or
http://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004136.htmlhttp://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004154.html
Consequently, I think the solution is that somehow,
deletions for cp issues and for other issues are just
separated in the big black void (sorry, the deletion
area of the db).
This could be made possible if, when deleting the
page, the sysop was somehow proposed to check a little
box (say), which would automatically classify the
deleted page in the cp category.
Then, the deletion log would be grossly separated in
two types, cp stuff and other stuff.
(I also think it would nice to separate per namespaces
: deletion of encyclopedia article, deletion of users
pages, deletion of meta pages).
When accessing the special:page undeleted, all the
stuff with cp material will be invisible (as now) from
non-sysop users, while other stuff (non copyrighted)
is visible.
On top of that, I also think it is quite weird to keep
forever in this deletion db, all this copyrighted
material (or porn pictures perhaps :-)).
Such a separation might give the developer the
possibility to run a deletion query from time to time
(such as "deletion of all copyrighted articles been in
the deletion db for more than 2 months"). Hence,
Wikipedia liability toward cp, would be reduced.
(see also on similar topic
http://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004121.html
and
http://mail.wikipedia.org/pipermail/wikitech-l/2003-May/004140.html)
Anthere
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
My first ever CVS commit seems to have worked just fine. I fixed a bug I
submitted to the tracker myself, # 635281, URL:
http://sourceforge.net/tracker/index.php?func=detail&aid=635281&group_id=343
73&atid=411192
It was a tough one: four whole characters of source code had to be added to
Article.php in the obvious place. Plus another four for good measure. I
tested it on Lee's machine and it seems to work.
-- Tim Starling.
Since this happens often, and since Danny is good, I would support
hardcoding (if necessary) for Danny's special case.
Or, is Danny a sysop? If not, why not? Can't sysops edit even under
an ip ban? If not, they should be able to, if for no other reason
than self-defense even if some bad person gains access to a sysop
account and tries banning other sysops.
----- Forwarded message from daniwo59(a)aol.com -----
From: daniwo59(a)aol.com
Date: Sun, 25 May 2003 15:49:55 EDT
To: wikiEN-l(a)wikipedia.org
Subject: [WikiEN-l] request for tech help
I am getting the "you are blocked" message again. Let me clarify. I am not
Michael. This is frustrating.
Danny
----- End forwarded message -----
I have recieved a spam. Nothing special. But the TO: adress is, I think.
Is it normal that spam send to <email AT pliny.wikipedia.org> is forward to
<wikinl-l-admin AT wikipedia.org> , the contact emailadress of Wikipedia
NL?
--->
>From - Wed May 28 00:28:22 2003
X-UIDL: 969e3452ea8a1cd625306ddc2aad1fa5
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <wikinl-l-admin AT wikipedia.org>
X-Flags: 0000
Delivered-To: GMX delivery to giskart AT gmx.net
Received: (qmail 8046 invoked by uid 65534); 27 May 2003 22:20:06 -0000
Received: from efwd.dnsix.com (EHLO efwd.dnsix.com) (216.34.94.189)
by mx0.gmx.net (mx028-rz3) with SMTP; 28 May 2003 00:20:06 +0200
Received: from [130.94.122.197] (helo=pliny.wikipedia.org)
by efwd.dnsix.com with smtp (Exim 3.36 #1)
id 19Kmnb-0001eh-00; Tue, 27 May 2003 15:20:03 -0700
Received: from pliny.wikipedia.org (localhost.localdomain [127.0.0.1])
by pliny.wikipedia.org (8.11.6/8.11.6) with ESMTP id h4RMK2132280;
Tue, 27 May 2003 22:20:02 GMT
Received: from NETSCAPE.NET ([200.101.71.203])
by pliny.wikipedia.org (8.11.6/8.11.6) with SMTP id h4RMJ4132225
for <wikinl-l-admin AT wikipedia.org>; Tue, 27 May 2003 22:19:05 GMT
Received: from group21.345mail.com ([108.43.83.131])
by nntp.pinxodet.net with SMTP; 28 May 2003 13:12:13 -1000
Received: from unknown (HELO qnx.mdrost.com) (102.165.97.188)
by smtp18.yenddx.com with asmtp; 28 May 2003 03:03:55 -0500
Received: from relay.2yahoo.com ([92.180.109.121])
by nntp.pinxodet.net with QMQP; Tue, 27 May 2003 21:55:37 -0000
Message-ID: <1c5501c32490$d6fde580$9552ba07@kqyixcpmtdnmxkt>
Reply-To: <CustomPrintGoods(a)NETSCAPE.NET>
From: <CustomPrintGoods(a)NETSCAPE.NET>
To: email AT pliny.wikipedia.org
Subject: Giant Posters made from YOUR Images: $7.00 a square foot
Date: Wed, 28 May 2003 08:44:59 +1200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_0CF_B84F_A258DD21.449BEA57"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: wikinl-l-owner AT wikipedia.org
Errors-To: wikinl-l-owner AT wikipedia.org
X-BeenThere: wikinl-l AT wikipedia.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:wikinl-l-request AT wikipedia.org?subject=help>
List-Post: <mailto:wikinl-l AT wikipedia.org>
List-Subscribe: <http://www.wikipedia.org/mailman/listinfo/wikinl-l>,
<mailto:wikinl-l-request AT wikipedia.org?subject=subscribe>
List-Id: De discussielijst van de Nederlandstalige Wikipedia <wikinl-
l.wikipedia.org>
List-Unsubscribe: <http://www.wikipedia.org/mailman/listinfo/wikinl-l>,
<mailto:wikinl-l-request AT wikipedia.org?subject=unsubscribe>
List-Archive: <http://www.wikipedia.org/mailman/private/wikinl-l/>
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Sender is in whitelist)
--
Contact: giskart AT wikipedia.be
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now I know we're supposed to be in feature freeze, but I consider this a
bug fix as it's been damn annoying. I've just checked in changes to
Article.php, SpecialContributions.php, and Language.php to add a
last-user-name check to the rollback link. If when the rollback is
activated, the last editor on that page is someone other than it was
when the link was generated, it will throw an error message instead of
blindly reverting -- usually putting the vandalism back on top. :)
This is in CVS and on test.wikipedia.org; please help shake it out a bit
more before putting it live.
I've also taken the $wgDisableCounters check out of SiteStatsUpdate.php,
since that had broken the article count. And, the article count should
now be running on the agreed-upon link-count instead of ugly old
comma-count (this change has been in the code for a while, but is only
now live).
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+0Gz8xVlOmwh1xjgRAhvAAJ9XAiqbZdEZtsFSij1k4hLq+a4kkwCeOCOP
N0Jx4D09BND4qAUFkzu9AdU=
=GoJP
-----END PGP SIGNATURE-----
We should try to find the most reasonable default user options possible.
Here's some data from the English Wikipedia (11474 users) on the number of
users who have changed each option from the default:
-----------------------------
skin=1 (nostalgia): 403
skin=2 (cologne): 991
hover=0: 52
underline=0: 2332
highlightbroken=0: 580
justify=1: 417
hideminor=1: 226
usenewrc=1: 362
numberheadings=1: 202
rememberpassword=1: 4735
editondblclick: 147
watchdefault: 213
minordefault: 160
previewontop: 831
nocache: 4
-----------------------------
Regarding the skins, I think Cologne Blue *could* become the standard with
some design fixes, but we should stick with Standard for now.
Considering that previewontop was recently changed to be the default,
there remain two strikingly popular options: rememberpassword=1 and
underline=0. Since most users never change their preferences, these
numbers are quite high, even if they are not the majority.
I therefore think it would make sense to make these options defaults, that
is, to make links non-underlined by default even for anonymous users, and
to remember passwords by default.
Underlining:
Users who like their links underlined can still turn on this option, but
extrapolating from the above, I would guess that non-underlined links are
more popular. Note that we are a very link-heavy page, so the high amount
of underlining on a page can get quite distracting. Links are reasonably
easy to distinguish from normal text when non-underlined.
Remember password:
This option needs to be distinguished from underlining, as it can also be
accessed on the login screen, not just on the preferences screen, and is
thus likely to be noticed by more people. However, I still think this
should be the default. There are users at places where they do not want
their password remembered, such as cafes and changing terminals at work.
What is the standard case and what the exception, though? My guess is that
most people log in to Wikipedia from one or two machines, and that the
browser on that machine is reasonably secure from access by others.
Other users should be security aware enough to tick off the "Remember"
checkbox during login.
Thoughts?
Regards,
Erik