Wikitech-l November 2007

wikitech-l@lists.wikimedia.org

90 participants
79 discussions

Re: [Wikitech-l] EBNF grammar project status?
by Merlijn van Deen 13 Nov '07

13 Nov '07

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

1 0

Moving forward on the parser
by Steve Bennett 12 Nov '07

12 Nov '07

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

3 5

Proposal for a configurable AutoLoader::__autoload()
by Jim Wilson 12 Nov '07

12 Nov '07

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)

4 6

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [27382] trunk/phase3/includes/SpecialRandomincategory.php
by Simetrical 11 Nov '07

11 Nov '07

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.

1 0

random idea
by Steve Summit 10 Nov '07

10 Nov '07

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.

2 1

centre the title of an article: how to change the skin
by Uwe Brauer 08 Nov '07

08 Nov '07

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

5 14

Text table
by Janani 07 Nov '07

07 Nov '07

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

2 2

Fast Similarity Search for Wikipedia
by Thomas Bocek 06 Nov '07

06 Nov '07

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

3 2

Merging APIedit branch with trunk
by Roan Kattouw 06 Nov '07

06 Nov '07

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/

3 3

[Fwd: Re: Unable to edit pages while logged in]
by Dimitris Tsallas 06 Nov '07

06 Nov '07

(Forwarding to the list as well for archival purposes, I just noticed the reply-to wasn't set in the original mail from Angela)

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l November 2007