[Wikitech-l] DEADLINE for WMDE contract applications

[Daniel Kinzler]

Hello all

At the developer meetup, I announced that Wikimedia Deutschland is offering
contracts for a couple of projects we feel are important. We again invite anyone
to apply NOW for any project that interests you.

  The DEADLINE for applying is SUNDAY, APRIL 19!

We did not receive any offer for the most urgent project:  Evaluate the impact
of using flagged revisions on the German Wikipedia, see
.

We feel that it would be very helpful to run a full analysis on this before the
English language Wikipedia decides on how to implement flagged revisions. It's a
powerful tool, and we should make sure we use it to it's full potential.

Below, the other projects are listed again:

* Rewrite CatScan, a tool for finding pages in a set of categories recursively,
based on various criteria -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Rewrite_CatScan

* Store interwiki-links in the database, just like we already store
interlanguage-links -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Store_interwiki-links_in_the_database

* Improve the Gadgets extension to allow for gadgets to be enabled per default,
be restricted to specific user groups, etc -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Improve_the_Gadets_extension

* Implement full support for TIFF files, including multi-page TIFFs, similar to
how DjVu is handled -
http://www.mediawiki.org/wiki/WMDE_contract_offers/Implement_full_support_for_TIFF_files

If you would like to help with any of the above, please contact me at
 and provide the following information:
* Your real name and country of residence
* How you plan to go about implementing the desired function
* Any experience working with MediaWiki
* How many working hours you would spend on it, and how much you ask for it
* In what time frame you would be able to do the job

This information is also available at
http://www.mediawiki.org/wiki/WMDE_contract_offers

Thanks you all for your interest!

-- daniel



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] European network outage

[Brion Vibber]

We’re encountering some networking problems between our Tampa and 
Amsterdam data centers, which is breaking access to the sites for people 
in Europe. Mark’s poking to see if it can be resolved; if necessary 
we’ll reroute European visitors directly to the Tampa center.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] European network outage

[Brion Vibber]

Seems to have been resolved.

-- brion vibber (brion @ wikimedia.org)

On Apr 16, 2009, at 9:00, Brion Vibber  wrote:

> We’re encountering some networking problems between our Tampa and
> Amsterdam data centers, which is breaking access to the sites for  
> people
> in Europe. Mark’s poking to see if it can be resolved; if necessary
> we’ll reroute European visitors directly to the Tampa center.
>
> -- brion
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin & JS cleanup and jQuery

[Sergey Chernyshev]

Speaking of libraries and all, I think it's worth merging libraries in
general and figuring out a way for skin and extension developers to include
libraries in the way that system can only:
- include a library once
- include latest library unless absolutely necessary
- maybe even load parts of the library on demand (
http://developer.yahoo.com/yui/yuiloader/ is an example of what I'm talking
about).

Maybe it's also worth adding some JS bundles functionality where main bundle
is global JS to be loaded on all page and there can be more bundles to load
the rest of the code on pages that need them. My point is that this decision
could be made in MW and not in the extensions - system should know what is
bundled where and ignore inclusion request on the page if, let's say, YUI is
already loaded in main bundle.

Thank you,

Sergey


--
Sergey Chernyshev
http://www.sergeychernyshev.com/


On Wed, Apr 15, 2009 at 6:53 PM, Hay (Husky)  wrote:

