from_name: Gregory Maxwell

body:
On 6/8/06, GerardM <gerard.meijssen at gmail.com> wrote:
> I do however want to address Amgine's point. There is one important
> difference between Commons and Napster. On Commons people are actively
> engaged in ensuring that content is properly labeled and licensed.
> This is in marked contrast with Napster where the defence was that
> they were only providing a service and that it was not THEIR content.

Considering that we've had violations persist for months after they
were tagged and even brought up in a Wikimedia board meeting, I'd say
that our position is even weaker than napsters.

At least napster was obviously at-your-own-risk.   As things stand
today I think it would be irresponsible for us to encourage others to
use content taken from commons automatically.  Yes, people can browse
commons and upload, but that means at least one person other than the
uploader has had a chance to consider the copyright impact.  With
instant commons, some drive-by anonymous editor types in
[[Image:Cat.jpg]] and you may suddenly have a violation.

> Given that everything is done to make Commons free of copyrighted
> articles and given that Commons explicitly aims to be a public
> resource for Free material. It is stupid to suggest that this cannot
> be because not everything has been 100% checked. Either it is a public
> resource or it is not. You cannot have it both ways.

I don't follow.   Instant commons as proposed would enable the
automated propagation of content without any real human oversight.
That seems quite dangerous.

Consider.
Sue holds the copyright to a book cover which includes pretty flowers.

John is not bright and uploads it to commons as pretty_flowers.jpg
tagged as "Public Domain".
Because our interface is so helpful, his tagging looks well formed and valid.

Over several months various Wiki's pick it up via instant commons.

Sue notices, and asks us to take down this obvious violation. We do,
but now sue is left playing wack-a-mole with hundreds, if not
thousands, of sites. Many of whom are still distributing the content
with a notice that it's public domain.

What a mess.

We've avoided a lot of problems with copyright holders on media by
simply being very responsive. While we've had instances of people
quite angry at us over mirrored text that we can't control.  Images
are an especially weak point for us from a copyright perspective, so
our ability to be more responsive (due to a lack of mirroring) has
been fortunate.

> What InstantCommons does is nothing more than make the material that
> is there as a public resource available in a convenient way.

As proposed it is also a vehicle where any irresponsibility on our
part can lead to greatly increased harm.  Care should be taken to
avoid this.


list: wikimedia-l

source: pipermail-mbox

subject: [Foundation-l] Instant Commons : INCORRECT


list: foundation-l

from_name: Jimmy Wales

body:
Anthere wrote:
> Erik Moeller wrote:
>> On 6/8/06, Jimmy Wales <jwales at wikia.com> wrote:
>>
>>> I will never allow you to use the Wikimedia Foundation name to raise
>>> money for a project with no written proposal, no budget, no
>>> professionalism, just "trust us, it's a cool idea".
>>
>> I wrote specifications, a budget and a full proposal for Kennisnet in
>> February.
>
> We have never seen a detailed budget (though we asked).
>
> This proposal named the developers, the roles and
>> responsibilities, and the duration of development.
>
> We have not received a timeline (despite repeated requests)
>
> The proposal, as
>> written in February, is at
>> http://scireview.de/temp/instantcommons_2.odt
>
> ...
> I can not read .odt...
> (shame...)
>
> I suddenly wonder if we got all the right documents...
> I suspect not...

No, you got the right documents.  It was just hopelessly inadequate, I
am afraid.

--
#######################################################################
#    Office: 1-727-231-0101       |  Free Culture and  Free Knowledge #
#    http://www.wikipedia.org     |     Building a free world         #
#######################################################################


from_name: Anthere

body:
Erik Moeller wrote:
> On 6/8/06, Jimmy Wales <jwales at wikia.com> wrote:
>
>>I will never allow you to use the Wikimedia Foundation name to raise
>>money for a project with no written proposal, no budget, no
>>professionalism, just "trust us, it's a cool idea".
>
>
> I wrote specifications, a budget and a full proposal for Kennisnet in
> February.

We have never seen a detailed budget (though we asked).

This proposal named the developers, the roles and
> responsibilities, and the duration of development.

We have not received a timeline (despite repeated requests)

The proposal, as
> written in February, is at
> http://scireview.de/temp/instantcommons_2.odt

...
I can not read .odt...
(shame...)

I suddenly wonder if we got all the right documents...
I suspect not...

> Kennisnet was ready to approve the project as such if Wikimedia was
> happy with it.

... if Wikimedia was happy with it...

I believe SP has received the same document. Let me know
> if that is not the case.

Errrr, can you make a pdf ?

Thanks

ant

> Since then, the only major thing that has happened from my point of
> view is that I answered to some questions that came from SP (via
> Legal). For the most part, there was nothing in there that could not
> have been worked out as the project moves along -- see my response
> from April:
> http://mail.wikipedia.org/pipermail/spcommittee-l/2006-April/000078.html
>
> Erik


body:
On 6/8/06, Erik Moeller <eloquence at gmail.com> wrote:
> On 6/8/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > I have some questions from a technical perspective.
> Before I answer these, let me ask if you agree with this being a
> reasonable idea in general. If it is, then for me it means that
> technical details should be worked out by technical people as the
> project moves along. Kennisnet actually told us that the proposal was
> more technically detailed than it needs to be in order to be funded.

Fundamentally I think it's a good idea, however our current lack of
due diligence in ensuring the copyright status of works uploaded to
commons, and the total lack of a plan to achieve acceptable oversight
may make the entire proposal a non-starter even ignoring any technical
factors.

> > 1. What is the purpose of the XML-RPC subsystem?   Since the images
> > are fetched via HTTP in any case, why not simply perform the existence
> > test via simple HTTP as well.   If that were done no modifications
> > would be needed on the commons side.
>
> There are future queries where the subsystem would come in handy, such
> as: show me the available, pre-rendered thumbnails, a list of
> conversion services, etc. Some of these are mentioned in the specs.

What is the purpose of having conversion services? Why not go a step
further and simply offer to host everyone's Wiki's?  Not that I'd
suggest that, but I don't see where the dividing line is that would
suggest we perform a lot of high touch services but not simply host
wikis for people.

It appears to me that this aspect of the proposal is asking for a vast
increase in complexity in the name of some ill defined future features
for which the XML-RPC interface may turn out to be ill suited should
such features ever be implemented.

> > 2. It would appear from the specification that their is no facility
> > for caching failures.
>
> Sure, the system should cache non-existence, but given that we
> anticipate fairly low usage to begin with, and given that the process
> of adding and reviewing an image is interactive, I do not anticipate
> any major load resulting from putting that feature into a future
> version of MW even without such caching. MW has several caching
> mechanisms that would kick in anyway for pages that have already been
> viewed before. If it does cause problems, we can deactivate the
> Commons service entirely until the feature is improved.

What was the point of including technical detail in the proposal when
it was so poorly considered that we're left saying "Well, we can turn
it off until it's improved"?

> > 3. The proposed method of interwiki transclusion doesn't appear fully
> > formed enough to determine if it will be sufficiently strong to
> > prevent instant commons from accidentally becoming an automated system
> > for license violations.  In particular there doesn't appear to be any
> > strong assurance that attribution and license data will *always* be
> > available when the image is available.
>
> We don't have the same assurance for Commons usage within the
> Wikimedia projects either, I think.

Can you name a time when the bulk of our Wiki's have been accessible
and serving commons images, but the commons pages themselves were
inaccessible? With common administration it's not likely to be a real
problem, but the same is not true when we spread the content all over
the world.

What happens when the commons image is deleted but the remote wiki's
retain the image? It's also not at all clear to me that remote wikis
would be in conformance with various copyleft licenses if they
distribute the content without attribution or license data and then
refer users to a site operated by a third party.

Fortunately this is fairly easy to resolve. Carry a copy of the image
page with it.  A system without such a feature could probably not be
accepted for use with Wikis outside of the foundation.

> > 4. Although copyright concerns are mentioned, they don't seem to be
> > explored in depth. Commons has a huge amount of copyright violations
> > on it today.
>
> Then they should be deleted. InstantCommons is a manual,
> user-initiated process. Commons has no legal responsibility to stop
> users of other wikis from copying images from Commons, whether it is
> by means of manually downloading or uploading, or by setting their
> wiki up for IC and initiating an IC transfer process. The copyright
> cleanup script is a convenient thing we can provide, and by no means a
> legal necessity.

Copyright violations are deleted from commons but only very slowly,
and only after they are discovered by someone who understands the
process, or only after an official email comes.

We know commons frequently has content which we can not legally
distribute, but we're able to address it almost completely. Instant
commons as proposed will create a situation where we frequently can
not address it.

I think it's a little disingenuous to call it a 'manual process'.
Downloading an image from commons and uploading it to the local wiki
is a manual process. It gives an opportunity for someone to evaluate
the sanity of the copyright claims.  Instant commons image insertions
can be made blindly.  And unlike uploads which are easy to limit,
instant commons insertion can be done by anyone that can edit.  This
opens exciting new vandalism opportunities. Free penis images on every
Wiki in the land!

> > 5. If the remote wiki will download the full image in all cases, what
> > is the purpose of burdening commons with the additional transfer and
> > storage costs of their thumbnail generation?
> It's a service which we can choose to provide - for some wikis, for
> some file formats, etc. This is a policy choice for Wikimedia to make.

What evidence do we have that there is any interest in such a feature.
It's also true that with the right code the XML-RPC could be used to
have commons generate large prime numbers or spider the web looking
for evidence of Elvis. Why would we want to offer thumbnailing and not
elvis searching?

> The first iteration of IC could support SVG the same way it is
> supported today: If your local wiki doesn't have a backend rendering
> library, you can still upload them (locally or through IC), but you
> can't view them as rendered PNGs and scaled thumbnails. Future
> iterations could support SVGs through some XML-RPC based
> query/response mechanism for the PNGs, if Wikimedia wants to provide
> that service.

I don't see why XML-RPC is required. You can request commons create a
basic rasterized version today with a simple http request. In any
case, I doubt that we should be in the business of resource intensive
transformations for remote wikis.

