body:
To add on to this, we already have Georgian, Irish, and Navajo Wikipedias.

Of these languages, Gikuyu and Georgian both have over 1 million
speakers, Navajo has about 180000 (including about 4000 monolinguals),
O'odham probably has around 45000 but it is not listed as a language
in records from the 2000 census for some reason so we can't know for
sure. (besides that, there are thousands of speakers on the Mexican
part of the reservation as well, and Native American languages are
often counted very inaccurately by the census, which has been known to
miss entire languages with thousands of speakers due to problems with
getting accurate census information from reservations)

Inuktitut has around 70000 speakers.

Irish cannot be placed for sure. Some people count all people who have
been taught Irish in school, which would be almost the entire
population of the Republic of Ireland (over 1 million); others count
only those residents of the Gaeltachta, others use various other
statistics.

Mark

On 10/06/05, Mark Williamson <node.ue at gmail.com> wrote:
> It's not "their own language".
>
> I can read, write, and speak Japanese to a sufficient degree that I
> can read articles in Japanese, but it's not "my language".
>
> For example, do you think Anthere considers English to be her
> language? Definitely not.
>
> Similarly Ngugi wa Thiong'o (formerly known as James Ngugi), winner of
> a nobel prize for his writing, would tell you that neither English nor
> Swahili -- his language is Gikuyu (ki.wikipedia.org, which just
> recently got its mainpage translated, but still has 0 pages... it has
> redlinks to pages about television, democracy, and the like though),
> the language of his mother, his father, his home.
>
> The language of former Japanese Diet member Shigeru Kayano is
> similarly not Japanese nor English. If you ask him what his language
> is, he will tell you that his language is Ainu without taking a moment
> to think.
>
> Susan Aglukark (Inuktitut "Susan Aglukkaq"), famous Canadian singer,
> will tell you that "her language" is Inuktitut -- not English or
> French -- the language of her hearth, of her family, of the arctic.
>
> Patrick Pearse would've told you "his language" was not English but Irish.
>
> Joseph Stalin (Georgian "Ioseb Jugashvili") may not be admired by
> everybody, but nevertheless he is a well-known figure and "his
> language" was not Russian but Georgian -- the language of his family,
> his ancestors.
>
> Joe Shirley, president of the Navajo Nation, will tell you that
> English is not "his language" -- although he can speak it well, "his
> language" and the language of his people is Dine bizaad, "the language
> of the humans".
>
> Vivian Juan-Saunders, the first ever female leader of the Tohono
> O'odham Nation (the US part of which is about the size of
> Connecticut), will tell you that "her language" and the language of
> the Nation is 'O'Odham Ni'ok -- again "the language of humans".
>
> "their language" could've been a bit ambiguous, but you said "their
> own language" -- their OWN language -- which goes deeper and implies
> more strongly that it truly belongs to them.
>
> Mark
>
> On 10/06/05, Jimmy Wales <jwales at wikia.com> wrote:
> > Mark Williamson wrote:
> > > You said, and I quote, "It is my intention to get a copy of Wikipedia
> > > to every single person on the planet in their own language."
> > >
> > > "In their own language" is unambiguous. Ngugi wa Thiong'o's "own
> > > language" is Gikuyu. He can read English very well, and Swahili very
> > > well. He would be able to read those Wikipedias. But they are not "in
> > > his own language".
> >
> > If you can competently read a language, it's "your own language".
> >
> > In terms of an actual practical definition of success, we have to use
> > something like 99.9% or 99.99%, because there will always be a handful
> > of quirky situations leftover.
> >
> > Let me put it this way.  If I die young (100 years from now ;-)) having
> > only gotten a free encyclopedia to 99.99% percent of the people in the
> > world, I won't feel that I've failed.
> >
> > --Jimbo
> >
>
> --
> SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
> QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
> POSSIT MATERIARI
> ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE
>

--
SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
POSSIT MATERIARI
ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE


list: wikien-l

source: pipermail-mbox

from_name: Ray Saintonge

subject: [WikiEN-l] My views on policies and debates over content

body:
James D. Forrester wrote:

>[[Sollog]] believes himself to be the son of God (AIUI, or God
>himself, or something), and there are very few, perhaps no, people who hold
>this opinions of him; thus, we would not mention his claim in the article,
>as it is inappropriately giving time and hence credence to a cause that does
>not warrant it. This, indeed, is exactly what we do do. Common sense seems
>to have triumphed. :-)
>
>
>>>I've never said that only one POV should be represented, only that
>>>extreme minority POVs shouldn't be.
>>>
>>>
>>This is still treating truth as a numbers game.  Sometimes great
>>scientific discoveries have come from people who stubbornly maintained
>>their opinions on a discovery.  Verifiability is a more important
>>criterion than being the position of a small minority.  Some
>>people who held the ridiculous minority notion that the earth went
>>around the sun were severely persecuted at one time.
>>
>>
>So? It's not our job to trumpet minor views "just in case" they turn out to
>be correct all along. Yes, we're "treating truth as a numbers game": it's
>called showing editorial judgement.
>
>
If Sollog is the only source of evidence for his being God he has a
verifiability problem.  Under those circumstances being a part of a
minority is moot.

Ec


list: wikitech-l

from_name: Rowan Collins

subject: [Wikitech-l] Re: Re: Re: Re: Namespace in Friulian Wiki

body:
On 10/06/05, A. Decorte <klenje at adriacom.it> wrote:
> Ok, thanks so I need to find out a developer... do you know someone I can
> contact? Thanks

Well, a request on this list or http://bugzilla.wikimedia.org would
probably get someone's attention eventually. If you want to be more
urgent and pester someone to do it "now", connect to irc.freenode.net
and join channel #wikimedia-tech

--
Rowan Collins BSc
[IMSoP]


from_name: Ævar Arnfjörð Bjarmason

subject: [Wikitech-l] substr vs mb_substr

body:
On 6/9/05, Brion Vibber <brion at pobox.com> wrote:
> ?var Arnfj?r? Bjarmason wrote:
> > Without having actually looked at the code but it should be using the
> > truncate() function from the language class, however the Language.php
> > version of that function is not Unicode aware so stuff like this will
> > continue happening until bug 2069 is solved
> > (http://bugzilla.wikimedia.org/show_bug.cgi?id=2069)
>
> I don't understand this claim. The LanguageUtf8 truncate *is* already
> UTF-8 aware; 2069 is a code layout issue only and does not affect
> functionality.
>
> If there's a bug here, it's from failing to call the function in the
> first place and letting the database crop the field.
>
I was assuming that it was a Latin-1 wiki ( didn't actually notice it
was the commons (they all look alike)).


subject: [WikiEN-l] Re: New Creative Commons Licenses - version 2.5

body:
On 10/06/05, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> By the way, I fail to see any difference between 2.0 and 2.5 Can some
> more law-savvy people explain the difference. I'm almost sure it's in
> the legal version of the license.

I find the creativecommons site very hard to find such information on,
although I'm sure it's there. But with a bit of Googling I turned up
the *beginning* of the discussion about v2.5...
http://lists.ibiblio.org/pipermail/cc-licenses/2005-May/002313.html
...and it "Drawing to a Close"...
http://creativecommons.org/weblog/entry/5457
...but no announcement that it has "become official", although it does
seem to have.

Basically, it seems to be to do with electing who gets attribution -
to allow collective and nominated attribution in some way. Don't ask
me how, or how this relates to the cc-wiki proposal, because I've only
skimmed the stuff, but the links above seem to basically explain it if
you have the patience to work it out.

--
Rowan Collins BSc
[IMSoP]


from_name: Brent 'Dax' Royal-Gordon

subject: [Wikitech-l] New syntax proposal

body:
Lee Daniel Crocker <lee at piclab.com> wrote:
> I decided to release my new syntax for comment before I
> finished the formal definition.  I'd like to get opinions
> about it; in particular:

This is extremely interesting, especially because I've been working on
a markup language called Kolophon that looks surprisingly similar,
especially in the common text formatting sequences.

One of the differences in it is that \\ is a null sequence, which you
can stick inside sequences that would otherwise be considered tokens:
**bold** would show up bold, but *\\*not*\\* wouldn't.  (Because all
tokens in it involve at least two characters--a newline and a star for
bullets, for example--the addition of a null sequence allows for a
universal escaping mechanism.)  You seem to be using \\ for something
else, but the concept might still apply.

Kolophon in summary:

