from_name: Dan Libby

subject: [Wikitech-l] Re: MediaWiki OpenID patch

body:
Brion Vibber wrote:
> Dan Libby wrote:
>
>> 1) this patch piggy-backs on top of SpecialUserlogin.  So if a username
>> contains "://" or '." then the OpenID code kicks in.  This does not
>> provide any sort of possibility for other login types, eg LID.  Also it
>> would break any pre-existing logins with those strings in them.
>
>
> The . check would break... 12579 registered usernames on
> en.wikipedia.org. :)

Ouch.   So clearly a better solution is needed for the user to specify
which type of Login system to use.

I've seen a couple sites that have a dropdown selector on the login page
for the user to pick the login type.  That seems pretty clean to me.

>
>> 2) MediaWiki insists on upper-casing all titles, including usernames.  I
>> worked around that for actually storing the username, but it still
>> happens for display,which looks kinda nasty for eg:
>> "Http://danda.videntity.org/".    I'm not sure how to get around that as
>> the title normalization stuff is a bit, umm, inscrutable.
>
>
> Using URLs for usernames is going to be inherently broken on the wiki,
> as accounts are closely tied to their user pages on the wiki. To be
> non-broken, the usernames need to be real, valid page titles. There are
> many valid URLs which are not valid titles, and trying to use them like
> that is I think going to be a tangle of ugliness, special cases, and
> identifiers which won't be able to login despite having a valid OpenID
> system.

I worked around this issue by forcing URLs to always use the "?title="
format if the title contains "/".  Otherwise there were problems with
Apache (php?) munging "//" in the PATH_INFO variable into "/".

It was a pretty simple check in Title::getLocalURL(), not much of a tangle.

afaik, user talk pages are working fine for OpenID logins.

Also, that seems like an issue that would affect any titles with "//",
but probably it is not a common case so possibly no one has run into it yet.

> There are basically two ways you can go I think:
>
> 1) OpenID identifiers are a special class of users and handled
> distinctly, like anonymous IP addresses are.

Interesting.  I wasn't aware of the distinction.

> Some mechanism for displaying properly formatted names and for picking a
> not-too-illegible title for the user page / talk page would need to be
> added to the core code.
>
> Every place that takes a username in input, displays a username in
> output, or tries to make a user page link would need to change. (That's
> not that bad an idea, though; consolidation of duplicated code would be
> good and other external authentication systems could use this same
> ability.)
>
> -or-
>
> 2) OpenID identifiers can be used to authenticate a named account in
> place of a password, but you have to pick a valid username name and
> create an account. (This could be as simple as confirming an automatic
> transformation of the OpenID identifier or choosing to change it during
> your first login.)
>
> Easy, but of course not as 'cool'. :)

I'm not sure it is so easy actually.

This approach would seem to defeat much of the benefit of OpenID if it
is not automatic.  Who wants to login with their universal ID only to
have to choose a local ID?

The difficulty with an automatic approach is guaranteeing a transform
that looks nice and yet is still unique.  For plain http:// urls, you
can get rid of the "http://" portion because it is assumed, but you
can't do that if the url starts with "https://".


list: wikien-l

source: pipermail-mbox

from_name: Justin Cormack

subject: [WikiEN-l] a valid criticism

body:
On 7 Oct 2005, at 22:25, Kat Walsh wrote:
> I disagree on this, and I wonder why so many people state it: a good
> encyclopedic article on a broad subject I am only casually acquainted
> with is very useful, and in fact Wikipedia is often the first place
> I'll turn. There are plenty of basic subjects for which I do not know
> most of the information contained in a decent encyclopedia article;
> I'd imagine this is true of most people. (Granted, I didn't go to a
> particularly good school, but even so!)
>
> But even if it is only a stopping-off point -- how will readers find
> the niche subject they really want to find if the main article does
> not lead them there by framing it with appropriate context and general
> information to let them know which subtopic they are looking for? If
> [[dog]] were so lacking as not to say that a young dog is a puppy and
> that the breed that ran by was probably a retriever, it wouldn't be
> much to step off from.

I think there are a lot of usage patterns. Looking at a few kind of
obvious gateways, they have a tendency to degenerate into lists (eg
[[Beer]] that was demoted from FA, [[Architecture]] is terrible, written
like a bad essay with a ==Conclusion== section). In fact the
architecture
Portal is better, much better (the main problem is the pointltess
list of
other portals which just wastes space). Maybe these shouldnt be
turned into
FAs at all, just something more portal like. Brittanica used to
have Micropaedia and Macropaedia in the later print volumes to organise
on different levels.

Justinc


list: wikitech-l

subject: [Wikitech-l] Re: MediaWiki OpenID patch

body:
?var Arnfj?r? Bjarmason wrote:
> Regarding your comments in the patch regarding on the usernames we
> restrict: We require usernames to be upper case for future
> compatability with single login.
>
> Anyway, have you considered making this an extension? (see
> docs/hooks.txt), I looked it over and found that it would be trivial
> to do all this through $wgHooks by sprinkling a few wfRunHooks();

I'd be happy to make it an extension if someone can define and add the
necessary hooks.

I'm curious if anyone has looked at how I added processLogin() to
AuthPlugin() in order handle multi-page authorization sequences.  I
imagine your LID patch must do something similar, eh Johannes?

There is still the matter of how to determine that the current login
should be processed via OpenID ( or LID, or... ) rather than by the
normal MediaWiki  login handler.  Checking for '.' in the login was a
temporary hack.  I suppose that each login-type could have its own login
page, but that still leaves the question of how/where the user chooses
the login type.


subject: [Wikitech-l] Re: MediaWiki OpenID patch

body:
Johannes Ernst wrote:
> On Oct 6, 2005, at 19:50, Brion Vibber wrote:
>
>
>> Using URLs for usernames is going to be inherently broken on the wiki,
>> as accounts are closely tied to their user pages on the wiki.
>>
>
> We've been doing some work integrating LID (the "other" URL-based
> digital identity system) with WikiPedia, and while ugly, even user  talk
> pages work surprisingly well with very few changes, for the LID  URLs we
> tried so far. I guess that will be the same for Dan and  OpenID. The
> MediaWiki code is more robust than we thought ;-)

Johannes, I'll be interested to see your patch when ready.  Possibly we
can come up with a common framework, where OpenID is one login handler
and LID is another.

I wonder if you've had a chance to evaluate my patch for areas of
commonality?

>> Some mechanism for displaying properly formatted names and for  picking a
>> not-too-illegible title for the user page / talk page would need to be
>> added to the core code.
>>
>
> The issue here is privacy and what follows from there. Within LID,  for
> example, we have extensive facilities for voluntary "profile data
> exchange" (see the LID MediaWiki ;-) at http://lid.netmesh.org/ wiki ),
> so it's very straightforward to determine what VCard calls  the
> "Formatted Name" for a user, but experience shows that people  don't
> necessarily want others to see their real name in public places  such as
> Wikipedia.
>
> Also, there is a namespace issue. The reason DNS is hierarchical is
> that there are simply too many things that need to be named to be in
> one, flat namespace. As Wikipedia grows to, say, include every  graduate
> student ever (kindergartener?), how realistic is it to stay  with a
> single-level name space? And the whole point of OpenID, LID,  and all
> the internet-scale identity efforts is to get away from local
> pseudonyms that need to be invented because somebody else took  john.doe
> already at that site.

Right.  Well URLs are in a universal namespace, and are unique.  So as
long as we store/display URLs, I think it should be fine, no?

> I'm afraid that I don't have a full-fledged answer here (not sure
> anybody does), except for the maybe-not-so-trivial one: what if users
> with REST-ful outside identifiers don't get a talk page?!? Chances  are
> that their REST-ful identifier actually refers to their blog, or  some
> place where people can leave comments ... Other than User:xxx,  where
> else would something break? It's easy to format, say,  SpecialListusers
> differently if it is a URL ...

I don't understand what is so special/difficult about the talk page?
Yes, there is a problem with "//" in the PATH_INFO.  It can be worked
around using "?title=<encoded url" format.  Am I missing something?

>> 2) OpenID identifiers can be used to authenticate a named account in
>> place of a password, but you have to pick a valid username name and
>> create an account.
>>

> Account federation with local pseudonyms... let's not do that, it's a
> kludge and not worth the effort ...

agreed.


from_name: Brion Vibber

subject: [Wikitech-l] Re: MediaWiki OpenID patch

body:
Dan Libby wrote:
> I worked around this issue by forcing URLs to always use the "?title="
> format if the title contains "/".  Otherwise there were problems with
> Apache (php?) munging "//" in the PATH_INFO variable into "/".

That's an issue with Apache 2. There's a patch which tries to work
around it by re-obtaining the URL data from another place in bugzilla
somewhere, not sure how ideal it is.

Certainly forcing an alternate URL is suboptimal. :)

-- 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/20051007/439f471c/attachment.pgp>


from_name: Alphax

subject: [WikiEN-l] a valid criticism

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

Tony Sidaway wrote:
> On 10/7/05, Alphax <alphasigmax at gmail.com> wrote:
>
>>
>>Tony Sidaway wrote:
>>
>>>On 10/7/05, Alphax <alphasigmax at gmail.com> wrote:
>>>
>>>
>>>>{{sofixit}}
>>>>
>>>
>>>That's one possible way to react. Another way would be to consult
>>>Encarta's entry on the same subject.
>>>
>>
>>I doubt they even have one.
>>
>
>
> Where do you think I got the information that was omitted from the Wikipedia
> article?
>

What? You looked at Encarta? Traitor! :P

- --
Andrew Cranwell StudIEAust  |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ0Z7n7MAAH8MeUlWAQhdHgf/cmPrcMbC87X8gzvlUvCKQVd3x512CzVC
USMPNDPZobuCypAuVxT7SmvFhOKuM0R4NtDjnBqdVZ+h/SVN2TfsMk/KXrBzhnZx
VF15/rPDYwgdpIN4rvDoiLWYyk1d8Q9SRBWB2v+OmM36kZGSQTsTSPoWKgIooYh9
gxinDdCGpNQw2yZ3M1B8xoRmmmG0C3l2Kk6Ny3KjOvXyeOvKciCJyNLJIpFqOJ8Z
ZpwnVEZUg6wmc5InBd8B6f63VaIs/ncoIpwym2AJQkuRAXKyXdZ0zYy8Mh/Kiqxh
e19ff+fKAkQNLhruLOsHYAEXpOdCY/33XiK7VtmAqXjx8xONJMrKrw==
=sPEe
-----END PGP SIGNATURE-----


from_name: Derick Rethans

subject: [Wikitech-l] PHP 4.4.1RC1 testing

body:
Hello!

You are receiving this email because your project has been select to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we hope
to make sure that you are either aware of things that might break, or to
make sure we don't introduce any strange regressions. With this effort
we hope to build a better relation between the PHP Team and the major
projects.

