A few new committers in the past few weeks:
* Ben Hartshorne (ben), Wikimedia Foundation staffer (operations engineer)
* John du Hart (johnduhart), working on API, CodeReview, UDP,
ResourceLoader, and more
* Also, I think we never welcomed Katie Horn (khorn) when she got commit
access in June. She's a Wikimedia Foundation staffer, a software
engineer in community R&D.
Welcome, all! :-)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Thought I should resend this after subscribing to the list.
In the mean time, I came up with another feature request, it would be
good if there were an '[edit]' link for each tab somewhere (in the tab
or in the text below).
On 20 August 2011 22:16, Dan Bolser <dan.bolser(a)gmail.com> wrote:
> Hi,
>
> The headertabs extension [1] told me to email here if I needed
> support, and since I don't see it listed on mediazilla, I thought I'd
> email my feature request here too:
>
> Currently #switchtablink works great, but it would be nice if it also
> jumped to an anchor point at the top of the tabs. If my tabs are a
> little way down the page, when using #switchtablink, I expect to not
> only change to the right tab, but also to jump to the right place in
> the page.
>
> In an extreme example, I may construct some links like this at the top
> of the page:
>
> * Firstly, ... See the {{#switchtablink:x|x tab (below)}}.
> * Secondly, ... See the {{#switchtablink:y|y tab (below)}}.
>
> A few more paragraphs here...
>
> =x=
> ...
>
> =y=
> ...
>
>
> In this case, the user may think the link is broken, if the tabbed
> section starts off the bottom of the screen. Clicking the links may
> have no apparent effect, because the switching is happening lower down
> in the document.
>
> I can't see a good reason for not creating an anchor where the tabs
> start and jumping to it when using #switchtablink.
>
>
> Cheers,
> Dan.
>
> [1] http://www.mediawiki.org/wiki/Extension:Header_Tabs
>
Hey,
I'm wondering if there are any concrete plans for dropping PHP 5.2.x support
in MediaWiki. Support for these versions of PHP has been discontinued by the
PHP people a few months back, and it'll take another while before the next
MediaWiki version (1.20) hits it's release anyway. So my vote goes for
dropping support for pre 5.3 in MW 1.20, if not already planned. Then we can
finally make use of the new things introduced in 5.3, which in some cases
are really useful and right now a complete pain to implement.
Any objections or thoughts on this?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Have been in discussion with the owner of MedPix Dr. James G.
Smirniotopoulos about the possibility of collaboration. One idea we
have been discussing is the possibility to update his site such that
image uploaders have the open of releasing images under a Creative
Commons 3.0 license and if they do they would be simultaneously added
to Wikipedia. He does the programming himself for the site. I am
wondering if there is anyone who can help him with this? His website
can be found here http://rad.usuhs.edu/medpix/ He can be reached at
james-smirnio at usuhs dot mil
--
James Heilman, MD, CCFP(EM)
Wikipedian, Wikimedia Canada
On wikimedia projects that are not Wikipedia (Wikia in specific comes
to mind) I often find myself using templates that have not been
defined on that installation. The English Wikipedia (which I am most
familiar with) has many very usefull templates, especially the
{{citeFoo}} templates, but numerous others as well. Trying to 'import'
one is a bit of a pain though. Many templates depend on other
templates, and it is not often very clear how (as a fun exercise for
the reader, try to import the {{convert}} template to a new wiki, and
see how easy it is!). I was wondering if it might be a good idea to
include a standard template library to Wikimedia installations,
containing a set of utility templates along with the Wikimedia
distribution. I'm cross-posting foudation, for possible discussion if
this is desirable, and wikitech, for possible discussion if this is
feasable.
I've been doing some code review today, and updated the revision
report at https://secure.wikimedia.org/wikipedia/mediawiki/wiki/MediaWiki_roadmap/1.1…
. The number of new revs in 1.18 dropped to 92 today, the first time
it's below 100. Yay!
A side effect of reviewing code, though, is that the number of fixmes
increases. We now have 64 fixme's in 1.18. The 1.18 wall of shame is:
platonides: 6
purodha, reedy, tstarling: 5
diebuche: 4
bawolff, freakolowsky, hashar, maxsem, mgrabovsky, robin, tparscal: 3
catrope, happy-melon, werdna: 2
aaron, btongminh, demon, hartman, hcatlin, ialex, mah, neilk, nimishg,
preilly, wikinaut, yaron: 1
So please address your fixme's, people!
Another call to action is for reviewers who have new revisions assigned to them:
nikerabbit: 10
krinkle: 6
brion: 3
tim: 4
trevor: 2
chad: 1
neil: 1
Revision lists for assigned revs and fixme's are on the revision report.
Roan
If you live in Europe and you'd like to help improve MediaWiki's support
for Postgres, please submit a talk about it to the PostgreSQL Conference
Europe. I'll help you write the proposal, if you need help. Call for
proposals: http://2011.pgconf.eu/callforpapers/
The deadline's on 21 August, 2 days from now. I've copied most of the
CfP below.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
PostgreSQL Conference Europe 2011 will be held on October 18-21 in the
Casa 400 Hotel in Amsterdam, The Netherlands. It will cover topics for
PostgreSQL users, developers and contributors, as well as decision and
policy makers. For more information about the conference, please see the
website at http://2011.pgconf.eu/.
We are now accepting proposals for talks. Please note that we are
looking for talks in English, Dutch, German and French.
Each session will last 45 minutes, and may be on any topic related to
PostgreSQL. Suggested topic areas include:
* Developing applications for PostgreSQL
* Administering large scale PostgreSQL installations
* Case studies and/or success stories of PostgreSQL deployments
* PostgreSQL tools and utilities
* PostgreSQL hacking
* Community & user groups
* Tuning the server
* Migrating from other systems
* Scaling/replication
* Benchmarking & hardware
* PostgreSQL related products
Of course, we're happy to receive proposals for talks on other
PostgreSQL related topics as well.
We also have a limited number of longer, 90-minute, slots available.
Please indicate clearly in your submission if you wish to make a
90-minute talk.
Finally, there will be a session of five minute lightning talks. A
separate call for proposals will be made for them further on.
The submission deadline is August 21st, 2011. Selected speakers will be
notified before Sep 5th, 2011.
Hello!
As many of you probably know, during last weeks (and also a lot of
time in 2009 and 2010) I have been working on the WikiScripts
extension (formerly InlineScripts), which allows to embed scripts into
pages.
The language it uses, as well as the instruction of how to use it, are
here: <http://www.mediawiki.org/wiki/Extension:WikiScripts>. Any clean
up of the docs would be appreciated.
(the rest of the mail probably should be read after reading the
documentation; right now it's short, because I'm lazy!)
The reason why we want our own language at all:
* Code maintainability. Right now we have horrible templates like the
legendary {{Citation/core}} nobody can really understand.
* I personally hope that it will be more performance-wise and easier
to optimize (due to fact that it has pretty straightforward
context-free grammar).
* It allows us to increase potential complexity of the code,
introducing things like string functions
The reason why we use our own language is:
* We can restrict is as we want (for example, the for( ; ; )
instruction is not present);
* We can make it platform-independent since it is written in PHP
* Based on some experience with writing those scripts and my generic
experience as well, I have added some nice features absent from
different languages, mainly the append keyword (see docs).
The reason why from InlineScripts it was changed to non-inline model:
* This is the only way we can adequately implement functions.
Previously I wanted to implement them as calling another template
directly from script, but parser overhaul seems useless, and this way
we have a better control over it.
* We can add syntax highlighting
* We can add the code editor
* It is easier to track inclusions that way
* Greater potential for global scripts
== The plan ==
Right now the extension is almost ready. There are certain features I
would like to see there (some are listed below), but no
backwards-incompatible dramatic changes. However, you may want to make
them, so here is my plan
1. We settle down all issues we will not be able to change later due
to b/c. I made a list of some below, you may want to add more. Before
we settle them, we cannot move further.
2. At this point I want someone at WMF review the language description
and make sure it is OK with them.
3. Once the details are settled, we may start doing
internationalization, documentation, cleanup and testing.
4. Probably some live test deployment here.
5. ???
6. PROFIT. WMF-wide deployment here.
== The questions ==
Here are some questions I found worth discussing. We need to discuss
them before we move on:
1. Case sensitivity. Right now the language is case-sensitive. We may
want to change that, since case-insensitivity is more user-friendly.
2. Transclusion from wikitext. I have added two hooks ({{#invoke:}}
and {{s:}}) and will probably add two more for global scripts
({{#globalinvoke:}} and {{g:}}). Any better ideas for hook names are
welcome.
3. Library. Right now I developed a set of conventions in order to
make the function naming more consistent and modular (with ability to
add new modules by extension).
4. Your question here.
== Stability and performance ==
Right now my benchmarking shows that a simple template which uses
{{#switch}} is as effective as a simple module using associated
arrays. You may benchmark yourself and put the results on the wiki. If
we find the problems with performance on the real use cases during
live trial (or before, or after), we have a lot possible performance
tweaks, including:
* Function output caching;
* Built-in optimizer;
* Separate cache for scripts (there aren't as many as templates), in
order to increase hit rate;
* Rewrite of parser in C;
* Rewrite of whole interpreter in C (probably not necessary, 50% to
75% of time is parsing);
* Rewrite of whole MediaWiki in <s>Python</s><s>C</s> HipHop-compatible PHP!
As of stability, we have built-in platform-independent limits (like
evaluation count) and most of insecure features (recursion, infinite
loops) are disabled (you can still make a deep nested loop, but you
better write the scripts as if Domas knew where you live).
== Future ==
Some possible future tweaks:
* switch construction
* Built-in code editor (with highlighting and auto-ident)
* AJAX-based debugging stuff right in the edit form (syntax check,
calling the function from the edit form instead of preview, etc).
* Global scripts! That would be (probably) easier than global
templates; the only tricky part would be tracking changes and
invalidating local caches.
* Your suggestion submitted here:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
--vvv