> That's great news. I've been programming in JavaScript quite a lot the
> last few years and i think i would've probably gone insane if i hadn't
> discovered jQuery. Especially for complex and intricate HTML
> selections it's pretty amazing what you can do with jQuery.
>
> Also, the fact that animations are built into the core could mean it
> might get a little bit more simple to do visually cool things, which
> might make the UI more intuitive.
>
> -- Hay
>
> On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev
>  wrote:
> > Guys,
> >
> > It's great to see that you're working in this direction - I'm thinking
> about
> > working on this for a while, but didn't have a gut to undertake such
> > ambitious project alone ;)
> >
> > Do you have a working instance of ScriptLoader anywhere so I can aim some
> > performance tools at it?
> >
> > Thank you,
> >
> >Sergey
> >
> >
> > --
> > Sergey Chernyshev
> > http://www.sergeychernyshev.com/
> >
> >
> > On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale 
> 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 custom skins out in the wild that would be no fun to stop
> >> working once they update medaiWiki)
> >>
> >> This consolidation of  includes _may_ result in _some_ un-updated
> >> skins referencing the same files twice which I think most browsers
> >> genneraly handle "oky"
> >>
> >> Enabling $wgEnableScriptLoader will not work so well with skins that
> >> have not been updated. Should have a patch soon. more about
> scriptLoader:
> >> http://www.mediawiki.org/wiki/ScriptLoader
> >> (We will most likely ship with $wgEnableScriptLoader off by default )
> >>
> >> I am also very excited about jQuery making its way into core. Things
> >> like the add_media_wizard are much easier to put together with jQuery's
> >> nifty abstractions and msg system. More about add media wizard:
> >>
> >>
> http://metavid.org/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 and make it easier to integrate in a
> >> > centralized loader so we can serve more JS together in a single
> >> > compressed request.
> >> >
> >> > Unless there's a strong objection I'd be very happy for this to also
> >> > include loading up the jQuery core library as a standard component.
> >> >
> >> > The minified jQuery core is 19k gzipped, and can simplify other JS
> code
> >> > significantly so we can likely chop down wikibits.js, mwsuggest.js,
> and
> >> > the site-customized Monobook.js files by a large margin for a net
> >> savings.
> >> >
> >> > If you've done browser-side JavaScript development without jQuery and
> >> > wanted to kill yourself, I highly recommend you try jQuery -- it's
> >> > so nice. :)
> >> >
> >> > -- brion
> >> >
> >> > ___
> >> > Wikitech-l mailing list
> >> > Wikitech-l@lists.wikimedia.org
> >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >> >
> >>
> >>
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin & JS cleanup and jQuery

[Chad]

On Thu, Apr 16, 2009 at 2:35 PM, Sergey Chernyshev
 wrote:
> Speaking of libraries and all, I think it's worth merging libraries in
> general and figuring out a way for skin and extension developers to include
> libraries in the way that system can only:
> - include a library once
> - include latest library unless absolutely necessary
> - maybe even load parts of the library on demand (
> http://developer.yahoo.com/yui/yuiloader/ is an example of what I'm talking
> about).
>
> Maybe it's also worth adding some JS bundles functionality where main bundle
> is global JS to be loaded on all page and there can be more bundles to load
> the rest of the code on pages that need them. My point is that this decision
> could be made in MW and not in the extensions - system should know what is
> bundled where and ignore inclusion request on the page if, let's say, YUI is
> already loaded in main bundle.
>
> Thank you,
>
>        Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
> On Wed, Apr 15, 2009 at 6:53 PM, Hay (Husky)  wrote:
>
>> That's great news. I've been programming in JavaScript quite a lot the
>> last few years and i think i would've probably gone insane if i hadn't
>> discovered jQuery. Especially for complex and intricate HTML
>> selections it's pretty amazing what you can do with jQuery.
>>
>> Also, the fact that animations are built into the core could mean it
>> might get a little bit more simple to do visually cool things, which
>> might make the UI more intuitive.
>>
>> -- Hay
>>
>> On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev
>>  wrote:
>> > Guys,
>> >
>> > It's great to see that you're working in this direction - I'm thinking
>> about
>> > working on this for a while, but didn't have a gut to undertake such
>> > ambitious project alone ;)
>> >
>> > Do you have a working instance of ScriptLoader anywhere so I can aim some
>> > performance tools at it?
>> >
>> > Thank you,
>> >
>> >        Sergey
>> >
>> >
>> > --
>> > Sergey Chernyshev
>> > http://www.sergeychernyshev.com/
>> >
>> >
>> > On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale 
>> 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 custom skins out in the wild that would be no fun to stop
>> >> working once they update medaiWiki)
>> >>
>> >> This consolidation of  includes _may_ result in _some_ un-updated
>> >> skins referencing the same files twice which I think most browsers
>> >> genneraly handle "oky"
>> >>
>> >> Enabling $wgEnableScriptLoader will not work so well with skins that
>> >> have not been updated. Should have a patch soon. more about
>> scriptLoader:
>> >> http://www.mediawiki.org/wiki/ScriptLoader
>> >> (We will most likely ship with $wgEnableScriptLoader off by default )
>> >>
>> >> I am also very excited about jQuery making its way into core. Things
>> >> like the add_media_wizard are much easier to put together with jQuery's
>> >> nifty abstractions and msg system. More about add media wizard:
>> >>
>> >>
>> http://metavid.org/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 and make it easier to integrate in a
>> >> > centralized loader so we can serve more JS together in a single
>> >> > compressed request.
>> >> >
>> >> > Unless there's a strong objection I'd be very happy for this to also
>> >> > include loading up the jQuery core library as a standard component.
>> >> >
>> >> > The minified jQuery core is 19k gzipped, and can simplify other JS
>> code
>> >> > significantly so we can likely chop down wikibits.js, mwsuggest.js,
>> and
>> >> > the site-customized Monobook.js files by a large margin for a net
>> >> savings.
>> >> >
>> >> > If you've done browser-side JavaScript development without jQuery and
>> >> > wanted to kill yourself, I highly recommend you try jQuery -- it's
>> >> > so nice. :)
>> >> >
>> >> > -- brion
>> >> >
>> >> > ___
>> >> > Wikitech-l mailing list
>> >> > Wikitech-l@lists.wikimedia.org
>> >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >> >
>> >>
>> >>
>> >> ___
>> >> Wikitech-l mailing list
>> >> Wikitech-l@lists.wikimedia.org
>> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >>
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/