> > There are also some more complex issues, like where the $5,000 EUR fee
> > comes from for what is, overall, such a simple feature set. But I
> > don't want to create a flood of comments initially.
>
> The feature set is reasonably simple. Do keep in mind that for a
> feature to be developed and for it to be "Brion-ready" generally takes
> some more time spent with testing, debugging, security review, etc.
> The developer is ready to use any surplus time for the purpose of
> developing Wikipedia content in one of the native languages of Ghana;
> Kennisnet was happy with that. Also keep in mind that this is his
> first MediaWiki project, so he'll need some tutoring from a skilled
> developer, which should be paid for.

5K EUR is almost two man months at the rates we pay our developers.
If this feature  as outlined will take more than a weeks time,
complete with debugging and the creation of a test suite then I
suspect we have over designed it, that we are paying too much, or
both.

Just because the funding will be donated does not excuse us from
fiscal responsibility if the foundations name will be attached.
Nothing is preventing this work from being done independent of the
foundation, funded by whatever means are available, and thus being
free from oversight or delay by the foundation.

If you're asking the foundation's name to be attached, then it would
be reasonable to explain the fees to the foundation to their
satisfaction, so that they can ensure that all donations taken in
their name are being effectively used.


body:
Board candidate platform...

Sigh

Ant

Erik Moeller wrote:
> On 6/7/06, Anthere <Anthere9 at yahoo.com> wrote:
>
>>I'd like that you make the effort to recognise that we are acting in
>>good faith
>
>
> This is not about good or bad faith, Florence. Of course the SP
> committee is acting in good faith - I never denied this. The point is
> that a 5000 EUR project that was essentially OK'd by Kennisnet in
> February is still not ready to go by June. The point is that at this
> organizational efficiency, we need not even dream of realizing any
> real grant proposals that are brought to us from the outside. I'd like
> _you_ to make the effort to recognize that the organization needs to
> fundamentally change in the way it does things if it does want to
> fulfill its charitable mission.
>
> I am very, very concerned that our promises about helping children in
> Africa are going to sound rather cynical when actual African projects
> (and InstantCommons is one) do not happen because the organization is
> so ineffective. _Especially_ in an all-volunteer organization, the
> approach which is currently taken -- a small group of people must make
> all the critical decisions, and new members are only recruited if
> there is consensus _within_ that group (_and_ ideally the Board) -- is
> not scalable. And it's certainly not scalable for a top 16 website
> with over a million registered users and hundreds, thousands of
> potential "special projects". Not to mention other projects besides
> Wikipedia which are badly in need of innovative thinking and creative
> partnerships. Not to mention that we're supposed to be multilingual.
>
> I have not seen a single announcement on this mailing list for an open
> SP-related meeting. Most of the discussions you need to have can be
> open without leaving a permanent record on the web -- publish edited
> logs or summaries where confidential information is concerned. You can
> accept advisors without even voting on them. And the core voting
> members should be those who do the most work of actually planning,
> coordinating and realizing projects as this becomes visible in a
> larger group.
>
> The notion that every contract has to be between the Wikimedia
> Foundation and another organization is also unnecessary -- contracts
> can be between volunteers and grant-giving organizations, if the
> grants are small and having the contracts managed by Wikimedia only
> adds unnecessary bureaucratic overhead. This way, Wikimedia adds
> organizational credibility for volunteers who deserve it.
>
> This could have been done with Kennisnet in February or March. Don't
> be overly afraid of  outcomes -- just dissociate yourself from
> projects which fail, and highlight those that succeed. And for
> Christ's sake, don't worry all the time about legal risks. Legal risks
> can be addressed as a project develops. Wikipedia is an insanely bad
> idea from a legal point of view and would never have been started
> through _any_ process which we are actually using in our organization
> to start things.
>
> Build _many_ relationships with people you can trust, instead of
> building _few_ relationships with people you'd like to take out for
> dinner.
>
>
>>We are under no obligation to spend hours studying
>>your proposals
>
>
> How about you start _trusting_ me, Gerard and other volunteers when we
> come to the Foundation and say: "This here is a moderately cool
> project that these people over there are willing to pay for, but
> they'd like to get an OK from the Foundation." Again, I ask: Why could
> the SP committee not simply have sent the authorization to Kennisnet,
> and let the contract side of things be handled between Gerard and
> them? Again, not a single valid reason has been given for excluding a
> person like Gerard from the committee. This is not about him
> personally -- it's about the _process_.
>
> You accuse me of assuming bad faith. Yet you are treating me as an
> outsider after 5 years of working with and around Wikipedia which has
> included more "special projects" than I care to mention (which pay my
> salary, I might add). There are large grants I am associated with
> which I wouldn't bring even anywhere _near_ the Foundation because of
> its current state. Your point above seems to be accurately
> summarizable as: "Erik, please be nice to us, because otherwise we'll
> just ignore your ideas."
>
> Not a single part of my e-mails was personal criticism, an assumption
> of bad faith, or deliberately insulting. I have been very careful to
> focus on the issues, using InstantCommons as an example of failure. I
> am doing this publicly not to humiliate you but because I know from
> experience that otherwise I will just be silently ignored. Instead of
> actually trying to resolve the problems I pointed out, you posted a
> new thread with the upper case title "INCORRECT", accusing me of
> spreading false information. When the information turned out to be
> correct, you accuse me of not being nice. How about, instead of
> accusing me of something, you try to actually answer to my points
> above? How is the Foundation going to scale to the size of problems it
> faces?
>
> I would be very happy to serve with you on SP and to work with you to
> reorganize it in such a fashion that it can handle grants and projects
> efficiently and effectively. The question is, do you acknowledge the
> problems there are, and do you want my help to solve them? Or are you
> hoping to pull a miracle CEO out of your hat who will solve global
> hunger?
>
> Kennisnet is just one random (if important) organization from the
> Netherlands we happen to have a good working relationship with. There
> are thousands of Kennisnets out there, thousands of organizations and
> companies and institutions who would be happy to support us in a
> myriad different ways. Heck, some of them have already sent the
> Foundation product samples.
>
> I have no doubt that the SP committee will initiate a dozen or half
> dozen projects from within its own ranks in the coming months.
> However, Wikimedia's ambition is not "to start a dozen or half dozen
> interesting projects". Wikimedia's ambition is:
>
>    "Imagine a world in which every single person is given free access
> to the sum of
>     all human knowledge. That's what we're doing."
>    http://wikimediafoundation.org/
>
> The first version of this statement was drafted by Jimmy and me at the
> WOS 2004. I would say it's about time we get serious about it, or drop
> the rhetoric. Wikimedia is turning into a "who likes who" club rather
> than an organization centered around goals, objectives, and
> qualifications. Jimmy says he doesn't want the organization to be run
> like a college club. Then it's time to get rid of the bullshit
> politics. Get Gerard and me on SP. Let us identify other people who
> can help. Allow us to bring our existing collaborations into the WMF.
> And let's broaden and open up the organization in ways which will
> amaze us all.
>
> This is not about "if all you have is a hammer, everything looks like
> a nail" philosophy, about applying wiki ideology to areas where there
> are "tried and tested" ways of doing things which are preferable. This
> is about learning from great thinkers like Douglas Engelbart, Ted
> Nelson, Howard Rheingold, Frederic Vester, and Tim Berners-Lee. This
> is about running Wikimedia in accordance with the laws of
> thermodynamics: only open systems are survivable. The last thing our
> planet needs is more politics and more bureaucracy. What it does need
> is smart people collaborating, building global networks, and
> overlooking their personal differences, before our civilization
> collapses under its own weight.
>
> Erik


list: wikien-l

from_name: Steve Bennett

subject:
[WikiEN-l] Cultural distinctions are accidental? Consensus
	among cultures is bad?

body:
On 6/8/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> On 6/8/06, Jimmy Wales <jwales at wikia.com> wrote:
> > For what is it worth, I think that questions of language and culture are
> > subtle and deep.  Perfect machine translation would of course be useful
> > -- only Anthony could manage to find the straw man argument that anyone
> > who thinks that language distinctions are important and relevant might
> > also think that machine translation would not be _useful_.
> >
> You stated that "For the record, and as I have said many times in the
> past, I do NOT
> think that cultural distinctions between difference language Wikipedias
> are accidental or to be regarded as accidental, and even if it were
> possible to translate every article using machine translation, I cannot
> imagine that we would want to do so."
>
> If you weren't talking about machine translation, then what did you
> mean?  Imagine that we would want to do what?

Peanut gallery chiming in here: It looks like Jimbo is saying machine
translation would be a very useful tool for building Wikipedia, but we
would not want to reduce Wikipedia to merely being a single repository
of information automatically kept in sync by machine translation.

In other words: Machine translation as a tool == good. Machine
translation as a model for interwikipedia relations == bad.

> And I'd say that "We try to reach people in their mother language or
> at least a language they handle very well, we should not provide
> different content based on any other specificity such as nationality,
> religion, political view point and such."

So an article about sport should discuss in equal measure sports
popular in anglophone countries, and sports we've never heard of, but
that have massive popularity in certain populous African countries?
What does your philosophy say about the Georgia/Georgia question (is
Georgia a country in the former USSR or a US state?) What does
"different content" mean? Given three articles A1, A2, A3, is having
A1 the main article pointing to A2 and A3 as sub articles the same
thing as some other arrangement?

Is it ok if a link at the top of [[President]] at en directs people to
[[George W Bush]], while a link at the top of [[Pr?sident]] at fr
directs people to [[Jaques Chirac]]?

These aren't rhetorical questions - what's ok, what isn't?

Steve


list: wikitech-l

subject: [Wikitech-l] Case inconsistency

body:
On 6/8/06, Steve Summit <scs at eskimo.com> wrote:
> And of course, if the various Search options all got their "Do
> you mean?" functionality just right, we truly would *not* need all
> those redirects.  Many of them exist not because a commandment on
> a tablet said we had to create them, but rather, as a workaround
> for the fact that readers do occasionally type in article names
> spelled wrong, and we want to make it easier to find what they
> want, and the software hasn't always been smart enough.

