body:
Axel-
> True. We also don't give people developer status so that they can
> unilaterally take away sysop rights, which you just did for the second
> time.

I applied for developer status on Wikipedia so I could handle incoming
sysop requests, because Ed Poor no longer did it. In spite of the name of
the access level, it had nothing to do with Wikipedia software
development. In my original request, I wrote:

>I would like to request developer rights on the English Wikipedia. This
>would allow me to execute write-access queries on the database, and as
>such, to grant sysop privileges to other users. I would like to help with
>the sysopping, which seems to be right now only done by a couple of
>people

Because there is nobody else who is highly involved on the English
Wikipedia and also has these access rights, it was only natural for me to
jump in in case of unusual situations regarding sysop status. And I
received wide encouragement to do so. Even Jimbo endorsed my actions when
I removed Kils' sysop status, see this post:

http://marc.theaimsgroup.com/?l=wikien-l&m=105447260632066&w=2

You did not object, so I fail to see why you emphasize "for the second
time" above. If you think I was wrong the first time, why didn't you say
so? In the latest case, several users also approved of my actions, and the
only one to substantially object regarding the actual case at hand (the
page protection/unprotection) was Jtdirl.

I am very sensitive to these matters, and if you feel that I am the wrong
person to do this, I will gladly stop handling the sysop requests on
Wikipedia. If you want me to do this, however, I'll expect you to either
name a replacement, or step in yourself. I also encourage you to set up an
alternative process page that does not rely on an individual user, such as
"Votes for unsysopping".

Regards,

Erik


list: wikitech-l

source: pipermail-mbox

from_name: Rotem Dan

subject: [Wikitech-l] Please update LanguageHe.php

body:
Please update LanguageHe.php from meta. I have asked this before, but it
probably went unnoticed. It is important because it sets the defaults
for TeX to always display as PNG. That will fix the incorrectly
displayed formulas (when rendered as HTML, probably due to RTL issues)
problem I have reported earlier. (See thread about "Hebrew wikipedia
buglist")

The amount of activity on the Hebrew wikipedia has jumped enormously
since it got the press article on Ynet yesterday. Current status: 215
articles (However, many of them are used as "placeholders" and contain
only links), 71 registered users, 8254 pageviews since 8 July 2003.

Rotem


from_name: Jakob Voss

subject: [Wikitech-l] Re: Script available for uniform statistics for all Wikipedias

body:
Erik Zachte wrote:
> I have written a PERL script that parses the SQL dumps (cur & old) and
> generates a html file, containing for each month since the project
> started.

Thanks a lot! I prefer developing this features out of the server anyway.

I wrote a german translation. feel free to modify :-)
   http://meta.wikipedia.org/wiki/Statistics_script

Jakob


list: wikien-l

from_name: Erik Moeller

subject: [WikiEN-l] 172 sysop status temporarily revoked

body:
Dante-
> My objection to the suspension of 172's sysop status is mainly that I don't
> think he overstepped the bounds of good conduct any more than various other
> sysops do on a not infrequent basis. We all go a bit past the realm of
> "good ideas" once in awhile, and I think that suspension of sysop status
> should be reserved for more substantive (especially REPEATED) violations
> than 172's single instance of "questionable" protected page behavior.

For the record, I suspended 172's status primarily because he reprotected
the talk page after I told him that it was against our policy to do so.
This was to prevent any protection wars on the page from occurring until
the policy questions raised by this would be settled satisfactorily. I
explicitly noticed that the suspension was temporary and immediately
posted a notice to the wikien-l mailing list.

Regards,

Erik


list: textbook-l

from_name: Daniel Mayer

subject: [Textbook-l] different open content licenses

body:
Schewek wrote:
>Why not add a "from <chose your date>
>the license is changed to...", and ask all
>contributers to sign on a page if they
>retroactively agree, and theoretically one
>could filter out all articles not covered and
>rewrite those is necessary.

You mentioned articles and not modules so I assume you are talking about
Wikipedia. In short: that's impossible on practical grounds. There have
probably been more than 20,000 people who have edited Wikipedia and most of
them were either anonymous or didn't leave an email address behind that is
still active.

Depending on the change many people may also opt not to agree to the change -
I would probably be one of those just on the principal that we shouldn't
change things like our license arbitrarily (it has worked great so far; so
why rock the boat?).

That is still possible for the textbook project though - however most of the
content being placed there so far is GFDLd textbooks that were created
elsewhere and copied Wikipedia text.

We can discuss the possibility of changing license terms when somebody finds
an impressive non-FDLd free text resource whose copyright owner declines our
nicely-worded request to grant us a GFDL license of their work.

-- Daniel Mayer (aka mav)


subject: [WikiEN-l] Catholicism

body:
Erik wrote:
>Wikipedia policy pages can be openly edited
>by anyone, as they could always be.

Edit, yes, change the meaning, no. Anybody can edit a policy page to correct
typos, misspellings or to make a good faith effort to clarify policy per
established consensus.

An editor /cannot/ unilaterally change policy. But I have no opinion on
whether or not you did that since I haven't looked over the changes yet.

-- Daniel Mayer (aka mav)


from_name: Kurt Jansson

subject: [Wikitech-l] please turn off the German page counter

body:
I suggested on the German list to turn off our page counter, like the
English Wp did long ago. I hope we can gain a bit more performance, and
maybe some of the other "big" 'pedias will follow.

Everybody on the list agreed, though some disliked to see another
(partly) useful function go for performance's sake.

Kurt

P.S.: Maybe the data can be archived for the archeologists somehow ...


from_name: Timwi

subject: [Wikitech-l] Phase IV

body:
Hi,

the past few days I've been experimenting a bit with Apache, mod_perl,
MySQL and creating an entire own website. I've never done that before,
and I think I've learnt a lot from this.

Now, for some reason, against all of your advice, I have started to
program a Wiki, and by now it's already become a suitable basis for a
Phase-IV Wikipedia software, including a database schema.

It really doesn't seem to be very difficult to re-program the current
software in Perl, this time taking all the problems into account and
designing everything right from the start (incl. single-login,
multi-language watchlists, a better translation system and skin system
(separated from the code), etc.) I've also made a lot of considerations
and decisions with respect to database design and performance.

Should I continue with this?

Greetings,
Timwi


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Phase IV

body:
On Fri, Jul 25, 2003 at 12:16:56AM +0200, Timwi wrote:
> the past few days I've been experimenting a bit with Apache, mod_perl,
> MySQL and creating an entire own website. I've never done that before,
> and I think I've learnt a lot from this.
>
> Now, for some reason, against all of your advice, I have started to
> program a Wiki, and by now it's already become a suitable basis for a
> Phase-IV Wikipedia software, including a database schema.
>
> It really doesn't seem to be very difficult to re-program the current
> software in Perl, this time taking all the problems into account and
> designing everything right from the start (incl. single-login,
> multi-language watchlists, a better translation system and skin system
> (separated from the code), etc.) I've also made a lot of considerations
> and decisions with respect to database design and performance.
>
> Should I continue with this?

While I'm much more a Perl guy than a PHP guy, I strongly advice against it.
With very small error it can be said that rewriting software is NEVER a
good idea. Forget your ego for a moment and code your ideas as patches
to existing codebase - this way everyone's going to benefit most.


subject: [Wikitech-l] Re: Phase IV

body:
Lightning wrote:

> Timwi wrote:
>
>> Should I continue with this?
>
> I wouldn't advise it.

Heh, knew it! ;-)

> Plus, I think there was a reason behing programming
> in php vs Perl, im not sure..

Read the section "Why are we using PHP instead of perl?" on
http://www.wikipedia.org/wiki/Wikipedia:PHP_script_FAQ

> Then add to that that you designed a new db schema
> and that all data will have to be converted from one to the other

Of course I have thought about this. My plan would be to convert
articles as they are requested by readers. That way the database would
get converted gradually on demand, thus minimising possible delay and
avoiding downtime.

> "If it's not broken, don't fix it"  I currently see no problems
> with the wiki software as it is.

Well, please allow me to reply something to this even if it may
potentially be somewhat offensive. If it is, I am very sorry, and I do
not mean to offend you. But the reason for this is that you are American
and (as far as I can tell, sorry if I'm wrong) only use the English
Wikipedia. People who are using several different language Wikipedias
are seeing many more disadvantages and shortcomings in the current
design. Add to that the fact that you are very much used to Wikipedia as
it is now; it is often difficult to forego something familiar.

Additionally, the current database schema has performance problems that
you will not be able to overcome without converting the database. Of
course, you could convert it bit by bit, but then again, you could
equally well start with an entirely new database schema...

> After
> that we could slowly move towards universal logins through a simple
> system I proposed earlier which would allow for a simple transition.

Unfortunately, any change that would introduce a universal-login system
to the current system, would be a hack solution in and of itself, simply
because the current software was not designed to handle this.

> Iwould however be very interested in seeing your DB schema

http://meta.wikipedia.org/wiki/Experimental_new_database_schema

Any comments, of course, are welcome.

> and some info
> about your ideas for then ew software

Well, I've had quite a lot of ideas, I probably wouldn't know where to
start. Of course, I have followed this mailing list and have picked up
ideas here and there. I support the idea of a more-or-less independent
layout system that will allow users to skin Wikipedia to their needs
without the software needing to hard-core any HTML (with the possible
exception of the contents of pages in the Special: namespace).

Other (not-so-important) improvements over the current system include
translatable names of Special pages (not just the namespaces), all
non-canonical URLs redirect to the canonical URLs, so every resource has
one and only one place to live; easier URLs (/Article_name/edit instead
of /w/wiki.phtml?title=Article_name&action=edit), being able to use
Wikipedia's web interface in one language while viewing articles in
another language ...

> just please don't post perl source full of perlisms like $/,
> $_, $? @var, %var. etc that crap is obfuscated and hurts my eyes..

I haven't used $? yet :)))

But I have to admit to being a fan of regular expressions. I use a few
of them currently to extract information from URLs (like the language
code), but the two Special Pages I have created so far (Log In and
Translate) do not use them at all, and I don't think most of them will
(things like Watchlist, Recent Changes, Orphans etc.etc. will just be
SQL statements and then an HTML table).

Greetings,
Timwi


subject: [Wikitech-l] Re: Phase IV

body:
Timwi wrote:
>
> Hi,
>
> the past few days I've been experimenting a bit with Apache, mod_perl,
> MySQL and creating an entire own website. I've never done that before,
> and I think I've learnt a lot from this.
>
> Now, for some reason, against all of your advice, I have started to
> program a Wiki, and by now it's already become a suitable basis for a
> Phase-IV Wikipedia software, including a database schema.
>
> It really doesn't seem to be very difficult to re-program the current
> software in Perl, this time taking all the problems into account and
> designing everything right from the start (incl. single-login,
> multi-language watchlists, a better translation system and skin system
> (separated from the code), etc.) I've also made a lot of considerations
> and decisions with respect to database design and performance.
>
> Should I continue with this?
>
> Greetings,
> Timwi

Hi Tim, I'm glad to see another person interested in working on "new"
code. I am not very familiar with the phase III code (still working on
understanding it), but I think more in "build a new front-end from
scratch", but using PHP (as I rather take the most backward compatible
way to do it). And then start figuring out how to connect to old, tested
code as imported classes. (and learn what sort of modifications they
will need, as currently I only know there are plenty of them)

