> Is this a Bug or intended behaviour?
Neither, really. It's inevitable behavior based on the
database layout, and would require a lot of work to change.
Write it up as a feature request, but it won't be high
priority.
> A dumb/long list is nice because I can use my browser's text
> search on the titles listed in it; but the need for this would
> largely go away if I could search in Wikipedia: and User:.
That's coming soon.
Hello,
at 19:04 server time 206.148.76.193 created a new article
Arnold Schoenberg. On Recent Changes it was marked with
a bold N as a new article.
Since the article had no markup, I edited it and saved it.
(19:12 server time). On Recent Changes, there is no "N"
anymore in front of the 19:04 change. On special:New_Pages
Arnold Schoenberg is not listed any more as a new article.
Is this a Bug or intended behaviour?
Regards,
JeLuF
> I think the problem with this markup is that you only have
> an "open"-tag and can't nest them.
You can, I just didn't show any examples of that. What I want to
do is have {xx some text} produce a SPAN, and
{xx
Some text
}
Produce a DIV, either or both of which can be nested if
necessary (though it should almost never be). The shortcut
syntax {xx} just means "apply the class or ID to whatever
the next thing you encounter is", which may be a single word
of text, or a table, or a cell, or a list, or a header....
> How would you combine it, for example, to have a small label
> below the floating-right image?
Put 'em in a DIV:
{right
[[image:baldeagle.jpg]]<br>
Caption
}
We'll have to do something about <br>, and we also need a way
to specify table captions and headers (you could then put the
image in a table with a caption if you preferred).
>Make it look wiki, I think this is similar to
>the way Jan Hidders proposed:
>
>>> [[image:spottedowl.jpg|Spotted owl]] >>
Right now that sets the ALT text.
JeLuF wrote:
>One of the tables I like in wikipedia is this one:
>http://www.wikipedia.com/wiki/Beryllium
>
>I think this is a very apropriate way to present the
information,
>some kind of fact sheet. tarquin's proposal needs to
get some
>kind of markup to mark the labels (which are then
rastered with
>background color according to selected skin).
Thank you. Although I think that particular
implementation is a bit fat -- it takes up nearly half
of the text area on low res screens. I am in fact far
more proud of the taxonomy tables that I helped
develop -- which use nested tables with invisible
borders, have embedded images, heading fill color and
a list in the final cell to make adding taxon group
members easy
(see: http://www.wikipedia.com/wiki/Typical_owl for an
example)
But here is the rub; any wiki syntax that is enacted
will need to have nested tables, the ability to have
embedded images, lists and heading color fill or I
won't be able to use or promote them for the element
articles, taxonomy tables or even the country tables
(I'm involved with all three projects and considering
helping with the US Presidents tables). The colors for
the elements and taxonomy tables have specific
meanings associated with them and the nested tables
are needed to present different types of information
(I guess this can be replicated without nesting, but
in HTML at least that requires a /more/ complicated
table).
In my view then, the goal of any wiki table mark-up
should be to recreate the typical owl table in the
most easy to learn and code wiki markup possible. The
details on how to do this are not as important to me
as the results.
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
Jimbo wrote:
>1. Not-logged-in -- you can edit pages, etc.,
>but you're penalized in some minor respects.
>The reason for this is that it's more productive
>for people to choose a consistent identity,
>rather than possibly having a different ip
>number every day. And if you remember '24',
>it's a pain to have to refer to someone by a number.
>
>2. Logged-in -- you can do anything that's not
>'royally destructive', i.e. anything that's not
>irreversible, EXCEPT edit some protected pages.
>Again, we like to keep the number of protected
>pages to a low level to just dissuade some of
>the more annoying and lame vandalism attempts,
>like putting spurting penis pictures on the homepage.
>
>3. Old-hand/sysop -- should be granted in
>an apolitical manner based on being essentially
>"legit" -- sysops should be able to do a tiny
>number of destructive (irreversible) things,
>IF we need to have those abilities for some
>reason. (For example, some kinds of deletes do
>need to be irreversible for legal reasons.)
>This status should be granted more or less
>automatically, and whatever privileges it give
>should, by strong social custom, NEVER be used
>"in anger", i.e. to "pull rank to win an argument".
>There are only technical reasons to even have
>such a status.
Perhaps I should expose my ulterior motive -- I want
to see an 'old hand' status established so that a
framework will be in place so that we can begin the
process of phasing-out "sysop" status -- maybe
entirely. This would be done by porting function after
function to 'old hands' as these functions become non-
irreversible and coded procedures are established to
handle these functions in the wiki way. Let me
explain:
The move feature used to be buggy, so it was limited
to a select few people for practical reasons. It isn't
buggy now so I would like to see this feature be
usable by anyone with an account older than 30 days
and who has edited more than 30 pages in the article
namespace (LDCs idea of having a valid email address
seems like a good additional requirement). The only
reason to have the 30/30 (or whatever) requirement is
because there is a bit of a learning curve about how
to use Wikipedia and what our policies and guidelines
are with article naming. And if somebody has been
around for more than 30 days and has edited more than
30 articles without running into serious trouble I
think it is reasonable to also allow them to edit the
main page and any policy pages that are protected
(actual policy changes would have to be done through
this list or its successor though).
Blocking IPs could eventually be ported to 'old hand'
too. Here is one possible way to do that: There could
be a warning feature, similar to some instant
messaging programs, where if a person is warned by
several 'old hands' within a certain amount of time
they will be blocked from editing for an amount of
time commensurate with the number and frequency of
warnings (there could be anti-warning function too to
negate unfair warnings -- all this should also be
logged). In this way Wikipedia will be watched 24
hours a day instead of being exposed at certain times
of day when sysops are not around. As it is, one sysop
blocks an IP which is highly personal to the person
being blocked -- thus potentially dangerous if the
blocked person is deranged and motivated. Even though
I don't use my real name in Wikipedia, I use it here.
It would be easy for any deranged maniac to find out
where I work starting with that information. I don't
like this situation.
Deletion, protection and promotion/demotion to from
user/'old hand' status could similarly be eventually
ported as these features become non-irreversible
and/or methods are developed for their collective use.
The above is just a set of initial ideas on how things
/might/ proceed. The details can be worked out for
each sysop feature as it is ported to 'old hands'.
In this way Wikipedia would be self-healing and
self-maintaining without having to have users of rare
and special rank.
I don't like being a cop and I don't like the fact
that we even have a quasi-Cabal -- that's why I want
to phase it out by eventually allowing the majority of
active, logged-in users to collectively perform
sysop-like functions (spreading the power around). But
this should be a slow process so that we can develop
procedures on how to perform sysop functions in a more
open and dare I say democratic manor that will not
hamper our success in the wiki way.
--mav
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
With all the talk about extending the Wiki-syntax, I'd like to post this
extension I proposed earlier on SourceForge
(http://sourceforge.net/tracker/index.php?func=detail&aid=586885&group_id=34…)
:
"To avoid piping, maybe we could use some features like the [[plural]]s
thing, which is rendered as [[plural|plurals]].
I propose:
* [[English] language]] --> [[English language|English]]
* [[George W. [Bush]] --> [[George W. Bush|Bush]]
the [ and ] are just an idea, I don't really care if another character
would be used."
I got positive reactions from Brion Vibber and Toby Bartels, who
proposed the additional extension of [[George ]W. [Bush]] --> [[George
Bush]].
Jeroen Heijmans
> What happens if somebody inserts a new table/figure?
> You renumber? And the complexity step from doing no formatting
> to doing a little formatting becomes relatively big.
That's why I'm throwing the suggestion out there--to get feedback.
> Couldn't we just try a little harder to come up with a WikiWiki
> markup? There is already table markup that does column-spanning,
> border selection and alignment of text in cells.
I really hate MoinMoin syntax. It's every bit as ugly and complex as
HTML, without the benefits.
> << float left <<
> >> float right >>
> >> center <<
> for tables and figures?
Not bad, but "<" and ">" are already something of a hassle; perhaps
less if HTML goes away.
But the upshot of my proposal is that there already exists a
technology for separating content and visual styling, and that we
should do exactly that. Style is important, and we need to be able
to let people create attractive articles that take advantage of the
technology, so we need /more/ style elements. But content and style
really are separate things, and the more wikisyntax we create for the
purpose of style, the more it becomes a bloated, non-standard new
language that does only half the job. I disagree with Toby about
HTML, but I agree with him that just reinventing the wheel with a new
non-standard language isn't a solution. CSS gives us an opportunity
to really do it right: let the gurus tweak the style as much as they
want, while still letting the regular folk see the content unobscured
by megabytes of markup.
>And do we really need colored text?
Absolutely. It's a function of the technology we have, and we should
take advantage of it where it's useful (without overdoing it, of
course). See [[Poker]], for example. Those articles would be much
less readable and useful without red text and suit symbols.
Let for formally solicit proposals: folks, give me a clean,
unobtrusive, user interface for (1) specifying spans and divs in
wikitext with class and/or id; (2) attaching a stylesheet to a page,
and being able to edit it.
><wiki table, center, thin line>
>|{light blue} ^ '''Mailing label''' ^|/
>|Name: |John Doe |/
>|Address: |2000 Main Street |/
>| Postal Code: |123456 |/
></wiki table>
I don't like it at all. Tarquin still has the best idea so far--it
just needs to be fleshed out a bit.