I actually mostly make them to prevent anyone else redlinking them and
then the same person (or someone else) creating a duplicate article. I
probably create on average 5 redirects a day just through random
browsing. If my first search term doesn't hit on the right article, I
make it a redirect.

Totally agree that the software "should" be smarter about resolving
search queries. Totally understand that the developers have other
stuff to do.

> So yes, if the software can tell that a user who typed A probably
> meant B, and if it can implicitly redirect from A to B, we don't
> need an explicit redirect from A to B, after all.  And having the

As long as the implicit redirect works in all cases, which it doesn't.

> software do that automatically is obviously preferable to the
> nuisance of creating and maintaining all those thousands of
> explicit redirects manually.

Yep.

> The remaining case is that if the software is implicitly
> redirecting from A to B, but there is some distinction between
> A and B after all, such that a later editor wants to create a
> distinct article on A, there must obviously be a way to do so
> without being trapped by the same implicit redirect.

Yes. You're also alluding to the basic problem of "a" and "A" mostly
being the same, but occasionally being different. It would be "nice"
if there was a way of making "Nice" and "nice" different articles, but
for many good reasons, that's the compromise that was reached.

> (Apologies if I'm belaboring the obvious here.)

No, you're helpfully reducing it to its most basic elements.

Steve


from_name: Tim Starling

subject: [Wikitech-l] New diff feature for MediaWiki

body:
Gerard Meijssen wrote:
> Hoi,
> This small Unicode issue is a show stopper. When software is suggested
> that only works on Latin script, you do not appreciate the amount of
> work that is done in other scripts using the MediaWiki software.
>
> Apart from that why would it be boring.. this is a technical list.
> Personally I am interested in two things as well, what other projects
> are you referring to and how you want to see this attribution done.

I discussed unicode support with the original poster on IRC. I couldn't get
through to him that adding UTF-8 support to a PHP application is trivial,
and requires no special UTF-8 support within PHP itself. MediaWiki's UTF-8
support is mostly implemented from scratch using PHP's binary-safe string
handling. My wikidiff2 module in C++ also contains a simple UTF-8 decoder
within the word splitting routine. It's not difficult.

-- Tim Starling


from_name: Lord Voldemort

subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, George Herbert <george.herbert at gmail.com> wrote:
> The straw man argument you were floating seems to have been, that
> everyone doing this type of behavior should be told to go away.
>
> My response is, now that we have some data, are you sure that you want
> to drive away a bunch of multi-thousand edit, apparently positive
> contributors for every actual problem child case you actually get in
> the signature cleanup effort?
>
>  Jimbo asks earlier whether we're really driving away good editors, as
> a data point he'd like to see.  My point here is that your attitude,
> that everyone displaying some of these problem symptoms should go
> away, would result in driving away over 50% good editors.
>
> The class of behavior is made up of individual people.  If you're
> really sure that you want to drive away all those individual people,
> even if  most of them are apparently strong contributors, then I
> object and see a problem.
>
> The solution has to be behavior modification, not exile, for the vast
> majority of these "problems".
>
> Whether some people who are predominantly just doing social stuff
> should be encouraged out the door or not if behavior modification
> fails is a different issue.  But that's 1/7 of the first set of people
> you were refactoring sigs on.

Wow... most words I think I've seen put in someone else's mouth in
quite some time.  Reread Tony's argument.  --LV


from_name: Ray Saintonge

subject: [WikiEN-l] To: Jimmy Wales - Admin-driven death of Wikipedia

body:
abu hamza wrote:

> yes, i have made my first submission,
> feels like a court of law :-), i knew my jury service would come in handy.

Being able to laugh at yourself in adversity when all around you are
taking themselves seriously is a sign of progress.

Ec


from_name: Erik Moeller

body:
On 6/8/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> I have some questions from a technical perspective.

Before I answer these, let me ask if you agree with this being a
reasonable idea in general. If it is, then for me it means that
technical details should be worked out by technical people as the
project moves along. Kennisnet actually told us that the proposal was
more technically detailed than it needs to be in order to be funded.

> 1. What is the purpose of the XML-RPC subsystem?   Since the images
> are fetched via HTTP in any case, why not simply perform the existence
> test via simple HTTP as well.   If that were done no modifications
> would be needed on the commons side.

There are future queries where the subsystem would come in handy, such
as: show me the available, pre-rendered thumbnails, a list of
conversion services, etc. Some of these are mentioned in the specs.

> 2. It would appear from the specification that their is no facility
> for caching failures.

Sure, the system should cache non-existence, but given that we
anticipate fairly low usage to begin with, and given that the process
of adding and reviewing an image is interactive, I do not anticipate
any major load resulting from putting that feature into a future
version of MW even without such caching. MW has several caching
mechanisms that would kick in anyway for pages that have already been
viewed before. If it does cause problems, we can deactivate the
Commons service entirely until the feature is improved.

> 3. The proposed method of interwiki transclusion doesn't appear fully
> formed enough to determine if it will be sufficiently strong to
> prevent instant commons from accidentally becoming an automated system
> for license violations.  In particular there doesn't appear to be any
> strong assurance that attribution and license data will *always* be
> available when the image is available.

We don't have the same assurance for Commons usage within the
Wikimedia projects either, I think.

> 4. Although copyright concerns are mentioned, they don't seem to be
> explored in depth. Commons has a huge amount of copyright violations
> on it today.

Then they should be deleted. InstantCommons is a manual,
user-initiated process. Commons has no legal responsibility to stop
users of other wikis from copying images from Commons, whether it is
by means of manually downloading or uploading, or by setting their
wiki up for IC and initiating an IC transfer process. The copyright
cleanup script is a convenient thing we can provide, and by no means a
legal necessity.

> 5. If the remote wiki will download the full image in all cases, what
> is the purpose of burdening commons with the additional transfer and
> storage costs of their thumbnail generation?  Yes, if that size has
> been used before commons will have it... but it's quite likely that
> other wikis will use a large number of sizes which are not used on
> Wikimedia sites, and even if the best case they still cost us
> additional bandwidth.  The far side will still need to perform
> thumbnailing for the image page for large images in any case.

It's a service which we can choose to provide - for some wikis, for
some file formats, etc. This is a policy choice for Wikimedia to make.

> 6. How will this address SVGs which are widely used on commons, but
> not supported by mediawiki out of the box? Our support for SVGs
> requires a modifyed version of librsvg in order to operate securely.

The first iteration of IC could support SVG the same way it is
supported today: If your local wiki doesn't have a backend rendering
library, you can still upload them (locally or through IC), but you
can't view them as rendered PNGs and scaled thumbnails. Future
iterations could support SVGs through some XML-RPC based
query/response mechanism for the PNGs, if Wikimedia wants to provide
that service.

> There are also some more complex issues, like where the $5,000 EUR fee
> comes from for what is, overall, such a simple feature set. But I
> don't want to create a flood of comments initially.

The feature set is reasonably simple. Do keep in mind that for a
feature to be developed and for it to be "Brion-ready" generally takes
some more time spent with testing, debugging, security review, etc.
The developer is ready to use any surplus time for the purpose of
developing Wikipedia content in one of the native languages of Ghana;
Kennisnet was happy with that. Also keep in mind that this is his
first MediaWiki project, so he'll need some tutoring from a skilled
developer, which should be paid for.

Erik


body:
On 6/8/06, Anthere <anthere9 at yahoo.com> wrote:
> We have never seen a detailed budget (though we asked).

How detailed do you want it to be? You received the roles and
individual budgets, for a 5K project. For a medium to large grant
proposal, a single row in a table is typically of that size.

> We have not received a timeline (despite repeated requests)

The timeline from the begin of development to the feature being
reviewed by Brion, as stated, is 4 weeks. We can now play bait and
switch for the next few days, with you stating new requirements, or
technical people coming in and asking for assurances. The point is,
this is a tiny project to which there have been no principal
objections. Funding is there, a skilled developer in Africa is there.
It should be underway already.

> The proposal, as
> > written in February, is at
> > http://scireview.de/temp/instantcommons_2.odt
>
> ...
> I can not read .odt...
> (shame...)

Append .pdf instead of .odt to the URL above.

Erik


from_name: stevertigo

subject: [WikiEN-l] Fixit tasks / bannerization

body:
Hello all,

Brion's note about this weeks HMTL table fix going in
made me wonder if there shouldnt be short one-line
banner message to let people know. Maybe its already
in teh works, but I havent seen any other usage of
bannerspace in a while (other than the funding drive).
A page describing how to help out would work too.

And since this is primarily a site for editing
editable stuff, and there are plenty of other things
to focus people on, why perchance not use the
bannerspace for other Fixit tasks as well?

Things that come to mind are the things I see all the
time:

* Self-refs ~ "for more on this topic"
* In-text external links (usually with a self-ref)
* Overuse of headers + tiny lede paragraphs

* Excess whitespace

Blah blah.
-Stephen

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Anthony DiPierro

subject: [WikiEN-l] AFC needs your help!

references:
<fb7fdd9c0605220024h7fda292ax2c0051fe5f5dbd43@mail.gmail.com>
	<71cd4dd90606030746q7bec3b0erb12fb4c7cbe0132d@mail.gmail.com>
	<e5umr7$jrf$2@sea.gmane.org>
	<71cd4dd90606040733l2edbb4efwc080326291c5fdcb@mail.gmail.com>
	<e6a25i$k6e$1@sea.gmane.org>

body:
On 6/8/06, Timwi <timwi at gmx.net> wrote:
> Anthony DiPierro wrote:
> > On 6/4/06, Timwi <timwi at gmx.net> wrote:
> >
> >>>Why not set up a system where each article proposed for creation
> >>>exists as a separate page.  And there could be a special page set up
> >>>which points to each of them.  This special page could list the date
> >>>and time created, the name of the proposed page, the number of bytes
> >>>of the page, and the username or  IP address of the proposer.
> >>
> >>Surely that would be equivalent to just letting unregistered users
> >>create pages again and having a Special page that simply lists all
> >>articles that have only ever been edited by IPs.
> >
> > Yeah, that was my point.
> >
> > Although, as I thought about it more, there would potentially be one
> > difference - "proposed" articles could live in a different namespace
> > (and have a warning at the top or whatever).
>
> And then the actual real difference would be what? The warning? The
> namespace prefix showing up in the article title? Both of those are
> trivialities. They are still publicly-visible and -editable pages that
> are primarily distinguished from others by means of that Special page
> that lists them. Whether that Special page performs a complex query or
> just lists a namespace, is irrelevant.
>
> Timwi
>
There could be a warning.  Nofollow could be turned on.  The pages
wouldn't be downloadable in the article-only db download that some
mirrors use.  The pages could be automatically deleted after a certain
period of time if they aren't promoted.

