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 informally mentoring André, Tiago, Diego, and César. They
are four students at Minho University who are currently working on a
project to improve DB2 database support in MediaWiki.
So far, they've:
- Fixed several outstanding issues with DB2 support involving
character encoding, Windows vs Linux, etc
- Added DB2 support to the new MediaWiki 1.17 Installer and Updater
- Put in the appropriate Updater sql patches to reflect database
schema changes since 1.14
MediaWiki already had some DB2 support, but it's been broken since
1.15 and never complete. As a result of their work, it's now possible
to successfully install MediaWiki on DB2 out of the box and to use the
core wiki features.
I'll shortly commit their first patch using my SVN account (leonsp).
I've taken some care to look over the code and make sure it abides by
the MediaWiki code guidelines.
Regards,
Leons Petrazickis
http://lpetr.org/blog/
(CC'd inez @ wikia)
In the process of getting a better feel for the current state of Wikia,
Wikihow, & a few others' rich text editor tools, I'm going through Wikia's
CKEditor-based RTE extension and seeing if I can get it working on MediaWiki
trunk.
I've got a fork from Wikia's SVN in this gitorious project:
http://www.gitorious.org/mediawiki-wikia-rte
The 'master' branch is a straight git-svn clone of the subtree; 'tweaks'
branch has some extra doc comments and some initial tweaks to get it loading
(if not actually working right yet ;) on stock MediaWiki 1.18-SVN.
Current state:
* most stuff won't work yet!
* the editor can be loaded if forced with &useeditor=wysiwyg
* load/save results in some corruption, probably mostly due to the parser
annotations not all being present (need to customize a few bits)
* the editor is loaded through ResourceLoader, using a quick stub to work
around the lack of removal of certain lines
* it's almost certain that the CSS and some JS is broken :D
* there are various Wikia-specific PHP-side and JS-side extensions, many of
which still need to be switched to the stock MW equivalent or copied over.
Note that definitions for such things can usually be found in the modified
MediaWiki core in Wikia's SVN tree --
https://svn.wikia-code.com/wikia/trunk/
At a minimum I'd like to end up with something that works on stock MediaWiki
1.18 (and if it can be made to work on stock or lightly-patched 1.17, even
better!). It should be a more stable option for 1.17 users than the old
FCKEditor extension.
I'm still a bit leery of the internal annotations & edge-case checks for the
round-tripping and whether this structure would work for us in the long
term, but there's some good stuff in here that's going to be useful to learn
from whatever we do, and it's a useful tool for many cases in the short
term.
If anybody feels like trying it out / pitching in on the fixes, do feel free
to give a shout. I can set a few folks up with commit access on the git repo
or take some pulls for now, and will merge it into our SVN extensions when
it's a bit more stable.
-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On Tue, May 31, 2011 at 10:35 AM, Neil Kandalgaonkar
<neilk(a)wikimedia.org> wrote:
> Are we all in deadlock or something? Are the users who can push waiting
> from some proposals/work from the rest of the community?
We had a hallway conversation about this just now (Neil, Trevor, Brion
and I, and then just Brion and I), which I think was pretty useful.
Here's where we went with it:
1. We rehashed the pre-commit review proposal that Neil suggested a
few months ago, and agreed that pre-commit would be helpful in keeping
the backlog down
2. Given our current tools/process, we agreed that insisting on
pre-commit review would be a pain in the butt.
3. Brion and I further discussed review process, trying to come up
with a system that give us the benefits of pre-commit review, without
actually switching to pre-commit review
Here's where things I think got interesting. Brion pointed out that
in ye olden days, he was much more aggressive about reverting things
he didn't understand. I pointed out that, as we broaden the pool of
committers, "I don't understand"-based reversions lead to a lot of
ugliness, since very few people claim to have a broad understanding of
the system and therefore an expectation of understanding every change.
Most reviewers, faced with a commit they don't understand, will leave
it for others to comment on. There's been a lot of unnecessary drama
and churn over reversions because of misunderstandings about what a
reversion means.
So, there's a number of possible solutions to this problem. These are
independent suggestions, but any of these might help:
1. We say that a commit has some fixed window (e.g. 72 hours) to get
reviewed, or else it is subject to automatic reversion. This will
motivate committers to make sure they have a reviewer lined up, and
make it clear that, if their code gets reverted, it's nothing
personal...it's just our process.
2. We encourage committers to identify who will be reviewing their
code as part of their commit comment. That way, we have an identified
person who has license to revert if they don't understand the code.
I coulda swore there are other ideas that came out of that
conversation, but alas, I wasn't taking notes. Anyway, I'm sure
they'll come up in this thread.
Rob
Neil spent some time yesterday hacking with the Hackpad guys (
https://hackpad.com/ -- an Etherpad fork) experimenting with embedding the
collaborative editor via an <iframe> into MediaWiki's edit page in order to
use it to do multiuser editing.
Apparently it's pretty cool so far and I'm looking forward to seeing it
stabilized! -- but more forward-looking we're tossing the idea around the
office of having a common protocol for such editor embedding, which we can
then use for other things:
* the contentEditable mode for WikiEditor
* the Ace syntax-highlighter in CodeEditor gadget
* experimental rich text editors etc
Some of Neil & my initial notes:
http://www.mediawiki.org/wiki/Future/Hackpad/Spec
The API between the host window and the (potentially offsite) iframe would
need to handle loading initial text, saving it, and some state checks at a
minimum; depending on how much we want to integrate the WikiEditor's toolbar
portion as a standard we may need to be able to let the toolbar control
things like selection and text insertion, or each editor variant could
manage its own toolbar and that could be a WikiEditor-specific protocol
part.
Thoughts?
-- brion
Hello,
Last year there where a lot of discussions about projects inside wikimedia
that needed to be renamed. The last thing I can remember is that it wasn't
possible at that time. However I would like to know if something changed
since the last discussion?
There are like 5 or 6 projects under discussion that /could/ be renamed, so
the question remains: Is it possible?
--
Kind regards,
Huib Laurens
WickedWay.nl
Hi.
Is there a status update about more regular code deployments to Wikimedia
wikis? I know it's been discussed endlessly, but I was under the impression
that it was a real goal going forward. Is that still the case?
MZMcBride
RE: http://www.mediawiki.org/wiki/Extension_talk:LiquidThreads
Let me talk about talk pages with Lqt.
The function to "drag to new location" a LiquidThread is not working for me.
Perhaps this is a browser issue ? I use Firefox current version 4.0.1 or
Chrome now and then or IE 8.0
Is there anyone out here, for whom this function really works?
Pls. can you then explain exactly, step-by-step, _/how/_ the function
actually works.
Dear all,
As of a member of Chinese Wikipedia community, we have submitted a bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=29114 on requestion for adding
LQT to Chinese Wikipedia. However, it seems that it is on hold. Due to a large
amount of comment on Chinese Wikipedia Village Pump, we need it as soon as
possible. When will it be enable? Or, need to wait for central action?
HW