from_name: Mark Williamson

body:
Wow!

You guys really drummed up support quickly!

Yes, please, we should have the Cebuano Wikipedia created right away.

It's high time we have Wikipedia in the non-Tagalog languages of the
Philippines, many of which are spoken by millions.

Mark

On 10/06/05, Vincent Bentong S. Isles <bentong_isles at yahoo.com> wrote:
> 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
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
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: wikipedia-l

source: pipermail-mbox

subject: [Wikipedia-l] Request for Kapampangan Wikipedia

body:
Hi Edwin,,

Just wondering but do you speak Kapampangan yourself?

And would you be willing to write much of the content on the
Kapampangan Wikipedia yourself?

Is there anybody else col-laborating with you?

Mark

On 11/06/05, katimawan . <katimawan2005 at yahoo.es> wrote:
> Sir/Madam:
>
> I wish to request for the inclusion of the Kapampangan language in the List of Wikipedias preliminary to the creation of a Wikipedia for Kapampangan.
>
> Kapampangan (ISO language code "pam"), described in ethnologue.com as a "language of wider communication," is the seventh largest of the eight major languages of the Philippines.  It is spoken by  over two million people (as of the 2000 census) in the provinces of Pampanga (where it is the language of about 90% of the population), Tarlac (about 40%), and adjoining areas of Bataan and Nueva Ecija.  There are substantial numbers of Kapampangans in other parts of the Philippines including Metropolitan Manila, as well as in the United States, Canada and Australia.
>
> Alternate names for Kapampangan listed by ethnologue.com include Pampango, Pampangue?o, and Kapampangan.  According to the same site,
> its classification is: Austronesian, Malayo-Polynesian, Northern Philippine, Bashiic-Central Luzon-Northern Mindoro, Central Luzon, Pampangan
>
> Thank you!
>
> Edwin
>
> ---------------------------------
>
> Correo Yahoo!
> Comprueba qu? es nuevo, aqu?
> http://correo.yahoo.es
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
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


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

body:
Hi Wouter,

Can you tell me, do you think Zeelandic is further or the same
distance linguistically from Dutch as Limburgish??

Mark

On 11/06/05, Wouter Steenbeek <musiqolog at hotmail.com> wrote:
>
> >We are currently inconsistent in our treatment of different linguistic
> >situations.  I do not think this inconsistency is good, but I also do
> >not think it is a grave crisis.  I am not even certain that consistency
> >is desirable -- there may not be a "one size fits all" solution to this
> >question.
>
> There isn't any. Think about Norwegian (bokmaol and nynorsk), Swedish and
> Danish - they could easily be grouped as variants of one language,
> "Continental Nordic". Yet I think it would have been madness to grant them
> only one Wikipedia, certainly as all Scandinavian Wikipedias are among those
> with the best speakers-size comparision.
>
> >
> >Are all people who could read Zeelandic and Town Frisian also people who
> >can read standard Dutch?  Then we don't *need* them for our primary
> >mission, but they would be a nice thing to have as well, if it makes
> >social sense for the community.  (Meaning, if there are enough people
> >who want to do it, etc.)
>
> Yes, they all can, as they learn Dutch proper only at school (and Frisian,
> for the Town Frisian speakers). But they have a certain pride of their
> languages, especially the Zealandic speakers, and I am pretty sure I can get
> some willing contributors behind a Wikipedia. (I won't even request it if my
> quest for other contributors fails!)
>
> Wouter
>
> _________________________________________________________________
> Gebruik MSN Webmessenger op je werk en op school
> http://webmessenger.msn.com/
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
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


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

body:
Yes...

And the same is true for many people handling a second language --
they will naturally not understand as well as a native speaker.

Many -- if not most -- people who are working in a second language
will find the Wikipedia in their second language less accessible than
one in their first.

My Navajo teacher was getting her PhD in English the last time I
talked to her, yet she said that for her Navajo is still easier. You
might expect that she's very old but in fact she's very young, in her
20s or 30s, and actually a former Miss Navajo Nation. As far as I
know, right now her main job is teaching English as a second language.

Mark

On 11/06/05, Anthere <anthere9 at yahoo.com> wrote:
>
>
> 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".
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
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: wikitech-l

from_name: Ævar Arnfjörð Bjarmason

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

body:
On 6/11/05, Matt Wright <mw at mattwright.com> wrote:
> 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.

Well I was thinking along the lines of an extesion like <unit>3
m</unit>, anyway not to be to critical of your work but I really
dislike the yet-another-syntax for something like this.

Just my $.02


from_name: Brion Vibber

subject: [Wikitech-l] New syntax proposal

body:
Tomasz Wegrzanowski wrote:
> On Sat, Jun 11, 2005 at 03:10:09PM -0700, Lee Daniel Crocker wrote:
>>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".
>
> Do you have any particular reason to allow only 5 levels ?
> That breaks backwards compatibility and reduces range of
> allowed options for no good reason.

HTML < XHTML 2.0 provides only six levels of headings; our existing
syntax, inherited from UseModWiki, directly maps each given ={1,6} to
<h1>..<h6>. The first level is reserved by MediaWiki for the page itself.

We could do additional levels by using different elements for headings
beyond <h6> in our HTML output, if we really needed to, but we don't
support those now and I doubt there's much reason to add them.

Manually adding level-1 headings is deprecated already, but we let the
current parser accept them as a stop-gap measure so that existing ones
could be fixed up without breaking in the meantime. (IIRC, on the
request of pl.wikipedia folks.)

A side note: XHTML 2.0 will introduce a new abstraction for headers
based on nested <section>s, each of which can contain a <h>, to
arbitrary depth:
http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.

I'm not sure if that's a model we might want to consider; that kind of
large-scale nesting doesn't really map well to the wiki model, which
favors line-based chunks.

-- 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/a8cfcb35/attachment.pgp>


from_name: katimawan .

body:
Sir/Madam:

I wish to request for the inclusion of the Kapampangan language in the List of Wikipedias preliminary to the creation of a Wikipedia for Kapampangan.

Kapampangan (ISO language code "pam"), described in ethnologue.com as a "language of wider communication," is the seventh largest of the eight major languages of the Philippines.  It is spoken by  over two million people (as of the 2000 census) in the provinces of Pampanga (where it is the language of about 90% of the population), Tarlac (about 40%), and adjoining areas of Bataan and Nueva Ecija.  There are substantial numbers of Kapampangans in other parts of the Philippines including Metropolitan Manila, as well as in the United States, Canada and Australia.

Alternate names for Kapampangan listed by ethnologue.com include Pampango, Pampangue?o, and Kapampangan.  According to the same site,
its classification is: Austronesian, Malayo-Polynesian, Northern Philippine, Bashiic-Central Luzon-Northern Mindoro, Central Luzon, Pampangan

Thank you!

Edwin

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

Correo Yahoo!
Comprueba qu? es nuevo, aqu?
http://correo.yahoo.es


from_name: Jeremy Dunck

subject: [Wikitech-l] Font in logo?

body:
Does anyone know what font is used in this logo:
http://upload.wikimedia.org/wikipedia/meta/thumb/d/d0/180px-Wikipedia-word.png

I tried to Identifont it, but without more of a sample of letters, it
was pretty tough.

Thanks!


from_name: Gerard Meijssen

subject: [Wikitech-l] Re: bugzilla votes

body:
Tim Starling wrote:

>Gerard Meijssen wrote:
>
>
>>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.
>>
>>
>
>Maybe that's what it meant to you, but what did it mean to the 170 out
>of 320 voters who have only voted for one bug? And what did it mean to
>the many people who voted with a value of 1, without ever giving
>consideration to multiple votes?
>
>As for the rest of your post, I've always done my best to do the right
>thing by Wikipedia and its users, I know you're annoyed that that's a
>"p" in the middle of the word instead of an "m". You're not going to
>make me feel guilty by pointing out that the group of users to whom I
>freely give my time and assistance doesn't include you. I'm interested
>in vote tallies to the extent that they give an indication of the needs
>of Wikipedians.
>
>-- Tim Starling
>
Hoi,
Tim, please do not misunderstand. The voting system has a limited
effect. When I need something programmed, I know that I do not need to
ask you if it does not apply to the "p". I am not annoyed about that
there are more fish in the sea and, I have my own way of getting what is
needed. When a bug is voted upon, and it gets many votes, it is voted
upon by Wikimedians, many people are not confined to just one project.
It is your choise to work only on Wikipedia issues. Your exclusiveness
makes it less relevant to ask you for an opinion when it is not strictly
Wikipedia. That is a loss, because I rate you as a capable and competent
person.

I would and will be annoyed when work done for other projects is
frustrated or sabotaged because it is not Wikipedia related. That is
something that has not happened yet as far as I am aware. It is sad that
you exclude me from people you would give assistance; I do spend time
and effort on wikipedia. If it means that I have to ask others to put
forward my proposals re Wikipedia let me know. I had something to do
with the Kennisnet servers, I do not think that you would not spend time
on these when there is a need just because I had some involvement
there.. Please Tim, judge my requests on their merits and if you do not
want to personally honour a specific request do so in silence, there is
no need to be nasty about it.

