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.
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.
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/
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? :)
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
-----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-----
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
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.
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]])
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