from_name: Sabine Cretella

body:
Well: let's make some practical point: people on the nap.wikipedia are
driven away because they have to use workarounds for '' - that is '
in whatever combination - we now uwse '' for '' to have a unique
way to identify words and word combinations if some day we should need
to use replace.py. Many now create non-standard artilces using the
accent of ? or ? that it ` or ? to create articles ... inserting spaces
where they are not needed etc. (all sorts of strange solutions to avoid
to see all in italics afterwards) before the &# thingie we needed to use
<nowiki> to get things right. It is an annoyance to have continuously
use workarounds - now I am quite "wikiphile" I'd say, being able to
install my own wikis + extensions and create sometimes quite complicated
templates ... imagine how someone feels who has no clue at all about
wikis - someone who would like to start a first article and then,
clicking on save gets weird stuff and therefore does not come back to
edit again, because editing is "too difficult". I have also plenty of
colleagues who maybe would like to help, but simply don't want to loose
the time to learn wiki, because donating a translation is already a lot
considering how much they would earn if they did translation jobs instead.

Next thingie - the |  sign - you don't have it on the German keyboard -
and it gets even worse if you have a laptop keyboard like I have - there
is no way to reproduce it easily with alt+<numeric code> like I could do
it on a normal keyboard.

How I work on the nap.wikipedia? Well there are two things to it: I
first write in OOo or Word, then I subsitute all '' with the numeric
code with search and replace and I avoid to create wiki-links, because I
am simply very annoyed (better I remain with nice words...)  to copy and
paste it here and there. Or I write the article on the wiki and then
substitute the parts needed - both ways require loads of time more.

At least the {{ [[ are on the keyboard - so normal wiki-links are not
much of an issue - for Wiktionary that works fine - but not for
wikipedia where you have declensed forms of a word.

I find wikis great - but they are not suitable for the biggest part of
potential contributors - maybe to 5% of them. See: I already said this
last time I wrote about these issues here ... if Mediawiki was not
developed by English sepaking people, but maybe by people speaking some
kind of "strange" language - if it was not developed for the English
speaking market only we would have more contributors in the regional
editions it would be different - more conscious about such issues - no,
please don't object - if people do things most of them only think about
the English wikipedia - the other projects might exist, but are
considered to be some kind of fun-stuff ... instead many of the small
wikipedias are very serious projects - much more serious than anyone of
you can imagine, they face many more problems you could ever imagine - a
good software approach would help many of us to grow a better community
and to be able to create more articles instead of having to re-read and
adapt every article to our standards (' is some kind of standard for
nap now) and people, who already have difficulties in writing local
languages, yes we have an alphabetization rate of approx 2 to 4%, would
not have to concentrate on multiple issues at a time, they could
concentrate on the text they are writing ... that would be great ...
that would be really a step ahead ... that would mean "think about the
users" not "for the majority it's fine ... so who cares ..."

I am sorry that I have to write this ... it should not be necessary.

I'll post this mail also on my blog in order to have it accessible to
more people.

Thank you for taking the time to read ... well I hope one day I will be
able to say "thank you for caring about the small communities".

Best, Sabine

*****
Sabine Cretella
Translations IT-DE, EN-DE
Evangelist for WiktionaryZ
s.cretella at wordsandmore.it
skype: sabinecretella
phone +39-340-1809828
http://sabinecretella.blogspot.com
Chiacchiera con i tuoi amici in tempo reale!
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com


list: wikitech-l

source: pipermail-mbox

from_name: Simetrical

subject: [Wikitech-l] Desire to Contribute

body:
And let's remember that vandals aren't going to give a rat's arse
about markup; you don't need to know what all that gibberish means to
replace it all with "u eat poo-poo".  But overall, yes, we want
good-faith contributors who are willing to expend exactly zero effort
learning how things work, because fixing typos will in many cases
progress to fixing facts, which may lead to discussion and further
involvement.

The point is a low barrier to *entry*.  Once you've gotten comfortable
with just editing, it's assumed that you might want to start
discussing things and learning policies and so on.  Or you might not,
which is also fine as long as you stay away from anything
controversial.  You don't need to read Verifiability or Neutral point
of view to know that things should be verifiable or neutral; you just
need someone to add {{fact}} or {{npov}} or something to a page you
edit, once.

But none of this will necessarily happen if you didn't do something to
commit yourself first.  It's the "foot in the door" principle: people
who start small will be more willing to proceed to bigger things than
they will be to start out with big things.  What were *your* first
edits to Wikipedia?


from_name: Platonides

subject: [Wikitech-l] Apple's Wiki Server brings WYSIWYG to wiki

body:
> 1. Click on the text.
> 2. A surrounding patch of text (a sentence? a paragraph?) is "locked"
> (no one else can edit it) and highlighted, and somehow rendered
> "editable".
> 3. Edit, drag text around etc. If necessary, mark other bits of text
> as being "locked" as well so you can edit them.
> 4. Press a commit button.
No losks are needed. If several people is editing, they will have an edit
conflict, like now. 'Please compare it'. And they aren't too frequent.


subject:
[Wikitech-l] Using a template to set some character formatting
	to several blocks of text

body:
On 8/14/06, Timwi <timwi at gmx.net> wrote:
> However, obviously, it is entirely possible to
> add a feature to MediaWiki that allows the inclusion of certain CSS on a
> specific page. One could even have the parser pick out all the 'class'
> attributes and include all the necessary CSS for those automatically.

Have you opened a bug on it?  It sounds like an interesting project.


list: foundation-l

from_name: Jimmy Wales

subject: [Foundation-l] Announcement regarding the Election

body:
Anthere wrote:
> Angela wished all new seats filled up by election. I wished some of the
> seats filled up by election and some by appointement. Jimbo apparently
> wishes only appointements.
>
>
No, I am open to a variety of options.  My feeling is that we will make
very good progress in figuring these
things out in our board retreat, face to face, high bandwidth.

--Jimbo


list: wikimedia-l


from_name: Steve Summit

subject:
[Wikitech-l] 404 on en.wikipedia.org: Server-side HTTP header
	instead of client-side meta-refresh?

references:
<NABBJGECPILFNLFEAPIKOEGEIKAA.nickpj@gmail.com>
	<44DBFB21.9050609@pobox.com>
	<f1c3529e0608110152t78a10babpde43b8fe8443bd27@mail.gmail.com>
	<44DCA33F.40906@pobox.com>
	<f1c3529e0608111008i713ab8e0n99105ff93cbcf1e1@mail.gmail.com>
	<ebq8p9$u1b$1@sea.gmane.org>
	<f1c3529e0608141016i2e16d2bave327654d9acaebc@mail.gmail.com>
	<20060814180929.GE16929@cgi.jachomes.com>

body:
Jay Ashworth wrote:
> I, too, think it would be nice to make it as difficult as possible to
> bookmark a URL that's the *source* of a redirect, but...

That's really true only if the "source" is "wrong".  It turns out
it's not always wrong, which is yet another reason I think the
current setup is the right compromise.  (That is, we'll just have
to find other ways to stamp out the "bad" links that result when
people bookmark or otherwise use a truly "wrong" URL that we're
actively trying to deprecate.)

In many (perhaps most) of the current cases, redirects are used
to create "aliases" for pages, and there really oughtn't be any
stigma attached to linking to such an alias, if that makes more
sense.  For example, if I know that [[Los Angeles]] redirects
to [[Los Angeles, California]], and if I'm writing in a context
where it's unnecessary to remind my readers of the state, should
I slavishly write [[Los Angeles, California|Los Angeles]], or
should I rely on the redirect and just write [[Los Angeles]]?
Truly, one of the reasons these "alias" redirects exist is to
make it easier on people creating wikilinks in naturally-flowing
prose without having to use pipelinks all the time, so why not
make use of them when they're there?

I've recently come across two other cases in which I think it
makes sense to deliberately link to a redirect.

1. Questionably-robust redirect partitioning.  Suppose I need to
   link to the article about Vancouver, BC.  It happens that,
   currently, plain [[Vancouver]] is about the Canadian city,
   and the  U.S. city is at [[Vancouver, Washington]], and
   there's a disambiguation page at [[Vancouver (disambiguation)]],
   and [[Vancouver, BC]] redirects to [[Vancouver]].  So I could
   get away with just linking to [[Vancouver]].

   But the Vancouver situation is (to me, at least) different
   from the Los Angeles one.  There is and is only ever likely
   to be one Los Angeles, but the Vancouver situation feels
   much less absolute.  I can imagine that, some ways down the
   line, someone might change plain [[Vancouver]] to be the
   disambiguation page.  So I'd like to explicitly link to
   [[Vancouver, BC]], even if it means using the pipelink
   [[Vancouver, BC|Vancouver]], and even though it means
   linking to something which I know today to be a redirect.
   But, in this case, being explicit feels much more robust
   to me, doesn't leave me feel like I'm relying on today's
   coincidence (i.e. that plain [[Vancouver]] happens to be
   the one I want) to last forever.

2. Clarifying "antiredirects".  Just this morning, I was reading
   up about countable versus uncountable nouns.  I tried
   [[Countable]], which redirects to [[Countable set]].  It turns
   out we do have [[Countable noun]], which is a redirect to
   [[Count noun]], which is another term some people use for what
   I think of as a "countable noun".  But to make it easier on
   the next reader who happened to be interested in linguistic as
   opposed to mathematical countability, I edited [[Countable set]]
   to add

	"Countable" redirects here.  For the linguistic concept,
	see Countable noun.

   at the top.  Almost immediately someone changed it to

	...For the linguistic concept, see Count noun.

   noting that [[Countable noun]] is a redirect.  But I think
   showing the link as [[Countable noun]] was (mildly) preferable
   in this case, because it explicitly shows the same word which
   the searcher who got redirected from [[Countable]] is looking for.
   It doesn't make too much of a difference in this case, but if
   the terms were more different -- if the searcher looked for
   [[Abc]] and got redirected to [[Abc d]] and was told that there
   was also an article on [[Xyz]], he might not realize that the
   [[Xyz]] link was worth following if what he thought he was
   looking for was [[Abc q]].

   (Actually, I don't need to use that hypothetical Abc/q
   example, because I've got a real one right in front of me:
   at the same time I was playing with [[Countable set]], I also
   edited [[Uncountable set]] to include the similar legend
   "'Uncountable' redirects here.  For the linguistic concept,
   see Uncountable noun".  Now, [[Uncountable noun]] is actually
   a redirect to [[Mass noun]], but if the same change were made
   here -- if the legend said "For the linguistic concept, see
   Mass noun" -- it might be confusing.)

The bottom line is if there's less reason to discourage linking
to "wrong" titles (as I maintain), there's less reason to worry
about showing the "wrong" URL in the address bar of a
redirected-to page.

[P.S.  Personally, I think it would be good if articles could have
alternate titles or "aliases" as a formally-supported concept, so
that we could do away with the hordes of manually-maintained
explicit redirects which simulate them, but that would admittedly
be much more complicated on the implementation side, if "more
convenient" on the user side.]

[P.P.S.  One way to tell if a redirect is really an "alias" is if
the alias name shows up in bold face, preceded by the word "or"
or "also", in the redirected-to article's lead sentence.
See [[Mass noun]] for an example.]


list: wikien-l

from_name: ikiroid

subject: [WikiEN-l] Bye.

body:
And so many feel compelled to bring everyone in on a private
issue............


subject: [WikiEN-l] CITE nazis

body:
It's obvious why, isn't it? Editors hide behind policy in order to hide
their ulterior motives when they have an agenda......this is why we have the
"Ignore all rules" corollary, to protect the integrity of the encyclopedia
when policy threatens to compromise it.


from_name: Steve Bennett

body:
On 8/14/06, Sabine Cretella <sabine_cretella at yahoo.it> wrote:
> How I work on the nap.wikipedia? Well there are two things to it: I
> first write in OOo or Word, then I subsitute all '' with the numeric
> code with search and replace and I avoid to create wiki-links, because I
> am simply very annoyed (better I remain with nice words...)  to copy and
> paste it here and there. Or I write the article on the wiki and then
> substitute the parts needed - both ways require loads of time more.

Would it not be possible to add some javascript to the monobook.css at
nap to do some substitution? Pick some character sequence that users
will use to enter non-italic text (or even better, a character
sequence for italics, and make '' natural). Then, when they go to edit
text, substitute all the text as it apperas from the wiki. When they
save, substitute it back. So, two solutions:

I think using // instead of '' would be cleaner for italics, but would
be harder to implement, as you would need to substitute as follows:
1. When the edit box appears:
* Substitute '' (when not enclosed in <nowiki>...) with //.
* Substitute all instances of '' '' and '' with ''
2. When saving:
* Substitute all non-escaped '' with ''
* Susbitute all // with ''

A bit of tricky parsing involved, I suspect...

Maybe something similar would work for | for Germans?

The problem with simply saying "this punctuation is no good because
there exists a language for which it doesn't work" is that it's
probably next to impossible to find a syntax that is acceptable for
*all* languages, present and future.

Steve


subject: [Foundation-l] bylaws (second call)

body:
Anthony wrote:
> I get the sense that there's an effort to run Wikimedia more like a
> private foundation than a public charity.
No.

--Jimbo
>
>


subject: [Foundation-l] bylaws (second call)


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] Are TV screencaps reputable sources?

body:
Ray Saintonge wrote:
> jayjg wrote:
>
>> On 8/13/06, Ray Saintonge <saintonge at telus.net> wrote:
>>
>>
>>> jayjg wrote:
>>>
>>>
>>>> On 8/12/06, Ray Saintonge <saintonge at telus.net> wrote:
>>>>
>>>>
>>>>> Alphax (Wikipedia email) wrote:
>>>>>
>>>>>
>>>>>> Joe Anderson wrote:
>>>>>>
>>>>>>
>>>>>>> Cool Cat recently created an article called Starfleet
>>>>>>> Uniforms<http://en.wikipedia.org/wiki/Starfleet_Uniforms>,
>>>>>>> and it was nominated for deletion as cruft and OR.
>>>>>>>
>>>>>>> The screencaps/promo photos in the article, IMO, acted as a reputable
>>>>>>> source. I mean, how else (canonically) are you going to know about the
>>>>>>> uniform switch between TOS and TNG? Using a book is not canonical, and
>>>>>>> therefore is surely not [[WP:V]].
>>>>>>>
>>>>>>>
>>>>>> There are such things as Star Trek encyclopediae, which report canon and
>>>>>> real life (and probably not fanfic/other non-canon).
>>>>>>
>>>>>> While the TV shows are canonical (as are the movies (except where
>>>>>> continuity fails, cf. /Enterprise/)), using a screencap is close to
>>>>>> original research and on dangerous ground wrt. using "fair use" as an
>>>>>> excuse for copyright infringement. (****)
>>>>>>
>>>>>>
>>>>> So using a picture from the secondary source would be somehow more free
>>>>> than using a screen capture?
>>>>>
>>>>>
>>>> No, the secondary source would describe the uniform switch from TOS to TNG.
>>>>
>>>>
>>> So would sample screen captures from episode of the two programs.  You
>>> would be able to see the difference without explanation.  This doesn't
>>> explain your gratuitous red herring about copyright infringement.
>>>
>>>
>> Copyright infringement? I don't know what you're talking about, I
>> never mentioned copyright infringement.
>>
> See (****) above.  If that was somebody else, I apologize for any
> implicitly wrong attribution.
>
<snip>

That was me, and it's not a red herring. Every time we claim "fair use"
on an image, it is because the image is not Free; that means, we are
infringing someone's copyright. "Fair use" is something which exists
under US law (presumably several others, but it's US law that we rely
on) which we use to justify that infringement; I was making the point
that with things like screenshots, we have to be careful that our claims
are in fact fair and valid.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060814/a44f7525/attachment.pgp


body:
On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Mon, Aug 14, 2006 at 08:21:15AM +0200, Steve Bennett wrote:
> > I think it's fair to assume that there will be people who will always
> > prefer working directly "in the code" (whatever that means). It's
> > probably also reasonable to say that a full WYSIWYG layer which makes
> > wikitext redundant for the user is also a good thing.
>
> You do; I gather Simetrical does not.

More precisely: I contemplated the possibility that the current markup
is no longer necessary.  I do not necessarily adhere to that view
dogmatically or without reservation, although up to this point I may
have allowed myself to be drawn into the argument beyond my level of
conviction.

On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> Size.

I believe the database is already compressed, so the difference would
not be particularly large.

> If there are two formats which are exactly round-trippable, and one of
> them is a) smaller, and b) supported by the current code... why would
> we change, again?

Because *maybe* the second format is more processor-efficient and
easier to work with across different applications.  This difference
will become much less once we get the grammar formalized, but I don't
know if most languages have something like yacc (Javascript is
particularly important), and many third-party reusers undoubtedly
don't have authority to install PHP extensions or run binaries (well,
not sure about the latter).

This would require evaluation by people more familiar with the issue
than I, to be sure.  It was only a suggestion.

On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> My Blackberry will not parse XML.

Which is why there would be a Javascript fallback, which could
probably be grabbed from any number of open-source projects.  Since
the syntax is well-defined, popular, and much simpler than that of
wikicode.


from_name: mboverload

subject: [Wikitech-l] Desire to Contribute

body:
Maybe I'm missing something here:

You don't need to learn ANYTHING.  Hit the edit button, fix the typo, and
you're done.

On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
>
> On Mon, Aug 14, 2006 at 11:53:05PM +0200, Steve Bennett wrote:
> > On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > > That does not, and will not, stop me from Wishing and Hoping that
> > > people will decide to Want to Learn again.
> >
> > Wikipedia is your hobby. Not theirs.
>
> I wouldn't really characterise it as a hobby, for me, which is likely a
> large part of the reason for this disconnect.  But apart from that, if
> I was going to contribute my knowledge to the world on any topic, I
> would want it to be useful and reflect well on me.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth
> jra at baylink.com
> Designer                          Baylink                             RFC
> 2100
> Ashworth & Associates        The Things I Think                        '87
> e24
> St Petersburg FL USA      http://baylink.pitas.com             +1 727 647
> 1274
>
>         The Internet: We paved paradise, and put up a snarking lot.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] thumbnail conversion

body:
"Mei Wu"wrote:
> Hi all,
>
> I'm running Mediawiki 1.6.7 on Windows XP.
> The thumbnail conversion doesn't work properly. Did anyone encounter
> the same problem? Is there a way to resolve this problem?
>
> Thanks so much in advance.
>
> Best regards,
> Mei

Did you install imageMagick's convert ?


body:
Ray Saintonge wrote:
> Alphax (Wikipedia email) wrote:
>
>> mboverload wrote:
>>
>>
>>> Someone explain to me how a screencap is ANY different than a quote from a
>>> book.
>>>
>>>
>> Quotes are factual (somebody said them), and facts cannot be copyrighted.
>>
> Wow!  Some people really work hard to prove they haven't got a clue.
> Quotes may be factual, but they are not facts.  What is copyrighted is
> the way something is expressed rather that its informational content.
> Sometimes they become merged when the two are indistinguishable.  The
> merger principle can render something uncopyrightable; this was the
> basis for Lexmark's loss over the copyrightability of the software in
> its ink cartridges.  When the work in question is fictional you are less
> likely to be dealing with facts, and unless the work is in the public
> domain the use of any quotation from it is an example of fair use.
> Picking up the quote from a work about the work doesn't change that.
>

You misunderstand me. First, you abuse me when I'm trying to explain
something to someone without flaming them for not understanding; second,
what is a quote if it's not a factual saying? Even made-up quotes are
factual in that someone made them up; even quotes from a book are
factual in that someone wrote the book they come from.

Oh, and if quotes are copyrightable (and we can only use them under
"fair use"), please explain to me how Wikiquote can exist?

>> A screenshot is one of several thousand (~= 24 * 60 * 45) copyrighted
>> images, a story, the characters in the story, and an audio track which
>> make up an episode of a TV show.
>>
>>
> My understanding was that "screenshot" and "screencap" referred to
> stills from a moving picture.  You make it sound like each pixel is
> copyrightable. :-)
>

No. A collection of pixels which represent something, where creative
input is involved, are copyrightable.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060814/bc02d41f/attachment.pgp


subject: [Wikitech-l] Wysiwyg debate

body:
On 8/14/06, Timwi <timwi at gmx.net> wrote:
> If the person designing the references syntax had thought about this a
> bit more, these severe problems should have been apparent to them. A
> much more sensible thing would be to use [1], [2] etc. in the text, and
> define the references in the place where they are actually displayed --
> the References section. (Duh.)

If you had thought about this a bit more, the severe problems with
your suggestions should be apparent to you.  :)  More precisely,
neither you nor Avar probably saw all the arguments for each side
before you made your respective statements/commits.  (When Avar did
it, the arguments against hadn't been *developed*, due to lack of
experience.)

Basically, the advantages of having just a reference name be in the
text itself, and the text in the references section, are intuitiveness
and less clutter.  The advantages of having the full reference in the
text are that it works with section editing, and the ref doesn't break
invisibly if someone transplants the section or whatever without
thinking to move the refs as well.  Trust me, that's constant and
horrible with the {{ref}} style: I've had to spend half an hour or
more on more than one occasion digging through page histories to
figure out where the references disappeared.

Jay is right that coloring the refs probably wouldn't be too hard with
current wikitext.  Ideally, WYSIWYG would handle refs in some special
way so that editing them is fully intuitive and uncluttered.
Something like being able to click the ref number to bring up a
floating popup-y thing that you could edit, while also being able to
click the ref in the references section and edit that directly, with
the Javascript keeping them synced and secretly editing only the <ref>
contents either way.


from_name: Lars Aronsson

body:
mboverload wrote:

> Why do we need WYSIWYG to visualise italics and bold?

What's wrong with this question is the word "we".  We who are
already great fans of Wikipedia and Mediawiki are obviously
comfortable with the current wikitext markup, or otherwise we
would be somewhere else.  What WYSIWYG can bring is *new* people.

I don't see your point in protesting against this.  Nobody is
going to force you to use my Swedish keyboard layout and nobody is
going to force you to use WYSIWYG editing.  What's your problem?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


from_name: Ligulem

body:
Steve Bennett wrote:
>
> Maybe something similar would work for | for Germans?

Just don't forget to check some facts about German keyboards first.


subject: [Wikitech-l] Open proxy blacklist

body:
"Simetrical" wrote:
> A major activity that, IMO, is almost certainly not worth the effort.
> We should use a few carefully vetted external blacklists with good
> reps, and not ban anyone who's not on all of them.  That, combined
> with local (and global?) whitelists, should be more than sufficient to
> ensure that no one legitimate is locked out, or at least not for long.

It could be easy to make it. Let's say you have a bot proxy scanning ips
that are being blocked on any project. If it finds an open proxy it lists it
in a global open proxy-db which would forbid editing from that ip for X
hours. Reincident ips would get a longer block.
-You only scan blocked ips, probably vandals.
-Detection and blocking is automatic.
-Project-wide
-Doesn't add log entries to the local project, improving legitibility.

Each project could ask for not using it (e.g. chinese)
Some human intervention could be asked but if the bot has a correct
open-proxy procedure, there's little humans could do (apart of asking a
steward for manual delisting).

We could have a gloabal system operated by sysops, but most probably doen't
know how to detect an open proxy and, what should an en sysop do when a user
ask him to delist cause a ku sysop blocked his ip?


references:
<NABBJGECPILFNLFEAPIKOEGEIKAA.nickpj@gmail.com>
	<44DBFB21.9050609@pobox.com>
	<f1c3529e0608110152t78a10babpde43b8fe8443bd27@mail.gmail.com>
	<44DCA33F.40906@pobox.com>
	<f1c3529e0608111008i713ab8e0n99105ff93cbcf1e1@mail.gmail.com>
	<ebq8p9$u1b$1@sea.gmane.org>

body:
On 8/14/06, Timwi <timwi at gmx.net> wrote:
> or (c) It hard redirects you, and there's a link back to where you came
> from.

So . . . I go to <http://en.wikipedia.org/wiki/HTTP_redirection>.  I
get a 301 to go to <http://en.wikipedia.org/wiki/URL_redirection>?
Then how does the server know to display the link back?  All it knows
is someone asked for one URL and got a 301 in return, then someone
asked for another URL and needs to be returned a page.  HTTP is
stateless.  So you'd have to redirect to
<http://en.wikipedia.org/wiki/URL_redirection?redirect=HTTP_redirection>
or something, which completely defeats the purpose.

Your only reply to that was that we didn't need the redirection link,
we could just have a "pages redirecting to here" and that would be
good enough.  I haven't seen anyone else agree with that yet; I
certainly don't.  You're talking at least two clicks and a pageload
plus hunting through a list, all instead of a single click.  It would
be quite annoying.


subject: [Wikitech-l] Desire to Contribute

body:
On 8/14/06, Chad Perrin <perrin at apotheon.com> wrote:
> In the case of
> edits to existing articles, I tend to suspect that typo fixes might be
> among the highest percentage of first-time edits -- and that isn't
> really affected much by "weird" stuff like templates and heading
> wikimarkup.

Well, that's the whole issue.  I, Jimbo Wales, etc. disagree.  We
think a large number of the less technically-inclined are probably
scared off by this kind of stuff, rather than ignoring it as they
should.


from_name: Jay R. Ashworth

subject: [Wikitech-l] Desire to Contribute

body:
On Mon, Aug 14, 2006 at 02:49:33PM -0400, Simetrical wrote:
> But none of this will necessarily happen if you didn't do something to
> commit yourself first.  It's the "foot in the door" principle: people
> who start small will be more willing to proceed to bigger things than
> they will be to start out with big things.  What were *your* first
> edits to Wikipedia?

http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20041027010309&limit=50&target=Baylink

plus about 4 or 5 where I thought I was logged in but it didn't stick;
you'll note, my first logged contribution was a *bug report on that
issue*.

But I've been doing this sort of thing for 25 years, and I *understand*
that I'm not the mainstream user.

That does not, and will not, stop me from Wishing and Hoping that
people will decide to Want to Learn again.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Chad Perrin

subject: [Wikitech-l] Desire to Contribute

body:
On Mon, Aug 14, 2006 at 11:53:05PM +0200, Steve Bennett wrote:
> On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > That does not, and will not, stop me from Wishing and Hoping that
> > people will decide to Want to Learn again.
>
> Wikipedia is your hobby. Not theirs.

Clearly.  I still sympathize with Jay's thoughts on the matter -- that
it would be nice to see an increase in the desire to learn in the
general populace.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid


references:
<NABBJGECPILFNLFEAPIKOEGEIKAA.nickpj@gmail.com>
	<44DBFB21.9050609@pobox.com>
	<f1c3529e0608110152t78a10babpde43b8fe8443bd27@mail.gmail.com>
	<44DCA33F.40906@pobox.com>
	<f1c3529e0608111008i713ab8e0n99105ff93cbcf1e1@mail.gmail.com>
	<ebq8p9$u1b$1@sea.gmane.org>
	<f1c3529e0608141016i2e16d2bave327654d9acaebc@mail.gmail.com>
	<20060814180929.GE16929@cgi.jachomes.com>
	<2006Aug14.1458.scs.0012@eskimo.com>

body:
On Mon, Aug 14, 2006 at 02:58:09PM -0400, Steve Summit wrote:
> Jay Ashworth wrote:
> > I, too, think it would be nice to make it as difficult as possible to
> > bookmark a URL that's the *source* of a redirect, but...
>
> That's really true only if the "source" is "wrong".  It turns out
> it's not always wrong, which is yet another reason I think the
> current setup is the right compromise.  (That is, we'll just have
> to find other ways to stamp out the "bad" links that result when
> people bookmark or otherwise use a truly "wrong" URL that we're
> actively trying to deprecate.)

Redirects are much more malleable, in my perception, than pages, and
that's why I feel that bookmarking them is Not The Best Idea.

> In many (perhaps most) of the current cases, redirects are used
> to create "aliases" for pages, and there really oughtn't be any
> stigma attached to linking to such an alias, if that makes more
> sense.  For example, if I know that [[Los Angeles]] redirects
> to [[Los Angeles, California]], and if I'm writing in a context
> where it's unnecessary to remind my readers of the state, should
> I slavishly write [[Los Angeles, California|Los Angeles]], or
> should I rely on the redirect and just write [[Los Angeles]]?

That's an excellent question.  How 'reliable' do you want your writing
to be.  When you find a redlink for which there "really" is a page,
what do you do?  Do you fix the link, or create a redirect?

> Truly, one of the reasons these "alias" redirects exist is to
> make it easier on people creating wikilinks in naturally-flowing
> prose without having to use pipelinks all the time, so why not
> make use of them when they're there?

There's an argument on both sides, certainly.

> I've recently come across two other cases in which I think it
> makes sense to deliberately link to a redirect.
>
> 1. Questionably-robust redirect partitioning.  Suppose I need to
>    link to the article about Vancouver, BC.  It happens that,
>    currently, plain [[Vancouver]] is about the Canadian city,
>    and the  U.S. city is at [[Vancouver, Washington]], and
>    there's a disambiguation page at [[Vancouver (disambiguation)]],
>    and [[Vancouver, BC]] redirects to [[Vancouver]].  So I could
>    get away with just linking to [[Vancouver]].
>
>    But the Vancouver situation is (to me, at least) different
>    from the Los Angeles one.  There is and is only ever likely
>    to be one Los Angeles, but the Vancouver situation feels
>    much less absolute.  I can imagine that, some ways down the
>    line, someone might change plain [[Vancouver]] to be the
>    disambiguation page.  So I'd like to explicitly link to
>    [[Vancouver, BC]], even if it means using the pipelink
>    [[Vancouver, BC|Vancouver]], and even though it means
>    linking to something which I know today to be a redirect.
>    But, in this case, being explicit feels much more robust
>    to me, doesn't leave me feel like I'm relying on today's
>    coincidence (i.e. that plain [[Vancouver]] happens to be
>    the one I want) to last forever.

So our disagreement is a difference in degree, not of sorts.  Got it.

> 2. Clarifying "antiredirects".  Just this morning, I was reading
>    up about countable versus uncountable nouns.  I tried
>    [[Countable]], which redirects to [[Countable set]].  It turns
>    out we do have [[Countable noun]], which is a redirect to
>    [[Count noun]], which is another term some people use for what
>    I think of as a "countable noun".  But to make it easier on
>    the next reader who happened to be interested in linguistic as
>    opposed to mathematical countability, I edited [[Countable set]]
>    to add
>
> 	"Countable" redirects here.  For the linguistic concept,
> 	see Countable noun.
>
>    at the top.  Almost immediately someone changed it to
>
> 	...For the linguistic concept, see Count noun.
>
>    noting that [[Countable noun]] is a redirect.  But I think
>    showing the link as [[Countable noun]] was (mildly) preferable
>    in this case, because it explicitly shows the same word which
>    the searcher who got redirected from [[Countable]] is looking for.
>    It doesn't make too much of a difference in this case, but if
>    the terms were more different -- if the searcher looked for
>    [[Abc]] and got redirected to [[Abc d]] and was told that there
>    was also an article on [[Xyz]], he might not realize that the
>    [[Xyz]] link was worth following if what he thought he was
>    looking for was [[Abc q]].

Well, if those "blah redirects here" things are *manual*, then there's
another good reason: they're *wrong* if you came in to a page with
multiple redirects pointing to it.

>    (Actually, I don't need to use that hypothetical Abc/q
>    example, because I've got a real one right in front of me:
>    at the same time I was playing with [[Countable set]], I also
>    edited [[Uncountable set]] to include the similar legend
>    "'Uncountable' redirects here.  For the linguistic concept,
>    see Uncountable noun".  Now, [[Uncountable noun]] is actually
>    a redirect to [[Mass noun]], but if the same change were made
>    here -- if the legend said "For the linguistic concept, see
>    Mass noun" -- it might be confusing.)

Which I think is another way to say the same thing.

> The bottom line is if there's less reason to discourage linking
> to "wrong" titles (as I maintain), there's less reason to worry
> about showing the "wrong" URL in the address bar of a
> redirected-to page.

My perception is that the writers on a page assume it's called what
it's really called, and that assumption may color what they write, in
the way you suggest, and possibly in other ways that aren't obvious,
both on WP and on private wikis... and the results of those problems
may confuse *readers*, which is a couple/three order of magnitude worse
problem... right?

> [P.S.  Personally, I think it would be good if articles could have
> alternate titles or "aliases" as a formally-supported concept, so
> that we could do away with the hordes of manually-maintained
> explicit redirects which simulate them, but that would admittedly
> be much more complicated on the implementation side, if "more
> convenient" on the user side.]

By which you mean that the article "could tell" that it had such and
such aliases, in a way that it can't now?

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


body:
On Mon, Aug 14, 2006 at 03:22:41PM -0400, Simetrical wrote:
> > You do; I gather Simetrical does not.
>
> More precisely: I contemplated the possibility that the current markup
> is no longer necessary.  I do not necessarily adhere to that view
> dogmatically or without reservation, although up to this point I may
> have allowed myself to be drawn into the argument beyond my level of
> conviction.

Noted.  My apologies if I presumed you to be more partisan than you
actually are.

> On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > My Blackberry will not parse XML.
>
> Which is why there would be a Javascript fallback, which could
> probably be grabbed from any number of open-source projects.  Since
> the syntax is well-defined, popular, and much simpler than that of
> wikicode.

While my BlackBerry *will* run JavaScript, if I tell it to, it would
probably choke on something the size of a Wysieditor.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


body:
On 8/14/06, Ligulem <ligulem at pobox.com> wrote:
> Steve Bennett wrote:
> >
> > Maybe something similar would work for | for Germans?
>
> Just don't forget to check some facts about German keyboards first.

http://en.wikipedia.org/wiki/Image:Cherry_keyboard.jpg

Is that it down next to the Y? I've got to stop getting sucked into
non-existent causes :)

Steve


from_name: Michael Bimmler

subject: [Wikitech-l] OTRS down?

body:
Could it be that OTRS is down at the moment?
https://secure.wikimedia.org/otrs/index.pl  seems to give a time-out
response.
(I would have asked in IRC but I'm not at my own computer at the moment)
Michael


from_name: Death Phoenix

subject: [WikiEN-l] CITE nazis

body:
I think it's most useful to detect original research and speculation. For
example, in [[Colonization of Mars]], I noticed two recent additions (
http://en.wikipedia.org/w/index.php?title=Colonization_of_Mars&diff=66947187&oldid=66945515and
http://en.wikipedia.org/w/index.php?title=Colonization_of_Mars&diff=66952733&oldid=66947187)
that weren't common knowledge and I was wondering where the heck they found
this information.

I added the dreaded {{fact}} template:
http://en.wikipedia.org/w/index.php?title=Colonization_of_Mars&diff=67030722&oldid=66952733

Another editor found the sources and put it in.
http://en.wikipedia.org/w/index.php?title=Colonization_of_Mars&diff=67076307&oldid=67074721

I don't see how this would be the actions of a CITE Nazi, and indeed, it
prevented me from simply reverting the two additions.

On 8/14/06, stevertigo <vertigosteve at yahoo.com> wrote:
>
> Im not exactly the most citatious Wikipedian, but nor do I have any
> tendency to make claims which arent easily verifiable. Over the years
> though Ive encountered a number of Wikipedians (I wont name names) who
> abuse or violate a clean interpretation of CIVIL by referring to CITE
> or V as a basis for what is essentially ownership of an article; in the
> form of a revert, rather than a constructive edit, correction, or (gasp!)
> a collaborative and helpful attempt to find a source.
>
> Im not sure on the stats, but it is my impression that this demand for
> verifiability is 1) deletionistic 2) one sided, and not applied to one's
> own person and 3) comes with some attached notion of "reliable sources" by
> which material from any deemed "unreliable" sources can be deleted.
>
> Thats the topic. Discuss.
>
> Wikilove,
> -Stevertigo
>
>
>
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Desire to Contribute

body:
On Tue, Aug 15, 2006 at 12:28:15AM +0200, Steve Bennett wrote:
> On 8/15/06, Chad Perrin <perrin at apotheon.com> wrote:
> > Clearly.  I still sympathize with Jay's thoughts on the matter -- that
> > it would be nice to see an increase in the desire to learn in the
> > general populace.
>
> Ok, now that we've enjoyed 5 seconds of wistful pondering, can we get
> back to the real world?
>
> Seriously. People are what they are. We can attempt to change
> everyone, or we can work with what we've got.

Sure.

Responding in more depth off-list.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The measure on a man's real character is what he would do
if he knew he would never be found out." - Thomas McCauley


subject: [Foundation-l] bylaws (second call)

body:
Ray Saintonge wrote:

> I have yet to see a clear rationale for a memberless Foundation.
> In some jurisdictions such a concept is unthinkable.

Really?  Exactly which jurisdictions don't provide for memberless
foundations?  This news should be added to the article
http://en.wikipedia.org/wiki/Foundation_%28charity%29

If I could think of a single property that is unique for
foundations, it is exactly this, that they don't have (or need)
members.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


subject: [Foundation-l] bylaws (second call)


from_name: George Herbert

subject: [Foundation-l] Wikiversity

body:
On 8/14/06, Anthere <Anthere9 at yahoo.com> wrote:
>
> It came to my mind that we probably did not clearly announced here that
> we approved the creation of Wikiversity :-)
>
> Here is the resolution :
> http://wikimediafoundation.org/wiki/Resolution_Wikiversity
>
> A couple of important points
>
> 1) there will be a domain at beta.wikiversity.org, where all new
> languages may contribute and start working on translation of guidelines
> etc...
>
> 2) those languages with at least 10 active participants can request a
> separate domain name. As of today, I presume the english language has at
> least 10 people interested, so you guys may bug Brion to ask for
> en.wikiversity.org. I am not sure if it is the case for any other
> language.
>
> 3) All sites will be flagged "beta" in the same way that wikinews has
> been for at least 6 months.
>
> 4) During these 6 months, guidelines should be developped, *in
> particular* with regards to collaborative research. We would hope that
> these guidelines are as much as possible developped on the beta site (in
> particular collaborative research), so that all languages share a common
> goal and a few common non negociable rules.
>
> 5) At the end of these 6 months period, the project will be reviewed, in
> particular so that the issue of collaborative research is qualified, and
> if possible to define whether the beta stage is over. Reviewal will be
> done by Spc.
>
> I hope that's clear... ;-)
>
> We wish good luck to this project.
>
> Ant
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

Thanks for the note on that.  Is there an ETA on beta.wikiversity.org going
live?

--
-george william herbert
george.herbert at gmail.com


subject: [Foundation-l] Wikiversity


body:
On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Mon, Aug 14, 2006 at 08:47:45AM +0200, GerardM wrote:
> > It is "nice" to have things both ways. However you have to realise that one
> > reason why the parser is ugly is because of all the provisions to make life
> > easy for people who do not code properly their wikisyntax.  When the code is
> > generated, there is no excuse for these "abominations" and much saner text
> > can be generated.
>
> I don't think that's all that big an impact, myself.  I think it's
> mostly because the grammar is not formally defined, and therefore,
> parsing pinch points crept in.

I'm not exactly clear on what a "parsing pinch point" is, but is it
expected that when the syntax gets formally specified, various weird
aspects of the grammar will suddenly spring to life (like a couple
that I've mentioned recently) and be fixed, breaking a few (or many?)
wikis? Is it anticipated that the grammar will be "fixed"?

Steve


from_name: Amgine

subject: [Foundation-l] Wikiversity

body:
On 14-Aug-06, at 4:35 PM, Elisabeth Bauer wrote:

> James Hare wrote:
>> A thing that should be pointed out...
>>
>> Don't worry about policies and guidelines, start working on things
>> and let
>> the policies come in later. I believe Jimbo posted something to
>> this effect
>> when Wikinews was new.
>>
>> However, things that SHOULD be noted include NPOV.
>
> I'm not sure if the concept of NPOV fits for a collaborative research
> project. Maybe one of the project supporters can say something
> about this.
>
> greetings,
> elian

That would be very interesting, since as I have been led to believe
research is not a part of the project until they have developed at
least minimal guidelines for approving it. NPOV is an element of good
research, as is an ethics review board, and human subjects review
board that is relevant.

Amgine

-------------- next part --------------


subject: [Foundation-l] Wikiversity


subject: [Wikitech-l] OTRS down?

body:
okay... is anybody working on it? (yes, i AM missing IRC desperately)
Michael

On 8/14/06, Adam Lorenz <kungfuadam at gmail.com> wrote:
> I think so, it doesn't work here either.
>
> Adam
>
>
> On 8/14/06, Michael Bimmler <mbimmler at gmail.com> wrote:
> >
> > Could it be that OTRS is down at the moment?
> > https://secure.wikimedia.org/otrs/index.pl  seems to give a time-out
> > response.
> > (I would have asked in IRC but I'm not at my own computer at the moment)
> > Michael
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Adam J. Lorenz
> Charleston, SC
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
Steve Bennett wrote:
> http://en.wikipedia.org/wiki/Image:Cherry_keyboard.jpg
>
> Is that it down next to the Y? [...]

I would say so.


subject: [Wikitech-l] OTRS down?

body:
question withdrawn, worksforme again.
Michael

On 8/14/06, Michael Bimmler <mbimmler at gmail.com> wrote:
> okay... is anybody working on it? (yes, i AM missing IRC desperately)
> Michael
>
> On 8/14/06, Adam Lorenz <kungfuadam at gmail.com> wrote:
> > I think so, it doesn't work here either.
> >
> > Adam
> >
> >
> > On 8/14/06, Michael Bimmler <mbimmler at gmail.com> wrote:
> > >
> > > Could it be that OTRS is down at the moment?
> > > https://secure.wikimedia.org/otrs/index.pl  seems to give a time-out
> > > response.
> > > (I would have asked in IRC but I'm not at my own computer at the moment)
> > > Michael
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l at wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> > >
> >
> >
> >
> > --
> > Adam J. Lorenz
> > Charleston, SC
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>


from_name: Brad Patrick

body:
I'm not sure what you mean.  Angela has announced she is leaving the
Board.  This election will fill her slot.

Jon Harald S?by wrote:
> This presumably means there will be no new seats up for election this year?
>
> On 8/14/06, Dariusz Siedlecki <datrio at gmail.com> wrote:
>
>> (Copy/paste from Meta, yes, I'm lazy)
>>
>> Following the Boston Board meeting on August 4, we the Election
>> Officers announce hereby the upcoming September election will fill the
>> board position of Angela Beesley.
>>
>> We wish all candidates good luck,
>> Datrio, Essjay, & Aphaia
>> 19:00, 14 August 2006 (UTC), Election Officials, Wikimedia Election
>> Committee 2006
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l at wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>>
>>
>
>
>


body:
On 8/14/06, Ligulem <ligulem at pobox.com> wrote:
> Steve Bennett wrote:
> > http://en.wikipedia.org/wiki/Image:Cherry_keyboard.jpg
> >
> > Is that it down next to the Y? [...]
>
> I would say so.

Yeah, it's a bit clearer in this image:
http://en.wikipedia.org/wiki/Image:KeyboardLayout-German.png

Steve


from_name: Edward Z. Yang

subject: [Wikitech-l] Wysiwyg debate

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simetrical wrote:
> Jay is right that coloring the refs probably wouldn't be too hard with
> current wikitext.  Ideally, WYSIWYG would handle refs in some special
> way so that editing them is fully intuitive and uncluttered.
> Something like being able to click the ref number to bring up a
> floating popup-y thing that you could edit, while also being able to
> click the ref in the references section and edit that directly, with
> the Javascript keeping them synced and secretly editing only the <ref>
> contents either way.

Or implementing them using WikiData to store references and linking to
that data from article text.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE4OTrqTO+fYacSNoRAsBaAJsGGDFdMvaGTHEZLunbrFEOC47JVgCdGob3
v3CkOXStdBOfWsXgGxEg3rI=
=Guq6
-----END PGP SIGNATURE-----


subject: [Wikitech-l] Real live preview

body:
Since that WYSIWYG thread is becoming excessively long, and I already wasted
three hours trying to read the arguments, and didn't even get halfway
through the thread, I'll just post anyway. Forgive me I repeat something
already said.

There's two opinions that throw the baby out with the bathwater: one asks
for complete WYSIWG editing, and the other one includes no support for that.
Both of them have no chance of making it through, so try to pick things out
of them that are beneficial and try to combine them.

I have "Show preview on first edit" enabled on my preferences, so I see the
current state of a page every time when I click edit. My current approach is
to hover down to where the edit box is and attack the blob of text
indiscriminately, then click "Show preview" and make sure I didn't destroy
anything. Most users do that, so we already have a wikitext->parsed text
conversion going. Why don't we have a parsed text->wikitext conversion
available too? For example, I could click on the "preview" text, type a
sentence or correct a typo, make sure it looks ok, then click an "refresh
boxes" button that would update the edit box with the text I added, and if
possible, convert it to wikitext, where the current save and preview
functions would still be available.

This has several advantages:
* There is a considerably lower barrier to entry
* Making a change on the preview pane will also update the wikitext, which
allows users to see what changes they did, and more importantly, the wiki
markup that corresponds to those changes, making the learning curve easier
* Seasoned editors do not need to touch the preview text; they can go
straight for the markup in the edit box
* It can be disabled in a user's preferences, if it really gets that
annoying for the user to have to deal with it
* More complicated edits on the preview pane, such as adding a wikilink, can
be done only with button, essentially encouraging editors to learn wiki
markup
* Adding unsafe HTML tags can be disabled when preview pane editing, or even
better - all XHTML tags need to be added through the current edit box, to
discourage their use
* No real changes to data storage, parser tests, etc...

Since it is not a matter of whether it is going to be done, wouldn't that be
a better approach, instead of forcing all users to have to go under a system
they may not like?

Titoxd.


list: commons-l

from_name: Gregory Maxwell

subject: [Commons-l] Editorial use vs commercial exploitation

body:
On 8/14/06, Sherool <jamydlan at online.no> wrote:
> While such licences are free-ish I don't think they would fall fully
> within the definition of free content (thouh IANAL). Either way they would
> not be compatable with the GFDL licence, since it does not put any
> restrictions on who can use a work or for what purpose, and unless I'm
> mistaken GFDL compatability is the acid test for wether or not something
> is allowed on Commons.

These are unfree licenses. Like any other 'non commercial' license
they create a huge area of grey... For example, if we sell a Wikipedia
DVD to help fun the project is that commercial exploitation?

This is no new revelation. Photographs of copyrighted art must be
released under a free license by all copyright holders. Photographs
which incidentally include copyrighted works do not concern us.


from_name: Timwi

subject:
[Wikitech-l] Using a template to set some character formatting
 to several blocks of text

body:
Steve Bennett wrote:
> On 8/12/06, Timwi <timwi at gmx.net> wrote:
>
>>You do that using <div class='some_name'>. This allows you to specify
>>the actual style (font, color, etc.) in the CSS, which is much more of a
>>"template" in its literal meaning than {{...}} is.
>
> What exactly do you mean by "the CSS". If one refers to a new class in
> a page, where does one define it? At the top of the page? In some
> other .css file?

"The CSS" is the CSS that is included in any particular page view.
Currently the only way to include CSS in a page view is to place it on
[[MediaWiki:Monobook.css]], [[MediaWiki:Common.css]], or any page that
is @import'ed from these. However, obviously, it is entirely possible to
add a feature to MediaWiki that allows the inclusion of certain CSS on a
specific page. One could even have the parser pick out all the 'class'
attributes and include all the necessary CSS for those automatically.
The only problem with things like this is that I'm the only one that
seems to think it's a good idea, while most other people like to stay
with old, limited and never-evolving systems.

Timwi


body:
Steve Bennett wrote:
> On 8/12/06, Edward Z. Yang <edwardzyang at thewritingpot.com> wrote:
>
>>Manual of Style?
>
> Nah, it doesn't cover much beyond the basics - certainly not layout,
> colours, etc. And these days most of what gets added to it is fairly
> equivocal - "sometimes you should do this, but this is ok too".

There is no reason why this shouldn't change. The purpose of the manual
of style is to prescribe a consistent style, and the proper way to do
this on the web is to prescribe the use of semantic CSS classes.


from_name: Elisabeth Bauer

subject: [Foundation-l] bylaws (second call)

body:
Ray Saintonge wrote:

> I have yet to see a clear rationale for a memberless Foundation.

and I have yet to see a clear rationale for a foundation with members.

For not having members, I see several reasons:
* adds one more organisational burden on the already strained office
resources of the foundation (it would need a membership management then,
letters to the members, lots of paperwork)
* what about the chapters? Should their members become automatically
members of the Foundation? How do you deal with the injustice of
different membership fees then (polish chapter has no fees, germans
pay)? Or should they have to choose between single memberships and
double memberships? What would be the incentive for becoming a member of
a local chapter then?
* How do you deal with the injustice of membership fees in general? One
dollar is much more money in Pakistan than in the US...
* Would people in Pakistan even think of becoming members in an US based
foundation? Or would it turn into a totally US centric organization,
contrary to its international and multilingual goals?

and last but not least, what would be the relation between the countless
members of the projects and the paying foundation members? Should only
the latter have the right to vote for board members and influence
foundation decisions?

Originally, I was undecided about the membership issue, but more and
more I have the feeling that it would not work well with the
organizational structure we developped over the last years.

We have a large community from all over the world and they constitute
the members of the foundation. If the next board elections show that the
community is unable to fullfill this role (by electing someone
unsuitable), we can think about a different setup, but honestly, I trust
the people to elect a responsible new board member. In the future, we'd
have to think about how to make sure that the smaller projects get
adequate influence and that the foundation is not dominated by the
english wikipedia. But even this, I think, is better accomplished by
letting members of all projects have their say instead of just those who
   bothered to mail a membership form to the foundation and pay 100$.

greetings,
elian


subject: [Foundation-l] bylaws (second call)


body:
On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> The problem, Lars, is that several of the partisans on the "WYSIWYG
> should take over the world" side of the argument are framing approaches
> that would, in fact, force us -- practically -- to use WYSIWYG editing:
> I don't think *anyone* who edits in wikitext now would bother if they
> had to do it in XML.
>
> I certainly wouldn't.
>
> Rob wouldn't either.

Can we just take it as read that any "solution" which involves a
strict choice between WYSIWYG and editing in XML is not viable, not
attractive and not worth further discussing?

Steve


subject: [Wikitech-l] Desire to Contribute

body:
On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> An argument seems to be being made (by the side which, clearly, I am
> not on) that there is a group of contributors out there who

Let's call them "random people" rather than "group of contributors".

>         a) have something useful to contribute to WP

Yep, whether it be fixing typos, pointing out errors, or even adding a
sentence or two.

>         b) have "precisely zero" interest in expending any effort
>                 to learn how to do so -- when that wall is *stunningly*
>                 low.  (This isn't Framemaker, folks.)

Yep. They're browsing the web. They're not doing homework.

> If they can't be bothered to learn wikitext, can they be bothered to
> read [[Assume Good Faith]]?  Or [[NPOV]]?  Or follow the [[Village
> Pump]], etc, etc, ad nauseum?

Nope. But that's ok, you need very little of that to make such small
contributions. WP:V is probably the only one worth knowing about, and
that can be summarised in the sentence "Tell us where you heard this,
so we can check it."

> Are we equipped, as a community, to deal with (let us say) tripling the
> number of active editors we have now, where most of the new ones can't
> be bothered to learn... well, anything?

I wouldn't call them "active editors". Is a one-time buyer of a train
ticket an "active public transport user?" Someone who dropped some
rubbish an "active litterer?" Etc.

But, to answer your question, yes. Haven't seen a lot of problems with
newbies, most of the problems seem to come from oldbies.

> Some would say we're in critical trouble on that front *now*; it
> doesn't make much sense to me to enable new people who "are willing to
> expend precisely zero energy" on working with our community, such as it
> is.

Who would say that?

Steve


subject:
[Wikitech-l] 404 on en.wikipedia.org: Server-side HTTP header
 instead of client-side meta-refresh?

body:
Brion Vibber wrote:
> Nick Jenkins wrote:
>
>>If I go to http://en.wikipedia.org/Tokyo (note the missing "/wiki"), I get a
>>404 page that contains a 5 second-client side refresh tag like so: <meta
>>http-equiv="Refresh" content="5; URL=http://en.wikipedia.org/wiki/Tokyo">
>>
>>Is there any chance we could follow the great example of the PHP folks, and
>>immediately give the user what they really want (e.g. http://php.net/date ,
>>which instantly shows the user the content of the
>>http://php.net/manual/en/function.date.php page) ?
>
> I nixed that because then you've got scary unstable URLs being linked to. The
> URL system may change, potentially dramatically so, and they'll no longer work.
> (But I'm a bit of a stickler about stable URLs on articles.)

I can't say I agree to this hand-wavy argumentation. There is no reason
to believe that any substantial amount of people would create links to
the redirecting URL. My guess is that 95% of people go to Wikipedia, use
the search function to find the article, and then copy & paste the URL.
Another 4% construct the URL manually and then copy & paste the URL it
redirected to. The remaining 1% are the wackos who construct URLs
without actually trying them, and neither a 301 header nor the current
5-second soft redirect helps against those. Therefore, the 301 redirect
is clearly more beneficial.

> The PHP manual example is particularly dangerous because they don't even issue
> an HTTP redirect, it just spits the content right back. Bad for caching and for
> linking.

That, I agree with -- unless they have made clever arrangements to
prevent themselves from needing to use those URLs for other purposes in
future.

Timwi


body:
On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Mon, Aug 14, 2006 at 10:39:33AM +0200, Steve Bennett wrote:
> > Can we please have this at Wikipedia? Please please please? It would
> > make so much of the editing I do soooo much faster.
>
> Steve: that's the code Jimbo was quoted as saying there's a paid
> project to integrate.
>
> So, yes.

Yeah, but I want it *now*. :)  (ok, after they fix a couple of bugs,
and make it possible to edit pages that don't have any section
headings...)

Actually I'm a little confused on this Wikia business. Wikia is
apparently testing WIKYWYG. Wikia is owned by Jimbo. Wikia is not
GFDL. After that, things get hazy for me.

Steve


body:
Brion Vibber wrote:
> Steve Bennett wrote:
>
>>Would this be an appropriate time for me to ask that if you go to a
>>redirected article (say, George Walker Bush), then you would properly
>>redirected to end up at http://en.wikipedia.org/wiki/George_W_Bush,
>>rather than http://en.wikipedia.org/wiki/George_Walker_Bush with
>>content from the George W Bush page (and the words "redirected from").
>>
>>I'm sure I had a good reason for requesting this, but it escapes me at
>>the moment. If anyone knows...:)
>
> We should have a FAQ for this. :)
>
> /me digs up an old response
>
> http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html

How ironic that you link to the one where I replied and refuted your
weak arguments. You have shown in that thread that you are stuck up with
your false dilemma and are unable to understand (much less conceive) any
alternatives.

Timwi


from_name: Eric Astor

body:
> -----Original Message-----
> From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-
> bounces at wikimedia.org] On Behalf Of Jay R. Ashworth
> Sent: Monday, August 14, 2006 10:42 AM
> To: wikitech-l at wikimedia.org
> Subject: Re: [Wikitech-l] Apple's Wiki Server brings WYSIWYG to wiki
>
> On Mon, Aug 14, 2006 at 03:06:18AM -0400, Simetrical wrote:
> > So how about using XHTML internally and when sending to WYSIWYG, but
> > if the user wants to manually edit it can be converted to wikitext and
> > then back?
>
> Size.
>
> One of the reasons wikitext is as easy to comprehend as Rob and I
> assert that it is (and you disagree with) is that it is *physically
> compact*.
>
> Hey, brion: what's the size of article bodies right now, in GB?  :-)

Just a note on size - this is an argument that I think holds a lot of value.
XHTML is, on average, about 12x larger than wikitext...

- Eric Astor

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.9/417 - Release Date: 8/11/2006


body:
Steve Bennett wrote:
> On 8/11/06, Brion Vibber <brion at pobox.com> wrote:
>
>>We should have a FAQ for this. :)
>>
>>/me digs up an old response
>>
>>http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
>
> Ok, that actually makes sense. Summarising: You have two options. Either:
>
> a) It hard redirects you, and there's absolutely no link back to where
> you came from. Very bad for maintenance, working on the redirect
> itself etc.
> b) It redirects you, but leaves the link back to the original
> redirecting page.

or (c) It hard redirects you, and there's a link back to where you came
from.

This is the false dilemma.

Timwi


from_name: Simetrical

body:
On 8/14/06, Eric Astor <eastor1 at swarthmore.edu> wrote:
> Just a note on size - this is an argument that I think holds a lot of value.
> XHTML is, on average, about 12x larger than wikitext...

Out of curiosity, where'd you get that figure?  Recall that we aren't
talking about the page output, just an XMLized wikimarkup (so
something like <wm:a href="link">display</wm:a> instead of
[[link|display]]).


from_name: Dan Li

body:
On 8/14/06, Nick Jenkins <nickpj at gmail.com> wrote:
> Please note that wikiwyg does not currently solve this problem (i.e. you cannot currently use Neapolitan quotes as a valid argument
> in favour of wikiwyg).
>
> As you can see from this edit :
> http://wikiwyg.wikia.com/index.php?title=Testpage&diff=136009&oldid=136007#Neapolitan_double_quotes:_dsomething (which was typed in
> wikiwyg mode), the '' gets converted to italics upon saving, not rendered as a literal '' (i.e. what you see in the wikiwyg mode -
> two quotes - is not what you get in the rendered HTML output after saving - italics in the headline).
>
> All the best,
> Nick.

If this is supposed to be a true WYSIWYG editor, then that's probably
just a bug. Somebody forgot they had to put <nowiki>'s around
wiki-markup.

Regards,
  - Dan Li


subject: [Wikitech-l] Wysiwyg debate

body:
Steve Bennett wrote:
> On 8/11/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
>>I think tables are just as bad as infoboxes, okay fine.. a concession:
>>they are indeed worse. The point I was trying to make was more along
>>the lines of "when someone wants to edit the intro and they get
>>something which is not the intro it leads to confusion".
>
> Yes. Footnotes sometimes have this effect too, as do excessive use of
> arcane page layout formatting.

I think the absolute worst part of this is references.

Firstly, if you spot a typo in a reference, the instinct is to click the
"edit" link for the References section. But then all you see is:

	== References ==
	<references/>

The other thing is that if you spot a typo in the middle of a paragraph
which has inline references in every sentence, it is *extremely* hard to
find that typo because all the inline references distract. You look
somewhere and you don't even know if you're looking at the paragraph or
the inside of a <ref> tag.

If the person designing the references syntax had thought about this a
bit more, these severe problems should have been apparent to them. A
much more sensible thing would be to use [1], [2] etc. in the text, and
define the references in the place where they are actually displayed --
the References section. (Duh.)

Timwi


body:
> -----Original Message-----
> From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-
> bounces at wikimedia.org] On Behalf Of Simetrical
> Sent: Monday, August 14, 2006 5:37 PM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Apple's Wiki Server brings WYSIWYG to wiki
>
>> ... 12x larger ...
>
> Out of curiosity, where'd you get that figure?  Recall that we aren't
> talking about the page output, just an XMLized wikimarkup (so
> something like <wm:a href="link">display</wm:a> instead of
> [[link|display]]).

Experiments with page output, actually, for the full Simple English
Wikipedia... My experiments also showed compressed HTML for the full page
output to be roughly 3x larger than compressed wikitext. That is full page
output, so the point is probably lost somewhat - but considering that the
full output should be *more* repetitive than the XML-ized markup, I'd still
be surprised if the database didn't double in size, at a minimum. Anyone
care to run the full database through a conversion to XML and run the
experiments? I'm a little short on time lately.

- Eric Astor

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.9/417 - Release Date: 8/11/2006


list: textbook-l

from_name: listspam at cretin.net

subject: [Textbook-l] Printed Versions of Textbooks

body:
> I think the time is ripe for this to happen, and for some significant
> publications to start coming out of the Wikibooks project.  I'm even
> willing to put some of my own money into this endeavor, but I would also
> like to see if there is any additional interest in those sympathetic to
> Wikibooks who would like to join me in this effort.

I think you should go for it! This is the whole point of the GFDL! Yay!

I would be willing to do some amount of layout and design work if that's
necessary and desired.

Kellen


subject: [Wikitech-l] Desire to Contribute

body:
On Mon, Aug 14, 2006 at 11:53:05PM +0200, Steve Bennett wrote:
> On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > That does not, and will not, stop me from Wishing and Hoping that
> > people will decide to Want to Learn again.
>
> Wikipedia is your hobby. Not theirs.

I wouldn't really characterise it as a hobby, for me, which is likely a
large part of the reason for this disconnect.  But apart from that, if
I was going to contribute my knowledge to the world on any topic, I
would want it to be useful and reflect well on me.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Steve Bennett

subject: [Wikitech-l] Desire to Contribute

body:
On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > But, to answer your question, yes. Haven't seen a lot of problems with
> > newbies, most of the problems seem to come from oldbies.
>
> Really?  I'll be darned.  Ok.

Ok, there are different sorts of problems, I'm a bit biased by a
stupid dispute I'm witnessing between two old-timers, who for the last
year have been arguing incessantly over whether the population of
Paris is about 2 million, or about 10 million.

Sigh.

Anyway I probably went a bit overboard there on "zero effort"
contributors. Shall we say that there are roughly three categories:
1) Total newbies
2) Casual contributors
3) Serious contributors

All three would benefit from a good  WYSIWYG.
Lack of a good GUI is likely to put off some categorie 1s from
becoming category 2s.
Lack of powerful editing features is likely to turn off category 3s.
Excessive separation of WYSIWYG and Wikitext may prevent category 2s
becoming category 3s.

Steve


from_name: Jeff V. Merkey

subject: [Foundation-l] Wikiversity

body:
Has anyone considered the possibility of actually instrumenting an
online course of instruction (beyond creating the content) and applying
for accredidation of the whole project and going after real funding?

Jeff

Anthere wrote:

>It came to my mind that we probably did not clearly announced here that
>we approved the creation of Wikiversity :-)
>
>Here is the resolution :
>http://wikimediafoundation.org/wiki/Resolution_Wikiversity
>
>A couple of important points
>
>1) there will be a domain at beta.wikiversity.org, where all new
>languages may contribute and start working on translation of guidelines
>etc...
>
>2) those languages with at least 10 active participants can request a
>separate domain name. As of today, I presume the english language has at
>least 10 people interested, so you guys may bug Brion to ask for
>en.wikiversity.org. I am not sure if it is the case for any other language.
>
>3) All sites will be flagged "beta" in the same way that wikinews has
>been for at least 6 months.
>
>4) During these 6 months, guidelines should be developped, *in
>particular* with regards to collaborative research. We would hope that
>these guidelines are as much as possible developped on the beta site (in
>particular collaborative research), so that all languages share a common
>goal and a few common non negociable rules.
>
>5) At the end of these 6 months period, the project will be reviewed, in
>particular so that the issue of collaborative research is qualified, and
>if possible to define whether the beta stage is over. Reviewal will be
>done by Spc.
>
>I hope that's clear... ;-)
>
>We wish good luck to this project.
>
>Ant
>
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>


subject: [Foundation-l] Wikiversity


subject: [Foundation-l] Wikiversity

body:
Elisabeth Bauer wrote:

>James Hare wrote:
>
>
>>A thing that should be pointed out...
>>
>>Don't worry about policies and guidelines, start working on things and let
>>the policies come in later. I believe Jimbo posted something to this effect
>>when Wikinews was new.
>>
>>However, things that SHOULD be noted include NPOV.
>>
>>
>
>I'm not sure if the concept of NPOV fits for a collaborative research
>project. Maybe one of the project supporters can say something about this.
>
>greetings,
>elian
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>
The concept of "Academic Freedom" does fit and the normal MeatBall rules
should not apply.

Jeff


subject: [Foundation-l] Wikiversity


from_name: GerardM

body:
Hoi,
What does it matter that the content of Wikia is not GFDL.. MediaWiki is
also not GFDL...

We are talking about software here. The license of the MediaWiki software is
GPL. The software that Wikia produces will also be GPL because when it is
not, it will not integrate with the MediaWiki software..

Thanks,
     GerardM

On 8/14/06, Steve Bennett <stevage at gmail.com> wrote:
>
> On 8/14/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > On Mon, Aug 14, 2006 at 10:39:33AM +0200, Steve Bennett wrote:
> > > Can we please have this at Wikipedia? Please please please? It would
> > > make so much of the editing I do soooo much faster.
> >
> > Steve: that's the code Jimbo was quoted as saying there's a paid
> > project to integrate.
> >
> > So, yes.
>
> Yeah, but I want it *now*. :)  (ok, after they fix a couple of bugs,
> and make it possible to edit pages that don't have any section
> headings...)
>
> Actually I'm a little confused on this Wikia business. Wikia is
> apparently testing WIKYWYG. Wikia is owned by Jimbo. Wikia is not
> GFDL. After that, things get hazy for me.
>
> Steve
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Jay R. Ashworth

subject: [Wikitech-l] Desire to Contribute

body:
On Tue, Aug 15, 2006 at 12:28:15AM +0200, Steve Bennett wrote:
> Seriously. People are what they are. We can attempt to change
> everyone, or we can work with what we've got.

*Exactly*.

:-)

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] Desire to Contribute

body:
On Mon, Aug 14, 2006 at 03:26:26PM -0700, mboverload wrote:
> Maybe I'm missing something here:
>
> You don't need to learn ANYTHING.  Hit the edit button, fix the typo, and
> you're done.

My message was, perhaps, not the best one to chain that reply on, as I
agree with you... ;-)

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Ray Saintonge

body:
geni wrote:

>On 8/14/06, jayjg <jayjg99 at gmail.com> wrote:
>
>
>>The Bible is usually considered a primary source, and many differing
>>versions of quotations are all acceptable.
>>
>>
>That ah could be problematical. The obvious example being the changes
>that we know have been made from older versions and in various
>tranlations (there are direct factual conflicts between NIV and KJV).
>
For an example of a project that is still in its early stages see
http://en.wikisource.org/wiki/Bible/Obadiah/1/19

Ec


body:
On 8/14/06, Eric Astor <eastor1 at swarthmore.edu> wrote:
> Experiments with page output, actually, for the full Simple English
> Wikipedia... My experiments also showed compressed HTML for the full page
> output to be roughly 3x larger than compressed wikitext. That is full page
> output, so the point is probably lost somewhat - but considering that the
> full output should be *more* repetitive than the XML-ized markup, I'd still
> be surprised if the database didn't double in size, at a minimum. Anyone
> care to run the full database through a conversion to XML and run the
> experiments? I'm a little short on time lately.

I've converted the first few sections of [[Paris]] (by hand) and done
the comparison on them.  (The XML isn't perfect ? I didn't convert
character entities, for instance ? but it suffices.)  The input was
12.7 KB, the XML 17.1 KB; after ZIPping with normal compression, the
difference dropped to 5.12 KB to 5.43 KB, and with best-compression
RAR, the XML was actually a bit smaller (4.47 to 4.61).  If we *do*
work with compressed databases, then increase in size from XML looks
to be trivial.

(Files available upon request.)


body:
On 8/14/06, Timwi <timwi at gmx.net> wrote:
> There is no reason why this shouldn't change. The purpose of the manual
> of style is to prescribe a consistent style, and the proper way to do
> this on the web is to prescribe the use of semantic CSS classes.

Yes, the MoS should be prescriptive. I'm thinking it would actually be
a good idea to split it in half, as it addresses the quite disparate
topics of *style* (grammar, expression, naming...) and *layout*
(headings, HTML, images etc).

Steve


body:
On 8/14/06, GerardM <gerard.meijssen at gmail.com> wrote:
> We are talking about software here. The license of the MediaWiki software is
> GPL. The software that Wikia produces will also be GPL because when it is
> not, it will not integrate with the MediaWiki software..

Ok, that's what I was wondering. Is that true though? You can't
"integrate" non-GPL software with GPL software? Anyway, it was just a
vague query that I had.

Steve


body:
On 8/14/06, Steve Bennett <stevage at gmail.com> wrote:
> Right, but can the GPL'd program integrate non-GPL'ed source? E.g.,
> can MediaWiki use non GPL'ed source code?

No.  Combining source code, at least in the view of the GNU Project,
constitutes forming a derivative work of both sources of code.  Any
derivative work of a work used under the GPL must itself be licensed
under the GPL.  (This interpretation has not been tested in court, of
course, but the WMF is pretty unlikely to disrespect it.)


from_name: Nick Jenkins

subject: [Wikitech-l] Wikipedia Suggest

body:
Hi Julien,

> The latest version of the sources with all these modifications is
> available at :
> http://suggest.speedblue.org/tgz/wikipedia-suggest-0.31.tar.gz

Some search suggestion updates:

* Got rid of the race condition in autocomplete when user types fast (e.g. can type "new" fast without having it lose the
highlighting on " York").
* Removed the first field from the JSON response from TcpQuery (basically client was asking a question, and getting a response from
server that said "the question you asked is this, and the answer is this" - however we only need the answer back, not the question).
Also removed a handful of spaces that aren't needed in the JSON data.
* Pressing "Enter" on a response which has no matches will now invoke MediaWiki's "Special:Search" on that query.
* Moved the URL to the wiki to index.php (as "var baseUrl"), which hopefully means that a single WSuggest.js file can be used for
both English and French.
* Added a CHANGELOG file to keep track of what's changed + release dates.
* With the "var autocomplete" + delete key stuff (intKey == 8), I think the intent was to update the suggestion list (but not the
autocomplete) if the user presses the backspace/delete keys. Added a 'showAutocomplete' boolean parameter for this.
* If the user searched for "XYZ Affair", then deleted the "Y" to give "XZ Affair", it would still show "XYZ Affair" as the only
matching result (when really there are no matching results). To prevent this removed the 'cache' boolean var.

Patch against 0.31 is at http://files.nickj.org/MediaWiki/wikipedia-suggest-0.31-diff.txt

All the best,
Nick.


from_name: charles.r.matthews at ntlworld.com

subject:
[WikiEN-l] Invited by admin to leave en if concerned about free
	reusability

body:
Stan Shebs wrote

> To me it says that en: has gotten big. I think the old assumption
> was that the definition of admin as "trustworthy editor" really
> meant that admins would naturally tend to be in agreement about
> philosophy and principles.

en-WP does scale/doesn't scale. One can make both cases. On the one hand, just as the hardware now copes with hugely more traffic, so also the social arrangements are perhaps surprisingly robust in relation to continued growth. OTOH, there are possibly some areas where there is no consensus, and the absence of a really agreed basis of how to proceed is storing up issues (which cannot adequately be aired). I come down on the optimist side of the argument, myself. The old-school wiki-way says if you don't like it, leave and come back some other time. Plenty of folk do stay and keep it all very constructive.

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


body:
On 8/14/06, Timwi <timwi at gmx.net> wrote:
> > a) It hard redirects you, and there's absolutely no link back to where
> > you came from. Very bad for maintenance, working on the redirect
> > itself etc.
> > b) It redirects you, but leaves the link back to the original
> > redirecting page.
>
> or (c) It hard redirects you, and there's a link back to where you came
> from.

Ok, what do "hard direct" and "soft redirect" mean in this context
exactly? Let's take some page A which redirects to page B. They're
hosted directly at wiki.org.

Currently wiki.org/A shows the content of wiki.org/B, but with a link
back to A. The URL shows wiki.org/A.

You're proposing that wiki.org/A force a (server-side?) redirect to
wiki.org/B, display the content of B, with a link back to A, and yet
the URL shows wiki.org/B? The question is, how does MediaWiki know to
show the link back if the URL is only wiki.org/B, and not
wiki.org/B&red=A or something?

Forgive my ignorance, I have absolutely no idea how server side redirects work.

Steve


subject: [Wikitech-l] Wysiwyg debate

body:
On 8/14/06, Timwi <timwi at gmx.net> wrote:
> I think the absolute worst part of this is references.
>
> Firstly, if you spot a typo in a reference, the instinct is to click the
> "edit" link for the References section. But then all you see is:
>
>         == References ==
>         <references/>

Yes.

> The other thing is that if you spot a typo in the middle of a paragraph
> which has inline references in every sentence, it is *extremely* hard to
> find that typo because all the inline references distract. You look
> somewhere and you don't even know if you're looking at the paragraph or
> the inside of a <ref> tag.

Agreed again. And you haven't even mentionde the problem of
multiply-used footnotes.

To me this says that the needs of the creator of the footnote, and the
needs of the future maintainer of the footnote are in direct conflict.

> If the person designing the references syntax had thought about this a
> bit more, these severe problems should have been apparent to them. A
> much more sensible thing would be to use [1], [2] etc. in the text, and
> define the references in the place where they are actually displayed --
> the References section. (Duh.)

We used to have a system (or 3) like that. It was crap. Hard numbering
footnotes is an awful solution.

The only thing I can think of that would work is that a person can add
a footnote like this:

Sometext<ref> a reference in the good old style</ref>...some more text.

...which the software would actually move down to the references section.

Sometext<ref name="ref1"/>...some more text.
...
<references>
<ref name="ref1">a reference in the good old style</ref>
</references>

Easy on the writer, easy on the maintainer. And totally confusing for
aynone who witnesses the transition.

Steve


from_name: David Gerard

subject: [WikiEN-l] CITE nazis

body:
On 14/08/06, stevertigo <vertigosteve at yahoo.com> wrote:

> Im not sure on the stats, but it is my impression that this demand for
> verifiability is 1) deletionistic 2) one sided, and not applied to one's
> own person and 3) comes with some attached notion of "reliable sources" by
> which material from any deemed "unreliable" sources can be deleted.
> Thats the topic. Discuss.

e.g. the War on Blogs, wherein some editors have got it into their
heads that ALL BLOGS ARE EVIL AND MUST NEVER BE USED IN REFERENCES
rather than e.g. regarding them as, say, lesser sources than
peer-reviewed academic papers and assuming the reader can read. The
response to crap sources is to say "those are crap sources, cut it
out" rather than countering foolishness with foolishness.

On non-contentious topics, the right way to do it would be to shift it
to the talk page for discussion and an attempt at sourcing, e.g. the
stuff on the early [[Casio Exilim]]s being crap in low light is
observed by a pile of Exilim owners (e.g. me) but I can't find a good
source - so out it goes as original research, but it's on the talk
page should I or someone find something verifiable showing this to be
an issue.

On contentious topics, there is good reason to be hard-arsed about
sources. But that doesn't mean you go overboard and legalistic because
someone who hates blogs edit-warred that wording into WP:V.

- d.


from_name: James Hare

subject: [Foundation-l] Wikiversity

body:
A thing that should be pointed out...

Don't worry about policies and guidelines, start working on things and let
the policies come in later. I believe Jimbo posted something to this effect
when Wikinews was new.

However, things that SHOULD be noted include NPOV.

On 8/14/06, Anthere <Anthere9 at yahoo.com> wrote:
>
> It came to my mind that we probably did not clearly announced here that
> we approved the creation of Wikiversity :-)
>
> Here is the resolution :
> http://wikimediafoundation.org/wiki/Resolution_Wikiversity
>
> A couple of important points
>
> 1) there will be a domain at beta.wikiversity.org, where all new
> languages may contribute and start working on translation of guidelines
> etc...
>
> 2) those languages with at least 10 active participants can request a
> separate domain name. As of today, I presume the english language has at
> least 10 people interested, so you guys may bug Brion to ask for
> en.wikiversity.org. I am not sure if it is the case for any other
> language.
>
> 3) All sites will be flagged "beta" in the same way that wikinews has
> been for at least 6 months.
>
> 4) During these 6 months, guidelines should be developped, *in
> particular* with regards to collaborative research. We would hope that
> these guidelines are as much as possible developped on the beta site (in
> particular collaborative research), so that all languages share a common
> goal and a few common non negociable rules.
>
> 5) At the end of these 6 months period, the project will be reviewed, in
> particular so that the issue of collaborative research is qualified, and
> if possible to define whether the beta stage is over. Reviewal will be
> done by Spc.
>
> I hope that's clear... ;-)
>
> We wish good luck to this project.
>
> Ant
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


subject: [Foundation-l] Wikiversity


subject: [WikiEN-l] SlimJay

body:
On 14/08/06, stevertigo <vertigosteve at yahoo.com> wrote:

> Somebody please tell SlimJay ( WP:RFC/Slim ) to knock it off
> with the wikistalking.

Er, what on earth? An RFC existing in existential space with no actual
signers or detailed conflict? On two editors who agree on lots and
don't agree on lots? Is this an attempt to outdo [[Wikipedia:Requests
for comment/Tony Sidaway 3]] for sheer artistic wonder?

- d.


subject: [WikiEN-l] CITE nazis

body:
On 14/08/06, stevertigo <vertigosteve at yahoo.com> wrote:

> David, one evil does not justify another.

No indeed it doesn't, and you should always warm the pot when making tea.#

(i.e. I have no idea how your comment follows from what I wrote.)

- d.


from_name: geni

body:
On 8/14/06, Stan Shebs <shebs at apple.com> wrote:
> I think this is another example of the leadership vacuum that we
> discussed earlier, and shows why it is not a trivial issue. We have
> no effective process for dealing with a group of fifty admins who
> collectively decide to take WP in a different direction;

We do. People keep trying to neutralise it but the comunity is a pain
to go against.

--
geni


body:
On Mon, Aug 14, 2006 at 06:48:17PM -0400, Simetrical wrote:
> On 8/14/06, Steve Bennett <stevage at gmail.com> wrote:
> > Right, but can the GPL'd program integrate non-GPL'ed source? E.g.,
> > can MediaWiki use non GPL'ed source code?
>
> No.  Combining source code, at least in the view of the GNU Project,
> constitutes forming a derivative work of both sources of code.  Any
> derivative work of a work used under the GPL must itself be licensed
> under the GPL.  (This interpretation has not been tested in court, of
> course, but the WMF is pretty unlikely to disrespect it.)

Actually, I believe the answer is a conditional yes: if the license
under which you acquire the code permits you to relicense it under the
GPL and distribute it, then you can take that path.

I'm not sure any of the standardised licenses would in fact let you do
that, but a private licence might, if so negotiated.

So it's not impossible, but practically?  Not so much.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] CITE nazis

body:
Verifiability is a basic pillar of Wikipedia, so we should clearly cite less
than well known statements. There's enough stuff out there that's often
cited as fact when they're really as wrong as you can get. Only the most
easily verifiable stuff can go unsourced.

I think it's only deletionist when you delete such claims that could be true
instead of giving people the chance to verify it. Only when you can falsify
it, it can be removed.

It's a fine line, but yes one should remain civil and friendly, but that's
no reason to go easy on people that fail to adhere to policy. Sometimes a
little harsh action can go a long way in teaching.

Mgm

On 8/14/06, stevertigo <vertigosteve at yahoo.com> wrote:
>
> Im not exactly the most citatious Wikipedian, but nor do I have any
> tendency to make claims which arent easily verifiable. Over the years
> though Ive encountered a number of Wikipedians (I wont name names) who
> abuse or violate a clean interpretation of CIVIL by referring to CITE
> or V as a basis for what is essentially ownership of an article; in the
> form of a revert, rather than a constructive edit, correction, or (gasp!)
> a collaborative and helpful attempt to find a source.
>
> Im not sure on the stats, but it is my impression that this demand for
> verifiability is 1) deletionistic 2) one sided, and not applied to one's
> own person and 3) comes with some attached notion of "reliable sources" by
> which material from any deemed "unreliable" sources can be deleted.
>
> Thats the topic. Discuss.
>
> Wikilove,
> -Stevertigo
>
>
>
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: maru dubshinki

subject:
[WikiEN-l] Future avenues of garnering participation;
	or, How Wikipedia is currently a crappy/crack-tastic game

body:
On 8/13/06, Ray Saintonge <saintonge at telus.net> wrote:
> maru dubshinki wrote:
>
> > Well, I was trying for a funny conclusion there. I doubt we could turn
> >
> >*all* of Wikipedia into a game - how would that even work, anyway?
> >You'd have people presented random paragraphs and asked where the
> >error is (in some cases added by computer, and in some cases not)?
> >That's the best I can come up with anyway, although it might be
> >interesting to have competitive article writing-based games - but
> >rather that we might as well formalize some otherwise tedious and
> >repetitve aspects of Wikipedia that do need to get done and put them
> >in game form so they can get done and free up editor effort for more
> >worthwhile things like writing new articles or rewriting old ones.
> >
> Why does the game need to be competitive?

Well, most previous examples are competitive, and competition
certainly is its own reward - I've noticed that cooperative games have
a hard time delivering whatever ther intangible reward is (like the
regard of one's peers) over the Internet. They work fine in person,
but online...

> A game that teaches co-operative skills in developing an article would
> be a very helpful educational tool.

Kind of like practice essays and articles, except your final product
goes on-wiki and you are graded by how much other editors feel needs
to be revised or added?

> Each student uses the Random article generator (perhaps with the help of
> a bot) to generate a list of ten articles that already exist on
> Wikipedia. He does not see the articles, only the titles. He then
> proceeds to write a first draft of an article on a chosen topic from
> that list. He uploads the article to a local wiki where the other
> students can view and edit the article. Marks can be allocated for
> different types of writing and editing, including big marks for
> achieving NPOV on a controversial topic and marks taken off for getting
> into an edit war.
>
> Ec

Meh. Edit wars are hard to generate on a small wiki AFAIK, and if the
other editors are fellow students, I don't see'em lasting long.
Wouldn't it be more effective to draw on the lists-of-missing-articles
like the Missing Encyclopedic Articles Project maintains, and get the
feedback from Wikipedia at large?  Feed'em through Peer Review, if
normal processes aren't enough.

~maru