Yesterday, the selection of GSoC projects was officially announced.
For MediaWiki, the following projects have been accepted:
* Niklas Laxström (Nikerabbit), mentored by Siebrand, will be working
on improving localization and internationalization in MediaWiki, as
well as improving the Translate extension used on translatewiki.net
* Zhe Wu, mentored by Aryeh Gregor (Simetrical), will be building a
thumbnailing daemon, so image manipulation won't have to happen on the
Apache servers any more
* Jeroen de Dauw, mentored by Yaron Koren, will be improving the
Semantic Layers extension and merging it into the Semantic Google Maps
extension
* Gerardo Antonio Cabero, mentored by Michael Dale (mdale), will be
improving the Cortado applet for video playback (I'm a bit fuzzy on
the details for this one)
The official list with links to (parts of) the proposals can be found
at the Google website [1]; lists for other organizations can be
reached through the list of participating organizations [2].
The next event on the GSoC timeline [3] is the community bonding
period [4], during which the students are supposed to get to know
their mentors and the community. This period lasts until May 23rd,
when the students actually begin coding.
Starting now and continuing at least until the end of GSoC in August,
you will probably see and hear from the students on IRC and the
mailing lists and hear about the projects they're working on. To
repeat the crux of an earlier thread on this list [5]: be nice to
these special newcomers, make them feel welcome and comfortable, and
try not to bite them :)
To the mentors and students: have fun!
Roan Kattouw (Catrope)
[1] http://socghop.appspot.com/org/home/google/gsoc2009/wikimedia
[2] http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
[3] http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline
[4] http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-community-bo…
[5] http://lists.wikimedia.org/pipermail/wikitech-l/2009-March/041964.html
Dear open source contributors,
I am Eunyoung Chung, a Masters student working with Dr. Jensen at
Oregon State University.
We are currently doing a research project in collaboration with Dr.
Truong and Ph.D student Koji Yatani at University of Toronto. Our goal
is to understand how contributors communicate and collaborate in Open
Source Software (OSS) projects, including diagramming practices.
We are seeking volunteers for a quick survey on this topic. Any person
who is actively working on a OSS project is eligible. The survey takes
approximately 10-15 minutes, and the 5 volunteers will be picked to
receive a $30 Amazon gift certificate. Your participation is anonymous
(unless you consent to have us contact you)
Here is the survey address.
https://secure.engr.oregonstate.edu/limesurvey/58564/lang-en
We really appreciate your help!
I've branch-merged the new preferences system that I've spent the last
few weeks developing.
On the outside, you probably won't notice any difference except a few
bugfixes, but the internals have undergone a complete rewrite.
All of the actual preference definitions and utility functions have
been separated out into Preferences.php, which holds all business
logic for the new system. The UI and submission logic for the system
is done in SpecialPreferences.php, which, now only a hundred lines
long, wraps a generic class I've written to encourage separation of
business and UI logic called 'HTMLForm'.
The advantage of this clear separation is that writing an API module
is very simple, and it can be called internally, too!
Extensions must now hook GetPreferences instead of the existing hooks
(which were too low-level to maintain compatibility with), I've
updated all extensions used on Wikimedia. This new hook allows you to
put preferences wherever you want, and a new preference can be added
in less than ten lines of code, rather than the hundred-line nightmare
that was required in the previous iteration.
I'd like to look towards trimming some of the existing preferences
that are no longer relevant, and adding new preferences as common
sense dictates.
Feedback, praise and criticism regarding the changes is certainly welcome!
--
Andrew Garrett
Sent from Sydney, Nsw, Australia
All true. The images should not be rethumb'd unless
resolution changes, a new version is uploaded, or the
cache is otherwise purged. However, on initial rendering,
the thumb generation can be a large part (especially if
rendering multiple images) of overall page execution time.
Being able to offload this elsewhere should decrease
that load greatly.
-Chad
On Apr 24, 2009 1:23 PM, "Roan Kattouw" <roan.kattouw(a)gmail.com> wrote:
2009/4/24 Aryeh Gregor
<Simetrical+wikilist(a)gmail.com<Simetrical%2Bwikilist(a)gmail.com>
>:
> How long does it take to thumbnail a typical image, though? Even a >
parser cache hit (but Squid ...
The problem here seems to be that thumbnail generation times vary a
lot, based on format and size of the original image. It could be 10 ms
for one image and 10 s for another, who knows.
> Moreover, in MediaWiki's case specifically, *very* few requests should >
actually require the thu...
That's true, we're already doing that.
> So it's not a good case to optimize > for.
AFAICT this isn't about optimization, it's about not bogging down the
Apache that has the misfortune of getting the first request to thumb a
huge image (but having a dedicated server for that instead), and about
not letting the associated user wait for ages. Even worse, requests
that thumb very large images could hit the 30s execution limit and
fail, which means those thumbs will never be generated but every user
requesting it will have a request last for 30s and time out.
Roan Kattouw (Catrope)
_______________________________________________ Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia....
Hi,
I think this event will be of great interest and relevance to a number
of MediaWiki developers. I hope we can have a significant presence at
this year's event, as compared to the first one in 2007
(<http://www.aspirationtech.org/events/opentranslation>).
cheers
Brianna
---------- Forwarded message ----------
From: Allen Gunn <gunner(a)aspirationtech.org>
Date: 2009/4/23
Subject: [opentranslation] OTT09: Call for Participants!
To: Open Translation Tools Discussion List
<opentranslation(a)lists.aspirationtech.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey friends,
We'll be doing broader announcements later this week, but I just wanted
to let folks know that we're ready to know who's coming to Amsterdam in
June!
Please spread the word on all fronts! Blog it, tweet it, etc!
http://aspirationtech.org/events/opentranslation/2009
peace,
gunner
- --
Allen Gunn
Executive Director, Aspiration
+1.415.216.7252
www.aspirationtech.org
Aspiration: "Better Tools for a Better World"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknwFVoACgkQTGSEj6og3Pd+iwCfcCjiGZSs0l2QAABL8Qihx+c/
aFwAn2englpVKCSKAhYF2B/Do1Tb9JU5
=iFhC
-----END PGP SIGNATURE-----
____________________________________________________________
You received this message as a subscriber on the list:
opentranslation(a)lists.aspirationtech.org
To be removed from the list, send any message to:
opentranslation-unsubscribe(a)lists.aspirationtech.org
For all list information and functions, see:
http://lists.aspirationtech.org/lists/info/opentranslation
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Cezary Kluczyński (ruiz): FramedVideo and VideoGallery extensions.
FramedVideo was committed by Siebrand and needs to be maintained, I've
sent Cezary a review of it.
-- Tim Starling
Just a heads-up --
Michael Dale is working on some cleanup of how the various JavaScript
bits are loaded by the skins to centralize some of the currently
horridly spread-out code and make it easier to integrate in a
centralized loader so we can serve more JS together in a single
compressed request.
Unless there's a strong objection I'd be very happy for this to also
include loading up the jQuery core library as a standard component.
The minified jQuery core is 19k gzipped, and can simplify other JS code
significantly so we can likely chop down wikibits.js, mwsuggest.js, and
the site-customized Monobook.js files by a large margin for a net savings.
If you've done browser-side JavaScript development without jQuery and
wanted to kill yourself, I highly recommend you try jQuery -- it's
sooooo nice. :)
-- brion
I don't edit as much as I did in years past, and my memory is obviously
feeble, as I find that I'm often making mistakes with subst'ing.
Worse, the explosion of parser functions has made the templates incredibly
complex. Subst'ing is increasingly less "user friendly".
It's hard to document ("subst" doesn't seem to translate well or mean
anything to many folks), harder to remember, and hardest to type:
{{subst:TEMPLATE|P1|P2|subst=subst:}}
I'm often forgetting that final parameter, and conscientiously have to edit
again. Others don't bother subst'ing at all!
Is there a solution proposed anywhere already?
===
If not, here's my rough idea:
Leading {{:: -- easy to type (already holding the shift key) -- same as
{{subst: -- only happens in edit parsing, no change to database.
Leading {{## -- easy to type (already holding the shift key) -- obviously
must be different than {{:: -- used inside templates, tells the edit
parsing to "subst:" only subst'ing, otherwise ignored and treated as
concatenation. Same as C pre-processing operator.
Are these already in use?
Would be a heck of a lot easier to document....
I'm building an application that uses DifferenceEngine.php to generate
word level unified diffs. I've figured out how to do this but now need
to generate patches given the diff.
This is what I have written to generate the diff:
$orig = array('One Two Three', 'One Two Three');
$closing = array('One Two Three', 'One Two Four');
$diff = new WordLevelDiff($orig, $closing);
$formatter = new UnifiedDiffFormatter();
echo $formatter->format($diff);
Which returns:
@@ -5,3 +5,3 @@
One
Two
- Three
+ Four
So my application will store this and when it comes to time to patch
that diff, I need a function that will do that, i.e. given the diff
string above and $orig, it should generate $closing.
Does such a patch functionality exist in MediaWiki, or anywhere else?
I'm using PHP and am aware of the xdiff extension but it doesn't
support word-level-diff, only line-level. And I can't install it
anyway.