Formatting:
    **bold**
    //italic//
    __cite__
    ==strike==
    ``code``
    ""unformatted""

 Hyperlink: [[http://www.google.com||Link]]
Transclude: {{Image:Foo.gif||caption}}
 Bi-relate: <<Category:films>>

\\  null sequence (used to break up tokens)
$$ident  variable
||  attribute separator

Line styles (at the beginning of a line):
    > blockquote
    * bullet
    # number
    ; term
    : definition
    ` code
    ? attributes for following paragraph
    ! table header
    | table cell
    - table row

Headings:
    = 1
    == 2
    === 3
    ==== 4

Special characters:
    &+   &
    &--  —
    &-   –
    &|   \
    &^   <br />
    &``  &lquot;
    &''  &rquot;
    &`   ‘
    &'   ’
    &<<  «
    &>>  »
    &<-  ←
    &->  →

--
Brent 'Dax' Royal-Gordon <brent at brentdax.com>
Perl and Parrot hacker


list: wikipedia-l

from_name: Mark Williamson

subject: [Wikipedia-l] Re: Enciclopedia Libre

body:
No, it wasn't directed at you and Susning.nu, it doesn't match because
as you said Susning has fewer articles than the Swedish Wikipedia, and
it doesn't share any articles.

But the part that does match is about you bragging (though to be fair,
you don't do it often). Simply describing that you are involved with
this project and that it has done so much, or whatever, is fine with
me and is most certainly not bragging. HOWEVER,, some of the comments
you have directed at me in other threads are definitely bragging. (if
you don't know which comments I'm talking about, I'll be happy to
point them out)

Mark

On 10/06/05, Lars Aronsson <lars at aronsson.se> wrote:
> Mark Williamson wrote:
>
> > If they're so innocent, why would they be hurt by "half-sung songs"?
>
> Come on, Mark.  Part of your description matches myself and my
> website susning.nu, a big non-English wiki.  Some readers might
> believe that you are pointing at me, and conclude that the other
> information is some kind of truth about me.  That hurts me.  If
> you really believe what you wrote, then I'm here to clarify any
> misunderstandings and answer your questions.  If you mean someone
> else, you will save me a lot of trouble by saying so.
>
> Perhaps you mean Erik M?ller and his infoAnarchy?  Perhaps you
> mean Jimbo Wales and his Wikicities?
>
> I'll assume the worst, and clarify your points as if they were
> relating to me.  As far as I know, you don't speak Swedish and are
> not a contributor to the Swedish Wikipedia, and so it disturbs me
> to learn that you might have such strong and possibly damaging
> opinions about me.  Who gave you these impressions?  Should you be
> more careful with trusting your sources?
>
> > > > I was thinking of another non-English semifork of Wikipedia
>
> Susning.nu has never been a fork (or "semifork", whatever that is)
> of Wikipedia.  It is a big Swedish wiki that I started from
> scratch after Larry Sanger made it clear that what I wanted to do
> would fall outside of Wikipedia's strictly encyclopedic scope. Not
> a single text has been copied or translated from Wikipedia to
> Susning.nu.  If that happened, it would be a copyright violation
> (unless the author dual licensed the text), since susning.nu does
> not enforce the GFDL license like Wikipedia does.  In many cases,
> susning.nu contributors have later copied their own texts to the
> Swedish Wikipedia, which of course is perfectly OK.
>
> > > > which has way more articles than the Wikipedia version, and
>
> This could be said a year ago, but today Susning.nu has 58,400
> articles, while the Swedish Wikipedia has 80,600.
>
> > > > whose owner is deeply involved in Wikipedia but while
>
> I'm not "deeply involved" in Wikipedia.  I'm an occasional
> contributor (user:LA2), but I've never been and have never aspired
> to be an administrator, bureaucrat, board member or developer of
> Wikipedia.  On the contrary, I've been extremely careful to point
> out the difference between the two projects, and kept myself at
> arm's length distance from anything Wikipedia.  I've never
> participated in any vote or opinion poll on how to run the
> project.
>
> > > > bragging in private e-mails and on-list about how much work
> > > > he/she does compared to others to put more free content
> > > > online,
>
> Back in 1992, I started Project Runeberg (runeberg.org), the
> Scandinavian e-text project, which possibly was the first "clone"
> of Project Gutenberg. In the more than 12 years since, quite a lot
> of out-of-copyright literature has been digitized there, including
> several old encyclopedias. Much of this has benefited the Swedish,
> Danish, and Finnish Wikipedia.  No description of who I am would
> be complete without mentioning this.  I've spent more hours on
> Project Runeberg than on any job or hobby I've ever had.
>
> > > > does not consider allowing the corresponding language
> > > > version of Wikipedia to share content.
>
> I'm contributing *some* of my texts and photos to Wikipedia, but
> that's not to say that everything I write or do is released for
> free.  Especially, the texts that I wrote for susning.nu are under
> my copyright without open licensing.  What others do with their
> texts on susning.nu is their decision, and the site does not force
> contributors to use any particular license.  In practice, this
> makes mirroring of the entire site impossible, and that is a
> deliberate choice; I don't believe in website mirroring.  I've
> also written texts and software for other purposes and customers.
> These texts belong to me or my customers and the copyright holders
> decide what or how to license them.
>
> --
>  Lars Aronsson (lars at aronsson.se)
>  Aronsson Datateknik - http://aronsson.se
>

--
SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
POSSIT MATERIARI
ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE


from_name: Andrea Forte

subject: [WikiEN-l] wikimania acceptance rate?

body:
Hi! I hear the acceptance letters are going out for Wikimania
submissions. Anyone know what the acceptance rate ended up at?

Andicat


from_name: Brion Vibber

subject: [Wikitech-l] Parser question

body:
Robert Jones wrote:
> I am trying to set up an RSS parser on a private wiki that uses the
> following for onsubmit:
>
> onsubmit="if(window.myInterval){window.clearInterval(window.myInterval);}if(
> importXML('rssLocal.php?feedURL='+escape(this.feedURL.value),'parseRSS',fals
> e,2000)){if(parseFloat(this.interv.value)){window.myInterval=window.setInter
> val('importXML(\'rssLocal.php?feedURL='+escape(this.feedURL.value)+'\',\'par
> seRSS\',false,2000);',parseFloat(this.interv.value)*60000);}}else{alert('You
> r browser cannot import XML, so it cannot view RSS feeds using this
> script');}return false;"
>
> The problem is that when I submit the page, every ' is replaced by a \'
> giving:

Where are you submitting it, exactly? In a wiki page or something else?
A regular wiki page? A user javascript page? MediaWiki:Monobook.js?

Where is the replaced text, exactly? In the source text stored in the
database? In the edit box editing the page again? In the rendered text?
In the output reading the .js?

Have you modified the wiki? In wiki-allowed HTML, onsubmit is barred
(not to mention <form>) and should not be showing up in output to begin
with. If you have changed it, exactly what have you changed? Or are you
working in an <html> section, or perhaps a custom extension that outputs
HTML?

What MediaWiki version are you using? What PHP version? Have you made
any non-standard PHP configuration options such as magic_quotes_runtime
(this will fatally break things if on)?

There is a bug up through 1.4.5 where HTML attribute normalization in
wiki-allowed HTML tags have ' incorrectly escaped in HTML output. This
is fixed in 1.5 and in REL1_4 from CVS (note there's currently a
breaking database change for some pages, which is why 1.4.6 has not been
released yet; this is unrelated to the parser changes).

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050610/b21c5b99/attachment.pgp>


subject: [Wikitech-l] Trophees du libre prizes

body:
> * an hosting offer "pack premium", description at
> http://nexenservices.com/product_info.php?set_lang=en&cPath=2&products_id=17
> .Once again, i guess you decide whether to accept it or not, what to
> do with it. I think the offer is for one year (but i can contact
> someone to make sure, or have more details)
> * 4 subscriptions to DirectionPHP (
> http://www.directionphp.biz/a_la_une.php ).

What's the current status of those two? Have they been accepted? And
what are they about exactly? (see my previous request about
translation).


from_name: Guaka

subject: [Wikipedia-l] The Borders of Language Variety Tolerance

body:
> On the other hand, I think it's worth noting that if promoting literacy
> and delivering encyclopedia content to the illiterate (worthy goals to
> be sure, but primary goals for other projects, or for the future after
> Jimbo's stated primary goal is already met) actually hinders the goal
> Jimbo has elucidated here, it's something that should probably be on the
> back burner.  The Wikipedia project can't be everything to everyone: we
> should ensure that it's successful at being something for someone,
> though, and that requires a certain narrowing of focus.

Delivering (encyclopedia) content to the illiterate should never be
Wikimedia's main goal. But there is money to be found to do this kind of
stuff. And why not get some of it and use it to set something up to
further these worthy goals :)

> The originally intended focus of it strikes me as a good choice.

Maybe the goal should be "one of people's mother tongues" instead of any
language they can read. This would exclude Zeelandic and other European
regional languages but would definitely include many African languages.


from_name: Lee Daniel Crocker

subject: [Wikitech-l] New syntax proposal

body:
On Fri, 2005-06-10 at 21:22 +0000, ?var Arnfj?r? Bjarmason wrote:

> * I don't like that your image syntax is like <<image foo.png>>
> instead of <<image:foo.png>>, this is inconsistant with the rest of
> the syntax.

Hmm, not sure what you mean--I did it that way precisely because
it's consistent with all the other extensions, and style tags.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


body:
James D. Forrester wrote:

>Ray Saintonge <saintonge at telus.net> wrote:
>
>
>>James D. Forrester wrote:
>>
>>
>>>[[Sollog]] believes himself to be the son of God
>>>
>>>
>[Snip]
>
>
>>If Sollog is the only source of evidence for his being God he has a
>>verifiability problem.  Under those circumstances being a part of a
>>minority is moot.
>>
>>
>The Christians are the only source of "evidence" that their words about a
>"the God" are true; similarly, the Jews, the Muslims, the Hindus, the
>Ancient Greeks, the Romans, the Celtic tribes of South-West Wales, etc. ad
>infinitum, or at least to the limit of human imagination of the
>supernatural, which is almost as vast. Don't be obtuse. :-)
>
>
Sounds like a good enough reason to eliminate all articles about God. :-)

Ec


subject: [Wikitech-l] New syntax proposal

body:
On Sat, 2005-06-11 at 00:49 +0200, Marco Krohn wrote:

> I like the proposal and in particular that internal / external links are
> handled more consistently - good work! Is it possible to use the pipe
> character "|" or external links as well, e.g.
>
> [[http://piclab.com|Piclab]]

Isn't it that way already?  Did I mistype something?

> > * I don't like that your image syntax is like <<image foo.png>>
> > instead of <<image:foo.png>>, this is inconsistant with the rest of
> > the syntax.

You guys will have to explain this to me--how is it inconsistent?
I don't use ":"s for any of the other extensions, just a keyword, a
space, and arguments.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Wikitech-l] New syntax proposal

body:
On Sat, 2005-06-11 at 00:54 +0100, Rowan Collins wrote:

> * I'm not 100% sure about external links using "|" as a separator (you
> don't have an example of this, but you imply it) - because they can be
> quite long and include all sorts of characters, it might not be clear
> at a glance where the URL ends and the text begins:

You're right, I don't have an explicit example, but it was my intent.
If you want to have URLs with "|" (pretty rare, I think), you'll have
to encode that character, just as we would with spaces now.

> * your omission of any keyword or character to reference built-in
> variables seems odd - <<servername>> looks like it should mean "invoke
> extension 'servername' with no input". I think <<global servername>>
> or <<$$servername>> would be more consistent with your other syntax.

Yes, each variable is like an extension of its own, and some of them
*will* have arguments, for example <<currentmonth tc gen>> when you
want the name of the current month, in titlecase and genitive.

> * come to that, why do template parameters ("<<$foo>>") get to be less
> verbose than everything else? Consistency would demand "<<param
> foo>>", whereas simplifying most common usage would probably lead to
> something like "<<+foo>>" instead of "<<include foo>>".

The $ things are for parameter expansions *inside* the template, not
for invocations of a template, so they're just like variables.  I think
"$" is just as evocative as "param", and easier to type, especially in
the three-way fallback syntax.  I wouldn't mind simplifying some of the
other ones like "include" or "raw" down to a special character,
especially in light of you're good point about internationalization.

>  I suspect
> you've been swayed by programming experience here - it's "obvious" to
> you that "$" means "variable", so why invent something new? But in
> doing so you've over-ridden what was clearly a design goal of not
> having lots of "magic characters"; for better or worse, that avoidance
> is the feature that comes out most strongly - verbosity in place of
> arcanity, I guess.

True, I am swayed by programming experience, but I'm not so concerned
with having many special characters, as long as they have some overall
sane structure to them--that's why "$$" is used for <tt>, for example;
it evokes the idea of "variable" there as well.  Simplicity is a goal,
but not number one; this is simpler than the existing syntax, but not
simpler than needed to achieve goal number one, ***ease of editing**.

> * I note that your image syntax sticks with the current kinds of
> argument (although a cryptic note implies that some of these will
> relate to styles in some way); it occurs to me that things like
> "frame" and "left", being neither named nor position-dependent, aren't
> consistent with everything else. Perhaps "align=left" and
> "style=frame"? [I guess what they imply is "frame=true" and
> "left=true", but this isn't how, say, "<<include foo left thumb>>"
> would interpret its arguments]

The details here are yet to be worked out. It is my intent that each
extension interpret its arguments its own way, so the arguments to
image will be only those meaningful to it, and not include *purely*
stylistic things, except maybe as shortcuts.  Again, I'm wiling to
sacrifice a little bit of simplicity and/or consistency for ease of use.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


from_name: Lars Aronsson

subject: [Wikipedia-l] Re: Enciclopedia Libre

body:
On June 5, Mark Williamson wrote:

> I was thinking of another non-English semifork of Wikipedia which has
> way more articles than the Wikipedia version, and whose owner is
> deeply involved in Wikipedia but while bragging in private e-mails and
> on-list about how much work he/she does compared to others to put more
> free content online, does not consider allowing the corresponding
> language version of Wikipedia to share content.
>
> *cough*

Now that you brought this up, why can't you spell the names out?
Innocent people might feel accused and hurt by half-sung songs
like this.

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


subject: [Wikitech-l] New syntax proposal

body:
Comments:

* I like the \\ for forcing a newline
* I think four hyphens, no more, no less, should translate to <hr/> (i
realise your proposal is not different from current syntax)

* I don't like that your image syntax is like <<image foo.png>>
instead of <<image:foo.png>>, this is inconsistant with the rest of
the syntax.
* I'd like ?? an ?? better than << and >>
* I like the syntax for **boldface text**, //italic text//,
$$typewriter text$$, ^^superscript^^, and __subscript__.


subject: [Wikitech-l] Transwiki

body:
On 6/10/05, Dominic McDevitt-Parks <dmcdevit at cox.net> wrote:
> Okay, this is my first post here, and I'm not really sure this is the best place to put my question. I'm hoping some of you know how to make bots. Here's my situation: a while back, Kevin Rector (who has since left Wikiedia) made me a bot to do assisted transwikis to Wiktionary. It's been a great help (Check out WP:TL) and whereas once there was a backlog of articles tagged for transwiki of >1000, now it is essentially zero as I clean out the category every day. So, I'd like a similar bot that can do transwikis to all the other sister projects. Wikibooks and Wikisource, in particluar, both have backlogs of over 100, some of which have been waiting around, even after VfD decisions, for months without transwiki. And some minor bugs in the current bot could do with some fixing. I'm hoping that someone can make this bot (I'll still run it). You can contact me on my WP talk page (I'm Dmcdevit). And thanks a lot.

Rather than hacking something togather to move the complete history of
a page you'd be better of helping finish bug 606
(http://bugzilla.wikimedia.org/show_bug.cgi?id=606)


from_name: Matt Wright

subject: [Wikitech-l] Automatic Unit Conversion (Patch for Bug 235)

body:
I am working on a patch for bug #235 (Auto unit conversion):
  http://bugzilla.wikipedia.org/show_bug.cgi?id=235

You can see it in action at:
  http://67.190.41.14:880/wiki/index.php/Main_Page
  (if it gets defaced,
http://67.190.41.14:880/wiki/index.php?title=Main_Page&oldid=54)

This will enable user preferences in displaying units of measurement as well
as provide an easier way for editors to insert units with conversions into
the articles.  For instance, you would be able to write:

A U.S. football field is (((100. yards))) in length. It would then display
in one of five different ways depending on the user preferences.

If you wanted to link that to the 1 E1 m, you would just do: ((([[100.
yards]])))

I currently have imperial to metric conversions for common lengths, volumes,
weights and speeds. Your input at the above demo would be greatly
appreciated if you are interested in this feature. Feel free to sign up for
an account and test out the preferences as well. There are plenty of
pre-made examples if you just want to see the potential. I am very new to
wikipedia, so I would appreciate any knowledgeable persons providing input
on the 'Issues to be Solved' section.

Other features:
  * can accommodate written out units such as (((three hundred metres)))
  * places commas into numbers only if editor does
  * automatically determines approximate significant figures

Thanks,

Matt Wright


subject: [Wikitech-l] Retrieving Articles for Mirror

body:
Eric Walker wrote:
> I have been fetching individual articles from the wikipedia site as
> visitors request them (once fetched, they are given some php-based
> processing, and the rest of the page built around them).  Apparently that
> is a no-no, owing, I am told, to the server load, especially from
> searchbots that may follow out the pages.
>
> I was, after some months of operation, suddenly hit with a 403 block; on
> inquiry, I discovered the facts above.  I then asked whether using instead
> the Special:Export XML access would be an acceptable way of fetching
> articles individually on demand.  The sysadmin wrote that he felt it would,
> but that I would be best to post here to see if others agree or disagree.

Hi Eric. Our resources are provided by donations from our users and
supporters to keep Wikipedia and our other projects available to human
readers and contributors.

Please remember that you're using someone else's servers, paid for with
someone else's money, to run your web site for you. As an uninvited
guest, you need to be mindful about how you use your host's resources.

Limit the number of connections you make and cache resources locally
once they've been retrieved. Understand and use HTTP caching headers
when available (such as the Last-Modified and Is-Modified-Since
headers). In particular remember that a rush of connections to your
site, such as a flash crowd (slashdot!) or a search engine spidering
loops of links, can cause your site to pass a *huge* number of requests
on to ours.

We make available public database dumps of the page databases for all
our wikis for the express purpose of making it easy for people to reuse
massive amounts of our content on their own sites as well as to perform
private research, republishing in other formats, etc. Updates are
somewhat intermittent while we're moving database servers around, but
occur roughly every couple of weeks. The last dump was made on May 16.

They're available at http://dumps.wikimedia.org/

I would strongly recommend that you make use of these database dumps if
possible, and avoid hitting our servers at all. If you _really_ need the
most up-to-date pages you can use the Special:Export interface to grab
source text, and render it within your own MediaWiki installation.

> I realize that there is no easy way to convert the marked-up text to HTML,
> but I am prepared to cobble up some php to essay the task--but, before
> going to that nontrivial effort,

Our code's all open source and you should feel free to use it for this
purpose: http://www.mediawiki.org/

> I would like to be sure that I will not
> again be blocked even if I am accessing individual articles via
> Special:Export XML.  (At present, I seem to be getting perhaps 20,000
> visitors a day.)

We cannot guarantee that you will never be blocked; if your site becomes
problematic it may very well be, but if the site is well-behaved it
probably will not be.

Most of all, remember that if you use a complete database dump you can
avoid any reliance on our site being up, down, unavailable, or blocking
you at any given time. This will make your site more resilient against
downtime, network troubles, and slow servers as well as the possibility
that you might get blocked.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050610/cb3b84d2/attachment.pgp>


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] Request for a link on your license plate page

body:
Dear Andy,

Assuming you contacted me with regard to the page on
http://en.wikipedia.org/wiki/License plate I'm afraid I'll have to
disappoint you. Wikipedia is an encyclopedia and as part of policy we
don't link to specific commercial sites to avoid bias. If we allow a
link to one company, others will feel left out and the links section
would turn into a sales list.

If my assumption on the reason of your contacting me is incorrect, I'd
like you to be more specific on the site you're talking about.

Sincerely,

MacGyverMagic, Wikipedia editor and administrator.

On 6/9/05, Andybnyork at aol.com <Andybnyork at aol.com> wrote:
> Hello! My name is Andy and am webmaster for THE PLATE HUT at
> _www.platehut.com_ (http://www.platehut.com) , I am interested in having a  link added to your
> license plate page. Would you be interested in this. I  apologize if I have
> contacted the wrong person here.
>
> Thank you very much,
>
> Andy Bernstein
> THE PLATE HUT
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
> But if our core purpose is to get information to people, isn't simply
> any language they can read well the proper criterion?

>From http://wikimediafoundation.org/wiki/Home: "Imagine a world in which
every single person is given free access to the sum of all human
knowledge. That's what we're doing."

If the core purpose is primarily to provide information to people who
can read then this should be accordingly changed on the website.
And, there is a huge amount of human knowledge hidden away in many
nearly-only-oral languages.

> (And what is a "mother tongue" anyway?  There are definitely people who
> claim some European regional language as their only "mother tongue", and
> say they only read/write/speak the "mainstream" language out of necessity.)

That's true, but I think they are wrong :) Though giving examples would
probably lead to a big flame war :)


body:
> There are a number of problems in the world somewhat related to our
> mission---illiterate people can't read a written encyclopedia in any
> language; people in countries with no internet access can't edit
> wikipedia; people in poverty don't have time to work on a wiki
> encyclopedia; people living under oppressive governments can't edit
> wikipedia freely; etc.
>
> I certainly don't think we should try to solve all those.  We can try to
> mitigate problems where it's not that hard to do so (e.g. by producing
> paper versions to distribute to non-internet-connected areas), but some
> of them---like solving the "digital divide" or world hunger, or
> overthrowing oppressive governments---are somewhat out of our areas of
> core competence.

Or by receiving money in order to do something about specific
problems. :)

I don't think we can or should try to solve any of those problems. But
we can help a little bit, at least with the stuff you mention in the
first paragraph. I don't see any reason to mention world hunger, digital
divide or similar general concepts in this discussion...


from_name: James D. Forrester

body:
[BTW, please don't strip attributions; it makes understanding who said what
('blame' ;-)) significantly harder.]

On Friday, June 10, 2005 11:46 PM, Ray Saintonge <saintonge at telus.net>
wrote:

> James D. Forrester wrote:
>
> > [[Sollog]] believes himself to be the son of God

[Snip]

> If Sollog is the only source of evidence for his being God he has a
> verifiability problem.  Under those circumstances being a part of a
> minority is moot.

The Christians are the only source of "evidence" that their words about a
"the God" are true; similarly, the Jews, the Muslims, the Hindus, the
Ancient Greeks, the Romans, the Celtic tribes of South-West Wales, etc. ad
infinitum, or at least to the limit of human imagination of the
supernatural, which is almost as vast. Don't be obtuse. :-)

Yours,
--
James D. Forrester -- Wikimedia: [[W:en:User:Jdforrester|James F.]]

Mail: james at jdforrester.org | jon at eh.org | csvla at dcs.warwick.ac.uk
IM  : (MSN) jamesdforrester at hotmail.com


list: foundation-l

from_name: Delphine Ménard

subject:
[Foundation-l] RV ESA - ESA Termin - Meeting with the ESA (European
	Space Agency)

body:
Deutsch folgt. English follows
----------------------------------------

Un peu de douceur dans ce monde de brutes.

Suite ? l'action probante de Arnomane, contributeur allemand, aupr?s
de l'ESA ? plusieurs reprises, concernant l'utilisation de leurs
contenus, notamment des photos, Wikimedia France a obtenu un
rendez-vous afin de pr?senter les projets Wikimedia aupr?s de la
Division de la Communication (Production iconographique et multim?dia)
de l'ESA ? Paris, le 27 juin.

Le but de ce rendez-vous est d'effectuer une premi?re prise de contact
informelle, de pr?senter les projets Wikim?dia et d'envisager les
bases d'une collaboration future.

--------------

Nachdem Arnomane mit der ESA viel und endlich erfolgreich gesprochen
hat, wegen der Ben?tzung ihre Inhalte, n?mlich Bilder, Wikimedia
France hat ein Termin mit der Division de la Communication (Production
iconographique et multim?dia) der ESA in Paris am 27. Juni fest
gestellt.

Das Ziel dieses Termins ist erst nur informellen Kontakt mit der ESA
machen, die Wikimedia Projekte pr?sentieren, und eine m?gliche
k?nftige Kollaboration zu bauen.

(Vergib mir f?rs schlechte Deutsch ;-) )

--------------

Thanks to Arnomane's (German contributor) long and finally fruitful
efforts to get in touch with the ESA concerning the use of their
contents, especially images, Wikimedia France has  a meeting planned
with the Division of Communication (Iconographic and multimedia
production) of the ESA in Paris, on June 27th.

The goal of this meeting is first to make informal contact with the
ESA, present the Wikimedia projects and layout the basis of a possible
future collaboration.

A+/Gr?sse/Cheers,

Delphine

--
~notafish


list: wikimedia-l


from_name: Marco Krohn

subject: [Wikitech-l] New syntax proposal

body:
On Friday 10 June 2005 23:22, ?var Arnfj?r? Bjarmason wrote:

I like the proposal and in particular that internal / external links are
handled more consistently - good work! Is it possible to use the pipe
character "|" or external links as well, e.g.

[[http://piclab.com|Piclab]]

?

The idea about "links with a pipe character with no text" is good and saves
quite a lot of typing.

> * I don't like that your image syntax is like <<image foo.png>>
> instead of <<image:foo.png>>, this is inconsistant with the rest of
> the syntax.

I agree.

> * I'd like ?? an ?? better than << and >>

? is hard to type as my (german) keyboard has no easy way of accessing these
characters.

I don't like that comments can be put in the tags.

best regards,
  Marco


subject: [Wikitech-l] New syntax proposal

body:
On 10/06/05, Lee Daniel Crocker <lee at piclab.com> wrote:
> I decided to release my new syntax for comment before I
> finished the formal definition.

This started off as a few quick comments, but grew as I thought; I
hope it proves constructive...

* In general, I like these suggestions more than I thought I would,
particularly the "generic inclusion syntax"; although whether it would
appeal in the same way to non-technical users I'm not sure. One major
problem I see with such a text-heavy syntax is localisation - French
users *will* be put off if they have to type "begin include".
Obviously, we have this already to some extent, but this syntax feels
much more verbose - "{{}}" doesn't need translations. In order to
allow multiple languages to exist on one site, it would probably
become essential to be able to map the entire wikitext of an article
into a different syntax-dialect (e.g. "<<begin ...>>" -> "<<commence
...>>") on demand.

* I'm not 100% sure about external links using "|" as a separator (you
don't have an example of this, but you imply it) - because they can be
quite long and include all sorts of characters, it might not be clear
at a glance where the URL ends and the text begins:
[[http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030155.html|wikitech-l
post about Lee's syntax]] vs
[http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030155.html
wikitech-l post about Lee's syntax]
(Obviously, with a page link, the opposite problem arises - because
the page name can include " ", you can't say [[a page and its target]]
and know how to split it.) I'm not saying I'm desperately married to
the current syntaxes, but I do think there's a certain logic to having
URLs terminated with a space.

* your omission of any keyword or character to reference built-in
variables seems odd - <<servername>> looks like it should mean "invoke
extension 'servername' with no input". I think <<global servername>>
or <<$$servername>> would be more consistent with your other syntax.

* come to that, why do template parameters ("<<$foo>>") get to be less
verbose than everything else? Consistency would demand "<<param
foo>>", whereas simplifying most common usage would probably lead to
something like "<<+foo>>" instead of "<<include foo>>". I suspect
you've been swayed by programming experience here - it's "obvious" to
you that "$" means "variable", so why invent something new? But in
doing so you've over-ridden what was clearly a design goal of not
having lots of "magic characters"; for better or worse, that avoidance
is the feature that comes out most strongly - verbosity in place of
arcanity, I guess.

* I also like your elimination of all HTML and HTML-like elements - as
you say, this will avoid confusion about people adding things in ad
hoc, although incorporating references to CSS may bring on a whole new
plague

* I note that your image syntax sticks with the current kinds of
argument (although a cryptic note implies that some of these will
relate to styles in some way); it occurs to me that things like
"frame" and "left", being neither named nor position-dependent, aren't
consistent with everything else. Perhaps "align=left" and
"style=frame"? [I guess what they imply is "frame=true" and
"left=true", but this isn't how, say, "<<include foo left thumb>>"
would interpret its arguments]

Right, I'll stop there, and probably find that other people have made
the same points more eloquently already. Ah well...

--
Rowan Collins BSc
[IMSoP]


from_name: Angela

subject: [WikiEN-l] wikimania acceptance rate?

body:
On 10/06/05, Andrea Forte <andrea.forte at gmail.com> wrote:
> Hi! I hear the acceptance letters are going out for Wikimania
> submissions. Anyone know what the acceptance rate ended up at?

We have accepted:
4 Keynotes and special invitations
35 presentations.
7 short presentations
2 after hours presentations

There are 6 open and late submissions still under discussion.
There are at least 3 accepted Poster/Paper only submissions.

There are 19 rejected submissions. In a few cases, people sent more
than one abstract, and generally only one was accepted, so the number
of rejected submissions reflects this.

More information about the conference can be found at
http://wikimania.wikimedia.org/

Angela.


subject: [Wikitech-l] New syntax proposal

body:
On 10/06/05, Marco Krohn <marco.krohn at gmx.de> wrote:
> The idea about "links with a pipe character with no text" is good and saves
> quite a lot of typing.

Note that this is already in MediaWiki's syntax, as an odd piece of
voodoo replaced at save-time. Presumably in the proposed syntax it
would be valid in the saved source and thus more visible to new users.
[The other big example we have of such voodoo is the "~~~~"
signatures; but I guess they'll always be an invisible software
feature]

> > * I don't like that your image syntax is like <<image foo.png>>
> > instead of <<image:foo.png>>, this is inconsistant with the rest of
> > the syntax.

I don't think it is - if you look, the suggested syntax consists of
"<<", the type of inclusion, a space, zero or more arguments, and
">>". In this case, the type of inclusion is "image" and the first
argument is "name of the image". In current MediaWiki syntax, it's not
clear whether "Image:" is part of the syntax (a "link type") or just
part of the first argument to the generic internal link syntax (the
namespace forming part of the target's title); in Lee's syntax, it's
very clear which is which.

> > * I'd like ?? an ?? better than << and >>
>
> ? is hard to type as my (german) keyboard has no easy way of accessing these
> characters.

Strongly agree; I don't know how much research Lee's done into which
characters are easily accessible on the most keyboard layouts (he
comments somewhere that he didn't use { and } for precisely that
reason), but I doubt ? and ? would fall into that category, as most
languages have no use for such characters. (AFAIK - anyway, neither
British nor US English have such characters at all, so that's an awful
lot of users you'd be annoying)

--
Rowan Collins BSc
[IMSoP]


from_name: Robert Jones

subject: [Wikitech-l] Parser question

body:
I am trying to set up an RSS parser on a private wiki that uses the
following for onsubmit:

onsubmit="if(window.myInterval){window.clearInterval(window.myInterval);}if(
importXML('rssLocal.php?feedURL='+escape(this.feedURL.value),'parseRSS',fals
e,2000)){if(parseFloat(this.interv.value)){window.myInterval=window.setInter
val('importXML(\'rssLocal.php?feedURL='+escape(this.feedURL.value)+'\',\'par
seRSS\',false,2000);',parseFloat(this.interv.value)*60000);}}else{alert('You
r browser cannot import XML, so it cannot view RSS feeds using this
script');}return false;"

The problem is that when I submit the page, every ' is replaced by a \'
giving:

onsubmit="if(window.myInterval){window.clearInterval(window.myInterval);}if(
importXML(\'rssLocal.php?feedURL=\'+escape(this.feedURL.value),\'parseRSS\',
false,2000)){if(parseFloat(this.interv.value)){window.myInterval=window.setI
nterval(\'importXML(\\'rssLocal.php?feedURL=\'+escape(this.feedURL.value)+\'
\\',\\'parseRSS\\',false,2000);\',parseFloat(this.interv.value)*60000);}}els
e{alert(\'Your browser cannot import XML, so it cannot view RSS feeds using
this script\');}return false;"

Is there a way to stop this from happening? Or does is break something else
if this is stopped?

I have tried calling the code in a non-wiki .js page, but this doesn't work
and I would like the code to be in the wiki so it can be edited.

Hope you can help, many thanks.


subject: [Wikipedia-l] Re: Enciclopedia Libre

body:
Mark Williamson wrote:

> If they're so innocent, why would they be hurt by "half-sung songs"?

Come on, Mark.  Part of your description matches myself and my
website susning.nu, a big non-English wiki.  Some readers might
believe that you are pointing at me, and conclude that the other
information is some kind of truth about me.  That hurts me.  If
you really believe what you wrote, then I'm here to clarify any
misunderstandings and answer your questions.  If you mean someone
else, you will save me a lot of trouble by saying so.

Perhaps you mean Erik M?ller and his infoAnarchy?  Perhaps you
mean Jimbo Wales and his Wikicities?

I'll assume the worst, and clarify your points as if they were
relating to me.  As far as I know, you don't speak Swedish and are
not a contributor to the Swedish Wikipedia, and so it disturbs me
to learn that you might have such strong and possibly damaging
opinions about me.  Who gave you these impressions?  Should you be
more careful with trusting your sources?

> > > I was thinking of another non-English semifork of Wikipedia

Susning.nu has never been a fork (or "semifork", whatever that is)
of Wikipedia.  It is a big Swedish wiki that I started from
scratch after Larry Sanger made it clear that what I wanted to do
would fall outside of Wikipedia's strictly encyclopedic scope. Not
a single text has been copied or translated from Wikipedia to
Susning.nu.  If that happened, it would be a copyright violation
(unless the author dual licensed the text), since susning.nu does
not enforce the GFDL license like Wikipedia does.  In many cases,
susning.nu contributors have later copied their own texts to the
Swedish Wikipedia, which of course is perfectly OK.

> > > which has way more articles than the Wikipedia version, and

This could be said a year ago, but today Susning.nu has 58,400
articles, while the Swedish Wikipedia has 80,600.

> > > whose owner is deeply involved in Wikipedia but while

I'm not "deeply involved" in Wikipedia.  I'm an occasional
contributor (user:LA2), but I've never been and have never aspired
to be an administrator, bureaucrat, board member or developer of
Wikipedia.  On the contrary, I've been extremely careful to point
out the difference between the two projects, and kept myself at
arm's length distance from anything Wikipedia.  I've never
participated in any vote or opinion poll on how to run the
project.

> > > bragging in private e-mails and on-list about how much work
> > > he/she does compared to others to put more free content
> > > online,

Back in 1992, I started Project Runeberg (runeberg.org), the
Scandinavian e-text project, which possibly was the first "clone"
of Project Gutenberg. In the more than 12 years since, quite a lot
of out-of-copyright literature has been digitized there, including
several old encyclopedias. Much of this has benefited the Swedish,
Danish, and Finnish Wikipedia.  No description of who I am would
be complete without mentioning this.  I've spent more hours on
Project Runeberg than on any job or hobby I've ever had.

> > > does not consider allowing the corresponding language
> > > version of Wikipedia to share content.

I'm contributing *some* of my texts and photos to Wikipedia, but
that's not to say that everything I write or do is released for
free.  Especially, the texts that I wrote for susning.nu are under
my copyright without open licensing.  What others do with their
texts on susning.nu is their decision, and the site does not force
contributors to use any particular license.  In practice, this
makes mirroring of the entire site impossible, and that is a
deliberate choice; I don't believe in website mirroring.  I've
also written texts and software for other purposes and customers.
These texts belong to me or my customers and the copyright holders
decide what or how to license them.

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


subject: [Wikitech-l] Parser question

body:
I'm submitting it on a wiki page, and the replaced text is showing on the
resulting page (rendered text after I submit, not in a preview).

I've modified the wiki to allow form and onsubmit, and I can see from the
output that this modification has been successful. I have written an
extensions but the text is not within any of the tags used for that
extension. I'm using MediaWiki 1.3.9 (I intend to upgrade once it becomes
possible to import pages as XML) I am using php 4.3.10, magic_quotes_runtime
is off (I haven't made any changes to the server configuration).

Thank you for responding to my question, I like mediawiki a lot, and have
found it very useful.

> Where are you submitting it, exactly? In a wiki page or something else?
> A regular wiki page? A user javascript page? MediaWiki:Monobook.js?
>
> Where is the replaced text, exactly? In the source text stored in the
> database? In the edit box editing the page again? In the rendered text?
> In the output reading the .js?
>
> Have you modified the wiki? In wiki-allowed HTML, onsubmit is barred
> (not to mention <form>) and should not be showing up in output to
> begin with. If you have changed it, exactly what have you changed? Or
> are you working in an <html> section, or perhaps a custom extension
> that outputs HTML?
>
> What MediaWiki version are you using? What PHP version? Have you made
> any non-standard PHP configuration options such as
> magic_quotes_runtime (this will fatally break things if on)?
>
> There is a bug up through 1.4.5 where HTML attribute normalization in
> wiki-allowed HTML tags have ' incorrectly escaped in HTML output. This
> is fixed in 1.5 and in REL1_4 from CVS (note there's currently a
> breaking database change for some pages, which is why 1.4.6 has not
> been released yet; this is unrelated to the parser changes).


subject: [Wikitech-l] bugzilla votes

body:
Anthere wrote:
> Why did you remove quantity voting system in Bugzilla ? It did not work ?

We last upgraded Bugzilla a month or two ago. Did it change then, or
more recently?

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050611/4adfc3cc/attachment.pgp>


from_name: Austin Hair

subject: [Wikitech-l] New syntax proposal

body:
This is more in line with what I'd personally come up with than the
existing syntax, but it's very different from what the hundreds of
current MediaWiki users expect.  I personally dislike "\\" for line
breaks, as I'd expect a literal \ or \\ instead, but that's a
relatively minor point overall.

I'm naturally opposed to any non-ASCII markup, for obvious reasons,
but from an idealistic perspective this isn't a bad start.

-- Austin


from_name: Eric Walker

body:
The sysadmin with whom I have been corresponding recommended that I post my
situation and query here.  I should say that while I am not quite illiterate
technically, neither am I an expert.

I established, quite some months ago, a web site that has been operating as
a combination of Wikipedia articles and the corresponding dmoz links lists.
I have been punctilious in observing the terms of use of both
organizations.  I have, however, now--after all these months--discovered
that I am apparently not using the resource itself in a preferred manner.

I have been fetching individual articles from the wikipedia site as
visitors request them (once fetched, they are given some php-based
processing, and the rest of the page built around them).  Apparently that
is a no-no, owing, I am told, to the server load, especially from
searchbots that may follow out the pages.

I was, after some months of operation, suddenly hit with a 403 block; on
inquiry, I discovered the facts above.  I then asked whether using instead
the Special:Export XML access would be an acceptable way of fetching
articles individually on demand.  The sysadmin wrote that he felt it would,
but that I would be best to post here to see if others agree or disagree.

I realize that there is no easy way to convert the marked-up text to HTML,
but I am prepared to cobble up some php to essay the task--but, before
going to that nontrivial effort, I would like to be sure that I will not
again be blocked even if I am accessing individual articles via
Special:Export XML.  (At present, I seem to be getting perhaps 20,000
visitors a day.)

This site is very important to me, and I need to act extremely quickly if
it is not all to just go down the drain, so please help me out here.


from_name: Pawe³ 'Ausir' Dembowski

subject: [Wikipedia-l] Interwiki articles without en: (another one forMark)

body:
There are many Polish articles linked to German equivalents and
vice-versa.

--
Ausir
Wikipedia, wolna encyklopedia
http://pl.wikipedia.org


from_name: Vincent "Bentong" S. Isles

subject: [Wikipedia-l] Request for a Wikipedia in Cebuano

body:
In behalf of the 26 million speakers of Cebuano (60%
of which have access to online resources by
conservative estimates), I would like to request for a
Wikipedia in the Cebuano language.

We already have the minimum number of interested
persons who will work on the encyclopedia.

<http://meta.wikimedia.org/wiki/Requests_for_new_languages#Cebuano>

Thank you for your time.

bentong

Send instant messages to your online friends http://uk.messenger.yahoo.com


subject: [Wikitech-l] New syntax proposal

body:
On Sat, 2005-06-11 at 10:59 +0200, Marco Krohn wrote:

> What are chances that we change the current mediawiki syntax to yours? ;-)

Certainly not anytime soon.  This is just the first step; now I
formalize it into something like a real spec, then write some
proof-of-concept code, then write and test conversion code, etc.

...and now I've got this unit conversion thing to think about...:)

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Wikitech-l] Re: Retrieving Articles for Mirror

body:
Brion Vibber <brion <at> pobox.com> writes:

> Hi Eric. Our resources are provided by donations from our users and
> supporters to keep Wikipedia and our other projects available to human
> readers and contributors.

Just so; I have made some myself.  I send a set percentage of any net
AdSense money I make to Wikipedia; and every article page of my site has
an explicit link to Wikipedia's fund-raising page.

> Please remember that you're using someone else's servers, paid for with
> someone else's money, to run your web site for you. As an uninvited
> guest, you need to be mindful about how you use your host's resources.

Again, just so.

> Limit the number of connections you make and cache resources locally
> once they've been retrieved. Understand and use HTTP caching headers
> when available (such as the Last-Modified and Is-Modified-Since
> headers). In particular remember that a rush of connections to your
> site, such as a flash crowd (slashdot!) or a search engine spidering
> loops of links, can cause your site to pass a *huge* number of requests
> on to ours.

Dear me, if I ever had a flash crowd, I think I'd faint dead away.  But
search engines are, I think, the very nut of the matter.  Philosophically,
my visitors are, in effect, simply visitors to Wikipedia, albeit by proxy,
and the load they represent is effectively just that of visitors to Wikipedia
itself; but the extra from the searchbots is the problem.  (Mind, I'd be
pleased as punch if the SEs would actually visit enough of my pages for it
to matter.)

> We make available public database dumps of the page databases for all
> our wikis for the express purpose of making it easy for people to reuse
> massive amounts of our content on their own sites as well as to perform
> private research, republishing in other formats, etc. Updates are
> somewhat intermittent while we're moving database servers around, but
> occur roughly every couple of weeks. The last dump was made on May 16.
>
> They're available at http://dumps.wikimedia.org/

Yes, so I have discovered.  But I wonder about the trade-off between my
taking files, especially if I can manage to use the XML feeds effectively,
"on demand" versus my taking many gigabytes of data every two to four
weeks--which would average to something like a gigabyte a day.  Which--in
any sense of the word--"costs" more?

> I would strongly recommend that you make use of these database dumps if
> possible, and avoid hitting our servers at all. If you _really_ need the
> most up-to-date pages you can use the Special:Export interface to grab
> source text, and render it within your own MediaWiki installation.

Yes, that is what I would do--indeed, would have done long ago if I had
available a simple, reliable markup-to-html translator.  But if needs be,
I am willing to work at handling the translation (based in good part on
my very recent discovery of some extant translation work).

> > I realize that there is no easy way to convert the marked-up text to HTML,
> > but I am prepared to cobble up some php to essay the task--but, before
> > going to that nontrivial effort,
>
> Our code's all open source and you should feel free to use it for this
> purpose: http://www.mediawiki.org/

True, save that the markup language seems to be not clearly set and defined
anywhere, though perhaps I simply have not yet found what I have been
looking for.  But Magnus Manske's wiki2xml.php script looks like an
excellent running start on the problem, at least for a site on my scale.

> > I would like to be sure that I will not
> > again be blocked even if I am accessing individual articles via
> > Special:Export XML.  (At present, I seem to be getting perhaps 20,000
> > visitors a day.)
>
> We cannot guarantee that you will never be blocked; if your site becomes
> problematic it may very well be, but if the site is well-behaved it
> probably will not be.

"Well-behaved" is, I fear, in the eye of the beholder.  I dearly want to be
well-behaved, and a good citizen in all ways, but I am still not sure I know
what the considerations are.  Was I 403'ed because the actual volume of
transactions was too high, or simply because I was using "remote loading"?
I also am unclear as to whether there is a difference between bandwidth used
downloading a dump and bandwidth used taking files (HTML or the XML available)
"on demand"--different servers, or all just "bandwidth"?).

> Most of all, remember that if you use a complete database dump you can
> avoid any reliance on our site being up, down, unavailable, or blocking
> you at any given time. This will make your site more resilient against
> downtime, network troubles, and slow servers as well as the possibility
> that you might get blocked.

Yet again, just so, but . . . .  I am already paying what is, for me as an
individual, anyway, a dearly high monthly for a "high-volume" account, yet
I get but 5 GB of storage, scarcely a fraction of even just the English-
language database.

I wonder that there is not in place some system for dealing with situations
like mine, which I can hardly think unique.  I would be more than happy to
pay some plausible fee for accesses, either to XML or to HTML, rather than
try to re-invent the wheel.  To install the entire Wikimedia package is, to
put it mildly, daunting to a solo nonexpert, yet almost all of it would
really be useless to me: all I want is to be able to get at the current
content of the actual articles.

I realize that Wikipedia is "open source", which is usually held to be equal
to "free", but is there no place for mixing "free to public visitors" and a
modest fee for serving, shall we say, on the wholesale rather than the
retail side?

Meanwhile, my question for the instant moment is: if the block is taken off,
and I take the XML Export files on an on-demand basis, will I be OK?  (I am
even now at work on a converter, using the aforesaid wiki2xml.php script;
there goes my weekend, and I have already gotten an earful about the weeds
that need mowing).


from_name: Tomer Chachamu

body:
On 11/06/05, Matt Wright <mw at mattwright.com> wrote:
> A U.S. football field is (((100. yards))) in length. It would then display
> in one of five different ways depending on the user preferences.
>
> If you wanted to link that to the 1 E1 m, you would just do: ((([[100.
> yards]])))
>   * automatically determines approximate significant figures

Surely only two brackets are sufficient?

I really like that you check significant figures. I'll go look at it now.


subject: [Wikitech-l] New syntax proposal

body:
On Saturday 11 June 2005 05:10, Lee Daniel Crocker wrote:
> On Sat, 2005-06-11 at 00:49 +0200, Marco Krohn wrote:
> > I like the proposal and in particular that internal / external links are
> > handled more consistently - good work! Is it possible to use the pipe
> > character "|" or external links as well, e.g.
> >
> > [[http://piclab.com|Piclab]]
>
> Isn't it that way already?  Did I mistype something?

I was asking because the fourth part of the "Links" section ("The text of the
link can be different from the target title...") gives no example for http.

> > > * I don't like that your image syntax is like <<image foo.png>>
> > > instead of <<image:foo.png>>, this is inconsistant with the rest of
> > > the syntax.
>
> You guys will have to explain this to me--how is it inconsistent?
> I don't use ":"s for any of the other extensions, just a keyword, a
> space, and arguments.

sorry, my fault of course Rowans argument is right.

What are chances that we change the current mediawiki syntax to yours? ;-)

best regards,
  Marco


from_name: Anthere

subject: [Wikitech-l] bugzilla votes

body:
Why did you remove quantity voting system in Bugzilla ? It did not work ?

ant


subject: [Wikipedia-l] Re: The Borders of Language Variety Tolerance

body:
Mark Williamson a ?crit:
> It's not "their own language".
>
> I can read, write, and speak Japanese to a sufficient degree that I
> can read articles in Japanese, but it's not "my language".
>
> For example, do you think Anthere considers English to be her
> language? Definitely not.

No. It is other people language. I have the chance to be able to
communicate with this people thanks to it. I have the chance to
understand most of it. But not all (I certainly could not read easily
philosophy in english) and not everyone (I hardly understand Angela for
example).

I can handle a lot with it. But it is not "my language".


body:
> On 11/06/05, Tomer Chachamu <the.r3m0t at gmail.com> wrote:
>
> > If you wanted to link that to the 1 E1 m, you would just
> > do: ((([[100. yards]])))
>
> Surely only two brackets are sufficient?

Are you suggesting something like [[100 yards]] to link and provide
automatic unit conversion?  I avoided this because of potential conflicts.
For instance:

[[one foot]] contains twelve inches.
[[one foot]] is the name of a snowboarding trick, according to Wikipedia.

That is why I suggest placing the [[ ]] inside of whatever syntax provides
automatic unit conversion if the user wants the automatic link to the 1 E* m
series of pages. Then, if they want the unit linked elsewhere, they can do
[[link|(((3 ft)))]].

If instead you were suggesting only two parentheses instead of three, that
is fine with me. As I state on the page, the entire syntax is up for debate.
I saw the three parentheses suggested somewhere when I started work, so that
is what I went with.  Clearly the fewer characters typed, the better. I
haven't been around Wikipedia long enough to know what I might be
conflicting with by choosing something shorter.

Matt Wright


body:
On 11/06/05 ?var Arnfj?r? Bjarmason <avarab at gmail.com> wrote:

> Please make it an extension and not part of the core syntax.

Can you explain this a little further?  The way it is currently written is
similar to date formatting.

* Like DateFormatter.php, a UnitFormatter.php file now exists
* Modifications in includes/User.php and includes/SpecialPreferences.php for
preferences
* Added lines simiar to DateFormatter in includes/Parser.php
* Several new global arrays and functions were added to Language.php for
cross-language operation
   $wgUnitSettingsEn = array();
   $wgUnitNamesEn = array('1in' => 'inch', 'in' => 'inches', ...);
   $wgUnitAbbreviationsEn = array('in' => 'in', ...);
   $wgNumericPowerWords = array(..., '6' => 'million', ...);
   $wgNumericValueWords = array('0' => 'zero', '1' => 'one', ...);

   getUnitName ( $unitcode ) {}
   getUnitAbbreviation ( $unitcode ) {}
   getWordsFromNumber( $number ) {}
   getNumberFromWords ( $words ) {}

Can this type of integration be done with an extension? If so, where would
you suggest I read up on how to make it an extension instead of core syntax?
This patch may be more useful for Wikipedia spceifically, rather than
WikiMedia in general.

Matt Wright


from_name: Ævar Arnfjörð Bjarmason

subject: [Wikitech-l] bugzilla votes

body:
Tim reconfigured it to have one vote per bug and a very large pool of
votes ( given our # of bugs ) per user, each user now has one vote per
bug.

I like it.


subject: [Wikitech-l] New syntax proposal

body:
> 1) Why  not keep {{}} for inclusion to be consistent and use <<>> for style?

I could go either way; the thing that tipped the scale for me was that
using curlies for this will make the "math" extension difficult to use.

> 4) I don't like keeping magic links (e.g. ISBN), just because they
> show up out of nowhere (i.e. magically). Why not [[ISBN:1234...]]?

I'm not real fond of them either, but you might have a user mutiny
on that one.

> 5) I don't like superflous named arguments for links all that much as
> it's increasing the complexity (more than one way to do things, it
> will confuse people, more stuff to translate, rememer, etc)

I just wanted the argument syntax to be the same for extensions,
links, and such.

> 7) Don't like multi line inclusions, but if you have to do it, I would use this:
>
> <<begin applet
>  applet=conway_life.class
>  size=400x300
>  pattern=none
> >>

That's a little harder to parse, and doesn't seem any simpler to me
(although it's a bit easier to type).

> 8) In the raw example, where does <<raw end, because math is getting
> interpreted?

Like all extensions, it ends at >>.

> 9) I *really* don't like styles using, and especially using {{}} for
> them. I know many people, including myself, who are used to the
> current syntax will bug out at that. Why give one more choice, instead
> of using the the other markup? If people want to use markup, fine, let
> them use full HTML (for MediaWiki, I'd be OK with not enabling HTML
> for Wikimedia). I don't want to open up an artile for editing and have
> to figure out what {{u}}, {{i}}, etc do, especially when they're
> nested. One set of markup should be enough, for anything else use
> HTML.

Styles aren't just about a new way to do boldface and such (it just
happens to do that as well--can't be avoided). It's about finally
getting rid of all HTML markup, and making it possible for users to
edit the text of an article without having to muck with all the
style data that power users have put in; it also enables shared
styles for multiple pages.

The big example is something like the taxonomy table on the right
side of species articles.  It's nothing but template inclusions,
and those templates are mostly markup.  Even I would have a hard
time adding a line of text somewhere in that box if I thought it
was needed.

With the new syntax, the table could be in a template or in the
text itself, with a style tag pointing to a sheet that does most
of the cosmetic stuff--and which is shared by all similar articles,
but the wikitext itself would be mostly content easier to edit.

The separation of content and style is a BIG win-win, and has to
happen in one form or another.  I've settled on using CSS as is
because typically the folks who want fancy styles are the power
users who are used to CSS anyway.

> 10) Again, for the styles I don't like one set to begin the markup and
> one to end it. I know it makes the syntax easier probably, but having
> to hunt down to which style an end tag belongs would be a pain in long
> articles.

They must be nested properly, but you can always use {{end bigtable}}
if you need to clarify, because comments are accepted there.
Most of them don't need to be terminated explicity anyway--that was
an ease-of-use thing I really wanted.

> 11) I really like the ////. ****, $$$$, ____, ^^^^, but I don't like
> terminating them by spaces, require begin and end for consistency.

It's only superscript and subscript I do that way, and I could be
convinced to eliminate that shortcut.

> 12) Not sure how I feel about the character entities not being
> interpreted. I always hate seeing them as it makes editing more
> difficult, but I don't know if they are needed in some cases. I
> personally almost never use them. Some people may have trouble finding
> the character to copy and paste when the keyboard doesn't support it.

What I mean is that they aren't used for markup--they are just passed
on as plain text, so that, for example, << does not cause the
parser to start an extension, it just puts two less-than signs into
the text.

Thanks for the feedback!

--
Lee Daniel Crocker <lee at piclab.com>
<http://creativecommons.org/licenses/publicdomain/>


from_name: Dori

subject: [Wikitech-l] New syntax proposal

body:
Some questons/comments/concerns:

1) Why  not keep {{}} for inclusion to be consistent and use <<>> for style?

2) I'd keep HRs to exactly ---- (4)

3) I like getting rid of he single bracket or external links, doule
brackets are good enough for this.

4) I don't like keeping magic links (e.g. ISBN), just because they
show up out of nowhere (i.e. magically). Why not [[ISBN:1234...]]?

5) I don't like superflous named arguments for links all that much as
it's increasing the complexity (more than one way to do things, it
will confuse people, more stuff to translate, rememer, etc)