By the way, for your amusement, a Dutch saying; "er de p in hebben" "to
have the p in it" means that you are really annoyed... so it is funny
that you want to find a "p" in it. :)

Thanks,
    GerardM


from_name: David A. Desrosiers

subject: [Wikitech-l] Font in logo?

body:
> I tried to Identifont it, but without more of a sample of letters,
> it was pretty tough.

 	"What the Font" gets it right:

 	http://www.myfonts.com/WhatTheFont/

David A. Desrosiers
desrod at gnu-designs.com
http://gnu-designs.com

d.

perldoc -qa.j | perl -lpe '($_)=m("(.*)")'


list: wikien-l

from_name: sannse

subject: [WikiEN-l] CSS and underlined links

body:
We had an email asking why we override browser defaults to underline
links.  I've asked about this at
http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css , but am not
sure how much that is watched.  Any comments would be most helpful there.

(and yes, I know this can be changed in preferences, but that's not a
help for the large number of non-logged in readers we have)

--sannse


from_name: David 'DJ' Hedley

subject: [WikiEN-l] CSS and underlined links

body:
It may be a colourblindness issue for red links. If your colourblind you
wouldn't be able to determine a red link from normal text.
----- Original Message -----
From: "sannse" <sannse at tiscali.co.uk>
To: <wikien-l at wikimedia.org>
Sent: Saturday, June 11, 2005 9:08 PM
Subject: [WikiEN-l] CSS and underlined links

> We had an email asking why we override browser defaults to underline
> links.  I've asked about this at
> http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css , but am not
> sure how much that is watched.  Any comments would be most helpful there.
>
> (and yes, I know this can be changed in preferences, but that's not a
> help for the large number of non-logged in readers we have)
>
> --sannse
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Wouter Steenbeek

body:
>We are currently inconsistent in our treatment of different linguistic
>situations.  I do not think this inconsistency is good, but I also do
>not think it is a grave crisis.  I am not even certain that consistency
>is desirable -- there may not be a "one size fits all" solution to this
>question.

There isn't any. Think about Norwegian (bokmaol and nynorsk), Swedish and
Danish - they could easily be grouped as variants of one language,
"Continental Nordic". Yet I think it would have been madness to grant them
only one Wikipedia, certainly as all Scandinavian Wikipedias are among those
with the best speakers-size comparision.

>
>Are all people who could read Zeelandic and Town Frisian also people who
>can read standard Dutch?  Then we don't *need* them for our primary
>mission, but they would be a nice thing to have as well, if it makes
>social sense for the community.  (Meaning, if there are enough people
>who want to do it, etc.)

Yes, they all can, as they learn Dutch proper only at school (and Frisian,
for the Town Frisian speakers). But they have a certain pride of their
languages, especially the Zealandic speakers, and I am pretty sure I can get
some willing contributors behind a Wikipedia. (I won't even request it if my
quest for other contributors fails!)

Wouter

_________________________________________________________________
Gebruik MSN Webmessenger op je werk en op school
http://webmessenger.msn.com/


from_name: Lee Daniel Crocker

subject: [Wikitech-l] New syntax proposal

body:
On Sun, 2005-06-12 at 01:55 +0200, Tomasz Wegrzanowski wrote:

> Do you have any particular reason to allow only 5 levels
> [of headings] ?
> That breaks backwards compatibility and reduces range of
> allowed options for no good reason.

Wikitexts generally end up being rendered /within/ HTML pages,
and HTML has a limit of six levels anyway, so it seemed safe.
But I'm not married to it.  Are there really Wiki pages that
use all six?  I'd be surprized if any really needed even five.

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


from_name: Brent 'Dax' Royal-Gordon

subject: [Wikitech-l] New syntax proposal

body:
On 6/11/05, Brion Vibber <brion at pobox.com> wrote:
> A side note: XHTML 2.0 will introduce a new abstraction for headers
> based on nested
s, each of which can contain a <h>, to
> arbitrary depth:
> http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.

As long as you're mentioning this, I'll point out that XHTML 1 and
MediaWiki markup don't support the problem pattern currently:

    <h>Upper heading</h>

...

...

        <h>Lower heading</h>

...

...

...

...

I don't think it's a particularly common one, so it probably wouldn't
be a big problem if we failed to support it.  The model we see now
would basically require tracking the our current heading depth and
adding an appropriate number of
 tags when we see a new
heading.

Once XHTML 2 is out and reasonably popular, of course.

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


subject: [Wikitech-l] New syntax proposal

body:
On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote:
> 1) I noticed you kept the "space for preformatted text" syntax. I think
> this is one of the single biggest causes of confusion, as it's quite
> easy to type:
>
> One line ..
>
> Another line ..
>
> That is, to accidentally insert a space between two paragraphs. The
> output will look weird, you look at your source text, but you don't see
> what the cause is, as spaces are invisible.

Actually, in the formal syntax I do fix this; spaces and tabs as the end
of input lines are removed, and /not/ interpreted.  What looks like an
empty line /is/ an empty line, so no invisible PRE section gets created.

> 2) Why not think about some alternative link patterns? I've personally
> always thought that double underscores might be cool. Compare:

I like it, but I'm not sure we could sell that one.

> 3) The template syntax needs to be shorter, since it's ubiquituous.

Personaly, I think they /should/ be a little more difficult to
discourage their use, but I'm sure that opinion isn't shared by
everyone.

> 4) We generally have to be careful with hiding namespaces from users.
> <<image file:xyz.jpg>> may be better than <<image file=xyz.jpg>> or
> <<image xyz.jpg>> because it preserves the visibility of the namespace.

Hmm. Not sure I see that as a big issue, but I'll think about it.

> b) Using {{..}} creates *huge* transitional issues. Like it or not,
> templates are deeply rooted into Wikipedia, and changing the function of
> curly braces to something completely different will confuse the hell out
> of many users who use that syntax every day.

That's really not an argument that sways me.  No matter how many users
there are now, /most/ Wikipedia users are in the future, and we owe it
to them to make the most usable system we can, even at the expense of
present users.

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


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] CSS and underlined links

body:
I assume it was done because a lot of people hate a bunch of
underlines in their text. Personally, it doesn't really bother me, and
I can change it in my preferences anyway, so we might as well change
it for outsiders.

--Mgm

On 6/11/05, sannse <sannse at tiscali.co.uk> wrote:
> We had an email asking why we override browser defaults to underline
> links.  I've asked about this at
> http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css , but am not
> sure how much that is watched.  Any comments would be most helpful there.
>
> (and yes, I know this can be changed in preferences, but that's not a
> help for the large number of non-logged in readers we have)
>
> --sannse
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Matt Wright

subject: [Wikitech-l] New syntax proposal

body:
On 2005-06-10, Lee Daniel Crocker wrote:
>
> I decided to release my new syntax for comment before I
> finished the formal definition.  I'd like to get opinions
> about it;

What about this idea for user preference displays (dates and possibly units
or other items in the future).  Terms which can be marked up for user
preference display is done with ((term)). I don't care about exact syntax,
this is just an example.  If it should be linked, the syntax becomes
([term]).

This would allow dates, units, etc. to be shown according to user
preferences without always having to appear in link form. For those who
still wish to use link form, the syntax is still just as short:

([January 1, 2000]) to link [[January 1]], [[2000]]
((January 1, 2000)) for date format without links

Which would get linked the same way it currently is for [[January 1]],
[[2000]]. Similarly, if people are in favor of an automatic unit converter,
it could be represented as:

((3 ft)) for a plain conversion
([3 ft]) for a conversion + link to 1 E0 m

Matt


subject: [Wikitech-l] New syntax/Styles

body:
On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote:

> a) This {{i may be {{b}}nested, as long}} reads horrible. Having
> styles separated from words with spaces makes them look like words.
> They are markup syntax, hence must be clearly visually distinct from
> the content they describe.

I agree it looks bad, so let's consider some alternatives (I've
separated this into a separate thread).

We need some way to tag a short span of text with either a
unique ID or a non-unique class.  The current proposal uses the
alpha/numeric separation to do this.  We could use just numbers,
and tag them with a special character:

{{.5 may be {{#7 nested}}, as long}}

(The "." and "#" are used by CSS)  But that makes it difficult to
have built-in styles with understandable names.

Another possibility is to put the ID between the braces:

{i{ may be {b{ nested}}, as long}}

This separates them from the words a little, but might make parsing
a bit trickier.  I definitely don't want to change the methods of
marking big blocks--that is, using begin/end consistent with other
parts of the syntax, and having a lone {{style}} on a line mark the
following block.  I hate having long-range bracketing--programmers
are used to it, but new users are much more comfortable with "tag
this next thing", or having the big brackets /very/ clearly marked.

FWIW, I imagine that these will not be used often enough to be a
big problem, because most of what needs to be done can be done with
the symbolic shortcuts.  But the full capability needs to get there
somehow for those special cases.

Any other ideas?

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


from_name: JAY JG

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

body:
>From: "James D. Forrester" <james at jdforrester.org>
>
>The identity of 'the God', 'a god', or 'the gods' is one that a great
>number
>of people have differing views upon. A sub-example of this is the concept
>of
>the r?le of 'the God' - a large number of people consider the Palestinian
>Jew "Jesus" to have been this figure. Other religions and traditions have
>different views - "Rastafarians believe that Haile Selassie is both God the
>Father and God the Son", to quote our article [[God]]. Yet further ones
>insist that he is yet to come forth, but will do at some point - Jews, for
>instance (IIRC).

This is getting a bit off topic, but Jews are not waiting for God to come
forth, since they already believe they have received a great deal of
revelation from him. Rather, they are waiting for the Messiah.  Your
confusion probably arises from the fact that Christianity equates the two.

>All of these are opinions held by (at least) millions of
>people, and we would (and do) given them time in an article on the subject
>(we would probably go through them in rough descending order of believers,
>by past memory - this gives more prominence to widely-held opinions without
>prejudicing the readers' opinions of or promoting some judgement on them).
>OTOH, [[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. :-)

Exactly; those who claim that every single thing that everyone has said on a
subject must be included in an article on that subject, so long as the
statement can be cited, are trying to build some soft of general
knowledge/trivia repository, not an encyclopedia.

> > > 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.

Exactly.

Jay.


list: foundation-l

from_name: Angela

subject: [Foundation-l] Local Wikimedia chapters FAQ

body:
I have started a FAQ about local Wikimedia chapters at
http://meta.wikimedia.org/wiki/Local_chapter_FAQ with 10 of the
questions that I know have been asked a lot.

If you know of any more frequently asked questions, or if you have
questions yourself, or if you are able to answer some of the existing
questions, please help with the creation of this page.

I am hoping it will become a useful resource, both for those involved
with current chapters, those wanting to start a new chapter, and also
for users of Wikimedia projects who are confused about the entire
concept of chapters.

Thanks.

Angela.


list: wikimedia-l


from_name: Tim Starling

subject: [Wikitech-l] Re: bugzilla votes

body:
?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.

-- Tim Starling


from_name: Ray Saintonge

subject: [Wikitech-l] New syntax proposal

body:
Lee Daniel Crocker wrote:

>On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote:
>
>
>>1) I noticed you kept the "space for preformatted text" syntax. I think
>>this is one of the single biggest causes of confusion, as it's quite
>>easy to type:
>>
>>One line ..
>>
>>Another line ..
>>
>>That is, to accidentally insert a space between two paragraphs. The
>>output will look weird, you look at your source text, but you don't see
>>what the cause is, as spaces are invisible.
>>
>>
>Actually, in the formal syntax I do fix this; spaces and tabs as the end
>of input lines are removed, and /not/ interpreted.  What looks like an
>empty line /is/ an empty line, so no invisible PRE section gets created.
>
A leading space can be useful for poetry in Wikisource.

>>3) The template syntax needs to be shorter, since it's ubiquituous.
>>
>>
>Personaly, I think they /should/ be a little more difficult to
>discourage their use, but I'm sure that opinion isn't shared by
>everyone.
>
Indeed.  The recent growth in template use can make editing far more
difficult for people who are not familiar with the relevant templates.

Ec


from_name: Zigger

subject: [Wikitech-l] Re: bugzilla votes

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

body:
I didn't like it at first, as I can't prioritise my votes, and the
previous wide range meant that developers might have been more likely
to look beyond the raw number.  But after having looked at the result
of (1), I'm intrigued by what is going to happen next, if people are
actually going to use these.  And will we see the rise of evangelists,
ginger groups, and sock-puppets?  Mmmm, politics ...

Some highlights:

   The only non-enhancement in the top ten requires MySQL 4.1.
   Getting 1.5 out the door gets two votes (bumped to three votes,
which may seem high for a tracking bug but the PostgreSQL tracker beat
it).
   The top four are all to do with integration of the Wikimedia wikis.
   Documentation is #11.

The maximum number of votes has not changed, but 1000 per product
seems sufficient.

(1)
http://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&votes=1&order=bugs.votes

-- Zigger


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] New syntax proposal

body:
On Sat, Jun 11, 2005 at 03:10:09PM -0700, Lee Daniel Crocker wrote:
> 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".

Do you have any particular reason to allow only 5 levels ?
That breaks backwards compatibility and reduces range of
allowed options for no good reason.


from_name: Brion Vibber

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

body:
Eric Walker wrote:
> Brion Vibber <brion <at> pobox.com> writes:
>>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?

Downloading a dump from time to time takes a bit of bandwidth and
virtually no processing power for us. Our scarce resources are in the
database load and the wiki's web processing, which aren't touched by this.

We pump out something on the order of 100Mbps, so if you were to
download, say, the 900 megabyte English Wikipedia current-article dump
once a week that would be a pretty small dent.

>>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"?

Generally, if your volume's big enough to be noticed leeching page views
and searches off our main servers, you've got a fair chance of being
blocked. (I seem to remember hearing something about the search engine
being hit in this case, but I may be thinking of something else.)

Having your rewritten output include ad banners or remove the Wikipedia
attribution, copyright/licencing info, etc is pretty much certain to get
you blocked. (I have never seen your web site personally, I don't know
if these apply.) We are under no obligation to act as a back-end web
server for other peoples' web sites.

> 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 hate to say "not my problem", but honestly it's your responsibility,
not ours, to find and pay for the hosting of *your* web site.

> 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.
[snip]
> 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?

You may wish to propose this to the Wikimedia Foundation board of
directors; they can be reached by e-mail at: board at wikimedia.org

> 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?

If your site doesn't appear to violate the content license, and you
follow earlier suggestions about caching data (preferably backed by your
own local copy to begin with) and you limit your hit rate and don't
abuse our search engine or other tools, you probably won't get blocked.

But again, there are no guarantees. We run our web site, not yours, and
if our system administrators feel your site's eating more load than it
should it may well get cut off at some point.

A general recommendation for remote loading: if you're not already doing
this, always use a relevant user-agent string which identifies your site
well enough that the other site's admins can find and contact you.
(Including an e-mail address is strongly recommended; an URL might be
insufficient if your site is being slashdotted or DoSed.)

If we know who you are and how to contact you, and we know that you've
made a good-faith effort, you're more likely to get the benefit of the
doubt. But if there's a necessity, such as a huge flash crowd sending
far too many requests to us due to poor throttling on your site, you
might well find yourself blocked without prior notice.

-- 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/20050612/552b02ee/attachment.pgp>


subject: [Wikitech-l] Re: bugzilla votes

body:
Gerard Meijssen wrote:
> 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.

Maybe that's what it meant to you, but what did it mean to the 170 out
of 320 voters who have only voted for one bug? And what did it mean to
the many people who voted with a value of 1, without ever giving
consideration to multiple votes?

As for the rest of your post, I've always done my best to do the right
thing by Wikipedia and its users, I know you're annoyed that that's a
"p" in the middle of the word instead of an "m". You're not going to
make me feel guilty by pointing out that the group of users to whom I
freely give my time and assistance doesn't include you. I'm interested
in vote tallies to the extent that they give an indication of the needs
of Wikipedians.

-- Tim Starling


from_name: David Friedland

subject: [Wikitech-l] Re: Font in logo?

body:
Jeremy Dunck wrote:
> Does anyone know what font is used in this logo:
> http://upload.wikimedia.org/wikipedia/meta/thumb/d/d0/180px-Wikipedia-word.png
>
> I tried to Identifont it, but without more of a sample of letters, it
> was pretty tough.
>
> Thanks!

It's Hoefler Text Roman Small Caps.


subject: [Wikitech-l] New syntax proposal

body:
On Sat, Jun 11, 2005 at 06:29:49PM -0700, Brion Vibber wrote:
> >Do you have any particular reason to allow only 5 levels ?
> >That breaks backwards compatibility and reduces range of
> >allowed options for no good reason.
>
> HTML < XHTML 2.0 provides only six levels of headings; our existing
> syntax, inherited from UseModWiki, directly maps each given ={1,6} to
> <h1>..<h6>. The first level is reserved by MediaWiki for the page itself.
>
> We could do additional levels by using different elements for headings
> beyond <h6> in our HTML output, if we really needed to, but we don't
> support those now and I doubt there's much reason to add them.
>
> Manually adding level-1 headings is deprecated already, but we let the
> current parser accept them as a stop-gap measure so that existing ones
> could be fixed up without breaking in the meantime. (IIRC, on the
> request of pl.wikipedia folks.)
>
> A side note: XHTML 2.0 will introduce a new abstraction for headers
> based on nested <section>s, each of which can contain a <h>, to
> arbitrary depth:
> http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.
>
> I'm not sure if that's a model we might want to consider; that kind of
> large-scale nesting doesn't really map well to the wiki model, which
> favors line-based chunks.

We can have as many header levels as we want with CSS classes.
That's what we already do, page title and article's level-1 headers
look different.

Anyway, it costs nothing, preserves backwards compatibility,
and is useful in at least some cases (otherwise it wouldn't be used),
so why remove it ?


from_name: Erik Moeller

subject: [Wikitech-l] New syntax proposal

body:
1) I noticed you kept the "space for preformatted text" syntax. I think
this is one of the single biggest causes of confusion, as it's quite
easy to type:

One line ..

Another line ..

That is, to accidentally insert a space between two paragraphs. The
output will look weird, you look at your source text, but you don't see
what the cause is, as spaces are invisible. Unless you know about this
particular bit of syntax and understand its purpose, you will likely
leave the text as it is and hope someone else fixes it. I've seen quite
a few decent articles where people made this mistake, but left it in --
though it's quite visually obvious in the output, it's non-trivial to
fix. My guess is that if we did a survey, we would find that the large
majority of users don't know that this syntax exists.

In my opinion, the leading space is not a big enough time saver to
justify keeping it (particularly since it scales very badly--
preformatting two lines like that is easy, preformatting 100 is a PITA
without search & replace).

2) Why not think about some alternative link patterns? I've personally
always thought that double underscores might be cool. Compare:

   During the reign of [[Charles I of Spain|Charles I]], who inherited
   the throne from his father Philip, '''Habsburg Spain''' controlled
   territory ranging from [[Argentina]] to the [[Netherlands]], and was
   among [[Europe]]'s greatest powers. For this reason, this period of
   Spanish history has also been referred to as the "Age of Expansion."
   Although usually associated with its role in the history of [[Central
   Europe]], the [[Habsburg]] family extended its realm into [[Spain]]
   from [[1516]] to [[1700]]. Under Habsburg rule, Spain reached the
   zenith of its influence and power, but also began its slow decline.

vs.

   During the reign of __Charles I of Spain|Charles I__, who inherited
   the throne from his father Philip, '''Habsburg Spain''' controlled
   territory ranging from __Argentina__ to the __Netherlands__, and was
   among __Europe__'s greatest powers. For this reason, this period of
   Spanish history has also been referred to as the "Age of Expansion."
   Although usually associated with its role in the history of __Central
   Europe__, the __Habsburg__ family extended its realm into __Spain__
   from __1516__ to __1700__. Under Habsburg rule, Spain reached the
   zenith of its influence and power, but also began its slow decline.

The benefit of __ is that it makes the text look underlined, which is an
intuitive visual hint to hyperlinks--not to mention that having the
opening and closing characters be identical makes it quite a lot faster
to create links. (On German keyboards, underscores are also much easier
to type than square brackets, but that's probably not the case everywhere.)

2a) You suggest supporting [[target=foo|text=bar]] as a more descriptive
way of linking. However, I think [[foo<=bar]] or [[foo=>bar]] would be a
more visually intuitive way to indicate the text/target distinction that
does not require the use of keywords (it could, however, exist alongside
that syntax, particularly with your title attribute and perhaps other
link attributes that we might want to support, such as semantic
information).

3) The template syntax needs to be shorter, since it's ubiquituous.
People are not going to like having to type <<include NPOV>> where they
previously could type {{NPOV}}. If you're trying to make templates
easier to understand -- the biggest usability issue is not that people
don't understand that templates are transclusions, it's that the
content of "NPOV" is in the Template: namespace, but other than in the
list of templates at the bottom of the editing screen, there's no
reference to that namespace. I think that this is best addressed on the
UI level, though.

My suggested shorthand for inclusions would be <<"stub">>, <<"NPOV">>, etc.

4) We generally have to be careful with hiding namespaces from users.
<<image file:xyz.jpg>> may be better than <<image file=xyz.jpg>> or
<<image xyz.jpg>> because it preserves the visibility of the namespace.