If you do not want to receive these heads-up emails, please reply to me
personally and I will remove you from the list; but, we hope that you
want to actively help us making PHP a better and more stable tool.

The first release candidate of PHP 4.4.1 can be found at
http://downloads.php.net/derick/ . If everything goes well, we hope to
release PHP 4.4.1 at the start of the week in which October the 17th
falls as there are certain critical issues that are solved in PHP 4.4.1.
If you find any issues, please contact the PHP QA team at
"php-qa at lists.php.net".

In case you think that other projects should also receive this kinds of
emails, please let me know privately, and I will add them to the list of
projects to contact.

regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org


from_name: Elisabeth Bauer

subject: [WikiEN-l] a valid criticism

body:
David Gerard wrote:

> http://en.wikipedia.org/wiki/Wikipedia:List_of_articles_all_languages_should_have
>
> I created the above page for this specific purpose - en: has all these
> articles (or something like them), but very few are up to featured
> quality.

Just a suggestion from another language in the wiki empire:
In german wikipedia, we just started the winterspeck campaign
(http://de.wikipedia.org/wiki/Wikipedia:Aktion_Winterspeck) which is
dedicated to improving important articles in all areas.

So far, participation and progress is quite good.

greetings,
elian


from_name: Tony Sidaway

subject: [WikiEN-l] a valid criticism

body:
On 10/8/05, Geoff Burling <llywrch at agora.rdrop.com> wrote:
>
> On Fri, 7 Oct 2005, Magnus Manske wrote:
>
> > Jimmy Wales wrote:
> >
> > >
> > >But it's really not joyful to see bad writing in two very prominent
> > >articles.
> > >
> > >
> > Just as a reminder, there *is* a validation/rating/whatever-you-call-it
> > system sitting in MediaWiki for month, waiting to be tested.
> >
> I'm attaching this to Magnus' email not so much as a response, but to
> throw out an idea for allowing us to put this into testing, & hopefully
> production.
>
> As I understand, the issue why this feature has not been enabled on
> Wikipedia is because of the load it would put on the servers: keeping
> track of another mesh of tables with the validation values for every
> revision of articles would bring the system to its knees.
>

Perhaps someone could explain to me, from the point of view of a developer,
why it would affect wikipedia *at all* if there was a javascript function to
send an encrypted response carrying a user's rating of an article to a
*separate* server.

The rating function would not have to operate in real time. With good
design, it wouldn't ever even have to be synchronized. As long as the
article name, wikipedia language, and datestamp for the rating were
recorded, the two servers could be on different continents.


subject: [WikiEN-l] a valid criticism

body:
Jimmy Wales wrote:

> I do not think that the fact that Jane Fonda and Bill Gates are
> controversial figures is the real answer here, by the way.  They are,
> but the problems I'm complaining about in the articles is not that they
> are biased, nor that they focus too much on the controversies, etc.
>
> It's that they are badly written.  A confusing mishmash of random facts
> not shaped into a coherent whole.  Others have written eloquently on
> this, and on why this might be the case.  The puzzle, though, is: what
> can be done about it.
>
> Project outsiders might suggest only allowing "expert writers" to work
> on such articles.  I think any of us can explain how that's much easier
> said than done.

I answer with a quote from someone you know:

   To attact and retain the participation of experts, there would have
   to be little patience for those who do not understand or agree with
   Wikipedia's mission, or even for those pretentious mediocrities who
   are not able to work with others constructively and recognize when
   there are holes in their knowledge (collectively, probably the most
   disruptive group of all). A less tolerant attitude toward disruption
   would make the project more polite, welcoming, and indeed open to
   the vast majority of intelligent, well-meaning people on the Internet.

In my view, wikipedia has to undergo a paradigm change if it really
wants to succeed in creating a good encyclopedia. Some answers in this
thread are symptomatic for this: You shouldn't be forced to explain a
revert of a bad edit (of course it's good if you still do).

Currently wikipedia forces editors to go through silly processes and
discussions to defend good edits. How many highlevel editors are willing
to do this all the time? The physics professor may explain relativity
theory once to a clueless wikipedian who just put his wisdom into the
article, but if he has to do it every week, he'll pack his belongings
and go to another project to spend his time on.

And it's even worse with style improvements if you have to argue with
bad writers why an article should be coherent text and not randomly
assembled item lists.

We shouldn't give up the principle of open editing but we should make
clear now from the beginning that we seek good writers and knowledgeable
people, not anyone. Yes, anyone _can_ edit an article. But not anyone
_should_ edit any article.

greetings,
elian


from_name: BJörn Lindqvist

subject: [WikiEN-l] a valid criticism

body:
> >> It's that they are badly written.  A confusing mishmash of random facts
> >> not shaped into a coherent whole.  Others have written eloquently on
> >> this, and on why this might be the case.  The puzzle, though, is: what
> >> can be done about it.
> >
> > Encourage people to become better writers?
> There are plenty of people capable of writing coherently, as evidenced
> by the quality of posts to this mailing list :)

You have a point there, but at the same time you dont. :) I don't know
why, but I feel that it is much easier to write well-written emails
than coherent encyclopedic prose. I suspect that atleast some other
Wikipedians have the same problem. Maybe it has something to do with
that in mails you can write from your personal view, but in articles
you have to use NPOV and only present the relevant facts? Also, the
longer the text, the harder it is to add to it without "destroying
it." It's like software development - introducing a new feature often
requires you to redesign the whole (or large parts of) the program
again. In programming, the answer is to always think ahead, structure
your code and refactor often. But Wikipedians already employ those
techniques with small incremental edits that slowly but surely make
bad articles better.

I don't think anything really needs to be changed. Someone with a good
knowledge of English could make their way through both Bill Gates and
Jane Fonda and make them much better. If something should be changed
then I think it is peoples perception about who the real "superstars"
on Wikipedia is. I think it is all those who mark their edits "minor,"
corrects spelling misstakes and other grammatical errors. Sometimes
that is seen as a thankless job I think.

--
mvh Bj?rn


from_name: Aaron Sherman

subject: [WikiEN-l] Merge vs. Keep/Delete

body:
On Sat, 2005-10-08 at 11:09 +0200, MacGyverMagic/Mgm wrote:
> On 10/8/05, Alphax <alphasigmax at gmail.com> wrote:

> > Michael Snow wrote:

> > > Tony Sidaway wrote:

> > > [...] I don't see why the authority to
> > > merge-and-redirect should be limited to administrators. I've always
> > > found the resistance to merges puzzling.

The reason is that an admin is required to end the AfD, not that an
admin is required to click on the "edit" button.

> > Merge-and-redirect often *does* require admin attention, because the
> > "proper procedure" is to perform a history merge, isn't it?

Not often, no. The vast majority of the time, the edit history consists
of one or two original edits and the addition of the AfD tag. Simply
noting "merging in joesixpax's [[Mushi mushi]] article" when doing the
merge should be sufficient, and the edit history is still on the
redirect page.

> Wouldn't that kill the usefulness of diffs over a period when both
> articles were edited?

Over that period? No. During that period? Sure, but that's as minor as a
page-blank. In the long-run it does not affect the usefulness of the
page's history.


from_name: steve v

subject: [WikiEN-l] The 3RR is an electric fence, not an entitlement.

body:
3RR is great when used properly, but Im not sure it is
consistently used in a proper way.

1) there is no binding review of anything except the
Arbcom
2) the Arbcom's supremacy in binding decisions makes
them treat issues disputes and conduct disputes as one
3) hence they typically neglect making any rulings on
issues or policy -- matters of review are too small
for the Arbcom to deal with, and they defer to
consensus
4) Consensus can be uselessly indeterminate and
unintelligent in areas which are not sharply clear-cut
5) As an example of "policy shift," 3RR has a
different function in the current context than it did
was when it was first implemented. For example, a
counterweight serves to balance excess weight in an
opposing area --remove the weight and the
counterweight itself becomes a problem needed
correction.
6) "nobody knows how it works"

Sum up: Policy review, separate Committee for handling
issues disputes, and another for handling policy
review/oversight. Establish a unitary central case
body
which lists each case in terms of both issues and
conduct.

SV

--- actionforum at comcast.net wrote:

>
> > If we should want to use edit-warring as a tool to
> achieve this end, we
> > should do so in full awareness that its over-use
> is ill-regarded by the
> > community and may land us with a block. In
> particular, we should not
> > complain when over-zealous use of reverts in the
> face of multiple opposition
> > lands us with a 3RR block.
>
> Those who edit war are still entitled to a fair
> assessment of the alleged
> 3RR violation evidence, and to a fair implementation
> of the block based
> upon that assessment, and to complain if there were
> problems with
> either of these.
>               -- Silverback
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com


body:
Reasonable people should agree completely with this,
but I (OTOH :) have to stipulate:

1) that 3RR should be applied according to what it
actually says and not in a one-sided manner according
with a complaint.