Sure, this could also be done without using a different namespace.

What's the difference between the system that exists now and the
system that existed before, other than the fact that it's harder to
maintain?  The proposed pages are still publically visible and
editable - in fact they're *more* publically visible.  Why aren't the
people who were overworked with deleting stuff from the article
namespace now overworked with deleting stuff from AFC?

I really don't know the answers to these questions.  My comment about
proposed pages existing in a different namespace was just an attempt
to get the benefits of the AFC system without the detriments.  But
other than being in a different namespace, it not really clear to me
what those benefits are (there must be some benefit though, because a
lot of people seem to prefer it).

Anthony


body:
On 6/8/06, Daniel Arnold <arnomane at gmx.de> wrote:
> Am Donnerstag, 08. Juni 2006 21:34 schrieb Gregory Maxwell:
> > Considering that we've had violations persist for months after they
> > were tagged and even brought up in a Wikimedia board meeting, I'd say
> > that our position is even weaker than napsters.
>
> Well we do our very best. I don't want to go into details why deletion on
> Commons is so much more work than in a single wikipedia, you all probably
> know it already very good. But one is for certain: We don't need more admins,
> we need more active admins and we need a change of mind of the people using
> Commons that Commons is more than a wikipedia helper project.

It's a hard problem. Implicit accept is burning us... nothing is
compelling people to help audit because auditing work is not in the
critical path for getting their image listed.

I'm not faulting any person, but rather our process causes our product
to have a fairly low quality from a licensing accuracy perspective. As
you mention  we get problems from people confusing enwiki's policy
with commons. It's not something we should be suggesting people use
without their own verification.

 I'm confident that over time we will improve things.

> There are also some things that would help Commons much more than you'd
> imagine:
> Burn all Fair Use images on *all* Wikimedia projects *now*. And I really mean
> burn. Just *mass delete* them on sight ASAP without looking back.
> I am really sick educating people afterwards that Commons is not en.wikipedia
> for example. So many people from wikipedia simply dump their stuff in Commons
> and just don't get the difference that Commons is not their Wikipedia.
>
> So please in every local wiki educate people that Fair Use is a clear NO.
> Please make this everywhere your most important image copyright policy.

I could make the exact opposite argument.  I've found quite a few
unfree images uploaded to commons tagged incorrectly as free images
because users on Dewiki understood that there was an obvious need and
little prospect of objection for some copyrighted work... so they
declared it "public domain".  An example of this was that until
recently, [[Dr._Who]] on dewiki was illustrated with a half dozen
obviously copyrighted images which were placed on commons by a de
wikipedian.

Another example along these lines is that the lack of a common sense
fairuse/fair deailings repository has caused many unreasonable claims
over what is free content. For example, rather than using commercial
logos directly, Dewiki articles are often illustrated with tightly
cropped photographs of company signs which are nearly
indistinguishable from the plain logos themselves.   Obviously the
third party rights on these images prevent them from being Free
Content, but they are none the less uploaded to commons (with
misleading tagging) because outside of enwiki we've provided no
alternative for such common sense usage.

> I know that this sounds radical to some of you but it would really help us a
> lot and it is worth the trouble (the trouble will quickly decrease after
> you're mainly done with fair use deletions).

I don't agree. A completely prohibition of the limited us of
copyrighted works ware are used in conformance with common sense and
copyright laws which respect academic discourse is likely to
dramatically increase the amount of incorrect tagging.

Today we deal fairly well with unacceptable images which are tagged as
such, but all our processes (on enwiki and commons) fail completely
once someone has made an incorrect or simply dishonest claim about an
image.

Several times I've seen images which were obvious stock photography,
uploaded by someone who only uploaded that image and a few which were
already deleted for being copyright violations... but since the
uncontactable uploader picked GFDL or PD in the drop down during their
otherwise commentless upload,  I'm placed in a position of having to
*prove* that it is a violation before the image can be removed without
hysteria.  I've always been able to do so when I've had such
suspicious, but it is a huge amount of work and an entirely thank less
job.

So please don't ask people to convert a large problem we can deal with
fairly easily (identified inappropriate use of unlicensed works) with
a slightly smaller problem that we are almost totally unable to cope
with.


from_name: Roman Nosov

body:
Regarding UTF-8 support. Perhaps it would be better if I try to
explain some of the problems I'm facing. For example I'm not tracking
most frequently used English words (a, the, and, or ?). In my opinion
every language should be tweaked separately and that's why I'm
suggesting to first test it on English Wikipedia.
Also I don't have a problem with finding spaces in UTF-8 encoded
strings and splitting it there. The problem is that some Unicode
characters like ? (letter w with two dots on top, Unicode code 0x1E85)
are used to write words and some Unicode characters such as ' (Left
single quotation mark, Unicode code 0x2018) are used to separate
words. Also I believe these characters could be encoded as HTML
entities in Wikitext.
As I'm tracking words I need to distinguish between these "character
classes" as they are known in regular expressions (i.e. \w word
character and \W non word character). If Tim Starling has a silver
bullet that can solve these problems feel free to e-mail it to me.
However in my opinion implementing that kind of UTF-8 support from
scratch can be somewhat tricky business.
The bottom line is that problems above *can* be solved but what I
suggest is to try on English Wikipedia first to see how it's going to
work in general and whether it's a useful feature. Support for other
languages could and should be added later on one language at a time.

On 08/06/06, Rob Church <robchur at gmail.com> wrote:
> On 08/06/06, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> > Gerard Meijssen wrote:
> > > Hoi,
> > > This small Unicode issue is a show stopper. When software is suggested
> > > that only works on Latin script, you do not appreciate the amount of
> > > work that is done in other scripts using the MediaWiki software.
>
> "You do not appreciate" - rather a confrontational tone, there. Who
> are we to assume that someone else doesn't appreciate the amount of
> effort put in elsewhere? It might be correct, but then again, there
> might be no specific bias against it.
>
> > > Apart from that why would it be boring.. this is a technical list.
> > > Personally I am interested in two things as well, what other projects
> > > are you referring to and how you want to see this attribution done.
>
> Apart from why what would be boring? The post was to get feedback,
> don't withhold it. I would imagine standard attribution for the code
> under GNU GPL blah blah blah. We won't be adding flashing banners,
> "Wikipedia now uses a feature from XYZ". Or are we to start crediting
> developers with individual features? "Thanks for clearing your
> watchlist, c/o Rob Church."
>
> > I discussed unicode support with the original poster on IRC. I couldn't get
> > through to him that adding UTF-8 support to a PHP application is trivial,
>
> My impression of the poster was that he didn't completely understand
> the whole UTF-8/Unicode/blah thing nor its implications, and looked
> somewhat confused.
>
> > and requires no special UTF-8 support within PHP itself. MediaWiki's UTF-8
> > support is mostly implemented from scratch using PHP's binary-safe string
> > handling. My wikidiff2 module in C++ also contains a simple UTF-8 decoder
> > within the word splitting routine. It's not difficult.
>
> If the *idea* is found to be viable, adding the UTF-8 goodies will be
> trivial, and we'll put the damn effort in.
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] Category translation

body:
On 6/8/06, Delirium <delirium at hackish.org> wrote:
> population.  For example, which do you think is more likely to cover the
> Bosnian war neutrally: the English-language Wikipedia, or the
> Serbian-language Wikipedia?  The English Wikipedia has Serbs, Bosniaks,
> Croats, and many neutral people; the Serb Wikipedia does not benefit
> from nearly the same diverse population.

There are probably comparable blind spots in the en Wikipedia, where
English speakers are insufficiently critical of themselves, or
insufficiently informed on topics that don't interest them.

Steve


from_name: Mark Williamson

subject: [Wikitech-l] Simplified/traditional Chinese on Commons

body:
It was my view that Vipuser promoted his side because he is a
Simplified user and so has not had experience with such errors.

Mark

On 08/06/06, Shinjiman <shinjiman at gmail.com> wrote:
> See also:
>
> http://commons.wikimedia.org/wiki/Commons:%E4%B8%AD%E6%96%87%E7%B9%81%E7%AE%80%
> E4%BD%93%E9%97%AE%E9%A2%98
>
> There's such discussion regarding whether such converter is implemented or not
> (this is composed by Vipuser according to the page history), however Node ue
> and I disagree with these because there will be some problem if such converter
> is being implemented. See also the talk page for Node ue:
> http://commons.wikimedia.org/wiki/User_talk:Node_ue, and Vipuser argues with
> that issue.
>
> cheers
> Man
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

--
Refije dirije lanm? yo paske nou posede pw?p bato.


from_name: maru dubshinki

subject: [WikiEN-l] AFC needs your help!

body:
On 6/8/06, Timwi <timwi at gmx.net> wrote:
> MacGyverMagic/Mgm wrote:
> > To others: the whole point of AFC is to help out people who don't want to
> > create an account and still want to submit articles while at the same time
> > filtering out the crap.
> > Allowing anyone to create articles again, would indeed overwork admins who
> > work in deletion.
>
> What difference does that make, given that AfC *also* overworks them?

No... AFC overworks whatever poor registered editor feels altruistic
enough to help. Not merely administrators.

~maru


from_name: Claudi Meneghin

subject: [Wikitech-l] customising namespace - 2 (Rotem Liss)