I really think the single username, single codebase is a good direction
(single database may be dangerous in case it fails and the whole site
breaks down). Anyway, I suggest you to leave the back-end logic for the
people who already work on it. As you'll probably end up dealing with
the same database, somewhat similar queries and same optimization
challenges. As for the wiki syntax parser, I wouldn't want to rewrite
that! (I hate parsers!)

For a new interface, I suggest you to look at my much thought-given
example on http://www22.brinkster.com/rotemdan/phase4-demo-v1-1.htm

I have done even more improvements including fixing support for some
browsers, support for zooming (uses em instead of px except for
positioning the right column, which is positioned relative to the
image). Organized and documented the CSS.

Some thoughts:
* No need for "smarty" or similar SGML templates since strict XHTML/CSS
does a nice job in separating content from formatting, see the link above.

It will be very easy to use it inside scripts, for example, to create a
box with some options inside just do something like this:

	This is the box title[ X ]

	Some stuff in the box

	hello!

And it will be automatically positioned and formatted by the CSS file..
Long live CSS!

* New language files may be needed for the new interface (though an ugly
backward compatibility may be possible to implement), we should also
think about using a template that's really easy to edit by
"non-programmers" and doesn't depend on the script used. (XML or
plain-text comes to mind, I haven't given any thought to this yet)

Another thing about language files: they shouldn't contain whole pages!
and not even a bit of HTML formatting! I saw this ugly feat when I
worked on translating the "Upload image" enormous string. These pages
should be edited using the wiki, even though they contain markup.

Also: switching interface language using the preferences (dynamically),
regardless of language of articles read/edited. (can really unify the
different language wikis). Another cool thing: using the new CMS, for
example, the same article in several different languages can be put on
the same page, side by side, an excellent aid in translating! (flamebait
warning: that will also require the whole site to move to UTF-8 or
similiar encoding, so I don't know if that's possible with all languages..)

Rotem


subject: [Wikitech-l] Re: Phase IV

body:
Hi Rotem,

Rotem Dan wrote:

> (single database may be dangerous in case it fails and the whole site
> breaks down).

Well, I'm neither a webserver expert nor a database expert, but I know
how LiveJournal does it (and I've mentioned it here in the past). They
use a number of independent webservers, and then put a "load balancer"
in front of that. This load balancer receives the requests from the
clients and distributes them evenly over the webservers. This way, if
one webservers crashes, the site will only be marginally slower until
this server is restarted. LiveJournal also has redundant load balancers
in case one of *those* crashes.

As for the database, they use MySQL replication. That means there are
several databases actually containing the same data; one of them is the
"master" (which is where data is written), and these writes are then
broadcast out to the other DBs, the "slaves". This way DB reads can be
even distributed among several servers. This, in turn, means you don't
need to keep buying bigger and better hardware, only more of it (and the
old and crap hardware can still contribute to handling some of the load).

They (LiveJournal) have even written an independent Perl module
(DBI::Role) which handles all of this (distributing DB reads across
several slaves, and even weighting them according to their performance).

Now, LiveJournal actually also use clustering, i.e. they distribute the
users' journals across several clusters (each of which has an own master
and several slaves). I'm yet undecided whether it's a good idea to do
the same with Wikipedia languages. Doing so would make multi-language
watchlists difficult. However, not doing so may make the architecture
not scalable enough. I'm not knowledgeable enough to judge this.

> As for the wiki syntax parser, I wouldn't want to rewrite
> that! (I hate parsers!)

This is actually the part I'm looking forward to! (Since, as mentioned
before, I love regexps ;-) )

> For a new interface, I suggest you to look at my much thought-given
> example on http://www22.brinkster.com/rotemdan/phase4-demo-v1-1.htm

Well, no. I wasn't planning to design or integrate a new interface. I
was going to create a skin system that will allow people to create skins
liberally without needing to code. Then you could create your skin
yourself :-)

> Long live CSS!

Well, looking at what many sites have achieved with CSS (including but
not limited to LiveJournal's Xcolibur scheme, which isn't yet the
default), it does seem quite impressive. However, there are a few
(probably minor) reasons I hate CSS, including but not limited to the
incapability of simply placing something at the bottom of the browser
window regardless of the main text flow, or centering a table. Also,
making a site layout browser-independent seems to be even more difficult
with CSS than with outdated HTML 2 (in my experience, anyway).

> * New language files

Na-ah! No language files in /my/ implementation ;-) My translation
system has everything in the DB. Translators can change the translatable
texts using a web interface. (I specifically decided against applying
the Wiki philosophy to this because things like the "Edit this page"
link text apply to /every/ page on the /entire/ site, so it would be too
easy to upset a whole bunch of people by changing it to something
offensive.)

> Another thing about language files: they shouldn't contain whole pages!

Yes, I thought the same -- and have planned to make longer page contents
(like the explanation on "Upload file" you mentioned) wiki-like, so they
are actually the contents of the page titled "Special:Upload" (or
whatever it would be in other languages).

> and not even a bit of HTML formatting!

Well, actually, I'd really rather keep /some/ simple HTML formatting
in-place. Sometimes you want to bold a single word in a sentence, but
bolding looks really ugly in Chinese and Japanese, so /they/ prefer
/not/ to do it. So I keep the simplest of formatting in, so translators
have at least /some/ control over it. (I am, at least, planning to use
HTML in translatable strings /much/ less than LiveJournal does now; they
have a /lot/ of HTML in their strings, and sometimes even BML, which is
their own mark-up language which nobody knows.)

> Also: switching interface language using the preferences (dynamically),
> regardless of language of articles read/edited.

Yep, planned. Also a URL parameter to force the interface in a
particular language.

> warning: that will also require the whole site to move to UTF-8 or
> similiar encoding, so I don't know if that's possible with all languages..

I am not aware of any language which has characters that are not
included in Unicode, and I'm pretty certain none of the Wikipedia
languages do. Of course, my implementation would simply use UTF-8 all
the way through, thus avoiding all annoying encoding problems.

(Well, not all of them; I've already handled the case that someone may
request a URL which contained invalid UTF-8; I assume Latin-1 in this
case, convert and redirect. But, of course, articles and all interface
stuff would be entirely UTF-8.)

Greetings,
Timwi


from_name: Anthere

subject: [WikiEN-l] Catholicism

body:
--- Daniel Mayer <maveric149 at yahoo.com> wrote:
> Erik wrote:
> Edit, yes, change the meaning, no. Anybody can edit
> a policy page to correct
> typos, misspellings or to make a good faith effort
> to clarify policy per
> established consensus.

Imho, Erik (not unilateral) change qualifies at a
"good faith effort to clarify policy" :-)

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: james duffy

subject: [WikiEN-l] Catholicism

body:
I'm glad to see everything has been sorted out. But 1 thing puzzles me.

>Erik wrote
>. . . this enforces a class distinction that I am not very comfortable
>with. I
>think it should be avoided.

>. . . I have now edited the policy
>to favor my interpretation -- this is of course open to discussion.

Surely some contradition, Erik? You rewrite the rules unilaterally to stop
someone unilaterally doing what you disapprove of. You are opposed to cabals
because they exclude people, so you unilaterally rewrite the rules to stop
people unilaterally excluding people. :-)

Is this what we should call 'Erik's Law of Unilateralist Logic'? :-)

JT

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail


from_name: b schewek

body:
From: Jimmy Wales
>
> If we were starting wikipedia from scratch today, I would prefer to
> create a wikipedia license that says "You can redistribute this
> content under GNU FDL, CC-SA, or additional free licenses that may be
> specified from time to time on this page."
>
> But isn't it too late for that?

Why not add a "from <chose your date> the license is changed to...",
and ask all contributers to sign on a page if they retroactively agree,
and theoretically one could filter out all articles not covered and rewrite those is necessary.

Schewek
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze


subject: [WikiEN-l] Erik Mollers comment

body:
>From: Adam von (whatever his name is /this/ time - well the last time Uncle
>Adam took offence at being called Rickleff but he has yet to tell us what
>his real name is!).
>
Now suddenly you can't write anything at all. But hey- some  people still
can. You're a second class user now.
>
>
>Boy, that sure sounds familiar....
>
But it shouldn't, Adam. As a multiple banned user who has had more illegal
identities on wiki than Pavorotti has had hot dinners you are not meant to
be a user on wiki at all. But since you are so concerned about wiki, maybe
on the the fourth time of asking you could answer the questions:

1. Are you on wiki?
2. What is your identity?

Oh and BTW, since you don't like being called Adam von Rickleff, what /is/
your real name?

JT

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


subject: [WikiEN-l] Daniel C. Boyer on wikipedia

body:
The Daniel C. Boyer bandwagon is getting a bit out of control. Daniel is a
user on wiki who has an article about himself on wiki. While that seems OK
as he is a real if rather minor celebrity and artist, his articles relating
to himself are breeding like rabbits.

17 (yes, 17) redirects to forms of his name - all were put on the Votes for
deletion page and in cleaning up the page in view of the general agreement
on the page I deleted them.

He has articles about the company he founded, [[Idealist Press
International, Ltd]], with some other people, on which we find that he
designed a special watch for the company. One of his co-directors
[[Elizabeth M.B. Davis]] has her own wiki page of one line to tell us when
she resigned from the company, which BTW he listed on [[List of American
companies]]. His grandfather [[Carl Benjamin Boyer]] gets a page (OK he was
sorta famous, but the article (surprise, surprise) of course mentions his
grandson!). Daniel even has a link to the [[Polyvinyl chloride]] (PVC) page
which I half expected to contain a line stating ''Idealist Press
International, Ltd, on whose board Elizabeth M.B Davis sat, specially covers
the books of internationally famous poet, filmmaker and creator of the Echo
Poems technique, Daniel C. Boyer, with black [[Polyvinyl chloride]].''