6) I don't like the type for inclusion being separated by space, but
that's not all that big a deal (I would like the : to be used for
inclusion as well <<image:blah.jpg>>)

7) Don't like multi line inclusions, but if you have to do it, I would use this:

<<begin applet
 applet=conway_life.class
 size=400x300
 pattern=none
>>

meaning no comments, and only one set of opening and closing signs.

8) In the raw example, where does <<raw end, because math is getting
interpreted?

9) I *really* don't like styles using, and especially using {{}} for
them. I know many people, including myself, who are used to the
current syntax will bug out at that. Why give one more choice, instead
of using the the other markup? If people want to use markup, fine, let
them use full HTML (for MediaWiki, I'd be OK with not enabling HTML
for Wikimedia). I don't want to open up an artile for editing and have
to figure out what {{u}}, {{i}}, etc do, especially when they're
nested. One set of markup should be enough, for anything else use
HTML.

10) Again, for the styles I don't like one set to begin the markup and
one to end it. I know it makes the syntax easier probably, but having
to hunt down to which style an end tag belongs would be a pain in long
articles.

11) I really like the ////. ****, $$$$, ____, ^^^^, but I don't like
terminating them by spaces, require begin and end for consistency.

12) Not sure how I feel about the character entities not being
interpreted. I always hate seeing them as it makes editing more
difficult, but I don't know if they are needed in some cases. I
personally almost never use them. Some people may have trouble finding
the character to copy and paste when the keyboard doesn't support it.