body:
Many thanks: only a question more, please: these language/message  files, LanguageLmo.php, and MessagesLmo.php. are to be placed at which  URL?

  http://lmo.wikipedia.org/MessageLmo.php or
  http://lmo.wikipedia.org/wiki/MessageLmo.php ?

  Are they compatible with the existing Mediawiki?
  Many thanks.
  Sincerely Yours,
  Claudi

 __________________________________________________
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicit?s
http://mail.yahoo.fr Yahoo! Mail


subject: [WikiEN-l] AFC needs your help!

references:
<fb7fdd9c0605220024h7fda292ax2c0051fe5f5dbd43@mail.gmail.com>
	<71cd4dd90606030746q7bec3b0erb12fb4c7cbe0132d@mail.gmail.com>
	<e5umr7$jrf$2@sea.gmane.org>
	<71cd4dd90606040733l2edbb4efwc080326291c5fdcb@mail.gmail.com>
	<e6a25i$k6e$1@sea.gmane.org>
	<71cd4dd90606081355o6df68714r25e18ba2cbbebfc1@mail.gmail.com>
	<b8ceeef70606081427xd3a13daocfa597c2063b2747@mail.gmail.com>

body:
On 6/8/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 6/8/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> > What's the difference between the system that exists now and the
> > system that existed before, other than the fact that it's harder to
> > maintain? The proposed pages are still publically visible and
> > editable - in fact they're *more* publically visible. Why aren't the
> > people who were overworked with deleting stuff from the article
> > namespace now overworked with deleting stuff from AFC?
>
> Why bother deleting anything from AfC? my understanding of the process
> was that the AfC for a given day hangs around for a few days to see if
> anyone can find anything redeeming, then the whole lot is flushed down
> the plughole. If we're preserving archives of AfC, then we're probably
> doing somethnig wrong.
>
> Steve

Flushing the archives isn't a particularly good idea, because good
articles *do* get lost in AFC. Now, if we had some mechanism to mark
each day as "Done", then that would be another thing.

~maru


from_name: Jay R. Ashworth

body:
On Fri, Jun 09, 2006 at 12:50:00AM +0300, Ilmari Karonen wrote:
> I concur.  If the feature is useful at all, a test version would be
> useful even if it only worked in a Cyrillic variant of EBCDIC.

Pervert.

:-)

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


subject: [WikiEN-l] AFC needs your help!

body:
On 6/8/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 6/8/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> > What's the difference between the system that exists now and the
> > system that existed before, other than the fact that it's harder to
> > maintain?  The proposed pages are still publically visible and
> > editable - in fact they're *more* publically visible.  Why aren't the
> > people who were overworked with deleting stuff from the article
> > namespace now overworked with deleting stuff from AFC?
>
> Why bother deleting anything from AfC? my understanding of the process
> was that the AfC for a given day hangs around for a few days to see if
> anyone can find anything redeeming, then the whole lot is flushed down
> the plughole. If we're preserving archives of AfC, then we're probably
> doing somethnig wrong.
>
> Steve

Last time I checked "archives" of AfC were being kept.

Anthony


subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, Fastfission <fastfission at gmail.com> wrote:
> Wikipedia is a project that thrives only because people want to spend
> a ridiculous amount of their time on it. Developing a sense of
> personal identity makes people feel comfortable, feel welcome, and
> feel invested. As long as said sense of personal identity does not get
> in the way of the goal of making an encyclopedia, I see absolutely no
> reason to try and quash it. So far most of the attempts to cut out
> "social" aspects seem to have done more harm than good, in my mind.
>
> I've never seen any plausible evidence that things like userboxes
> actually get in the way of the goal of making an encyclopedia, except
> in the sense that trying to eliminate them takes months and creates
> all sorts of awful falling-outs.

It probably comes down to this:
1. Users work mostly on the encyclopaedia, and spend some time socialising
2. The social aspect attracts more users, who spend time in equal
measure, creating pretty userboxes and expressing their political
beliefs
3. This attracts more social users, who spend most of their time on
purely social functions and creating noise
...

Eventually you have to draw a line. For serious contributors to have a
bit of social fluff about them is fine. Having people whose primary
presence at Wikipedia is social, rather than encyclopaedical does
eventually get in the way of building an encyclopaedia, through pure
noise.

Steve


subject: [WikiEN-l] Category translation

body:
On 6/8/06, Delirium <delirium at hackish.org> wrote:
> There are blind spots to be sure, but I certainly don't think they're
> "comparable", simply by virtue of the fact that English speakers don't
> comprise only members of one ethnicity or nationality.  If it were an
> encyclopedia edited solely by Americans you might have a point, but it
> isn't.  We have, in addition to people from all the English-speaking
> countries in the world, substantial numbers of speakers of English as a
> second language who contribute regularly.

Well I'll wait to hear whether the Bosnian war really is portrayed so
badly on the Serbian Wikipedia. Anyway, comparable <> equivalent or
even similar.

> Which isn't to say it's perfect, but as far as the potential to be a
> global, neutral, thorough encyclopedia, I think en.wikipedia is the
> structurally best placed by far, simply because so many people from such
> diverse cultures speak English.

You're probably right. I never notice much of an Indian presence
surprisingly enough...

Steve


from_name: Raphael Wegmann

subject:
[WikiEN-l] Cultural distinctions are accidental? Consensus
 among cultures is bad?

body:
Anthony DiPierro wrote:
>
> Jimbo claims he's said this many times in the past.  I couldn't find
> any, but if anyone else can maybe I can better understand what he's
> saying.  If Jimbo does "NOT think that cultural distinctions between
> difference language Wikipedias are accidental", then he must think
> they're intentional.  That raises the question as to who intended
> these distinctions, and what distinctions were intended.  I always
> thought the English Wikipedia at least was supposed to be neutral with
> regard to culture.  Maybe English is the exception?
>

Regardless whether the cultural distinctions are intended or not,
they are a fact. I would consider i.e. a translation of terms like
Islam and Terrorism from english to arabic and vice versa very
exciting. I honestly thought about paying a translator to do it.

--
Raphael


body:
On 6/8/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Note: This post is a long ramble about not much.
>
> On 6/8/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> > I would disagree.  The "dablinks" Steve seems to be referring to are
> > metadata that just happens to be included in the article text for lack
> > of a better technical solution.  Without looking at the actual articles
> > in question, I'd say a link at the top of [[en:President]] that says in
> > effect "If you came here looking for [[George W. Bush]], he's thataway."
> > would be perfectly reasonable if readers of that particular project in
> > fact with some frequency do so (which I find plausible enough).
>
> As things turn out, this is not currently the case. However, I note
> that [[President]], while being one of our more "internationally
> balanced" articles, still has an excessive US bias:
> There is a whole paragraph on electoral colleges in the US, while most
> other countries don't get more than their name mentioned.
> There is another paragraph beginning "The head of a university or
> non-profit corporation, particularly in the United States of America,
> is often known as president."
> A paragraph on the fact that the head of the mormons is known as the
> president...I doubt very much this would be interest to anyone reading
> the hypothetic Urdu version, for instance.
>
> In fact most of the article is centred around the US and France, with
> a bit of Spain. For a Wikipedia article, that's not too bad, and is a
> good start. But it's certainly skewed in favour of providing more
> information on topics likely to interest anglophone (and in
> particular, American) readers.
>
> Is this bad? To me, not particularly, though other information on
> other countries, perhaps including the presidential referendum in
> Australia, would have been welcome.
>
> Steve

Personally, as an American, I'd be more interested in presidents of
countries other than the US.  More specifically, it'd be interesting
to me to read what the world as a whole considers the most important
information about presidents.  If I wanted to read specifically about
the [[President of the United States]] (a topic about which I already
know plenty), I could always go to that article.

And like Raphael, I'd be very interested in reading about things like
[[terrorism]], [[George W. Bush]] and [[United States]] in non-English
versions of Wikipedia.  Are there other avenues of getting some of the
same information?  Sure, though none of them would provide precisely
the same information (what does this particular slice *of Wikipedians*
think is an appropriate article).   Many of the other avenues would
require significantly more work to answer a particular question.  And
many of the other avenues would introduce their own particular bias.

Anthony


from_name: Tony Sidaway

subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, Fastfission <fastfission at gmail.com> wrote:
> On 6/5/06, Tony Sidaway <f.crdfa at gmail.com> wrote:
> > On 6/5/06, Fastfission <fastfission at gmail.com> wrote:
> > > People should be allowed and encourage to develop their personal
> > > identity on Wikipedia
> >
> > Why?  Wikipedia isn't a web host, a blog or a social networking site.
> > Those who are looking for such sites will find that there are plenty
> > of those around.  There is only one Wikipedia.
>
> Wikipedia is a project that thrives only because people want to spend
> a ridiculous amount of their time on it.

If they want *us* to spend a ridiculous amount of time discerning the
comments on a discussion page from the clutter of their signatures, I
think they'll be very disappointed with Wikipedia.  But you know what?
 That's okay.  They can go somewhere else to play silly buggers.


from_name: Daniel Mayer

