Hello
Using mediawiki-1.9.3, I have a page which is entitled
Comportamiento asintótico y dinámica de ecuaciones diferenciales
and displayed in my browser as
index.php/Comportamiento_asint%C3%B3tico_y_din%C3%A1mica_de_ecuaciones_diferenciales
Now I have the following setting
$wgGroupPermissions['*']['read'] = false;
$wgWhitelistRead = array(":Main
Page",":Seminarios",":Comportamiento_asint%C3%B3tico_y_din%C3%A1mica_de_ecuaciones_diferenciales":SpecialPages");
Now the article Seminarios, which does not contain no ascii caracters
is displayed for all users, however in order to visit
Comportamiento asintótico y dinámica de ecuaciones diferenciales
media wiki claims that you have to be logged in order to see the
article.
But since that article is in the whitelist I am puzzled.
What shall I do with non ascii chars?
thanks
Uwe Brauer
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.12alpha (r26767).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...
17 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 527 of 544 tests (96.88%)... 17 tests failed!
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.12alpha (r26717).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...
17 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 527 of 544 tests (96.88%)... 17 tests failed!
Hi, I have downloaded the wikipedia database and want
to pose a query to search for all featured pages. Can
you tell me which table I should look into. Thank you
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
On 10/14/07, Tim Starling <tstarling(a)wikimedia.org> wrote:
[snip]
> Instead, I would suggest having two edit boxes on the edit page -- one
> at the top for templates, and a second one for the main article text.
> The one at the top would be hidden by default, you would click a button
> to expand it.
>
> The dividing line between the two would be determined heuristically on
> the server side.
>
> A link would be provided to a non-JS version of the edit page, for
> compatibility. A user preference could also be added.
If we're going as far as two edit boxes and JS magic it would probably
be better to adjust the edit window so that template parameters, (and
probably ref tags) are hidden by JS and clicking on them or moving the
cursor into them expands them.
It wouldn't be any more evil than the various syntax highlighting
user-scripts that already exist.
The parsing required to identify templates is not at all hard. (I
think it's the only aspect of our Wikitext parsing that is fairly easy
to get right... :) )
We could go even further and have it go fetch a template configuration
page for each template, and then automatically show all the fields,
refuse to allow the user to completely remove a mandatory field,
provide hover-over/pop up help about the various field types, and even
basic input validation.
Is this line of thinking too kludgy?
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.12alpha (r26706).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...
17 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 527 of 544 tests (96.88%)... 17 tests failed!
David Gerard escribió:
> On 13/10/2007, Erik Moeller <erik(a)wikimedia.org> wrote:
>> On 10/13/07, David Gerard <dgerard(a)gmail.com> wrote:
>
>>> http://www.calacanis.com/2007/02/20/technological-obscurification-three-way…
>
>> His name is Calacanis,
>
>
> And it's right there in the URL. I suppose this is what I get for
> including a vocabulary flame.
>
>
>> and it's an old thread - but IMHO quite
>> relevant to the discussion about slowing growth.
>
>
> Yes, which is why I forwarded it.
>
>
>> Good WYSIWYG in a wiki is hard; even Wikia hasn't solved that
>> particular problem yet. Hopefully we'll make serious progress on it
>> next year.
>> The LiquidThreads discussion extension which could replace talk pages
>> is now in production use e.g. on WikiEducator.org ; all it needs is a
>> champion within the Wikimedia community.
>
>
> Really? That's excellent :-)
>
> The comment I added to the discussion was:
>
> ===
> 1. The main problem is that MediaWiki wikitext does not have a defined
> syntax - the definition is quite literally the PHP code - and is
> mathematically impossible to put into EBNF. (Many have tried, got to
> 95% and realised it wasn't actually possible.) So there are no
> alternate parsers, and no WYSIWYG can cover the lot. But 95% coverage
> in a WYSIWYG editor should get most of the useful bits.
>
> FCKeditor looks like the best prospect for a WYSIWYG MediaWiki editor
> at present. It's not there yet, but I hold out hope for the near to
> medium future.
>
> 2. Talk pages are indeed a crappy forum format. There are various
> extensions to help improve this - Uncyclopedia uses the forum
> extension to good effect (wikitext pages but with a forumlike main
> page) and the LiquidThreads extension is undergoing serious work.
> 3. On this one, I think you're plain wrong. (a) IRC is damn useful,
> but you do not in any way have to be on IRC to be a productive
> Wikipedia editor, admin or even arbitrator. And many aren't and won't
> be. (b) I find it hard to conceive how any Internet idiot can lower
> the world's collective IQ with instant messaging, but thinking people
> who would want to contribute to an encyclopedia can't. And IRC is IM
> based around chatrooms instead of one-to-one. If you can use Trillian
> or GAIM/Pidgin, you can use IRC.
There was a proposal on may[1] about having cgi-irc gateway on the
toolserver but it was rejected[2]. Time to rethink it?
Other solutions include the Java client[3] and Wikizine cgi-irc[4] which
seem to have added most of our channels.
1-http://lists.wikimedia.org/pipermail/toolserver-l/2007-May/000759.html2-http://lists.wikimedia.org/pipermail/toolserver-l/2007-May/000765.html
3-http://tools.wikimedia.de/~bjelleklang/pjirc/index.php
4-http://chatwikizine.memebot.com/cgi-bin/cgiirc/irc.cgi
Are there settings to alter the title length to accommodate unicode
character sets like cherokee, which requires 3 bytes for each letter. I
am now translating titles and I am findind they do not fit when converted
to Cherokee (and I get a lot of duplicate title errors for titles which
are not duplicates.
On 13/10/2007, Erik Moeller <erik(a)wikimedia.org> wrote:
> On 10/13/07, David Gerard <dgerard(a)gmail.com> wrote:
> > http://www.calacanis.com/2007/02/20/technological-obscurification-three-way…
> His name is Calacanis,
And it's right there in the URL. I suppose this is what I get for
including a vocabulary flame.
> and it's an old thread - but IMHO quite
> relevant to the discussion about slowing growth.
Yes, which is why I forwarded it.
> Good WYSIWYG in a wiki is hard; even Wikia hasn't solved that
> particular problem yet. Hopefully we'll make serious progress on it
> next year.
> The LiquidThreads discussion extension which could replace talk pages
> is now in production use e.g. on WikiEducator.org ; all it needs is a
> champion within the Wikimedia community.
Really? That's excellent :-)
The comment I added to the discussion was:
===
1. The main problem is that MediaWiki wikitext does not have a defined
syntax - the definition is quite literally the PHP code - and is
mathematically impossible to put into EBNF. (Many have tried, got to
95% and realised it wasn't actually possible.) So there are no
alternate parsers, and no WYSIWYG can cover the lot. But 95% coverage
in a WYSIWYG editor should get most of the useful bits.
FCKeditor looks like the best prospect for a WYSIWYG MediaWiki editor
at present. It's not there yet, but I hold out hope for the near to
medium future.
2. Talk pages are indeed a crappy forum format. There are various
extensions to help improve this - Uncyclopedia uses the forum
extension to good effect (wikitext pages but with a forumlike main
page) and the LiquidThreads extension is undergoing serious work.
3. On this one, I think you're plain wrong. (a) IRC is damn useful,
but you do not in any way have to be on IRC to be a productive
Wikipedia editor, admin or even arbitrator. And many aren't and won't
be. (b) I find it hard to conceive how any Internet idiot can lower
the world's collective IQ with instant messaging, but thinking people
who would want to contribute to an encyclopedia can't. And IRC is IM
based around chatrooms instead of one-to-one. If you can use Trillian
or GAIM/Pidgin, you can use IRC.
===
- d.