Wikitech-l May 2008

wikitech-l@lists.wikimedia.org

94 participants
131 discussions

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

Replacement stats for placeholder images?
by David Gerard 13 Oct '09

13 Oct '09

I've been putting placeholder images on a lot of articles on en:wp. e.g. [[Image:Replace this image male.svg]], which goes to [[Wikipedia:Fromowner]], which asks people to upload an image if they own one. I know it's inspired people to add free content images to articles in several cases. What I'm interested in is numbers. So what I'd need is a list of edits where one of the SVGs that redirects to [[Wikipedia:Fromowner]] is replaced with an image. (Checking which of those are actually free images can come next.) Is there a tolerably easy way to get this info from a dump? Any Wikipedia statistics fans who think this'd be easy? (If the placeholders do work, then it'd also be useful convincing some wikiprojects to encourage the things. Not that there's ownership of articles on en:wp, of *course* ...) - d.

7 11

GSoC Project: Category Moving
by Tim Johansson 29 Jun '08

29 Jun '08

Hello, wikitech. I have applied to Google Summer of Code with the project to enable category moving without using bots. After some correspondance with Catrope, the following text is my project idea. Any feedback would be welcome. Synopsis I will provide capability of moving categories to achieve an effect for the end-user similar to that of moving other pages. Currently, contributors must apply to use a bot that recreates the category page and changes the category link on all relevant articles. Project The object can be divided into three parts. First, the category page is moved, along with its history, just as renaming of articles works. A redirect is optionally placed on the old category page, and the category discussion is moved as well. Second, all articles in the relevant category must have their category links changed. There are several obstacles involved in this task: 1. Finding all alternative ways of categorizing articles. It is simple to match the simple category links and category lists, but more difficult to find e.g. categories included from a template. Roan Kattouw (Catrope) suggested category redirects for this, such that all articles categorised as [[Category:A]] would also be listed at [[Category:B]] if the prior has been redirected to the latter. 2. Articles might be in the process of being edited as the movement is done. This, however, can be solved in the same manner as edit collisions are currently solved. 3. The algorithm would likely have high complexity and would thus not scale well with very large categories. This is likely to constitute a significant and challenging part of the project. As the last step, the relevant entries in the categorylinks table would need to be changed. This is accomplished by a simple SQL query. This could be avoided if bug #13579 [1] ("Category table should use category ID rather than category name") is fixed, which it could be as part of this project. The project would preferably be written as a patch to the core. Catrope suggested setting up a separate SVN branch for the project, such that everyone can see my progress. Profits for MediaWiki Developing a means of moving categories would decrease dependency on bots, gaining in administrative time. Additionally, the solution would be faster than any bot-relying solution could be due to, among other things, the removed need of loading pages. Category moving would also increase the consistency in layout on the different article types. The only real reason for a "move" tab not to reside on category pages is that the feature is not yet implemented. Roadmap Publishing this document to the MediaWiki development community (wikitech-l) and awaiting comments on the planned procedure would be the first step. After the community bonding period specified by the time line, a week should be enough to get comfortable with the relevant MediaWiki code and implement the first section, moving the category page along with its discussion and history. Much old code should be reusable here, such as the Title::moveTo() method for moving pages. Until mid of July, most of the second part of the project should be finished. In a week from there, the last part would be completed, too. A month is then reserved for bug-testing, tweaking and as a buffer for unexpected obstacles. The MediaWiki community is very important in this step for testing and feedback. Regards -- Tim Johansson http://timjoh.com/

8 13

Case insensitive links (not just titles).
by subscribe＠divog.com.ru 23 Jun '08

23 Jun '08

Hi Sorry for my English :) What I need is case insensitive titles. My solution for the problem was to change collation in mysql from <unf8_bin> to <utf8_general_ci> in table <page>, for field <page_title>. But bigger problem with links persists. In my case, if there is an article <Frank Dreben>, link [[Frank Dreben]] is treated like a link to an existent article (GoodLink), but link [[frank dreben]] is treated like a link to a non-existent article, so, this link opens editing of existent article <Frank Dreben>. What can be fixed for that link [[frank dreben]] to be treated like a GoodLink? I've spent some time in Parser.php, LinkCache.php, Title.php, Linker.php, LinkBatch.php but found nothing useful. The last thing I tried was to do strtoupper on title every time array of link cache is filled, in LinkCache.php. I also tried to do strtoupper on title every time data is fetched from the array. I've tried to make titles in cache be case insensitive, but it didn't work out, not sure why - it seems like when links are constructed (parser, title, linker, etc) only LinkCache methods are used. Could anybody point a direction to dig in? :)

7 36

confirmemail_body and create account
by Andreas Rindler 23 Jun '08

23 Jun '08

Hi, I need to create some user accounts and have mediawiki send the users a welcome message. I found the Mediawiki:confirmemail_body page which appears to feed such a welcome message. How do I do that? If I use Special:Userlogin, create an account and use "by email", the user gets a password reminder, but not a welcome message. I could change the password reminder text, but that wouldn't be correct for all the other users who use that page to genuinely retrieve their password. Thanks, Andi

3 5

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [34601] trunk/extensions/MetavidWiki
by Brion Vibber 16 Jun '08

16 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dale(a)svn.wikimedia.org wrote: > - window.domain = 'www.parent.domain.com'; > + window.domain = '<?=$parent_domain?>'; Just a note -- I strongly recommend against using the "short tags" (<? and <?= instead of <?php), as your code won't work at all on a server with short tags disabled in php.ini. Portable code should use the long-form tags consistently. - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgoz70ACgkQwRnhpk1wk46bOwCgxhT8T8Mv5jLz0PPpBKQTU5Nq Je4AnjsjG/IsKESaskfug+eTtXqmmpvh =bAri -----END PGP SIGNATURE-----

