Hello,
we will soon need to customize namespaces at Lombard wikipedia; this is mainly due to three reasons (3 is most important):
1) translating English names
2) creating a 'portal' namespace
3) duplicating 'category' feature, to deal with the fragmentation of Lombard tongue into two major dialect groups.
As to 1) I guess that local Mediawiki should be enough; as to 2) it seems to me yet obscure; 3) cannot be dealt with by creating, say : 'category/west' and 'category/east', since the word 'Category' itself has two slightly different translations.
Thus an additional namespace is needed, like in case 2).
I read this:
http://meta.wikimedia.org/wiki/Help:Custom_namespaces
Best regards,
Claudi
---------------------------------
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
Hello,
we will soon need to customize namespaces at Lombard wikipedia; this is mainly due to three reasons (3 is most important):
1) translating English names
2) creating a 'portal' namespace
3) duplicating 'category' feature, to deal with the fragmentation of Lombard tongue into two major dialect groups.
As to 1) I guess that local Mediawiki should be enough; as to 2) it seems to me yet obscure; 3) cannot be dealt with by creating, say : 'category/west' and 'category/east', since the word 'Category' itself has two slightly different translations.
Thus an additional namespace is needed, like in case 2).
I read this:
http://meta.wikimedia.org/wiki/Help:Custom_namespaces
Best regards,
Claudi
---------------------------------
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Cliquez ici.
Hello,
this is a trial message: seemingly there is sum bug, since I do not receive e-mails sent by me to Wikitech.
Claudi
---------------------------------
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.6.7 is a security and bugfix maintenance release of the
Spring 2006 snapshot:
An HTML/JavaScript-injection vulnerability in the edit form has been closed.
This vulnerability was new in 1.6.0; MediaWiki versions 1.5.x or earlier are
not affected.
Extensions, comments, and <nowiki> sections are now handled in a one-pass
way which is more reliable and safer. Under earlier versions of MediaWiki,
certain extensions could be abused to inject HTML/JavaScript into the page.
Additional precautions are made against offsite form submissions when
the restricted raw HTML mode is enabled.
Some small localization and user interface updates are also included.
* (bug 6051) Improvement to German localisation (de)
* (bug 6017) Update bookstore list for German language (de)
* (bug 6138) Minor grammar tweak in "loginreqlink"
* (bug 5957) Update for Hebrew language (he)
* Increase robustness of parser placeholders; fixes some glitches when
adjacent to identifier-ish constructs such as URLs.
* (bug 5384) Fix <!-- comments --> in <ref> extension
* Nesting of different tag extensions and comments should now work more
consistently and more safely. A cleaner, one-pass tag strip lets the
'outer' tag either take source (<nowiki>-style) or pass it down to
further parsing (<ref>-style). There should no longer be surprise
expansion of foreign extensions inside HTML output, or differences
in behavior based on the order tags are loaded.
* (bug 885) Pre-save transform no longer silently appends close tags
* Pre-save transform no longer changes the case of close tags
* Edit security precautions in raw HTML mode, etc
Full release notes:
http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_6_7/phase3/RELEASE-NOTEShttp://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_6_7/phase3/HISTORY
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.6.7.tar.gz
MD5 checksum:
cbcba609339abb5688068e5dc379110b mediawiki-1.6.7.tar.gz
SHA-1 checksum:
b5aadd8240d63c644728d071e4f452d0efacf5bf mediawiki-1.6.7.tar.gz
Before asking for help, try the FAQ:
http://www.mediawiki.org/wiki/FAQ
Low-traffic release announcements mailing list:
(Please subscribe to receive announcements of security updates.)
http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce
Wiki admin help mailing list:
http://mail.wikimedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikimedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEhUuXwRnhpk1wk44RAt3lAJ47O0Zy8n3AuM03GM5jvXETaC75ogCfdsEe
JFcS6FqSkz0485oU4HN7eBs=
=8x0L
-----END PGP SIGNATURE-----
[Brion Vibber wrote] :
> <b>First paragraph
>
> Second paragraph
Just thinking aloud, but could this be made equivalent to:
==============================
'''First paragraph
Second paragraph
==============================
... which currently produces HTML-compliant output?
[Adrian Buehlmann wrote] :
> We need them because the "|" of wiki
> table interferes with template "|" and ParserFunctions "|".
Yes, it is slightly unfortunate that "|" has been overloaded to mean
both a parameter and to perform table-related functions.
Of course with 20/20 hindsight, it's easy to say it could be useful to
have two different constructs for these purposes. I suppose it's
theoretically possible to introduce a new construct of some type
(example: "%") to indicate parameters (since I suspect parameter
delimiters are probably used less than "|" in tables), and have an
overlap period when both the new and the old construct work to allow
transitioning, and to then turn off/deprecate "|" for parameters. Then
the old HTML "<table>" syntax could be dropped if there was general
support for it (bias disclaimer: I personally prefer the
wiki-table-syntax to the HTML-table-syntax), because "|" would no
longer interfere with templates or ParserFunctions.
In such a scenario, the question main though is whether $gain >=
$pain. The pros and cons are probably something like this:
$gain:
* For people who prefer wiki tables to HTML tables.
* Gain in standardization (only one table format to understand, rather
than two).
* Gain in simplifying the Parser slightly by eliminating HTML table
syntax and "|" ambiguity (maybe?)
* Gain for people who want to use table-related syntax as parameters
to templates or ParserFunctions.
$pain:
* Transition costs in moving pages using old parameter syntax to new
parameter syntax.
* Transition costs in moving some pages from old HTML table syntax to
wiki table syntax.
* The Parser implementation pain.
* Adjustment pain for people who prefer HTML table syntax.
All the best,
Nick.
An automated run of parserTests.php showed the following failures:
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 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 379 of 390 tests (97.18%) FAILED!
I am not a statistician, but I did throw some numbers together to create an overall metric for the
editing growth of en:Wikipedia. The idea is thus: How many "active editors" do we have at any
given time, and how much are they actually editing at any given time? Find a way to put both on
the same graph and you have a slick graph without getting buried in detail.
http://commons.wikimedia.org/wiki/Image:Wiki_editing_growth_guide.pnghttp://commons.wikimedia.org/wiki/Image:En_wikipedia_overall_editing_growth…
Start at (0,0) and follow the arrowheads that indicate time progression. (Loop-d-loops are
possible, but didn't show up.) I used numbers from a toolserver page and did some simple
manipulation and plotting.
In short: Wikipedia, as of a year ago, was attracting more editors each month while keeping up an
average of 115 edits/month/Wikipedian.
Hope this helps,
George
meta|en|irc:[[User:GChriss]]
> Patterns by day of the week would also be interesting. My entirely
> subjective observation is that there are fewer people around on a
> Saturday night.
I'm pretty sure there actually are fewer people around.
I say this because there used to be a graph of number of web requests
at: http://wikimedia.org/stats/live/org.wikimedia.all.squid.requests-hits.html
The Internet Archive has a picture-less cache of it here:
http://web.archive.org/web/*/http://wikimedia.org/stats/live/org.wikimedia.…
*However* it does not have the images, which were the useful bits....
so you'll probably just have to make do of my summary of them.
Basically what that graphs showed was:
* Oscillating within a day, presumably to reflect peak times / off
peak times for the US and Europe, with peak load presumably falling in
the overlap of business hours between the two.
* Varying within a week. Saturday and Sunday were substantially
quieter. Most of the weekdays were fairly similar, but Monday was a
little bit quieter than the rest (people coping with the Monday work
rush?), whilst Wednesday was the busiest day of all (work rush
partially coped with?), and Friday was a little bit quieter (thinking
about the weekend?).
Hope that helps.
All the best,
Nick.
Hi All,
There is a Cross-Site-Scripting arbitrary JavaScript execution and
HTML insertion vulnerability in MediaWiki.
This is achieved by injecting malicious data into a specific value
which is not sanitized / escaped before being echoed back to the
user's browser.
The vulnerability affects current SVN, MediaWiki 1.6.6 (current
stable), as well as the live Wikipedia.
No extensions need to be installed.
Details have been provided to security(a)wikimedia.org as per the
instructions at: http://www.mediawiki.org/wiki/Security , and will be
withheld for a period, before being made publicly available at:
http://nickj.org/MediaWiki
All the best,
Nick.
