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.
Nope, committers can continue doing what they do.
You should only notice a change if you try to commit
broken code :)
-Chad
On Nov 30, 2010 10:34 AM, "Krinkle" <krinklemail(a)gmail.com> wrote:
> On Tue, Nov 30, 2010 at 10:19 AM, Chad <innocentkiller(a)gmail.com>
> wrote:
>> On Tue, Nov 30, 20...
if/when this is enabled. Does this require anything from the commiters ?
Do I need to install something or run a command in addition to or
instead of 'svn commit -m "" ' ?
Sounds nice as an additional check :)
--
Krinkle
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello,
I am interested in developing an extension for handling molecular files
(files containing informations about chemical molecules : atoms, bonds,
...).
If I understand correctly it will enable me to display specific informations
in the File:... page, like what MediaWiki does for simple images.
Something like existing extensions (FlvHandler, OggHandler,
PagedTiffHandler, PNGHandler, TimedMediaHandler in SVN trunk for example).
I have read several pages on MediaWiki about writing extensions, but they
are not very detailed for media handler extensions.
I have also written an extension to display and interact with
molecules<http://wiki.jmol.org/index.php/Jmol_MediaWiki_Extension>,
but I still have several questions on how I can create a handler for
molecular files in MediaWiki.
Any help or links to some explanations will be appreciated.
Molecular files exist in several formats : pdb, cif, mol, xyz, cml, ...
Usually they are detected as simple MIME types (either text/plain or
application/xml) by MediaWiki and not as more precise types (even if this
types exist : chemical/x-pdb, chemical/x-xyz, ...).
It seems that to register a Media handler, I have to add an entry to
$wgMediaHandlers[] : $wgMediaHandler['text/plain'] = 'MolecularHandler';
Will it be a problem to use such a general MIME type to register the handler
? Especially for files of the same MIME type but that are not molecular
files ?
Are there some precautions to take into account ? (like letting an other
handler deal with the file if it's not a molecular file, ...)
I want to use the Jmol <http://www.jmol.org/> applet for displaying the
molecule in 3d, and allowing the user to manipulate it.
But the applet is about 1M in size, so it takes time to load the first time,
then to start and load the molecular file.
I would like to start showing a still image (generated on the server) and a
button to let the user decide when loading the applet if interested in.
Several questions for doing this with MediaWiki :
- What hook / event should I use to be able to add this content in the
File:... page ?
- Is there a way to start displaying the File:... page, compute the still
image in the background,and add it in the File:... page after ?
- Are there any good practices for doing this kind of things ?
Is it also possible to create thumbnails in articles if they include links
to a molecular file (like [[File:example.pdb]]) ?
What hook should I use ?
Is it possible to compute the thumbnail in the background ?
Any other advice for writing a media handler extension ?
Or other possibilities that could enhance the extension ?
Among the few handler extensions in SVN, which is the better example ?
Thanks for any help
Nico
> Message: 5
> Date: Wed, 24 Nov 2010 15:46:24 -0800
> From: Erik Moeller <erik(a)wikimedia.org>
> Subject: Re: [Wikitech-l] Commons ZIP file upload for admins
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <AANLkTimD7kXngs4azgPanR_84Ok_th9T1DsANc7stkSh(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> [Kicking this thread back to life, full-quoting below only for quick reference.]
>
> I've collected some additional notes on this here:
> http://commons.wikimedia.org/wiki/Commons:Restricted_uploads
>
> Would appreciate feedback & will circulate further in the Commons community.
>
> Thanks,
> Erik
Personally I think it would be nicer if you could associate source
files with the final files.
Something like:
*User uploads jpeg of 3D image (or whatever)
*on the image description page for the jpg, there is an upload
"source" file link
*Users (who have appropriate permissions) can upload the associated
source files with this link.
*These source files might appear as a subpage of the primary
image/document/media, or they might just appear in list form at the
bottom of the image description page of the main image/media. Either
way, the source files would be associated with a single "main" file.
Doing it this way would limit the feature to source files of actually
uploaded files (so less random cruft lying around, no orphaned source
files, less chance of people abusing the feature to get around file
type restrictions). I also personally don't like the idea of uploading
archives. Instead I think it would be better just to upload all the
source files needed. (although that might fall apart if you're
uploading source files for something very complex which has many
source files in a specific directory structure). There could also be a
download all option where all the source files get tar'ed together on
the server side for an easy download.
-bawolff
Hi everybody,
It's kind of silly when we commit php syntax errors to SVN
(I've done it too). Of course we should all test our code before
committing, but sometimes we don't--especially when it's a
one line change and there's No Way It Could Break.
To help us stop making these silly mistakes (and to avoid
the inevitable complaint and followup), I've added a pre-commit
hook to SVN.
All changed/added files ending in .inc/.php/.php5 are now
checked with php -l prior to the transaction completing. You
should get a fun error message on your local console if you
commit bad code :)
Let me know if you have any problems with it.
-Chad
Hey everyone,
Last week I've done some usability testing with my InlineEditor extension, to see whether or not it's a good idea at all. I've still got to do formal analysis, but that'll take a while, so for now I'll only share with you the most important things I noticed while doing the tests.
First, a few remarks. The test group was heavily biased towards students of Information Sciences, so towards above average intelligence and familiarity with codes and programming. There were 3 test groups, testing both versions of the editor (one where you can select an edit mode like "Sentences", "References", "Media", etc., and one where you can select "Sentences", "Paragraphs", "Sections") and a control group.
1. The editing of sentences was great the new way. Users were much more comfortable seeing the article and being able to directly manipulate it.
2. Users did not really notice the other editing options. This is a huge problem, as the whole idea of this editor is to show the user an increasing amount of wikitext complexity. When users did notice it...:
a. In the case of the functional edit options ("References", "Media", etc.), users used this more as a help center and then proceeded to the full (original) editor.
b. In the case of the block edit options ("Paragraphs", "Sections"), users used it correctly and found it helpful. This might indicate that this is the right way to go (which was my hypothesis), but it still has to be approached differently.
3. Users did actually like the idea of the interface, whether or not they could accomplish their tasks. Users noticed the edit summary field earlier and used it more often (although the test groups were too small to draw a formal conclusion from this).
In conclusion: users really liked the direct manipulation, but did not get the different edit modes. So, back to the drawing board! ;)
Full interview videos will be available on Wikimedia Commons somewhere next month. They are in Dutch, though.
You can try the editor with block edit options at http://janpaulposma.nl/sle/wiki. It's still work in progress: do expect to run into bugs that I did not find worthy to fix yet. :)
Best regards,
Jan Paul Posma
Hello alltogether,
is there any alternative way to get hands on a wikipedia dump?
Preferably the last complete one.
Which was supposed to be found at this address:
http://download.wikimedia.org/enwiki/20100130/
I would need that dump asap for my research.
Thank you for any help!
Best regards
—
Oliver Schmidt
PhD student
Nano Systems Biology Research Group
University of Ulster, School of Biomedical Sciences
Cromore Road, Coleraine BT52 1SA, Northern Ireland
T: +44 / (0)28 / 7032 3367
F: +44 / (0)28 / 7032 4375
E: schmidt-o1(a)email.ulster.ac.uk<mailto:schmidt-o1@email.ulster.ac.uk>
—
We had confused "uselang" and "variant" for a long time. until the releasing
of 1.16. But the distinction has introduced new problems to variants-enabled
language wiki. Now we can not convert the interface text even under the main
code (like *zh* for Chinese wiki). I plan to commit a patch to Language.php
and MessageCache.php but I'm not completely sure whether it would affect on
MediaWiki's message cache. Can somebody known message cache better than me
takes a "previous review" before I committed?
Philip Tzou