So I was thinking instead of just packaging in jQuery I should package
in / move the entire mv_embed folder into the skins directory .. it does
not make sense to maintain two branches reinventing what mv_embed.js
provides in the process of refactoring other core mediaWiki javascript.
We will
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale md...@wikimedia.org
wrote:
These changes will probably result in some minor adjustments to existing
skins. (I will try not to completely break compatibility cuz I know
there are many
,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale md...@wikimedia.org wrote:
These changes will probably result in some minor adjustments to existing
skins. (I will try not to completely break compatibility cuz I know
individually requested. If we really want all the style sheets grouped I
can bump that on the priority list to right after the upload api stuff
that I have to finish up ;)
--michael
Brion Vibber wrote:
Just a heads-up --
Michael Dale is working on some cleanup of how the various JavaScript
/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wikimediaorg/
peace,
michael
Brion Vibber wrote:
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
I am wondering if anyone has some contributer browser-client
information handy or can point me to a some dataset that I could query
to get the following information:
1) What is wikipedia client browser usage percentage distribution ( I
recall that being published recently but I have misplaced
as some have pointed out its test.wikipedia.org ( not test.wikimedia.org )
Michael Dale wrote:
The add media Wizard is in testing see blog post:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wikimediaorg/
If no one objects (or has any blocker bugs that I have
The add media Wizard is in testing see blog post:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wikimediaorg/
If no one objects (or has any blocker bugs that I have missed) I will
add the gadget option for firefogg / add media wizard to commons
shortly. (for wider
.
In addition to being able to handle large files without an ugly manual
download+reupload, the upload-by-URL functionality is also needed for
future-facing work Michael Dale is working on to allow an on-wiki media
picker to fetch freely-licensed files from Flickr, Archive.org, and
other places.
We
Sergey Chernyshev wrote:
Yes, of course - I checked it out and that's why I quoted it in my original
email.
My brief overview made me feel that it wasn't enough.
I just didn't want this to be only in context of localization as performance
is more related to overall user experience then to
nightlies its 5 scripts at a time. So you still end up doing
a few round trips when you have a high script count.
--michael
Aryeh Gregor wrote:
On Mon, Feb 23, 2009 at 2:35 PM, Michael Dale md...@wikimedia.org wrote:
... I was looking at commons upload form JavaScript load profile is like
... I was looking at commons upload form JavaScript load profile is like
a long waterfall or rather a steep river :(
http://metavid.org/promo/round_trips.png
Would be much nicer do 1 or 2 request instead of 27 ... true... a lot
are gadgets and what not.. but even on a not logged in Main page
So I was running into the problem of localizing the messages for the
add_media_wizard mv_embed associated libraries. So I have taken a
first pass at witting the script server (that I had previously
described) http://tinyurl.com/ae44vd Below is a description of how it
works. the code is in
with MediaWiki ...
So the question is, why re-invent the wheel ?
Thanks,
GerardM
2009/2/3 Michael Dale md...@wikimedia.org
We really need a wikidata type site. We ran into similar issues with
structured data between government data wikis. Yaron hacked up a
(relatively simple
Revising the $wgAllowCopyUploads request ... The thread ended here:
http://lists.wikimedia.org/pipermail/wikitech-l/2009-January/040942.html
Any updates on this; or ideas on how we could support client initiated
importing of media assets over http?
--michael
good points
I don't think it would be a _bad_ idea to support server side
transcoding it ofcourse gives more flexibility to have the original file
and then let us target different output formats in the future. Would let
us support camera video uploads etc.
But there are logistical issues.
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
Gregory Maxwell wrote:
This does
client side transcoding, but as far as the user can tell it's all done
by the server except no long transmission time for his 14gbyte DV
movie. (although, perhaps a long transcoding time. :) )
At some talks here a FOMS (foundations of open source media)
opps bad url for add_media_wizard try:
importScriptURI('http://mvbox2.cse.ucsc.edu/w/extensions/MetavidWiki/skins/add_media_wizard.js');
--michael
Michael Dale wrote:
While the upload API is under development / stabilization ... I hacked
in basic firefogg upload support
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
Can we look into enabling $wgAllowCopyUploads on Wikimedia projects?
This will let Wikimedia work a lot better with external archives
especial around large video files that are cumbersome for users to
download and then upload over our POST upload interface on home Internet
connections. In
great :) this will greatly benefit both the add_media_wizard and the
in-browser theora video transcoder / uploader :)
--michael
Bryan Tong Minh wrote:
On Thu, Jan 8, 2009 at 3:19 PM, Roan Kattouw roan.katt...@home.nl wrote:
Chad schreef:
I think the thing in the way of this is a
Once we ship the firefogg extension support for the uploading videos;
commons should request that users select the highest quality source
video footage available ie the HD video their camera captured or DV
original edited footage from their local computer and then commons will
supply the
, 2008 at 6:37 PM, Michael Dale md...@wikimedia.org wrote:
The debug switch would modify the HTML output to point at the individual
files with a GET seed ie myscript.js??php= date()? or something of
that nature bypassing the script loader altogether. The bulk of extra
content is comments, code
101 - 124 of 124 matches
Mail list logo
