from_name: Birgitte Arco

body:
> I am perplex that the en.wikibooks does not have a
> big enough base of
> editors to vote on a check user...
> I am quite lazy, so I will not go to the stats page
> to check. But can
> you roughly say how many active editors per month
> the project currently
> has ? How many very active editors per month ?
>
> ant
>

The number of editors who edit a small project, and
the number of editors who pay any attention to the
community pages are two completely different things.
At English Wikisource which has over 3,000 registered
users (There is no stats on the languages of
Wikisource) often closes consensus deletion with two
votes plus the nomination.  There are less than 10
people who regularly edit at the Scriptorium, although
I hope more read it.  There are a lot of editors who
come over from Wikipedia to work on a single project,
and only pay attention to our policies if that project
is up for deletion of a copyright violation.  And
vandalism is definitely on the rise.  We used to have
a few vandals that just messed up one page (Macbeth is
a favorite).  In the past month we have had three
attacks that seem to be by a bot.  It registered some
name with Troll in it and replaces entire pages with
Animations of a troll until blocked.  It seems each
attack has targeted the sames pages.  I feel the need
of a project for checkuser and ability to gather 25
votes are completely unrelated.  Perhaps if everyone
still feels this is non-negotiable we could have a
steward who is generally available personally assigned
to each project that requests one.

When I have needed a checkuser in the past I have had
to go through third parties on IRC because no
available steward felt comfortable fulfilling my
request directly.  And that makes it hard on me when
my blocks are questioned and I am accused having
ulterior motives (this was from outside the project).
I feel in my case I alerted and consulted with other
administrators and people outside of Wikisource enough
to feel confident these accusations cannot taken
seriously.  However, administrators of small projects
are being put in the position of deciding between
protecting the project legally or from vandalism or
else protecting their reputations from accustions of
blocking people on unconfirmed suspicions.  If I
hadn't been trusted by someone who was trusted by
stewards, I would have been put in a very nasty
postition.  If things continue as they are, sooner or
later some one on some project is going to be stripped
of adminship because they did what they needed to do
to protect the project, and didn't think to cover
themselves as well as I did.

Birgitte SB

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


list: wikimedia-l

source: pipermail-mbox

subject:
[Foundation-l] Stewards are ignoring requests for CheckUser
	information?


list: wikien-l

from_name: Steve Bennett

subject: [WikiEN-l] Georgia/Victoria

body:
On 13/04/06, David Boothroyd <david at election.demon.co.uk> wrote:
> Other editors subsequently sorted them by field, and then Uncle G
> removed the 'disambiguation' notice on the grounds that the names were
> not really ambiguous, which is (as usual for Uncle G) quite correct.

Right, I think there's something to be said for lists which group
people by last name, or places with *similar* names. However, it's not
a disambiguation page. In the case of the Victoria dab page, entries
like "Victoria Falls" seem misplaced to me - no one looking for
Victoria Falls would go to the "Victoria" entry.

In fact, if you're talking true ambiguity - names that can't be
disambiguated using a fuller title or some natural construct - there
are very few Victorias. The British monarch could be searched for
under Queen Victoria. The Canadian city could be found under
"Victoria, British Columbia" (if indeed that's the standard
nomenclature). The various mountains, lakes and so on could be found
under "Lake Victoria" etc.  Which leaves the following genuinely
ambiguous entities:

Victoria (Australian state)
Victoria (Cervecer?a Centro Americana), a pale Guatemalan lager.
Victoria (Grupo Modelo), a dark Mexican lager.
Victoria (novel), an 1898 novel
Victoria (game), a PC RTS game released by Paradox Entertainment
Victoria (ship), the first ship to circumnavigate the globe
Victoria (waterlily), the waterlily genus
Victoria (name)

A much shorter list, isn't it!

(arguably a few of the cities named Victoria should be on the list, if
"Victoria, Newport" is not a natural construction in the UK etc.

Steve


subject:
[WikiEN-l] Alexa - rankings differenciated among users from
	different countries

body:
On 14/04/06, Mathias Schindler <neubau at presroi.de> wrote:
> AU  15
> NZ  08

#8 in New Zealand but #15 in Australia? I feel suspicious.

Steve


subject: [WikiEN-l] Wikipedia compared..... again!

body:
On 14/04/06, Arwel Parry <arwel at cartref.demon.co.uk> wrote:
> The May issue of BBC Focus magazine ("The world's best science and
> technology monthly"), (www.bbcfocusmagazine.com, but the contents are
> not online) is interesting from a Wikipedia point of view. Firstly

Wow, those a really fantastic results. I would have expected us to
clean up in the Bird Flu category (so to speak), but I was less
certain about the other two - we can definitely be patchy on obscure
(well, to me anyway :)) biographies. Thank god they chose a railway
engineer - I notice that areas that appeal to
collectors/spotters/obsessive compulsives (such as trains, military
aircraft, stamps...) do a lot better than, say, art or vague concepts.

Steve


subject: [WikiEN-l] Archives as sources proposal

body:
On 13/04/06, Guettarda <guettarda at gmail.com> wrote:
> Unpublished primary sources can only be valid sources about the content they
> contain ("his birth certificate says...").  In the hands of an amateur, they
> really can't be taken to say anything more, we can't evaluate how good the
> source is, we can't determine how much weight to give to one source as
> opposed to another...

I like your approach here. Proposal for NOR summary: "Leave original
research to the experts. If you are an expert, leave it to a different
expert."

Seriously, that's the basic problem isn't it - amateurs trying to do
the work of experts. That was exactly the issue at [[Safe Speed]] -
editors were attempting to debunk the claims of this group themselves,
by digging up scientific papers and applying them directly to the
data. Which wound up with a Wikipedia amateur scientist going head to
head with a Safe Speed amateur scientist - totally pointless.  The few
"professional" refutations of their claims were totally acceptable and
encyclopaedia-worthy, of course.

Steve


list: wikitech-l

from_name: Seiduluqman at aol.com

subject: [Wikitech-l] (no subject)

body:
please cancel Email to my mail box
thank you
s luqman


from_name: William Allen Simpson

subject: [Wikitech-l] templates and RTL issues

body:
Brion Vibber wrote:
> William Allen Simpson wrote:
>> We covered these issues in great detail in the IETF over a decade ago.
>> There was a lot of acrimonious argument then, too, but Hank (and others)
>> did a great job drafting a technical solution that solved the
>> transmission and editing problems.
>>
>> (1) A canonical form for storage and transmission.  In SMTP, all storage
>> and transmission is LTR.  I don't see why that couldn't apply here, too.
>> Sure, it makes Hebrew appear backward in storage, but we usually don't
>> look at the stored version.
>>
>> (2) Display and edit as RTL.  In practice, this turned out to be fairly
>> simple by thinking about such things as opening and closing parentheses,
>> rather than left and right.  They simply are reversed on display.
>>
>> (3) This allows all email to be parsed consistently, without change to
>> the existing mail transmission programs, while specialized mail user
>> agents (MUA) handle display of the text body.
>
> Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C
> world has explicitly embraced bidirectional text stored in logical order.
>
Yes, that's good, a canonical form for storage.

> Parsing of markup happens on text in logical order. Since the markup is very
> much embedded in the text and requires both exposure to human editors and
> consistent parsing by the machine, I'm not sure that e-mail is a good
> comparison. The 'markup' in e-mail is invisible to the user: headers, escape
> codes, MIME content part separators.
>
But not when editing.  The edits are handled by specific MUA.  Some expose
the raw markup, others hide the markup and handle the conversions.

> Our output is to HTML, and editing is done in a web browser. This is a heavily
> bidi-centric environment which I don't think we could really override if we
> wanted to.
>
I'm sorry, perhaps I'm not sufficiently clear.  The final output of text
pages should always be handled in the standard canonical manner.

It's the edits that seem to be the problem.  The edit box is defined and
filled and processed by Wiki software.  That is, this software is providing
the UI.  So, I was proposing that the Wiki software do the flipping into
the edit box, then reversing and preprocessing from the edit box back into
the canonical format.

That is, folks seem to have a problem with treating the edit box the same as
a raw text editor.  I was using the parallel that user freindly email
editors don't treat the text as "raw", instead they handle the user edit
processing and conversion from/to the canonical format.

Likewise, the difference in editing pages with Mozilla as opposed to the
raw HTML with BareBone's BBEdit (my personal preference).  Most folks seem
to like the former.

Still clear as mud?


from_name: Erik Moeller

subject:
[Wikitech-l] Binary vs. non-binary strings (was: What is
	required to "fix search"?)

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

> AFAIR, most string matches in mysql are case insensitive, which would
> mean that we could have indexed case insensitive matches quickly...
> but I'm guessing that our use of binary fields for titles (which is
> required because no version of mysql has complete UTF-8 support) most
> likely breaks that.

Yes, they are, and yes, it does. Could someone explain what the exact
reason is that we're using varchar binary in MediaWiki for page
titles? I've been using regular varchars for my WiktionaryZ tables,
and so far it seems to work fine with UTF-8. Where exactly does a
non-binary varchar break?

Also, according to the MySQL 5.0 documentation:
http://dev.mysql.com/doc/refman/5.0/en/binary-varbinary.html

<quote>
The BINARY and VARBINARY data types are distinct from the CHAR BINARY
and VARCHAR BINARY data types. For the latter types, the BINARY
attribute does not cause the column to be treated as a binary string
column. Instead, it causes the binary collation for the column
character set to be used, and the column itself contains non-binary
character strings rather than binary byte strings. For example,
CHAR(5) BINARY is treated as CHAR(5) CHARACTER SET latin1 COLLATE
latin1_bin, assuming that the default character set is latin1. This
differs from BINARY(5), which stores 5-bytes binary strings that have
no character set or collation.
</quote>

Since we are using VARCHAR(255) BINARY for page titles, rather than
VARBINARY(255), does that mean that "it causes the binary collation
for the column character set to be used"? If so, does the use of
VARCHAR(255) BINARY, as opposed to a simple VARCHAR(255), affect
anything but the sorting order (collation)?

Might it make sense to use non-binary strings and use binary
comparisons instead where case-sensitivity is required?

Erik


from_name: Will "Sceptre" Noble

body:
How long will it be until EB complains though?
--
-Sceptre
http://tintower.co.uk


subject: [Wikitech-l] ParserFunctions trial