Thanks for taking a big step towards cleaning up the syntax!


from_name: Ray Saintonge

subject: [Wikitech-l] New syntax proposal

body:
?var Arnfj?r? Bjarmason wrote:

>* Regarding your style of headings: It's currently possible to make
>the html equivalent of <h[1-6]> with wikisyntax, but you specifically
>disallow level one (=) headings which is insufficient, remember that
>not everything is an article where you get the first heading generated
>for you, special pages and other extensions might want to make their
>own first heading (other than the one made with use of the title
>object) using wikisyntax and there will be no way for them to do that
>save for falling back to spitting out HTML, furthermore level one
>headings are in wide use on pages like the English Wikipedia's Village
>pump, why do you want to deprecate it? Presumably it clashes with
>something else I haven't noticed.
>
>
I noticed that one.  The wider range of headings is helpful for nesting
concepts in Wiktionary.

There too the H1 headings have practical application.  In the Requests
for deletion adding a new item automatically adds a level 2 heading.
Being able to group these by month with a level 1 heading is a big help
in the management of the page.

Ec


subject: [Wikitech-l] Re: bugzilla votes

references:
<42AAAFC0.4010601@yahoo.com>
	<51dd1af8050611071232cc5374@mail.gmail.com>
	<d8esel$psb$1@sea.gmane.org>