2) that your (or other's) implied or stated assumption
that tag-teaming an issue is simply an aspect of
consensus is false down to its toe fungus. Civil law
in meatspace doesnt say:
  "if youre a lesbian walking home at night and some
   guys beat and rape you, they (being in a majority)
   should be considered as a microcosm of democratic
   consensus against your position."

SV
There doesnt seem to be an article on [[toe jam]] BTW.

--- Tony Sidaway <f.crdfa at gmail.com> wrote:
> If we should want to use edit-warring as a tool to
> achieve this end, we
> should do so in full awareness that its over-use is
> ill-regarded by the
> community and may land us with a block. In
> particular, we should not
> complain when over-zealous use of reverts in the
> face of multiple opposition
> lands us with a 3RR block.

__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/


from_name: Michael Snow

subject: [WikiEN-l] Re: Merge vs. Keep/Delete

body:
Tony Sidaway wrote:

>On 10/8/05, Alphax <alphasigmax at gmail.com> wrote:
>
>
>>So history merges are useful only for cut-and-paste moves?
>>
>>
>Yes, pretty much. The problem with history merges is that the software
>provides no means of unmerging elements from the history. One they're there,
>there's no way to get them out again.
>
>
There are other circumstances that call for a history merge, but the
general principle here is important. Whether it's a cut-and-paste move,
or duplicate articles created independently (I've done several recently
where this happened due to variant spellings), a history merge should
generally be done only if the articles are about the exact same topic,
and will never need to be taken apart again.

Furthermore, with articles nominated for deletion, we're generally
talking about a short article being merged into a larger one about a
broader topic. As was pointed out, merging history produces disjointed
and mostly useless diffs. Also, merging by cut-and-paste is not
necessarily desirable anyway, and if you rewrite the basic material
you're merging from, then you're using the merged article as a resource
rather than creating a derivative work, so concerns about GFDL
compliance can be eliminated.

--Michael Snow


from_name: Sean Barrett

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

> Those who edit war are still entitled to a fair assessment of the alleged
> 3RR violation evidence, and to a fair implementation of the block based
> upon that assessment, and to complain if there were problems with
> either of these.
>               -- Silverback

Not so, at least not literally.

Those who are /accused/ of edit warring are entitled to an assessment.
Those who /are/ edit warring are entitled to nothing but being sent to
their rooms for a time-out.

Edit warring is an offense against the community that estops the
"warrior" from the recourses available to those with self-control.

- --
 Sean Barrett     | Never stand next to anyone throwing
 sean at epoptic.com | shit at an armed man. --Larry Niven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDR/WQMAt1wyd9d+URAnpvAJ9MPgGfXVZm5sK0EUQ1RzkiWIBkOgCeNne8
mPSpIGJ4axXpMVf088/G1iA=
=3rOd
-----END PGP SIGNATURE-----


from_name: Jeremy Dunck

subject: [Wikitech-l] Uncompressed en xml size?

body:
I downloaded en_20050713_pages_full.xml.gz but upon decompressing,
apparently ran out of disk space.

gunzip -l doesn't appear to show the correct uncompressed size.

jgd011100 at utd51523:~/wps/data$ gunzip -l en_20050713_pages_full.xml.gz
         compressed        uncompressed  ratio uncompressed_name
        32171234059          3560916631 -803.5% en_20050713_pages_full.xml

Can someone give me a ballpark size for this file (uncompressed) so I
know how to deal with it?


list: foundation-l

from_name: Stephan Walter

subject: [Foundation-l] Re: New Wikimediach-l for Wikimedia CH

body:
I have submitted the list to gmane.org, so the we'll be able to read the
list on the gmane.org usenet server. If you don't now about gmane: this
mail-to-news gateway is really useful, because you won't have thousands
of email each day if you're subscribed to a lot of mailinglists. See
http://gmane.org/ for more information.

The hierarchy currently is a mess:

gmane.org.wikimedia.foundation.uk
gmane.org.wikimedia.france
gmane.science.linguistics.wikipedia.verein

I have now asked for wikimediach-l to be
gmane.org.wikimedia.foundation.switzerland, but maybe they'll change the
hierarchy.

-Stephan


list: wikimedia-l


from_name: Michael Turley

subject: [WikiEN-l] Response to Nick Carr on Wikipedia and Web 2.0

body:
On 10/7/05, Alphax <alphasigmax at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Michael Turley wrote:
> > On 10/7/05, JAY JG <jayjg at hotmail.com> wrote:
> >
> >>> From: Tony Sidaway <f.crdfa at gmail.com>
> >>>
> >>> I like your idea of adopting the Economist house style, but a lot
> >>> of kids are taught in schools to write unimaginably long, tedious
> >>> essays on quite trivial subjects, so they have to learn how to
> >>> trim out the waffle when they come to writing for real readers.
> >>
> >> Is anything too trivial for Wikipedia, if it is to become "the sum
> >> of all human knowledge"?
> >>
> >
> > Subject wise?  If it's verifiable, perhaps not.  Too trivial for
> > inclusion in broader articles?  Certainly.
> >
> > For example, someone cut out the links to Bill Gates' home from the
> > Bill Gates article.  Details of his home are trivial in the Bill
> > Gates article so cutting them out was probably the right thing to do,
> > but adding them back into Wikipedia elsewhere, in article about his
> > home, would be completely appropriate.
> >
>
> I think NPOV comes into it here. It's possible that a lot of what might
> be described as "trivia" is difficult to write about from a neutral
> point of view.

Perhaps you meant third party verifiable?  NPOV isn't any more
difficult for smaller subjects.

--
Michael Turley
User:Unfocused


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] Merge vs. Keep/Delete

