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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I've set up an NNTP gateway for Wikimedia mailing lists. The
"wikimedia.*" hierarchy is available via news.tcx.org.uk. More
information: <http://news.tcx.org.uk/wikimedia.html>.
Unlike GMane, this gateway does not rename lists (all lists are
wikimedia.<list name>), and does not munge email addresses inside posts,
which breaks PGP signatures.
However, posting via NNTP is not currently possible. (I expect to fix
this in a few days.)
Only a few lists are available right now, but if people find it useful,
I will add the rest of them (at least those with public archives).
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk1HLeEACgkQIXd7fCuc5vJFWwCeJvcsA+RSvgF8IXkRxxlk1q2r
t0oAn1ei8J9VqHfb/EUy7h1o8VWehE4r
=omjK
-----END PGP SIGNATURE-----
Hey all,
I've been working on the InlineEditor extension again, primarily working on a new interface that doesn't use the different edit modes anymore, as the usability testing showed that this was not the right approach. Luckily, without a change in the underlying algorithms, it was doable to combine all the edit modes into one interface. This also resulted in the deletion of tens of files plus hundreds of lines of code [1], which usually is a good thing, because it shows it's a simpler and more natural approach. If you're interested in testing this on your own wiki or looking at the code, grab your copy from SVN. [2]
If you're interested in testing this, a wiki has been set up here: http://janpaulposma.nl/sle/wiki As you might know, some more usability testing will be done soon by GRNET [3], so we can see if this interface works better or not. Feel free to ask questions and throw in suggestions, etc.
Best regards,
Jan Paul
[1] http://www.mediawiki.org/w/index.php?path=%2Ftrunk%2Fextensions%2FInlineEdi…
[2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/
[3] https://code.grnet.gr/projects/wikipedia-wysiwyg/wiki
For those of you who didn't see bug 26791, our use of JSMin has been
found to conflict with our GPL license. After assessing other options (
https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
decided to try and use the minification from JavaScriptPacker, but not
its overly clever but generally useless packing techniques. The result
is a minifier that outperforms our current minifier in both how quickly
it can minify data and how small the minified output is.
JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
code at about 2x the speed of Tim's optimized version of JSMin, and 4x
the speed of the next fastest PHP port of JSMin (which is generally
considered the standard distribution).
Similar to Tim's modified version of JSMin, we chose to retain vertical
whitespace by default. However we chose not to retain multiple
consecutive empty new lines, which are primarily seen where a large
comment block has been removed. We feel there is merit to the argument
that appx. 1% bloat is a reasonable price to pay for making it easier to
read production code, since leaving each statement on a line by itself
improves readability and users will be more likely to be able to report
problems that are actionable. We do not however find the preservation of
line numbers of any value, since in production mode most requests are
for many modules which are concatenated, making line numbers for most of
the code useless anyways.
This is a breakdown based on "ext.vector.simpleSearch"
* 3217 bytes (1300 compressed)
* 2178 bytes (944) after running it through the version of JSMin that
was in our repository. Tim modified JSMin to be faster and preserve line
numbers by leaving behind all vertical whitespace.
* 2160 bytes (938 compressed) after running it through
JavaScriptDistiller, which applies aggressive horizontal minification
plus collapsing multiple consecutive new lines into a single new line.
* 2077 bytes (923 compressed) after running it through
JavaScriptDistiller with the vertical space option set to true, which
applies aggressive horizontal minification as well as some basic
vertical minification. This option is activated through
$wgResourceLoaderMinifyJSVerticalSpace, which is false by default.
The code was committed in r80656.
- Trevor (and Roan)
An interesting idea just popped into my head, as a combination of my
explorations through the dom preprocessor and my attempt at deferring
editsection replacement till after parsing is done so that skins can
modify the markup used in an editsection link in a skin-specific way
without breaking things, and so that we can stop fragmenting the parser
cache by user language just for edit section links.
A postprocessor. It would be quite interesting if instead of html we
started outputting something like this in our parser output:
<root><html><p>foo</p><h2></html><editsection
page="Foo"
section="1">bar</editsection><html>bar</h2><p>baz</p><h2></html><choose><option><html><p>foo</p></html></option><option><html><p>bar</p></html></option><option><html><p>baz</p></html></option></choose></root>
((don't get scarred off by all the entities, this is nothing new, try
looking at a preprocess-xml cache entry))
Course this is a Postprocessor_DOM oriented look, like Preprocessor_Hash
we'd have a Postprocessor_Hash and it would store a different format
like we already do with Preprocessor_Hash (serialized?).
The idea being the creation of new markers that aren't 100% parsed but
are outputted in a easy to deserialize format and finish parsing with
minimal work and extensions can output and have a postprocessor hook
expand later on. In essence the idea here is two fold.
Firstly things like the <editsection page="Foo"
section="1">bar</editsection> I tried to introduce now is no longer a
hack. And we can try to start deferring minimal processing cost things
which fragment the parser cache if they aren't needed. Ideally in the
future if something like {{int:asdf}} isn't used in a [[]] or in a
parser function and is just a base level bit of display isolated from
the rest of the WikiText we might be able to output it in a way that we
don't have to fragment the cache by user lang but can still output the
message in the user's lang by deferring it.
And as a big extra bonus, think of the RandomSelection extension. Right
now extensions like RandomSelection end up disabling the entire parser
cache for a page, just so they can output a random one of a series of
options. With a postprocessor they could instead craft partially parsed
output where all the normal wikitext is still parsed, but all the
options given in the source text are outputted and the postprocessor
handles the actual random selection on each page view, only outputting
one of the three html nodes.
Likewise we might be able to implement "Welcome {{USERNAME}}!" without
fragmenting the cache by user or having to disable it.
The key being that we get things as variable as complete randomness, at
the level of re-executing that randomness on each page view, yet have
barely any more processing to do than we did before. (like the rest of
the ui that isn't part of the page content)
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hey,
Over the past year I've been working on an extension to facilitate parameter
handling in MediaWiki, with a focus on parser hooks. It's titled Validator
[0], which currently is a bit misleading since it enables a lot more then
simple validation. As the only thing this extension does is facilitate
parameter handling in other extensions, I think it makes sense to include it
into core, or at least in the default MediaWiki distribution.
I created this extension out of frustration as an extension developer that
to create a parser hook, you need to do the same plumbing over and over
again, and have to write a whole mess of parsing and validation code that is
similar for almost every parser hook. Of course this is doable, but it's
error prone, causes small differences in how exactly parameters are handled
in different parser hooks (not very nice for the end users), and is hard to
maintain. If you have done this a few times, it becomes rather obvious that
a more generic framework to handle parameters would be a big win. You want
to describe a parameter, not all the details of how it should be handled.
Using Validator is somewhat similar to how API classes and their
getParameters methods work, but more powerful and extendible. A parser hook
can be created by deriving from the ParserHook class added by Validator, and
implementing or overriding some methods to specify the name, aliases (if
any), parameters (and all their meta data) and actual handling function of
the parser hook. This last method gets called with a list of all parameters
handled by Validator, and in most cases won't need any extra work. This
ParserHook class is just a wrapper around creating parser functions and tag
extensions and using the actual validation class of validator. You can
directly handle parameters using the Validator class. A nice example of
ParserHook usage can be found in the SubPageList extension [1]. The Maps and
Semantic Maps extensions also use Validator, and contain more complex
examples (with parameters dependent on others, ect) that implement the
display_map and display_points parser hooks [2].
Putting this functionality in core would be a big help to everyone writing
new parameter handling code, and would enable cleaning up existing
implementations where this is desired. As this functionality does not
replace anything in core, putting it in would not disrupt anything. I'm
willing to do the little work required to merge Validator into core.
I could just do that right now of course, but I'm quite sure some people
would object to that. So can these people please respond to this email in
some constructive manner, so this request does not simply get ignored for no
good reason?
[0]
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:Validator
[1]
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:SubPageList
[2]
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/includes/pa…
Cheers
--
Jeroen De Dauw
http://blog.bn2vs.com
Don't panic. Don't be evil.
--
Right now in the skins system (if you consider vector part of the skins
system) we have two parallel methods of adding tabs to the page:
- Into content_actions via SkinTemplateTabs,
SkinTemplateBuildContentActionUrlsAfterSpecialPage, and
SkinTemplateContentActions,
- Into vector's navigation_urls via SkinTemplateNavigation (the missing
two hooks should be added)
The only important difference between these (besides some vector
specific stuff that can stay in vector) is that content_actions is a
flat array, and navigation_urls is an array of arrays organized into
categories. Besides that, they are basically mirrors of each other with
the same functional purpose, but you need to add tabs to both of them to
avoid something not showing up in vector. There's also the misfortune
that other skins can't take advantage of the organized navigation_urls
because the actual implementation (which is basically a reimplementation
of buildContentActionUrls with code duplication) without being a vector
subskin because the code in question is inside of vector.
Right now we have extensions using both methods of adding tabs to the
page, code duplication on their part. And a few extensions that are
broken in vector because they haven't added the hooks.
Doing a quick grep, it appears the following extensions are missing
vector support: Oversight, CommentPages, Todo, WikiTrust, Tasks,
CategoryTree, DeleteQueue, Wikidata, Imagetabs, purgetab, Tab0,
AuthorProtect, TidyTab, Purge, SpecialTalk
Shouldn't be to hard to fix, especially if we fix the bug of missing
hooks for navigation_urls.
Now onto my focal point. As I've been improving the skin system trying
to pull out the thorns that make building skins troublesome and mesh in
new features and helpers which are missing, I'd like to remove the
content_actions hooks and deprecate content_actions in 1.18 and start
using navigation_urls style data everywhere.
Since content_actions and navigation_urls are the same, content_actions
can be built by having SkinTemplate take the navigation_urls data and
flatten it into a single array. Similarly to how I already have
$wgFooterIcons work and fold it for some skins like Monobook which don't
organize it the way vector does.
The effects will be like this:
- The three content_actions related hooks will no longer work in 1.18,
thus extensions that haven't started supporting vector tabs will also
stop showing tabs in other skins
- In their place extensions will use 3 navigation_urls related hooks
(most extensions are already using the one hook available)
- Extension code for those already using both forms of hooks will stay
the same, the only difference being that 1.18 will use the
navigation_urls related hooks and the content_actions related ones will
become redundant code which the extensions can keep for back compat but
drop once they stop supporting pre-1.18 installations
- All standard skins will be using navigation_url based data and
content_actions will be available but deprecated
- 3rd party skins will still function using content_actions but it would
be preferred for them to be updated to use the new BaseTemplate and use
the helpers in there (a navigation_urls related one would be added) once
they don't need to support pre-1.18
- SkinTemplatePreventOtherActiveTabs will probably still work, though I
may want to find a cleaner method to transition to (ie: one that says
"this is the active tab" rather than "don't make other tabs active").
Any comments, rejections?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
A little bug i reported to Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=629878
This happens in Wikipedia and Wordpress, but not in GMail, so it may
interest MediaWiki developers.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
"We're living in pieces,
I want to live in peace." - T. Moore
In JavaScriptDistiller, inside of the createParser() function, we have:
$parser->add( '/\\/\\*(.|[\\r\\n])*?\\*\\//' );
It took me hours to track down that this was causing Apache 2.1.11 to crash
on nearly any page view on my test wiki. This happened when a large JS
bundle is loaded, such as:
load.php?debug=false&lang=en&modules=jquery.checkboxShiftClick|jquery.client|jquery.cookie|jquery.makeCollapsible|jquery.placeholder|mediawiki.action.watch.ajax|mediawiki.language|mediawiki.legacy.ajax|mediawiki.legacy.diff|mediawiki.legacy.mwsuggest|mediawiki.legacy.wikibits|mediawiki.util&skin=vector&version=20110129T005517Z
I made a simple php file to reproduce this. It crashes when viewed over
apache but not CLI. It appears to be http://bugs.php.net/bug.php?id=47689
(which uses a similar regex).
Is something worth adding a note somewhere about or tweaking some code?
--
View this message in context: http://old.nabble.com/ResourceLoader-%2B-Windows-%2B-PHP-bug-47689-tp307922…
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
Wikimedia Commons and the English Wikipedia have customized their site-wide
CSS to put a checkered pattern on the transparent part of files on the file
description page.
Because I view this code as almost necessary on any wiki that supports
uploading PNGs, I filed a bug about including it in the default site-wide
CSS: https://bugzilla.wikimedia.org/show_bug.cgi?id=26470
There's definitely missing functionality here. On wikis that don't use a
checkered background, a lot of users end up downloading the images to their
computer to look at them in order to determine if a background is white or
transparent. That sucks.
There was previous discussion about this, but more discussion is needed,
apparently. Is site-wide CSS the best way to do this? Would a toggle on the
file description page make more sense? User preference?
MZMcBride