Re: [Wikitech-l] Skin & JS cleanup and jQuery

[Michael Dale]

mv_embed has some functions for doing exactly that.

You can run something like: doLoad({list, of, classes, that, i need}, 
function(){
//code to run now that all those components have been included.
}

It plays well with the script loader and loads it all the requested 
components in a single scriptLoader request. If you have already loaded 
some of those libraries it skips the classes it already has available.

and is a bit simpler than the YUI framework I think ;)

--michael



Sergey Chernyshev wrote:
> Speaking of libraries and all, I think it's worth merging libraries in
> general and figuring out a way for skin and extension developers to include
> libraries in the way that system can only:
> - include a library once
> - include latest library unless absolutely necessary
> - maybe even load parts of the library on demand (
> http://developer.yahoo.com/yui/yuiloader/ is an example of what I'm talking
> about).
>
> Maybe it's also worth adding some JS bundles functionality where main bundle
> is global JS to be loaded on all page and there can be more bundles to load
> the rest of the code on pages that need them. My point is that this decision
> could be made in MW and not in the extensions - system should know what is
> bundled where and ignore inclusion request on the page if, let's say, YUI is
> already loaded in main bundle.
>
> Thank you,
>
> Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
> On Wed, Apr 15, 2009 at 6:53 PM, Hay (Husky)  wrote:
>
>   
>> That's great news. I've been programming in JavaScript quite a lot the
>> last few years and i think i would've probably gone insane if i hadn't
>> discovered jQuery. Especially for complex and intricate HTML
>> selections it's pretty amazing what you can do with jQuery.
>>
>> Also, the fact that animations are built into the core could mean it
>> might get a little bit more simple to do visually cool things, which
>> might make the UI more intuitive.
>>
>> -- Hay
>>
>> On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev
>>  wrote:
>> 
>>> Guys,
>>>
>>> It's great to see that you're working in this direction - I'm thinking
>>>   
>> about
>> 
>>> working on this for a while, but didn't have a gut to undertake such
>>> ambitious project alone ;)
>>>
>>> Do you have a working instance of ScriptLoader anywhere so I can aim some
>>> performance tools at it?
>>>
>>> Thank you,
>>>
>>>Sergey
>>>
>>>
>>> --
>>> Sergey Chernyshev
>>> http://www.sergeychernyshev.com/
>>>
>>>
>>> On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale 
>>>   
>> 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 custom skins out in the wild that would be no fun to stop
 working once they update medaiWiki)

 This consolidation of  includes _may_ result in _some_ un-updated
 skins referencing the same files twice which I think most browsers
 genneraly handle "oky"

 Enabling $wgEnableScriptLoader will not work so well with skins that
 have not been updated. Should have a patch soon. more about
 
>> scriptLoader:
>> 
 http://www.mediawiki.org/wiki/ScriptLoader
 (We will most likely ship with $wgEnableScriptLoader off by default )

 I am also very excited about jQuery making its way into core. Things
 like the add_media_wizard are much easier to put together with jQuery's
 nifty abstractions and msg system. More about add media wizard:


 