body:
On 10/8/05, Alphax <alphasigmax at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Michael Snow wrote:
> > Tony Sidaway wrote:
> >
> >> I wonder if we could agree to change policy to permit an administrator to
> >> "speedy redirect" a merge candidate and close an AfD where notability
> >> is the
> >> sole or principal reason given for deletion, or no reason is given. This
> >> would be a good way of ensuring that the possibility of merging
> >> articles was
> >> not unreasonably neglected. An article could always be renominated if
> >> good
> >> faith attempts to merge had failed.
> >>
> >>
> > I endorse that, although I don't see why the authority to
> > merge-and-redirect should be limited to administrators. I've always
> > found the resistance to merges puzzling. It's almost as bad as the
> > polarizing notion that deletion debates orbit the twin suns of Keep and
> > Delete, which are the only possible outcomes, and a "vote" to merge is
> > in reality to be reinterpreted as a vote for one of these binary stars
> > (which one depends on who's arguing). An argument for a merge is just
> > that, and in these cases it's often by far the best solution.
> >
>
> Merge-and-redirect often *does* require admin attention, because the
> "proper procedure" is to perform a history merge, isn't it?
>
> - --
> Alphax                      |   /"\
> Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
> OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
> http://tinyurl.com/cc9up    |   / \
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iQEVAwUBQ0dAL7MAAH8MeUlWAQhQPQf+JUqu3Qc3jfeggXPZRpgwEeqL2DNy4KcJ
> y02ec0wcwwWE641GWdIzv4uBVZHufJAj3pqyTZyaccYxbUp9VinKzttZL9Y8ssno
> jDUrPUZtTIRpN9i9y4Yv+z/CPV4C3TQ9tuZb9CAQs4k7njIgWylKN+VSDtMTfybW
> wlu+0OItFOPRScOBX5IqRHtaE6zZAegwYYagzYj9G+tGhsgF+UQRTm9+7yi+uhvQ
> wihn9Cv81ExPF8LvX85a10htDF3OZKYQiBaR3IW3hwmx9fnyHBPIWBB0ybyTrTfF
> p7SJ+Lk6krR9VFqNREyqpFleZqPkwhX5RnFFRxKNa7Z74NzUzT9jog==
> =Zn+p
> -----END PGP SIGNATURE-----
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
Wouldn't that kill the usefulness of diffs over a period when both
articles were edited? If article A was edited on December 1 and
December 3 and you merge in an article edited on December 2. You get
two diffs with massive changes without any explanation how that
happened. You could mention the merge in an edit summary, but you'd
have to list which edits have been merged in. Redirecting keeps the
histories clean.

--Mgm


from_name: Ryan Norton

subject: [WikiEN-l] Re: I demand a daily spot for great writing

body:
>> good writing doesn't guarantee FA status. From a recent featured
>> article:
>
> {{sofixit}}.

Yes, please go to peer review and maybe FAC and help point out problems
in articles. Even one person can help a lot and stop a FAC from
succeeding in most cases as FACs generally do not get a lot of support
"votes".

Thanks,
Ryan

[[User:RN]] at wikipedia: http://en.wikipedia.org/wiki/User:RN
Ryan Norton at wxforum: http://wxforum.org


from_name: Any File

subject: [Wikitech-l] Re: Uncompressed en xml size?

body:
Jeremy Dunck wrote
>
> I downloaded en_20050713_pages_full.xml.gz but upon decompressing,
> apparently ran out of disk space.
>
> gunzip -l doesn't appear to show the correct uncompressed size.
>
> jgd011100 at utd51523:~/wps/data$ gunzip -l en_20050713_pages_full.xml.gz
>           compressed        uncompressed  ratio uncompressed_name
>          32171234059          3560916631 -803.5% en_20050713_pages_full.xml
>
> Can someone give me a ballpark size for this file (uncompressed) so I
> know how to deal with it?
>

I argue that you have a versin of gzip that is not good to deal with so large file.

Try to install a new version of gzip.

AnyFile

--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm


subject: [WikiEN-l] I demand a daily spot for great writing

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

Tony Sidaway stated for the record:

> I *demand* that we have a guaranteed daily place on the main page, to be
> reserved solely for articles chosen for their great writing.

Oh, my goodness!  He *demands* it!  With asterisks, no less!

- --
 Sean Barrett     | Never stand next to anyone throwing
 sean at epoptic.com | shit at an armed man. --Larry Niven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDSBC2MAt1wyd9d+URAmn5AJ95vszADsUpsgY/ODoPjNzxiPdAuACfUxdO
DNY2PZ89iOQ1+r85MkIiwQw=
=2t4M
-----END PGP SIGNATURE-----


body:
On 10/8/05, Any File <anyfile at mail.com> wrote:
> I argue that you have a versin of gzip that is not good to deal with so large file.
>
> Try to install a new version of gzip.

It seems to be the most recent version, unless I've missed something.

jgd011100 at utd51523:~/wps/data$ gunzip -V
gunzip 1.3.5
(2002-09-30)
....

Regardless, that's not my question.  :)

Can someone give me a ballpark size for this file (uncompressed) so I
know how to deal with it?


from_name: Ray Saintonge

subject:
[Foundation-l] Authoring on wikijunior :
	providing	private	information.

body:
Robert Scott Horning wrote:

> Nicholas Moreau wrote:
>
>> On 10/6/05, foundation-l-request at wikimedia.org <
>> foundation-l-request at wikimedia.org> wrote:What I am asking for is
>> that if
>> you want to claim copyright on your contribution, you need to give this
>> minimum amount of information for legal protection and to give a
>> realistic
>> copyright claim on your contributions. As it stands right now, there
>> is no
>> way that you can realisticly claim copyright on any of your
>> contributions
>> right now, and certainly there is no way that you canresolve potential
>> copyright claims on material if it goes to court in a dispute.
>>
>> Okay, suppose I didn't include my information, and I wanted to claim
>> copyright on content in Wikijunior.
>>
>> I take the Foundation to court, saying "I CLAIM MY COPYRIGHT ON THIS!"
>>
>> The defendant's lawyer says "But, you can't. On the website, when you
>> contribute anything to any Wikimedia project, it says that you're
>> contributing this info to the Wikimedia Foundation."
>>
>> Like, seeing that I have my information on the "contributors" page, does
>> that mean I own part of the Wikijunior project, and thus can profit
>> from my
>> "share" of the contribution? Every time one issue of the books is
>> published,
>> $0.02 come rolling into my PayPal account? What? If that's the case, I'm
>> doing fifty edits under fifty different usernames.
>>
>> I honestly am dumb-founded on what you consider "claiming [my]
>> copyright",
>> on something solely copyrighten by the foundation.
>
> I think you miss the point.  The Foundation does not claim copyright
> on anything for any Wikimedia project.  There is a legitmate reason to
> do this, and a good one as well.  All the Wikimedia Foundation does is
> claim trademarks on commonly used images and names that relate
> directly to each one of the projects, and this is proper as well.  I
> can't set up another web site and claim it is Wikipedia with Wikipedia
> content...that is a violation of trademark.  In order to enforce
> copyright, it is up to the individual authors for each web page to do
> the enforcement and keep violators from getting away with breaking the
> law.

Absolutely! Trademarks though are a different topic, and are not that
big of a problem for us.  Getting into that aspect of IP law would only
muddy the waters.  Copyright is another matter because we are in an area
that is not properly covered by the law.  Free licensing was an unheard
of and unimaginable concept when these laws were written.  In principle,
copyright was invented to protect the _financial_ rights of authors.  It
has been more a matter of civil law than criminal law..  There is such a
thing as criminal infringement for wilfull violations, but I don't think
we need to worry about that aspect for now.

The Berne convention mandates automatic copyright such that no person
loses his copyrights because of a failure to register.  The Berne
convention forbids signatory states from imposing  obligatory
registration.  The US, as a signatory to the Berne convention is also
bound by this.  What it does is make registration a prerequisite to
filing an infringement  law suit.  This is useful because it helps to
establish a right of action; it also imposes a limitation on the damages
that can be claimed to those that were sufferred after registration.  It
allows you to ignore copyright infringement claims from third parties
who have no personal interest in the claim.

> The real issue is if somebody, like Microsoft Press or Prentiss-Hall,
> decides to claim copyright on something found on a Wikimedia Project,
> like one of the Wikijunior books, and decides instead to claim
> copyright on it for themselves.  They do some "minor" modifications of
> the content, research the images to make sure they are free and clear
> to reproduce, and then say "to heck with the GFDL... we don't care"
> and publish the book anyway as if they wrote it themselves.

I'm sure I commented on this a couple years ago.  The big problem is not
with copyvio material on the wikis; we have already shown ourselves to
be diligent in trying to deal with that.  The likelihood of being
defendants in a serious law suit are very rmote.  It's far more likely
that our copyrights will be violated, and we will do fuck all about it.
We may go ahead with nice letters to the infringers begging them to
please, please, please not infringe, but what plan is there for when
they simply respond, "Go to hell!"?  With copyrights lasting 70 years
beyond death, what plans are there to deal with that when the relevant
authors are dead, and it's not even clear who can give permission to sue.

Material by unidentified authors is copyrightable just as much as
material by identified authors, except that the term of copyright is
counted from the date of publication.  The same term applies to
copyrights owned by corporations.  The only practical solution would be
for all contributors to appoint Wikimedia as a non-exclusive copyright
agent that can go ahead and take action against copyright violators when
the occasion arises.  This should be stated on every edit page along
with the reference to the GFDL.  We should also be periodically (perhaps
quarterly) dumping the entire project on a CD and registering that as
evidence of the state of the wiki at a given time.  Being non-exclusive
will still allow the heirs of properly identified authors to take action
for the longer period beyond their lifetimes.

Rights which are not defended are meaningless.  I think that it is
essential that Wikimedia accept the responsibility to act as an agent
for the protection of our collective rights.

> They can even go back and claim that the material on Wikibooks in this
> case is violating their copyright even and force the removal of the
> content on Wikibooks.

I think that this is taking it a little far.  The periodic registration
that I mentioned above will be prima facie evidence that the disputed
material was added at the date that we claim.  That should make it
easier to shift the burden of proof that their material was written earlier.

> As far as the "contributors" page is concerned, who are they?  Where
> are they from?  Can you certify that the author mentioned in the
> contributors page even exist?  Really, are you sure it isn't somebody
> else?  Are you sure they are in the USA/France/Germany like you claim
> they are?  Are you sure that it wasn't some hacker in Mongolia where
> international copyright doesn't apply?  Prove it.  What court has
> juristiction on enforcing the author's wishes?  You can't even be sure
> who the author is, so why do you think a particular court even has a
> right to prosecute?  So you think the server is in the USA and
> therefore the USA has original juristiction on prosecuting copyright
> because of the foundation.  Guess what, the Wikimedia Foundation
> doesn't claim copyright on any of the material, so that claim is
> thrown out.  Now what?

Mongolia is signatory to the Berne Convention.  What is the basis of
your claim that international copyrights do not apply there?

This is a confused paragraph.  Whatever the real problems, this is not
one.  Legal jurisdiction is based on where the offence took place, not
on where the copyright owner or his servers are resident.

> It gets even worse.  Because we can point to comments here on this
> mailing list and on several talk pages that not only is this
> information (about the country of birth and nationality of each
> author, together with each full real name) is not collected but there
> seems to be "official" opposition to even collecting it, all
> contributions can be argued as anonymous contributions.  This wasn't
> just an oversight from somebody not understanding copyright, but a
> deliberate policy of removing identification related to user
> contributions even with specifics of copyright law being explained.

If individuals want to protect their privacy I recognize that as their
personal right for which they don't need to make an excuse.  I don't
know of any "official" opposition to people freely providing that
information.  A person who chooses to invoke his right to privacy does
need .to be aware of how this will limit his copyrights.  A teen
contributor may still be alive and in his eighties when the copyright
expires.

> In short, yes, we know who has contributed what stuff to each
> Wikimedia article/module/entry but trying to prove authorship is going
> to be a major headache if any single page is going to be challenged on
> its copyright claim.  Already I've seen supposed copyright violations
> when in fact it was the "other" website that was violating copyright
> of the authors of a particular page.  It is just a matter of time
> before something on one of the Wikimedia projects is going to be
> challenged and "forced" to be removed, not because of an obvious
> copyright violation from a previously published source but because the
> copyright of the Wikimedia content is in doubt.

Proof of authorship is still not essential to the subsistance of
copyright.  It is only essential if that individual wants to pursue his
case as an individual.  I agree that it is only a matter of time before
these issues need to be litigated, but it is up to us to carefully
circumscribe the issues so that we are not wasting our efforts on a lot
of red herrings.

> In addition, one of the reasons I asked for this information is that I
> intend to do a formal copyright registration on Wikijunior books when
> I send them into print format.  I've already taken one Wikijunior book
> down to a printing company and made a copy that I can send around to
> some people as the tangible results of these projects.  As a part of
> this formal registration which I don't need any permission to do, I am
> required by law when filing the registration to try and find all
> copyright claims on the material that I am registering.  At least a
> reasonable attempt at collecting the information.  In the case of the
> Wikijunior Solar System book, there are over 50 different
> contributors, and it would be nice to be able to give credit to all of
> them, and give them all a "stake" in the book as it goes to press.  I
> was trying to be polite and ethical as I can, and then I find people
> like you, Zanimum, who not only object to me collecting this from
> people voluntarily, but seek to stop me from trying to collect this
> information altogether.

Nothing prevents you from taking the material to the printer at your own
expense, or even making a personal profit when you sell it to the
public.  You just need to follow the GFDL, and can't object when anyone
else does the same thing.

> I do think this information can and should be a part of the "user"
> record for each Media Wiki user, and adding the information is very
> trivial to accomplish from the viewpoint of a developer.  Like I said,
> voluntary information only, and you don't have to include the
> information if you don't want to, but why it shouldn't be listed as
> another field on the user preferences page is beyond my comprehension.
> And it can save us some headaches in the future as well.

I'm sure that software could be written to handle this; go ahead and do
that.  Maybe the developpers will agree to make your programming a part
of Mediawiki if it is fairly bug free.  Nevertheless it is still not
clear that it is a legal necessity.

Ec


subject: [Wikitech-l] approved requests for new wikipedias

body:
?var Arnfj?r? Bjarmason wrote:

>The reason I didn't create these when I created ilo is:
>
>* Samogitian, Banyumasan, Ripuarian, Dutch-Low Saxon: Don't have an
>ISO code (nds-nl claims to have one but that looks like a
>pseudo-ISO-code)
>*  Banyumasan, Ripuarian are dialects according to Wikipedia,
>Dutch-Low Saxon appears to be some kind of dialect as well.
>
When we want to accept a language which does not have an ISO code we
could use one from that range of codes beginning with the letter "q"
which ISO allows for user defined codes.

Ec


from_name: Fastfission

subject: [WikiEN-l] a valid criticism

body:
On 10/7/05, Jimmy Wales <jwales at wikia.com> wrote:
> Yes, but these are not exactly obscure people.  If he went and found an
> article on an obscure 13th century poet which was crap, I would be not
> quite as bothered.  But Jane Fonda?  Bill Gates?

But clearly "obscurity" is not the factor which determines a good or
bad article. Plenty of articles on obscure people are very good and
plenty articles on very simple things can be quite bad. But still, he
did not, of course, give any rationale for these two articles except
that they exemplify the fact that Wikipedia is edited by amateurs and
sometimes has spotty content. So what? Oh, the Bill Gates article
should be better. I think it *is* a bit better since he looked at it.
Bill Gates is a major figure, no doubt. Jane Fonda is not obscure but
the world doesn't revolve around her, either -- she's a U.S. actress
who has gotten press because of a few of her political stances she
took in the 1960s.

But nobody's making excuses here. I'm just saying that you will always
be able to find sore spots if you want to. If you believe in the
Wikipedia way, what you do is try to fix them or call them to the
attention to others. If you don't, then you write pissy articles about
them.

I don't think it's worth taking such criticisms too seriously, because
they boil down to "Wikipedia articles are sometimes spotty and written
poorly." Well, that's no surprise to anyone. That's not why it's
popular, that's not why it's interesting, and that's not why it's a
good project.

We're not making software, here -- just because some parts of it are
spotty doesn't mean the entire package won't work. In that way we're a
lot less restrained than the open source software projects and can
afford to have a philosophy of eventualism.

> Well, I don't agree.  It is my intention that we be valued for
> completeness and coherency and "brilliant prose" *as well as* for being
> freely licensed, with magnificent breadth and speed and usefulness, etc.

There will always be places on Wikipedia without brilliant prose, and
there will be places with it. Those who want to value us on our
strengths will. Those who don't, won't.

FF


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: wfEscapeJsString method

body:
Amruta Lonkar wrote:
> Can someone please tell me where i can find the  wfEscapeJsString method. I
> have added a button in the edit tool bar and now want to add the sample text
> and tool tip for it. I am guessing its in this method.

The 'wf' prefix probably stand for 'Wikipedia Function', most of them
are in the ./includes/GlobalFunctions.php file.

The wfEscapeJsString function just escape stuff.

--
Ashar Voultoiz - WP++++
http://en.wikipedia.org/wiki/User:Hashar
http://www.livejournal.com/community/wikitech/
IM: hashar at jabber.org  ICQ: 15325080


from_name: dominik.bach at web.de

body:
I belong to the group that runs the Ripuarian Testwiki, and we have
been discussing the language code. Currently, there is no ISO-Code
for Ripuarian, and an SIL-Code exists only for the biggest ripuarian
dialect, K?lsch (ksh), but we do not want to use it because the majority
of Ripuarian speakers does not speak K?lsch dialect. We thought of
proposing an ISO code that could be "grp" (german-ripuarian), or better
"frp", since the linguistic term for our language is "Franconian-
Ripuarian", or simply "rip".

We are also translating the language interface, what do we have to do
when it is ready?

Thanks Dominik


from_name: Alphax

subject: [WikiEN-l] a valid criticism

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

Ryan Norton wrote:
>> It's that they are badly written.  A confusing mishmash of random facts
>> not shaped into a coherent whole.  Others have written eloquently on
>> this, and on why this might be the case.  The puzzle, though, is: what
>> can be done about it.
>
>
> Encourage people to become better writers?
>

There are plenty of people capable of writing coherently, as evidenced
by the quality of posts to this mailing list :)

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ0c+zLMAAH8MeUlWAQh3tAf+PfI1LgBFgs4ifVHMN17ULqHHZ3G4r1aU
HVimV7AhVjglBVXogQvcN4rFM6jSnXhM7u3wshsTGRLE+UXQk5bRedIm3PSv3DPR
T5am8+fYqdrxRX1GYT43oc6DJocmp8o7RC1BO00UY5gZm3Q+jQRJMxUHtC2gWzOC
6/lHCrZ/hjvuIufrxiHsshroTEJDCdJRzuLnuRiyMkKitf1SPfjjE8Gpp6+EZd9t
L1REQzdPa3iRuBa4bba5r95l61wEcMQaf/0cM9hCEnkmgF02QAXy65GS7KZrjZwW
Nqe+qJ6sI1UZ3syMGvE8iz487SOLxPl9Z/E3C5eHFiuVRWJOnrwFhA==
=Hw8l
-----END PGP SIGNATURE-----


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

