Chris Lüer wrote:
> At 09:59 AM 6/19/2006, Guettarda wrote:
>
>
>> Don't forget the accounts which exist to prevent impersonation in one's main
>> language - names with capital I's to mimic L's and Cyrillic characters.
>> Deleting these would just open things up for abuse again.
>>
>
> Is there are a reason why user names with weird Unicode characters
> are even allowed? It would seem sensible to limit user names on each
> Wikipedia to the alphabet that is used in that language.
>
> Chl
>
>
>
A suggestion, based on practices used for IDN registration:
Restrict new usernames on the en: Wikipedia to characters from the Latin
alphabet and selected punctuation only (and possibly digits as well).
Before allowing a username to be registered, generate a canonical
comparison form by Unicode normalization, lowercasing, punctuation and
space suppression and accent-stripping, followed by homograph
canonicalizations such as mapping both digit zero and letter O to the
latter, digit 1 and letter L to the latter, eth to lowercase d, etc.
A new username should then only be allowed to be registered if the
comparison form of the proposed new username is different from the
comparison form of every existing username (which are stored in an
indexed table, alongside the full, uncanonicalized name that actually
gets registered).
Doing this will eliminate the vast majority of all simple username
spoofing hacks.
Existing usernames get grandfathered in, of course.
-- Neil
---------- Forwarded message ----------
From: rotem(a)svn.leuksman.com <rotem(a)svn.leuksman.com>
Date: 20-Jun-2006 10:56
Subject: [MediaWiki-CVS] SVN: [14835] trunk/phase3/languages/Messages.php
To: mediawiki-cvs(a)wikimedia.org
Fixes per Gangleri's request:
* Replacing {{ns:X}} with the real namespace names, for performance -
except for "administrators" which is directly shown.
* Removing the obsolete underscores from the log pages.
I went through the messages files and replaced certain instances of
{{ns:blah}} with canonical names a while ago, per Domas' request. This
change is a little bit needless, since those messages aren't used in
all page views, so the performance hit is reduced. What does happen is
a less intuitive interface readout.
I did explain all this to Gangleri at the time.
Rob Church
Hi,
I have downloaded enwiki-latest-pages-articles.xml.bz2, and have a version
of Wikimedia checked out from subversion (with relevant extension added as
well).
I issue the following commands:
bzip2 -d enwiki-latest-pages-articles.xml.bz2
cat enwiki-latest-pages-articles.xml | php5 maintenance/importDump.php
My question is:
Does this XML file include the Template: namespace, on completion will pages
with references to templates render.
Regards
Richard Wooding
On 6/18/06, Brion Vibber <brion(a)pobox.com> wrote:
> When the primary file storage is migrated to the hash-based filestore, that will
> decouple physical filenames from logical filenames and make that feasible.
>
> I do want to make sure it's done before the end of the year, but it's not a top
> priority (and we want to be damn sure migration will work correctly when it
> happens; we'll have near half a terabyte of data to migrate when the time
> comes!) so it won't be tomorrow.
Brion,
When you work on the hash store for primary storage you'll have to
address thumbnails.
When you do this, please keep in mind the ability to create thumbs
with multiple parameters beyond size, I'm not suggesting that such
extensions need be implemented today, I just want us to avoid a
redesign should we decide to implement them in the future.
Here are three examples where additional parameters would be very useful:
1) Cropping. Right now there are cases where people will upload
multiple cropped versions of an image to place parts at reasonable
sizes throughout the article. This complicates tagging and copyright
matters, is generally wasteful, and can not be fluidly edited. A
syntax such as [[Image:foo.jpg|crop:100x100+20+80|50px]] would solve
this. Cropping should be possible without loading the entire image in
memory, but imagemagick doesn't currently do this as far as I can
tell.
2) Sharpening. Many images lose too much [[accutance]] when
downsampled with quality filtering, and appear blurry as a result.
This has caused some cases of people uploading thumbed and sharpened
images rather than using mediawiki syntax. Syntax would be something
like [[Image:foo.jpg|thumb|sharpen_high]]. Sharpening should be
possible without completely loading the image in memory, but
imagemagick doesn't do this as far as I can tell.
3) SVG parameters. For translations and other applications it would be
useful to do basic variable replacement in SVGs, for example
[[Image:heart.svg|250px|options=title:The human heart,la:Left
auricular,rv:Right ventricle]]. Perhaps positioning issues will make
that non-useful without a full XSLT engine (which can be done in bound
memory and cpu...) but that would be a much larger issue.
I hope you can see from these examples that it is possible that
someday we will decide that having more options offsets the additional
storage and missrate of having more thumbnail flavors.
It's also possible that some would like to provide a jpeg quality
switch, because our current setting create visible artifacts on some
images... but I think this would be better solved by increasing our
jpeg quality setting globally.
Hi, we have a strange behaviour on the nap wikipedia. Strange enough the
categories don't work well - the first one works - the others not ... hmmm
http://nap.wikipedia.org/wiki/Acerno
The categories are inserted like this:
[[category:giugrafia]]
[[category:Comune d<nowiki>''</nowiki>a Campania]]
[[category:Comune d<nowiki>''</nowiki>a pruvincia 'e Salierno]]
now we tried the following:
changed the category to Categoria, Category, categoria
took out the nowiki-tag
The only thing that works is take out the '' + the nowiki tag - so we
get a category, but the resulting spelling is then plain wrong. It
worked well up to the last version of the Mediawiki software ... so
something must have been changed there.
One thing I just tried out: also wiki-links do not work anymore - this
means we cannot create correct pages anymore since <nowiki> does not
seem to be allowed within a wiki link. This means problems with
nap.wikipedia, but not only: also wiktionary will have (maybe already
has) problems with this (we have approx. 3000 Neapolitan words (if I am
right) in the Italian wiktionary - some of these probably use the '')
Could someone please look into this?
Thank you!
Best, Sabine
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
Hi!
This is relevant to Wikimedia. See also my workshop on Wikipedia
research and Max Völkel's workshop on Semantic Wikis. You should
definitely consider to come to WikiSym.
Greetings,
Jakob
-------- Original-Nachricht --------
Betreff: [wiki-standards] Wiki Markup Standard Workshop
Datum: Tue, 20 Jun 2006 13:04:37 +0200
Von: Chuck Smith <chuckssmith(a)gmail.com>
An: wiki-standards(a)wikisym.org
In the upcoming WikiSym in Denmark, Christoph Sauer and I will be
leading a workshop on creating a wiki markup standard. More
information can be found here:
http://ws2006.wikisym.org/space/Workshop%3E%3EWiki+Markup+Standard
Would anyone else be interested in working with us to provide a more
balanced wiki markup standard to present during WikiSym? I heard
there are some very interested parties from SnipSnap interested in
helping with this. You are all welcome to attend our workshop and we
would appreciate any feedback you have for us.
For our workshop, we plan to follow Suggestion B on
http://www.usemod.com/cgi-bin/mb.pl?WikiMarkupStandard
Best regards,
Chuck
_______________________________________________
wiki-standards mailing list
wiki-standards(a)wikisym.org
http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
John Lee wrote:
> Steve Bennett wrote:
>
>>It would be good if we could put users on probation. Occasionally I've
>>taken the effort to track a vandal, watching and reverting their
>>edits. But it would be nice to be able to say "this user's next edit
>>is 90% likely to be vandalism, hence, let's screen it *before* it goes
>>live". All the edits of probationary users could appear on one screen,
>>and people watching that list could pick out the occasional good ones
>>to let through, much like moderating a mailing list.
>
> This is something of a perennial proposal. The main problem I see with
> it is the potential for edit conflicts - if a valid edit goes through
> between when the probationary edit is made, and when it is approved,
> there might be trouble merging the two edits together.
The technical side could actually be handled rather easily: all we need
is a way to tag a specific revision as the visible one. If the visible
version isn't the latest, and someone tries to edit it, they get the
same (or similar) warning as when editing an old revision in general.
"You are editing the stable version of this page. If you save it, any
unreviewed changes made since this version will be removed."
(In fact, it might be possible to use the existing page_latest column
for this, though I haven't really checked.)
--
Ilmari Karonen
An automated run of parserTests.php showed the following failures:
Running test External image... FAILED!
Running test External image from https... FAILED!
Running test External links: Clickable images... FAILED!
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Parsing optional HTML elements (Bug 6171)... FAILED!
Running test Inline HTML vs wiki block nesting... FAILED!
Running test Mixing markup for italics and bold... FAILED!
Passed 388 of 404 tests (96.04%) FAILED!
I tried to post William Albert Wirt today, and kept being redirected to
William Wirt; the General.
William Albert Wirt was the best Superintendent of schools, that started the
Platoon System.
I had to list him under, Superintendent William Albert Wirt .
Is there anyway, that it can be changed to just William Albert Wirt, without
conflicts with William Wirt the General?
TimT