>> http://metavid.org/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 and make it easier to integrate in a
> centralized loader so we can serve more JS together in a single
> compressed request.
>
> Unless there's a strong objection I'd be very happy for this to also
> include loading up the jQuery core library as a standard component.
>
> The minified jQuery core is 19k gzipped, and can simplify other JS
>   
>> code
>> 
> significantly so we can likely chop down wikibits.js, mwsuggest.js,
>   
>> and
>> 
> the site-customized Monobook.js files by a large margin for a net
>   
 savings.
 
> If you've done browser-side JavaScript development without jQuery and
> wanted to kill yourself, I highly recommend you try jQuery -- it's
> so nice. :)
>
> -- brion
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin & JS cleanup and jQuery

[Michael Dale]

I have a branch I have made some initial commits to..
http://svn.wikimedia.org/viewvc/mediawiki/branches/script-loader/

(Its not ready yet)...will be great to have some tests to compare it 
with... I will be sure to let you know when it is ready ;)

peace,
michael


Sergey Chernyshev wrote:
> Guys,
>
> It's great to see that you're working in this direction - I'm thinking about
> working on this for a while, but didn't have a gut to undertake such
> ambitious project alone ;)
>
> Do you have a working instance of ScriptLoader anywhere so I can aim some
> performance tools at it?
>
> Thank you,
>
> Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
> On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale  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 custom skins out in the wild that would be no fun to stop
>> working once they update medaiWiki)
>>
>> This consolidation of  includes _may_ result in _some_ un-updated
>> skins referencing the same files twice which I think most browsers
>> genneraly handle "oky"
>>
>> Enabling $wgEnableScriptLoader will not work so well with skins that
>> have not been updated. Should have a patch soon. more about scriptLoader:
>> http://www.mediawiki.org/wiki/ScriptLoader
>> (We will most likely ship with $wgEnableScriptLoader off by default )
>>
>> I am also very excited about jQuery making its way into core. Things
>> like the add_media_wizard are much easier to put together with jQuery's
>> nifty abstractions and msg system. More about add media wizard:
>>
>> http://metavid.org/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 and make it easier to integrate in a
>>> centralized loader so we can serve more JS together in a single
>>> compressed request.
>>>
>>> Unless there's a strong objection I'd be very happy for this to also
>>> include loading up the jQuery core library as a standard component.
>>>
>>> The minified jQuery core is 19k gzipped, and can simplify other JS code
>>> significantly so we can likely chop down wikibits.js, mwsuggest.js, and
>>> the site-customized Monobook.js files by a large margin for a net
>>>   
>> savings.
>> 
>>> If you've done browser-side JavaScript development without jQuery and
>>> wanted to kill yourself, I highly recommend you try jQuery -- it's
>>> so nice. :)
>>>
>>> -- brion
>>>
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>>   
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>   


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Fwd: Phorm opt-out for Wikipedia.org and related domains]

[Brion Vibber]

After some internal discussion on whether opting out of the Phorm 
user-profiling system in the UK would legitimize it, we're going ahead 
and requesting an opt-out for all the domains under the Wikimedia 
Foundation's control.

For background see eg:
http://www.openrightsgroup.org/2009/03/22/open-letter-call-for-major-websites-to-opt-out-of-phorm/

-- brion vibber (brion @ wikimedia.org)

 Original Message 
Subject: Phorm opt-out for Wikipedia.org and related domains
Date: Thu, 16 Apr 2009 14:28:11 -0700
From: Brion Vibber 
To: website-exclus...@webwise.com
CC: privat...@lists.wikimedia.org

To whom it may concern --

The Wikimedia Foundation requests that our web sites including
Wikipedia.org and all related domains be excluded from scanning by the
Phorm / BT Webwise system, as we consider the scanning and profiling of
our visitors' behavior by a third party to be an infringement on their
privacy.

Here is a list of our domains which should be excluded (please exclude
any and all subdomains as well):