Michael Turley wrote:
> On 10/7/05, JAY JG <jayjg at hotmail.com> wrote:
>
>>> From: Tony Sidaway <f.crdfa at gmail.com>
>>>
>>> I like your idea of adopting the Economist house style, but a lot
>>> of kids are taught in schools to write unimaginably long, tedious
>>> essays on quite trivial subjects, so they have to learn how to
>>> trim out the waffle when they come to writing for real readers.
>>
>> Is anything too trivial for Wikipedia, if it is to become "the sum
>> of all human knowledge"?
>>
>
> Subject wise?  If it's verifiable, perhaps not.  Too trivial for
> inclusion in broader articles?  Certainly.
>
> For example, someone cut out the links to Bill Gates' home from the
> Bill Gates article.  Details of his home are trivial in the Bill
> Gates article so cutting them out was probably the right thing to do,
> but adding them back into Wikipedia elsewhere, in article about his
> home, would be completely appropriate.
>

I think NPOV comes into it here. It's possible that a lot of what might
be described as "trivia" is difficult to write about from a neutral
point of view.

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ0c/srMAAH8MeUlWAQgdmwf+IH8gf1AwWrmr2Pq9jZiObE8VSbvmd8vv
sh18tMWm1ac9Hka1NQmwVT/URZMx+kGnLaQl5SCvqQF5+VKWPoKdSui7WgR9V0j6
L1wYPdNPe5RHscL1Q+fdV53yuQWOoXtga5VgG8L3QDYNHlFRkRjH20W5MJmwLHgZ
AyY+G4FFAZmchSRVeN4gawr+MDs0wD4wTz0R1cKRbtdEfXzJ6yLdF+cQ55V4GEK/
LLGRbPGR+YYD85MCiJBqVm99LxFfu1Ba5ogdzme/s/74Hm8noutoRmZ0uYIjfvFu
LV4PxCp5cU8T3pCFw/wAGQUdGcTLtCu3JpeTd1w0PxC92HOn9AEyvQ==
=zBMs
-----END PGP SIGNATURE-----


subject: [WikiEN-l] Merge vs. Keep/Delete

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

Michael Snow wrote:
> Tony Sidaway wrote:
>
>> I wonder if we could agree to change policy to permit an administrator to
>> "speedy redirect" a merge candidate and close an AfD where notability
>> is the
>> sole or principal reason given for deletion, or no reason is given. This
>> would be a good way of ensuring that the possibility of merging
>> articles was
>> not unreasonably neglected. An article could always be renominated if
>> good
>> faith attempts to merge had failed.
>>
>>
> I endorse that, although I don't see why the authority to
> merge-and-redirect should be limited to administrators. I've always
> found the resistance to merges puzzling. It's almost as bad as the
> polarizing notion that deletion debates orbit the twin suns of Keep and
> Delete, which are the only possible outcomes, and a "vote" to merge is
> in reality to be reinterpreted as a vote for one of these binary stars
> (which one depends on who's arguing). An argument for a merge is just
> that, and in these cases it's often by far the best solution.
>

Merge-and-redirect often *does* require admin attention, because the
"proper procedure" is to perform a history merge, isn't it?

- --
Alphax                      |   /"\
Encrypted Email Preferred   |   \ /     ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |    X   Against HTML email & vCards
http://tinyurl.com/cc9up    |   / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQEVAwUBQ0dAL7MAAH8MeUlWAQhQPQf+JUqu3Qc3jfeggXPZRpgwEeqL2DNy4KcJ
y02ec0wcwwWE641GWdIzv4uBVZHufJAj3pqyTZyaccYxbUp9VinKzttZL9Y8ssno
jDUrPUZtTIRpN9i9y4Yv+z/CPV4C3TQ9tuZb9CAQs4k7njIgWylKN+VSDtMTfybW
wlu+0OItFOPRScOBX5IqRHtaE6zZAegwYYagzYj9G+tGhsgF+UQRTm9+7yi+uhvQ
wihn9Cv81ExPF8LvX85a10htDF3OZKYQiBaR3IW3hwmx9fnyHBPIWBB0ybyTrTfF
p7SJ+Lk6krR9VFqNREyqpFleZqPkwhX5RnFFRxKNa7Z74NzUzT9jog==
=Zn+p
-----END PGP SIGNATURE-----


from_name: actionforum at comcast.net

body:
> Seconded. The 3RR is an electric fence, not an entitlement. It *really
> doesn't matter* if the article is on [[m:The Wrong Version]] for a
> while longer. It really doesn't. Consistently running up 3 reversions
> every 24 hours is prima facie evidence of failure to work with others.

It only takes one motivated party for failure to work together.  Sometimes reverting is a way to bring them to the table.

                 -- Silverback


from_name: Mark Pellegrini

body:
Tony Sidaway wrote:
"I *demand* that we have a guaranteed daily place on the main page, to
be reserved solely for articles chosen for their great writing."

We have that. It's called the daily featured article.

-Mark


from_name: Tony Sidaway

subject:
[WikiEN-l] Merge vs. Keep/Delete (was: Dispute resolution attempt
	in the Ashida Kim case)

body:
On 10/8/05, Michael Snow <wikipedia at earthlink.net> wrote:
>
> Tony Sidaway wrote:
>
> >I wonder if we could agree to change policy to permit an administrator to
> >"speedy redirect" a merge candidate and close an AfD where notability is
> the
> >sole or principal reason given for deletion, or no reason is given.
> >
> I endorse that, although I don't see why the authority to
> merge-and-redirect should be limited to administrators.

I agree. I don't know why I thought it should be limited to administrators.
A non-administrator can close a clear non-delete debate (indeed I believe
some adventurous non-administrators may have closed delete debates by
putting a delete-because tag on the article).

I can see that a speedy redirect of this kind could encounter severe
resistance where there is already an emerging consensus to delete. I
wouldn't like to be there when something like that happened; it could be
very unpleasant. There is a strand of thinking that regards any alternative
to deletion in such case as illegitimately thwarting the decision-making
process--perhaps this stems from a belief that the purpose of AfD is to
delete rather than to debate deletion.


from_name: Ævar Arnfjörð Bjarmason

body:
The reason I didn't create these when I created ilo is:

* Samogitian, Banyumasan, Ripuarian, Dutch-Low Saxon: Don't have an
ISO code (nds-nl claims to have one but that looks like a
pseudo-ISO-code)
*  Banyumasan, Ripuarian are dialects according to Wikipedia,
Dutch-Low Saxon appears to be some kind of dialect as well.


subject: [WikiEN-l] Merge vs. Keep/Delete

body:
On 10/8/05, Alphax <alphasigmax at gmail.com> wrote:
>
>
> Merge-and-redirect often *does* require admin attention, because the
> "proper procedure" is to perform a history merge, isn't it?
>

Absolutely not. A history merge should be limited to situations such as
those where a fork has been created. A proper merge is one that would permit
the merge to be reversed at some time in the future, and this would require
the use of a redirect, not a history merge.


body:
On 10/8/05, actionforum at comcast.net <actionforum at comcast.net> wrote:
>
>
> > Seconded. The 3RR is an electric fence, not an entitlement. It *really
> > doesn't matter* if the article is on [[m:The Wrong Version]] for a
> > while longer. It really doesn't. Consistently running up 3 reversions
> > every 24 hours is prima facie evidence of failure to work with others.
>
> It only takes one motivated party for failure to work together. Sometimes
> reverting is a way to bring them to the table.
>
>
If we should want to use edit-warring as a tool to achieve this end, we
should do so in full awareness that its over-use is ill-regarded by the
community and may land us with a block. In particular, we should not
complain when over-zealous use of reverts in the face of multiple opposition
lands us with a 3RR block.


from_name: Andrew Gray

subject: [WikiEN-l] Autoblocking, reverts, and verifiability

body:
On 06/10/05, Ryan Delaney <ryan.delaney at gmail.com> quoted:

> According to baseball rules, if one has "more than 2 strikes" called
> against him while at bat, that player will be called "out." In other
> words, each batter is "entitled" to 2 strikes before being called
> "out." According to Wikipedia rules, if one edits a page "more than
> three times" in a 24 hour period, he is subject to being blocked. How
> is it, then, that that rule does NOT "entitle" an editor to "three
> reverts" without being called out? (...)

My personal solution would be to edit WP:3RR such that it says
something like "Administrators may, at their discretion, block people
for aggressive reverting in accordance with the _spirit_ of this rule,
not the letter; this is considered acceptable, even if less than three
reverts have been made to any one page in a 24-hour period".

However, this would not - to put it mildly - go down very well if
suggested. (despite the fact that 98% of editors with common sense
would never notice the difference)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


subject: [Wikitech-l] Re: approved requests for new wikipedias

body:
dominik.bach at web.de wrote:
<snip>
> We are also translating the language interface, what do we have to do
> when it is ready?
>
> Thanks Dominik

Have a look at:

http://meta.wikimedia.org/wiki/MediaWiki_localisation

As the file probably does not exist yet, just translate the Language.php
file then submit it as a bug report on bugzilla.wikimedia.org .

--
Ashar Voultoiz - WP++++
http://en.wikipedia.org/wiki/User:Hashar
http://www.livejournal.com/community/wikitech/
IM: hashar at jabber.org  ICQ: 15325080


body:
> If we should want to use edit-warring as a tool to achieve this end, we
> should do so in full awareness that its over-use is ill-regarded by the
> community and may land us with a block. In particular, we should not
> complain when over-zealous use of reverts in the face of multiple opposition
> lands us with a 3RR block.

Those who edit war are still entitled to a fair assessment of the alleged
3RR violation evidence, and to a fair implementation of the block based
upon that assessment, and to complain if there were problems with
either of these.
              -- Silverback


subject: [WikiEN-l] Fvw's abuse of admin powers

body:
> On 10/6/05, MacGyverMagic/Mgm wrote:
> > If the autoblocker causes so much problems for 3RR blocks, then we
> > could ask the developers to make autoblocking optional. Have a nice
> > clickable 3RR box in the block screen which switches off autoblocking
> > for 3RR blocks.
> >
> > Of course, if one would follow a 1 or 2RR this wouldn't even be an issue.
>
> I'm not inclined to care a whole lot. People who hit the 3RR have
> already gone beyond reasonable editing. Whether they get blocked for
> 24 hours or a week is not that great of a concern to me.
>
> Kelly

You don't care about the length of the block, yet on August 7th,
you didn't think blocking was punitive,  and you thought a violation 24 hours in the past was no longer significant.  Now
the violation is so unreasonable that the length of the block
is no concern.  Care to explain the change of heart?

    Blocking this editor at this point would not serve the purpose
    of the 3RR as the edits are nearly 24 hours old anyway and the
    article is currently protected. Please note that the purpose of
    the 3RR is as a tripwire to stop edit warring; it is not punitive.
    I therefore recommend against blocking him.
    Kelly Martin 14:27, August 7, 2005 (UTC)


subject: [WikiEN-l] a valid criticism

body:
>> Today I summarily removed the Featured Article status from an article,
>> [[Iraqi insurgency]], because it's now such an unholy mess, with two
>> competing versions each pushing a point of view, and full of
>> unreferenced
>> statements and opinions represented as fact. And yet that article
>> survived a
>> move to remove its featured status as recently as June, 2005.
>> Assuming that
>> the earlier version really was better than the mess that exists today,
>> perhaps it would be as well to revert to that version and to find
>> ways to
>> incorporate later work on this current event without degrading it.

Yes. Maintaining a featured article is a pretty thankless job :).