body:
Tim Starling wrote:
> William Allen Simpson wrote:
>> Conrad Dunkerson wrote:
>> When Tim says "trial", how is the testing coordinated?  Shouldn't it be
>> tried on a few not too prominent places, rather than fix every qif now?
>>
>> Where should I be looking for posts coordinating this?
>
> The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to
> enable it permanently. The critics of this concept now have one final chance to turn community
> opinion against it, before it becomes ingrained. However the reception has generally been positive.
> I've received a number of private compliments on it, in addition to what can be seen publically.
>
OK, here's another public compliment!  Thank you!

> There's also the possibility of bugs and syntax changes. We've already had one syntax change: I
> changed the whitespace handling in #if to mirror the behaviour in template parameters, to allow for
> easier conversion and neater multi-line syntax.

Yes, that's great.

> ...  There's also a pending suggestion to allow
> whitespace between the #if and the colon, and a suggestion to make #if treat "0" as true, both of
> which may well be implemented.
>
Please don't implement either of these.

It doesn't make sense to have whitespace between the # and the if, and no
demonstrable reason to have it before the colon.

The logic of qif was often confusing.  There's only very short term
advantage to backward compatibility.  Having #eval and #if work like
other languages will be easiest to document in the long term.  Remember,
features aren't of much use without easy to understand documentation.

