Let me know if this is the wrong place to report this.
Are the image display bugs on my third sandbox
(http://en.wikipedia.org/w/wiki.phtml?title=User:Snoyes/sandbox3) known?
1. An image may under mysterious circumstances not display with the assigned
width
2. There is some strange display of html code when using both quotes (") and
apostrophes (') in the image comment area between the double-square brackets.
Best,
Sascha Noyes
--
Please encrypt all email. Public key available from
www.pantropy.net/snoyes.asc
Right now, we support <div> tags, but not <span> tags. I can't imagine
there is a legitimate security concern for disallowing <span> tags, and
supporting them would allow CSS-correct style changing mid-sentence.
(<div> tags put their contents into a new box, like a new paragraph)
Is this the intended behavior? If not, can it be fixed by a
configuration change or is it a code issue?
- David [[User:Nohat]]
PS I posted a bug a couple days ago about edit links, and it seems to be
pretty serious. The problem is if a section is commented out in an HTML
comment (<!-- -->) , then the counters for links and the edit section
code get out of sync, and when you click to edit a section, it takes you
to the wrong section. This is very confusing if a user inadvertently
clicks an edit section link on an affected page. At the very least, a
warning about this problem should listed somewhere.
Bug page:
http://sourceforge.net/tracker/index.php?func=detail&aid=887680&group_id=34…
Example of an affected page:
http://en.wikipedia.org/wiki/Tamil_language
Try clicking the [edit] link for the "Writing system" section
At 06:22 PM 2/4/2004, you wrote:
>Guillaume Blanchard wrote:
> > There are many other criteria that can define "questionable modifications",
> > but this can handle a lot of case we run up against. Those questionable
> > modifications may be displayed in RC (for sysop or for all) with a
> different
> > mark (color, bold, italic or any visible marker). The goal is to give
>
>Could you use SpamAssassin for this? It assignes a probability that a
>message is a spam, based on how previous messages were categorized.
>Filtering based on http://en.wikipedia.org/wiki/Bayes%27_theorem
>or rather http://en.wikipedia.org/wiki/Bayesian_inference
>
>Can we dig out cases of vandalism from the "old" database table, and
>use them as training fodder for SpamAssassin?
SpamAssassin may indeed use Bayesian filtering but is primarily a heuristic
(rule based) engine. I believe you could create a heuristic engine that
would mark "likely" vandalism on the Wiki, however, just like spam, it only
starts an arms race. The spammers know about SpamAssassin, so they do
things to get around it. The next version of SpamAssassin deals with these
tricks (like word salad, for example). Then the spammers do something more
tricky. and so forth.
In the world of the Wiki, there is no economic advantage to vandalism (that
I can think of anyway) so perhaps it would not be as serious an escalation
as there is in the world of spam.
Eventually, I'm afraid that you will have to REQUIRE logging in with a user
name prior to allowing edits on the Wiki. At least that way you can undo
all changes by user XXX automatically...
-Kelly
All wikis will be locked for a while tonight to make an up to date
clone of the database so we can get it set up on the new server.
8 February 05:00 UTC == 9pm PST, midnight EST, 5am GMT, 6am CET
Please announce this wherever it seems appropriate!
I'm sorry, I don't know exactly how long this will take, but perhaps
roughly a couple of hours. Maybe less, maybe not. We'll actually switch
over to running the site on the new servers later this weekend if
nothing goes wrong; updates on the old server until then will be
replicated so there shouldn't be any data loss.
(Tech note: we'll just copy the files on the local hard disk since
there's room, then ship the copies across the continent at our leisure
once the main db's running again. This should minimize the downtime,
but they're still really big files.)
-- brion vibber (brion @ pobox.com)
Erik wrote:
>...
>Once an edit is flagged, it would just get a little extra C or X in the
>Recent changes table. The box would not appear for subsequent diffs.
>Instead it would be nice to show something like
> ________________________________________________
>| This edit has been flagged as non-vandalism by |
>| User:Foo |
> ------------------------------------------------
>
>So if someone abuses the flagging privilege, they can be dealt with in
>some way.
>...
This sounds like a great feature! But unless flagging is limited to admins, I
fear that it may be abused by a group of like-minded vandals working together
(each marking the other person's edits as non-vandalism). I also think that it
should not be limited to just vandalism but to blatant POV as well (which, IMO,
is a form of vandalism).
I check for both while on RC.
-- mav
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
I have an idea of a possible way to settle part of a dispute, which I
know in theory is possible, but I don't know if it also is in
practical terms.
What I would like to do is find the IP addresses for several people
who made changes to Wikipedia, then do an reverse lookup in order to
determine whether these people come from the same subnet. This mgiht
be convincing enough to the two people I'm working with to settle
the matter.
Is this doable?
Geoff
I have here 3 things that need to be installed in the colo. I'll be
there in about 2 hours, which means around noon Florida time.
1. SCSI RAID Card - MegaRaid SCSI 320-1LP with battery backup (neat!)
I'm a bit nervous about this, because the driver installation
instructions are very strange and un-linux-like. There's a program
called RWFLOPPY.EXE that I might have to use. What is this, 1981?
2. 1U rackmount keyboard/monitor 16 port KVM switch (nice!)
3. APC powerport, donated during our pledge drive, new in box
The installation of the SCSI RAID card will mean some downtime today
for suda (the new database server, 2U opteron), while the powerport
installation will mean a few minutes of downtime for the others.
The new facility is staffed 24 hours so, in theory anyway, we don't
need the powerport, as we can have a human do it. But adding people
to the list of authorized contacts is harder than giving people access
to the power port, so it's still worthwhile.
The power port has 8 outlets, but we have 9 machines and 10 plugs. We
therefore need to prioritize what is on the powerport.
1. suda (database server)
2. suda (database server)
3 ?
4 ?
5 ?
6 ?
7 ?
8 zwenger (mail server, right?)
The prioritization has to do with (a) liklihood of the machine
actually going down and (b) how desperately important that machine is
to the running of wikipedia.
We're going to have failover protection for the webservers and the
squids, so maybe that's it.
Remember, here's the chain of events that has to happen before we
experience major regret about not having the right thing on the APC:
1. A machine has to die in such a way that a hard boot is necessary
2. The 24x7 staff at the colo has all vanished
3. I am out of town and can't drive over there (but I guess if there is
no staff there, I can't get in anyway)
4. The machine in question is not on the power port.
We could experience minor regret, though, if the machine isn't on the
power port and someone has to call a human to reboot it, which takes 5
minutes instead of 5 seconds.
--Jimbo
I agree with Erik's idea.
And on Recent Changes in the same way we have "hide logged in users" (&hideliu=1) which only lists changes by anonymous users, we could have "hide flagged edits" (&hideflagged=1) (or some other wording) to only list edits which have not yet been flagged as being non-vandalism by someone else. Using both in combination (&hideliu=1&hideflagged=1) would work well, and would be like a collaborative "check for vandalism" to-do list. With a hundred people, say, checking for vandalism, each of them would only have to check 1% of the edits, instead of 100% as it is now. And they could get back to spending more time authoring their own edits.
And for logged in users who are vandalizing, it is important that the person who did the edit cannot also mark it as flagged. Anyone who flags vandalism as non-vandalism would be considered liable for the change themselves. e.g. to catch a person who anonymously vandalizes, them logs on and flags their edit as non-vandalism. (Although it would help if the software could detect that the IP address is still the same, even though they are logged in, and hence prevent the flagging in the first place.)
Alternative suggestion for UI is a single link or button on the diff screen labeled:
Flag as not vandalism
or just a single word like
endorse, concur, ratify, approve, countersign, corroborate, warrant, authenticate, verify or equivalent
my thesaurus got a bit of a workout :)
which then changes to Verified by Foo
And Recent Changes would have "hide verified edits" (&hideverified=1) or whatever. "Flag" is much too generic a term.
Michael Richards
-----Original Message-----
From: wikitech-l-bounces(a)Wikipedia.org
[mailto:wikitech-l-bounces@Wikipedia.org]On Behalf Of Erik Moeller
Sent: Wednesday, February 04, 2004 4:33 PM
To: wikitech-l(a)wikipedia.org
Subject: Re: [Wikitech-l] Mark questionable modifications
Guillaume-
> Some wikipedians would like to have an automatic detection of "questionable
> modifications". Questionable modifications, mean, modifications that have a
> great chance to be a rookie's test or a vandalism. This automatic detection
> may be done by check, for example:
I'm against that particular solution because I think it would produce too
much visual clutter and false positives. However, one thing that I would
like to see, and will implement myself sooner or later if nobody else does
it, is a way to quickly "flag" edits as being OK, that is, non-vandalism.
Implementation wise, it would be a little box on the diff screen:
________________________________
[ I have checked this edit, |
| and it is not [[vandalism]]. |
| _____ _______ |
| | OK! | | Edit! | |
| ----- ------- |
--------------------------------
Possibly only for edits made by anonymous users or those with no user
page.
Once an edit is flagged, it would just get a little extra C or X in the
Recent changes table. The box would not appear for subsequent diffs.
Instead it would be nice to show something like
________________________________________________
| This edit has been flagged as non-vandalism by |
| User:Foo |
------------------------------------------------
So if someone abuses the flagging privilege, they can be dealt with in
some way.
The point is, of course, to avoid having to keep diffing the same pages
for vandalism. It wouldn't work for new pages because those have no diffs,
but new pages should probably be looked at by multiple people anyway.
Regards,
Erik
Hi,
I'm sorry for reporting this bug here, and not on SourceForge, but since
the SourceForge site hasn't gotten any better... anyway:
There appears to be a new feature on the history page of an article
whereby we can click two checkboxes and then it will create a diff
between the two versions we selected.
Clicking on any checkbox first and then clicking on the checkbox for the
most recent edit, however, yields the same diff as the top "last" link,
and not a diff between the two selected revisions. Any other combination
appears to work correctly.
In the JavaScript, it says:
if(v2 > v1 && v1 != 0){ tmp = v1; v1 = v2; v2 = tmp; }
My guess would be that it would work if you change this to:
if((v2 > v1 && v1 != 0) || v2 == 0){ tmp = v1; v1 = v2; v2 = tmp; }
On a slightly related note: Who wrote this feature? Where was this
feature discussed? I didn't see an announcement along with invitation to
test.
On an even slightlier related note: What do I need to do to get the
change I mentioned in the thread titled "Suggested change" up on
test.wikipedia.org?
Thanks,
Timwi
