Hello All
I'm happy to announce the MediaWiki Developer Meet-Up will happen April 3.-5. in
Berlin, at the c-base. The event is for everyone who works on MediaWiki, writes
extensions, builds bots, writes scripts for the toolserver, or is otherwise
interested in the technical aspects of Wikimedia. We are happy that we can now
have the meet-up after our plans for 25C3 and FOSDEM failed. If you want to come
to the Developer Meetup, please sign up at
<http://www.mediawiki.org/wiki/Project:Developer_meet-up_2009>.
The event will take place in parallel to the Wikimedia Foundation's board
meeting and chapter meeting, so there will be a lot of Wikimedians in Berlin at
the time. We plan to have a party to bring everyone together and give an
opportunity for developers, board members and chapter people to mingle.
The meet-up will be a loose BacCamp-like event so topics and schedule are
largely up to you. The goal is to get to know new aspects of MediaWiki and
Wikimedia and to develop ideas on how we can make things even better. And of
course to have a lot of fun with wiki hackers from around the world!
-- daniel
At the moment image description pages on our projects that are
transcluded from Commons will be shown in English. That was no problem
for the last four years cause the pages basically all were in English.
But with the autotranslate template on Commons now many templates can be
shown in any language. It would be very useful, if the transcluded pages
on the local projects would be shown in the content language or user
language too.
If I am not mistaken, its the function "getDescriptionRenderUrl" in
"FileRepo.php" that gets the image description page from Commons. We
should add "'uselang='. $wgLang->getCode()" as an additional parameter,
so the page is rendered in the right language. (I don't know the code
well and had only a brief look into the file, perhaps some additional
changes are needed. The developers will know best.)
Can this be done?
Marcus Buck
Added to SVN:
Tzou PhiLiP (philip) -- patches for Chinese encoding converter
Tom Maaswinkel (thedevilonline) -- patches for UniWiki extensions.
-- brion
2009/1/20 <brion(a)svn.wikimedia.org>:
> Revision: 45938
> Author: brion
> Date: 2009-01-20 22:32:25 +0000 (Tue, 20 Jan 2009)
>
> Log Message:
> -----------
> Revert r45788 "Page moves should not be minor edits"
> Would prefer to see some discussion first; it's not obvious whether the change is needed/wanted.
I can't see any argument for changing the title of a page not being a
pretty big deal. Even without that, it's a definite bug - the edits
are marked as minor yet don't disappear when you click "hide minor
edits" (because they're actually log entries, not edits, so don't get
treated as minor by watchlists, etc.).
Yeah, get on that. We call it a feature...but it clearly
doubles as a drama-generator for those communities
prone to such antics.
-Chad
On Jan 20, 2009 6:35 PM, "David Gerard" <dgerard(a)gmail.com> wrote:
2009/1/20 Chad <innocentkiller(a)gmail.com>:
> Veeeerrrrry bad idea. I can already see enwiki having > ArbCom cases about
stuff someone wanted t...
No, no, this is a feature. The only way to fix en:wp is to cause the
dramatic core to enter final meltdown and annihilate itself, then the
people who write an encyclopedia can get on with that.
- d.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Veeeerrrrry bad idea. I can already see enwiki having
ArbCom cases about stuff someone wanted to say but
didnt .
-Chad
On Jan 20, 2009 5:50 PM, "Brion Vibber" <brion(a)wikimedia.org> wrote:
On 1/20/09 1:40 PM, Platonides wrote: > They could benefit from drafts, but
in that case better to d...
Client-side storage would be fantastic (and avoid unnecessary server
round-trips). We discussed this in original planning but didn't get
round to implementing it yet.
> A completely different approach could be to allow anyone to view other's >
drafts. As a new featu...
I wouldn't be comfortable with that, especially for discussion pages. I
also wouldn't be comfortable with my e-mail client showing everybody my
drafts of my e-mails...
I'm sure I'm not the only one who sometimes writes things they delete
for a very good reason before pushing save. ;)
-- brion
_______________________________________________ Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia....
>The current direction is to encourage in-browser client side
>transcoding. This offloads the costs of server side transcoding
and
>maximizes quality letting us supply the transcode settings for
>generating theora files from the HD or DV source. Instead of
users
>uploading intermediary format at low bandwidth & arbitrary
encode
>quality settings.
Why can we not do server-side transcoding to derive a few files
(ie 3 levels of quality, plus an animated gif thumbnail...?) akin
to Archive.org?
This seems to work nicely for them (and me, when I used it).
Simply upload your file, and it automatically transcodes the file
into the appropriate derivative files. This is certainly a lot
easier than asking the user to do it (most have no sweet clue,
and even experienced users are in over their head), and ensures
that the derived files have a minimal level of quality (ie no
transoding mistakes, which is easy to do if you don't know what
you're doing), saves the user time and energy, and also automates
a repetitive task. If we're asking users to upload several sizes
of a video because we can't "thumbnail" while streaming it then
instead of making them transcode it a bunch of times so there are
a few sizes of the file, WMF servers can do it.
Incidentally, archive.org required me to transfer the file via
FTP, which would also be /very/ nice to allow on WMF servers.
Cheers,
Mike
----
Mike.lifeguard
mikelifeguard(a)fastmail.fm
While the upload API is under development / stabilization ... I hacked
in basic firefogg upload support to the add_media_wizard ... Since
firefogg works over post you can use it with the existing upload
interface (without good error handling).... If you first download the
browser extension from firefogg.org you can do client side transcoding
by adding in:
importScriptURI('http://mvbox2.cse.ucsc.edu/wiki/extensions/MetavidWiki/skins/add_media_wiza…');
to your User:Name/monobook.js page on commons... once added visit the
upload page and hopefully it gives you the option to transcode ;)
This is just a proof of concept demo.. we should soon have real
integration ;)
peace,
--michael
I just realized that if a page has leading newlines, on every page edit
exactly one line is removed. This is no expected behaviour, is it? I'd
expect, that a null edit does not change the page.
Marcus Buck
Mike Baynton asked about some server side transcoding code he has worked
on this seems appropriate for wikitech-l so I have cc'ed it here.
The current direction is to encourage in-browser client side
transcoding. This offloads the costs of server side transcoding and
maximizes quality letting us supply the transcode settings for
generating theora files from the HD or DV source. Instead of users
uploading intermediary format at low bandwidth & arbitrary encode
quality settings.
I see a few potential directions to take with the transcoder work that
has been done...
1) Firefogg will request two copies one for archival and one for web
streaming. Perhaps we want to create derivatives from the archival
version (say for playback on a mobile device) and we need to re-derive
everything from the archival version.
2) Perhaps the infrastructure you developed may be applicable to dealing
out the tasks of "rendering out of sequences" of video. I have been
working on a web video sequencer/editor that will playback in html5
browsers but will need to be "flattened" to be played in other players,
browsers, put on DVD's etc. The best way to do this will probably be the
Gstreamer's GNonLin library (as used in PiTiVi). More on that later...
3) Perhaps we want to support _arbitrary file formats_ uploads from
users not running firefox in the immediate term? I don't see this as
hugely important. I think people that use video editing software or
people regularly dealing with digital video assets can likely
download/run firefox and handle the one click install of an extension.
3.5) The special case ofcourse is supporting video contributions from
mobile devices that are limited to encoding hardware specific video
codecs... But I think we would wait on this until A) we have the upload
api working, B) have an actual use case. ie lets get uploading photos
from cellphones working first. This use case will likely include
funding given the controlled exposure of applications / services in cell
phone devices. (hopefully that controlled environment issue will change
though) ...ultimately we want to push out patent unencumbered formats
to the "phones" too...
peace,
--michael