5) The style syntax, I think, is the biggest problem area of your
proposal. I would actually prefer it to be taken out completely at this
point and developed separately, as it is also a significant new feature
with major implications. The main syntax-related problems I have with it:

a) This {{i may be {{b}}nested, as long}} reads horrible. Having styles
separated from words with spaces makes them look like words. They are
markup syntax, hence must be clearly visually distinct from the content
they describe.

I think the problem is exacerbated by shortcuts like {{i}}this, where
the scope of the tag is not intuitively clear, which may make it look
like it's not a tag at all. I don't really see this shortcut as
particularly useful either, as all frequently used styles should have
symbolix shortcuts anyway..

How could it be made simpler? An XML-like syntax might be the most
appropriate here: <red box>Warning!</red box>.

b) Using {{..}} creates *huge* transitional issues. Like it or not,
templates are deeply rooted into Wikipedia, and changing the function of
curly braces to something completely different will confuse the hell out
of many users who use that syntax every day.

c) In any case, curly braces are ugly and programmer-like. I'd much
prefer to get rid of them completely in our syntax.

There are other objections I have to using stylesheets, but as I said,
I'd prefer to discuss this topic separately from the syntax.

All in all, however, this is an excellent proposal with a lot of
potential. Transitioning to a new syntax will be painful, but the
wiki-users of tomorrow would greatly benefit from the added consistency,
not to mention that it will allow us to move towards standardization
across wiki engines as well. Before this is finalized, hopefully we can
also get some input from non-MediaWiki developers to find out what other
features we may want the syntax to support.

Best,

Erik


subject: [Wikitech-l] New syntax proposal

body:
On Sat, Jun 11, 2005 at 10:11:23PM -0700, Lee Daniel Crocker wrote:
> On Sun, 2005-06-12 at 01:55 +0200, Tomasz Wegrzanowski wrote:
>
> > Do you have any particular reason to allow only 5 levels
> > [of headings] ?
> > That breaks backwards compatibility and reduces range of
> > allowed options for no good reason.
>
> Wikitexts generally end up being rendered /within/ HTML pages,
> and HTML has a limit of six levels anyway, so it seemed safe.
> But I'm not married to it.  Are there really Wiki pages that
> use all six?  I'd be surprized if any really needed even five.

Results of quick grep of pl.wikipedia.org and en.wikipedia.org:

On a single page, 2 or 3 levels are typically used, sometimes 4,
and I haven't found even one with 5 in the grep.

Pages with big leaf sections tend to use level-range about
1 level higher than pages with small leaf sections,
probably for esthetic purposes, but they use the same
number of levels.

Levels 2-4 are most common, then 5 and 1, level 6 is rare.

So 4 is doable, but painful, 5 is necessary not to disturb current practice too much.
Throwng 1 more for special cases (like pages different from encyclopedia articles)
seems sensible, but if automatic conversion is provided, not doing so probably
won't cause too much troubles, at least for wikipedias.


subject:
[Wikipedia-l] Wikipedia, Copyright,
	Trademarks and British Military Crests

body:
David Newton wrote:

><snip: long detailed commentary>
>
>It seems to me that it would be a good idea to get in touch with them
>over this matter and find out what their policy with respect to the
>Wikipedia is. It is nice to have good quality illustrations of the
>crests from the RAF Marham website, but even if they do turn out to be
>copyvios, we need to sort out the issues with respect to trademarks.
>
>
It seems to me that what something is used for is far more important in
trademark law than in copyright law.  Whatever might be said about
copyright law in terms of a particular reproduction it can still be used
without violating trademark law.  In your material you quoted:

>But any such use otherwise than in accordance with honest practices in
>industrial or commercial matters shall be treated as infringing the
>registered trade mark if the use without due cause takes unfair
>advantage of, or is detrimental to, the distinctive character or
>repute of the trade mark.
>
Unless we are using the material in direct competition with these units,
or are creating confusion in the marketplace, or are pretending to be
them, or are treating them unfairly in a manner that brings them into
disrepute we come nowhere near to violating trademarks.  Where and how
do you perceive that we could be violating trademarks?

Copyright is a completely different manner.

Ec


subject: [WikiEN-l] CSS and underlined links

body:
David 'DJ' Hedley wrote:
> It may be a colourblindness issue for red links. If your colourblind you
> wouldn't be able to determine a red link from normal text.

Yes, there are problems with forcing in the other direction too, so
surely it's best to leave it to browser preferences?

--sannse


subject: [WikiEN-l] CSS and underlined links

body:
MacGyverMagic/Mgm wrote:
> I assume it was done because a lot of people hate a bunch of
> underlines in their text. Personally, it doesn't really bother me, and
> I can change it in my preferences anyway, so we might as well change
> it for outsiders.
>
> --Mgm

Wrong way round - we currently force underlining for everyone who hasn't
logged in and changed their preferences - that is, the majority of
people who use Wikipedia

--sannse


subject: [Wikitech-l] Re: possible interwiki solution

body:
Gerard Meijssen wrote:

> Hoi,
> Elly wrote a fine message about the increasing problems with interwiki
> links. Several people have answered on this threat indicating
> problems. I think I have an answer to the issues raised and I wrote
> them here http://meta.wikimedia.org/wiki/A_new_look_at_the_interwiki_link
>
> I believe that we can dispense with running the many client side bots
> for the interwikis and have a more economical server side bot in stead.
>
> I welcome all comments and I hope that there will be no arguments that
> prevent an implementation of this scheme.

