Re: New diff feature for Wikipedia

Rob Church wrote:
> It's worth noting that someone else has registered an intention to do
> something similar and provide it as a script on the toolserver. That
> sounds infeasible to me, however, since we all know that, right now
> (and likely, for some considerable time), Zedler does not have access
> to the text of pages.
>

Well, my idea was simpler. While this new system would be superb in giving 
the attribution, and an exapmple of GFDL-compliance, on everyday use, you 
won't need to know 'who added each piece', but 'who added that quote' on 
Jimbo Wales user page (~3000 edits) OffTopic: interesting how Jimbo ip was 
hidden 
[http://en.wikipedia.org/w/index.php?title=User:Jimbo_Wales&diff=7476787&oldid=7476786]

So you would ask 'when was this phrase [at revision y] introduced?', 
getting:

a) You must be wrong, article doesn't have such phrase
b) Three edits before, by Foo [diff]

I don't think it to be very expensive. I calculate that most changes would 
have been introduced on last 10 edits (average 4 edits or so). Of course 
then you should try to guess if it was a blanking + reversion and complicate 
things a little more ;)

The worst case would be where the page has a lot of edits and the token has 
been there for a lot of edits. The first time it will be slow, but next 
times the cache will fast it a lot, so you'll have to go looking for another 
biggy article.

Re: New diff feature for Wikipedia

On 6/30/06, Platonides <Platonides@...> wrote:
> Well, my idea was simpler. While this new system would be superb in giving
> the attribution, and an exapmple of GFDL-compliance, on everyday use, you
> won't need to know 'who added each piece', but 'who added that quote' on
> Jimbo Wales user page (~3000 edits) OffTopic: interesting how Jimbo ip was
> hidden
[snip]

The proposed system would be completely inadequate for attribution
purposes, too easy to confuse the computer even in obvious cases...
plus not all cases are obvious, someone can still hold a significant
copyright interest in the work even if every word they wrote has been
replaced.

(Not that I don't think it would be a useful tool, but don't advertise
it as something that it is not :) )

Ligurian counter

Hello, many thanks. Maybe in some papers internal links are still missing. I'm going to check, but almost
surely this is the matter. If so, I will fix it as soon as possible.
Sincerely yours,
Claudi

Date: Fri, 30 Jun 2006 17:34:54 +0100
From: "Rob Church" 
Subject: Re: [Wikitech-l] paper counter at lij.wikipedia.org
To: "Wikimedia developers" 
Message-ID:

Content-Type: text/plain; charset=UTF-8; format=flowed

On 30/06/06, Claudi Meneghin  wrote:
> Hello,
>   the counter of articles at Ligurian wikipedia seems not to run properly: it shows some delay (not
depending on the cache of the browser), and it counts only 33 papers, instead of about 45. Could you please
take a look? Many thanks,

First, let's check you're not misinterpreting a value. For a page to
count towards the "article total" in Special:Statistics, MediaWiki has
to acknowledge it as an article. For this, it must meet three
criteria:

1. Be in the main namespace, or another designated content namespace
2. Not be a redirect
3. Contain at least one internal [[link]]

Please confirm pages matching these criteria are not affecting the
article total.

MediaWiki automated test run failure 2006-07-01

An automated run of parserTests.php showed the following failures:

Running test Table security: embedded pipes
(http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Parsing optional HTML elements (Bug 6171)... FAILED!
Running test Inline HTML vs wiki block nesting... FAILED!
Running test Mixing markup for italics and bold... FAILED!

Passed 394 of 407 tests (96.81%) FAILED!

Re: OpenDocument file format

Brion Vibber schreef:

> Where specifically would you like them?
> 
> We've also gotten requests to disable uploading of document file formats in most
> places, as they're only really relevant in a handful of meta-work wikis, not the
> main content wikis.
> 
> -- brion vibber (brion  <at>  pobox.com)

For at least Meta this could be useful. The option to upload also an
archive file like  .gzip ,.rar or zip would also be useful for Meta.

When people make a poster or a leaflet it is very useful that the can
upload also the source files of that item and not only the end result.
If an archive format can be upload then the file, from whatever the
program is, also be included.

Besides Meta enabling this for all the internal wikis, especially the
comcom-wiki, chapter wikis and foundationwiki can also be useful I suspect.

Side node; the upload function of the comcom wiki does not work.

The upload directory (/mnt/upload3/private/comcom) is not writable by
the webserver.

--

-- 
Contact: walter AT wikizine DOT org
Wikizine.org - news for and about the Wikimedia community

Re: New diff feature for Wikipedia

On 01/07/06, Platonides <Platonides@...> wrote:
> As a side note, there's currently a script on toolserver querying every
> change on wikipedia. Ask for some revisions when a user calls the php
> shouldn't matter in comparison 

Whose?

> External storage is a toolserver problem so i don't know why you complain to
> me so much about it. Morevoer, there're worse methods of implementating it,
> what about doing it on javascript? hahaha.

I'm not complaining, so don't misrepresent me as doing so. I'm
pointing out that a strong reliance upon text access is not too
brilliant for a project running on the toolserver at present.

Rob Church

Re: New diff feature for Wikipedia

On 6/30/06, Platonides <Platonides@...> wrote:
[snip]
> As a side note, there's currently a script on toolserver querying every
> change on wikipedia. Ask for some revisions when a user calls the php
> shouldn't matter in comparison 
> External storage is a toolserver problem so i don't know why you complain to
> me so much about it. Morevoer, there're worse methods of implementating it,
> what about doing it on javascript? hahaha.

There is a huge difference between reading every article change (less
than 1 per second on a one month average) and reading all of the
9000ish revisions to George W. Bush every time someone wants to view
the blame map.

Re: New diff feature for Wikipedia

Moin,

On Saturday 01 July 2006 18:00, Gregory Maxwell wrote:
> On 6/30/06, Platonides <Platonides@...> wrote:
> [snip]
>
> > As a side note, there's currently a script on toolserver querying
> > every change on wikipedia. Ask for some revisions when a user calls
> > the php shouldn't matter in comparison 
> > External storage is a toolserver problem so i don't know why you
> > complain to me so much about it. Morevoer, there're worse methods of
> > implementating it, what about doing it on javascript? hahaha.
>
> There is a huge difference between reading every article change (less
> than 1 per second on a one month average) and reading all of the
> 9000ish revisions to George W. Bush every time someone wants to view
> the blame map.

Cache the blame map. In addition, cache it for each revision. Limit the 
cache to "N maps or M megabytes, whatever is reached earlier".

I think it should be possible to generate the blame-map for revision N+1 
from the map of revision N and the diff between the revisions.

Best wishes,

Tels

--

-- 
 Signed on Sat Jul  1 19:20:27 2006 with key 0x93B84C15.

Re: New diff feature for Wikipedia

On 7/1/06, Tels <nospam-abuse@...> wrote:
> Cache the blame map. In addition, cache it for each revision. Limit the
> cache to "N maps or M megabytes, whatever is reached earlier".
>
> I think it should be possible to generate the blame-map for revision N+1
> from the map of revision N and the diff between the revisions.

Locality is poor, any time you talk about caching revisions you're
fighting a losing battle.

We'd really need incremental production of blame maps... Where you can
take a finished blame map for revisions 1..5 and add revisions 6 and 7
and get the 1..7 blame map.   Then blame maps could be could simply be
generated and stored.. and when they are requested it would only
require fetching the map and updating it.

New SVN committer

Added Ilmari Karonen (vyznev); has been working on misc fixups and patches.

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
http://mail.wikipedia.org/mailman/listinfo/wikitech-l