Thanks,
Ryan

[[User:RN]] at wikipedia: http://en.wikipedia.org/wiki/User:RN
Ryan Norton at wxforum: http://wxforum.org


from_name: Jamie Bliss

subject: [Wikitech-l] Re: MMCache vs. eAccelerator

body:
Jeremy Dunck wrote:
> I see that MW 1.5 supports 2 object caching methods.
>
> Is one preferred, or are they considered interchangable?

One is not prefered as far as MW goes, but you should know the
background behind them.

eAccelerator is the "successor" of Turck MMCache. The primary developer
for Turck was hired by Zend and so Turck was fairly considered "abandoned".

eAccelerator branches off of Turck. However, due to
copyright/patent/etc. issues with Zend, they have been forced to develop
a new architecture.

eAccelerator, in our enviroment, has caused much grief, especially in
combination with WordPress (go figure). (endeavour.zapto.org and its
hosted sites are what I am talking about.) The reason we keep it
installed is so that BrickWiki has some scrap of performance.

MediaWiki only uses Turck/eAccel for shared memory management (faster
caching that SQL). Both of these apps also cache parsed scripts
(speeding startup time) and may even optimize them (speeding execution
time, hopefully).

The bottom line is to do your own testing before making a decision.

-- Jamie
-------------------------------------------------------------------
http://endeavour.zapto.org/astro73/
Thank you to JosephM for inviting me to Gmail!
Have lots of invites. Gmail now has 2GB.


from_name: Geoff Burling

subject: [WikiEN-l] a valid criticism

body:
On Sat, 8 Oct 2005, BJ?rn Lindqvist wrote:

> I don't know
> why, but I feel that it is much easier to write well-written emails
> than coherent encyclopedic prose. I suspect that atleast some other
> Wikipedians have the same problem.

Part of the problem is that it is often easier to talk about doing
something than actually doing it. I suspect that often we all are
seduced by the easier choice. ;-)

But a larger problem is that with finite amounts of time, all of us are
faced with the quandry of devoting this time to (1) writing new articles;
(2) improving existing articles; or (3) devoting ourselves to discussions
about procedure or the first two.

I try to spend a couple of hours a day online with Wikipedia, & usually
spend as much time offline doing research -- or writing. Sometimes I
can write an article in 15 minutes; sometimes it takes 6 months, &
that article will look worse than the one I spent 15 minutes on.
There is the problem that I have to accept that I will never get an
article into a "polished" state, & a rough draft at least has the
chance of attracting someone who will improve on what I wrote. And
then there is the problem that a given forum -- AfD, a poll , a meta
or a talk page, or even this email list -- requires attention, & I
have to put some of my other work on hold to pitch in. (I don't mean
to sound as if I'm complaining here: I'm just stating that I can only
do so much; frankly I am in awe at all of you who can not only
contribute content to Wikipedia but effectively participate in several
fora at once.)

[snip]

> Also, the
> longer the text, the harder it is to add to it without "destroying
> it." It's like software development - introducing a new feature often
> requires you to redesign the whole (or large parts of) the program
> again. In programming, the answer is to always think ahead, structure
> your code and refactor often. But Wikipedians already employ those
> techniques with small incremental edits that slowly but surely make
> bad articles better.
>
BJ?rn makes a good point here: there are technical reasons why it is
hard to keep the quality of an article high (such as the difficulty of
gracefully inserting more content into an article). Sometimes we can
borrow tricks from the programming world (e.g., structure our content
into sections more often), but sometimes an article must get worse
before it can get even better.

I'm just throwing out some ideas here in this email. The only suggestion
I have is that if the quality of existing articles becomes bad enough,
maybe we should declare a moritorium on new articles until the quality
of enough articles is up to snuff. But I'm not sure I'd want to deal
with the fallout from that decision.

Geoff


subject: [WikiEN-l] Merge vs. Keep/Delete

body:
On 10/8/05, Alphax <alphasigmax at gmail.com> wrote:
>
>
> So history merges are useful only for cut-and-paste moves?
>

Yes, pretty much. The problem with history merges is that the software
provides no means of unmerging elements from the history. One they're there,
there's no way to get them out again.


body:
On 10/8/05, actionforum at comcast.net <actionforum at comcast.net> wrote:
>
>
> Those who edit war are still entitled to a fair assessment of the alleged
> 3RR violation evidence, and to a fair implementation of the block based
> upon that assessment, and to complain if there were problems with
> either of these.
>

Possibly. I think opinion is divided on this. My personal opinion is that
edit warring should be deprecated to the point where those who edit war
should have no expectation of a strict interpretation of the rules. In
general a block on a party that is seen as edit warring tends to attract
popular support, so IAR applies well here.


from_name: Evan Martin

body:
On 10/8/05, Jeremy Dunck <jdunck at gmail.com> wrote:
> Can someone give me a ballpark size for this file (uncompressed) so I
> know how to deal with it?

In http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/19674
, Brion  found 4.74x compression for similar data with gzip.

32171234059 * 4.74 = 152.49g

Hope this helps!


from_name: Lars Aronsson

subject:
[Foundation-l] Authoring on wikijunior : providing private
	information.

body:
Robert Scott Horning wrote:

> In addition, one of the reasons I asked for this information is
> that I intend to do a formal copyright registration on
> Wikijunior books when I send them into print format.

To avoid further confusion, it should be pointed out that this
"copyright registration" is something that only exists in the
United States.  Earlier (before 1978) the U.S. had a copyright
law that required copyrights to be registered, much like patents
work in other countries.  If you didn't register, anybody could
claim copyright to your text.  The registration was not made at
the patent office, but at the U.S. Copyright Office, which is a
part of the Library of Congress, www.copyright.gov

After the
http://en.wikipedia.org/wiki/United_States_Copyright_Act_of_1976
went into effect on January 1, 1978, copyright is automatically
granted to anybody who creates a work (text, music, software,
etc.), just like it works in other countries.  This opened up a
possibility of doubt about who owns the copyright to a work.
Therefore, the copyright office and its registration is still
available, as a safety measure, but this is a voluntary option.

The article http://en.wikipedia.org/wiki/Copyright
says "In the United States, copyright has relatively recently been
made automatic".  The idea that copyright must be "obtained" is
still very much part of the American way of thinking.  To many
Europeans this concept is as foreign as slavery.

I am not a lawyer.

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


from_name: Ting Chen

subject:
[WikiEN-l] Fix "auto-IP blocks last past the original block" (Bug
	856 in Bugzillar)

body:
Hello folks,

I have just submitted a patch to the problem, that sometimes a user is
blocked longer than is intended. The problem is described as following and
is submitted as Bug 856 in Bugzillar:

If a user is blocked, say for 2 hours. And he tries to make some edit
though. Then the IP he uses would be also blocked for the timespan. If he
tries to make some edit a second time, then his IP would be blocked for
another day, exceeding the priviosly defined 2 hours.

The patch I submitted should fix this bug. The auto-block should never
exceed the user-block in any case.

Thanks
Ting

--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner


list: wikipedia-l

subject:
[Wikipedia-l] Fix "auto-IP blocks last past the original block"
	(Bug 856 in Bugzillar)


subject:
[Wikitech-l] Fix "auto-IP blocks last past the original block" (Bug
	856 in Bugzillar)


from_name: Jimmy Wales

subject: [WikiEN-l] a valid criticism

body:
Fastfission wrote:
> But clearly "obscurity" is not the factor which determines a good or
> bad article. Plenty of articles on obscure people are very good and
> plenty articles on very simple things can be quite bad. But still, he
> did not, of course, give any rationale for these two articles except
> that they exemplify the fact that Wikipedia is edited by amateurs and
> sometimes has spotty content. So what?

It disappoints me to hear a Wikipedian take this attitude towards
quality.  "So what?"  So -- we're trying to be better than this, that's
what.

> But nobody's making excuses here. I'm just saying that you will always
> be able to find sore spots if you want to. If you believe in the
> Wikipedia way, what you do is try to fix them or call them to the
> attention to others. If you don't, then you write pissy articles about
> them.

I don't think this is what our general response to this sort of
complaint should be.  I think our response should be: hey, you know
what, he's right!  These articles ought to be pretty decent, but they
aren't.  Why?  What can we do to improve?

If we study it up one side and down the other and conclude that there is
nothing to be done about it, then fine.  But we should not just accept
the current state of affairs if there are sensible proposals for
improvement.