> One of Gangleri's syntax suggestions sounded quite reasonable and I may well implement it. The idea
> if I understand it correctly was to treat pipe characters beyond the specified maximum number of
> arguments literally, e.g. {{#if: 1 || literal pipe: | }}.
>
Actually, the trailing pipe doesn't sound reasonable to me, as it only works
with "else" parameters, requiring logic to be inverted.  There's a couple of
fairly simple alternatives (standard html syntax, or the {{!}} template), and
they work in a consistent, predictable, symmetric manner.  Again, ease of
documentation.


from_name: Reinhardt WIEWE @ torg.is

subject: [Wikitech-l] ParserFunctions trial

body:
On Fri, 14 Apr 2006 13:51:58 +1000
 Tim Starling <t.starling at physics.unimelb.edu.au> wrote:

> The main reason I'm calling it a trial is to avoid appearing to have made a
> unilateral decision to
> enable it permanently. The critics of this concept now have one final chance
> to turn community
> opinion against it, before it becomes ingrained. However the reception has
> generally been positive.
> I've received a number of private compliments on it, in addition to what can
> be seen publically.
>
> There's also the possibility of bugs and syntax changes. We've already had
> one syntax change: I
> changed the whitespace handling in #if to mirror the behaviour in template
> parameters, to allow for
> easier conversion and neater multi-line syntax. There's also a pending
> suggestion to allow
> whitespace between the #if and the colon, and a suggestion to make #if treat
> "0" as true, both of
> which may well be implemented.
>
> One of Gangleri's syntax suggestions sounded quite reasonable and I may well
> implement it. The idea
> if I understand it correctly was to treat pipe characters beyond the
> specified maximum number of
> arguments literally, e.g. {{#if: 1 || literal pipe: | }}.
>
> -- Tim Starling

Thank you Tim for your work and for working on extending the template syntax
which was pending for a while.

Sorry if some of my comments have been 'sarcastic' but I never tried to be
polemic. Thanks for the trimming and supporting new lines between the
delimitors.

My comments where mainly based on the "missing somthing" in the syntax, on the
interaction with other features. As has been suggested at
http://meta.wikimedia.org/wiki/Talk:ParserFunctions there are 'solutions' to
implement different needs (as table support) but these are 'workarounds'
falling back to HTML syntax usage, escaping tricks and various usage of expoits
(because of the knowledge how the implementation is today).

I suppose that the "missing somthing" is a "grouping construct" and the syntax
can be realy simplistic:
{{# <wikisyntax> }} where <wikisyntax> is whatever valid wikisyntax as
(sub)table code etc.

The idea comes from
http://meta.wikimedia.org/wiki/Talk:ParserFunctions#.23switch

where
{{#switch: VALUE-TO-BE-TESTED
 | foo|bar = hello
 | baz = world
 | = Neither ''foo'' nor ''bar'' nor even ''baz''
}}

could also be
{{#switch: VALUE-TO-BE-TESTED
 | foo|bar|bla|more = hello
 | baz = {{# world }}
 | = Neither ''foo'' nor ''bar'' nor ''bla'' nor ''more'' nor even ''baz''
}}

regarding {{#if: 1 || literal pipe: | }} I suggest that if you could implement
{{# <wikisyntax> }} then the best way would be to output FAST and LOUD an
'Invalid trailer' error message. This defetes arguments that the syntax is not
symmetrical with respect to the <then> and <else> branches.

{{# }} will be / should be stable agains {{subst:}} (and the {{substall:}}
feature request).

best regards reinhardt [[user:gangleri]]


list: foundation-l

from_name: Robert Scott Horning

subject:
[Foundation-l] Stewards are ignoring requests for
	CheckUser	information?

body:
Anthere wrote:

>The reason for the 25 votes limit comes from two reasons
>* A community with less than 25 users is unlikely to really need
>frequent checkusers, because it is a project with reduced activity. So,
>it can not be a heavy load for stewards.
>* A community with less than 25 users has a rather serious risk to have
>a rather little known editor become a checkuser, rather than a trusted
>oldbie. If we start handing out status just as we do for sysop status on
>small projects, I think there will be abuse. I say this from my
>experience, as I had to unsysop several sysops on small projects (the
>guys did not know our basic rules, behaved like dictators with the
>handful of editors, put advertisements on the main page, controlled povs
>etc...).
>
>I am perplex that the en.wikibooks does not have a big enough base of
>editors to vote on a check user...
>I am quite lazy, so I will not go to the stats page to check. But can
>you roughly say how many active editors per month the project currently
>has ? How many very active editors per month ?
>
>ant
>
>
Since the stats page hasn't been updated since November of last year, it
is completely useless to even gague what the current activity is on any
Wikimedia project.  I can only use the current activity on the Wikibooks
staff lounge to even remotely gague what the current user activity level
is, but I would guess it is pretty close to about 20 user at the
absolute top.  Really stretching it perhaps we can get to 25 total at
the most.

And as for advertising this, I guess we could put it in bold 40 point
type on the project main page with a link to a special page only for
this kind of request.  I think that is way over the top and something
that is not needed in this situation.  The advertising was more than
adequate, it is just that this is a very unreasonable request.

As for a "community with less than 25 users unlikely needing frequent
checkuser scans", I think this is mistaken totally what is going on.
 en.wikibooks has numerous links from within Wikipedia, and is being
hammered by vandals that have moved on from Wikipedia, indeed with
excellent training on how to be a vandal on Wikipedia, and taking on
other projects as well that don't have quite the same pool of
administrators.

As for handing out checkuser status to people who are not trusted
oldies, that is totally rediculous as well.  There are admins and
bureaucrats on en.wikibooks who are also admins on other projects,
including meta, wikinews, and even en.wikipedia.  Active ones at that.
 I see absolutely no reason why the standards for giving somebody
bureaucrat status when you can't also give them checkuser status.

Furthermore, what abuse could possibly happen with somebody having
checkuser scans?  Really, at the most extreme?  With bureacrat status I
could give admin status to a whole team of 'bots that would then in
tandem go through and systematically delete every page on a project and
block every user.  Talk about damage to a project.  With checkuser
privileges, all you have access to is just the IP address of each user.
 So the absolute worst damage is that they publish on an external
website (making it harder for the board to go after that user) all of
the IP addresses of every user.  Which is worse?  Really, think about it.

More to the point, show me a single user that has been given checkuser
rights on any local project besides a Wikipedia and meta.  This would be
a contrary example to prove me wrong.  If not, why not?  Because
checkuser rights are not needed except on Wikipedia?

--
Robert Scott Horning


from_name: Sean Barrett

subject: [WikiEN-l] Archives as sources proposal

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

Oskar Sigvardsson stated for the record:

> Honestly, the verifiability argument doesn't fly at all with me. If
> you pick information out of an archive, it's most certainly
> verifiable, someone else can check it out as well. I realise that that
> is a hassle, but that doesn't change the fact that it is verfiable.

I have a specific example: the Wikipedia article on a notable historical
figure, like all other sources I have checked, states that he had two
wives (in series, not parallel).  However, an official government-issued
marriage certificate on file in a county clerk's office proves that he
had another wife between those two.  What will I be permitted to add to
this person's article?

- --
 Sean Barrett     | People who need to be shot usually need to
 sean at epoptic.org | be shot soon and a lot. Very few people
                  | need to be shot later or just a little.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEP+LKMAt1wyd9d+URAp4AAJ984qBdQhswUwoBviPIRMz7Eq6txwCfeHBX
rkogSY+tc/pXtn+zcn5iszg=
=L2QT
-----END PGP SIGNATURE-----


subject: [Wikitech-l]  operational issues

body:
Jay R. Ashworth wrote:
> On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
>> I'm a recent addition to this list.  I joined after the Apr 9 outage,
>> thinking that as a longtime Internet engineer I'd be able to help on
>> operational issues.  Sadly, that doesn't seem to be a focus here.
>
> Note that there are many lists related to MediaWiki and Wikimedia
> Foundation issues; it's possible that you're on the wrong one.
>
Say Jay, you're as acerbic as ever.  Anything's possible.  Any suggestions?


from_name: Tels

subject: [Wikitech-l] ParserFunctions trial

references:
<e1i1nn$oek$1@sea.gmane.org> <443D8A87.9040605@gmail.com>
	<e1n68r$196$1@sea.gmane.org>

body:
Moin,

On Friday 14 April 2006 05:51, Tim Starling wrote:
> William Allen Simpson wrote:
> > Conrad Dunkerson wrote:
> >>* Tim Starling wrote:
> >>>The extension for mathematical expressions and conditional
> >>> constructs has been enabled on all Wikimedia wikis, on a trial
> >>> basis. Documentation is at:
> >>>
> >>>http://meta.wikimedia.org/wiki/ParserFunctions
> >>>
> >>>See the talk page for discussion.
> >>
> >>Great!
> >>Wonderful job Tim! This is wonderful and will vastly simplify tons of
> >> things.
> >
> > When Tim says "trial", how is the testing coordinated?  Shouldn't it
> > be tried on a few not too prominent places, rather than fix every qif
> > now?
> >
> > Where should I be looking for posts coordinating this?
>
> The main reason I'm calling it a trial is to avoid appearing to have
> made a unilateral decision to enable it permanently. The critics of
> this concept now have one final chance to turn community opinion
> against it, before it becomes ingrained. However the reception has
> generally been positive. I've received a number of private compliments
> on it, in addition to what can be seen publically.

There really is nothing you can do it people absolutely, positively want
to re-invent the wheel aka: a new programming language in completely new
environment. I have said my reasons against it, and that's it.

Best wishes,

Tels

--
 Signed on Fri Apr 14 11:14:30 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "I know what I don't know, and to this day I don't know technology and I
 don't know accounting and finance." -- Bernie Ebbers, former WorldCom
 Inc. CEO, speaking in his defense during the WorldCom fraud trial.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060414/3ba9a941/attachment.pgp>


subject: [WikiEN-l] Georgia/Victoria

body:
On 14/04/06, Matt Brown <morven at gmail.com> wrote:
> I disagree with removing everything that has a natural qualifier,
> since people may not know or think of the correct one.  E.g. if
> someone is searching for a city named Victoria, they may not know what
> state, province, county or whatever it's in.
>
> It makes sense to list the more likely cases first, though.

Several possibilities:
1 List only true ambiguities, point all others to a subpage ("things
called Victoria")
2 List true ambiguities first, followed by "other things with the word
Victoria in them"
3 List true ambiguities and things called Victoria all mixed in
together (current strategy)

I would tend to agree that strategy 2 is better.

Also note that I'm obviously talking about a general strategy for big
disambig pages, not just the Victoria page :)

Steve


subject: [Wikitech-l] ParserFunctions trial

body:
On 14/04/06, Tels <nospam-abuse at bloodgate.com> wrote:
> There really is nothing you can do it people absolutely, positively want
> to re-invent the wheel aka: a new programming language in completely new
> environment. I have said my reasons against it, and that's it.

I don't know if it counts as "re-inventing the wheel" when the old
wheel is not available. There is no workable alternative to these
parser functions, correct? And the only partial alternatives were more
Flindstone vehicles than proper wheels...

Steve


subject: [Wikitech-l] templates and RTL issues

body:
Ilmari Karonen wrote:
> William Allen Simpson wrote:
>> (2) Display and edit as RTL.  In practice, this turned out to be fairly
>> simple by thinking about such things as opening and closing parentheses,
>> rather than left and right.  They simply are reversed on display.
>
> The major difficulty, based on what I've seen, seem to be parentheses
> and other punctuation in mixed LTR/RTL text.  The browsers try to guess
> which way these should be displayed, but they're not very good at it.
>
> This isn't much of a problem in the displayed content, since there we
> can use  tags to explictly set the directionality, but in the edit
> box.  Ironically, HTML tags themselves are a problem when embedded in
> RTL text, since they themselves consist of LTR text surrounded by paired
> delimiters.  For example, if the source of a page contained, in storage
> order, the string "HEBREW", where the capitals stand for
> Hebrew letters, it may render in the edit box as "WEspan>/>RBspan>>EH".
>   Not very easy to edit, is it?
>
Aha, I'd not considered that this problem would also occur with the HTML
markup itself.  Seems like the same problem as templates.

> As a practical suggestion, it might be a good idea to set the CSS
> property "unicode-bidi: bidi-override;" for the edit box.  That should,
> in browsers that understand it, force all the text in the edit box to
> render in the same direction.  That way, on a RTL wiki, the example
> string above would render as "WE<naps/>RB<naps>EH", which at least is
> less confusing than the current rendering.
>
I only knew about "<BDO>...</BDO>" but not "bidi-override;" for entire
sections, very clever.

> In fact, I just tested it by adding:
>
> FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
>
> to my monobook.css on yi.wiktionary and it seems to work.  Gangleri, can
> you try this and say if it helps any?
>
Might check with a variety of editors in several languages, as Gangleri
admits he doesn't actually write them.  Are these well represented on
technical lists?


from_name: Mathias Schindler

subject:
[WikiEN-l] Alexa - rankings differenciated among users
 from	different countries

body:
Nathaniel Sheetz wrote:
> You have ES listed twice--is one of them supposed to be EN, perhaps?

there is no Country with EN as an ISO 3166-1 alpha code. BTW:  Alexa has
filed the UK under "GB".

I don't know where my mistake is but ES is 14.


from_name: Patrick, Brad

subject:
[Foundation-l] Stewards are ignoring requests for
	CheckUserinformation?

body:
My personal two cents on WS:User:Birgitte Arco is that she is a
responsible and valuable member of the community generally, and in large
measure the soul of Wikisource (tortured, fragmented or otherwise).  I
was disturbed to hear about questioning of her ulterior motives, and
having been involved with Checkuser issues for Wikisource myself, in my
experience she acted positively and appropriately.

>From my perspective, I would hate to see damage done to the projects
"for want of a nail."  The kingdom should not be lost; we should find a
way to either grant status on an interim basis or otherwise adjust the
guidelines.  The vandals have tools, so should we.  We must act to
defend ourselves - even Wikisource - and not let the primary goal of
promoting the projects fall flat in the face of rather arcane
administrative details (not that Checkuser isn't important - to the
contrary - but it shouldn't be more important than the project itself).

-BradPatrick

==========
When I have needed a checkuser in the past I have had
to go through third parties on IRC because no
available steward felt comfortable fulfilling my
request directly.  And that makes it hard on me when
my blocks are questioned and I am accused having
ulterior motives (this was from outside the project).
I feel in my case I alerted and consulted with other
administrators and people outside of Wikisource enough
to feel confident these accusations cannot taken
seriously.  However, administrators of small projects
are being put in the position of deciding between
protecting the project legally or from vandalism or
else protecting their reputations from accustions of
blocking people on unconfirmed suspicions.  If I
hadn't been trusted by someone who was trusted by
stewards, I would have been put in a very nasty
postition.  If things continue as they are, sooner or
later some one on some project is going to be stripped
of adminship because they did what they needed to do
to protect the project, and didn't think to cover
themselves as well as I did.

Birgitte SB

-----------------------------------------------------------------------------------------------------------
Disclaimer under IRS Circular 230: Unless expressly stated otherwise in this transmission, nothing contained in this message is intended or written to be used, nor may it be relied upon or used, (1) by any taxpayer for the purpose of avoiding penalties that may be imposed on the taxpayer under the Internal Revenue Code of 1986, as amended and/or (2) by any person to support the promotion or marketing of or to recommend any Federal tax transaction(s) or matter(s) addressed in this message.

If you desire a formal opinion on a particular tax matter for the purpose of avoiding the imposition of any penalties, we will discuss the additional Treasury requirements that must be met and whether it is possible to meet those requirements under the circumstances, as well as the anticipated time and additional fees involved.
-----------------------------------------------------------------------------------------------------------
Confidentiality Disclaimer: This e-mail message and any attachments are private communication sent by a law firm, Fowler White Boggs Banker P.A., and may contain confidential, legally privileged information meant solely for the intended recipient. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited. Please notify the sender immediately by replying to this message, then delete the e-mail and any attachments from your system. Thank you.


from_name: Dariusz Siedlecki

body:
On 4/14/06, Angela <beesley at gmail.com> wrote:
> > Why has no steward responded to these and many other requests for
> information
> > made in February, March, and April 2006?
>
> Only three stewards (Anthere, Datrio, and Oscar) have CheckUser
> access. I don't know if the backlog is because the policy is unclear
> on when requests can be fulfilled, or whether there just aren't enough
> people willing to carry out these requests.

Not really - we have CheckUser access on Meta, but every Steward can
give him CheckUser access on any other wiki.

Personally, I'm taking care of every request that'll get through _to
me_. I'm not checking [[Request for CheckUser information]] all the
time, I'll confess. I'll try to take care of these requests in a few
minutes, I hope someone will be able to help me.

--
Pozdrawiam,
Dariusz Siedlecki


subject: [Wikitech-l] templates and RTL issues

body:
Reinhardt WIEWE @ torg.is wrote:
>> In fact, I just tested it by adding:
>>
>> FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
>>
>> to my monobook.css on yi.wiktionary and it seems to work.  Gangleri, can
>> you try this and say if it helps any?
>>
>> --
>> Ilmari Karonen
>
> Thanks Ilmari for the suggestion.
>
It wasn't a suggestion, it was a question.  Please say whether it helps?

> Niklas and Rob suggested
> http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&action=edit
> form#editform textarea#wpTextbox1 { direction: ltr }
> form#editform input#wpSummary { direction: ltr }
>
But that just makes everything ltr.  Not what was under discussion here.

> This is just a part of the interface. It does not cover search, move, delete,
> undelete, block etc. fields
>
> Editing RTL in MediaWiki is a mather of practice. As requested in
>
> Allow users to change text direction in all text input and textarea boxes
> http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
>
> the change from LTR to RTL editing and viceversa should be as easy as possible.
> I would realy be happy to have a choice in 'special:Preferences'.
>
> Anonymous editors would not have this posibility. If they accept cookies one
> could offer two radio buttons for a 'LTR' or 'RTL' choice.
>
But not possible to be addressed until folks know the technical solution.
Stay focused.  Does bidi-override help with template edits?


from_name: Angela

body:
> Why has no steward responded to these and many other requests for information
> made in February, March, and April 2006?

Only three stewards (Anthere, Datrio, and Oscar) have CheckUser
access. I don't know if the backlog is because the policy is unclear
on when requests can be fulfilled, or whether there just aren't enough
people willing to carry out these requests.

Angela.


from_name: Jay R. Ashworth

subject: [Wikitech-l] operational issues

body:
On Fri, Apr 14, 2006 at 11:14:21AM -0400, William Allen Simpson wrote:
> Jay R. Ashworth wrote:
> > On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
> >> I'm a recent addition to this list.  I joined after the Apr 9 outage,
> >> thinking that as a longtime Internet engineer I'd be able to help on
> >> operational issues.  Sadly, that doesn't seem to be a focus here.
> >
> > Note that there are many lists related to MediaWiki and Wikimedia
> > Foundation issues; it's possible that you're on the wrong one.
> >
> Say Jay, you're as acerbic as ever.  Anything's possible.  Any suggestions?

You're projecting, William; that was as even-handed as anything I ever
say.

On looking at the mailing list descriptions at http://mail.wikimedia.org/
though, I'd have to say I'm wrong; this apparently *is* the ops list.

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: [Wikitech-l] templates and RTL issues

body:
Brion Vibber wrote:
> Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C
> world has explicitly embraced bidirectional text stored in logical order.
>
> Parsing of markup happens on text in logical order. Since the markup is very
> much embedded in the text and requires both exposure to human editors and
> consistent parsing by the machine, I'm not sure that e-mail is a good
> comparison. The 'markup' in e-mail is invisible to the user: headers, escape
> codes, MIME content part separators.
>
As a followup, a little searching found:
   http://www.w3.org/TR/REC-html40/struct/dirlang.html

Amazingly, this references Hank's work on email mentioned earlier:
   http://www.w3.org/TR/REC-html40/references.html#ref-RFC1555
   http://www.w3.org/TR/REC-html40/references.html#ref-RFC1556

> Our output is to HTML, and editing is done in a web browser. This is a heavily
> bidi-centric environment which I don't think we could really override if we
> wanted to.
>


from_name: Brion Vibber

subject:
[Wikitech-l] Binary vs. non-binary strings (was: What
 is	required to "fix search"?)

body:
Erik Moeller wrote:
> On 4/13/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> AFAIR, most string matches in mysql are case insensitive, which would
>> mean that we could have indexed case insensitive matches quickly...
>> but I'm guessing that our use of binary fields for titles (which is
>> required because no version of mysql has complete UTF-8 support) most
>> likely breaks that.
>
> Yes, they are, and yes, it does. Could someone explain what the exact
> reason is that we're using varchar binary in MediaWiki for page
> titles? I've been using regular varchars for my WiktionaryZ tables,
> and so far it seems to work fine with UTF-8. Where exactly does a
> non-binary varchar break?

It could break string matching, but would definitely break sorting. (Sorting by
codepoint may suck, but at least it's predictable.)

More generally, deliberately choosing a non-binary collation which applies to a
*different character set* from the one really you're using seems pretty silly.
You get unpredictable, incorrect sorting and potentially have strings rejected
as invalid.

> Might it make sense to use non-binary strings and use binary
> comparisons instead where case-sensitivity is required?

When MySQL finally reaches the mid-1990s and supports full Unicode, we'll be
able to do that.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060414/baa6a9b8/attachment.pgp>


subject: [WikiEN-l] Archives as sources proposal

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

Guettarda stated for the record:

> In the case of a discrepancy between what you can find for yourself and what
> the article says - I suppose the place to start is with {{fact}} or
> something stronger.  Obviously, if you have found the marriage certificate,
> why haven't other people?  Or is it that they just aren't famous enough to
> have a real biographer?  I'd say it is problematic.  Personally I wouldn't
> think twice about trusting Sean's veracity - but the truth is, we don't have
> "trusted editors" and in theory, what stands for Sean should stand for any
> anon.

Thank you for the complement, but I would never expect anyone to simply
take anyone else's word for any source.  In this situation, I would post
a scanned copy of the certificate and detailed information about where
to see the original.

I maintain that mere difficulty of access should not be a criterion in
evaluating sources.  If a source /can/ be obtained by any editor, be it
by Google, by using the public library, by snail-mail, or by traveling
by camel to Samarkand, then it is a valid source, IMAO.  In contrast,
many of us have access to material that cannot be verified by those
outside our professions.  There is, for example, quite a lot of
perfectly innocuous, unclassified, public domain data that only people
with .mil e-mail addresses would be able to verify.

- --
 Sean Barrett     | All I ask is the chance to prove
 sean at epoptic.org | that money can't make me happy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEQAKSMAt1wyd9d+URAlxlAJ9KmsfvgAXNAogic0WWMjF+vntl2QCePDgt
3YIgSBUlHg7TjXXKl9H6WZE=
=1zMy
-----END PGP SIGNATURE-----


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] Georgia/Victoria

body:
David Boothroyd wrote:
> Alphax writes:
>> Steve Bennett wrote:
>>  > On 4/13/06, Alphax (Wikipedia email) < alphasigmax at gmail.com > wrote:
>>  >
>>  >> Without even looking, I'd suggest something like:
>>  >>
>>  >> * [[Queen Victoria]]
>>  >> * [[Victoria, Australia]]
>>  >> ** Stuff relating to Victoria, Australia
>>  >> * [[Victoria, British Columbia]]
>>  >> * Stuff relating to Victoria, British Columbia
>>  >
>>  >Have a look now.
>>
>> Nice work. I've added {{disambig}} to the top as well, since (somewhere,
>> probably [[Wikipedia:Disambiguation]]) says that you can do so for
>> really long disambiguation pages.
>
> A few months ago, musing on the conjunction between Sven-Goran Eriksson
> and Sven the scorer on "I'm Sorry, I Haven't a Clue", I noticed there
> wasn't a page for [[Sven]]. Using Special:Allpages to identify the page
> produced a very long disambiguation page which included all the people
> called Sven on which there was an article. A brief introduction simply
> stated that Sven was an old German first name.
>
> Other editors subsequently sorted them by field, and then Uncle G
> removed the 'disambiguation' notice on the grounds that the names were
> not really ambiguous, which is (as usual for Uncle G) quite correct.

Hrm, I did something similar to [[Ellison]] when I went looking for
Harlan Ellison, the author. I think I sorted them by the order I got
hits for them though (I was too lazy to use Special:Allpages and I
either didn't know abot Special:Prefixindex or it hadn't been written at
the time); they've now been sorted alphabetically.

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

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


from_name: Matt Brown

subject:
[WikiEN-l] Article help: Canon Ixus/PowerShot Elph/Ixy users
	needed

body:
I've worked on a good deal of camera articles - mostly older film
cameras, though - and have had fairly good luck finding images on
online photo sites like Flickr.  A lot of people post pictures of
their own cameras, and I have a pretty good hit rate at persuading
them to allow Creative Commons CC-BY-SA licensing of them.

Another possibility is ebay auction listings - find someone selling
such a camera and ask permission to use their pics.

-Matt


from_name: David Gerard

subject: [WikiEN-l] Article help: Canon Ixus/PowerShot Elph/Ixy users needed

body:
I realise this email is about actual article content, not userboxes,
abusive admins or similar. But anyway ...

    http://en.wikipedia.org/wiki/Canon_Digital_IXUS

I need pics of more models of camera. I've been taking shots as I
encounter them, but there's a lot of gaps (these things ain't cheap).
Also, the Ixus i photo is a Canon promo, and needs replacement with a
free image. I asked on the dpreview.com photo boards, but they all
seem to be shy ...

In particular, it'd be nice to have pics of the US (PowerShot Elph)
and Japanese (Ixy) models - all the current pics are European (Ixus)
models.

The Commons cat for these is [[Category:Canon Digital IXUS]] and the
Commons article is [[Canon Digital IXUS]].

For those of you on de:, the article there is
http://de.wikipedia.org/wiki/Canon_Ixus - I took the table format and
contents for the en: article from there, and an enthusiast to keep the
two in sync would be good.

- d.


body:
A quick Advanced Search on flickr found a fair number of results for
"powershot elph" and "ixy camera" that were actual pictures of the
cameras, btw.

-Matt


from_name: Gregory Maxwell

body:
On 4/14/06, Erik Moeller <eloquence at gmail.com> wrote:
> On 4/13/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > AFAIR, most string matches in mysql are case insensitive, which would
> > mean that we could have indexed case insensitive matches quickly...
> > but I'm guessing that our use of binary fields for titles (which is
> > required because no version of mysql has complete UTF-8 support) most
> > likely breaks that.
>
> Yes, they are, and yes, it does. Could someone explain what the exact
> reason is that we're using varchar binary in MediaWiki for page
> titles? I've been using regular varchars for my WiktionaryZ tables,
> and so far it seems to work fine with UTF-8. Where exactly does a
> non-binary varchar break?
[snip]
> Might it make sense to use non-binary strings and use binary
> comparisons instead where case-sensitivity is required?

It is my understanding that MySQL doesn't correctly handle UTF-8 where
the characters are outside of the basic multilingual plane (BMP).
These are the characters which can not be represented by UCS-16 (i.e.
more then two bytes in the UTF-16 representation) and this includes a
number of characters which are required for complete support of some
asian languages.

I'm not sure how it fails (does it munge, or warn, .. since it's mysql
I'm sure it doesn't reject bad data...), since I haven't tried it
personally but thats where I understood the current issue was.

PostgreSQL had simmlar issues with non-bmp characters until version 8
(prior to version 8, PG would reject inserts with most non-bmp
characters as invalid).

There are other issues as well.. for example, last I checked on enwiki
there were some titles  (and page/image links) which contained
completely invalid characters... (back from when enwiki was latin1 and
more permissive about binary input not so long ago).  I see that a
number of bad pages have been moved to broken/whatever .. so perhaps
thats been cleaned up.   ...  a switch to utf-8 might potentially run
into problems with this pages, depending on how strict mysqls input
validation is (historically not strict at all... but...), I know it's
always caused me troubles importing into postgresql (because in PG I
don't use binary fields for mediawiki imported data, and PG's input
validation is fairly strict).


from_name: Birgitte SB

body:
>
> Nod. I understand what you say.
> Unfortunately, absolutely *any* editor may be
> attacked anytime and have
> his/her reputation attacked. If you doubt that,
> check out the recent
> emails between David Gerard, Aurevilly and myself
> :-(
>
> Now, I must also say that it is quite unconfortable
> to do checkuser on a
> project you absolutely do not know and in a language
> you do not know either.
>

. . .

> Requests may be done by *good* editors and by *bad*
> editors. Stewards
> have no way to know. I am not sure it is good.
>
> ant (who heard you were a good person :-))

I realize there is fine line here.  And I am confident
that no one will take the accusations against me
seriously.  However I was very cautious about things,
thinking of how everything would look once all the
evidence was deleted.  All history of any
contributions made by the editor at Wikisource have of
course disappeared.  And especially as the person was
nuked on another project which destroyed most of the
history there, which I could have used to back up my
actions.  I kept records of what I could and trusted
that people would speak up for me if it came that (as
Brad has done).

However, in general the people who are trusted from a
Foundation perspective take little interest in the
running of the smaller projects.  At the same time,
those that keep these projects running smoothly are
told they are not trusted enough to have the tools
they need.  And then people with access, such as
yourself, feel uncomfortable even using the tools to
pass info on.  And I understand why you feel that way
of course.  Because I feel uncomfortable blocking
someone indefinitely without being 100% sure he was
the same person who had caused problems before.  It is
not just that I worry about what others may accuse me
of, but I take the responsibility seriously.  In the
end it is my action, whoever else advised me on it.
But am convinced the risk of legal exposure is a great
enough problem that I can overcome the discomfort.

This is really a larger and mor far reaching problem.
No one at Wikisource subscribed to this list until
someone told us that it had been decided here that our
copyright policy was not restrictive enough.  That is
when a few of the regular editors signed up.  I
imagine there are a great number of active projects
out there running their own little worlds, divested
from the Foundation in all but name.  I believe there
are other problems we haven't yet imagined already out
there.  Things need to be handled differently.
Perhaps new projects are approved to easily.  It might
be a good idea to assign official liaisons.  Or maybe
there should be a mentorship program for bureaucrats.
Perhaps the Foundation should randomly run a detailed
assesment of the smaller but active projects.  Or
maybe there should be a recruitment of the people who
run these projects to become more active within the
Foundation.  I do not know the answer, but I can see
symptoms that this is a larger problem than stewards
ignoring requests for Checkuser.

I will say this, projects like Wikisource are very
different from Wikipedia.  They are also very
different from Wikipedia was when it as small as
Wikisource is now.  What worked then and now for WP
will not work for Wikisource or Wikibooks.  I can see
this just from that expectations there are of how X
voters should be gotten from X active editors.  When
people were active at Wikipedia years ago, they joined
the community.  Now these editors are either fed up
with community from WP experiences, or else they
devote all their "community" time to WP, but they
still come edit regularly on places like Wikisource.
I see many names I recognize from WP community
discussions in the Recent Changes at Wikisource.  But
they never join in on any WS general disscussions.  I
am not saying this is either good or bad; it is just
makes a different animal entirely.  Also as Robert
Horning said, we attract vandals of a sophisticaton WP
never even imagined when there were only 12
administrators.  I feel that if projects like
Wikisource and Wikibooks are continually regarded by
the Foundation the way they are now, they will become
like difficult step-childrem.  I do not believe anyone
wants that to happen.  I certainly don't and that is
why I encouraging for something to change.  There must
be more intergration and trust on all levels.  And I
mean trust that our work will be supported as well as
trust that we act responsibly in the running our
projects.

Although this is old news, I will say this also
because it regards trust running the other way.  It
was very hard on us to have to delete all the UN
resolutions and Crown legislation.  We truly believed
(trusted) our copyright policy was supported.  And
even now we have never gotten a straight answer on the
thinking behind the copyrights.  Any disscussion I
read about it, leaves me newly aware of the lack of
understanding people have about the basics of
Wikisource.  Or else I get the impression that
everyone from the Foundation is being intentionally
vague.  So we are being very cautious, and I worry
every day someone will come down and say we have get
rid of X also. And that is the worst part of being and
admin, when the rules suddenly change on you and you
are left to enforce them on very unhappy people.  And
on top of it all I do not understand why they changed
or even if my current interpration of the rules is
correct.  Things like this can only happen so many
times before everyone becomes too gun-shy to keep
contributing, or else decides to just ignore the rules
they feel are arbitrary.  Either of those would be a
bad thing.  Sorry this was so long.

Birgitte SB

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


from_name: Tim Starling

subject: [Wikitech-l] ParserFunctions trial

body:
William Allen Simpson wrote:
> Conrad Dunkerson wrote:
>
>>* Tim Starling wrote:
>>
>>>The extension for mathematical expressions and conditional constructs has been enabled on all
>>>Wikimedia wikis, on a trial basis. Documentation is at:
>>>
>>>http://meta.wikimedia.org/wiki/ParserFunctions
>>>
>>>See the talk page for discussion.
>>
>>Great!
>>Wonderful job Tim! This is wonderful and will vastly simplify tons of things.
>>
>
> When Tim says "trial", how is the testing coordinated?  Shouldn't it be
> tried on a few not too prominent places, rather than fix every qif now?
>
> Where should I be looking for posts coordinating this?

The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to
enable it permanently. The critics of this concept now have one final chance to turn community
opinion against it, before it becomes ingrained. However the reception has generally been positive.
I've received a number of private compliments on it, in addition to what can be seen publically.

There's also the possibility of bugs and syntax changes. We've already had one syntax change: I
changed the whitespace handling in #if to mirror the behaviour in template parameters, to allow for
easier conversion and neater multi-line syntax. There's also a pending suggestion to allow
whitespace between the #if and the colon, and a suggestion to make #if treat "0" as true, both of
which may well be implemented.

One of Gangleri's syntax suggestions sounded quite reasonable and I may well implement it. The idea
if I understand it correctly was to treat pipe characters beyond the specified maximum number of
arguments literally, e.g. {{#if: 1 || literal pipe: | }}.

-- Tim Starling


subject: [Foundation-l] Google Summer of Code

body:
Google's doing their Summer of Code program again this year. We missed last
years', but I'm going to try signing us up as a mentoring organization this year.

Feel free to put any relevant-sounding project ideas here:
http://meta.wikimedia.org/wiki/Summer_of_Code_2006

Mozilla's experience last year wasn't so good[1]; some of their projects didn't
complete, and most of them haven't been touched since the end of the summer.
Mono however had a much more positive experience[2], with most of their projects
completing and being further developed and adopted after the end.

So I think it will be important to try to engage the folks working on our
projects if we want to keep them. :)

[1]
http://weblogs.mozillazine.org/gerv/archives/2006/03/summer_of_code_six_months_on.html

[2] http://tirania.org/blog/archive/2006/Apr-13.html

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060414/cf759efd/attachment.pgp


subject: [Foundation-l] Google Summer of Code

body:
Google's doing their Summer of Code program again this year. We missed last
years', but I'm going to try signing us up as a mentoring organization this year.

Feel free to put any relevant-sounding project ideas here:
http://meta.wikimedia.org/wiki/Summer_of_Code_2006

Mozilla's experience last year wasn't so good[1]; some of their projects didn't
complete, and most of them haven't been touched since the end of the summer.
Mono however had a much more positive experience[2], with most of their projects
completing and being further developed and adopted after the end.

So I think it will be important to try to engage the folks working on our
projects if we want to keep them. :)

[1]
http://weblogs.mozillazine.org/gerv/archives/2006/03/summer_of_code_six_months_on.html

[2] http://tirania.org/blog/archive/2006/Apr-13.html

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060414/cf759efd/attachment-0001.pgp


subject: [Foundation-l] Google Summer of Code

body:
Google's doing their Summer of Code program again this year. We missed last
years', but I'm going to try signing us up as a mentoring organization this year.

Feel free to put any relevant-sounding project ideas here:
http://meta.wikimedia.org/wiki/Summer_of_Code_2006

Mozilla's experience last year wasn't so good[1]; some of their projects didn't
complete, and most of them haven't been touched since the end of the summer.
Mono however had a much more positive experience[2], with most of their projects
completing and being further developed and adopted after the end.

So I think it will be important to try to engage the folks working on our
projects if we want to keep them. :)

[1]
http://weblogs.mozillazine.org/gerv/archives/2006/03/summer_of_code_six_months_on.html

[2] http://tirania.org/blog/archive/2006/Apr-13.html

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060414/cf759efd/attachment.pgp>


subject: [Foundation-l] Google Summer of Code

body:
Google's doing their Summer of Code program again this year. We missed last
years', but I'm going to try signing us up as a mentoring organization this year.

Feel free to put any relevant-sounding project ideas here:
http://meta.wikimedia.org/wiki/Summer_of_Code_2006

Mozilla's experience last year wasn't so good[1]; some of their projects didn't
complete, and most of them haven't been touched since the end of the summer.
Mono however had a much more positive experience[2], with most of their projects
completing and being further developed and adopted after the end.

So I think it will be important to try to engage the folks working on our
projects if we want to keep them. :)

[1]
http://weblogs.mozillazine.org/gerv/archives/2006/03/summer_of_code_six_months_on.html

[2] http://tirania.org/blog/archive/2006/Apr-13.html

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060414/cf759efd/attachment-0001.pgp>


subject: [Wikitech-l] Google Summer of Code

body:
Google's doing their Summer of Code program again this year. We missed last
years', but I'm going to try signing us up as a mentoring organization this year.

Feel free to put any relevant-sounding project ideas here:
http://meta.wikimedia.org/wiki/Summer_of_Code_2006

Mozilla's experience last year wasn't so good[1]; some of their projects didn't
complete, and most of them haven't been touched since the end of the summer.
Mono however had a much more positive experience[2], with most of their projects
completing and being further developed and adopted after the end.

So I think it will be important to try to engage the folks working on our
projects if we want to keep them. :)

[1]
http://weblogs.mozillazine.org/gerv/archives/2006/03/summer_of_code_six_months_on.html

[2] http://tirania.org/blog/archive/2006/Apr-13.html

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060414/cf759efd/attachment.pgp>


list: wikipedia-l

from_name: lapin

subject: [Wikipedia-l] Europanto

body:
Hi "dear" Mark,
"U" talk, but you don't  listen, it seems so.
How many languages do you speak ? => ?????
I suppose you have a cell phone, ... sms and so ? xdr ...
Sms language is ... er ... "smarter"  than Europanto will never be, no ?
Worse than ... slang ?
In the end I wonder :  r u a  "vieux r?ac'" ?

... Regards,

Lapin

--
View this message in context: http://www.nabble.com/Europanto-t1056989.html#a3923572
Sent from the Wikipedia General forum at Nabble.com.


from_name: Locke Cole

subject: [Wikitech-l] ParserFunctions trial

body:
On 4/14/06, William Allen Simpson <william.allen.simpson at gmail.com> wrote:

> Please don't implement either of these.
>
> It doesn't make sense to have whitespace between the # and the if, and no
> demonstrable reason to have it before the colon.

For formatting, to make it easier to read.

> The logic of qif was often confusing.  There's only very short term
> advantage to backward compatibility.  Having #eval and #if work like
> other languages will be easiest to document in the long term.  Remember,
> features aren't of much use without easy to understand documentation.

Having #if test for blank/non-blank makes more sense. #ifexpr now
wraps what would have previously been a call to #if *and* #expr into a
single call. If you still need to test against 0 or 1, you can use
#ifeq.

> Actually, the trailing pipe doesn't sound reasonable to me, as it only works
> with "else" parameters, requiring logic to be inverted.  There's a couple of
> fairly simple alternatives (standard html syntax, or the {{!}} template), and
> they work in a consistent, predictable, symmetric manner.  Again, ease of
> documentation.

Agreed, this is a bad idea IMO. There's a better idea on Meta at
[[Talk:ParserFunctions]] to allow "wikisyntax" between {{#: <syntax>
}} (I think it's mentioned here on the mailing list too), and this
seems like a very good idea IMO. It would allow full wiki-table markup
to be included inside conditionals (so those annoyed by XHTML could
stick with what they know/like, in theory).

-L


from_name: Guettarda

subject: [WikiEN-l] Archives as sources proposal

body:
Taken at face value, I think that the simple answer to both Oskar and Sean's
questions is yes, thes are OR.

In the case of Oskar's first question, when you read a book to write a
summary, or view a film to write a summary, it constitutes OR.  I suppose
ideally what you should be doing in consulting book or film reviews, and
using them to construct your own.  Why is it a problem?  For the most part,
it probably isn't.  Nonetheless, if you are doing more than relating the
simple facts of the movie, it becomes a creative endeavour, and that isn't a
good thing.

In the case of the number of wives of a famous person or the birth date of
Nancy Reagan, if one of us can find the birth or marriage certificates, then
hopefully so should their biographers.  In the case of Nancy Reagan or
Jennifer Lopez, it amounts to a WP:V issue - and their press agent isn't a
reliable source.

In the case of a discrepancy between what you can find for yourself and what
the article says - I suppose the place to start is with {{fact}} or
something stronger.  Obviously, if you have found the marriage certificate,
why haven't other people?  Or is it that they just aren't famous enough to
have a real biographer?  I'd say it is problematic.  Personally I wouldn't
think twice about trusting Sean's veracity - but the truth is, we don't have
"trusted editors" and in theory, what stands for Sean should stand for any
anon.

I wouldn't have a huge problem with the examples cited, but any alteration
of policy would have to be extremely tightly worded.

Ian


from_name: Fred Bauder

subject: [WikiEN-l] Socialist POV

body:
On the contrary, the [[Socialist International]], which speaks for
mainstream socialism, does oppose racism.

Fred

On Apr 14, 2006, at 1:49 PM, Sam Spade wrote:

> Trying to add
> a view that National Socialism was, er, the only real socialism
> ever implemented seemed rather foolish, and out of place there.
>
> The article needs more references, but I can see it is hard to
> do this in the overview (havent yet had time to read all the
> subarticles).
>
> Justinc
>
> Thats a pretty uninsightful interpretation of what was going on.
> Editors have been trying to insert that claim that socialism opposes
> racism:
>
> "Socialism rejects the [[racist]] theories and [[totalitarianism]] of
> the Nazis, while Nazism rejected the policies of [[internationalism]],
> [[egalitarianism]], [[class struggle]], and common ownership of the
> [[means of production]] pursued by many socialists.<ref>[[Leon
> Trotsky|Trotsky]], Leon.
> ''[http://www.marxists.org/archive/trotsky/works/1930-ger/330610.htm
> What is National Socialism?]'' June 10 1933</ref>"
>
> http://en.wikipedia.org/w/index.php?
> title=Socialism&diff=46506992&oldid=46506617
>
> That is a highly misleading "citation" there. Trotsky doesn't define
> Socialism any more than Hitler, Mao or Marx does. They all are persons
> who claimed to be socialists, with wildly divergent views. There is no
> consensus amongst socialists on these issues, and it is false to claim
> their is one.
>
> SS
>
>
>
> On 4/14/06, Justin Cormack <justin at specialbusservice.com> wrote:
>
>>
>> On 13 Apr 2006, at 23:25, Fred Bauder wrote:
>>
>>
>>> Yes, and when I got to looking at it, some of it was still the old
>>> National Socialism is socialism stuff.
>>>
>>
>> Yes that seemed to be the main issue when I looked.
>>
>> I looked over the Socialism article and it didnt seem too bad,
>> especially as it is an overview article that mainly is referencing
>> other articles, always a hard thing to write well. Trying to add
>> a view that National Socialism was, er, the only real socialism
>> ever implemented seemed rather foolish, and out of place there.
>>
>> The article needs more references, but I can see it is hard to
>> do this in the overview (havent yet had time to read all the
>> subarticles).
>>
>> Justinc
>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> To unsubscribe from this mailing list, visit:
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>>
>>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Anthere

body:
Angela wrote:
>>Why has no steward responded to these and many other requests for information
>>made in February, March, and April 2006?
>
>
> Only three stewards (Anthere, Datrio, and Oscar) have CheckUser
> access. I don't know if the backlog is because the policy is unclear
> on when requests can be fulfilled, or whether there just aren't enough
> people willing to carry out these requests.
>
> Angela.

I do not usually answer to requests on that page, but only when they are
specifically asked to me. Several reasons : first, I consider I do not
have a technical enough knowledge to help best. Second, I already have
too much to do :-) So, I only help when people email me or ask me on irc.

Ant


body:
Robert Scott Horning wrote:
> Essjay wrote:
>
>
>>Perhaps this would be an appropriate time to say "Maybe we could use a
>>couple more stewards?"
>>
>>Essjay
>>
>>
>
> Or perhaps the minimum requirement for the number of votes for users to
> get checkuser status on smaller projects like en.wikibooks is
> unreasonable?  We have had a couple of candidates for checkuser status
> for almost two months now, and we simply can't get the number of votes
> necessary because of the size of our active user base.

The requirements are 25 votes roughly. Has en.wikibooks lesser than 25
active editors ? I would have thought it had more editors...

If there are more than 25 active editors, they may not know about the
checkuser job, they may not know they could nominate their own
checkuser, they may not know the interest for your project ?

----> advertise the job !

  Yet we are the
> target of repeated vandalism, and even sockpuppet voting from die-hard
> sock puppets.  If the concern is that checkuser privileges are going to
> be abused, it is a smaller user base that can be abused.

> Should projects be allowed to set their own standards for people with
> this status, or is it something that is imutable and only set by the
> Foundation board?  So far, only Wikipedias are seemingly allowed to have
> somebody with checkuser status at all.  And if stewards are overwhelmed
> with this task of dealing with checkuser scans, perhaps the policy needs
> to be reviewed.

Rahhhh, do not go again on that rant : wikipedia get it all and we have
nothing :-)

A policy can always be reviewed. But I sweated enough for that policy so
that I feel not very motivated to go through this pain one more time :-)

The reason for the 25 votes limit comes from two reasons
* A community with less than 25 users is unlikely to really need
frequent checkusers, because it is a project with reduced activity. So,
it can not be a heavy load for stewards.
* A community with less than 25 users has a rather serious risk to have
a rather little known editor become a checkuser, rather than a trusted
oldbie. If we start handing out status just as we do for sysop status on
small projects, I think there will be abuse. I say this from my
experience, as I had to unsysop several sysops on small projects (the
guys did not know our basic rules, behaved like dictators with the
handful of editors, put advertisements on the main page, controlled povs
etc...).

I am perplex that the en.wikibooks does not have a big enough base of
editors to vote on a check user...
I am quite lazy, so I will not go to the stats page to check. But can
you roughly say how many active editors per month the project currently
has ? How many very active editors per month ?

ant


from_name: Reinhardt WIEWE @ torg.is

subject: [Wikitech-l] templates and RTL issues

body:
On Fri, 14 Apr 2006 16:01:48 +0300
 Ilmari Karonen <nospam at vyznev.net> wrote:
> William Allen Simpson wrote:
> >

> In fact, I just tested it by adding:
>
> FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
>
> to my monobook.css on yi.wiktionary and it seems to work.  Gangleri, can
> you try this and say if it helps any?
>
> --
> Ilmari Karonen

Thanks Ilmari for the suggestion.

Niklas and Rob suggested
http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&action=edit
form#editform textarea#wpTextbox1 { direction: ltr }
form#editform input#wpSummary { direction: ltr }

This is just a part of the interface. It does not cover search, move, delete,
undelete, block etc. fields

Editing RTL in MediaWiki is a mather of practice. As requested in

Allow users to change text direction in all text input and textarea boxes
http://bugzilla.wikimedia.org/show_bug.cgi?id=4011

the change from LTR to RTL editing and viceversa should be as easy as possible.
I would realy be happy to have a choice in 'special:Preferences'.

Anonymous editors would not have this posibility. If they accept cookies one
could offer two radio buttons for a 'LTR' or 'RTL' choice.

reinhardt [[user:gangleri]]


from_name: Ilmari Karonen

subject:
[WikiEN-l] Article help: Canon Ixus/PowerShot Elph/Ixy users
 needed

body:
David Gerard wrote:
> I realise this email is about actual article content, not userboxes,
> abusive admins or similar. But anyway ...
>
>     http://en.wikipedia.org/wiki/Canon_Digital_IXUS
>
> I need pics of more models of camera. I've been taking shots as I
> encounter them, but there's a lot of gaps (these things ain't cheap).
> Also, the Ixus i photo is a Canon promo, and needs replacement with a
> free image. I asked on the dpreview.com photo boards, but they all
> seem to be shy ...

That shouldn't be too hard -- I'll try to snap a few photos next time
I'm in a camera shop.  I can't help with the non-EU models, though.

--
Ilmari Karonen


subject: [Wikitech-l] templates and RTL issues

body:
William Allen Simpson wrote:
>
> (2) Display and edit as RTL.  In practice, this turned out to be fairly
> simple by thinking about such things as opening and closing parentheses,
> rather than left and right.  They simply are reversed on display.

The major difficulty, based on what I've seen, seem to be parentheses
and other punctuation in mixed LTR/RTL text.  The browsers try to guess
which way these should be displayed, but they're not very good at it.

This isn't much of a problem in the displayed content, since there we
can use  tags to explictly set the directionality, but in the edit
box.  Ironically, HTML tags themselves are a problem when embedded in
RTL text, since they themselves consist of LTR text surrounded by paired
delimiters.  For example, if the source of a page contained, in storage
order, the string "HEBREW", where the capitals stand for
Hebrew letters, it may render in the edit box as "WEspan>/>RBspan>>EH".
  Not very easy to edit, is it?

As a practical suggestion, it might be a good idea to set the CSS
property "unicode-bidi: bidi-override;" for the edit box.  That should,
in browsers that understand it, force all the text in the edit box to
render in the same direction.  That way, on a RTL wiki, the example
string above would render as "WE<naps/>RB<naps>EH", which at least is
less confusing than the current rendering.

In fact, I just tested it by adding:

FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }

to my monobook.css on yi.wiktionary and it seems to work.  Gangleri, can
you try this and say if it helps any?

--
Ilmari Karonen


subject: [WikiEN-l] Socialist POV

body:
Yes, I mean democratic socialism or social democracy, not
totalitarian movements which adopt some socialist elements or label
themselves socialist while butchering millions. Of course they don't
label themselves totalitarian.

Fred

On Apr 14, 2006, at 4:05 PM, Sam Spade wrote:

> What is mainstream socialism? Do you mean Democratic socialism? Or
> social democracy? Why is that "mainstream"?
>
> Something like "The socialist international opposes racism" would be
> fine, I can't imagine who would object to that.
>
> My point is that plenty of socialists were racist, and that nazi's are
> not ruled out from being socialist for racism or opposition to
> democracy for that matter. Socialism is known for its centrally
> planned command economy, according to my economics textbook. That is a
> criteria which all socialists fall under (to my knowledge). It is also
> material, rather than rhetorical in nature.
>
> SS
>
> On 4/14/06, Fred Bauder <fredbaud at ctelco.net> wrote:
>
>> On the contrary, the [[Socialist International]], which speaks for
>> mainstream socialism, does oppose racism.
>>
>> Fred
>>
>> On Apr 14, 2006, at 1:49 PM, Sam Spade wrote:
>>
>>
>>> Trying to add
>>> a view that National Socialism was, er, the only real socialism
>>> ever implemented seemed rather foolish, and out of place there.
>>>
>>> The article needs more references, but I can see it is hard to
>>> do this in the overview (havent yet had time to read all the
>>> subarticles).
>>>
>>> Justinc
>>>
>>> Thats a pretty uninsightful interpretation of what was going on.
>>> Editors have been trying to insert that claim that socialism opposes
>>> racism:
>>>
>>> "Socialism rejects the [[racist]] theories and
>>> [[totalitarianism]] of
>>> the Nazis, while Nazism rejected the policies of
>>> [[internationalism]],
>>> [[egalitarianism]], [[class struggle]], and common ownership of the
>>> [[means of production]] pursued by many socialists.<ref>[[Leon
>>> Trotsky|Trotsky]], Leon.
>>> ''[http://www.marxists.org/archive/trotsky/works/1930-ger/330610.htm
>>> What is National Socialism?]'' June 10 1933</ref>"
>>>
>>> http://en.wikipedia.org/w/index.php?
>>> title=Socialism&diff=46506992&oldid=46506617
>>>
>>> That is a highly misleading "citation" there. Trotsky doesn't define
>>> Socialism any more than Hitler, Mao or Marx does. They all are
>>> persons
>>> who claimed to be socialists, with wildly divergent views. There
>>> is no
>>> consensus amongst socialists on these issues, and it is false to
>>> claim
>>> their is one.
>>>
>>> SS
>>>
>>>
>>>
>>> On 4/14/06, Justin Cormack <justin at specialbusservice.com> wrote:
>>>
>>>
>>>>
>>>> On 13 Apr 2006, at 23:25, Fred Bauder wrote:
>>>>
>>>>
>>>>
>>>>> Yes, and when I got to looking at it, some of it was still the old
>>>>> National Socialism is socialism stuff.
>>>>>
>>>>>
>>>>
>>>> Yes that seemed to be the main issue when I looked.
>>>>
>>>> I looked over the Socialism article and it didnt seem too bad,
>>>> especially as it is an overview article that mainly is referencing
>>>> other articles, always a hard thing to write well. Trying to add
>>>> a view that National Socialism was, er, the only real socialism
>>>> ever implemented seemed rather foolish, and out of place there.
>>>>
>>>> The article needs more references, but I can see it is hard to
>>>> do this in the overview (havent yet had time to read all the
>>>> subarticles).
>>>>
>>>> Justinc
>>>>
>>>> _______________________________________________
>>>> WikiEN-l mailing list
>>>> WikiEN-l at Wikipedia.org
>>>> To unsubscribe from this mailing list, visit:
>>>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> WikiEN-l mailing list
>>> WikiEN-l at Wikipedia.org
>>> To unsubscribe from this mailing list, visit:
>>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>>>
>>>
>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> To unsubscribe from this mailing list, visit:
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>>
>>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
On 4/14/06, Brion Vibber <brion at pobox.com> wrote:
[snip]
> It could break string matching, but would definitely break sorting. (Sorting by
> codepoint may suck, but at least it's predictable.)
>
> More generally, deliberately choosing a non-binary collation which applies to a
> *different character set* from the one really you're using seems pretty silly.
> You get unpredictable, incorrect sorting and potentially have strings rejected
> as invalid.

The collation problem is a hard problem in general, as I understand
it, as there are some cases where the collation of some unicode
characters changes depending on the language.. For example, the
position of ? in danish vs most other languages.  ... although doing
it wrong but mostly right isn't too hard.

Thus supporting multiple languages correctly in a single database
becomes a little difficult. I don't think it's reasonable to expect
the database to allow you to magically specify a new collation on the
fly for each query, since index order depends on collation.

Instead, given sufficient support in the database, you could create a
function  enumerate_collation(language,string) which returns an
integer array (or a mangled string), with one value for the absolute
collation position of each character in the string.  You could then
define index on that function applied to the title column for each of
the collations you will be using, and ORDER BY
enumerate_collation('en',title) in your queries.


subject: [Wikitech-l] ParserFunctions trial

body:
On 4/14/06, William Allen Simpson <william.allen.simpson at gmail.com> wrote:

> I've never found adding a space before the colon at the end of a sentence
> fragment to be easier to read, either.

It's not just literal spaces, but *any* whitespace (carriage returns,
tabs, etc). So you could do, for example:

{{#if
  :<string>
  |<then result>
  |<else result>
}}

Note also that the result strings are also trimmed of whitespace, so
the CR/LF are ignored.

> So, it should be called "#ifdef:" to match ingrained expectations.  Could
> "#if:" be quickly retired?

#if is shorter which is probably why it'll be kept as-is.

> Also, "#ifexpr:" just showed up in the documentation today, so you'll
> forgive me for not knowing about it.  And wouldn't we just use
>     "#ifexpr: X = 0" otherwise?

I proposed it on the talk page a little while ago (which is where most
discussion is going on right now). Yes, you could use #ifexpr as you
describe I suppose. =) I was mostly thinking of situations where a
template would return 1 or 0 for true or false (see
[[en:Template:IsLeapYear]]).

> "#ifeq:" is for matching strings, not against "0".  See what I mean
> about ingrained expectations?

Everything is a string. You could use #ifeq or #ifexpr (though I
suspect #ifeq would be faster as far as CPU resources are concerned).

-L


from_name: Rotem Liss

subject: [Wikitech-l] (no subject)

body:
Please go to http://mail.wikipedia.org/mailman/options/wikitech-l, log
in, and click "Unsubscribe".

Seiduluqman at aol.com wrote:

>please cancel Email to my mail box
>thank you
>s luqman
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>


subject: [Wikitech-l] templates and RTL issues

body:
On Fri, 14 Apr 2006 11:53:17 -0400
 William Allen Simpson <william.allen.simpson at gmail.com> wrote:
> Reinhardt WIEWE @ torg.is wrote:
> >> In fact, I just tested it by adding:
> >>
> >> FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
> >>
> >> to my monobook.css on yi.wiktionary and it seems to work.  Gangleri, can
> >> you try this and say if it helps any?
> >>
> >> --
> >> Ilmari Karonen
> >
> > Thanks Ilmari for the suggestion.
> >
> It wasn't a suggestion, it was a question.  Please say whether it helps?

I would not use 'bidi-override' for my personal work. Remember it is a matter
of preferences and available options. I made aprox. 10,000 RTL edits in the
normal textarea box and get used to it. The main question is if it would help
*other* contributors. This depends on the available options and some might like
'bidi-override'.

If people are using a RTL browser, a RTL OS (or a RTL keyboard) if they have an
RTL editor of their choice they would have completly different preferences.
Please remember that MediaWiki supports the usage of an external editor via
special:Preferences > Editing > Use external editor by default .
I neither have used an external editor for LTR edits nor have I investigated
about experiences with an external editor with good RTL / BiDi support.
I will let you know as soon as I get additional informations.

> > Niklas and Rob suggested
> >
>
http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&action=edit
> > form#editform textarea#wpTextbox1 { direction: ltr }
> > form#editform input#wpSummary { direction: ltr }
> >
> But that just makes everything ltr.  Not what was under discussion here.

"Making everithing ltr" is the default setting for http://ar.wikipedia.org/ and
http://he.wikipedia.org/ for logged in users. Anonymuous users would still have
an RTL textarea. I mentioned this in a previous post. It is an option; my
opinion about this: as more option you have the more flexible the system will
be.

> > This is just a part of the interface. It does not cover search, move,
> delete,
> > undelete, block etc. fields
> >
> > Editing RTL in MediaWiki is a mather of practice. As requested in
> >
> > Allow users to change text direction in all text input and textarea boxes
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
> >
> > the change from LTR to RTL editing and viceversa should be as easy as
> possible.
> > I would realy be happy to have a choice in 'special:Preferences'.
> >
> > Anonymous editors would not have this posibility. If they accept cookies
> one
> > could offer two radio buttons for a 'LTR' or 'RTL' choice.
> >
> But not possible to be addressed until folks know the technical solution.
> Stay focused.  Does bidi-override help with template edits?

The fair answer is: It is the *last choice*. If I need to debug a template or
page I copy the content and past it to http://pastebin.com/ . This is
equivalent to 'bidi-override' when direction is 'ltr'. pastebin.com offers the
additional advantage that I am able to identify (unwanted) general punctuation
characters which have found their way into the code by eroneous copy and paste.
Why 'bidi-override' when direction is 'rtl' should not be a good solution for
someone comming from / native in the RTL world?

Please note that RTL and mainly BiDi source code *editing* is very complex,
that the bidirectional algorithm works on / resets on entities as paragraphs,
table cells etc. And please do not forget that the nesting levels are limited.

What the textarea box editing is is mainly writing an email in Outlook /
Outlook express in *source code*. Nobody would do that. And things are changing
slowly so it is very important to know the texarea editing capabilities of the
browsers (and Firefox is a very common browser).

As more lines you have in the textarea as less bidirectional "mess" you get.
You would still need to get used to the bidirectional algorithm but the effects
are limited to *one* line only. This is where the suggestion of splitting the
template (and page) code over many lines comes from.

reinhardt [[user:gangleri]]


subject: [Wikitech-l] templates and RTL issues

body:
Reinhardt WIEWE @ torg.is wrote:
> On Fri, 14 Apr 2006 11:53:17 -0400
>  William Allen Simpson <william.allen.simpson at gmail.com> wrote:
>> Reinhardt WIEWE @ torg.is wrote:
>>>> In fact, I just tested it by adding:
>>>>
>>>> FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
>>>>
[snip]
>>>
>> It wasn't a suggestion, it was a question.  Please say whether it helps?

As a testing hack I've set up control buttons on one of our test wikis to change
the CSS 'direction' and 'unicode-bidi' values at edit time.

Here's a copy of the Hebrew Wikipedia main page source; since the test wiki is
LTR it shows LTR by default, but you can switch the edit box around with the
buttons:
http://test.leuksman.com/edit/New_page

(Briefly tested in Firefox 1.5.0.2 and Safari 2.0.3.)

It's pretty ugly, but being able to switch in the unidirectional mode at will
might be helpful.

The JS:
http://test.leuksman.com/extensions/BidiSwitch/switch.js

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060414/4df4f6fb/attachment.pgp>


from_name: Fastfission

subject: [WikiEN-l] Archives as sources proposal

body:
On 4/14/06, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
>
> Honestly, the verifiability argument doesn't fly at all with me. If
> you pick information out of an archive, it's most certainly
> verifiable, someone else can check it out as well. I realise that that
> is a hassle, but that doesn't change the fact that it is verfiable.

"Verfiable" of course does not mean "absolutely verfiable" (in which all
facts would at some level be), but clearly something on a spectrum from
"anyone can see it by clicking a link" to "it's an old book but there are
copies of it in at least a few major repositories where a large number of
Wikipedians are located." In the last category, it is worth noting that a
significant number of Wikipedians are students at universities with
extensive library services, including interlibrary loan, and it would not be
very hard to verify 90% of all very-old book references. It would be a rare
source indeed that somebody in the University of California system or in the
Ivy Leagues would not be able to verify within a few days, to speak nothing
of all of the other universities in the world with fine and extensive
library services.

If something is archival and unpublished though, it generally means that it
is in one single archive. That archive may have no interarchival lending
options. There may be no interested Wikipedians with access to that archive.
There are no doubt a few exceptions, but so rare would they be, and
certainly not worth changing a very good policy, one which sits as a chief
cornerstone to our epistemological approach, in order to satisfy. All of the
proposed benefits (a few birth/death dates? information about obscure and
probably non-notable institutions?) seem a paltry thing in comparison with
the fact that removing "verfiabiilty" would create an endless mess of
difficulty with POV-pushers.

How about, as a compromise, if someone would like to include a source
> from an archive, they are required to submit a copy of the document,
> so everyone can see it for themselves.

If they can host it semi-permanently somewhere (a scan at Commons, for
example), then it is, so far as I can reason, "published" and verfiability
is no longer an issue (NOR might still be, but that's a different can of
worms). If they cannot put it somewhere where editors of the future can see
it then no, it is still unpublished and unverifiable except to the small
group of editors who happened to see it at one point in time.

The fact is, it's really hard to define research in this context. How
> is looking up someones birth certificate in an archive worse than
> looking it up on the internet?Technically, they're both research.
> Honestly, I'd prefer it if the info got directly from the source. Same
> thing with things such as trial transcripts, if we quote someone from
> a trial, I'd prefer it if we knew excactly, word by word, what they
> were saying instead of trusting a third party.

NOR would not prohibit people quoting from trial transcripts or other
primary source material, so long as it was not being used in a way which is
"unique." I could quote all I wanted from the Oppenheimer trial but if I
quoted out of context in order to prove he was a space alien, that would be
NOR. If I did it to substantiate and add color to the standard
interpretation (or any of the possible notable POVs included in the
article), that would be just fine, of course.

The above only holds true if the primary source is accessible and verifiable
though. If I say that a quote in a secondary source is wrong but can't
provide any proof of it, then other editors are going to have to take me at
my word. That's a bad policy -- there are far too many people who either
purposefully or unintentionally mis-read or mis-quote to support their
arguments to allow this. Even I sometimes make transcription mistakes, and I
do archival research for a living. Perhaps it is not assuming "good faith",
but I don't want a policy which lets people assert things that I cannot
check. The entire system of Wikipedia relies upon multiple eyes being able
to see something, and what you're suggesting is that we just jetison that in
the case of primary sources (which are already difficulty enough for people
to interpret).

As long as you don't do analysis, and pick your information straight
> from the source, document it and be sure other people can see it too,
> what's the big deal? How is that any different from looking up
> information on the internet or in a magazine from half a century ago?
> Especially so if we make them provide a copy of the document.

If other people "can see it too" and we can "provide a (long term) copy of
the document" then verifiability is not a problem at all. There is no such
thing as using a primary source without "doing analysis", as any historian
will tell you. All reading involves interpretation. All quoting (and all
narrative) involves being selective. The current policies allow for plenty
of flexibility in regards to editing and researching; they require that at
the end, all interpretations are anchored in a secondary source, and that
all sources used should be verifiable.

I've yet to see a compelling reason why that shouldn't remain the case; it
has worked pretty well so far, and yet even now we have constant problems of
people inserting dubious and incorrect information into articles. At least
at the moment we have a strong argument for consistently removing
information which cannot be verified -- you would remove this check? What
benefit could possibly outweigh such a deficit?

FF


from_name: Evan Martin

subject: [Wikitech-l] What is required to "fix search"?

body:
On 4/14/06, Lars Aronsson <lars at aronsson.se> wrote:
> I'm not sure if you're talking about the big web search engines
> (Google, Yahoo, MSN) or the search function in Mediawiki here.
> There is little excuse for the latter to have any delay.  But even
> for a big web search engine, it is easy to keep track of how often
> each webpage has changed in history, and economize how often it
> needs to be revisited.  Combined with the high PageRank of en.wp's
> RecentChanges (9 of 10), it would be trivial for Googlebot to
> revisit this page (or the front page of websites of major
> newspapers) every minute or two and make it a high priority to
> reindex all pages linked from there.  I suppose this is how Google
> News works.  Why it still takes about a month for Google to update
> its index on Wikipedia articles is a mystery to me.  Probably it
> has to do with a lack of competition.  If MSN or Yahoo were
> faster, it would force Google to improve.

I know this was intentionally provocative, but I'll bite anyway.

As far as I know, the limitation in general on Google indexing more of
wikipedia is that wikipedia can't serve pages fast enough (or, more
accurately, the extra load of more Googlebot will make wikipedia
slower).