2 1

loading of extensions in 1.12 slow?
by Travis (wikiHow) 09 Jun '08

09 Jun '08

Hi, We're in the process of upgrading from 1.9 to 1.12 (I know I know I know...), and it seems that the including of extensions is taking a long time. Profile from 1.9: 26.449 WebStart.php-conf 24.659 Setup.php 1.362 Setup.php-includes 2.117 Setup.php-misc1 1.020 Setup.php-memcached 0.570 Setup.php-SetupSession 0.117 Setup.php-globals 0.052 Setup.php-User 0.017 Setup.php-misc2 18.543 Setup.php-extensions Seems fast, but 1.12: 594.761 WebStart.php-conf 0.012 WebStart.php-ob_start 207.409 Setup.php 50.838 Setup.php-includes 8.691 Setup.php-misc1 6.780 __autoload 9.632 Setup.php-memcached 0.685 __autoload 0.564 Setup.php-SetupSession 0.197 Setup.php-globals 0.046 Setup.php-User 0.023 Setup.php-misc2 128.051 Setup.php-extensions This is pretty slow. It seems like for WebStart, having multiple inclusions like this: require_once('extensions/wikihow/SpecialThankAuthors.php'); slows things down. Has something changed, or did we miss flipping a switch in the upgrade? What about Setup.php, does that have the same issue? Thanks, Travis

4 9

SUL homewiki selection question
by Anon Sricharoenchai 05 Jun '08

05 Jun '08

Hi, 1. Why still we let the SUL to auto select the homewiki in Special:MergeAccount? 2. Why not we let the wiki that do Special:MergeAccount as homewiki? Example, Assuming that it has user test123@testwiki (1000 edit counts) and test123@lowikibooks (500 edit counts) * If test123 do merge account at, http://test.wikipedia.org/wiki/Special:MergeAccount, then testwiki will be homewiki. * If test123 do merge account at, http://lo.wikibooks.org/wiki/Special:MergeAccount, then lowikibooks will be homewiki. 3. Why not prohibit creation of existing account that have not yet been merged on any wikis? Example, 1. Before SUL, if have test123 created on http://lo.wikipedia.org 2. test123@lowiki has not been merged on any wikis. 3. After SUL, should immediately prohibit the creation of test123 account on any WM wikis. (even that test123 has not yet been merged to SUL) 4. Considering the following situation, 1. Mr.A own "user123" at, * testwiki,meta,common,mediawiki: 100,500,500,500 edits count * enwikipedia,enwikibooks,enwikitionary,enwikisource,enwikinews: 100,100,100,100,100 edits count * lowikipedia,lowikibooks,lowiktionary,lowikisource,lowikinews: 500,100,100,100,100 edits count * totally, Mr.A has 3000 edits count 2. Mr.B own "user123" only at frwikipedia with 2000 edits count 3. When Mr.A use user123 on lowikipedia, and do http://lowikipedia/Special:MergeAccount, what will be the homewiki of user123? 4. Mr.A can successfully merge account? 5. If homewiki determined by the system is user123@frwikipedia, then what thing Mr.A could do to get his accounts merged? Regards, Anon.

9 22

Scream for mercy: breaking changes
by Max Semenik 03 Jun '08

03 Jun '08

Sorry, this is going to be a blatant rant... Request: http://www.wikia.com/api.php?action=query&list=categorymembers&cmtitle=Cate… Result: <?xml version="1.0" encoding="utf-8"?> <api> <error code="cmtitleandcategory" info="The cmcategory and cmtitle parameters can't be used together" /> </api> How are people supposed to write tools that work with sites other than Wikipedia when things change fast and non-intrusive fallbacks for older versions are specifically blocked? Please remember that MediaWiki is not used only on Wikimedia, where SVN HEAD is just fine. It is used by thousands of other sites, many of which are older, but still can benefit from bot tools. And I can't just get the MediaWiki version before retrieving categories, because that would disqualify those who use 1.12 pre-releases. Thanks Satan this at least was removed soon after the release. The moral: please think of long-term consequences of your changes, if you change the way a piece of code works, at least (pleeeease!) allow people to fall back without much PITA. And can this mistake be fixed at least in service releases for 1.12? -- Max Semenik ([[User:MaxSem]])

6 6

Database dumps fail in the wrong way
by Lars Aronsson 01 Jun '08

01 Jun '08

When a database dump fails, as seen in "20 items failed" on http://download.wikimedia.org/backup-index.html then the dump script continues with the next database in turn. Apparently they often fail in groups. I guess this is because the failure doesn't depend on the database itself (e.g. svwiki) but on some other circumstance. When that circumstance is solved, all dumps succeed. Right now (20080529), frwiki is being dumped. Previous successful dumps of frwiki were done on 20080514 and 20080420, http://download.wikimedia.org/frwiki/ The last successful dump of svwiki was made on 20080406, but the one on 20080425 failed, and the one on 20080524 was aborted, http://download.wikimedia.org/svwiki/ Hopefully, but only hopefully, the next svwiki dump will succeed in just a few days or weeks. But who knows. Maybe it too will be aborted and the next dump of frwiki will run instead. What I want is the dump script to be rewritten so it prioritizes those databases (websites) that haven't been successfully dumped in a long time. It seems unfair that the French should have one every fortnight when us Swedes are waiting almost two months. Other than this, I want the dumps to fail less often. Why do they fail? Has this been investigated? What can be done to help this? -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

8 15

Jump to page:

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 May 2008