>How about [*[image:...]] and [[image:...]*] ? But I'm
open to any suggestion
>that reduces the html tags and keeps the syntax
intuitive.
>
>Kurt
Hum, I like the concept. How about something like
^[[image:...]], [[image:...]]^ and ^[[image:...]]^ for
respectively, left, right and center. The asterisk is
already used for something else in wiki markup.
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
>But I still don't like tables
>--
>Karen AKA Kajikit
Believe it or not, I really don�t care much for them
either --- I can see how tables could be downright
frightening to newbies hitting edit. However, tables
are often necessary, sometimes vital, to presenting
data in a logical and easy to follow manor. This is
especially true for the elements articles and for
presenting taxonomic data in organism articles. So I
view tables as being a necessary evil to get things
done.
With that said�.
I have recently submitted a feature request for a
<wiki table> syntax that would greatly simplify table
markup and not be intimidating to newbies.
Please add additional ideas to the sourceforge
tracker.
http://sourceforge.net/tracker/index.php?func=detail&aid=584459&group_id=34…
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
>To re-use an earlier idea of mine: There could be a
namespace "thumb:"
>(or thumbnail or preview or ...), which refers to the
same files as
>"image:" does, but:
>* It has a fixed width (say, 150 pixel, or "15%" or
something)
>* It could have "special effects", like aligning it
to the right, with
>the text floating around it
>* [[thumb:xyz.png|text]] would display the
thumbnailed image, with
>"text" below it
>* It would link to the large image, maybe with the
description from the
>image: namespace
Oh please no! Forcing images to downsize like that
often results in hideous thumbnails and if I read you
right, will also force browsers to download the
full-sized image just the see the thumbnail. This
might work if the server automatically created a new
image at a certain pixel width and then linked that to
the larger one (in standard 'thumbnail', �click image
for larger version� format. But forcing a 400 pixel
wide image into a thumbnail that is 150 pixels wide is
a bad idea (again, if I read you right).
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
>then LDC wrote:
>>There's two issues there: as for upload privileges,
those in favor
>>of restricting them to logged in users make a good
case, so I'll make
>>that happen soon.
>>
>>The second issue is should the Wikis share uploads.
I'm of the
>There is a third issue, which we saw in spades on the
Phase II
>software: once someone is logged in, we will no
longer see that person's IP and
>therefore will have no way to block that person--and
there will most
>certainly be people who log in solely to upload files
that should not be
>uploaded, and who will deserve to be blocked.
>
>This problem could be solved by reinstating the
UseModWiki feature of
>revealing the IP of someone who is logged in simply
by hovering the
>mouse over the username. It worked quite well, even
on my dynamic IP--each
>time I logged out and back in whatever I did on
Recent Changes would
>reflect the IP I had assigned me when I did it. I
would love to see the
>feature returned.
>
>cheers,
>
>kq
Better idea; Reinstate a type of �trusted hand� status
and name it something like �old hand�. Old hands would
be users that have been around for at least 30 days
and have made at least 30 edits (status would be
automatically granted by the software when those two
requirements are met � there could be more than a 30
edit requirement if that is deemed necessary). Then
have the software only allow old hands, sysops and
developers the ability to use the upload utility. This
would be grandfathered in for current users.
I would further suggest that old hands would also have
the ability to edit protected pages and use the
administrative move feature (I don�t know if we should
restrict the possible �vote for� feature to old hands
though). Then the only special privileges sysops would
have would be pure meta functions; blocking IPs,
manually setting user status, deleting pages and
protecting/unprotecting pages.
Having a 30 day/30 edit requirement ensures that users
are exposed to wikipedia long enough to become
familiar with our naming conventions, policies and
guidelines. Whether they actually do pay attention is
up to them. If needed their status could be reset back
to just �user� by a sysop. Alternatively, sysops
should be encouraged to upgrade the user status of any
user that �gets it� early.
I see no reason why we should prevent long time users
from editing protected pages and moving pages and
their history. I also don�t see any need to /ever/
have to block the IP of a long-time logged-in user.
Why then would this information be displayed, even to
a select few? Furthermore, how is it going to be
possible to associate a user with an IP on the blocked
page? Even though I trust this won�t be abused, the
existence of the possibility of abuse could be
chilling to some.
Allowing sysops the ability to block anyone, anytime
might be viewed by some as strengthening the perceived
quasi-cabal we have now into a real one. I have mixed
feelings on whether to allow the display of IPs of
non-�old hand� users though�This might still be a good
idea, but then to see the IP of an �old hand� all a
sysop would have to do is reset the user status of the
�old hand� to just �user�. To prevent this type of
activity from going unnoticed logs should be made.
Besides, there are only about a dozen active sysops
and the protected pages need to have more maintainers
(It�s tiring to constantly to have to review and take
requests on what to put on or edit on protected pages
by well trusted long-time users � I would prefer to
just edit their edits in the wiki way). Having an �old
hand� status would also help a great deal with the
upload issue � those that want to use wikipedia as
just a server are going to have to ; 1) create an
account, 2) log-in, 3) make 30 valid edits and 4) wait
30 days.
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
excellent. Sorry for mentioning a problem you had already considered, and mostly solved. :-)
kq
LDC wrote:
>The new software is capable of blocking by IP or by login name.
>There just aren't yet any features in the software to add to the
>block list by name, or to discover the IP of a logged in user.
>Those will need to be added at some point; I'll add that to the
>tracker at high priority.
That would be an easy way to do it, but it doesn't take into account the wasted download time (a big consideration for people on dialup, which is probably still most people on wikipedia). It would be faster to have the two files separate so the thumb can display quickly, and people have the option to see the larger pic but are not forced to.
cheers,
kq
Magnus wrote:
>A mode that might work:
>* Default is "browser loads large image, then downsizes it"
>* The exceprion for this is server-side, when the article contains
>[[thumb:xyz.jpg]] *and* there is a "t_xyz.jpg" file.
>
>That would guarantee the thumb: thing works, and enable fast loading
>/if/ there's a thumbnail file available.
Guys, I started working on an "Image use policy" for wikipedia. I'd
appreciate it if you could take a look and flesh it out and start
some discussion--I'm a techie, so I put in lots of techie details,
but I'm sure many of you have many other things you'd like to say
there. It's linked from the policy page.
Hi.
Suggestion. Some background:
I notice that some articles on Wikipedia, while having an air of NPOV (by using
terse language, and lots of facts (or factoids)) are in fact rather politically
tainted.
This is especially the case in left/right issues, middle east issues and in
regards to nationalities (German/Polish borders, etc.).
This is probably unavoidable, and the way to solve it is of course to include
everyone's viewpoint as _viewpoints_, and only let what everyone agrees on be
"facts" of an article.
However, this is _a lot_ of work, for any given article. You have to rewrite
sections of the article (or spread it out through several articles), you have
to go several rounds with people on both sides of the contested issue, and you
have to keep a close watch on the article for quite a while.
Actual suggestion:
Can we add a "contested flag" or something? That alerts the reader to the
opinion (of any given author) that the content of the article is or might be
tainted? A lot of the middle east articles popping up all over could then be
tagged as not entirely reliable until everyone have had their say.
If not as a specific feature, then at least as a convention on how to mark an
article as controversial, for instance with an agreed upon keyword early in the
article.
I love Wikipedia, but this problem always gives me a bad feeling, and makes we
feel like giving up. Something like this would help to civilize disagreements,
and thereby divert a lot of energy away from them, and over to other articles.
What do you say?
-- Daniel
> There is a third issue, which we saw in spades on the Phase II
> software: once someone is logged in, we will no longer see that
> person's IP and therefore will have no way to block that
> person--and there will most certainly be people who log in
> solely to upload files that should not be uploaded, and who
> will deserve to be blocked.
The new software is capable of blocking by IP or by login name.
There just aren't yet any features in the software to add to the
block list by name, or to discover the IP of a logged in user.
Those will need to be added at some point; I'll add that to the
tracker at high priority.