To answer your specific proposal:
1) http://en.wikipedia.org/wiki/Special:Recentchanges has a meta tag:
<meta name="robots" content="noindex,follow" />
which indicates it's explicitly disallowed from being crawled.
2) If it were allowed to be crawled, I'd expect it to be regularly
updated for the reasons you describe.  But even in that case, this
particular page changing rapidly is not an indicator that the target
pages are also changing rapidly.  For example, I imagine that the digg
front page changes pretty much every time a crawler visits, but the
pages linked *from* digg are not necessarily changing any more rapidly
than any other random page on the web is changing.

Instead, there is a way for webmasters and Google to cooperate: the
sitemaps program.  You can read more about it here:
https://www.google.com/webmasters/sitemaps/docs/en/about.html


subject: [WikiEN-l] Archives as sources proposal

body:
On 4/14/06, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
>
> On 4/14/06, Guettarda <guettarda at gmail.com> wrote:
> Honestly, I think that is taking WP:NOR way too far. A book summary is
> one of the easiest things to verify, just pick up the book and see for
> yourselves. It is easy to spot where there is strict outlining of the
> facts, and it is just as easy to see where the author inserts his own
> opinion or analysis. For instance, take [[Pride and Prejudice]]. It
> contains a long detailed summary of what's in the book. What if we
> were to ask for a source that Mr Collins first proposed to Elizabeth
> Bennet and, when turned down, asked Charlotte Lucas. The contributor
> would probably say "Just read the damn thing and see for yourselves!"
> And he'd be right, that is by far the best way, instead of relying on
> a third party, which may or may not be entirely trustworthy (and migth
> be hard to find).