body:
On 6/11/05, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> ?var Arnfj?r? Bjarmason wrote:
> > Tim reconfigured it to have one vote per bug and a very large pool of
> > votes ( given our # of bugs ) per user, each user now has one vote per
> > bug.
> >
> > I like it.
>
> Now you can actually tell which bugs are more wanted than other bugs.
> Some people were voting 1, some 100, some 400, some 700. When you add
> them all together you get a number which has not much relation to
> anything. There were 3 developers present on IRC, all were in favour.
> Bugzilla sent an email to everyone who had voted telling them that their
> votes had been declared invalid, bless it.

I like this as well. It makes it a lot easier to figure out at a
glance how many people want a certain feature/bug.


subject: [Wikitech-l] New syntax proposal

body:
On 6/11/05, Dori <slowpoke at gmail.com> wrote:
> Some questons/comments/concerns:

Addendum, I forgot about MetaData, which is the best part about the changes.

13) I *really* like separating out the meta data from the article.
This would include things like stub messages, styles for the whole
article, categories, various tags being added to articles (e.g.
{{cleanup}} which seriously infuriate me as it does the opposite of
cleaning up the article). I don't think considering redirects as meta
data would be a good idea though. I like that the redirect is its own
entity.

How would the redirect work, while at the same time allowing people to
go and create an article for that title later on?