This seems like a typical techomanic solution to the world's problems.
It assumes that each project will miraculously reach a perfectly
equivalent solution when faced with the same problem or challenge, and
that a babelwiki can bring them all together with a stroke of a magic
wand.  As much as I hate to use the Bible as a reference we have ample
experience that goes bach to the eleventh chapter of Genesis.

Using history as an example two pedias may easily decide that some
country's history be broken down chronologically.  Nevertheless, one may
divide that history into dynastic periods, while the other chooses to do
so strictly by centuries.  Neither group is likely to want to revise its
structure to accomodate the other, nor should it be required to do so.

Ec

PS: I appreciate the joke in the last sentence of your comments. :-)


from_name: Yann Forget

subject: [Wikitech-l] New syntax proposal

body:
Hi,

Le Sunday 12 June 2005 09:47, Ray Saintonge a ?crit :
> >
> >Actually, in the formal syntax I do fix this; spaces and tabs as the end
> >of input lines are removed, and /not/ interpreted.  What looks like an
> >empty line /is/ an empty line, so no invisible PRE section gets created.
>
> A leading space can be useful for poetry in Wikisource.

As you mention Wikisource, there is a need for a syntax for texts in verse.

Something like

<verse>
foo
bar
</verse>

which would replace

foo

bar

 is fine for a few line, it is NOT usable for books.

> Ec

Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


from_name: Pawe³ 'Ausir' Dembowski

body:
> Yes, they all can, as they learn Dutch proper only at school (and Frisian,
> for the Town Frisian speakers). But they have a certain pride of their
> languages, especially the Zealandic speakers, and I am pretty sure I can get
> some willing contributors behind a Wikipedia. (I won't even request it if my
> quest for other contributors fails!)
> Wouter

Same with Cashubians in Poland - the goal of Cashubian Wikipedia is
mostly preserving the language.

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


from_name: Thomas Gries

subject:
[Wikitech-l] Mailinglist business: auto-add link to the archived
	mail

body:
Hello,

I'd like to know, whether all mails sent here could **automatically**
have/show a link to the copy in the mail archive
such as in the example here:
---
(mock-up)
This is mail
http://mail.wikipedia.org/pipermail/wikitech-l/2005-June/030219.html


from_name: Dori

body:
On 6/12/05, Thomas Gries <mail at tgries.de> wrote:
> Hello,
>
> I'd like to know, whether all mails sent here could **automatically**
> have/show a link to the copy in the mail archive
> such as in the example here:
> ---
> (mock-up)
> This is mail
> http://mail.wikipedia.org/pipermail/wikitech-l/2005-June/030219.html

I second that it would be great if it were possible. It's a tad
annoying to hunt down a link to refer a message to someone  else.


from_name: Edward Z. Yang

subject: [Wikitech-l] New syntax proposal

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

Yann Forget <yann at forget-me.net> wrote:
> As you mention Wikisource, there is a need for a syntax for texts in verse.
>
> Something like
>
> <verse>
> foo
> bar
> </verse>
>
> which would replace
>
> foo

> bar

The HTML 4.1 recommendation (
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.3.4 ) seems to hint
that the tag PRE should be used for poetry (see their example). There's
still a few problems with it (like the monospace font), but nothing a
little stylesheet magic couldn't fix up.

- --
 Edward Z. Yang      Personal: edwardzyang at thewritingpot.com
 SN:Ambush Commander Website: http://www.thewritingpot.com/
 GPGKey:0x869C48DA   http://www.thewritingpot.com/gpgpubkey.asc
 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCrH+zqTO+fYacSNoRAgmyAJwMX2pjPrxHkFNmWCJiGnR9JpDIIACePz5g
izgDbgLTuSD01IN/d6d4TnY=
=zRDq
-----END PGP SIGNATURE-----


from_name: Jerome Jamnicky

subject: [Wikitech-l] Retrieving Articles for Mirror

body:
Eric Walker wrote:

> 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 object.  If we allow that, then the rest of the Wikipedia mirrors
would also see fit to do the same thing.  Given the number of mirrors
out there, this would likely be a severe burden.

 > 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?

This idea has been tossed around a bit, but currently it's not done.  It
would need somebody to draw up agreements, to do the sysadmin work, and
so on.

> 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.

Why not remote load from a Wikipedia mirror belonging to one of your SEO
colleagues?  You'd be dealing with someone whose mission is in line with
your own, and we'd have more of our time free to do something useful.

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


from_name: Anthere

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:
Dori a ?crit:
> 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.

Well, voting methods always have benefits or drawbacks.

Now, you can measure how many people really support a feature.
But no more.

Previously, you could mostly measure how much a feature was important to
those who voted for it. But you could also go see details and see how
many people really wanted it.

In a sense, results are easier to read now for you as they have only one
interpretation (number of supporters), while before they had two
interpretations (number of supporters AND degree of support). They are
easier, but far less informative. Perhaps a middle solution might have
been to allow between 1 to 3 points for each feature.

This said, as several mentionned here, it does not really matter
actually, as developers are volunteers and work on features they feel
like working on.

Recently, a journalist reminded me about wikimoney and asked me why I
think it failed. Well, most of us needs at the same time to work on
something that is fun for them and something useful for others. Possibly
first driven force is more important than second ;-)

Ant


from_name: David Newton

body:
I have some concerns about the interaction of trademark and copyright
law when certain military crests are reproduced on the Wikipedia.

>From what I understand the GFDL is intended to be a license dealing
with copyright. It says concerning this matter:

"You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no
other conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and
you may publicly display copies."

However, not all of the information that we deal with is covered
simply by copyright law. A lot of it is covered by trademark law. I
understand that US trademark law has a defence similar to fair use
under copyright law. From the British point of view the Trademarks Act
1994 states that for registered trademarks:

"10. - (1) A person infringes a registered trade mark if he uses in
the course of trade a sign which is identical with the trade mark in
relation to goods or services which are identical with those for which
it is registered.

(2) A person infringes a registered trade mark if he uses in the
course of trade a sign where
because -

      (a) the sign is identical with the trade mark and is used in
relation to goods or
services similar to those for which the trade mark is registered, or

      (b) the sign is similar to the trade mark and is used in
relation to goods or services
identical with or similar to those for which the trade mark is registered,

there exists a likelihood of confusion on the part of the public,
which includes the likelihood of association with the trade mark.

(3) A person infringes a registered trade mark if he uses in the
course of trade in relation to goods or services a sign which -

      (a) is identical with or similar to the trade mark, and

      (b) is used in relation to goods or services which are not
similar to those for which the trade mark is registered,

where the trade mark has a reputation in the United Kingdom and the
use of the sign, being without due cause, takes unfair advantage of,
or is detrimental to, the distinctive character or the repute of the
trade mark.

(4) For the purposes of this section a person uses a sign if, in particular, he-

      (a) affixes it to goods or the packaging thereof;

      (b) offers or exposes goods for sale, puts them on the market or
stocks them for those
purposes under the sign, or offers or supplies services under the sign;

      (c) imports or exports goods under the sign; or

      (d) uses the sign on business papers or in advertising.

(5) A person who applies a registered trade mark to material intended
to be used for labelling or packaging goods, as a business paper, or
for advertising goods or services, shall be treated as a party to any
use of the material which infringes the re gistered trade mark if when
he applied the mark he knew or had reason to believe that the
application of the mark was not duly authorised by the proprietor or a
licensee.

(6) Nothing in the preceding provisions of this section shall be
construed as preventing the use of a registered trade mark by any
person for the purpose of identifying goods or services as those of
the proprietor or a licensee.

But any such use otherwise than in accordance with honest practices in
industrial or commercial matters shall be treated as infringing the
registered trade mark if the use without due cause takes unfair
advantage of, or is detrimental to, the distinctive character or
repute of the trade mark."

The reason for my interest in trademarks over this matter is
specifically related to military units. There are a number of RAF
squadron and command logos that have been used on pages about those
units. Looking at the license terms of the site they come from, it
appears that they might be a copyvio. They come from the RAF Marham
website, which uses the Crown copyright notice about being freely
reproduced subject to being used accurately, not in a derogatory
manner and with an acknowledgement of source. The rub comes in the
terms and conditions of use for the actual crests themselves. The
terms state:

"This is a gallery of Squadron, Station and Section crests and RAF
badges available for personal use only, to anyone interested in crests
and badges. If you publish them on your website then please place a
link to this website, or include a reference to this website in your
literature."

I wrote an email to them pointing out the apparent dichotomy between
saying personal use only and talking about being published on websites
and asking them to clarify the policy. The reply was not particularly
helpful and said:

"The Gallery of Crests was initially created due to the large amount
of requests that we received for ex-Servicement looking for their
Squadron or Station Crests. This Gallery is primarily intended for
their use, not for use for financial gain. I believe the information
provided (below) will answer your questions."

The information that is referred to in that paragraph is links to the
RAF Marham copyright notice, the OPSI copyright guidance pages and the
MOD trademark use pages. Given what they have said I get the
impression that the usage restrictions they are referring to are from
trademark law. The MOD policy on the reuse of armed forces insignia
for reference purposes is as follows:

