I have updated the improved (?) RC at test.wikipedia.org. These are new:
* "total diff" for a diff of all changes that happened on an article today
* correct diff from each version to current version
* correct diff from each version to prior version
* direct link to the old version
The "history" link for multiple edits is now in "changes"; like it used
to be, a long time ago, in a software far, far away ;-)
Please go and test it so I can implement it as a user option in the CVS.
Magnus
>And third thing:
>Could we make it an official rule that no change in markup will
>be even considered without considering how would it affect CJK and
>right-to-left languages ?
I'd never thought specifically about that, but I suppose you're right. I
don't know jack about CJK or Hebrew or anything other than English (and a
wee bit o' French), so I wouldn't really know how to be sympathetic to
issues raised by those languages (until someone educates me on the topic, at
least).
In any case, I would agree. The markup should be comfortable for all
languages.
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&…http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_virusprote…
It appears Hotmail may have messed up the text file I attached to the
original email. Stupid Hotmail. My server's down, so I'm stuck with
Hotmail temporarily. I can't wait to be back home with pine and vi.
In any case, if Wikitax.txt looks all sorts o' messed up, with lines wrapped
unintelligibly, just head over to:
http://meta.wikipedia.org/wiki/Wikitax
Okay, I'm done now,
Derek
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
I've been workin' on a plaintext markup syntax for the purpose of providing
rich
formatting capabilities in article submission to laypeople. A syntax
similar to
the variants used in wikies, but much more consistent, much more coherent,
and
(I would say) much more intelligently designed. I'll start implementing the
begins of logic and regular expressions for parsing the syntax very soon. I
just want to get some preliminary feedback on what I've come up with thus
far.
There is a lot about Wikitax where I'm still not set in stone, or where I'm
questioning myself, or where I just haven't thought much about how to solve
that
particular problem. I could use other minds in helpin' to flesh out the
final
stages of Wikitax. Anybody wanna take a look and offer ideas, suggestions,
additions, etc.? I've put quite a lot of thought into the syntax, and why
things should be the way they are. Hopefully it's pretty obvious to
everybody,
but I would really appreciate input and help. I figure the more minds that
attack this problem, the better the solution will be.
Out of all the wiki syntaxes, I enjoy Wikipedia's syntax the most. I
remember
the first time I came across a WikiWikiWeb. The early syntax was just shit.
And most wikies still have really crappy syntax. Even though Wikipedia has
evolved the syntax in a number of nice ways, it still feels lacking in many
areas. It would also be nice to have a specification to standardize
plaintext
markups: a syntax so consistant, other projects will pick it up and use it.
I started work on this because I'm doing a lot of development on a second
generation community-developed/organized open publishing content management
system for Independent Media Centers. The particular codebase I'm working
on is
going to be a sort of Wikipedia + scoop + multimedia galleries/archives +
weblogs + newswire + Kronolith + etc.--all tightly rolled into one nice,
easy-to-use, and consistent package.
You'll find an attached text/plain, Wikitax.txt. The preliminary
specification
is contained therein.
If you're sincere about contributing, see also:
<http://meta.wikipedia.org/wiki/Wikitax>
Peace out, g-money homey lokes,
Derek
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 3 months FREE*.
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=74…http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_stopmoresp…
>Two things:
>* openings and closings of tags should not be the same ('' and ''),
> and they should not prefix-overlap (like '' and ''').
> You're just asking for troubles by introducing more such
> tags.
Well, the whole single quotes syntax for emphasis is something I've haven't
liked much from the get-go. But are you also saying that '!!...!!' and
'//...//' and others are bad choices? What are some good, simple
alternatives? I tend to think that if the wiki syntax is going to be more
than something simple like '!!' or '==', we might as well forget about a
special wiki syntax, and just have people use the basic HTML markup.
But I see what you mean... Maybe something similar to [!bold!], [/italic/],
[=monospace=], [-strike-], etc., for text formatting and other similar tags?
Or {!bold!}, |!bold!|, (!bold!), `!bold!`, ~!bold!~, etc. Hell, I dunno.
Anyways, that's why I came to this list with these issues. *smile*
>* don't do it with regular expresions. Be a real man and write
> LALR syntax. It will be order of magnitude faster, much easier
> to change, and correct (current wikipedia parser fails under some
> more complex cases) that way.
Okay. *grin* I was just thinkin' regexes, 'cause I'm familiar enough with
'em. And because I'd know how to distinguish between '//' in a URL and '//'
in italicizing words, or '!!' in making stuff bold and '!!' at the end of a
sentence, etc. But I'll definately check into LALR. I just love learnin'
new crap.
Thanks for the input, yo.
Derek
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&…http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_virusprote…
TeX support done.
Code is on http://test.wikipedia.org/
Changes since last version posted to wikitech-l:
* texvc judges HTML to be either conservative (renders on most browsers, likely to look good)
or liberal (renders on recent Mozilla and probably on other new browsers, should be readable,
but no warrancy about how will it look like)
* boolean math_conservative column added to math table
* There are 4 options in preferences:
* Always PNG
* Conservative HTML or else PNG (default)
* Any HTML or else PNG
* Leave as Pseudo-TeX (for text browsers mostly)
Thanks to this <math> can be used for both inline (which will usually end as HTML)
and displayed (which will usually end as PNG) math.
* HTML does italics right, and correctly supports \mathit and \mathrm
* Support for other formating options removed in HTML
(but maybe \mathbb wouldn't be such a bad idea)
* Font size changed from 140 to 120.
Criterium of conservativeness is using nothing more than:
* ASCII
* greek literals
* subscripts, superscripts
* \mathit (also \it \textit)
* \mathrm (also \rm \textrm)
* \mbox (also \hbox \vbox)
Todo:
* add "math" => 1 to default preferences in all language files (done for En
and It only now).
* add math_conservative column and the rest of math table to default db
creation script and add some db upgrade script which adds math table.
Please test it.
Hi,
one of our problems in dealing with vandals is that we can't reliably talk
to them. They may read the changelog, but it's quite possible that they
don't. They may see the article Talk page, but it's quite probable that
they have already moved on to the next one.
We already have a user talk page change notification mechanism in place,
but we currently don't use it for anons. How about this: next to the IP
number in recent changes, we would make a link to User
Talk:xxx.xxx.xxx.xxx. This would be created if it doesn't exist. Anonymous
users would then by default get notifications when their Talk pages have
been changed.
This isn't reliable, because several users can share an IP. But that's not
a problem -- it's really not a big deal if someone reads a message not
intended for them, and we could include a standard disclaimer: "Please
note: Sometimes several users share one IP address. These messages might
not be addressed to you -- in that case, please ignore them." At least it
would allow us to talk to anons, which I believe would help in many cases,
or keep them busy.
I also suggest changing the somewhat unfriendly "*" indicator to something
more obvious, like
(Talk)
when there are no new messages and
(Talk - new messages)
when there are.
What do you think? The only problem I see is that these talk pages might
be obsolete after a day or so, but if that ever becomes a problem, we
could clean them up automatically.
Regards,
Erik
Hi all...I'm a new subscriber to this list. I just learned about
Wikipedia for the first time a couple of weeks ago and think it's an
impressive new step in the evolution of the web as an information
commons. I have some thoughts about directions in which I think it
could be taken further, and I hope that some people here could offer
your reactions and advice.
I'll begin by giving some particulars that explain my personal
interest in Wikipedia, after which I'll touch on ways that my
specific interests might have more general relevance.
I edit a publication called "PR Watch" (www.prwatch.org) that
monitors deceptive and manipulative public relations campaigns. My
particular interest in Wikipedia stems from my long-standing desire
to develop an information base about PR firms, PR campaigns and
deceptive PR front groups -- organizations that claim to represent
some public interest while actually serving the agenda of a client or
industry whose sponsorship of the organization is often hidden. For
example, the APCO PR firm set up a front group called "The
Advancement of Sound Science Coalition" (TASSC), whose stated mission
was to promote science-based decision-making about public health
policies. In reality, TASSC was a front group for the Philip Morris
tobacco company, whose primary mission was to attack the U.S.
Environmental Protection Agency's risk assessment of secondhand
cigarette smoke.
A number of organizations, including PR Watch, have tried over the
years to develop databases, printed directories or other systems for
tracking PR campaigns, front groups or industry-sponsored "think
tanks." Typically, however, these efforts have run up against
limitations of time and staffing. There are thousands of think tanks
in the United States alone, with new ones forming all the time and
ever-changing personnel. Awhile back we added a section to the PR
Watch web site called the "Impropaganda Review" that serves as a
"rogues gallery" of a few notable examples, but the Impropaganda
Review remains in what Wikipedians might call the "Nupedia stage of
development." We've developed a handful of articles, but nothing
approaching a comprehensive directory. Rather than attempt the
impossible task of trying to expand the Impropaganda Review all by
ourselves, it seems to me that the Wikipedia model would be a great
way to invite the world at large to contribute.
There are, however, a few issues with this idea:
First, the nature of the work we do at PR Watch is inherently
controversial. Not everyone would agree with our characterization of
TASSC as an "industry front group," and I'm wondering if attempting
to develop an open-source directory of information on controversial
topics could succeed.
Second, the type of directory I'm interested in developing requires
the imposition of a bit more structure than Wikipedia imposes. Each
organizational profile in the "Impropaganda Review" contains the
following sections:
* A general description
* Personnel
* History
* Funding
* Case studies
* Contact information
* Related information resources
It isn't possible to obtain all of that information about every
organization (for example, some groups don't disclose the identity of
their funders), but I would want to strongly encourage contributors
to try to follow that framework.
Thirdly, I think it would be ideal if the information I want to
develop could be structured as a relational database. For example,
there would be a separate article for each ORGANIZATION, but also a
separate article for each PERSON, with a many-to-many relationship
linking the two categories. In other words, each article on a person
would include a list of the organizations with which that person has
been affiliated, while the article on an organization would include a
list of all its related personnel.
That's my basic concept. Now, here are my thoughts that might be of
more general relevance to Wikipedians:
(1) The Wikipedia model could be applied to a number of other uses if
the software could be modified to support something that users
experience as "relational databases of structured objects." Right now
users experience it as a non-relational database of ONE type of
object, namely an "article." The ability to insert hyperlinks to
other articles provides a quasi-relational capability, but it's not
truly relational. If, for example, I put a hyperlink in the "Leon
Trotsky" article that points to the "Mensheviks" article, the
software doesn't automatically create a corresponding link pointing
back from "Bolsheviks" to "Leon Trotsky." For certain types of
knowledge databases, it would be nice if the software could be
configured to do this automatically. Moreover, the structure of each
"article" is entirely free-form, and many knowledge databases try to
impose some sort of structure. For example, scientific articles are
typically structured to include an abstract and footnotes in addition
to the main text. If the Wikipedia software could be configured to
impose this sort of structure on individual articles, it could be
used to host a number of valuable, specialized knowledge bases in
addition to the general-purpose encyclopedia for which it was
designed. Moreover, that information could be extracted in a variety
of formats for different presentations. A database of "people," for
example, could be sorted in different ways according to different
fields, such as date of birth or city of residence.
(2) Supporting this sort of relational database structure may also
become important as Wikipedia continues to grow. One of the great
virtues of Wikipedia is that it supports collaborative synthesizing
and summarizing of information. Most of the information in
Wikipedia's articles can be found elsewhere on the web, but doing a
"Google" search often forces users to wade through mountains of
irrelevant information before they can find what they're looking for.
As the number of articles on Wikipedia continues to grow, the sheer
volume of information may also become daunting for users. Comments
are already being made to the effect that there are "too many
articles" about certain topics, and suggestions are being made to
split off certain topics into separate "sister" wiki projects such as
a Wikiteer (gazetteer) or a Wikipediatlas. However, creating separate
sister projects also leads to information fragmentation and
redundancy. If the Wikipedia software could support structured
information objects in addition to simple text articles, it might be
possible to encompass a number of "sister" projects as parts of a
single whole, while letting users decide what types of objects they
are looking for. For one user, it might be a general-purpose
"encyclopedia"; for another, a "gazetteer" (an encyclopedia of
locations); for another, a "who's who" (an encyclopedia of people).
Anyway, those are my thoughts for the moment. I'd appreciate
feedback, and especially advice on how I might go about starting a
Wikipedia-style open source information base on PR firms, PR
campaigns and front groups.
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------
One of the users on the Dutch Wikipedia (ArthurKing) is complaining that he
is unable to log in, getting the following error messages:
Parse error: parse error, expecting `')'' in /usr/local/apache/htdocs-nl/w/LanguageNl.php on line 81
Fatal error: Cannot instantiate non-existent class: languagenl in /usr/local/apache/htdocs-nl/w/Setup.php on line 26
Could someone please look what these error messages actually mean?
Andre Engels