from_name: Lee Daniel Crocker

subject: [Wikitech-l] New syntax proposal

body:
On Sat, 2005-06-11 at 15:24 +0000, ?var Arnfj?r? Bjarmason wrote:

> ...you specifically
> disallow level one (=) headings which is insufficient, remember that
> not everything is an article where you get the first heading generated
> for you, special pages and other extensions might want to make their
> own first heading...

The syntax only says that you can have five levels; the highest of
these is "==" (I don't want to have any single-character markup).
There's nothing that says you can't make "==" headings look identical
to (or even bigger than) H1s with styles.

I might even have a piece of metadata that says "move all headings
on this page up one level".

> * I like that one newline no longer terminates a list, however this
> syntax will not be complete without allowing
 since there will be
> no way to make paragraphs within a list item.

Paragraphs inside list items are not part of my content model, though
perhaps they should be.  You can achieve line breaks with \\.  I could
be convinced either way, but if we want paragraphs inside list items,
we'll have to come up with a syntax for it--perhaps \\ on a line by
itself could mean that.

> * I don't like your definition lists because they're exactly the same
> as the current ones and encourage using ":" for indenting, if you're
> going to indent something like
>
> : Indent
>
>

indent

 is not the best way to render it, it may be
> legal XHTML to omit
 and take advantage of the fact that
 is
> indented by what would be approximately a tab in most (if not all)
> browsers, but it's certainly far from the way it should be done?.

There's nothing that says the parser can't treat ":"s without a ";"
differently, and render them as paragraphs with an intend style instead
of actual DLs.  This is a rare concession to current use; I don't like
it much either, but I think most people generally do.

> * Using [[]] for external links means that in practice we won't be
> able to have articles/pages with titles like "http://foo" although
> [htp:/fo] are all legal characters in page names (not really that big
> a disatvangage, and I like it better than [])

That's another coming spec--I assure you, it will be possible to have
article titles with absolutely any combination of Unicode characters,
although some may be a little tricky to work with.

> * Just so we're clear you want [[stuff|like|this]] to generate
> (approximately) like? I don't really
> see the point, but I suppose it doesn't hurt since it extends the
> previous syntax gracefully.

And it keeps the syntax consistent with extensions and such.

> I like where you're going with the image syntax but I don't like it
> *quite* enough to really like it, I'll explain: What I don't like
> about our current image syntax is that due to the way it's all
> cluttered up it's hard to extend, yours is better but IMO not quite
> good enough, for example I'd like to have (comments begin with #):
>
>  <<begin image>>
>  file=pl_bulet.png
>  style=frame # instead of just "frame", no "magic words", just attributes=values
>  width=5em
>  caption=Logo
>  <<end>>

I like the idea of comments on variable lines.

> Note however that since = has a special meaning caption would always
> have to come last if you wanted to write something like.

Just use "caption=You can...with caption&x3D;foo"

> * I like the whole <<>> thing, but I'm not sure about the added
> complexities of using it for comments too, how about <<comment like
> this>> (just an extension named comment that ignores its input) rather
> than << like this>> (i.e. to make << *.*?>> comments), or just the old
>

I considered <<! This is a comment>> as well, but why add the character
just to make it look more like HTML?  The "noname" extension seemed like
a reasonably understandable thing to do.

> * I like // ** ^^ $$ and __, note however that since * is used for
> both lists and bold the parser would have to break a case like..

I thought about that, and I don't think it's a big problem, because
the only ambiguity arises when we're already inside a list (a line
beginning with ** outside a list is clearly boldface, because you
can't start nesting at level two).
A line beginning with "**" inside a list is either a nested list
item, or a boldface word at the start of an input line folded into
the list item above.
The ways to resolve that include just always making it mean a new
list item and taking care not to put bold words there (they can
always be avoided), or counting the **s on the line and making it a
list item if there's an odd number (a bit magical, but I'm not
terribly worried about rare cases like that).

