Freako F. Freakolowsky wrote:
> I think it would be about time to start practicing what we preach (like,
> that MW is a great knowlagebase tool) and move all these comments to
> mw.org database manual pages.
> It's handy to have all those comments in the code, but to clutter the
> schema abstraction code over those comments is just silly.
You want them out of the code entirely, or only in once place (e.g.
the mediawiki.schema file)? I'm all for the latter, especially as we
can also automate the updating of the MW pages once we have a sane,
machine-parseable schema in place.
Jeremy Postlethwaite wrote:
>> I'm open to using something existing: did you have something
>> specific in mind? I didn't see anything out there that would
>> be less trouble to customize than rolling our own.
>
> Doctrine does versioning of databases in PHP:
>
> http://www.doctrine-project.org/
Yeah, it is interesting, but severe overkill for what we are
looking at here. I'm also loath to add another dependency, which
I'm sure at the end of the day we are going to have to
[monkey] patch anyway.
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
Hi,
Are there any statistics about the number of visitors that go from
Wikipedia to different websites linked with external links? We've
recently seen some people adding external links (as references) to
articles from different newspapers and I was wondering if it's really
worth it for the newspaper to have someone add such links?
Thanks,
Strainu
Hi all!
I just noticed that MediaWiki uses two different mime types for wikitext:
* application/x-wiki is used by AjaxResponse, OutputPage and StreamFile.
* text/x-wiki is used by RawAction.php (i.e. when you use action=raw)
Is there a good reason for this, or is it just an oversight? I suggest to use
the same mime type everywhere, and keep the old one for compatibility reasons -
i.e. we should use application/x-wiki consistently, and RawAction could support
text/x-wiki as an alias.
That being said... the *correct* mime type would imho be
application/x-mediawiki. But i don't insist on it :)
-- daniel
Wikitech-l Digest, Vol 105, Issue 105
Reply-To:
In-Reply-To: <mailman.190579.1335293572.15574.wikitech-l(a)lists.wikimedia.org>
X-PGP-Key: http://www.gtsm.com/Greg_Sabino_Mullane.key.html
Erik Moeller asked:
> can we agree on how we want to identify changes
...
> One proposal:
> - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to
> un-merged commits
> - Commit SHA-1s for deployment log entries and follow-ups to merged commits
+1. SHA-1 should be the rule, anything else should be the exception.
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
Platonides wrote:
> Note we will also need a way to generate a SQL from that (eg.
> for manually creating a new database with SQLAdmin).
>
> Personally, I prefer viewing the code (SQL) which is really
> used, but I won't stop you from making the perfect abstraction.
Well, the very first task of the new system will be to generate
a tables.sql and make sure it matches the current one. Perhaps we
can even keep them around, but make them "read only", for the benefit
of circumstances like the above (as well as making it easy to read
from the perspective of each database-in-question).
The only question in my mind at the moment is do we also copy all
the comments to each tables.sql (see maintenance/tables.sql), no
comments (see oracle|postgres/tables.sql) or something in the middle
(see mssql/tables.sql)?
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
https://www.mediawiki.org/wiki/Roadmap indicates that we aim to have
TimedMediaHandler deployed onto Wikimedia Foundation sites by the end of
May 2012.
TimedMediaHandler has been reviewed by Ian Baker and Kandalgaonkar
extensively, with lots of changes made in response by Michael Dale.
Review notes and Michael's follow-up are at
https://www.mediawiki.org/wiki/TimedMediaHandler/ReviewNotes . It is
currently being tested, including transcoding support, at
http://commons.wikimedia.beta.wmflabs.org/wiki/File:Electric_sheep.webm
. (Copied this from the extensions review queue status at
https://www.mediawiki.org/wiki/Review_queue .)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
On 04/24/2012 12:17 PM, Samuel Klein wrote:
> Where's the latest thread on the Timed Media Handler progress?
>
> I am meeting with MIT Open CourseWare tomorrow - they want to expand
> the set of videos they released last year under CC-SA, starting with
> categories / vids that would be fill gaps on Wikipedia. Any thoughts
> on how to make that collaboration more effective would be welcome.
>
> SJ
>
> On Tue, Apr 24, 2012 at 8:59 AM, David Gerard <dgerard(a)gmail.com> wrote:
>> On 24 April 2012 13:26, emijrp <emijrp(a)gmail.com> wrote:
>>
>>> Also, this message is more related to Wikimedia or Commons mailing lists
>>> (cc:). If you are the owner of those videos and you want to donate them,
>>> some people can help you in the process.
>>
>>
>> Well, not really - uploading video is still laborious because we've
>> been waiting literally years for the Timed Media Handler, which is a
>> wikitech issue. Andrew could probably deal with the ffmpeg2theora bit,
>> but it's still faffy and troublesome.
>>
>>
>> - d.
>>
>> _______________________________________________
>> Wikimedia-l mailing list
>> Wikimedia-l(a)lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Hello Everyone,
Does anyone know if mediawiki has ever used HTMLPurifier (
http://htmlpurifier.org/) as a library? Or if any extensions have used it?
I'm looking at adding in a library for svg cleaning that depends on it, but
not sure if that's something that can be added in, or if I
should re-implement those features.
Thanks,
Chris
While we were still getting set up with deployments from git/Gerrit,
we have allowed deployers to push directly to the wmf/* branches using
'git push origin wmf/1.20wmf1'. This bypasses Gerrit completely, so
there is no review (which is usually what we want), but also no e-mail
notification, no IRC notification, and you can't find the commit hash
or Change-Id in the Gerrit search (these are bad things).
So, as of 18:48 UTC today (about 30 minutes ago), this is no longer
allowed: using 'git push' to push into the wmf/* branches will result
in an error message ("Prohibited by Gerrit"). All commits in the wmf/*
branches now have to go through Gerrit, which means you need to submit
them with 'git review', and get someone to approve (+2) them before
they are merged. The project owners group (for core this is the group
of core reviewers ('mediawiki'), for extensions this is the extension
owners) do NOT have the ability to +2 revisions in the wmf/* branches,
this is reserved to the wmf-deployment group [1]. If you have deploy
access, you should be in this group. If somehow you're not, get a
Gerrit admin [2] to add you.
I have also updated the documentation accordingly [3]. If you have any
questions, feel free to ask (on-list is preferred, but off-list is
fine too).
Roan
[1] https://gerrit.wikimedia.org/r/#admin,group,21
[2] https://gerrit.wikimedia.org/r/#admin,group,1
[3] https://wikitech.wikimedia.org/index.php?title=How_to_deploy_code&diff=4603…