subject:
[Foundation-l] Fundraising committee (was Re: Fundraising ideas -
	using what we've already got)

body:
All I have time to say is this - all good ideas that should be looked into.

Please sign-up at:
http://meta.wikimedia.org/wiki/Fundraising_committee

Only a few people on the committee need access to sensitive things like the internal wiki, the
PayPal and MoneyBookers accounts and the CafePress shop. Thus the fundcom will likely be the most
open committee in the foundation.

Much work needs to be done by a great many fundcom advisers/associates/volunteers (title for
non-core members not set yet); we have a donation queue in ORTS, the fundraising pages need a
facelift, the CafePress shop needs *weekly* updates to keep people checking back for new
merchandise, we need an army of translators, and need to explore new ideas for maximizing
donations (such as those below).

-- mav

--- Brianna Laugher <brianna.laugher at gmail.com> wrote:
> I think there is a lot of untapped potential in selling existing WM
> items to try and increase the average donation. 'sweeteners'. The
> CafePress merch at the moment is a little bit crud. For example some
> Wikibooks already offer PDF versions (well, Learning German in English
> does, at least). So you could say, "Donate $X and receive a free
> e-book to learn German!" Or a "best of" the cookbook. The only extra
> cost to the Foundation is the bandwidth.
>
> I am constantly amazed at the quality of Wikimedian photography at the
> Commons and we could easily bundle, say, 10 super high quality images
> together in a ZIP and offer "10 free computer wallpapers". Since we
> have so many I think we could even offer a choice between a few of
> these, by theme (eg landscapes, art, sunsets, science-y, insects
> having sex). We could set the donation bar for this $5 higher than
> whatever the average donation last time was.
>
> I would also like to create some templates and put together some
> themes to allow people to easily make their own calendars from Commons
> material. And back to fundraising, CafePress does calendars. I don't
> really know who controls all that but I assume there'd be no objection
> if I/we put some together for that? I imagine they would sell really
> well in Nov/Dec. They also do prints and mousepads, gift cards...
>
> Of course the markup on CafePress stuff is not great, it would be
> better if could be done inhouse somehow, but I haven't figured out a
> good solution to that yet. The "computer wallpapers" and PDF books
> stuff exists already though. I guess all you would need is to have the
> files on the foundation wiki and when a donation is over the target,
> they get some special 'download link'.
>
> So, is what I'm proposing technically feasible, is it a good idea or
> will it probably be a lot of fuss for negligible impact, and should I
> start trying to find good candidates for such things?
>
> cheers,
> Brianna
> en|commons:user:pfctdayelise
>
> PS. I also think there is great potential in the Spoken Wikipedia
> material, but I haven't figured out what the best format for it would
> even be. How many could you reasonably ZIP?
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Daniel Arnold

body:
Am Donnerstag, 08. Juni 2006 16:42 schrieb Erik Moeller:
> > 4. Although copyright concerns are mentioned, they don't seem to be
> > explored in depth. Commons has a huge amount of copyright violations
> > on it today.
>
> Then they should be deleted. InstantCommons is a manual,
> user-initiated process. Commons has no legal responsibility to stop
> users of other wikis from copying images from Commons, whether it is
> by means of manually downloading or uploading, or by setting their
> wiki up for IC and initiating an IC transfer process. The copyright
> cleanup script is a convenient thing we can provide, and by no means a
> legal necessity.

FYI: Wikimedia Commons has already such a thing. We made our
license/maintenance templates machine understandable (not just readable :p)
and any script can make use of it. See:

http://commons.wikimedia.org/wiki/Commons:Tag_categories

There is already a brand new alpha media search engine by Duesentrieb using
that feature (remember Wikimedia Commons is not indexed in any search engine,
due to a technical problem with file extension pagenames like
Image:example.png that let skip all search engine robots indexing these HTML
pages, this affects all MediaWiki wikis for those that still don't know ;):

http://tools.wikimedia.de/~daniel/WikiSense/MediaSearch.php?wikifam=commons.wikimedia.org

It also linked in our slightly modified search page: ;)

http://commons.wikimedia.org/wiki/Special:Search

Another use of these tag categories and many more modules (like the CheckUsage
module) is the CommonsTicker (already advertised here).

So completely independent the question how and when to relize InstantCommons
you can imagine how to solve some legal problems technically.

Arnomane

P.S.: I will write to you some more things I fear getting lost in that
somewhat heated debate here in a private mail in some hours.


subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, John Lee <johnleemk at gawab.com> wrote:
> People who are here to use Wikipedia as a social gathering place do not
> belong here. The community is a means to the construction of the
> encyclopaedia, not the other way round.
>

I suspect that the problem lies with us.  We are failing to say "go
away, we're not interested" to those who want to abuse Wikipedia to
conduct their social experiments.


from_name: Brianna Laugher

body:
Hello,

I posted this on commons-l a week ago to apparent deaf ears.

While browsing in my Special:Preferences today, I noticed that we
apparently support no less than five variants of Chinese:

zh
zh-cn (simplified, as used by the Chinese mainland)
zh-hk (Hong Kong, traditional)
zh-sg (Singapore, simplified)
zh-tw (Taiwan, traditional)

Is there a reason these codes have been set up as country codes rather
than, say, zh-hans and zh-hant? (Han Chinese, simplified/traditional -
these are codes that the Chinese translators on Commons have
favoured.)

Is there thought to be any distinction between zh-sg and zh-cn?

Can the 'automatic converter' thing that zh.wp has be turned on for
the Commons, so we can stop this unnecessary 'translation' between
scripts anyway? (And then we just offer "zh".)

cheers,
Brianna
en.{wp,wb}|commons|meta:user:pfctdayelise


body:
Hear hear!

:P
-Stevertigo

--- Kelly Martin <kelly.lynn.martin at gmail.com> wrote:

> On 6/4/06, Jimmy Wales <jwales at wikia.com> wrote:
> > Did you write something different from what you
> meant?
> >
> > I fully support you as an admin, if that is what
> you were wondering about.
>
> No, it's more along the lines of what would happen
> if I were to be
> desysoped by a "community process"... in the long
> term, it might help
> to undermine that process and our admin promotion
> process generally,
> which I think would be a good thing.
>
> I occasionally think about running for bureaucrat,
> but realize that by
> doing so I would be implicitly supporting the RfA
> system, which I have
> grave objections to and which I think should be
> reformed or eliminated
> entirely.
>
> Kelly
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Timwi

subject: [Wikitech-l] Template HTML fixups coming this week

body:
Tim Starling wrote:
>
> Infoboxes are a very important application of templates. There needs to
> be some way conditionally add table rows based on whether or not a given
> template parameter is defined.

Surely this could be done by adding a certain sub-syntax to the table
row syntax? Something like

|-#ifdef:parameter

e.g.

{|
|-#ifdef:heading style="background-color: pretty;"
! {{heading}}
|-
| {{content}}
|}

Of course, that would be an extremely specific syntax (specific to
templates *and* to table-rows), but in my opinion, it is way cleaner and
more structured than any hacky attempt to fool the parser into correctly
patchworking the table from pieces.

> When people complained about the argument separators in {{#if:}}
> clashing with table syntax, I told them to use HTML table tags
> instead.

I am quite surprised that you didn't notice that this means you are
suggesting a workaround, as opposed to a solution.

> Why is the template required to close its own tags? It would make things
> a lot easier if this was not required.

I totally can't believe you said that.

Timwi


from_name: Kelly Martin

body:
On 6/4/06, Jimmy Wales <jwales at wikia.com> wrote:
> Did you write something different from what you meant?
>
> I fully support you as an admin, if that is what you were wondering about.

No, it's more along the lines of what would happen if I were to be
desysoped by a "community process"... in the long term, it might help
to undermine that process and our admin promotion process generally,
which I think would be a good thing.

I occasionally think about running for bureaucrat, but realize that by
doing so I would be implicitly supporting the RfA system, which I have
grave objections to and which I think should be reformed or eliminated
entirely.

Kelly


subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, Fastfission <fastfission at gmail.com> wrote:
>
> Gosh, Tony, I didn't realize you had such a hard trouble reading
> discussion pages, what with all of those colors and fonts!

Now you know.


body:
Rob Church wrote:
>
>Gerard Meijssen wrote:
>
>>Hoi,
>>This small Unicode issue is a show stopper. When software is suggested
>>that only works on Latin script, you do not appreciate the amount of
>>work that is done in other scripts using the MediaWiki software.
>
> "You do not appreciate" - rather a confrontational tone, there. Who
> are we to assume that someone else doesn't appreciate the amount of
> effort put in elsewhere? It might be correct, but then again, there
> might be no specific bias against it.

It is already confrontational of a programmer to pretend the whole world
could make do with Latin-1. It is one of the most devastating and
accordingly infuriating assumptions that still prevails despite the fact
that Unicode is decades old. We're in the 21st century; it is no longer
appropriate to even start programming anything where any user-visible
text is restricted to Latin-1 or any other 8-bit charset.

Unicode is not a "feature". Unicode is an implementation detail. Latin-1
is a bug.

Timwi


body:
On 08/06/06, Mark Williamson <node.ue at gmail.com> wrote:
> I'm not sure why it's such a big deal to have separate Traditional and
> Simplified versions of pages on Commons. Unlike most other projects,
> language is obviously not a main concern of the project, that's why it
> combines so many languages in one site.

It is vital for the Help and Commons namespace pages though. And
Commons:Licensing.

> With Commons, on the other hand, the only sorts of material that need
> to be translated are things like documentation, a relatively small
> volume, so the effort to convert by hand is not misplaced -- why not
> have a better-quality product when it takes only slightly more effort?

I feel an up-to-date effort is the best thing we can offer our users.
Do you volunteer to keep traditional translations up to date then? We
are currently missing traditional translations for these pages:
Commons:?? Welcome
Commons:???? Community portal
Commons:?????? FAQ
Commons:???? Contact us (actually this page is very incomplete)
Commons:Privacy policy (no Chinese at all)
Commons:???? Project scope
Commons:?????? Deletion guidelines (this is incomplete and likely out
of date anyway)
Commons:???? Copyright tags
Commons:Media help (no Chinese at all)
Commons:File types (no Chinese at all)
Commons:Help page maintenance/Wikimedia Commons interface (strings
listed on this page, not this page itself)
Template:No source since (no Chinese at all)
Template:Idw/zh-hans
Template:Welcome/zh (note that this is seriously out of date, and
since we are now posting automatic welcomes to all active new
accounts, I think it would be nice to have an up to date translation)

These are just some of the more important ones. I don't really mind if
we don't have the autoconverter, I'd just like to be clear about what
we DO have.

Maybe you can offer some advice about the zh/zh-tw/zh-cn/zh-sg/zg-hk
vs zh-hans/zh-hans issue?

cheers,
Brianna


subject: [Wikitech-l] Case inconsistency

body:
Steve Bennett wrote:
> On 6/8/06, Timwi <timwi at gmx.net> wrote:
>
>>Nick Jenkins wrote:
>>
>>>Good idea, but maybe it can be improved slightly by assuming that most
>>>people are somewhat lazy.
>>>
>>>Instead of:
>>>  (Redirected from _Lyon metro_)
>>>
>>>You could have:
>>>  (Redirected from _Lyon metro_ - _create redirect_)
>>
>>I don't understand. If it already redirects automatically, why would you
>>still want to create the redirect?
>
> The "automatic redirection" only occurs if you happen to type the name
> in the box at the left of screen and press the Go button. In any other
> situation (linking to it, typing the name in the URL, searching) it
> doesn't "redirect automatically".

I don't see why it shouldn't?

Timwi


from_name: Steve Bennett

body:
On 6/8/06, Raphael Wegmann <raphael at psi.co.at> wrote:
> Regardless whether the cultural distinctions are intended or not,
> they are a fact. I would consider i.e. a translation of terms like
> Islam and Terrorism from english to arabic and vice versa very
> exciting. I honestly thought about paying a translator to do it.

Why would you translate the Wikipedia article? Wouldn't it be more
interesting to choose a more biased source? If you're just curious on
a middle-eastern perspective, Al Jazeera is a good place to read in
English.

Steve


subject: [WikiEN-l] Category translation

body:
On 6/8/06, John Lee <johnleemk at gawab.com> wrote:
> Eh? I've seen lots of Indian editors around, and the Indian community is
> very active.

I was hoping someone would say that. Anyway I'm obviously just not in
the right areas. I love the different flavours of English that you
see. I've been working a bit on [[Comparison between cricket and
baseball]] and in the process been reading lots of articles on
baseball (written almost exclusively by Americans I think) and cricket
(mostly Australians and Brits, though some Indians, Pakistanis etc).
The difference is striking, even if I can't put my finger on it.
Similarly when I once found myself reading some of the articles about
the Singapore MRT system.

That's all stuff essentially written by locals. Working on articles
about French topics is very different - it's mostly either expats like
me, or French people wanting to share their knowledge with the
Anglophone world.

Which I suppose all leads me to think that in places en.wikipedia
*does* reflect local cultures, for articles where that makes sense,
and for more global topics, it has a more global perspective, or at
least a wider one.

Steve


subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, Fastfission <fastfission at gmail.com> wrote:
> Social activity on Wikipedia is more than just "socializing", in my
> experience. I spent most of my day-to-day time on Wikipedia either
> reverting vandalism or explaining to people why certain edits are
> better than others. A quick look at my own contributions shows that
> out of the last 50 edits, around 80% were to talk namespaces.

I'm very hesitant to apply basic statistics to trying to work out what
sort of editor someone is. Someone with a very low absolute number of
article edits (eg, <200), though, is worth a question mark if they
have a high absolute number of talkspace edits.

> Part of this involved fostering creative collaborations with others,
> getting others on-board with ideas, answering questions, etc. In the
> end all of this does have an effect on article content, but not
> necessarily a direct one.

Definitely.

> Wikipedia content is decided by a lot of back-and-forth between users.
> Any time you have lots of communication, disagreement, contestation,
> etc. between human beings you need a lot of social lubricant. You need
> ways to identify others, you need things to put around your head that
> says, "I know about this, I define myself as this, I am a real person
> and not just some name on a screen, and you should treat me that way."

Fwiw, I don't really do that. I tend to just get on the job and be
nice to people because it gets the job done better. I can only think
of about three or four people that I've made any effort to consider
"the person behind the screen", and one wasn't by choice! The others
are basically photographers - I was curious what sort of people make
the effort to take photos for WP.

So, social lubricant in the "be nice to people" way, yes. In the
"what's your name, neigbour", not necessarily (for me).

> I've nothing against that at all. I don't see any great reason to try
> and root it out. If there are a few freeloaders who are just in it for
> "social" reasons, so be it. As long as they aren't using their
> userspace for anything directly nefarious, then who cares? My time --
> and I assume the time of others -- is better served continuing my own
> business than it is getting into the business of others.

The main complaints are against people who just enjoy arguing, and
they get good value for money here.

> I'm admittedly non-interventionist here. I think it is easier and more
> pragmatic tolerate mild misuse and annoyance than to waste time trying
> to make everyone into ideal Wikipedians. As they say, if it ain't
> (really) broke, don't fix it.

There are ways of shaping a community to get more of the people you
want, and less of those you don't. Ease of access is a classic one -
make it complicated to get in, you end up with smart people. Define
firm but complicated rules, you'll get rules lawers and game players.
Promise everyone that their opinions are equally valid - you'll get
frustrated academics. (for example)

Steve


subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, Fastfission <fastfission at gmail.com> wrote:
> I'm happy to agree with that in principle, but I'm not sure we need a
> complicated policy to sort that one out. If a signature is
> legitimately fouling up editing (and it is not just a case of
> annoyance or aesthetics), we should contact the user in question,
> explain what is wrong with it, and ask them to scale it down a bit. I
> find it hard to see where this is different than any other user habits

I think in a nutshell, Wikipedia is reaching that point where we could
ask them, and they might just say "no, ask my friends, they all say
it's ok". We probably don't have that single cohesive community where
everyone shares the same ideals and standards of behaviour, at least
amongst casual editors.

Steve


subject: [WikiEN-l] "refactoring" signatures

body:
On 6/8/06, George Herbert <george.herbert at gmail.com> wrote:
>
> Watching this interchange, I was wondering exactly how valid the claim
> was that (for example) the signature refactoring complaintants were
> "social Wikipedians" who might fall under the "go away" clause.

That's a straw man.  The problem is not one of people but of a class
of behavior.


from_name: Rob Church

body:
On 08/06/06, Timwi <timwi at gmx.net> wrote:
> It is already confrontational of a programmer to pretend the whole world
> could make do with Latin-1. It is one of the most devastating and
> accordingly infuriating assumptions that still prevails despite the fact
> that Unicode is decades old. We're in the 21st century; it is no longer
> appropriate to even start programming anything where any user-visible
> text is restricted to Latin-1 or any other 8-bit charset.

Of course, of course, I clean forgot. Because a quick proof of concept
has to be PERFECT, doesn't it. Do excuse that little oversight.

It's not perfect yet. Get over it and give some feedback on the idea.

Rob Church


from_name: Elisabeth Bauer

subject: [WikiEN-l] "refactoring" signatures

body:
Tony Sidaway schrieb:
> On 6/8/06, Fastfission <fastfission at gmail.com> wrote:
>
>>Gosh, Tony, I didn't realize you had such a hard trouble reading
>>discussion pages, what with all of those colors and fonts!
>
> Now you know.

And he's not the only one.

greetings,
elian


from_name: GerardM

body:
Hoi,
For your information, there is no point in having a public wrangle
about InstantCommons, it does not help if anything it makes people
increasingly angry. It also leads to a situation where people refuse
to communicate and cooperate. From my perspective, I will need to
cooperate with people in the Wikimedia Foundation be they the Board or
the Special Projects Committee. When I have a beef with either of them
I will not have a public row.

I do however want to address Amgine's point. There is one important
difference between Commons and Napster. On Commons people are actively
engaged in ensuring that content is properly labeled and licensed.
This is in marked contrast with Napster where the defence was that
they were only providing a service and that it was not THEIR content.

Given that everything is done to make Commons free of copyrighted
articles and given that Commons explicitly aims to be a public
resource for Free material. It is stupid to suggest that this cannot
be because not everything has been 100% checked. Either it is a public
resource or it is not. You cannot have it both ways.

What InstantCommons does is nothing more than make the material that
is there as a public resource available in a convenient way.

Thanks,
    GerardM

On 6/8/06, amgine at saewyc.net <amgine at saewyc.net> wrote:
> On Thu, 2006-08-06 at 16:42 +0200, Erik Moeller wrote:
> On 6/8/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> >
> > > 4. Although copyright concerns are mentioned, they don't seem to be
> > > explored in depth. Commons has a huge amount of copyright violations
> > > on it today.
> >
> > Then they should be deleted. InstantCommons is a manual,
> > user-initiated process. Commons has no legal responsibility to stop
> > users of other wikis from copying images from Commons, whether it is
> > by means of manually downloading or uploading, or by setting their
> > wiki up for IC and initiating an IC transfer process. The copyright
> > cleanup script is a convenient thing we can provide, and by no means a
> > legal necessity.
> >
> Isn't this the Napster defense? And didn't that fail to convince the US
> Supreme Court? Wouldn't the failure to address copyright concerns result
> in Commons potentially being used as a file sharing service?
>
> Amgine
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Ben Garney

body:
On 6/8/06, Roman Nosov <rnosov at gmail.com> wrote:
>
> Well it looks like my question about why some quotation marks do break
> words and others don't will remain unanswered ("rareness" of high
> numbered punctuation doesn't make it part of a word) ? Anyway if such
> level of supporting UTF-8 is sufficient for Mediawiki then Unicode
> issue is "solved". Unicode ?ber alles.

I think it was adequately explained - the reason why it isn't detected is
because the algorithm doesn't know it's a seperation character. So it's not
seperated. If the algorithm did know, it would be seperated properly.

So perhaps someone, like you, should submit a quick patch to that part of
the diff engine, as outlined by Tim, that makes it properly interpret that
code point. If there's a general rule or table in the Unicode standard then
implementing that might be an even better option.

The unicode site, by the way, is www.unicode.org and you can find a database
of unicode character properties here:

http://www.unicode.org/Public/UNIDATA/UnicodeData.txt

with information on interpreting them here:

http://ftp.lanet.lv/ftp/mirror/unicode/3.2-Update/UnicodeData-3.2.0.html

Enjoy!

--
Ben Garney
Torque Technologies Director
GarageGames.Com, Inc.


from_name: Gerard Meijssen

body:
Brianna Laugher wrote:
> Hello,
>
> I posted this on commons-l a week ago to apparent deaf ears.
>
> While browsing in my Special:Preferences today, I noticed that we
> apparently support no less than five variants of Chinese:
>
> zh
> zh-cn (simplified, as used by the Chinese mainland)
> zh-hk (Hong Kong, traditional)
> zh-sg (Singapore, simplified)
> zh-tw (Taiwan, traditional)
>
> Is there a reason these codes have been set up as country codes rather
> than, say, zh-hans and zh-hant? (Han Chinese, simplified/traditional -
> these are codes that the Chinese translators on Commons have
> favoured.)
>
> Is there thought to be any distinction between zh-sg and zh-cn?
>
> Can the 'automatic converter' thing that zh.wp has be turned on for
> the Commons, so we can stop this unnecessary 'translation' between
> scripts anyway? (And then we just offer "zh".)
>
> cheers,
> Brianna
> en.{wp,wb}|commons|meta:user:pfctdayelise
Hoi,
I assume that what is called zh-cn is actually cmn-Hans and that zh-tw
is cmn-Hant (Mandarin). I do not really appreciate what I have to
understand by Singaporian or Hong Kong Chinese. The problem with zh
(zho) is that in ISO-639-3 it is considered a macro language and it is
really ambiguous what is to be understood by it.
Thanks,
    Gerard


list: commons-l

from_name: Matt Brown

subject: [Commons-l] some statistics

body:
I'm not so sure that any one person's efforts can make THAT much of a
difference, but I'll be happy to help with the deletion backlog.

-Matt


from_name: Roman Nosov

body:
I'm totally agree with Timwi ? proper Unicode support is a requirement
not a feature. However can someone tell me why PHP comes with no
appropriate out-of-box support for such vital feature in 21 century?
The root cause of my diff engine ignoring Unicode at the moment is
because many PHP functions simply don't work with UTF-8 encoded
strings. PHP team promises proper Unicode support only in version 6.
Yeah I guess we are still in nineties ?

However I think it's much better to honestly say upfront that Unicode
isn't properly supported then to claim that it is. For example look no
further than Wikipedia's current diff engine. Self-appointed Unicode
expert Tim Starling brags that it is extremely easy to build UTF-8
support from scratch. Well let's check that.

For example if you use ordinary single quote (the one from damned
latin-1, you can easily find it on your keyboard) to separate two
words in wikipedia then no problems. Diff engine will see these two
separate words. However if you use Left
single quotation mark (Unicode code 0x2018, the one MS Word likes to
use) to separate two words oops now these two words are treated as
one.

Test Case for everyone to check:

Using ordinary single quote:
First edit:
One'two
Second Edit:
One'three
Diff engine output:
Correctly highlights words two and three

Using left single quotation mark (Unicode code 0x2018, you might need
to type it rather than copy&paste it, of course all due to excellent
Unicode support by each and every e-mail program):
First edit:
One'two
Second Edit:
One'three
Diff engine output:
Incorrectly highlights both strings

So my question to all Unicode Nazis here is why quote from latin-1
charset is treated *differently* from slightly different Unicode
quote?

On 08/06/06, Rob Church <robchur at gmail.com> wrote:
> On 08/06/06, Timwi <timwi at gmx.net> wrote:
> > It is already confrontational of a programmer to pretend the whole world
> > could make do with Latin-1. It is one of the most devastating and
> > accordingly infuriating assumptions that still prevails despite the fact
> > that Unicode is decades old. We're in the 21st century; it is no longer
> > appropriate to even start programming anything where any user-visible
> > text is restricted to Latin-1 or any other 8-bit charset.
>
> Of course, of course, I clean forgot. Because a quick proof of concept
> has to be PERFECT, doesn't it. Do excuse that little oversight.
>
> It's not perfect yet. Get over it and give some feedback on the idea.
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] AFC needs your help!