--
Lee Daniel Crocker <lee at piclab.com>
<http://creativecommons.org/licenses/publicdomain/>


body:
On Sat, 2005-06-11 at 17:52 +0000, ?var Arnfj?r? Bjarmason wrote:
> Please make it an extension and not part of the core syntax.

Well, <<units 3 feet>>, of course. :)

--
Lee Daniel Crocker <lee at piclab.com>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Wikitech-l] New syntax proposal

body:
First of all, forget about my comment regarding ?? and ??, I was under
the impression that they were common on most keyboard layouts but they
apperently aren't, so I take that back, it's not a good idea.

I've gone over your proposal more thoroughly so here are some more
detailed, comments:

* Regarding your style of headings: It's currently possible to make
the html equivalent of <h[1-6]> with wikisyntax, but you specifically
disallow level one (=) headings which is insufficient, remember that
not everything is an article where you get the first heading generated
for you, special pages and other extensions might want to make their
own first heading (other than the one made with use of the title
object) using wikisyntax and there will be no way for them to do that
save for falling back to spitting out HTML, furthermore level one
headings are in wide use on pages like the English Wikipedia's Village
pump, why do you want to deprecate it? Presumably it clashes with
something else I haven't noticed.

* I like that one newline no longer terminates a list, however this
syntax will not be complete without allowing
 since there will be
no way to make paragraphs within a list item.

* I don't like your definition lists because they're exactly the same
as the current ones and encourage using ":" for indenting, if you're
going to indent something like

: Indent

indent

 is not the best way to render it, it may be
legal XHTML to omit
 and take advantage of the fact that
 is
indented by what would be approximately a tab in most (if not all)
browsers, but it's certainly far from the way it should be done?.

* Using [[]] for external links means that in practice we won't be
able to have articles/pages with titles like "http://foo" although
[htp:/fo] are all legal characters in page names (not really that big
a disatvangage, and I like it better than [])

* Just so we're clear you want [[stuff|like|this]] to generate
(approximately) like? I don't really
see the point, but I suppose it doesn't hurt since it extends the
previous syntax gracefully.

* I like the [[Foo (bar)|]] syntax, we currently do support that but
transform it (as Rowan Collins pointed out) at savetime, however I
don't see any good reason why it shouldn't be a valid part of the
syntax.

* I don't like the named arguments for links, It would clash with the
current namespace of links (i.e. does [[target=foo|text=bar]] point to
"foo" or "target=foo" ? How about [[asdf=foo]] ? ) I think it's
overdoing it, let's have one syntax for each action.

I like where you're going with the image syntax but I don't like it
*quite* enough to really like it, I'll explain: What I don't like
about our current image syntax is that due to the way it's all
cluttered up it's hard to extend, yours is better but IMO not quite
good enough, for example I'd like to have (comments begin with #):

 <<begin image>>
 file=pl_bulet.png
 style=frame # instead of just "frame", no "magic words", just attributes=values
 width=5em
 caption=Logo
 <<end>>

Note however that since = has a special meaning caption would always
have to come last if you wanted to write something like:

caption=You can make captions in MediaWiki with caption=foo

Or alternatively the parser would have to be smart about it.

* I like the whole <<>> thing, but I'm not sure about the added
complexities of using it for comments too, how about <<comment like
this>> (just an extension named comment that ignores its input) rather
than << like this>> (i.e. to make << *.*?>> comments), or just the old