wikipedia.org
wikipedia.com
wikipedia.co.uk
wikipedia.cz
wikipedia.fr
wikipedia.info
wikipedia.lt
wikipedia.net
wikipedia.nl
wikipedia.org.br
mediawiki.com
mediawiki.org
quickipedia.net
quickipedia.org
toolserver.org
vikipedio.com
vikipedio.org
wikibook.com
wikibooks.com
wikibooks.cz
wikibooks.org
wikicitaty.cz
wikidata.org
wikidisclosure.com
wikidisclosure.org
wikidruhy.cz
wikifamily.com
wikifamily.org
wikigis.com
wikigis.org
wikijunior.com
wikijunior.net
wikijunior.org
wikiknihy.cz
wikimania2006.org
wikimania2007.org
wikimaps.com
wikimaps.net
wikimediacommons.co.uk
wikimediacommons.de
wikimediacommons.eu
wikimediacommons.info
wikimediacommons.mobl
wikimediacommons.net
wikimediacommons.org
wikimedia.cz
wikimediafoundation.com
wikimediafoundation.net
wikimediafoundation.org
wikimedia.hu
wikimedia.li
wikimedia.lt
wikimedia.org
wikimedia.pl
wikimedia.se
wikimedia.us
wikimemory.org
wikimorial.com
wikimorial.org
wikinews.org
wikipaedia.net
wikipedie.cz
wikiquote.com
wikiquote.cz
wikiquote.net
wikiquote.org
wikislovnik.cz
wikisource.com
wikisource.cz
wikisource.org
wikispecies.com
wikispecies.cz
wikispecies.net
wikispecies.org
wikiversity.com
wikiversity.cz
wikiversity.org
wikiverzita.cz
wikizdroje.cz
wikizpravy.cz
wiktionary.com
wiktionary.cz
wiktionary.org

Thank you for your time.

-- brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
+1 (415) 839-6885

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin & JS cleanup and jQuery

[Marco Schuster]

On Wed, Apr 15, 2009 at 11:05 PM, 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 and make it easier to integrate in a
> centralized loader so we can serve more JS together in a single
> compressed request.


Are there any plans to use Google Gears for storage on clients? Okay, people
have to enable it by hand, but it shoulda speed up page loads for people
very much (at least for those who use it).

Marco


-- 
VMSoft GbR
Nabburger Str. 15
81737 München
Geschäftsführer: Marco Schuster, Volker Hemmert
http://vmsoft-gbr.de
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin & JS cleanup and jQuery

[Michael Dale]

oky... branch /branches/script-loader/ ready for wider testing

after you check out the branch you have to add $wgEnableScriptLoader = 
true;  to your local settings.

Things I don't tackle in this version of the scriptLoader:

1) checking the version of every msg string packaged in JS (right now I 
will just rely on bumping the $wgStyleVersion up global var to clear 
caches as not many projects besides mine are using JavaScript msg 
packing system yet ;) ... and there are other issues with the language 
packaging that need to be addressed. But I do check the latest revision 
id for every wiki page that is included via the scriptLoader. This has 
the nice benefit of once you save a gadget preference or update a user 
javascript page you don't have to "shift reload" as a new unique 
javascript request id is automatically generated.

2) Style sheet grouping is a bit tricky cuz you have to rewrite all the 
relative paths to a different relative position since its being served 
from the script server location. There is a library that handles this:
http://code.google.com/p/minify/source/browse/trunk/min/lib/Minify/CSS.php
but i have not integrated that yet...so style sheets are still 
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 
> bits are loaded by the skins to centralize some of the currently 
> horridly spread-out code and make it easier to integrate in a 
> centralized loader so we can serve more JS together in a single 
> compressed request.
>
> Unless there's a strong objection I'd be very happy for this to also 
> include loading up the jQuery core library as a standard component.
>
> The minified jQuery core is 19k gzipped, and can simplify other JS code 
> significantly so we can likely chop down wikibits.js, mwsuggest.js, and 
> the site-customized Monobook.js files by a large margin for a net savings.
>
> If you've done browser-side JavaScript development without jQuery and 
> wanted to kill yourself, I highly recommend you try jQuery -- it's 
> so nice. :)
>
> -- brion
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>   


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] SVN commit access

[Robin P.]

It seems this is the place to request commit access, so I'd like to request
commit access too.

My key: http://toolserver.org/~robin/publickey.txt
Commit name: robin (my wikiname is SPQRobin but uppercase appears to be not
allowed)

I want to use it to commit and maintain my extension (see
http://www.mediawiki.org/wiki/Extension:WikimediaIncubator) to be used on
Wikimedia Incubator.
Maybe I'll do some general work/maintenance as well, or fix bugs, when I see
something I can fix.
I have already worked on SpecialInterwiki extension but I didn't work on it
further since I didn't have commit access..
I also used to work a bit on i18n through Translatewiki.net (for example,
reporting unused messages, ...) although that's not so important for this :)

Thank you.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l