body:
Anthony DiPierro wrote:
> On 6/4/06, Timwi <timwi at gmx.net> wrote:
>
>>>Why not set up a system where each article proposed for creation
>>>exists as a separate page.  And there could be a special page set up
>>>which points to each of them.  This special page could list the date
>>>and time created, the name of the proposed page, the number of bytes
>>>of the page, and the username or  IP address of the proposer.
>>
>>Surely that would be equivalent to just letting unregistered users
>>create pages again and having a Special page that simply lists all
>>articles that have only ever been edited by IPs.
>
> Yeah, that was my point.
>
> Although, as I thought about it more, there would potentially be one
> difference - "proposed" articles could live in a different namespace
> (and have a warning at the top or whatever).

And then the actual real difference would be what? The warning? The
namespace prefix showing up in the article title? Both of those are
trivialities. They are still publicly-visible and -editable pages that
are primarily distinguished from others by means of that Special page
that lists them. Whether that Special page performs a complex query or
just lists a namespace, is irrelevant.

Timwi


subject: [WikiEN-l] AFC needs your help!

body:
MacGyverMagic/Mgm wrote:
> To others: the whole point of AFC is to help out people who don't want to
> create an account and still want to submit articles while at the same time
> filtering out the crap.
> Allowing anyone to create articles again, would indeed overwork admins who
> work in deletion.

