Hello,
I don't know whether this is a known bug:
There is a problem with headlines not well-formed.
I grabbed some examples from the German Wikipedia:
== wrong headline
== Italienisch ==stimmt das denn??
Both lines are not parsed as headlines, but when you edit a section of
the article containing these lines you get a different section from what
you expected, because it seems that the software increments the section
counter at these lines, too.
Eckhart
Hi,
I'm going on holiday for the next week. Accordingly, I will not be able
to work on the lex/yacc parser that I have written during the past weeks
or so. I will check into CVS my work so far, and anyone interested can
continue the work while I am away.
So far, the parser can do:
* paragraphs
* pre-lines (lines beginning with spaces)
* lists (* and # only)
* extensions (<math>, <hiero>)
* headings
* bold and italics
I am sorry I took so long to do bold and italics, but, just as I
originally anticipated, it was quite hard. I had discarded two failed
attempts until the third one finally worked out. There is one special
case in which I had to apply a bit of a hack, but I am sure that this is
okay, given that it works pretty much perfectly now.
As for "extensions", it currently recognises anything as an extension
that is an HTML tag without attributes and its corresponding closing
tag. Using this mechanism, <nowiki> and <pre> can be considered
"extensions" for the purposes of the parser.
What is missing:
* links, images, categories (everything in [[ ... ]])
* template inclusions and variables ({{...}} and {{{...}}})
* tables
* HTML tags that should be allowed but are not extensions (esp. div)
The lexer already recognises tokens for the former two, but not for
tables or HTML tags. In particular, it will recognise something like
<b>''something''</b> as an "extension" and not parse the '' as italics.
Obviously, this needs to be fixed.
If anything is unclear about how things work, please drop me an e-mail
and I will document the relevant bits when I am back.
Timwi
Coming from UseMod wiki software, where this information is always
present, I would like to introduce these patches in the coming versions
of MediaWiki:
to show and link who edited last the article (or revision)
==========================================================
(1) on every article's footer
"This page was last modified on .. (date) by userX(talk)"
=========================================================
For this patch the page MediaWiki:lastmodified needs to be
modified, add $2 and/or $3 if you wish to display the user and usertalk
information and links:
page MediaWiki:lastmodified
1.3.1 Original: "This page was last modified $1."
1.3.1 TG Patch: "This page was last modified $1 by $2 ($3)."
(2) on each article's revision page
"Revision as of .. (date) by userX(talk)"
=========================================
For this patch the page MediaWiki:revisionasof needs to be
modified, add $2 and/or $3 if you wish to display the user and usertalk
information and links:
page MediaWiki:revsionasof
1.3.1 Original: "Revision as of $1"
1.3.1 TG Patch: "Revision as of $1 by $2 ($3)"
The patch is for the modules Skin.php and Article.php of version 1.3.1;
the patch is ready and will be published soon.
Tom
Hello,
is there a possibility to get
a) the markup text of a wikipedia article,
b) the markup of a specific article version and
c) the current version number of an article?
Eckhart
Yes, if you read my last post to the wiken list, viewable here: http://mail.wikipedia.org/pipermail/wikien-l/2004-August/029985.html, I think I made it clear that I was using the term copyright too loosely. What I meant, was material released under a non-gnu-compatible license. We should draw a line between gnu-compatable content, and non-gnu-compatable content on the software side, to better facilitate removal of that content by future users of our content. Otherwise, we are sacrificing the freeness of our encyclopedia. If we leave things the way they are, there is no telling how hard it will actually be to remove this non-free content in the future.
On Fri, 20 Aug 2004 18:23:55 -0300, Jeff Warnica <jeffw(a)chebucto.ns.ca> wrote:
> On Fri, 2004-20-08 at 12:58 -0400, Michael Becker wrote:
> > I'm forwarding my message to the wikitech list because I think this
> > might be of more interest to you people than wikipedians at large.
> >
> > ---------- Forwarded message ----------
> > From: Michael Becker <mbecker(a)jumpingjackweb.com>
> > Date: Fri, 20 Aug 2004 09:43:09 -0400
> > Subject: RE: [WikiEN-l] defining Free Encyclopedia
> > To: wikien-l(a)wikipedia.org
> >
> > though, as long as there is a hard line drawn between copyrighted and
> > GPL material, it should be easy enough to remove. If we don't
> > facilitate the easy removal of this content, the wikipedia is no
>
> The opposite of copyrighted is "public domain". Works covered by the
> GPL, and the FDL ARE copyrighted. It is copyright law that provides for
> the legal backing of the GPL/FDL (and for that matter, _any_ license).
>
>
--
Michael Becker
I'm forwarding my message to the wikitech list because I think this might be of more interest to you people than wikipedians at large.
---------- Forwarded message ----------
From: Michael Becker <mbecker(a)jumpingjackweb.com>
Date: Fri, 20 Aug 2004 09:43:09 -0400
Subject: RE: [WikiEN-l] defining Free Encyclopedia
To: wikien-l(a)wikipedia.org
Personally, the *free*ness of wikipedia concerns me a lot too. This was my first concern when I first submitted the image to vfd. I personally had NO political or censorship concerns. That is pretty obvious if you check out the history of the Clitoris article. In any case, I'm also VERY concerned about the effects of using copyrighted material in the wikipedia will have on it's freeness. As I see it now though, as long as there is a hard line drawn between copyrighted and GPL material, it should be easy enough to remove. If we don't facilitate the easy removal of this content, the wikipedia is no longer free, and we have failed in our goals IMHO. At the moment, the lines drawn between free and non-free content in the wikipedia are very thin. This is a line drawn by the users, and we are essentially trusting people who upload these non-free images/content to make sure it is easy to distinguish their added content as non-free. I'm not very comfortable with this. IMNSHO, it wo uld be better if we had some sort of hard line drawn on the software side of things between free and non-free content so that it can easily be removed in the future.
On Fri, 20 Aug 2004 09:38:12 -0400, Anthony DiPierro <anthonydipierro(a)hotmail.com> wrote:
> > Well, the email has been sent already, so why don't we see what they
> > reply with? I hardly see how any kind of permission (or refusal) from AP
> > could [be] bad for us: It clarifies our options, but we don't /have/ to
> > avail of them if we don't want.
>
> First of all, refusal wouldn't clarify our options. If the image is being
> used in a way which is fair use, then it's fair use regardless of whether or
> not AP has refused to allow us to use it. Secondly, clarifying our options
> doesn't resolve the dispute. Having options is exactly the reason we have
> the dispute. If we didn't have any options, we wouldn't have a dispute.
>
> > Besides, the root of the problem _as I perceive it_ is that this is a
> > proxy political dispute:
>
> > The very people pushing hardest against that picture's use and for its
> > removal on copyright grounds made edits that would seem to hint at a
> > political affiliation which might make them feel uncomfortable about
> > this picture. (That's not a judgment, just an observation.)
>
> That's certainly not the *root* of the problem. It may be why the problem
> came to light in this particular instance, but the root of the problem has
> nothing to do with these details. The root of the problem is that we
> haven't decided what it means to be a *free* encyclopedia. This needs to be
> resolved in a way which provides objective criteria for inclusion. We've
> started along on that path, but we've still got a long way to go.
>
> Incidently, this is somewhat analogous to the problem of deciding what it
> means to be a free *encyclopedia*. We're farther along with that
> definition, and have already come up with somewhat objective criteria at
> [[Wikipedia:What Wikipedia is not]]. But we still resort to
> [[Wikipedia:Votes for deletion]], still have ongoing inclusion disputes, and
> people still abuse the abiguities for political purposes.
>
> > My motivation was to settle the copyright situation, yay or nay, so
> > people can THEN deal with it.
>
> > If we first wanted to wait till we had agreement, we'd wait till
> > kingdom come.
>
> I don't think that's at all the case. I'm probably one of the biggest
> objectors to having non-free images on Wikipedia, and I've come a long way
> toward accepting some non-GFDL images as being "free enough". I actually
> think the majority of the problem is a lack of understanding rather than
> diametrically opposed viewpoints.
>
> I think we can come to an agreement on what it means to be a *free*
> *encyclopedia*. It would probably speed things up to organize the effort,
> and that's why I proposed as part of my platform when I ran for the
> Wikimedia board to start a committee with the task of defining those terms
> by community consensus (i.e. what the term means to us). I think a
> definition of the term "Free Encyclopedia", similar in concept and spirit to
> the GNU Project's definition of Free Software (see
> http://www.gnu.org/philosophy/free-sw.html), formed by the community as a
> whole and ratified by the board, would *be* an agreement, and I think it
> could be reached. Maybe I'm just overly optimistic.
>
> > Thanks and regards,
> > Jens Ropers
>
> Anthony
> _______________________________________________
--
Michael Becker
UPDATE
We found an much easier way to change the letter "N" indicating NEW
PAGES for an UPLOADABLE icon.
See the result **LIVE** on the page
http://de.wikipedia.org/wiki/Spezial:Recentchanges
The whole patch:
see http://de.wikipedia.org/wiki/MediaWiki:newpageletter
<img src=/upload/X/YY/Neu.png>
* Replace "/upload/X/YY/Neu.png" with the relative URL on your wiki
* The URL is shown on the [[Image:Neu.png]] page after you uploaded it
to your wiki.
The uploaded image file page should be locked against unintended and
unwanted changes.
Tom
Berlin
Ævar Arnfjörð Bjarmason wrote:
> On Sun, 15 Aug 2004 23:33:36 +0100, Timwi <timwi(a)gmx.net> wrote:
>
>>You are the one who proposed this. The onus lies with you to set up a
>>vote on Meta and convince us that the community at large really does
>>want this change. :-)
>
> Every bugfix and feature request needs a vote on meta now?
Every controversial one, I would assume. If we just blindly change it
the way you suggest, people are going to complain, I bet you.
Timwi
We're going to be tweaking the backup mail server configuration a bit to
not suck so much. In the meantime, I'm cleaning out the forgotten
moderation queue on the backup server; some of these postings may have
been reposted and answered already.
-- brion vibber (brion @ pobox.com)
On 20 Aug 2004, at 20:29, wikitech-l-request(a)wikimedia.org wrote:
> Message: 4
> Date: Fri, 20 Aug 2004 09:28:43 -0700 (PDT)
> From: <leercontainer-wikimedia(a)yahoo.com>
> Subject: [Wikitech-l] Re: Article history link
> To: wikitech-l(a)wikimedia.org
> Message-ID: <20040820162843.92854.qmail(a)web13424.mail.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> <snip>
>>> An oldid is not assigned until the revision is saved into the old
>>> table.
>>> Hence, you see, the problem.
>>
>> Ugh.
>> I suppose there's no way to change that and save the revision into the
>> old table immediately?
>> Or don't really save it but at least assign an oldid that can later be
>> used when it does actually get saved?
>>
>> - Jens
>
> I have submitted this as an enhancement "bug" at MediaZilla, see:
>
> http://bugzilla.wikipedia.org/show_bug.cgi?id=181
>
> --Guttorm
THANK YOU very much !!! ;-) :-)
Especially so because from the one time I was forced to use (another
implementation of) BugZilla, I remember I hated it and found it far too
unwieldy.
<n00b>However I didn't even know we used bugzilla here.</n00b>
So thanks again for putting this forward! Much appreciated! It would
really help if this were implemented.
:-)
:)
- Jens