BTW wouldn't it be faster to have all banner on a statical page loaded (refreshed e.g. twice a week) and just pick a random one from the list (filtering the list with JS for current user)? The banners seems short enough.

The slowness of BannerLoader is because the script has to lookup your location based on your IP address before it decides which banner to serve (and it doesn't even start this until the page is finished loading). We may want to change this so that your location is stored in a cookie instead.

Regardless, CentralNotice/BannerLoader is probably the only JavaScript component that didn't change with the new 1.17 deployment (since it was already loading everything on document.ready to start with). So it's very unlikely the BannerLoader is responsible for any recent changes in toolbar loading.

May not be related but I noticed the other day that BannerLoader is causing a 302 redirect (not a 301 or 303) on all page views of non-English content language wikis.

The url is constructed like :

wgServer,
wgScript,
?title=[localized namespace name for Special],
:BannerListLoader
&etc etc.

"BannerListLoader" is put there in English, causing a redirect to the localized version (ie. "Speciaal:Bannerlijstlader" on nl.wikipedia)

Can the special page _name_ be translated in the url construction, just like the namespace name is localized ?

It seems the behavior of special page aliases is the opposite of what is described at http://www.mediawiki.org/wiki/Manual:Special_pages#The_Alias_files. Was this switched around at some point?

Also, is there a more elegant way of retrieving the localized alias besides:
if ( $specialPageAliases[$wgContLang]['BannerListLoader'][0] ) {

return $specialPageAliases[$wgContLang]['BannerListLoader'][0];

} else {

return 'BannerListLoader';

}

I imagine there's some specialized get method for this, but I haven't found anything yet.

(In reply to comment #2)

The slowness of BannerLoader is because the script has to lookup your location
based on your IP address before it decides which banner to serve (and it
doesn't even start this until the page is finished loading). We may want to
change this so that your location is stored in a cookie instead.

That may be one way but you could also check this for all users based on there most common IP and decide for them. Then you could write it to preferences after a user would confirm that this is his location (something similar is happening in Youtube). That way all this geolocalization and banner stuff could run once and be done for. Users could change their localization/country in preferences (near the language) and they could choose it after registering.

Regardless, CentralNotice/BannerLoader is probably the only JavaScript
component that didn't change with the new 1.17 deployment (since it was already
loading everything on document.ready to start with). So it's very unlikely the
BannerLoader is responsible for any recent changes in toolbar loading.

I'm guessing loading sequence changed with RL, so that might be a bit more of a pain now. Or maybe caching is still a bit unstable.

BTW could you load banner script only if banners are not disabled? Something like:

if (document.cookie.indexOf('hidesnmessage=1')==-1)
  mw.loader.load(wgServer + wgScriptPath + '?title=Special:BannerController&cache=/cn.js')

It's pointless to load it if it is not going to be used and it might help in page loading speed. Same might apply for the geo stuff...

That sounds like a good idea (checking the hide cookie before loading).

In case anyone's interested, the answer to my earlier question is:
$wgContLang->specialPage( $pageName )

I'll implement both of these fixes some time in the next couple weeks.

Fix to avoid redirect checked into r82749.

I'm almost certain now that all this problems are based in one thing - scripts (all scripts) were moved from head to the bottom of a page.

I know it is supposed to make pages load faster but it's just not working. Many users on pl.wiki complain that pages load slower and jump back and forth while portlets and toolbars are added (by scripts).

I wonder if implementing the suggestion I made in bug 25860 would solve at least some of this?

wiki wrote:

See my comments on the Bug 27488.

(In reply to comment #9)

I wonder if implementing the suggestion I made in bug 25860 would solve at
least some of this?

I don't think so. The problem is that the elements are already being displayed before the scripts even start loading. It's the way HTTP/HTML works. This is why some suggest that you should put scripts on the bottom of the page so the page can load before the scripts do. The problem is it is not working when a user want to and should (!) wait for the scripts to load before he does anything to the page. I think it just doesn't work for wiki and should be changed or at least users should be able to decide what does they want.

The BannerListLoader issue on non-english wikis is fixed on the live wikis now.

I see a significant difference now, so I consider this fixed. Thanks :-).

alexsm333 wrote:

However the textarea still loses focus after the new toolbar is loaded and you can even type some characters before this happens. This is easily reproduced on Wikipedia in Firefox 3.6.15 and Opera 11.01 but not in Chrome.

Are there any plans to fix that?

This is in Bug 27488. AFAIK it's impossible to fix it otherwise.