On a users "User Contributions" page, can someone please modify it so
that the comments a user made to accompany the articles edit shows up?
Jonathan
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: djw(a)reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2
I think we need to have an open ended discussion about "Talk" pages and
what we could do to improve them. I see primarily the following
problems:
- It tends to be cumbersome to search for the right place to insert a
comment in a huge thread with sometimes correctly, sometimes incorrectly
indented comments.
- Many users, newbies or not, tend to quote, indent etc. in uncommon
ways. It's a bit like email in that respect: Give people too many
options to make mistakes, and they will do so.
- Edit conflicts are very likely especially in near-realtime-talk. This
is *very* distracting and one of our biggest usability issues.
Here's what I think we can do:
- Auto-merge after edit conflicts. Do a paragraph-wise comparison, merge
when paras are the same or new, trigger conflict when paras are
different. Show warning when another user has recently started editing a
page.
- Make better use of existing comment demarcation. When a user inserts a
sig --~~~ this could be used to also render a "reply to this comment"
link. This link could lead to a blank edit form, the content of which
would be automatically inserted in indented form after the comment in
question.
- Have better context-sensitive help. Our current editing screen is nice
and all, but it could use some refinements to direct users to pertinent
information.
The alternative would be to replace the talk page with threaded
discussions a la Kuro5hin/Slashdot. Individual comments should still
have all wiki capabilities, but users would not be allowed to edit other
users' comments, and there would be a clear thread structure. Also,
stuff like signing etc. would no longer be necessary.
Issues with this idea:
- editing other users' comments is sometimes desirable
- archival? perhaps thread creator and sysops could have
"archive this thread" link
- being able to write wherever you want can be good to alert users, e.g.
put important notices at the top - this requires advanced features like
"sticky" posts in a discussion forum
- should deletion of one's own comments be possible?
- revision history?
- having two different "modes" of writing can be a usability
problem, too
Weighing the different arguments against each other, I think we should
concentrate on the edit conflict issues, and perhaps try to somewhat
streamline the reply process. Having a threaded forum seems to be too
different from the existing wiki process to work well, although I am
still somewhat undecided here. The edit conflict issue is relevant to
all pages, not just talk pages.
What do you all think?
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
----- Forwarded message from Dana Hunley <threeroses(a)adelphia.net> -----
From: "Dana Hunley" <threeroses(a)adelphia.net>
Date: Sun, 15 Dec 2002 21:11:34 -0500
To: <wikidown(a)bomis.com>
Subject:
your software sucks i get on and get kicked off everyday please fix it or i will stop refering ur site
----- End forwarded message -----
Brion has taken the time to write the very necessary bot patch, which is
great. I found this in CVS in the "maintenance" directory: bot.sql --
this is an SQL file that modifies the table structure accordingly.
I would like to recommend that when we alter database structure, we
create patches of the form
patch-01-bots.sql
patch-02-recentchanges.sql
..
in a subdirectory of maintenance/ called "db-patches", and a separate
file "patches.txt" describing the nature of the patch and the date when
it was written. This way we can keep better track of which patches need
to be applied after, say, CVS updating in a few weeks. This is the way
the Scoop project does it (they also order their patches by release tag,
but we don't have any releases), and it works rather well.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
I've switched test.wikipedia.org to use InnoDB tables (the ones with
row-level locking and transactions). This requires breaking the columns
for the search index out to a separate table, since the fulltext index
is only supported on MyISAM tables. I've set up an 'innodb' branch in
the cvs which contains these changes.
Please check it out; there are probably some cases remaining where
consistency isn't maintained.
Once that's all running smoothly, we can worry about things like
commit/rollback. (There are probably all kinds of fun race conditions in
the various updates that are made on separate tables during page
creation, edit, and renaming, which we currently have no protection
for.)
-- brion vibber (brion @ pobox.com)
http://test.wikipedia.org/ contains math extension to Wikipedia.
It is possible to write math markup with <math></math>
and it will be converted to nice PNG. Markup is more or less LaTeX+AMS.
Please test it.
Some error reporting has been added.
Oh, and for translators.
The following messages should be translated:
(preference page):
"Rendering math"
"Aways render PNG"
"Try HTML first, fallback to PNG if too complex"
"Leave it as TeX (for text browsers)"
What looks like:
=== Rendering math ===
(*) Aways render PNG
( ) Try HTML first, fallback to PNG if too complex
( ) Leave it as TeX (for text browsers)
(errors)
"Failed to parse"
"unknown error"
"unknown function "
"lexing error"
"syntax error"
What looks like:
Failed to parse (syntax error): ^_^
Failed to parse (unknown function \elephant): \elephant^2 = \mouse
That's 5pm PST, 8pm EST, 1am GMT, 2am CET
Not long, but thought I'd give some slight warning for the
Wikipediholics among us... ;)
I'll be upgrading MySQL to support InnoDB tables which have row-level
locking which should help with the lag problem (actual conversion of the
tables will be done later, after I've double-checked it on
test.wikipedia.org).
Should only be down for a couple minutes.
-- brion vibber (brion @ pobox.com)
Message: 4
Date: Sat, 14 Dec 2002 06:14:24 -0800 (PST)
From: Digital Addictions Software
<digitaladdictions(a)yahoo.com>
To: wikitech-l(a)wikipedia.org
Subject: [Wikitech-l] Re: Feature Request: Bot user
accounts and/or
disable 'hide minor edits' for non-logged-in users
Reply-To: wikitech-l(a)wikipedia.org
Oh and I could run it in the bot in
middle of
the night on full speed and then turn it off during
the day, but alas I
sleep
during that time.
Ram-Man
Hi
Except your day time is other people night time. It
would annoy less some, and more others. It would also
slow down the server of other people day time. Please,
don't forget this. Thanks.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
http://www.wikipedia.org/wiki/Image:Enigma.png results in the following error:
A database query syntax error has occurred. This could be because of an
illegal search query (see Searching Wikipedia), or it may indicate a bug in
the software. The last attempted database query was: SELECT
cur_id,cur_namespace,cur_title FROM cur,brokenlinksWHERE bl_from=cur_id AND
bl_to='Image:Enigma.png' LIMIT 10 from within function "Article::getContent".
MySQL returned error "1064: You have an error in your SQL syntax near
'=cur_id AND bl_to='Image:Enigma.png' LIMIT 10' at line 1".
It looks like the space before "WHERE" is missing.
phma
