Hello there,
I've just subscribed to this list. I'm already on Foundation-l and the
mailing list for Wikimedia UK. I've joined here as I am hoping to get
some technical insights and ask a few questions as a result of my
participation in the Strategy process.
But before I do that I have some newbie questions:
Is there a FAQ for this mailing list?
Can I assume the WMF staff tech team [1] is subscribed to this list?
[1] http://wikimediafoundation.org/wiki/Staff
Regards,
User:Bodnotbod (on en:wp)
Hi everyone im a novice in MediaWiki. Does anyone know how to create those
boxes on the index page?
For example on the MediaWiki main page it has the boxes :
- welcome
- users
- system administrators
- news
- etc
How does one create those boxes?
Looking forward to any feedback.
Thanks
Hello and thanks for the feedback!
so to "package" urls like so
site.net/<namespace>/<title[/subpage][?params]
there are two parts that need to be done:
1) have MW somehow respond to these urls
2) output urls in that format
For 1) it can be done either by
(a) modifying MW url processor and
(b) - by rewrite rules - not sure here how to handle a case of no
namespace
- I guess that with no namespace it will be maybe simpler to insert
"main" namespace explicitly
For 2) you'll either have to
(a) post-process all MW output through some filter outside MW
(b) modify the "url renderer" inside MW
Where should I look inside MW code to find incoming url parser and url
renderer?
I'll appreciate any suggestions, will post a patch on github too.
Evgeny.
Hello,
here is what I would like to accomplish:
somesite.net/<namespace>/<page_name[/subpage]>[?optional parameters]
Is there a way to achieve that?
Thank you and best regards,
Evgeny.
Michael Dale, Tim Starling and I have been planning the integration of
the things being done of the js2-work branch into phase3. Michael and I
today discussed some of the changes we are looking to make, and we
wanted to make contact with stakeholders about them.
* Create a new folder: "phase3/static/"
* Move "js2-work/js/" to "phase3/static/js".
* Move the PHP portions of the 'js2-work/js/mwEmbed/" resources to
their appropriate MediaWiki locations such as
"phase3/includes/scriptloader/" and "phase3/maintenance"
* Move JavaScript files in "phase3/skins/common/" into
"phase3/static/js/"
* Move CSS files in "phase3/skins/common/" into "phase3/static/css/"
* Move image files in "phase3/skins/common/" into
"phase3/static/images/"
The resulting structure will look like...
* phase3/static/
* css/ -- Gerenally shared CSS files
* images/ -- Generally shared image files
* js/ -- MediaWiki Core JavaScript files, jQuery, jQuery UI,
additional JavaScript modules (Purely JavaScript extensions),
ScriptLoader support code
Overall, we're just moving things where we see they should be.
Justifications for moving the skins/common/* stuff to their own places
is basically that "skins/common/" is a strange place for resources which
are used mostly by non-skin software and it fits more with the current
bits.wikimedia.org approach.
Please try and keep responses concise, productive and on-topic. (i.e
discussions about how wikibts will change can be left for another thread)
- Trevor
I'm experimenting with converting the MediaWiki SVN repository to Git.
To do that properly commits need to be rewritten to turn SVN commiter
ID's like "avar" into name/email pairs like "Ævar Arnfjörð
Bjarmason"/"avarab(a)gmail.com".
We have a USERINFO directory in SVN that keeps metadata for commiters,
unfortunately it's far from complete. Out of around 250 commiters only
132 have valid USERINFO data at all, and some of the users that do
have data are missing a name, email or both. Those are:
Users with no name: key:
bawolff filnik huji nikerabbit overlordq robin soxred93 sql thomasv
Users with no email: key:
a_engels aaron allyunion cydeweys danny_b filnik gerrit hooft huji
j jasonr jhb lrbabe misza13 mulligen quistnix rikwade russblau sanbeg
straussd valhallasw warddr wikipedian
And finally, users with no info at all:
aboostani adam adammck adhair ajvol alnokta angelab aoineko_jp
axelboldt bartek beckr bradneuberg b_stancescu chrisseaton
christianlist danenberg diana dschwen e23 eflebeth egilk eloquence
emiller evanprodromou ezachte fredck fvassard gabrielwicke gmaxwell
greenreaper gri6507 harddisk hidders ilyah imsop jeronim jitseniesen
jonwilliford jostrow karstenuil kateturner kelson42 kipcool knutux
lcrocker looxix luca lupin lupin-wp maarten magnus_manske maikmerten
malvineous markcdeckert markj marumari matjordan mej millosh
minuteelectron nicdumz nimishg (no author) nojhan npassoc oggk op_kai
platonides proes robh rodasmith root ryo_saeba shaihulud shaneking
sj_kissane skierpage smurf-wiki stipe strainu tarquindarkling taw
timwi tomgilder tparscal uid23179 urichj00 wmahan zhengzhu zilche
If you're one of the guilty or know the contact info for them please
add it to USERINFO/
For the curious this is the tool that did the analysis:
http://github.com/avar/mediawiki-userinfo
Hi again,
http://project2.wikimedia.org:3000
Here's an instance of Redmine for y'all to try out. It has data migrated
from bugzilla.wikimedia.org, but is a few weeks old.
The Bugzilla users were migrated, but you will have to use the Lost
Password link to reset your password:
http://project2.wikimedia.org:3000/account/lost_password
For now, all users are members of all projects and all users are Editors
on MediaWiki and Wikimedia.
Somewhere along the multiple imports and migrations I did with the data,
I must have use a bad database characterset so some of the names show up
as ???. Please edit your name if you see that.
If you want to be an admin or want any additional permissions, email me
off list.
I am aware that this RoR instance is having performance issues, I am
looking around to see if there are ways to configure it to make it faster.
Enjoy
-p
--
Priyanka Dhanda
Code Maintenance Engineer
Wikimedia Foundation
http://wikimediafoundation.org
San Francisco, CA
I've created a branch for MediaWiki 1.16, and updated the version
numbers in trunk to 1.17alpha.
This does NOT mean that the 1.16 branch is stable and ready for
general use. It is still in alpha. I have created it because I was
getting tired of chasing the ever-receding target that is HEAD. Now
that we are branched, if the schedule has to slip again, it will just
mean less features, rather than more time reviewing new features.
In the current state, it will take at least a week to get 1.16
stabilised enough to do a beta release.
During this pre-release period, everyone who commits fixes of
significant bugs should also backport them to the 1.16 branch, if that
branch is affected. This might be a nuisance, but I don't think it's
unreasonable. It's in line with the way most other open source
projects work, and we had a similar period before the release of 1.15.
At this stage, you do not need to ask for approval to backport
something to 1.16.
This is not the time to merge all your unreviewed experimental work
into trunk. I'd like the merges to be done progressively, in priority
order, so that our reviewers can keep up with them. That way, we can
limit the amount of unstable code in HEAD, and keep trunk usable.
I'm open to suggestions about priority, but I think the simpler
branches (platonides, conrad) should be done before the more complex
branches (SkinSystemRewrite, parser-work).
-- Tim Starling