As he said, in most cases summaries are not an issue. But "see for
yourselves" does not work for any claims which are not strictly about who
did what at what time. For example, I could write something in the [[Origin
of Species]] article which claims that this book actually is an explicit
call to overthrow the British upper-classes. Someone else would no doubt
object. I am sure I could cite pages and lines from the book which support
such a goofy interpretation (but one not uncommon in the late 19th century).
But in this case, it would be clear that my "summary" was considerably
different than practically every secondary interpretation of the book. This
is where the NOR rule is handy -- it helps you clean out people's
idiosyncratic interpretations of primary sources, of which the internet
abounds (if you believed what you read online, Albert Einstein was a
card-carrying believer in every religion and philosophy on the planet --
everybody likes to find some way to relate Einstein's vague metaphysical
writes to their own personal outlook). When something is in real doubt (not
a matter of uncontested facts), we should go with the secondary literature.

One can also get all philosophical and say that when you something
> from a secondary source, you do the same thing, you analyze and parse
> the information and put it in your own words. Infact, besides making
> straight-copyvio copies of text, arn't we all breaking WP:NOR by
> simply contributing? However, that argument is just plain silly :P

I run into issues like this pretty regularly. The older a source is, and the
more people can relate it to something contemporary, the more you get this.
If you do anything at all on major intellectual figures then I imagine it
comes up pretty often. Again, in many situations summaries and quotations
are unproblematic and, as such, generally unchallenged. When people raise an
eyebrow, though, that's when the NOR really kicks in with a fury. And lo, it
is good.

FF