Daniel's tendency to . . .  em . . . write about Daniel, his companies, his
art-form, his former company director, his granddad, himself,  another
company . . . is getting a tad tedious. Maybe Jimbo might like to ask him to
try to write a couple of articles not containing the words ''Daniel'',
''Boyer'' or any of the 17 variants he dreamt up as redirects. He isn't
doing any major harm, but unless stopped, wiki is in danger of looking like
a vanity press publishing attempt.

JT

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail


subject: [Wikitech-l] Re: Phase IV

body:
I would like to ask developpers a question : I have a
problem on my browser with indivisible spaces.

Please, this is an important question, the sort of
issue that might lead to an edit war.

In french typography, indivisible space are put before
some caracters, such as :

Recently, a new editor (a french language teacher) got
on the french wiki. He insists on using these
unbreakable spaces. As far as I know, he is the only
one.

However, for some reasons I can't explain, my browser
(a brand new one, last version, unicode friendly, page
over 32 kb friendly, etc...) appears to be "breaking"
these spaces. Though I can't figure how it is doing
so. When I look at the history, I see nothing I can
explain.

Still, Vincent insists that I do break his text. To
fix it, he has to either revert my changes, or fix
them himself, isssue upon which he is strongly
complaining so requesting that I fix the stuff myself.
Fact is, I can't see what I do wrong, and I can't
imagine myself editing by hand his comments myself
each time I edit an article or talk page, to avoid
removing the non-breakable space (if only I could
figure how not to do so !)

Let me show you an example :

Here is my edit (I was removing a div in a talk page,
use of div is becoming more and more common, as well
as use of anchors to support 40 or 50 kb pages)

http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82635&oldid=82624

And here is Vincent next edit, restoring manually all
the non-breakable spaces behind me

http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82637&oldid=82635

The fact is that if I see him restoring the spaces, I
see not in *my* edit where I broke these spaces. I
only removed the div line. I just look from my job
browser (a very regular PC), and I can't see anything
special either.

Guys, this is a tough problem because that means
either Vincent has to correct behind me each time, and
complain loudly, and request that I fix the mess
myself, or I can't edit the pages Vincent edits.

This is doubly important as Vincent and I strongly
disagree on other matters as well, so I fear this
particular point might disrupt our peaceful little
world.

Is there anyone who would have a *clue* on that
specific problem ? Is it solvable or not ?

Are there other wikis using non-breakable spaces ? Did
they meet problems as well ?

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Karl Wick

subject: [Textbook-l] RE: different open content licenses

body:
Mav wrote:
>We can discuss the possibility of changing license terms
>when somebody finds an impressive non-FDLd free text
>resource whose copyright owner declines our nicely-worded
>request to grant us a GFDL license of their work.

We are creating new content. If we want to use wikipedia
content we can link to it, as I linked to the periodic table.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Catholicism

body:
james-

>> . . . I have now edited the policy
>> to favor my interpretation -- this is of course open to discussion.

> Surely some contradition, Erik?

Not at all, James. Wikipedia policy pages can be openly edited by anyone,
as they could always be.

Regards,

Erik


subject: [Wikitech-l] Re: Phase IV

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> Anthere-
> > Recently, a new editor (a french language teacher)
> got
> > on the french wiki. He insists on using these
> > unbreakable spaces.
>
> I don't think that's a good idea. It only makes
> pages harder to edit
> because of the ugly HTML entities.

I know.

This is also why I remove the div tag after he used it
for the second time on the same day (the first being
on *my* page)

And why I don't like the anchors he is putting
everywhere. Since most of his articles are very long
(but very good and interesting as well), he puts some
anchors in the text, so links from other articles may
lead to the good paragraph in the very meaty one.

All this is good, but I dare not (and he wishes me not
to) edit article such as the one on greek religion to
avoid messing with the anchors.

This is very unwiki ihmo,

