Wikitech-l November 2010

wikitech-l@lists.wikimedia.org

88 participants
67 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

Re: [Wikitech-l] No more syntax errors!
by Chad 02 Dec '10

02 Dec '10

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

3 3

Creating a Media handler extension for molecular files ?
by Nicolas Vervelle 01 Dec '10

01 Dec '10

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

3 5

Re: [Wikitech-l] Commons ZIP file upload for admins
by bawolff 01 Dec '10

01 Dec '10

> 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

8 14

No more syntax errors!
by Chad 30 Nov '10

30 Nov '10

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

7 12

InlineEditor / Sentence-Level Editing: usability review
by Jan Paul Posma 30 Nov '10

30 Nov '10

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

4 4

alternative way to get wikipedia dump while server is down
by Oliver Schmidt 30 Nov '10

30 Nov '10

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> —

9 12

A proposal to convert interface language when use main code
by Philip Tzou 29 Nov '10

29 Nov '10

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

2 4

Bugzilla Weekly Report
by reporter 29 Nov '10

29 Nov '10

MediaWiki Bugzilla Report for November 22, 2010 - November 29, 2010 Status changes this week Bugs NEW : 140 Bugs ASSIGNED : 6 Bugs REOPENED : 19 Bugs RESOLVED : 88 Total bugs still open: 5210 Resolutions for the week: Bugs marked FIXED : 73 Bugs marked REMIND : 0 Bugs marked INVALID : 7 Bugs marked DUPLICATE : 10 Bugs marked WONTFIX : 4 Bugs marked WORKSFORME : 3 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component UploadWizard 25 Site requests 7 CodeReview 5 Maintenance scripts 3 General/Unknown 3 New Bugs Per Product MediaWiki 21 Wikimedia 11 MediaWiki extensions 39 Wikipedia Mobile 1 Top 5 Bug Resolvers neilk [AT] wikimedia.org 15 jeluf [AT] gmx.de 10 JSchulz_4587 [AT] msn.com 10 hcatlin [AT] wikimedia.org 6 sam [AT] reedyboy.net 6

1 0

Categories and interlanguage links not displaying at diff preview
by lampak 28 Nov '10

28 Nov '10

The problem occurs at least on Polish and German Wikipedias. When viewing a diff, categories and interlanguage links are not displayed in the article preview below the diff. See [1] for an example. According to the guys reporting it at the Polish village pump ([2]), the issue appeared a few days ago and might have coincided with the recent FlaggedRevs update. Could you have a look at it? Thanks in advance, lampak [1] http://pl.wikipedia.org/w/index.php?title=Wikipedia&diff=23986220&oldid=239… [2] http://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Podgl.…

1 0

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 November 2010