> We're not making software, here -- just because some parts of it are
> spotty doesn't mean the entire package won't work. In that way we're a
> lot less restrained than the open source software projects and can
> afford to have a philosophy of eventualism.

I don't have a problem with eventualism -- but 'eventualism' is not the
same as saying "so what?" to quality problems.

--Jimbo


subject: [WikiEN-l] a valid criticism

body:
Tony Sidaway wrote:
> On 10/7/05, Jimmy Wales <jwales at wikia.com> wrote:
>>I'm a big fan of eventualism. But Bill Gates and Jane Fonda are not new
>>articles, nor are they difficult or obscure subjects. Nor are the
>>problems I'm _currently_ concerned about with these articles problems
>>resulting from a lack of knowledge. They are stylistic problems which
>>are pretty awful.
>
> I think you've put your finger on the problem there. The mechanisms by which
> Wikipedia articles improve and degrade are not fully understood, and there
> may well be some complex factors that we don't consider seriously enough.
>
> But we can make a stab at guessing the main factor: entropy. An article that
> is edited frequently by many people will probably degrade quickly

I don't disagree with you, but it occurs to me that this is at least
roughly a testable hypothesis.

> One idea I suggested a while back, half jokingly, is that it should be
> possible to make a group decision to revert to an earlier version of an
> article. Articles do degrade and it may sometimes be a good idea to
> recognise that the overall effect of recent edits has been to destroy what
> was good about the article.

Of course, right now, there's no real need for a group decision to do
this.  It's perfectly acceptable (if a bit bold) to dig back six months
into the past and resurrect an older version of an article before it
went downhill.  "Something went badly off track back there, so I
resurrected the old article and seek help in incorporating any positive
changes from intervening versions in a way that doesn't make the article
read like chopped liver" sounds like a great thing to write on the talk
page.

> Today I summarily removed the Featured Article status from an article,
> [[Iraqi insurgency]], because it's now such an unholy mess, with two
> competing versions each pushing a point of view, and full of unreferenced
> statements and opinions represented as fact. And yet that article survived a
> move to remove its featured status as recently as June, 2005. Assuming that
> the earlier version really was better than the mess that exists today,
> perhaps it would be as well to revert to that version and to find ways to
> incorporate later work on this current event without degrading it.

I agree completely.

--Jimbo


subject: [WikiEN-l] a valid criticism

body:
On 10/7/05, Jimmy Wales <jwales at wikia.com> wrote:
>
> I'm a big fan of eventualism. But Bill Gates and Jane Fonda are not new
> articles, nor are they difficult or obscure subjects. Nor are the
> problems I'm _currently_ concerned about with these articles problems
> resulting from a lack of knowledge. They are stylistic problems which
> are pretty awful.
>

I think you've put your finger on the problem there. The mechanisms by which
Wikipedia articles improve and degrade are not fully understood, and there
may well be some complex factors that we don't consider seriously enough.

But we can make a stab at guessing the main factor: entropy. An article that
is edited frequently by many people will probably degrade quickly. An
article that doesn't start out with a firm structure will not improve until
a single person or a tightly organized group imposes such a structure. An
article that is part of a series of similar articles that are edited by the
same group of people will tend to have a structure similar to the others in
the series.

We can help people to improve articles by preserving examples of articles
which are the best of their class: exhibiting superior structure, subject
coverage, and writing style. We can give recognition to editors who perform
extraordinarily good improvements on articles. I think we already do some of
these things.

One idea I suggested a while back, half jokingly, is that it should be
possible to make a group decision to revert to an earlier version of an
article. Articles do degrade and it may sometimes be a good idea to
recognise that the overall effect of recent edits has been to destroy what
was good about the article.

Today I summarily removed the Featured Article status from an article,
[[Iraqi insurgency]], because it's now such an unholy mess, with two
competing versions each pushing a point of view, and full of unreferenced
statements and opinions represented as fact. And yet that article survived a
move to remove its featured status as recently as June, 2005. Assuming that
the earlier version really was better than the mess that exists today,
perhaps it would be as well to revert to that version and to find ways to
incorporate later work on this current event without degrading it.


subject: [WikiEN-l] The 3RR is an electric fence, not an entitlement.

body:
On 10/8/05, steve v <vertigosteve at yahoo.com> wrote:
>
>
> 2) that your (or other's) implied or stated assumption
> that tag-teaming an issue is simply an aspect of
> consensus is false down to its toe fungus.

I'm sorry that's simply incorrect. Your use of the term "tag teaming" here
is prejudicial and misrepresents what is happening: one person tries to
impose his will on an article while two or more oppose him. This is an
informal consensus, and the solo editor is ignoring that consensus.


body:
On 10/8/05, steve v <vertigosteve at yahoo.com> wrote:
>
> 3RR is great when used properly, but Im not sure it is
> consistently used in a proper way.
>
> 1) there is no binding review of anything except the
> Arbcom
>

That's incorrect. Any 3RR block imposed by any administrator can be
challenged by any editor and reversed by any other administrator. Community
consensus in this matter is binding.


from_name: Gerard Meijssen

body:
?var Arnfj?r? Bjarmason wrote:
> The reason I didn't create these when I created ilo is:
>
> * Samogitian, Banyumasan, Ripuarian, Dutch-Low Saxon: Don't have an
> ISO code (nds-nl claims to have one but that looks like a
> pseudo-ISO-code)
> *  Banyumasan, Ripuarian are dialects according to Wikipedia,
> Dutch-Low Saxon appears to be some kind of dialect as well.

Hoi,
The problem with Low Saxon is that some people have high jacked the Low
Saxon Wikipedia by insisting on a German dominated orthography. Because
of the incompatibility that this creates with the Dutch Low Saxon, there
is this need for a separate wikipedia. To make matters even more weird,
one of the persons insisting on this Sass orthography is not even a
Lower Saxon speaker but is one who does contribute to the nds.wikipedia
for a hobby.

Then again, I am not interested in the nds.wiktionary.org really. But
denying the nds-nl wikipedia because of this is not just.

Thanks,
    GerardM


from_name: Arbeo M

body:
--- Mark Williamson <node.ue at gmail.com> schrieb:

> It seems very clumsy to have the "binomial"
> subdomains, as in roa-rup:
> (which now has its own ISO code, rup), fiu-vro:...
> so I think it's
> best to search for possible alternatives. Samogitian
> and Banyumasan
> may not have good alternatives, but I would imagine
> that there's an
> ISO/DIS 639-3 code for Riparian, which I hope we
> could use.
>
Good point, the binomal codes are very clumsy indeed
and most people not familiar with the standard they
are based upon will probably wonder why're choosing
them.

A possible alternative has just crossed my mind: why
not use four-lettered codes for languages that don't
have an iso code (yet)? That would allow us to pick
abbreviations that users can memorize more easily
while not interfering with any existing or potential
future iso codes. (e. g. "samo" for Samogitian, "bany"
or maybe "wjav" - to include all Western Javanese
dialects - for Banyumsan, "ripu" for Ripuarian and so
forth)

Arbeo

___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de


from_name: Delirium

subject: [WikiEN-l] a valid criticism

body:
Jimmy Wales wrote:

>>But nobody's making excuses here. I'm just saying that you will always
>>be able to find sore spots if you want to. If you believe in the
>>Wikipedia way, what you do is try to fix them or call them to the
>>attention to others. If you don't, then you write pissy articles about
>>them.
>>
>>
>
>I don't think this is what our general response to this sort of
>complaint should be.  I think our response should be: hey, you know
>what, he's right!  These articles ought to be pretty decent, but they
>aren't.  Why?  What can we do to improve?
>
>
Well, in principle, *all* our articles should be pretty decent, but we
have nearly a million of them in en: now, so that takes some time.  Even
if you take only all high-profile articles, there's at least a few
thousand of them, so the fact that someone can find 2 of those thousands
that aren't very good at one particular moment in time isn't
particularly convincing.

I'm not convinced that any general problem has been illustrated in terms
of the editing process.  If anything, the main thing illustrated (which
is already recognized) is that we don't have a good way yet of marking
particular revisions as high quality.  If we did implement a sort of
'sifter' project, as long-contemplated, and people found crappy articles
among /those/, then we'd have a demonstrated problem.

-Mark


subject: [WikiEN-l] a valid criticism

body:
Delirium wrote:
> Well, in principle, *all* our articles should be pretty decent, but we
> have nearly a million of them in en: now, so that takes some time.  Even
> if you take only all high-profile articles, there's at least a few
> thousand of them, so the fact that someone can find 2 of those thousands
> that aren't very good at one particular moment in time isn't
> particularly convincing.

*nod*  Ok, I see your point.  What I wonder is if we could identify a
particular class of articles and discover that they tend to be bad in a
particular way and then do something about it.

In the case in hand, we have "Bill Gates" and "Jane Fonda" -- they are
similar in that they are both living famous Americans who are
controversial.  The problems with the articles are similar in that the
problem isn't so much bias or lack of factual accuracy, as it is bad
writing.

Are the biographies of other living famous Americans who are
controversial similarly godawful?

Here's a test: Bill Clinton, Michael Moore, Sean Penn, Ann Coulter

I wonder how those are, and I'll be studying them on the plane home
tomorrow....

/me goes to download and save.

--Jimbo


body:
If editors are supposed to take great writing seriously, we must give it the
highest possible award.

Jimmy Wales, here's something you could make happen.

I *demand* that we have a guaranteed daily place on the main page, to be
reserved solely for articles chosen for their great writing.

Anything less is a display of lack of commitment in our goal--to be as good
as, or better than, any other encyclopaedia, free or otherwise, with
digraphs or without.


body:
On 10/8/05, Mark Pellegrini <mapellegrini at comcast.net> wrote:
>
> Tony Sidaway wrote:
> "I *demand* that we have a guaranteed daily place on the main page, to
> be reserved solely for articles chosen for their great writing."
>
> We have that. It's called the daily featured article.
>

No. An article can make FA even if the writing is pretty rubbish, and good
writing doesn't guarantee FA status. From a recent featured article:

"Although 64 kB of RAM was very expensive, Tramiel knew that
DRAM<http://en.wikipedia.org/wiki/DRAM>prices were falling, and that
it would eventually drop to an acceptable
level before going into full production."


from_name: Quistnix

body:
Gerard Meijssen wrote:

> ?var Arnfj?r? Bjarmason wrote:
>
>> The reason I didn't create these when I created ilo is:
>>
>> * Samogitian, Banyumasan, Ripuarian, Dutch-Low Saxon: Don't have an
>> ISO code (nds-nl claims to have one but that looks like a
>> pseudo-ISO-code)
>> *  Banyumasan, Ripuarian are dialects according to Wikipedia,
>> Dutch-Low Saxon appears to be some kind of dialect as well.
>
>
> Hoi,
> The problem with Low Saxon is that some people have high jacked the Low
> Saxon Wikipedia by insisting on a German dominated orthography. Because
> of the incompatibility that this creates with the Dutch Low Saxon, there
> is this need for a separate wikipedia. To make matters even more weird,
> one of the persons insisting on this Sass orthography is not even a
> Lower Saxon speaker but is one who does contribute to the nds.wikipedia
> for a hobby.
>
> Then again, I am not interested in the nds.wiktionary.org really. But
> denying the nds-nl wikipedia because of this is not just.
>
> Thanks,
>    GerardM

Low Saxon covers a large variety of dialects, both in the Netherlands
and in Germany. Insisting on a German-based orthograpy for all dialects
is unrealistic. Therefore I agree with Gerard that if nds.wikipedia
takes this step, there is a need for a separate nds-nl wikipedia.

Highjacking is the correct word for what has happened. It is an
unnecessary act of intolerance, that unnecessary splits a community,
united by a common language across different countries into two groups,
living at the opposite sides of a national border. And now, for some
obscure reason, one of these groups is denied the right to have its own
wikipedia, so even splitting seems impossible.

Anton


from_name: Daniel Kinzler

subject:
[Wikitech-l] Two patches that would make things much easier for
	bots and scripts

body:
Hi all

I propose two small changes to MediaWiki, which would allow scripts and
bots to parse the HTML output of MediaWiki more easily. (I'm
crossposting this to wikitech-l and pywikipediabot-users, because it's
relevant to both).

The first proposal is a minimal skin that adds only the absolutely
necessary HTML around the article content. This would remove a lot of
overhead for bots (in terms of parsing and loading), and meight also be
handy for people using a PDA or cell phone to browse a wiki; This way,
server load would also be reduced (a little). Here's the feature request
(patch included): http://bugzilla.wikimedia.org/show_bug.cgi?id=3651

The second proposal is a pseudo-language, called "bot" or "none", that
would cause MediaWiki to return system messages untranslated, in the
form {@[key]@}. This way, system messages can be regognized and parsed
easily - no need to deal with different languages, or with people
changing the message. This would also save some effort on the server
side (no need to look into the database for messages). Here's the
feature request (patch included):
http://bugzilla.wikimedia.org/show_bug.cgi?id=3652

Hint: you can force a specific skin and language to be used by adding
uselang=bla (resp. useskin=bla) to the URL. This also works without
logging in.

Both patches are not intended to replace a full featured bot API. They
are simple hacks that can be applied without much pain. Bots would only
need minimal changes to be able to use those features. Much breakage due
to changin system messages could be avoided that way, for instance.

Please give some feedback. If you like my proposals, please comment in
bugzilla, so we may actually get this running on Wikimedia's servers soon.

Cheers,
Daniel

--
Homepage: http://brightbyte.de


from_name: Servien Ilaino

body:
Well since people are being so fussy, but there is no reason to be
because if people only knew the cultural point and the details about
DLS they'd know it's necessary. People agree there should be one but
other don't (which are supprisingly people who are not gonna
participate and don't know DLS nor do they speak Dutch or German Low
Saxon) I have given up on this wiki, it's REALLY irritating, I'm sick
of answering dumb questions from non-native speaker who vote against
the wiki for "problems" which can be solved by letting the community
decide on the writing system. People who want to start another dialect
Nds wiki, which I really don't recommend, are gonna have a hard time.
Same really goes for any wiki!

Servien

2005/10/8, Arbeo M <arbeo_m at yahoo.de>:
>
> --- Mark Williamson <node.ue at gmail.com> schrieb:
>
> > It seems very clumsy to have the "binomial"
> > subdomains, as in roa-rup:
> > (which now has its own ISO code, rup), fiu-vro:...
> > so I think it's
> > best to search for possible alternatives. Samogitian
> > and Banyumasan
> > may not have good alternatives, but I would imagine
> > that there's an
> > ISO/DIS 639-3 code for Riparian, which I hope we
> > could use.
> >
> Good point, the binomal codes are very clumsy indeed
> and most people not familiar with the standard they
> are based upon will probably wonder why're choosing
> them.
>
> A possible alternative has just crossed my mind: why
> not use four-lettered codes for languages that don't
> have an iso code (yet)? That would allow us to pick
> abbreviations that users can memorize more easily
> while not interfering with any existing or potential
> future iso codes. (e. g. "samo" for Samogitian, "bany"
> or maybe "wjav" - to include all Western Javanese
> dialects - for Banyumsan, "ripu" for Ripuarian and so
> forth)
>
> Arbeo
>
>
>
>
>
>
> ___________________________________________________________
> Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
Please let me know if I should continue with this almost impossible
battle or if I should just stop here and just let the project go. I
initially requested the wiki for people in the Netherlands to be able
to write in their own language, since nds is far from even being
comprehensible with DLS, and since most/if not all DLS dialects are
mutually comprehensible I decided to create a nds wiki with a Dutch
orientated writing style and grammar (which most/if not all DLS
dialects have). If people only want a German version of this than
that's fine (discrimination; but who cares) but personally I'd like to
see a Dutch version of this as well.

Servien

2005/10/8, Servien Ilaino <servien at gmail.com>:
> Well since people are being so fussy, but there is no reason to be
> because if people only knew the cultural point and the details about
> DLS they'd know it's necessary. People agree there should be one but
> other don't (which are supprisingly people who are not gonna
> participate and don't know DLS nor do they speak Dutch or German Low
> Saxon) I have given up on this wiki, it's REALLY irritating, I'm sick
> of answering dumb questions from non-native speaker who vote against
> the wiki for "problems" which can be solved by letting the community
> decide on the writing system. People who want to start another dialect
> Nds wiki, which I really don't recommend, are gonna have a hard time.
> Same really goes for any wiki!
>
> Servien
>
> 2005/10/8, Arbeo M <arbeo_m at yahoo.de>:
> >
> > --- Mark Williamson <node.ue at gmail.com> schrieb:
> >
> > > It seems very clumsy to have the "binomial"
> > > subdomains, as in roa-rup:
> > > (which now has its own ISO code, rup), fiu-vro:...
> > > so I think it's
> > > best to search for possible alternatives. Samogitian
> > > and Banyumasan
> > > may not have good alternatives, but I would imagine
> > > that there's an
> > > ISO/DIS 639-3 code for Riparian, which I hope we
> > > could use.
> > >
> > Good point, the binomal codes are very clumsy indeed
> > and most people not familiar with the standard they
> > are based upon will probably wonder why're choosing
> > them.
> >
> > A possible alternative has just crossed my mind: why
> > not use four-lettered codes for languages that don't
> > have an iso code (yet)? That would allow us to pick
> > abbreviations that users can memorize more easily
> > while not interfering with any existing or potential
> > future iso codes. (e. g. "samo" for Samogitian, "bany"
> > or maybe "wjav" - to include all Western Javanese
> > dialects - for Banyumsan, "ripu" for Ripuarian and so
> > forth)
> >
> > Arbeo
> >
> >
> >
> >
> >
> >
> > ___________________________________________________________
> > Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>


body:
BTW: looked up the word "consensus", it says: "a generally accepted
opinion or decision among a group of people". This of course meaning
the MAJority's vote is accepted and not the MINority....

Serv

2005/10/8, Servien Ilaino <servien at gmail.com>:
> Please let me know if I should continue with this almost impossible
> battle or if I should just stop here and just let the project go. I
> initially requested the wiki for people in the Netherlands to be able
> to write in their own language, since nds is far from even being
> comprehensible with DLS, and since most/if not all DLS dialects are
> mutually comprehensible I decided to create a nds wiki with a Dutch
> orientated writing style and grammar (which most/if not all DLS
> dialects have). If people only want a German version of this than
> that's fine (discrimination; but who cares) but personally I'd like to
> see a Dutch version of this as well.
>
> Servien
>
>
> 2005/10/8, Servien Ilaino <servien at gmail.com>:
> > Well since people are being so fussy, but there is no reason to be
> > because if people only knew the cultural point and the details about
> > DLS they'd know it's necessary. People agree there should be one but
> > other don't (which are supprisingly people who are not gonna
> > participate and don't know DLS nor do they speak Dutch or German Low
> > Saxon) I have given up on this wiki, it's REALLY irritating, I'm sick
> > of answering dumb questions from non-native speaker who vote against
> > the wiki for "problems" which can be solved by letting the community
> > decide on the writing system. People who want to start another dialect
> > Nds wiki, which I really don't recommend, are gonna have a hard time.
> > Same really goes for any wiki!
> >
> > Servien
> >
> > 2005/10/8, Arbeo M <arbeo_m at yahoo.de>:
> > >
> > > --- Mark Williamson <node.ue at gmail.com> schrieb:
> > >
> > > > It seems very clumsy to have the "binomial"
> > > > subdomains, as in roa-rup:
> > > > (which now has its own ISO code, rup), fiu-vro:...
> > > > so I think it's
> > > > best to search for possible alternatives. Samogitian
> > > > and Banyumasan
> > > > may not have good alternatives, but I would imagine
> > > > that there's an
> > > > ISO/DIS 639-3 code for Riparian, which I hope we
> > > > could use.
> > > >
> > > Good point, the binomal codes are very clumsy indeed
> > > and most people not familiar with the standard they
> > > are based upon will probably wonder why're choosing
> > > them.
> > >
> > > A possible alternative has just crossed my mind: why
> > > not use four-lettered codes for languages that don't
> > > have an iso code (yet)? That would allow us to pick
> > > abbreviations that users can memorize more easily
> > > while not interfering with any existing or potential
> > > future iso codes. (e. g. "samo" for Samogitian, "bany"
> > > or maybe "wjav" - to include all Western Javanese
> > > dialects - for Banyumsan, "ripu" for Ripuarian and so
> > > forth)
> > >
> > > Arbeo
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___________________________________________________________
> > > Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l at wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> > >
> >
>


from_name: fallout at lexx.eu.org

body:
> No. An article can make FA even if the writing is pretty rubbish,

But it shouldn't.

> good writing doesn't guarantee FA status. From a recent featured
> article:

{{sofixit}}.

Ausir


from_name: Ryan Delaney

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

geni wrote:

>
>Who cares what consensus is? What matters is what is right. Edit
>waring has it's uses. For some reason it seems to be an effective way
>of increaseing the number of citations.
>
This comment baffles me. There are a lot of things I find wrong with
it, but I'll stick with this: Maybe a better way to increase the
number of citations, rather than edit warring, would be to /add them/.

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

iD8DBQFDSGzn6MKb8lYmCtcRAmmNAJ9JTOYcyNlRr2s5HjF1wtWY8NgsYQCcDUu5
IpDdos8RgejTxv1Mt/L+6u8=
=3Ddc
-----END PGP SIGNATURE-----