"Trade Mark law protects the identity of goods and services, allowing
distinctions to be made between different undertakings. Trade marks do
not necessarily need to be registered with the Patent Office in order
to be protected, although many MoD trade marks are. In the context of
the MoD, "trade marks" include all badges, crests, heraldry, logos and
other insignia used by the Armed Services and other MoD sections,
together with their names, mottoes and the names of any services they
provide.

These signs embody the reputation of the units they represent, and as
such their use is very tightly controlled under trade mark law.
Unauthorised reproduction is treated as a serious matter, as it can
amount to the appropriation of an organisation's reputation.

If you wish to reproduce insignia purely for as an illustration for
reference purposes, please contact the Directorate directly, at the
address below."

The address of the Directorate refered to is:

Directorate of Intellectual Property Rights,
MOD Abbey Wood #2218,
Bristol,
BS34 8JH
Tel: 0117 9132862. Fax: 0117 9132929.
E-mail ipr-cu at dpa.mod.uk

It seems to me that it would be a good idea to get in touch with them
over this matter and find out what their policy with respect to the
Wikipedia is. It is nice to have good quality illustrations of the
crests from the RAF Marham website, but even if they do turn out to be
copyvios, we need to sort out the issues with respect to trademarks.

David Newton


from_name: Mathias Schindler

body:
Dori wrote:

> I second that it would be great if it were possible. It's a tad
> annoying to hunt down a link to refer a message to someone  else.

speaking of "great". I would prefer if the archived mail was some kind
of wiki. the original mail would still be preserved in the history.

Mathias


from_name: Rowan Collins

subject: [Wikitech-l] New syntax proposal

body:
On 12/06/05, Erik Moeller <erik_moeller at gmx.de> wrote:
> All in all, however, this is an excellent proposal with a lot of
> potential. Transitioning to a new syntax will be painful, but the
> wiki-users of tomorrow would greatly benefit from the added consistency,
> not to mention that it will allow us to move towards standardization
> across wiki engines as well. Before this is finalized, hopefully we can
> also get some input from non-MediaWiki developers to find out what other
> features we may want the syntax to support.

This is something I forgot to mention - there is (or was) a bit of
discussion towards a standardised WikiMarkup a while ago:
* some discussion on MeatBall -
http://www.usemod.com/cgi-bin/mb.pl?WikiMarkupStandard
* a mailing list which seems to have died a quiet death, but to which
some people might be subscribed who would be interested in Lee's
proposal - http://www.freelists.org/archives/wiki/
* one result was the beginnings of a collection of existing markups -
http://interwiki.sourceforge.net/wms/summary.sxc

Indeed, it seems there's lots of stuff about that might be worth "tapping into":
* looking around, I found a more general "interwiki" list on which
people seem to have raised these kinds of issues -
http://sourceforge.net/mailarchive/forum.php?forum=interwiki-discuss
* ...from which I further blundered into
http://www.emacswiki.org/cw/MarkupStandardPlanB

I guess there's an almost unreadable amount of discussion "out there",
but what I was really looking for was places Lee could present his
ideas to non-MediaWiki folk if/when he feels they're ready.

--
Rowan Collins BSc
[IMSoP]


body:
This can be automatically done with a mail-to-wiki gateway. I developed
something for mediawiki, see [1, 2]

[1] http://bugzilla.wikipedia.org/show_bug.cgi?id=831 and
[2] http://bugzilla.wikipedia.org/show_bug.cgi?id=1675

See U in Frankfurt (Wikimania !)
Tom

Mathias Schindler schrieb:

> Dori wrote:
>
>> I second that it would be great if it were possible. It's a tad
>> annoying to hunt down a link to refer a message to someone  else.
>
>
> speaking of "great". I would prefer if the archived mail was some kind
> of wiki. the original mail would still be preserved in the history.
>
> Mathias
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>


from_name: Boris Lohnzweiger

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

body:
This looks like the most promising request for a new Wikipedia in months. I hope one of our developers will find the time to install it pretty soon. Good luck for your project!

Boris
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193


from_name: Arne Klempert

body:
On 6/12/05, Angela <beesley at gmail.com> wrote:
> I have started a FAQ about local Wikimedia chapters at
> http://meta.wikimedia.org/wiki/Local_chapter_FAQ with 10 of the
> questions that I know have been asked a lot.

I overworked the chapters page and would be glad if the people who are
involved in the creation of a chapter have a look at it and help to
make/keep it up-to-date:
http://meta.wikimedia.org/wiki/Wikimedia_chapters

Thanks.

Arne (akl)


from_name: Gerard Meijssen

body:
Hoi,
Elly wrote a fine message about the increasing problems with interwiki
links. Several people have answered on this threat indicating problems.
I think I have an answer to the issues raised and I wrote them here
http://meta.wikimedia.org/wiki/A_new_look_at_the_interwiki_link

I believe that we can dispense with running the many client side bots
for the interwikis and have a more economical server side bot in stead.

I welcome all comments and I hope that there will be no arguments that
prevent an implementation of this scheme.

Thanks,
    GerardM


subject: [Wikitech-l] New syntax proposal

body:
On 11/06/05, Lee Daniel Crocker <lee at piclab.com> wrote:
> 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'm a bit sceptical about having a "null" extension, too - the main
problem being that it is an example of "significant whitespace",
something you rightly (imho) rejected for pre-formatted text. "<<
image foo >>" looks too much like "<<image foo>> for my liking, so
having one be an image and the other a comment seems unwise. (I'm not
necessarily suggesting that "<< image foo >>" should include an image,
but having it visibly pass through as invalid would probably be
preferable to having it "vanish". Having *something* explicit for
saying "this is a comment" would therefore be a good idea.

Whether to use "<<comment foo>>" or "<<!foo>>", or something else,
touches on a larger question I already made about whether to go with
words or symbols to denote what "class" of inclusion is taking place.
As in, would "<<include foo>>" be better off as "<<+foo>>", etc. I
think such a carefully designed syntax should consider carefully which
approach to take (or exactly how to mix them), and to try and clarify
my thoughts, I've made a table with examples and comments, and placed
at http://meta.wikimedia.org/wiki/User:IMSoP/ext-markup [I wanted to
use wiki-markup :p]

--
Rowan Collins BSc
[IMSoP]


subject: [Wikitech-l] Re: bugzilla votes

body:
Anthere:

> In a sense, results are easier to read now for you as they have only one
> interpretation (number of supporters), while before they had two
> interpretations (number of supporters AND degree of support).

