On Monday 20 January 2003 04:00 am, Brion Vibber wrote:
> That is *not* grounds for reverting the changes made, particularly
> without explanation. It wouldn't have been that hard to remove the
> whitespace and note the problem in the talk page, would it?
There were hundreds of lines of whitespace, removing it without resorting to a
revert would have taken at least a half an hour and probably longer.
But yes, I should have explained in as nice a way as possible, just why I did
the revert on the talk page. For that I am sorry.
--mav
For several months I recieve on the lists Intliwiki-l and Wikitech-l
spam almost every day.
see also
http://www.wikipedia.org/pipermail/wikitech-l/2002-December/001719.html
Those spams always come by the old posting adress of the lists, wikitech-
l(a)nupedia.com and intlwiki-l(a)nupedia.com
Can the forward be removed?
--
Contact: giskart AT wikipedia.be
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be
On Sunday 19 January 2003 04:00 am, wikitech-l-request(a)wikipedia.org wrote:
> As a conclusion
> 1. I can't do any revert back, or it will lose the new
> stuff
> 2. I lost my time yesterday
> 3. I can't edit that page again, without breaking
> things up, or making some stuff disappear. In other
> words, either I am a vandal (if I edit) or I am
> censored (If I don't)
> 4. What I did was utterly misconsidered, and abused by
> Mav, who didnot even "try" to understand why I was
> doing it.
>
> So, I am very upset
I am sorry that I made you upset, but I looked at the diffs - all that was
done was breaking off a couple of proposals onto separate pages. Was there
other editing that you did? If there was I didn't see it.
The revert was needed due to the fact that your browser (I know it wasn't you
on purpose) inserted HUGE amounts of whitespace inbetween each and every
line. See the revert diff here
http://meta.wikipedia.org/w/wiki.phtml?title=What_to_do_with_www.wikipedia.…
notice all the extra spacing that was deleted and also the two proposals that
were pasted back-in.
I would have done what I normally do in these cases and perform version
management but the proposals you moved were still very relevant to the
current discussion. It will take only a few minutes to delete these proposals
and provide links to the new pages you created.
So even though I still don't think it is such a good idea, I've already done
this. Now look at this diff
http://meta.wikipedia.org/w/wiki.phtml?title=What_to_do_with_www.wikipedia.…
the only difference between your last version and the newest one is all the
white space placed into your version.
--Daniel Mayer (aka mav)
>Last week I was a fascist, this week I am a vandal,
>next week ???
>
>Regards
Nobody is calling you a vandal - the only issue here is that your choice of
browser/platform and the Wikipedia software for some reason try to kill each
other.
-- mav
Hi list,
Two issues are rised: improving text edit box
and JavaScript to help wiping it out.
While I was working on langauge php file for Polish,
I decided to enhance the text
Put your text for the new page here.
The rationale was: the imperative tone could provoke
trolls to give a try to they creativity
and vandals to express they agression.
I've changed the text to sth that could be translated
to English as:
There is no article on that subject yet.
In this field you can enter it's first fragment.
If this wasn't your intention just press the Back button.
A bit of comment - the only valid interpretation... ;)
It's a small guide for the "tresspasser"
- first line explains the situation,
- second explains and encourages editing
- the last one clears the confusion that perhaps occured
in the "tresspassers" mind (that's _the_ "guard")
And the ratio of "light" acts of vandalism (since on Polish
Wikipedia there are no such "heavy" acts as on English)
dropped down from about 2-3 unwanted new articles per day
to 1 such article per week! (I'm still curious if that was
the reason for unwanted edits... :-)
The change provoked some users to add a kind of method
helping in wiping out the default text
- some of them are working on X-Windows - after copying an earlier
prepared article to the clipboard they mark the default text
of the textarea and unfortunately the article in the clipboard
is replaced by rubish (many forget about wiping out the box
at first)
- other would be pleased to substitute 3 step combination
as well (like eg. <leftclik>, <ctrl-a>, <del>)
with one click.
"One click is enough for all of us" as some time ago Sting sang... :-)
We propose to add the following scripts to TEXTAREA attributes
onfocus="if(this.value=='.....') {this.value='';}"
onblur="if(this.value=='') {this.value='.....';}"
where five dots should be replace by the text
returned by wfMsg("newarticletext")
this text should be posted between
<TEXTAREA> and </TEXTAREA> tags as well.
I don't know if that works on most browsers so another option
in user preferences would be a necessity.
No matter how long the text, such script makes the work
more comfortable.
Regards
Youandme
----------------------------------------------------------------------
Nowa MOTORYZACJA w portalu INTERIA.PL: aktualnosci, nowe auta, testy,
tuning, ceny, galerie, motosport... >>> http://link.interia.pl/f16bb
I decided to move this discussion from the village pump to here.
|The result of <math> tags is ugly. The pictures are too big, and
|the ALT text shows the awful-looking raw markup when people move their
|mouse over it in most browsers. Any hope of some more user preferences
|in this area, hopefully with sensible defaults? -- [[User:Tim
|Starling|Tim Starling]]
|
|:I tend to agree on the size; font sizes can be manually bumped up on
|equations that really need it. (But the PNGs are limited to fixed
|pixel sizes, which does not have a guaranteed relation to a readable
|font size for any given user.) What other improvements would you
|suggest? I'm afraid "not ugly" and "more sensible" aren't things we
|can code. ;) Eventually output as inline [[MathML]] is hoped for, but
|few browsers currently support it and we would need to beef up our
|wiki->HTML translator to produce proper XHTML. --[[User:Brion
|VIBBER|Brion]] 06:42 Jan 9, 2003 (UTC)
By "user preferences with sensible defaults", I just meant two more items in
the user preferences:
* TeX formulas display raw markup in ALT text
* TeX formula size
IMHO the first one should be off, and the second should line up with the
most common browser configuration. Whoever made [[Image:del.gif]] seemed to
be on the right track. As for other improvements: perhaps you could find
some way to convert most formulas to ASCII art and use that for the ALT
text. Maple can do it, why not Wikipedia? ;) That said, I think you guys
have more pressing matters. I made a feature suggestion on SourceForge a few
weeks ago requiring only a few extra lines of code, and AFAIK it hasn't been
touched.
I've heard rumours you can get JavaScript to tell you the font size in
pixels, but I'm not sure if they're true. Barring that, half-blind people
can probably find their way to the preferences and enlarge the formulas.
MathML sounds nice, although I can't stand messages in articles saying "if
the formulas on this page aren't displaying correctly, you need to get a
better browser", e.g. in [[Table of mathematical symbols]]. As long as we
don't get any more of them, I'll be happy.
-- Tim Starling.
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*
http://join.msn.com/?page=features/virus
Here's how I think the FileReplacement proposal
http://www.wikipedia.org/pipermail/wikipedia-l/2003-January/008537.htmlhttp://www.usemod.com/cgi-bin/mb.pl?FileReplacement
should be implemented (Jimbo and Brion agreed that it would be a good
idea):
1) Add a copy_of int(8) column to the CUR table. If blank or 0, the
article is not a copy. This saves us the trouble of creating a dozen
Copy/Copy talk namespaces.
2) Change the "Protect this page" link to a more general "Protection
settings" special page, looking roughly like this:
Protection settings
-------------------
[*] Page is not protected
[ ] Only copy is editable. Page is replaced with copy
[*] [ ] minutes after the last edit
[ ] manually
[Save]
(The timed auto-replacement might cause problems especially for less
active wikis. How we set the policy is a matter for wikipedia-l.)
The time (null or 0 for unprotected, -1 for manual replacement,
otherwise number of minutes after which article is replaced) could be
stored in the cur_restrictions field of the cur table.
2) Once the page is protected this way, copy page contents to a separate
page with the title appended by "(COPY)" and is_copy set to the
referenced article ID. If there is already a COPY, copy it to the OLD
table first.
3) Now we need a way to automatically do the following:
1) start OR reset a timer when someone edits the page
2) replace the article with the COPY once the timer has elapsed.
I'm a bit clueless as to whether there is a good Apache/PHP-based
solution for such a persistent timer, cron seems like a bad choice
(makes the whole thing harder to maintain). The way I would do it is as
follows:
Create a new action table:
action_type page_id action_time
When someone edits a COPY and the protection is not set to manual, set
action_type=1 (copy) and action_time=<current server time> + <copy time
period>.
In wiki.phtml, we have two lines
#
$wgOut->output();
foreach ( $wgDeferredUpdateList as $up ) { $up->doUpdate(); }
#
Between these lines we could insert a function call that checks if there
is anything in the ACTION table and if so, picks a random row (or all
rows, not sure about the load this would cause), creates a new Update
object for that row and adds it to the deferred update list. That way we
would regularly replace the original pages with their copies. Once the
page has been copied, the row is removed from the ACTION table.
User interface
--------------
>From an UI perspective, we would add an "Edit copy" link under the
"Protected page" text. There should also be some dynamically generated
explanatory text on the COPY page:
"This is a copy of $1."
+
"This copy is different from the current revision of [[$2]]. It will
automatically replace it at $3 unless someone else edits it, in which
case the timer is reset to $4 minutes."
OR
"This copy is identical to the current revision of [[$2]]. If it is
edited, it will automatically replace it $4 hours later."
Sysops should also be shown a "Use this revision" link to execute the
copy action immediately.
Discussion
----------
I would be especially interested in feedback on
- "Copy:/Copy talk:/User copy:/User copy talk:..." namespaces vs.
copy_of column vs. ???
- Timed action execution: other strategies; always check all rows of the
table?
As always, I am happy if someone else adds this to their todo list,
otherwise I'll add it to mine.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
The folks at ZOPE have come up with a pretty damn good idea to support
external editors in all browsers. (Right now we have to use the
<textarea> or copy&paste, the latter of which is horribly broken in
Linux-Mozilla.) It's at
http://www.zope.org/Members/jimbag/ZopeEDIT
What they basically do is generate a x-zope-edit MIME type file, which
contains the data and some metadata. This MIME type has to be associated
with the provided "helper application" by the user. The helper app
(written in Python) launches the editor and, if the file has changed
after the editor is closed, uploads it to the server.
We might implement the same. I suggest the following strategy:
* Should be a user preference with prominent link to help page
explaining setup.
* Use existing "Edit this page" link to call external editor
immediately, so that there's no added overhead
* have some header in the generated file like
<header>
wpMinorEdit=0
wpWatchthis=0
wpSummary=""
</header>
so that we don't miss any other information in the form. Alternatively,
let the helper app provide some user interface to do this.
* Once the file is closed, submit it directly and transparently to the
server. The user just has to reload the page and should see his changes
immediately.
* Biggest problem: In case of edit conflicts, we need to send the helper
app a smart file, preferably with CVS-style syntax. Alternatively,
instead of submitting the file directly to the server, we could launch a
browser window with the contents in preview mode. This is somewhat less
user friendly though, especially if we cannot control how the window is
opened.
In any case, this is an absolute killer feature, especially for power
users. Any volunteers for implementation? Otherwise I'll put it in my
(already long) to do list. (Right now I'm working on talk pages for
anons.)
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
The Dutch misspellings page seems to have gone crazy, showing for many words
not only the pages with mis-spelled words, but also the pages where the
word or part of it is spelled correctly. For example, the second misspelling on
http://nl.wikipedia.org/w/wiki.phtml?title=Speciaal:Maintenance&subfunction…
is 'adfundum', being a mis-spelling of 'ad fundum'. There are 18 pages there,
but those are actually pages with 'ad' rather than 'ad fundum'. What is going
on? Is there a technical error or is there something wrong with our
[[Wikipedia:Veel voorkomende spelfouten]]?
Andre Engels
See subject, especially important on pages like [[Main Page]] and
[[Wikipedia:Sandbox]]. Could someone familiar with our paging stuff code
that in?
Regards,
Erik