On Tue, November 13, 2007 2:49 am, Lars Aronsson wrote:
> After a long and complicated analysis, Virgil Ierubino concluded:
>
>> What this means is that we can't use a basic EBNF parser in all
>> the usual useful ways. We need new solutions.
>
> And the answer is: No, we don't need any of this. Because the
> current solution works fine.
>
> This whole discussion is without point. There is no need for
> change, is there? If it ain't broken, don't fix it.
Well, actually...
ever tried nesting tables?
ever tried putting a table inside a template argument?
those two are the most important issues as far as I am concerned. For
another example, check the CommonsDelinker talk page. Finding images is
not an easy task for a bot...
And let's not start about the magic words syntax in image placement...
All in all, I cannot agree with some of you that the current syntax is OK.
However, it's impossible to switch to a better grammar unless we can
convert the current syntax. I have given my views on how to do this (a
parser that outputs an XML tree or any other system that stores what you
meant instead of the wikitext), but apparently it's not feasible.
I'll see if I have some time in the next week to check out the parser
completely. If it is possible to hack template substitution etc to output
an XML description... then I'm already pretty happy because my python XML
parser project just became obsolete :D
--valhallasw
First, I notice there are some very useful links here:
http://meta.wikimedia.org/wiki/Alternative_parsers
There seems to be vague consensus that:
- It would be a good idea to replace the parser with a simpler parser using
a more traditional method
- Some parts of the grammar are virtually impossible to implement in such a
parser
- We may have to modify those bits of the grammar
- We will have to take very careful steps to roll out the new parser, to
avoid community outcry and breaking existing wikitext
- We would like to know which bits of the grammar are likely to be affected
and how important they are
Can I suggest that as a first step, we produce a table of the form:
Language feature | Difficulty of implementation | Changes required | Impact
of changes | <link to EBNF>
where the rows are sorted in the order they are processed by
the current parser.
So for example,
Nowiki | Easy | None | - | ...
Nested lists | Hard (I think) | To be determined | To be determined | ...
etc.
The major enlightenment that will come out of this is we will see *all* the
major problems, not just the ones that keep being raised, like bold/italics.
Steve
Hi all,
Looking at AutoLoader's __autoload() method, I see that the mappings
are kept in a static internal variable called $localClasses. Would
anyone have a problem with allowing this to be augmented by a global?
For example, say in LocalSettings or an extension you had:
$wgAutoloadClassMappings['Article'] = 'extensions/myextension/MyArticle.php';
And MyArticle extends Article, but with extra processing (presumably
something which can't currently be done with hooks).
Then, the code inside AutoLoader::__autoload() would contain something
like this:
------------
static $localClasses = array(
....
);
static $firstRun = true;
if ($firstRun) {
$firstRun = false;
global $wgAutoloadClassMappings;
if (!empty($wgAutoloadClassMappings)) {
$localClasses = array_merge( $localClasses, $wgAutoloadClassMappings );
}
}
------------
I think this could go a long way towards the goals of having a single
abstract factory pattern for object instantiation discussed previously
as the "Massive Hook Proposal".
I fully expect there's a better way to implement this than what's
proposed above. Any thoughts you have about this are much appreciated.
Thanks in advance.
-- Jim R. Wilson (jimbojw)
On 11/11/07, vasilievvv(a)svn.wikimedia.org <vasilievvv(a)svn.wikimedia.org> wrote:
> + $use_index = $dbr->useIndexClause( 'page_random' );
> + $page = $dbr->tableName( 'page' );
> + $categorylinks = $dbr->tableName( 'categorylinks' );
> + $category = $dbr->addQuotes( $this->category );
> +
> + $extra = $wgExtraRandompageSQL ? "AND ($wgExtraRandompageSQL)" : "";
> + $sql = "SELECT page_namespace, page_title
> + FROM $page $use_index JOIN $categorylinks ON page_id = cl_from
> + WHERE page_is_redirect = 0
> + AND page_random >= $randstr
> + AND cl_to = $category
> + $extra
> + ORDER BY page_random";
I'm not sure this is at all acceptable. The toolserver on the enwiki
database, at least, appears to filesort the contents of the category
in categorylinks. It may be "good enough" for small categories, but
it's far from ideal and might result in significant slowdown for large
categories like Living people. I would recommend requiring
$wgMiserMode to be false until a more efficient implementation can be
developed.
This may well have been suggested before, but: what if there
were a variant on Special:Random that somehow gave you a random
article in a category of your choice?
This popped into my head while thinking of better ways to
announce cleanup crusades (better, say, than proposing that
everyone take an hour out of navel gazing on the mailing lists
and instead select N articles from Special:Random and clean
them up), but it'd probably have plenty of other practical
applications, too.
Hello
I would like that the title of each article is placed in the centre
and not at the left margin as it is the default. I presume I have to
change the skin I use, but please could somebody give me a hint, where
exactly?
thanks
Uwe Brauer
Hi,
We are researching on the post quality of wikipedia, and we would like to
know how the page id is linked to the content ( page article content ). We
gather that from the dumps we can mirror wikipedia. We however want only a
subset.
Please do reply if anyone knows how to go about this.
Thank you in advance.
Janani Krishnamurthy
Hi,
We have developed a fast similarity search algorithm (FastSS) for
keyword search and we have used English Wikipedia articles to test it.
The similarity metric is the edit distance between words, which is
language independent. The result is displayed according to the
occurrence and edit distance. The website (http://fastss.csg.uzh.ch/)
has a demo of our prototype.
The indexing of the complete English Wikipedia takes ~3 days. We are
still working on improving the performance, solving issues with umlauts,
improving the rendering of the output page and integrating the title in
the indexing phase.
Should we work towards a mediawiki integration of FastSS? Is it of
interest to you to include FastSS into wikimedia? Any comments are welcome.
Regards,
Thomas Bocek
After 4 months, the APIedit branch [1] I've been maintaining is pretty
much finished. The branch adds the following functions to the API:
* State-changing actions
** Blocking and unblocking users (ApiBlock.php and ApiUnblock.php)
** Adding users to and removing them from groups (ApiChangeRights.php)
** Deleting and undeleting pages (ApiDelete.php and ApiUndelete.php)
** Moving pages (ApiMove.php)
** Protecting and unprotecting pages (ApiProtect.php)
** Rolling back edits (identical to the rollback link) (ApiRollback.php)
* Lists
** List all blocks (ApiQueryBlocks.php)
** List deleted revisions (ApiQueryDeletedrevs.php)
All these modules (except ApiQueryBlocks) require sysop or bureaucrat
rights, which means the user must be logged in through either a cookie
or the lg* parameters obtained from action=login. Additionally, all
state-changing actions require an edit token to be obtained from
prop=info, which changes at every login (changerights tokens also depend
on the username, rollback tokens on username and page name). This
prevents malicious pages from tricking a logged-in sysop into clicking a
link to something like api.php?action=delete&title=Very_important_page .
In order to facilitate these new modules, some minor and some less minor
changes to Article.php, Title.php, SpecialUndelete.php,
SpecialBlockip.php, SpecialIpblocklist.php and SpecialUserrights.php are
necessary. These changes mostly involve separating UI and DB logic. For
instance, instead of calling OutputPage::showErrorPage(), functions will
return an error code that is interpreted by either a UI wrapper (which
calls OutputPage::showErrorPage()) or an API wrapper (which calls
ApiBase::dieUsage()). This means I'll just be moving code around, not
changing it, except in Article::delete() (partial rewrite of the
deletion generation code which was ugly as hell; it even says so itself)
and Title::moveTo() (adding the possibility of not recreating a
redirect). Changes will have "APIEDIT BRANCH MERGE:" in the commit
reason, and will be made every two or three days. Please discuss them on
this list (wikitech-l).
I welcome your criticism,
Roan Kattouw (AKA Catrope on SVN)
[1] http://svn.wikimedia.org/viewvc/mediawiki/branches/apiedit/