It's a very bad idea to use a rating system with a large scale (e.g.
from 1 to 1000), as everyone will use it differently and the average
becomes meaningless (as does the individual vote unless you look at that
person's entire voting record). The other problem was that, due to the
terminology "vote", many people were likely to assume that they only had
a single vote.

A 1-5 rating system (without the term "vote") would probably be optimal,
but the current solution is a big improvement to make the statistics
more meaningful, which will be useful to the Research Team.

Best,

Erik


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.
>
> Well I was thinking along the lines of an extesion like <unit>3
> m</unit>

For how to do this, see:
http://meta.wikimedia.org/wiki/Write_your_own_MediaWiki_extension

--
Rowan Collins BSc
[IMSoP]


subject: [Wikipedia-l] Re: Enciclopedia Libre

body:
> On 10/06/05, Lars Aronsson <lars at aronsson.se> wrote:
> > 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.

On 10/06/05, Mark Williamson <node.ue at gmail.com> wrote:
> If they're so innocent, why would they be hurt by "half-sung songs"?

Because, as Lars' seemingly unnecessary rebuttal showed, it's
impossible to distinguish between you being mistaken in your facts
about someone and the facts being correct but about someone else. In a
sense, it means no-one can deny your claims, because they don't know
whether you're talking about them or not - they either have to
silently suspect you mean them, or risk giving you ammunition to say
"I wasn't thinking of you, but...".

--
Rowan Collins BSc
[IMSoP]


body:
On 11/06/05, Eric Walker <email at owlcroft.com> wrote:
> 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.

Just a quick note that although the markup itself is fairly
ill-defined, many attempts have been made to make tools which
"understand" it to some extent or another. If you haven't already, it
might be worth looking at
http://meta.wikimedia.org/wiki/Alternative_parsers

--
Rowan Collins BSc
[IMSoP]


from_name: Quistnix

body:
Gerard Meijssen wrote:

> Hoi,
> Elly wrote a fine message about the increasing problems with interwiki
> links. Several people have answered on this threat indicating problems.
> I think I have an answer to the issues raised and I wrote them here
> http://meta.wikimedia.org/wiki/A_new_look_at_the_interwiki_link
>
> I believe that we can dispense with running the many client side bots
> for the interwikis and have a more economical server side bot in stead.
>
> I welcome all comments and I hope that there will be no arguments that
> prevent an implementation of this scheme.

If you do: check that Gerard doesn't delete or move them. He has been
known to do that.

Anton


subject: [WikiEN-l] CSS and underlined links

body:
On 11/06/05, sannse <sannse at tiscali.co.uk> wrote:
> We had an email asking why we override browser defaults to underline
> links.  I've asked about this at
> http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css , but am not
> sure how much that is watched.  Any comments would be most helpful there.

As I understand it:
* some people voted, a long time ago, to keep underlines (or, rather,
"use browser default") -
http://meta.wikimedia.org/wiki/Link_style_vote

* when 1.3 came out, with the spangly new MonoBook skin, it included
non-underlined links, and people complained -
http://meta.wikimedia.org/wiki/MediaWiki_1.3_comments_and_bug_reports/Archive#Underlining_of_links

* the skin as distributed with the software still has them
non-underlined by default (underline on hover), and indeed most
Wikimedia projects leave them as such, but "by popular demand", the
English Wikipedia overrides this in its global stylesheet

Whether that makes it the *right* thing to do, I've no idea.

[On a technical note, I can't quite work out how the user preference
toggle for this works, but it might be cleaner to have this set as a
default preference rather than explicit in the stylesheet]

--
Rowan Collins BSc
[IMSoP]


from_name: Sean Barrett

subject: [WikiEN-l] Arbitration Committee Seeking Comment

body:
Jimmy Wales stated for the record:

> steven l. rubenstein wrote:
>
>>Moreover, no one has mentioned "unpopular" content and Sean is just
>>waving a red herring to distract us from a serious problem.
>
> I fully and totally agree with every bit of this.
>
> --Jimbo

Wow.  I am such scum.  Let this be a lesson to me.

--
  Sean Barrett     | Of course, misunderstanding or misrepresentation
  sean at epoptic.com | is something Sean is well-practiced at.
                   | --Associate Professor Steven L. Rubenstein


from_name: Lee Daniel Crocker

body:
On Sun, 2005-06-12 at 20:01 +0200, Jimmy Wales wrote:
> > Please make it an extension and not part of the core syntax.
>
> Please do not include it in MediaWiki at all.
> This is my opinion.  I defer to the judgment of others.  But I think it
> is a perfectly awful idea.

I don't think it's a good idea for Wikipedia, but I can see the
possibility that it might be useful for other special-purpose
wikis using the Mediawiki software.

That's another one of my ulterior motives for cleaning up the
extension syntax. The Mediawiki software is already suffering
from some serious feature creep, and its use at other sites is
only going to increase that pressure. I'm hoping that giving
the feature-hungry masses a way to add some whizbang to the
software that we at Wikipedia can choose to ignore may appease
them a bit.

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


from_name: sannse

subject: [WikiEN-l] CSS and underlined links

body:
ah, that's helpful Rowan - it was that meta page that I couldn't find.

Many thanks

--sannse

Rowan Collins wrote:
> On 11/06/05, sannse <sannse at tiscali.co.uk> wrote:
>
>>We had an email asking why we override browser defaults to underline
>>links.  I've asked about this at
>>http://en.wikipedia.org/wiki/MediaWiki_talk:Monobook.css , but am not
>>sure how much that is watched.  Any comments would be most helpful there.
>
>
> As I understand it:
> * some people voted, a long time ago, to keep underlines (or, rather,
> "use browser default") -
> http://meta.wikimedia.org/wiki/Link_style_vote
>
> * when 1.3 came out, with the spangly new MonoBook skin, it included
> non-underlined links, and people complained -
> http://meta.wikimedia.org/wiki/MediaWiki_1.3_comments_and_bug_reports/Archive#Underlining_of_links
>
> * the skin as distributed with the software still has them
> non-underlined by default (underline on hover), and indeed most
> Wikimedia projects leave them as such, but "by popular demand", the
> English Wikipedia overrides this in its global stylesheet
>
> Whether that makes it the *right* thing to do, I've no idea.
>
> [On a technical note, I can't quite work out how the user preference
> toggle for this works, but it might be cleaner to have this set as a
> default preference rather than explicit in the stylesheet]
>


from_name: Jimmy Wales

body:
Sean Barrett wrote:
> I am very worried that we are seriously discussing the formation of a
> committee empowered to prohibit unpopular content from Wikipedia and to
> ban those that feel that it is important to record it.

I don't think that's what we are discussing.

There are dedicated POV warriors who know how to stay within our
behavior rules, and they camp out on articles to make sure they continue
to say the same POV things.  This is a bannable offense, as well it
should be.  But it is quite difficult for the ArbCom to assess by
themselves.  Usually we have been able to deal with this by focussing
strictly on behavioral issues (3 revert rule, for example, or the fact
that many POV warriors have other personality problems that give us
other reasons to ban them).

Slim Virgin very astutely identified this problem a few months back:
there are people who can write in a pseudo-NPOV way about complete
nonsense, and when other editors -- who are not experts in the area --
are asked to come and help, they have a very hard time sorting out what
is going on.

I see no problem with empowering the ArbCom in such cases to call on
some outside opinions to help understand the facts of the case.

--Jimbo


body:
Sean Barrett wrote:
> Fred Bauder stated for the record:
>
>> There is also the question of whether it is  reasonably convenient to
>> access it. For example, a NYT's article  might cost 2 bucks but
>> something that requires accessing Nexus or  consulting an obscure
>> journal is much more expensive.
>
>
> So material from an "obscure" journal is less acceptable?  I guess my
> digging into old Soviet naval records for information about their
> nuclear submarines is a waste of time.

I think Fred made a tiny error in using the word "Obscure" here, but his
basic point is certainly valid.  A physics journal published by Harvard
University and widely consulted and cited by physicists is a valid
source -- an obscure website published by the Flat Earth Society is not.

Assessing whether or not sources are valid is well within our range of
competence in most cases.

--Jimbo


body:
steven l. rubenstein wrote:
> Moreover, no one has mentioned "unpopular" content and Sean is just
> waving a red herring to distract us from a serious problem.  In one of
> my own messages -- here or at the project page -- I pointed out that one
> use of such a committee is to ensure that the content is being presented
> in an NPOV way, or to ensure that the sources are properly represented.
> Anyone can assert something and cite a book.  But in some cases readers
> need to know whether the author of that book was published by a
> university press, a trade press, or a vanity press, or whether the book
> was written by someone with a PhD. in Biblical Studies or Geology.  You
> might think that disputes revolving around such questions would be easy
> to resolve, and of course, in many cases, they are.  But sometimes they
> are not, and there is a need for some mechanism to arbitrate content.

I fully and totally agree with every bit of this.

And I repeat very very firmly that I will never support _popular voting_
as a substitute for doing this kind of serious work to get things right.

--Jimbo


body:
Tony Sidaway wrote:
> Fred Bauder said:
>
>>Folk with eccentric points of view such as splinter political parties
>>often maintain websites and sometimes even publish books.
>>
>
> Then those websites and books are pretty good references for their
> opinions.  I don't see a problem here.  A flat earth society website is an
> excellent reference for a description of the views of that society.

Strawman argument.  No one is suggesting that we can't refer to such
source _for a description of their views_.

What we must say, if we are to be serious at all, is that the views of
the flat earth society are totally inappropriate for a serious article
on serious scientific views of the world.

This case is easy, but other cases are not so easy.

It will be quite useful for us to have some mechanisms to fairly and
seriously assess such matters.

--Jimbo


subject: [WikiEN-l] Arbitration Commitee Seeking Comment

body:
Erik Moeller wrote:
> You appear to be operating under the assumption that someone not
> interested the least in quantum physics would participate in a vote on
> whether this or that study result should be included in an article about
> it. This does not seem very likely to me.

Nor to me.  But this is one of the problems.  Most of us aren't
interested in pedophilia.  Pedophiles are.  Let's hold a vote on what
the pedophilia articles should so, a vote on which references are valid,
and see what happens.

Instead what we should do is use serious judgment to determine how to
find out which references are valid, and rely on those judgments.  We
can consult with psychologists and sociologists and get an idea of
whether or not a particular user is acting in good faith or just citing
crackpot sources to push a POV.

> Wikipedia has always been based on the idea that you can trust
> reasonable people to do the right thing, and that the unreasonable ones
> will be a minority that we can deal with. I think that principle should
> be applied here as well.

Indeed, I think that no one really questions this.  The real question is
whether a formal voting process is the right way to deal with it.

--Jimbo


body:
Erik Moeller wrote:
>I think
> there are community-based approaches that are not as susceptible to
> error and corruption and that therefore should be preferred.

And I think it is a serious mistake to suggest that his approach is not
"community-based".

"Community-based" means a lot more than "hold a vote".

--Jimbo


body:
Daniel Mayer wrote:
> Exactly. All I want are groups of people that the ArbCom can consult to help it
> determine just who is and is not following our content-related policies like
> NPOV and NOR. Going back to an old example; I simply don't know enough about
> advanced mathematics to know if a person is pushing a POV in that area or is
> engaging in original research except in the most blatant of cases. It would
> help arbitration a great deal if the ArbCom could ask a panel of non-involved
> and vetted users who *could* tell one way or the other.

I think this is very well stated.

--Jimbo


subject: [Wikipedia-l] Re: Enciclopedia Libre

body:
Mark Williamson wrote:
> 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.

I would like to say that I share Lars distaste for you making criticisms
that might be about any number of people in such a backhanded way.  If
you want to criticize someone please just say the name so we can know
what you're talking about.

--Jimbo


body:
?var Arnfj?r? Bjarmason wrote:
> Please make it an extension and not part of the core syntax.

Please do not include it in MediaWiki at all.

This is my opinion.  I defer to the judgment of others.  But I think it
is a perfectly awful idea.

--Jimbo


body:
Brion Vibber wrote:
> Eric Walker wrote:
>

...

>>
>> "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"?
>
>
> Generally, if your volume's big enough to be noticed leeching page views
> and searches off our main servers, you've got a fair chance of being
> blocked. (I seem to remember hearing something about the search engine
> being hit in this case, but I may be thinking of something else.)

Yes, omniknow.com uses Wikipedia's search, for example fetching this:

http://omniknow.com/common/search.php?in=en&redo=NO&text=aleech&submit.x=0&submit.y=0

results in this request on Wikipedia:

209.68.1.165 - - [12/Jun/2005:03:29:09 +0000] "GET
http://en.wikipedia.org/wiki/Special:Search?search=aleech HTTP/1.0" 403
1486 "-" "-"

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


body:
On 6/12/05, Ray Saintonge <saintonge at telus.net> wrote:
> David Newton wrote:
>
> ><snip: long detailed commentary>
> >
> >It seems to me that it would be a good idea to get in touch with them
> >over this matter and find out what their policy with respect to the
> >Wikipedia is. It is nice to have good quality illustrations of the
> >crests from the RAF Marham website, but even if they do turn out to be
> >copyvios, we need to sort out the issues with respect to trademarks.
> >
> >
> It seems to me that what something is used for is far more important in
> trademark law than in copyright law.  Whatever might be said about
> copyright law in terms of a particular reproduction it can still be used
> without violating trademark law.  In your material you quoted:
>
> >But any such use otherwise than in accordance with honest practices in
> >industrial or commercial matters shall be treated as infringing the
> >registered trade mark if the use without due cause takes unfair
> >advantage of, or is detrimental to, the distinctive character or
> >repute of the trade mark.
> >
> Unless we are using the material in direct competition with these units,
> or are creating confusion in the marketplace, or are pretending to be
> them, or are treating them unfairly in a manner that brings them into
> disrepute we come nowhere near to violating trademarks.  Where and how
> do you perceive that we could be violating trademarks?
>
> Copyright is a completely different manner.
>
> Ec
>
>

The thing that worries me is the intertwining of copyright and
trademark law in this case. It is not clear whether the additional
restrictions on the logos, as compared with the rest, on the RAF
Marham website are due to copyright law or to trademark law. The reply
to my email to the RAF Marham webmaster in this case suggests to me
that we are dealing with trademark law.

The reason I am concerned over trademarks is not the usage of the
logos as they currently are: when they are used as infoboxes or
otherwise as illustrations in serious articles about  the units and
formations concerned. What concerns me is that a vandal might link the
image into an entirely different and dodgy article, and that it might
be unnoticed. That would be skating perilously close to a violation of
trademark law. It also applies to many other, equally or even more
prominent, registered trademarks. What I would ideally like to be the
case is to get a much more exact statement of what can be done with
trademarks than is currently in place in the Wikipedia. Just as we
have copyright tags for images, a couple of which do mention trademark
law, I think it would probably be a good idea to have trademark tags,
setting out the restrictions on what may be done with the image
according to that law. We would obviously need two types of tag;
registered and unregistered trademarks, and naturally this would have
to be based on US law since that is where the servers are.

Another matter that I have searched the internet for is how trademarks
interact with the GFDL. That explicitly says that images under that
licence cannot be distributed in a more restricted way than with the
licence. That would seem to mean that images of trademarks cannot be
licensed under the GFDL, since trademark law places restrictions on
their usage beyond those of the GFDL. The images in question from RAF
Marham are not under the GFDL, but again it is something that needs to
be considered.

I am not saying that the Wikipedia is breaking trademark law. The
disclaimer does a pretty good job of mitigating that danger. What I am
saying is that trademark law is a potentially dangerous minefield for
the Wikipedia. I understand copyright law a good deal better than the
average person since I have had to make a study of it in running a
website, but I am not particularly familiar with trademark law beyond
its most basic concepts (ie that a trademark must be defended, that it
covers only certain fields unless it is very, very well known etc). I
think something that is particularly dangerous, and under-explored, is
the interaction of trademark law with virial licences like the GFDL,
since they are worded in such a way that they could potentiall come
into that area.

I hope I am being paranoid about trademarks on this occasion.

David Newton


from_name: Wouter Steenbeek

body:
>Wow!
>
>You guys really drummed up support quickly!
>
>Yes, please, we should have the Cebuano Wikipedia created right away.
>
>It's high time we have Wikipedia in the non-Tagalog languages of the
>Philippines, many of which are spoken by millions.
>
>Mark
>
Hear, hear!

And let's pray we can expect more new succesful non-western Wikipedias in
the near future, or hope for the animation of many of those dormant
wikipedias!

Wouter

_________________________________________________________________
Nieuw: Download nu MSN Messenger 7.0 http://messenger.msn.nl/


from_name: Eric Walker

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

[parts elided for brevity]

>If your site doesn't appear to violate the content license, and
>you follow earlier suggestions about caching data (preferably
>backed by your own local copy to begin with) and you limit your
>hit rate and don't abuse our search engine or other tools, you
>probably won't get blocked.

I have been scrupulously careful about the license terms, and even
provide a link (and suggestion text for it), on every page, to the
Wikimedia Foundation fund-raising page.  (Incidentally, I repeat
that this is not a dead-exact mirror, in that each topic page also
includes the dmoz links, if any can be found, for that topic, thus
providing--so far as I can determine--a unique value-added page.)

I also have in place (beside a Crawl-delay: 5 statement in the
robots.txt file) a throttler that blocks any entity trying to
exceed thast 5-second limitation for longer than a half minute or
so, so as to keep ill-behaved searchbots (or email harvesters) from
rapid attacks.

>We run our web site, not yours, and if our system administrators
>feel your site's eating more load than it should it may well get
>cut off at some point.

I understand and completely agree.  Had I known any of this before
starting up, I would have gone about things in a very different
manner.  My problem--not, I agree, yours, but I am just *asking*
for a little help, not trying to demand anything--is not that I
don't want to or won't convert to a local system using database
dumps; I will, _but_ this is an ongoing project, and it will no
doubt take me some little time to learn enough to set up and
operate a database system and the associated software, matters of
which I am at present wholly ignorant.

>A general recommendation for remote loading:  if you're not
>already doing this, always use a relevant user-agent string which
>identifies your site well enough that the other site's admins can
>find and contact you.  (Including an e-mail address is strongly
>recommended; an URL might be insufficient if your site is being
>slashdotted or DoSed.)

Thank you for the idea; I have now added a "From: " header giving
my email.

So, again, I wonder if, should I manage to quickly adapt or invent
a usable parser and take files "on demand" (as visitors hit a
topic) purely via XML, at least for the time--which could be a
while--that a crash course in database management and some
associated things takes me, would I be allowed to operate?

I have begun working on such a parser (I discovered that trying to
adapt the existing ones is likely more work than starting anew); I
have asked the sysadmin I first dealt with, via email, if I could
have a "grace period" of about a week to continue as I have been
for the past several months while I develop and test a parser and
switch to XML exports, after which I will begin trying to set up a
full dump-based back end, which, as I say, will be quite a learning
process.  But I thought it best to also make that request here, so
as to not seem to be trying to go around the community in any way.

Should I be allowed the grace period (I suggested this coming
Friday, but time having gone by, I would ask instead for this
coming Sunday), would someone lift the current block?

I apologize for the time this thread is taking, but I have acted in
good faith, if, it appears, in ignorance.  I want to get into full
compliance as soon as I can, but I am praying that I will not be
knocked wholly off the air till I can accomplish that.


from_name: Thomas Gries

subject: [Wikitech-l] Minor bugbear fixed: newtalk notification

body:
Tim:

as I wrote in [1]

"fully reestablished memcache-efficient user_newtalk table,but only for the newmessage marker."

Please consider to commit this bugzilla (patchlet #1) - I have told you this several times, but the collaboration were stoped from your and Brions side with saying that I shall concentrate on other issues.
The patchlet #1 solves the problem you are referring to (at least in my reference implementations and implementatation of other people).

Tom

[1] http://bugzilla.wikipedia.org/show_bug.cgi?id=2014 published 26
April 2005

Tim Starling schrieb:

>Everyone's seen the "sticky" newtalk notification problem -- that ugly
>orange box hangs around for longer than it's meant to and can be hard to
>get rid of. I fixed one cause of this: the client cache. We've always
>had a system to invalidate the client cache when the newtalk status
>changes, but it was broken shortly before 1.4 was branched and nobody
>noticed. I'm pretty sure it's now fixed.
>
>The changes were inapplicable to HEAD, since newtalk handling has
>changed completely. It will need to be tested separately.
>
>-- Tim Starling
>
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>
>