but when I protest, he says I am not the boss and this
is only *my* opinion, and that I am forcing my desire
of simplicity upon others, to the detriment of quality
articles, which may be long, with sankrit or greek or
whatever characters, and anchors, and non-breakable
spaces, and div spaces :-((((

http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&action=edit

This one is a nightmare to me.
I have no idea what other people see here, but as for
myself, it is scarry

And since other editors either don't say anything or
push the use of anchors, complicated html codes, fancy
small bars, div tags and such, who am I to say
anything all alone ???

This desolate me, but if the consensus is to make
editing difficult, I can only try to salvage my little
area of edition.

> > Here is my edit (I was removing a div in a talk
> page,
> > use of div is becoming more and more common, as
> well
> > as use of anchors to support 40 or 50 kb pages)
>
> >
>
http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82635&oldi
> > d=82624
>
> > And here is Vincent next edit, restoring manually
> all
> > the non-breakable spaces behind me
>
> >
>
http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82637&oldi
> > d=82635
>
> I don't see how anything was "broken" by your
> browser and I strongly doubt
> that Netscape would have any such bug. Vincent
> inserted the  s for
> the first time in the above edit after yours, as the
> page source code for
> the earlier revision shows. Any changes in display
> he noticed are likely
> the result of how his browser handles word/character
> wrapping, which may
> change when more words/characters are added. It
> could also be that he
> pasted the text from some word processor and
> inserted hard spaces in that
> application, which were lost during the copy and
> pasting.

Ah, yes, he absolutely does so. Word processor.

I know because he lectured me on the fact I didnot
know the proper usage of non-breakable spaces (which I
do, but do not respect in the least ;-)). He gave me a
link to a page explaining how to do non-breakable
spaces from my editor. He also said any decent editor
was supporting writing properly good french, and that
I should not edit anything even on talk pages without
having first run the grammatical/typo corrector.
Because my editing without accents, and with spelling
mistakes on talk pages was not respectful of readers.
'Cause we were not a chat, but an encyclopedia

We've got to be serious ! This is no joke work !

:-(((((( !!!!!

But there is *no* grammatical/typo corrector on a wiki
edit page :-((

All I can conclude from this comment is that he is
indeed writing all what he upload to wiki on a Word
(or equivalent) editor first hand. Is that usual ???
It happens I prepare long articles on Word before, or
that I save text on simpletext when there are lags, to
avoid loosing them, but all I write is just straight
edited in wiki.

The only other person I apparently messed text a
couple of times on our pump is Aoineko.

Do you remember Aoi ? Do you write sometimes your text
on editors rather than on wiki edit windows ?

> is quite obvious that your edits did not break
> anything because the
>  s Vincent added were still there after your
> further edits to the
> same page.

Well, I will try to explain that to him
But he will probably answer that I am the only one
doing so with his non breakable editor spaces.

Thanks Erik

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikitech-l] Phase IV

body:
Timwi-

> the past few days I've been experimenting a bit with Apache, mod_perl,
> MySQL and creating an entire own website. I've never done that before,
> and I think I've learnt a lot from this.

Great. mod_perl rules. Are you using DBI? In that case, it should be
relatively easy to switch to PostgreSQL.

I encourage you to move forward with this, and to commit all code to a
separate CVS module. The current code design is very messy, and there's a
lot that can be done to improve it. But do not underestimate the
complexity of the current software -- you will be spending months on this
to get as far as we have. If you don't want to do this, you will end up
very disappointed and frustrated because we won't adopt an incomplete
solution. Any new version should at least have the features listed here:

http://wikipedia.sourceforge.net/features.html

That's a *lot*. In addition, if you really want to provide advantages over
the current codebase, please *document* your code. The current codebase is
horribly documented and I still haven't bothered to figure out through
line by line reading what every function does. Perldoc is a great way to
do this. The current documentation of your database schema is completely
insufficient, though. Each table needs its own comment header explaining
what it does, how and why.

Regarding interlanguage links, note that the problem is quite complex:
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/
2025

Here is some other stuff that would be important for a redesign:
* have some kind of built in profiling
* test each query on a large dataset before including it
* have some better way to handle edit conflicts, for example, CVS style
merging
* have a better way to handle discussions, e.g. "Post a comment", "Reply
to this", but still do it using wholly editable wiki-pages
* have a category system built right in, perhaps using a meta namespace
* have better image handling with auto-rescaling:
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/
2024
* have a template system that can be used by the wiki user:
http://marc.theaimsgroup.com/?l=wikitech-l&m=105557077500936&w=2
this could perhaps be combined with the general template system.

Regards,

Erik


body:
Kurt-
> I suggested on the German list to turn off our page counter, like the
> English Wp did long ago.

Done.

Regards,

Erik


list: wikipedia-l

subject: [Wikipedia-l] PNG format???

body:
Ralphem-
> Eric,
> There is a basic problem with your logo, logo contest, and use of art in
> general -- a good number of us out here cannot see them!

Then you can't see the current Wikipedia logo either. It is and has always
been in PNG format. GIF has patent problems (the European, Japanese and
Canadian patent won't expire until June 2004) and may therefore even be
incompatible with the FDL's requirement of format transparency. JPEG is a
lossy format. PNG is perfect for logos and screenshots. All modern
browsers support it; Mozilla, a powerful, modern browsers is available for
most platforms, including MacOS 9 (only version 1.21, but that's less than
a year old):

http://www.mozilla.org/releases/#1.2.1

Regards,

Erik


subject: [WikiEN-l] Catholicism

body:
Daniel-
> An editor /cannot/ unilaterally change policy.

An editor (everyone is an editor on Wikipedia, so you might as well say "a
user") can change policy pages if there are no objections to them doing
so. They should use common sense to determine whether their change would
require prior discussions, or be reasonably minor or non-controversial not
to. The same principle applies to edits of non-policy pages. Be bold in
updating policy pages.

Regards,

Erik


from_name: Andre Engels

subject: [Wikitech-l] Inter-language links

body:
On Thu, 24 Jul 2003, Arwel Parry wrote:

> Having started to put links between articles in different language
> wikis, I wonder if it would be possible to create a process (a bot?) to
> occasionally search through all the interlanguage links to make sure
> that there is a reverse link back to the original wiki e.g.
>
> If we have [[cy:Yr_Ariannin]] linking to [[en:Argentina]]
> [[es:Argentina]] [[pt:Argentina]] [[pl:Argentyna]] and so on, the
> process would check if there's a link in each of those wikis back to
> [[cy:Yr_Ariannin]] and if not, automatically create a link. I think it
> would help to tie the different wikis together into one overall
> Wikipedia.
>
> Anyone think this is a reasonable idea, or how to do it?

On nl: Erik Zachte is already running such a script (semi-automatically,
because not rarely there is an error in these links). He seems to have
decided against changing the links on the other languages too because
some of them are quite strongly against bots.

Andre Engels


from_name: Fred Bauder

subject: [Wikitech-l] The New French Editor, was Re: Phase IV

body:
Well, you've got to bring it to a head. Pick something of his and edit it.
And fight it out. Otherwise you're letting him establish a custom and
practice that in the long run is unacceptable. Basically he is what we used
to call "taking position" on you. More or less in the manner of Larry
Sanger.

Let him worry about the anchors...just bull ahead...

That you are in essence poking what seems to be a skunk, albeit a pretty
French one, will tell you the sacrifices you must bear...

The alternative is to permit him ownership of the article, an option not
permitted by current Wikipedia policy (although I don't happen to be in
agreement with it).

Fred Bauder

http://wwww.internet-encyclopedia.org

> From: Anthere <anthere6 at yahoo.com>
> Reply-To: wikitech-l at wikipedia.org
> Date: Fri, 25 Jul 2003 08:22:02 -0700 (PDT)
> To: wikitech-l at wikipedia.org
> Subject: Re: [Wikitech-l] Re: Phase IV
>
>
> --- Erik Moeller <erik_moeller at gmx.de> wrote:
>> Anthere-
>>> Recently, a new editor (a french language teacher)
>> got
>>> on the french wiki. He insists on using these
>>> unbreakable spaces.
>>
>> I don't think that's a good idea. It only makes
>> pages harder to edit
>> because of the ugly HTML entities.
>
> I know.
>
> This is also why I remove the div tag after he used it
> for the second time on the same day (the first being
> on *my* page)
>
> And why I don't like the anchors he is putting
> everywhere. Since most of his articles are very long
> (but very good and interesting as well), he puts some
> anchors in the text, so links from other articles may
> lead to the good paragraph in the very meaty one.
>
> All this is good, but I dare not (and he wishes me not
> to) edit article such as the one on greek religion to
> avoid messing with the anchors.
>
> This is very unwiki ihmo,
>
> but when I protest, he says I am not the boss and this
> is only *my* opinion, and that I am forcing my desire
> of simplicity upon others, to the detriment of quality
> articles, which may be long, with sankrit or greek or
> whatever characters, and anchors, and non-breakable
> spaces, and div spaces :-((((
>
>
> http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&action=edit
>
> This one is a nightmare to me.
> I have no idea what other people see here, but as for
> myself, it is scarry
>
> And since other editors either don't say anything or
> push the use of anchors, complicated html codes, fancy
> small bars, div tags and such, who am I to say
> anything all alone ???
>
> This desolate me, but if the consensus is to make
> editing difficult, I can only try to salvage my little
> area of edition.
>
>>> Here is my edit (I was removing a div in a talk
>> page,
>>> use of div is becoming more and more common, as
>> well
>>> as use of anchors to support 40 or 50 kb pages)
>>
>>>
>>
> http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82635&oldi
>>> d=82624
>>
>>> And here is Vincent next edit, restoring manually
>> all
>>> the non-breakable spaces behind me
>>
>>>
>>
> http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82637&oldi
>>> d=82635
>>
>> I don't see how anything was "broken" by your
>> browser and I strongly doubt
>> that Netscape would have any such bug. Vincent
>> inserted the  s for
>> the first time in the above edit after yours, as the
>> page source code for
>> the earlier revision shows. Any changes in display
>> he noticed are likely
>> the result of how his browser handles word/character
>> wrapping, which may
>> change when more words/characters are added. It
>> could also be that he
>> pasted the text from some word processor and
>> inserted hard spaces in that
>> application, which were lost during the copy and
>> pasting.
>
> Ah, yes, he absolutely does so. Word processor.
>
> I know because he lectured me on the fact I didnot
> know the proper usage of non-breakable spaces (which I
> do, but do not respect in the least ;-)). He gave me a
> link to a page explaining how to do non-breakable
> spaces from my editor. He also said any decent editor
> was supporting writing properly good french, and that
> I should not edit anything even on talk pages without
> having first run the grammatical/typo corrector.
> Because my editing without accents, and with spelling
> mistakes on talk pages was not respectful of readers.
> 'Cause we were not a chat, but an encyclopedia
>
> We've got to be serious ! This is no joke work !
>
> :-(((((( !!!!!
>
> But there is *no* grammatical/typo corrector on a wiki
> edit page :-((
>
> All I can conclude from this comment is that he is
> indeed writing all what he upload to wiki on a Word
> (or equivalent) editor first hand. Is that usual ???
> It happens I prepare long articles on Word before, or
> that I save text on simpletext when there are lags, to
> avoid loosing them, but all I write is just straight
> edited in wiki.
>
> The only other person I apparently messed text a
> couple of times on our pump is Aoineko.
>
> Do you remember Aoi ? Do you write sometimes your text
> on editors rather than on wiki edit windows ?
>
>> is quite obvious that your edits did not break
>> anything because the
>>  s Vincent added were still there after your
>> further edits to the
>> same page.
>
> Well, I will try to explain that to him
> But he will probably answer that I am the only one
> doing so with his non breakable editor spaces.
>
> Thanks Erik
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Thomas R. Koll

subject: [Wikipedia-l] PNG format???

body:
On Thu, Jul 24, 2003 at 09:11:07PM -0400, Ralphem at aol.com wrote:
> latest "fireworks" or whatever in order to just view a common page. Backward
> compatibility is an important concept, and is worth keeping whenever possible.

Please shorten your lines to 75-80, for backward-compatibility (BC).
Sure BC is important, but it's 2003 and those still using hard and
software from 1999 are mad in my eyes. The world's turning and the internet
is even faster.

> Most of us are still using dialup 56K modems out in the world -- web entities that
> load up their pages with sophisticated cutting-edge animations and hi-res
> long-loading photos and art are virtually assured of loosing me and millions of
> others as potential viewers. Same thing applies with your art -- coding your
> artwork in PNG format closes out a lot of potential viewers -- put them JPEG and
> your viewership and useability will increase.

Do you know why the WP is soo slow? It's not the few images but the heavy
user load. I think none of the developers ever thought about putting in more
images than needed.

Take a look a Amazon.com or any
> other highly successful web business -- their pages open just as pretty in my
> Mac as they do in the latest Pentium blazer, and they don't use advanced
> formats. Let's keep it low tech -- PNG is an unnecessary complication for the
> project. Thanks for listening.

Amazon.com is making money with it's website. We aren't. We are volunteers and
thus don't have any pressure from people living in 1998.
Don't forget, it's just a small logo in the upper left corner. If you don't
see it you won't miss anything.

ciao, tom

--
http://www.tomk32.de - just a geek trying to change the world
   -.-       http://de.wikipedia.org/wiki/Benutzer:TomK32
   /|>	         Bonsai - http://bonsaiwiki.tomk32.de
   / \              http://tomk32.bookcrossing.com


body:
Rotem-
> Please update LanguageHe.php from meta.

Every Wikipedia should have a person with CVS access committing
translation updates, which will then go live automatically with the next
CVS update. I have no problem with you having CVS access, since these
changes automatically all go to the same codebase. Please write Brion, Lee
or Magnus who are the ones handling CVS access. Remember to tell them your
SourceForge account name.

Regards,

Erik


from_name: tarquin

subject: [Wikitech-l] Re: Phase IV

body:
Timwi wrote:

>
>> As for the wiki syntax parser, I wouldn't want to rewrite that! (I
>> hate parsers!)
>
>
> This is actually the part I'm looking forward to! (Since, as mentioned
> before, I love regexps ;-) )
>
If you're using perl...
http://wiki.beyondunreal.com/wiki/Wookee

wiki parser in perl, free for use. Produces correct HTML (ie all <p>
elements are correctly closed!)


body:
--- Fred Bauder <fredbaud at ctelco.net> wrote:
> Well, you've got to bring it to a head. Pick
> something of his and edit it.
> And fight it out. Otherwise you're letting him
> establish a custom and
> practice that in the long run is unacceptable.
> Basically he is what we used
> to call "taking position" on you. More or less in
> the manner of Larry
> Sanger.
>
> Let him worry about the anchors...just bull ahead...
>
> That you are in essence poking what seems to be a
> skunk, albeit a pretty
> French one, will tell you the sacrifices you must
> bear...
>
> The alternative is to permit him ownership of the
> article, an option not
> permitted by current Wikipedia policy (although I
> don't happen to be in
> agreement with it).
>
> Fred Bauder

yup; quite true

Update : I posted Erik answer on our pump.

Vincent comment was that I was intellectually
dishonest, as the message was clearly from me,
pretending to be someone called Erik. In short, he
said the answer was a forgery !

I also decided not to be *too* bold, and before
reworking the article, I matter of factly proposed a
solution for division of the article and renaming.

Vincent only answer was "I said I would take care of
it myself"

That is all. I think that won't make it :-)

Anthere

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Delirium

subject: [Wikipedia-l] request of permission

body:
Daniel Shalev wrote:

>  I was not able to find a "contact us" or a "public relations" email
> address of wikipedia, so please redirect this letter to the
> appropriate person.

In general we're a community-consensus-driven project, so this is
probably the best place to ask questions.  If you do need to contact the
project leader (our "benevolent dictator") at some point for a more
'official' response, he's Jimbo Wales, at jwales at bomis.com.  But usually
that's not necessary, especially since he reads this list as well.

> I wrote an unconventional hyperlinked online booklet on ecology.
> http://www.geocities.com/tgcp2084
> I put your URL http://www.wikipedia.org/wiki/Middle_Ages as one of the
> hyperlinked references of it.
> Please send me a note if you have any objection, and your URL  will be
> eliminated from the reference list.
> Your site has been cited in the specific
> page http://www.geocities.com/tgcp2084/2threatnature.html
>
> I plan to put more hyperlinked references from wikipedia, since the
> style and content of wikipedia is much appropriate to the criteria
> explained in the reference page
> http://www.geocities.com/tgcp2084/reference.html

Linking to Wikipedia is always okay, so the references list is fine, and
in fact we like the added exposure.

The only time you have to comply with specific requirements is if you
actually take text from Wikipedia and incorporate it into your page.
You are allowed to do this, but you must comply with the GNU Free
Documentation License if you do.  The easiest way to do so is to put a
notice "This page licensed under the GNU FDL" at the bottom of your page
(with a link to the license text at
http://www.gnu.org/licenses/fdl.txt), along with a link to the Wikipedia
article you copied the text from.

Some additional information may be found at:
http://www.wikipedia.org/wiki/Wikipedia:Copyrights

However, you do not appear to actually be using Wikipedia text (as far
as I can tell), just linking to Wikipedia itself, so you don't even have
to do that, and your page as it currently stands is fine.

-Mark


subject: [Wikitech-l] Re: Phase IV

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> I don't see how anything was "broken" by your
> browser and I strongly doubt
> that Netscape would have any such bug. Vincent
> inserted the  s for
> the first time in the above edit after yours, as the
> page source code for
> the earlier revision shows. Any changes in display
> he noticed are likely
> the result of how his browser handles word/character
> wrapping, which may
> change when more words/characters are added. It
> could also be that he
> pasted the text from some word processor and
> inserted hard spaces in that
> application, which were lost during the copy and
> pasting. In any case, it
> is quite obvious that your edits did not break
> anything because the
>  s Vincent added were still there after your
> further edits to the
> same page.

Thank Shai for trusting me :-)

Vincent replied the example chosen was not good

I tried to translate his comment below

:?videmment, l'exemple choisi ne fonctionne pas
puisque presque tout le texte appara?t comme modifi?.
On ne voit donc pas le d?tail des op?rations.
Maintenant, regardons avec
[http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&diff=71928&oldid=71914
un exemple pertinent] : que voit-on ? Outre les
changements volontaires, tous les mots encadr?s par
<??> ou pr?c?dant <:> et <;> sont marqu?s en rouge. Il
est pourtant improbable qu'Anthere ait remplac? tous
ces termes et les signes de ponctuation par la m?me
chose, car c'est bien ce que l'on semble constater
(par exemple, ''ligne 1'' : ? Note : ? est remplac?
par ? Note : ?, etc.). Or, si l'on prend la peine de
regarder dans le d?tail ce qui a ?t? modifi?, il
suffit d'utiliser un ?diteur hexad?cimal et de
regarder la source, on voit qu'il s'agit des...
espaces ins?cables, situ?es justement devant <:> et
<;>, apr?s <?> et avant <?> (entre autres).

:Je prends toujours la ''ligne 1'', ? partir de ? Note
? jusqu'au deux-points ; que dit l'?diteur ?
:* version ant?rieure : 4E 6F 74 65 A0, ce qui
correspond ? ''N'', ''o'', ''t'', ''e'', ''[ ] (espace
ins?cable)'' ;
:* version corrig?e : 4E 6F 74 65 20 ; ce qui
correspond ? ''N'', ''o'', ''t'', ''e'', ''[ ] (espace
normale)''.

:On peut s'amuser ? v?rifier cela avec n'importe quel
autre mot en rouge qui semble correspondre dans la
version corrig?e exactement ? ce qui est pr?sent dans
la version ancienne. ? chaque fois, le caract?re
U+00A0 devient U+0020. Pour ?viter cela, j'ai pris le
parti de corriger le caract?re brut U+00A0 en entit?
html <nowiki> </nowiki> ce qui, je l'accorde,
rend le code disgracieux.

-----------
Naturally, the chosen example does not work since most
of the text appears modified. One can't see the
details of the modifications. Now, let's consider

[http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&diff=71928&oldid=71914
a great example] : what do we see ?

Apart from volontary changes, all the words bordered
(?) by  <??> or before <:> et <;> are in red. However,
it is unlikely that Anthere has replaced all this
words (note : I did not) and all the punctuation signs
by the same thing, though it is what it appears to be

For example,  ''line 1'' : ? Note : ? is replaced by ?
Note : ?, etc.). If we take great care to look in
detail what has been modified, it is sufficient to use
a hexadecimal editor and to consider the source. One
can see that it is precisely ... non-breakable spaces,
just before  <:> and <;>, after <?> and before <?>
(among others).

''line 1'' also, from ? Note ? to the double points,
what does the editor says ?

:* anterior version : 4E 6F 74 65 A0, which
corresponds with ''N'', ''o'', ''t'', ''e'', ''[ ]
(non breakable space)'' ;
:* corrected version : 4E 6F 74 65 20 ; which
corresponds with ''N'', ''o'', ''t'', ''e'', ''[ ]
(normal space)''.

One can play checking this with any other red word
which appear to fit in the corrected version with the
anterior version. Each time, the character  U+00A0 is
transformed in U+0020. To avoid this, I decided to
correct the raw character U+00A0 in an html entity
<nowiki> </nowiki>, which is, admitedely, ugly.

--------

Anthere : so ? :-(

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikitech-l] Re: Re: Phase IV

body:
--- Vincent Ramos <siva-nataraja+spam at alussinan.org>
wrote:
> Le Fri, 25 Jul 2003 06:25:44 -0700 (PDT), Anthere
> <anthere6 at yahoo.com> wrote
>
> > Recently, a new editor (a french language teacher)
> got
> > on the french wiki. He insists on using these
> > unbreakable spaces. As far as I know, he is the
> only
> > one.
>
> You should see what other say; for instance Didup,
> Panoramix (I quote: "Je
> suis l'un des integristes de la typographie ici (je
> mets des vrais
> guillemets, des espaces insecables, etc.")), Mokona,
> etc.

Key word : integrist :-) (you said it)

> > However, for some reasons I can't explain, my
> browser
> > (a brand new one, last version, unicode friendly,
> page
> > over 32 kb friendly, etc...) appears to be
> "breaking"
> > these spaces. Though I can't figure how it is
> doing
> > so. When I look at the history, I see nothing I
> can
> > explain.
>
> > Still, Vincent insists that I do break his text.
> To
> > fix it, he has to either revert my changes, or fix
> > them himself, isssue upon which he is strongly
> > complaining so requesting that I fix the stuff
> myself.
> > Fact is, I can't see what I do wrong, and I can't
> > imagine myself editing by hand his comments myself
> > each time I edit an article or talk page, to avoid
> > removing the non-breakable space (if only I could
> > figure how not to do so !)
>
> Well, let me give you a real example:
>
<http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&diff=71928&oldid=71914>
> If you had looked at the source with an hexadecimal
> editor, you could have
> seen (first line, from "Note" to ":"):
>
> * my version: 4E 6F 74 65 A0, that is <N>, <o>, <t>,
> <e> and <[ ]> (non-
> breakable space);
> * Anthere's version: 4E 6F 74 65 20 ; that is <N>,
> <o>, <t>, <e>, <[ ]>
> (space).
>
> Thus, Anthere made U+00A0 (NBSpace), a normal raw
> ISO-8859-1 character,
> become U+0020, the normal space.
>
> Anyone can verify this fact
>
> Vincent Ramos

Yes. Anyone. But then what do you suggest ?

To a certain point, I do not care whether you or I are
responsible of this. Clearly, our editing ways are
incompatible. Still we are on the same place, so we
need to find a solution

Five solutions

1) a technical explanation and solution is found, and
you or I is able to make it up to solve the technical
issue

2) You clearly see that I can't do anything to avoid
this, so each time you edit a page, and I edit it
after you, you go after me without complaining and
correct each and other non-breaking space (admitedly,
that makes a lot)

3) Each time you write an article, you put your name
at the top of the page, and we officially declare I am
forbidden to edit this page. Potentially an issue in
terms of wiki principle

4) You or I agree to quit wikipedia

5) We do not accept non-breakable spaces on the french
wikipedia

So ? Does anyone has an idea for option 1 ?

Cheers

Anthere

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikitech-l] Re: Re: Phase IV

body:
--- Vincent Ramos <siva-nataraja+spam at alussinan.org>
wrote:
> Le Fri, 25 Jul 2003 08:22:02 -0700 (PDT), Anthere
> <anthere6 at yahoo.com> a ???crit:
>
> > All this is good, but I dare not (and he wishes me
> not
> > to) edit article such as the one on greek religion
> to
> > avoid messing with the anchors.
>
> I've just told you how you could do this; rather
> simple but daunting.

No problem. We'll get rid of anchors. That will make
the moves easier

> > This is very unwiki ihmo,
> > but when I protest, he says I am not the boss and
> this
> > is only *my* opinion, and that I am forcing my
> desire
> > of simplicity upon others, to the detriment of
> quality
> > articles, which may be long, with sankrit or greek
> or
> > whatever characters, and anchors, and
> non-breakable
> > spaces, and div spaces :-((((
>
> What kind of behavior is this? Will you then start
> crying?

I'll tell you :-)

> > Ah, yes, he absolutely does so. Word processor.
>
> Laugh. I do not even own it; I use Babelpad, a raw
> Unicode text editor
> <http://uk.geocities.com/BabelStone1357>. But you
> still believe I'm wrong;
> please look a the raw source of your modifications
> with an hexadecimal
> editor.

That is not the point. What is important ? The fact I
am responsible or the fact you are ?

None. What is a problem is that *you* complain you
have to edit all the time after me. This is what
matter. Not  anything else

> >> is quite obvious that your edits did not break
> >> anything because the   s Vincent added were
> still there after your
> >> further edits to the  same page.
>
> Of course: Anthere only modifies U+00A0, and not
> html entities.
>
> > Well, I will try to explain that to him
> > But he will probably answer that I am the only one
> > doing so with his non breakable editor spaces.
>
> No.

Ah ? You mean you have similar problems with others
than me ? That is interesting !

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikitech-l] Re: Re: Phase IV

body:
For the record, some of the comments I attributed to
Vincent (intellectual dishonesty) were from a troll. I
apologize then. I would have appreciated that he
indicated before that he did not voice these comments
however :-(

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: The Cunctator

subject: [WikiEN-l] Daniel C. Boyer on wikipedia

body:
On 7/25/03 12:37 AM, "james duffy" <jtdirl at hotmail.com> wrote:

> The Daniel C. Boyer bandwagon is getting a bit out of control. Daniel is a
> user on wiki who has an article about himself on wiki. While that seems OK
> as he is a real if rather minor celebrity and artist, his articles relating
> to himself are breeding like rabbits.
>
I fail to see the problem. Wikipedia is meant to be a universal
encyclopedia.


subject: [Wikitech-l] Re: Phase IV

body:
Erik Moeller wrote:

>>the past few days I've been experimenting a bit with Apache, mod_perl,
>>MySQL and creating an entire own website. I've never done that before,
>>and I think I've learnt a lot from this.
>
> Great. mod_perl rules. Are you using DBI? In that case, it should be
> relatively easy to switch to PostgreSQL.

Does PostgreSQL support replication?

> I encourage you to move forward with this, and to commit all code to a
> separate CVS module.

Well, to be entirely honest, I'd rather not use the SourceForge CVS
server. It's cumbersome and full of problems. It doesn't work in Linux
for me, and in Windows I have to keep entering my password for every
single request (not just the commits).

> The current code design is very messy

So *that's* why I didn't understand a bit of it! ;-)

> If you don't want to do this, you will end up
> very disappointed and frustrated because we won't adopt an incomplete
> solution. Any new version should at least have the features listed here:
> http://wikipedia.sourceforge.net/features.html

Whee. You have a list of requirements. That is a Very Good Thing Indeed.
I guess I'll copy this to my User page and then tick things off as I
finish them.

> That's a *lot*. In addition, if you really want to provide advantages over
> the current codebase, please *document* your code.

Yep. If there's one thing I hate, it's missing documentation. However, I
like doing it later. Once the thing is finished and I know it works and
does not need any more significant change, I can document it, or else
the documentation will have been for nothing.

> I still haven't bothered to figure out through
> line by line reading what every function does.

I have, and I couldn't make much of it :-) I didn't have that many
problems with LJ's code, even though it's equally badly documented. (And
no, I don't think it's solely because of PHP.)

> Perldoc is a great way to do this.

OK. I've thought about using some sort of documentation system like
that. I've never done that before though. I'll have a look.

> The current documentation of your database schema is completely
> insufficient, though. Each table needs its own comment header explaining
> what it does, how and why.

Yes, of course I understand this. I didn't do this yet for the reasons
mentioned above. Even now I have already changed some tables again. I'll
document them when I feel I'm happy with them as they are.

> Here is some other stuff that would be important for a redesign:
> * have some kind of built in profiling

What exactly does this mean?

> * test each query on a large dataset before including it

Yep

> * have some better way to handle edit conflicts, for example, CVS style
> merging
> * have a better way to handle discussions, e.g. "Post a comment", "Reply
> to this", but still do it using wholly editable wiki-pages
> * have a category system built right in, perhaps using a meta namespace

Already planned (though that latter one would be near the bottom of the
list)

> * have better image handling with auto-rescaling:
> http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/
> 2024

This seems to assume that images would have to be stored in a file
system. I think it's better to store them in a database, possibly one
separated from the rest.

> * have a template system that can be used by the wiki user:
> http://marc.theaimsgroup.com/?l=wikitech-l&m=105557077500936&w=2
> this could perhaps be combined with the general template system.

I have indeed planned such a template system, but I'm not sure what you
mean by the "general template system". Is that referring to the site
skin system? I'd really rather keep those two separate. They are not
related enough concepts.

Greetings and thanks,
Timwi


body:
Good to know it was all a false alarm...

Fred Bauder

http://www.internet-encyclopedia.org

> From: Vincent Ramos <siva-nataraja+spam at alussinan.org>
> Organization: Les Dieux anciens r?unis
> Reply-To: wikitech-l at wikipedia.org
> Date: Fri, 25 Jul 2003 21:36:30 +0200
> To: wikitech-l at wikipedia.org
> Subject: [Wikitech-l] Re: The New French Editor, was Re: Phase IV
>
> Le Fri, 25 Jul 2003 09:47:08 -0600, Fred Bauder
> <fredbaud at ctelco.net> wrote:
>
>> Well, you've got to bring it to a head. Pick something of his and edit
>> it.
>
> Thanks.
>
>> And fight it out. Otherwise you're letting him establish a custom and
>> practice that in the long run is unacceptable. Basically he is what we
>> used to call "taking position" on you. More or less in the manner of
>> Larry
>> Sanger.
>
> You really should not try to judge people without knowing what they have to
> say.
>
>> Let him worry about the anchors...just bull ahead...
>> That you are in essence poking what seems to be a skunk, albeit a pretty
>> French one, will tell you the sacrifices you must bear...
>
> Bravo. That's a kind of incisive judgement I find rather displaced: when
> one only knows what another one tells about someone (did you ever think
> Anthere could be wrong?) and takes it for granted whithout even verifiying
> the facts.
>
>> The alternative is to permit him ownership of the article, an option not
>> permitted by current Wikipedia policy (although I don't happen to be in
>> agreement with it).
>
> I've *never* asked this. And whoever can modify the pages I wrote.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


subject: [Wikitech-l] Re: Phase IV : a troubling point about browsers

body:
--- Jens Frank <JeLuF at gmx.de> wrote:
> On Fri, Jul 25, 2003 at 08:55:23PM +0100, tarquin
> wrote:
> >
> >
> > Jens Frank wrote:
> >
> > >
> > >Despite this I think wiki software for French
> Wikipedia
> > >should be changed to insert  's around
> colons, brackets,
> > >etc pp. to automatically render "good French" at
> reasonable
> > >editing efforts. Having those blanks unbreakable
> is what a
> > >computer should have to care about, not an
> editor.
> > >
> > >
> > It *should* be the web browser that does this!
> >
> Agreed, but I think it might be easier to update
> wikipedia software than all available browsers.
>
> JeLuF

Errr...a point came to my mind...

I switch my browser about a month ago

Mine was an old Opera. I had trouble with long pages,
and messed meta quite often as it did not support
unicode. But had no pb with it on the french wiki
about one good month ago when some northern characters
appeared in a myth article. I then discovered I messed
some characters.

To suit Vincent needs, I really looked for another
browser which could work on my system (mac os 9). And
I finally found Netscape 7

The th? chinois article given as an example by Vincent
is an article I edited with Opera 5. And that is after
discussions with Vincent that I concluded my only
three options were either to buy a new computer, or to
quit wikipedia, or to find a unicode friendly
navigator. Which I did.

The example I put this afternoon was done recently,
under my new browser.

So...the same problem is occuring under Opera 5 and
Netscape 7. Vincent claims it is my browser. So these
are my browserS. Or my system. Or my plateform. Or
what ?

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikipedia-l] Re: PNG format???

body:
Ralphem at aol.com wrote:

> JPEG AND GIF are the standards for use on the web

In addition to what other people have already mentioned (JPEG is lossy
and thus unsuitable for logos and other discrete-tone graphics; GIF is
(currently) patent-contaminated and therefore cannot be used with GFDL),
I would also like to point out that GIF has a lot of actual technical
limitations that, in themselves, already make it not a choice for most
application:
* Limited to 256 colours
   * Therefore, in a sense, also lossy. A >256 colour image will need to
     be reduced in colour depth. This results in dithering or diffusion,
     which greatly hurts the compression ratio
* Only single-colour transparency
* gzip compression (which PNG uses) often outperforms the patented
   LZW compression (which GIF uses)

I really hate GIF. Does it show?

Timwi


subject: [Wikitech-l] Re: The New French Editor, was Re: Phase IV

body:
--- Vincent Ramos <siva-nataraja+spam at alussinan.org>
wrote:
> Le Fri, 25 Jul 2003 11:45:05 -0700 (PDT), Anthere
> <anthere6 at yahoo.com> wrote:
>
>
> > Update : I posted Erik answer on our pump.
> > Vincent comment was that I was intellectually
> > dishonest, as the message was clearly from me,
> > pretending to be someone called Erik. In short, he
> > said the answer was a forgery !
>
> It's a shame! I never wrote that; just look at the
> history. The text is
> even not well written (lacks a capital, does not use
> the right quote marks,
> etc.). Frankly, this is disgusting and, there, you
> are making a forgery. I
> can not believe you think *I* wrote this.

which is precisely why I apologized for not having
recognise a troll at

http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/005164.html

and on your talk page.

I agree a lack of capital and wrong quote marks are
definitly signs I should have noticed. you are the one
who express himself the best on the fr wiki.

Now, you may wish to go on fueling the troll with
screaming and bad words, it will just do what he
wanted to get in doing so.

Which would not solve our problem in any way :-)

> > I also decided not to be *too* bold, and before
> > reworking the article, I matter of factly proposed
> a
> > solution for division of the article and renaming.
> > Vincent only answer was "I said I would take care
> of
> > it myself"
>
> Yes, because, as I've already told, it's rather
> boring to do I do know
> where the links are.

Vincent. This is *precisely* why anchors are wrong.
When it comes to a point only the main editor (or
should I say the only ?) is able to edit, rename,
rework, add, remove to an article, because of a
complex linking system, there is a problem. That is
exactly what I mean by simplicity of edition. And no,
it is not only *my* agenda to support this. That is
what I have been trying to explain to you. You say you
want other editors to edit your text, but at the same
time, you say you would prefer they do not do so,
because the link system is tough, and only you know
where the links are. Well, yes, an article should not
have only one author, and everyone should rework it
without fear of messing the whole place.

Please, if you do not understand that, say so here, so
that perhaps somebody else explain better than I do.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Daniel Shalev

subject: [Wikipedia-l] request of permission

body:
Dear Sirs,
 I was not able to find a "contact us" or a "public relations" email address of wikipedia, so please redirect this letter to the appropriate person.

I wrote an unconventional hyperlinked online booklet on ecology. http://www.geocities.com/tgcp2084
I put your URL http://www.wikipedia.org/wiki/Middle_Ages as one of the hyperlinked references of it.
Please send me a note if you have any objection, and your URL  will be eliminated from the reference list.
Your site has been cited in the specific page http://www.geocities.com/tgcp2084/2threatnature.html

I plan to put more hyperlinked references from wikipedia, since the style and content of wikipedia is much appropriate to the criteria explained in the reference page http://www.geocities.com/tgcp2084/reference.html

I will be pleased to receive any comment/suggestions  from you about the online booklet.
(please note that the site is still in construction - you might encounter some error notifications - please ignore them)

                                                        Best regards
                                                        Daniel Shalev

                                                        ddshalev at netvision.net.il

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030725/80918dc6/attachment.htm


subject: [Wikitech-l] Re: Phase IV

body:
Timwi-
> Does PostgreSQL support replication?

There are several simple replication systems, DBMirror and RServ are part
of postgresql-contrib. For setting up RServ, see

http://techdocs.postgresql.org/techdocs/settinguprserv.php

I haven't tried any of them. There are many good reasons to use
PostgreSQL, though, and many good reasons to use MySQL, so it makes sense
to use a database interface layer in case we ever want to switch.

> Well, to be entirely honest, I'd rather not use the SourceForge CVS
> server. It's cumbersome and full of problems.

I never had any problems with it. Once it's set up properly, it seems to
work reasonably well. You could also set up a project at BerliOS or
Savannah:

http://developer.berlios.de/
http://savannah.gnu.org/

You definitely should use a CVS server if you expect any kind of
constructive contributions.

>> Here is some other stuff that would be important for a redesign:
>> * have some kind of built in profiling

> What exactly does this mean?

Keep a log of how much time is spent within each function so the parsing/
page generation process can be optimized accordingly. There are probably
ready-made CPAN modules for this.

>> * have some better way to handle edit conflicts, for example, CVS style
>> merging
>> * have a better way to handle discussions, e.g. "Post a comment", "Reply
>> to this", but still do it using wholly editable wiki-pages
>> * have a category system built right in, perhaps using a meta namespace

> Already planned (though that latter one would be near the bottom of the
> list)

Categories will likely go live soon (if Magnus finally finishes the damn
thing), so a compatible scheme needs to be in place if we want to switch
over.

>> * have better image handling with auto-rescaling:
>> http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/
>> 2024

> This seems to assume that images would have to be stored in a file
> system. I think it's better to store them in a database, possibly one
> separated from the rest.

I never understood this approach. It only seems to be associated with
increased risks (reduced performance, increased risk of data corruption)
and have no benefits. What exactly is the disadvantage of just storing a
pointer to the local filesystem in the DB?

>> * have a template system that can be used by the wiki user:
>> http://marc.theaimsgroup.com/?l=wikitech-l&m=105557077500936&w=2
>> this could perhaps be combined with the general template system.

> I have indeed planned such a template system, but I'm not sure what you
> mean by the "general template system". Is that referring to the site
> skin system? I'd really rather keep those two separate. They are not
> related enough concepts.

I do think there are similarities between the two. Any good template
system, for site skins OR for internal rendering, will have to support
things like loops, conditional blocks etc. This stuff needs to be parsed,
so you might as well use a single library for doing so.

You are using proper object-oriented design, I hope?

Regards,

Erik


subject: [Wikitech-l] Re: Phase IV

body:
Anthere-
> Recently, a new editor (a french language teacher) got
> on the french wiki. He insists on using these
> unbreakable spaces.

I don't think that's a good idea. It only makes pages harder to edit
because of the ugly HTML entities.

> Here is my edit (I was removing a div in a talk page,
> use of div is becoming more and more common, as well
> as use of anchors to support 40 or 50 kb pages)

> http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82635&oldi
> d=82624

> And here is Vincent next edit, restoring manually all
> the non-breakable spaces behind me

> http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82637&oldi
> d=82635

I don't see how anything was "broken" by your browser and I strongly doubt
that Netscape would have any such bug. Vincent inserted the  s for
the first time in the above edit after yours, as the page source code for
the earlier revision shows. Any changes in display he noticed are likely
the result of how his browser handles word/character wrapping, which may
change when more words/characters are added. It could also be that he
pasted the text from some word processor and inserted hard spaces in that
application, which were lost during the copy and pasting. In any case, it
is quite obvious that your edits did not break anything because the
 s Vincent added were still there after your further edits to the
same page.

Regards,

Erik


from_name: Guillaume Blanchard

subject: [Wikipedia-l] PNG format???

body:
Bonjour Ralph,
Personnaly I use PNG files since long time and never ran into any problem.
You can found part of your answer here :
http://www.gnu.org/philosophy/gif.html

Aoineko

----- Original Message -----
From: <Ralphem at aol.com>
To: <wikipedia-l at wikipedia.org>
Sent: Friday, July 25, 2003 10:11 AM
Subject: [Wikipedia-l] PNG format???

> Eric,
> There is a basic problem with your logo, logo contest, and use of art in
> general -- a good number of us out here cannot see them! ALL of the art on
your
> pages discusssing the logo contest come up with a red X in place of the
art. You
> discuss the fact that you want all logo designs in PNG format, but this is
a
> format that not all systems (Mac) and not all browsers (AOL 5.0, the only
> software available for older Power PC Macs) support -- so you are cutting
out a
> sizeable portion of potential viewership. I'm a graphic designer, but I've
never
> used, nor have I had to use, PNG format for any image. TIF, JPEG, GIF and
EPS
> are the standards for graphics, and JPEG AND GIF are the standards for use
on
> the web when people with non-graphic software or systems need to view
them.
> One of the guiding principles in the development of the web has been to
honor
> the common person, probably one using an older computer with
unsophisticated
> software, and not freeze them out by demanding they constantly download
the
> latest "fireworks" or whatever in order to just view a common page.
Backward
> compatibility is an important concept, and is worth keeping whenever
possible. Most
> of us are still using dialup 56K modems out in the world -- web entities
that
> load up their pages with sophisticated cutting-edge animations and hi-res
> long-loading photos and art are virtually assured of loosing me and
millions of
> others as potential viewers. Same thing applies with your art -- coding
your
> artwork in PNG format closes out a lot of potential viewers -- put them
JPEG and
> your viewership and useability will increase. Take a look a Amazon.com or
any
> other highly successful web business -- their pages open just as pretty in
my
> Mac as they do in the latest Pentium blazer, and they don't use advanced
> formats. Let's keep it low tech -- PNG is an unnecessary complication for
the
> project. Thanks for listening.
> Ralph McGeehan
> ralphem at aol.com
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Michael Becker

subject: [WikiEN-l] Daniel C. Boyer on wikipedia

body:
Sure, but if you read the [[Wikipedia:What Wikipedia is not]] page,
point 18 reads "A vehicle for advertising. We don't need articles on
items just because a contributor is associated with them. However,
commercial links are certainly OK if they can serve to identify major
corporations associated with a topic, as in Finishing school."
You can find plenty of other websites that talk about Daniel's works.
However, most of them seem to be listings of artist, that anyone can
post to.
Additionally, a lot of his edits have been to pages he created, were
pages that link back to [[Daniel C. Boyer]].  It's ridiculous, and
people wouldn't put up with it if he wasn't a member of the wikipedia
community.  In fact, we have deleted pages added by people about
themselves before (I seem to remember something about some guy trying to
put his crank theories on wikipedia).  It's a bit upsetting that we are
making an exception because he is a wikipedian.

--
Michael Becker

-----Original Message-----
From: wikien-l-admin at wikipedia.org [mailto:wikien-l-admin at wikipedia.org]
On Behalf Of The Cunctator
Sent: Friday, July 25, 2003 1.12
To: wikien-l at wikipedia.org
Subject: Re: [WikiEN-l] Daniel C. Boyer on wikipedia

On 7/25/03 12:37 AM, "james duffy" <jtdirl at hotmail.com> wrote:

> The Daniel C. Boyer bandwagon is getting a bit out of control. Daniel
> is a user on wiki who has an article about himself on wiki. While that

> seems OK as he is a real if rather minor celebrity and artist, his
> articles relating to himself are breeding like rabbits.
>
I fail to see the problem. Wikipedia is meant to be a universal
encyclopedia.

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Toby Bartels

subject: [Textbook-l] legal counsel on copyright issues

body:
Daniel Mayer wrote:

[nonsense]

Well, mav has pretty obviously not read a single word that I've written,
so what's the point in replying?

-- Toby


subject: [Wikitech-l] Re: Phase IV

body:
Erik Moeller wrote:

>Anthere-
>
>
>>Recently, a new editor (a french language teacher) got
>>on the french wiki. He insists on using these
>>unbreakable spaces.
>>
>>
>
>I don't think that's a good idea. It only makes pages harder to edit
>because of the ugly HTML entities.
>
>
>
I agree. It's ugly in source.

Why can't a browser see a text is in french and then treat a space
between numbers or after punctuation as unbreakable?
Has the w3c thought of this yet?


subject: [Wikipedia-l] Re: PNG format???

body:
Timwi wrote:

> Ralphem at aol.com wrote:
>
>> JPEG AND GIF are the standards for use on the web
>
JPEG and PNG are the standards now.

>
> I really hate GIF. Does it show?
>
Yeah. But I agree with you, so I don't mind :-)


body:
Jimmy Wales wrote:

>Toby Bartels wrote:

>>The Creative Commons SA licence, in contrast, has no such problems.
>>It is by any objective measure the superior licence; however, we
>>really should license Wikibooks disjunctively with the GNU FDL, so
>>that books can borrow the substantial material from Wikipedia if
>>useful.

>I don't think disjunctive licensing solves the license incompatibility
>issues.  We'll be taking content from Wikipedia (GNU FDL) and then
>offering it under *either* GNU FDL or CC-SA.  Suppose someone tries to
>re-use the content under CC-SA rather than GNU FDL, how does that not
>violate the provisions of use for the solely-FDL content?

No, this is not what we will be doing (under my suggestion).

If a textbook (like a cookbook would) takes content from Wikipedia,
then it must license those contents under the GNU FDL alone.
It obviously can't license them under a disjunctive licence;
that would be a blatant violation of the GNU FDL,
which says that only the GNU FDL can be used.

OTOH, if a textbok (like any math book would) doesn't take content from WP,
then it can use CC SA, or a disjunctive licence, or whatever it likes.
My argument that you quoted above is about this situation.

>Maybe this will work, though, but we need to think hard about the
>details.

To be sure.

One thing to consider is when material is different enough
that it can belong to different licences (potentially),
in case one wants to borrow from Wikipedia and one doesn't.
This would be less a matter of distinction between material covered
than the appropriate style of explanation for the relevant audience.

For example, both a physics text and a math text might discuss vectors.
But the physics explanation wouldn't be rigorous enough for the math text,
and the math explanation wouldn't have the right sort of applications
for the physics text.  Anything borrowed would need to be rewritten --
in which case, copyright and licence issues don't apply.
Similarly, a chemistry text and a cookbook might both discuss caramelisation,
but in very different ways for different purposes, with no sharing of text.
OTOH, the physics and chemistry texts might well want to borrow,
not just information, but entire chunks of text with only minor changes --
especially given the modular nature of textbooks that's been proposed here,
where different textbooks might share the exact same module.

IMO, only the cookbook (of these examples) is likely to want WP text,
so only it would need to change its licence from a disjunction to GNU FDL.
Still, I may be wrong about the science books, since I'm not very familiar
with either Wikipedia's material or the real needs of such textbooks.
OTOH, a math textbook would need to rewrite every WP article it uses,
and would probably just consider WP one more source of information.

We'd also have to write code to handle all of this,
but we need to redo all of the code anyway for the modules.

>If we were starting wikipedia from scratch today, I would prefer to
>create a wikipedia license that says "You can redistribute this
>content under GNU FDL, CC-SA, or additional free licenses that may be
>specified from time to time on this page."

This is exactly what I propose.  This is a disjunctive licence.

>But isn't it too late for that?

It is indeed too late for Wikipedia, AFAICT, but not for Wikibooks --
unless a Wikibook borrows from WP, in which case the disjunctive licence
allows the project to switch over.  If mav ends up being entirely right,
then every project will borrow from WP but never from anything non-GNU,
in which case everything will eventually be under the GNU FDL anyway.
But I don't think that mav is right, certainly not for math books.

-- Toby


body:
Mav wrote:

>Toby wrote:

>>But anybody can add Invariant Sections.
>>So if GNU FDL with Invariant Sections is not free,
>>then GNU FDL without them is not copyleft.

>Well the Debian people want to consider the GNU FDL non-copyleft - that is
>their right. But they do not own the term. Anyway...

What do the Debian people have to do with this?
I'm using the terms "free" and "copyleft" as the FSF defines them.
Do you disagree with my conclusion above?  Then say why.
Debian has nothing to do with this; the truth is independent of their opinion.
Just as it's independent of the FSF's opinion.

>The Invariant Sections issue is very troublesome to me and we really need to
>work with the GNU people to remove this option from future versions of their
>license (for the sake of free content we must do this because it is not
>possible to change Wikipedia's license). I would furthermore /strongly/ argue
>that we do not accept any GNU FDL text in any Wikimedia project that has
>Invariant Sections. The last thing we need is to become infected with that
>garbage.

If we licence our material under the GNU FDL with no Invariant Sections,
then we /can't/ accept material with Invariant Sections
any more than we can accept material under CC SA, etc.
FDL w/ IS is incompatible with FDL w/o IS.
(And also with my disjunctive licence, for that matter.)

>>The Creative Commons SA licence, in contrast,
>>has no such problems. It is by any objective measure
>>the superior licence;

>I tend to agree but in the real world the GNU FDL is the license used by the
>great majority of free content (not just Wikipedia ; CC is a suite of
>licenses, not a single license, but together they are gaining some ground).
>So our strategy should be to go with the flow and try to change that license
>instead of making things really complicated by having a bunch of different
>licenses within one project.

We should only go with the flow if we have reason to.
If your cookbook wants to borrow material from WP, then it has reason to.
But if my math book has no interest in that material except as information,
then it has no reason to.

>I'm sure RMS will listen to our concerns since Wikipedia is by far the largest
>GNU FDL project in the world and I'm sure RMS is also concerned about
>Debian's decision. The whole point of the GNU FDL was to have a license for
>software documentation and yet anybody who wants their documentation in
>Debian won't use this license - hence the license needs to be overhauled.

I suspect that RMS will accept removing the Invariant Sections.
But I can't imagine him changing the GNU FDL to allow
redistribution under a Creative Commons licence;
since CC doesn't share the FSF's ethical philosophy
(they even offer the non-free ND and NC licence options!),
how can he be sure that CC licences will remain free?

Now, if you can get a statement from RMS saying that
he trusts CC and wants to change the FDL to allow compatibility
(presumably with CC BY-SA or possibly also with CC SA),
then I wouldn't worry about anything anymore!

>But in the meantime it is already difficult enough to get people to understand
>our one license - let's not add another and make it even more complicated.

Who has trouble understanding it?
I still expect that most users don't care at all.

-- Toby


body:
Daniel Mayer wrote:

>We can discuss the possibility of changing license terms when somebody finds
>an impressive non-FDLd free text resource whose copyright owner declines our
>nicely-worded request to grant us a GFDL license of their work.

No we can't; it'll be too late then.

It'll also be too late when we find a textbook project like ours --
that is, one with thousands of different copyright holders --
which is sympathetic to release under the GNU FDL but practically can't.

And it'll be too late when a textbook project like ours finds /us/ --
you consistently ignore this reverse possibility.
This is in fact the situation that I worry about most;
not our practical problems in having to rewrite what /we/ want,
but our unethical (I share much of RMS's ethical opinions) decision
to restrict /their/ use of our material.

-- Toby


body:
Schewek wrote:

>Why not add a "from <chose your date> the license is changed to...",
>and ask all contributers to sign on a page if they retroactively agree,
>and theoretically one could filter out all articles not covered
>and rewrite those if necessary.

Given the thousands of Wikipedia contributors, this is impractical.

We can, however, do this for Wikibooks, but only if it happens early.
If we ignore the licence issue now and just use the GNU FDL,
then it will be equally impractical for Wikibooks.

-- Toby


subject: [Textbook-l] No new wikis

body:
Erik Moeller wrote:

>Toby wrote:

>>Why hold a vote?
>>If some people want to do it and others don't,
>>then some people will do it while others won't.

>Anyone is of course free to start their own project on their own servers,
>but a Wikimedia brand project should have support from a substantial
>number of, er, Wikimedians. We're not a wiki hosting provider.

Since when does Wikimedia take votes to make these decisions?
A substantial number of Wikimedians /does/ want to do Wikibooks.
I don't need any vote to prove this.

-- Toby


body:
I wrote in part:

>Similarly, the Open Document License has free options A and B.
>Enabling them renders the licence non-free;
>the fact that they may be enabled later renders it non-copyleft.

Typo alert!

That's /non/-free options A and B in the first line, as the second line states.
In fact, given the second line, just delete the word "free" in the first line:

>Similarly, the Open Document License has options A and B.
>Enabling them renders the licence non-free;
>the fact that they may be enabled later renders it non-copyleft.

-- Toby


from_name: Lightning

subject: [Wikitech-l] Re: Phase IV

body:
Timwi wrote:

> Jens Frank wrote:
>
>> On Fri, Jul 25, 2003 at 01:42:29AM +0200, Timwi wrote:
>>
>>> Lightning wrote:
>>>
>>>> Plus, I think there was a reason behing programming in php vs Perl,
>>>> im not sure..
>>>
>>>
>>> Read the section "Why are we using PHP instead of perl?" on
>>> http://www.wikipedia.org/wiki/Wikipedia:PHP_script_FAQ
>>
>>
>> Selecting the language to use for Phase IV we should
>> think about the features it has to provide.
>
>
> Well, the particular feature you have mentioned isn't specific to a
> programming language. Yes, mod_perl allows you to store something in a
> global hash and keep the data between requests, but obviously this
> will only work if you have only a single webserver (which I hope we're
> not going for).
>
> This is a problem MemCacheD can solve - in fact, that's exactly what
> MemCacheD is for. And APIs for MemCacheD are, as has been said,
> available for both Perl and PHP (though the Perl one is the only one
> currently in use at a frequently-visited production website,
> livejournal.com.)

-- not to mention slashdot.org has started using memcached too.. thats a
big name.. although I dont think you can compare them to the huge size of LJ

>
>
>> does it allow e.g. a design of
>> Recent Changes as a big array?
>
>
> Although the theoretical answer to this is 'yes', this is optimising
> at the wrong spot. I've said this before. The Recent Changes page is
> not a performance problem as long as it only reads (provided of course
> it is optimised enough). What really blocks the database is a write.
> With the current software and database schema, article text is
> inserted into 'old' and then also modified in 'cur' every time you
> edit a page - which is doubly bad because 'cur' is the table you read
> from when you to the most basic thing: displaying an article. It also
> updates the search index, which is accessed by the search function,
> which is probably the second-most-used function.
>
>> Instead of writing a
>> dedicated Recent Changes table it would be enough
>> to write edits line by line to a journal and reload some
>> thousand lines of journal on a server restart.
>
>
> I'm not exactly sure what you mean here by a 'journal' if not a
> dedicated database table?
>
>>>> Then add to that that you designed a new db schema and that all
>>>> data will have to be converted from one to the other
>>>
>>>
>>> Of course I have thought about this. My plan would be to convert
>>> articles as they are requested by readers. That way the database
>>> would get converted gradually on demand, thus minimising possible
>>> delay and avoiding downtime.
>>
>>
>> This will be very hard to maintain if you want to have the special
>> pages reenabled. You will have to do lots of joins and subselects.
>> Nothing MySQL is very fast at.
>
>
> Well no, I wasn't really planning to have the database-intensive
> Special Pages (Orphans, Long articles, etc.) work with the old
> database. Especially Recent Changes doesn't need to because virtually
> anyone only uses the n most recent changes and no longer cares about
> those before the switch. Instead, I was planning to provide a Special
> Page listing all the articles that are still in the Phase-3 DB, and
> after a few weeks they'll all have been converted. It doesn't matter
> as much that "Long articles" and "Orphans" doesn't work reliably in
> this short interim period as it would if editing or even viewing
> articles wasn't possible.
>
>> I don't think the database schema is the source of our problems, I
>> thinks
>> it's the RDBMS.
>
>
> I have outlined the problems I see with the current DB schema in a
> posting to this list dated 12.07.2003 03:58, Subject "Database
> design":
> http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/004829.html
> The problem I mentioned above is only one of them.
>
>>> I haven't used $? yet :)))
>>
>>
>> I suddenly remember why I don't like Perl ...
>
>
> Don't get me wrong, I'm not disagreeing that Perl /is/ sometimes quite
> obfuscated - myself, I also hate the single-character variables ($/,
> $|, $`, $[, etc.). But apart from $_, they are all very rarely used.

Well hey, you know... its your time. so if you want to do this be my
guest. it seems like a cool project. I mean I love php, i just do and i
just dont like Perl cause i never did understand it to well.. im more of
a C or C++ guy myself. But hey, if you try to write in nonobfuscated
style and comment your code where something is not too logical I'll
probably like to keep track of your code and look at it and see if i can
come up with suggestions or even find bugs. But as I said, I have a hard
time reading perl.. i like those languages where things are written
exactly like you would expect them to be..  oh and i wont even look at
regexps.. I just cant get them.. my brain segfaults and coredumps when i
see them

Lightning