* I was sceptical at first about the new {{}}, but I've come to like
it, any "decent" article on Wiki(pedia|media) seems to have infoboxes
and other things that require some kind of inline CSS styles and
eliminating all that in favor of a pure wikisyntax solution would be
nice indeed.

* I like // ** ^^ $$ and __, note however that since * is used for
both lists and bold the parser would have to break a case like
"***foo**" down by looking for the closing ** at the end of the line
to see if it's dealing with a first level
 or a third level

(not that big a deal, we do that already in a way with ''' and '')

* Aside from the advantages of the new {{}} they're just like our
current tables, except for one thing, the new ^ and < syntax, I love
it, I think it's a very simple and intuative solution to the problem
of  colspan/rowspan not being obvious enough.

P.s. Of course the french will hate it, but that kind of given..


subject: [Wikitech-l] Re: bugzilla votes

body:
On 6/11/05, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> ?var Arnfj?r? Bjarmason wrote:
> > Tim reconfigured it to have one vote per bug and a very large pool of
> > votes ( given our # of bugs ) per user, each user now has one vote per
> > bug.
> >
> > I like it.
>
> Now you can actually tell which bugs are more wanted than other bugs.
> Some people were voting 1, some 100, some 400, some 700. When you add
> them all together you get a number which has not much relation to
> anything. There were 3 developers present on IRC, all were in favour.
> Bugzilla sent an email to everyone who had voted telling them that their
> votes had been declared invalid, bless it.
>
> While I was at it I gave ?var admin access on Bugzilla, I'm sure he'll
> have fun tweaking categories.

I'm having the time of my life >;)

But while we're at it here's a neat vote-related link:

* http://tinyurl.com/7svp9 Bugs with more than 3 votes ordered by votes


subject: [Wikitech-l] Re: bugzilla votes

body:
On 6/11/05, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> Hoi,
> I have mixed feelings with this new effort to give a new lease of life
> to the bugzilla votes. Previously the votes on bugs were dismissed with
> a "we do what we want because we are volunteers". It is encouraging that
> the votes are looked at again, but has something really changed, the
> developers are still volunteers and they can as easily dismiss the votes
> as they have done in the past. It makes no difference who does the
> asking, there are bugs where Jimbo, Anthere and Angela all asked for a
> particular bug to be fixed.. to no avail.. And indeed why would such a
> request be honoured; the developers are volunteers ..

Well votes will always be dismissed to a certain degree for the
reasons you cited, however with the previous system when I did look at
it I felt that, like Tim said (paraphrased) I didn't get a number with
much relation to anything. Whereas now I can see that X people found
bug Y important enough to vote for it, which for me says alot more
than a bug with 2000 votes which could be the result of two people
voting for it with their maximum of 1000 votes or 20 people voting
with 100 votes.

> In the past you had many votes to give away but they were a finite
> resource. When a bug was given a massive amount of votes by one person
> it meant that the request was really important. Now a person can give
> only one vote for one bug. The developer can still say "I am a volunteer
> and I will do bug X in stead".

Of course, and that will never ever change as long as you have
volunteers, no matter good your vote system you have, note however
that some of us(1) do like helping people out and at least take these
votes in as a factor when deciding what to work on.

1. Not meant as some lame attack on anyone else working on develoment.


from_name: Mathias Schindler

subject: [Wikitech-l] bugzilla votes

body:
Brion Vibber wrote:

> We last upgraded Bugzilla a month or two ago. Did it change then, or
> more recently?
>
this morning.


from_name: Matthew Felgate

subject: [Wikitech-l] MediaWikiSite

body:
Hi there,

I want to set up a MediaWiki site on my hosting and domain. The
technical info seems a bit complex, could you explain it to me please?
I can get mySQL and PHP as required, but is a lot of PHP required to
make my wiki site secure and so some small edits?

thanks,
hope you can help,
--
MatthewFelgate
@Hotmail.com for MSN
@GMail.com for Email


from_name: Sj

subject: [WikiEN-l] wikimania acceptance rate? (update)

body:
Submissions were generally good, and we tried to accept as many
submissions as we could.  Due to time constraints, a number of
presentations could only be accepted as short presentations.

== Presentations ==
8 of 10 workshops and tutorials were accepted.
Another two tutorials were specifically requested.

Of around 65 other submissions, we have accepted 44:
  27 as presentations
  15 as short presentations / part of a panel discussion
  Two fun submissions will be part of a late-night program, along with
the wikitrivia finals and virtual mud-wrestling. (ok, the mudwrestling
is still a point of contention)
-----
This comes to around 25 hours of presentations and workshops, spread
across the three days of the conference.

== Hacking Days ==
Another dozen ideas have been submitted from various wiki developer
groups (XWiki, Twiki, PurpleWiki, Confluence, Craowiki, TING?) about
tools and hacks to present during the Hacking Days leading up to the
conference.

== Proceedings online ==
Serious submissions, including those we were not able to accept as
speakers, will be invited to have a paper included in the online
proceedings.

Last-minute posters and papers (particularly for breaking
developments) are being accepted for another few weeks.

== Unofficial calendar ==
Finally, attendees and those planning to take part via skype/IRC are
invited to schedule their own gatherings and specialized workshops :
http://meta.wikimedia.org/wiki/Wikimania:Presenters#Unofficial_calendar

SJ

> We have accepted:
> 4 Keynotes and special invitations
> 35 presentations.
> 7 short presentations
> 2 after hours presentations
>
> There are 6 open and late submissions still under discussion.
> There are at least 3 accepted Poster/Paper only submissions.
>
> There are 19 rejected submissions. In a few cases, people sent more
> than one abstract, and generally only one was accepted, so the number
> of rejected submissions reflects this.
>
> More information about the conference can be found at
> http://wikimania.wikimedia.org/
>
> Angela.


from_name: Gerard Meijssen

subject: [Wikitech-l] Re: bugzilla votes

references:
<42AAAFC0.4010601@yahoo.com>	<51dd1af8050611071232cc5374@mail.gmail.com>	<d8esel$psb$1@sea.gmane.org>
	<d2f92e8b05061108006b0fecd6@mail.gmail.com>

body:
Hoi,
I have mixed feelings with this new effort to give a new lease of life
to the bugzilla votes. Previously the votes on bugs were dismissed with
a "we do what we want because we are volunteers". It is encouraging that
the votes are looked at again, but has something really changed, the
developers are still volunteers and they can as easily dismiss the votes
as they have done in the past. It makes no difference who does the
asking, there are bugs where Jimbo, Anthere and Angela all asked for a
particular bug to be fixed.. to no avail.. And indeed why would such a
request be honoured; the developers are volunteers ..

In the past you had many votes to give away but they were a finite
resource. When a bug was given a massive amount of votes by one person
it meant that the request was really important. Now a person can give
only one vote for one bug. The developer can still say "I am a volunteer
and I will do bug X in stead".

To conclude, it makes little difference how the votes are looked at
because there is only one vote that is essential. It is the developer
saying: "Yes, that is something I can do, let's give it a go".
Thanks,
    GerardM


from_name: Fastfission

subject: [WikiEN-l] Wikipedia & Original Research

body:
On 6/10/05, Geoff Burling <llywrch at agora.rdrop.com> wrote:
> 3. To write some articles with a desirable quality, it is almost
> impossible not to resort to what can be called, in good faith,
> original research. And this point makes the matter a hard one.

> This is all meant as more material to chew on. The [[No original
> research]] policy helps in a lot of different ways, but clearly
> it has a few problems that require some tweaking with it.

Yes and no. Yes -- NOR and NPOV cannot be understood as strictly
logical rules, as all entries (and some more than other) involve some
forms of individual interpretation, or at least selection of some
approaches out of others, etc. No -- I'm not sure they require
tweaking because of this.

In the 19th-century, scientists went through what is now considered a
"crisis of objectivity" -- they became increasingly insecure about
their ability to be "objective" (for a variety of reasons; increasing
influence of scientific opinion in public life, increasing concerns
about science and religion, discovery of phenomena such as systematic
observation errors, i.e. the "personal equation", etc.) and began to
frantically assert their objectivity in various ways (i.e. by relying
on mechanical representation over "interpretation", etc.). A number of
philosophers (i.e. Kuhn) have pointed out that the idea of an
"objective observation" is contradictory -- if it is an observation,
there must be an observer, and all observers are, to some degree,
subjective. Objectivity cannot be achieved in a philosophically
rigorous sense -- indeed, it never has been.

So what purpose does the concept serve? It is an ethos more than
anything else, a quasi-religious stricture about proper conduct and
goals. The desire not to mislead, the desire to report only as things
are and not what you want them to be, etc. and so forth. When it gets
violated in some obvious way, it is held up as an example of "what not
to do." Otherwise it pushes things along, and sometimes (often?)
falters, because humans are fallible and the world is not a logical
machine. But Wikipedia articles are remarkable for their process, not
their conclusions*, and the same thing could probably be said of
science as well -- many conclusions of today's scientific work will be
seen as woefully inadequate in a few decades, but that doesn't mean we
should disregard them today; the system of knowledge production makes
them the most reliable knowledge we have.

So yes, ultimate NPOV and NOR is not possible. And never will be. But
I think changing the rules to more heavily reflect this would not be
helpful -- it would only encourage those who want to emphasize their
policies against notions of NOR and NPOV, and as goals they are very
good.

As someone I respect once said, all of the world is built up on
various constructions. But the Three Little Pigs well shows that not
all constructions are as good as others. Similarly, all entries are
built up on some inherent POV. But some POV is more nuanced and
neutral than others. Let's keep our lofty goals, even if we know they
won't satisify the analytical philosophers. They make a nice ethos.

FF

*Which is why I think having hard-copies is so counter-intuitive,
though I can understand why some people would want one -- i.e. slow
internet connections, more interested in using it as a tool to learn
with than a tool to edit with, etc.


subject: [Wikitech-l] MediaWikiSite

body:
On 6/11/05, Matthew Felgate <matthewfelgate at gmail.com> wrote:
> Hi there,
>
> I want to set up a MediaWiki site on my hosting and domain. The
> technical info seems a bit complex, could you explain it to me please?
> I can get mySQL and PHP as required, but is a lot of PHP required to
> make my wiki site secure and so some small edits?

Well, it's not any harder than installing MySQL, PHP, Apache/IIS; in
fact, I find it much easier. Read all the documentation (especially
README's INSTALL's or what comes with the package), then go through
the installation pages on
http://meta.wikimedia.org/w/index.php?title=Help:Contents and if you
come to any problems, post about them here or ask in IRC.

Frankly I don't see how anyone could explain such an open ended
question without you hiring someone and that person going through the
install for you.


body: Please make it an extension and not part of the core syntax.