What difference does that make, given that AfC *also* overworks them?


subject:
[WikiEN-l] Fwd: [Wikitech-l] Special:Contributions: index
	missing?

body:
Rob Church wrote:
> There's been some discussion on a development mailing list regarding
> the namespace selector in contributions pages, which is expensive due
> to our schema arrangement.
> [...]
> What is the point of per-namespace contribution feature on live site?
> What are the applications of it?

What is the point in that question? If it is so database-intensive that
it needs to be taken down, then surely it should be taken down even if
it is useful. Conversely, if it is not database-intensive enough to be a
real problem, then surely it doesn't hurt to have it even if it isn't
useful.

Besides, it appears that few people have found a really good use for it;
it can therefore be assumed that it will not be used very frequently,
and therefore it will likely not have much database impact after all. :)

Timwi


from_name: amgine at saewyc.net

body:
On Thu, 2006-08-06 at 22:42 +0200, Daniel Arnold wrote:
So please in every local wiki educate people that Fair Use is a clear NO.
> Please make this everywhere your most important image copyright policy.
>
> I know that this sounds radical to some of you but it would really help
us a
> lot and it is worth the trouble (the trouble will quickly decrease after
> you're mainly done with fair use deletions).
>

Arnomane, perhaps you and I do not agree on the purpose of Commons, but I
thought it was to serve as a useful repository for the projects, and
minimize the need/likelihood of multiple image copies. Fair Use is
absolutely necessary for Wikinews. The fact Fair Use in any form is not
accepted on Commons is the reason Wikinews project sites now have file
uploads; Commons was not being useful to this project in this regard.

Commons does work no one else has the expertise or patience to do, and it
could be an extremely valuable tool for the WMF project sites. I do not
know about others, but this sounds to me very much like Commons is
dictating image policy to the projects, and not the other way around the
way Commons was set up to be. While I greatly respect the work Commons
does, when it interferes or harms the projects I have little respect for
the actions of Commons.

Amgine


from_name: Erik Moeller

body:
On 6/8/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> Because our interface is so helpful, his tagging looks well formed and valid.

Maybe, but we do Special:Newimages patrol fairly well for this kind of
stuff. That said:

> Over several months various Wiki's pick it up via instant commons.

Why? Is it such a hugely popular and well-known book? How did these
wikis find out that it's on Commons in the first place, to know the
filename and use it on their own wiki?  This seems like a very
artificial scenario to me. It seems much more likely that you have
_occasional_ copyvios of _single_ files that people discover on
Commons. There will also be imports of topical categories.

Let's look at some of the stuff that is actually happening. There is,
for instance, this wiki here:
http://www.orthodoxwiki.org/Category:Images

They are copying images from Commons to their galleries. You can see
some of the images they copied here:
http://www.orthodoxwiki.org/Special:Whatlinkshere/Template:Commons

Right now, they are adding a {{commons}} template to these; they
probably have uploaded some without the template. They are also adding
licensing information, which is frequently incorrect, and they are
typically not copying stuff from the description page such as author
information, e.g., compare:

http://www.orthodoxwiki.org/Image:Jerusalem.jpg
vs.
http://commons.wikimedia.org/wiki/Image:Jerusalem_from_mt_olives.jpg

As of this writing, the above image is labeled as CC-BY-NC-SA, with no
author information. The Commons image is CC-BY and attributed to
User:Jgritz.

Correctly copying licensing and attribution information is complex
stuff. That it is copied at all above is already a pleasant surprise.
There will be many places where the _project leaders_ have no
knowledge of copyright. As Commons becomes a more widely used
resource, the number of these places will increase dramatically.

Leaving the process of sorting out license requirements to humans, as
we do now, causes many more problems than leaving it to machines
would.

> As proposed it is also a vehicle where any irresponsibility on our
> part can lead to greatly increased harm.

I simply disagree. If the file in question - a mislabeled book cover,
or whatever - is so popular and will evade copyright detection on
Commons for months, then a) our copyright processes function very
poorly, b) this fact could be exploited for any purpose regardless of
InstantCommons or not.

It seems much more likely that, if we do it right, IC will increase
our responsiveness to copyright issues, as someone discovers a copyvio
on an IC wiki, sees the backlink to Commons, and points it out to us.

Erik


from_name: Raphael Wegmann

subject:
[WikiEN-l] Cultural distinctions are accidental?
 Consensus	among cultures is bad?

body:
Steve Bennett wrote:
> On 6/8/06, Raphael Wegmann <raphael at psi.co.at> wrote:
>> Regardless whether the cultural distinctions are intended or not,
>> they are a fact. I would consider i.e. a translation of terms like
>> Islam and Terrorism from english to arabic and vice versa very
>> exciting. I honestly thought about paying a translator to do it.
>
> Why would you translate the Wikipedia article? Wouldn't it be more
> interesting to choose a more biased source? If you're just curious on
> a middle-eastern perspective, Al Jazeera is a good place to read in
> English.
>

I certainly know Al Jazeera and http://www.archive.org/details/mosaic
but IMHO the news reports of a media networks are far less interesting
than a "public Wikiconsensus" on "generic" topics like Islam, 9/11,
Terrorism, Israel, etc.
Apart from being exciting, those translations whould show how culturally
biased Wikipedia actually is.

--
Raphael


body:
On 6/8/06, Daniel Arnold <arnomane at gmx.de> wrote:
> FYI: Wikimedia Commons has already such a thing. We made our
> license/maintenance templates machine understandable (not just readable :p)
> and any script can make use of it.

IC could certainly filter any images with templates from:
http://commons.wikimedia.org/wiki/Category:Problem_tags

Erik