From Wikipedia, the free encyclopedia

Internet Explorer bug fix

Discussing this diff and mediazilla:12157

I'm pretty sure that code was supposed to fix this IE6 horizontal scroll bug. The code was added on 19 January 2005 by User:Tom-, he has been asked about this on his talk page a year ago but there is no answer. The way I see it, there are 3 choices:

  • propose another solution (imho inlikely)
  • add browser detection (combine with 2 cases below?)
  • simply remove the code

AlexSm 17:30, 30 November 2007 (UTC) reply

I'm going to find out what it was supposed to fix in the first place, because I see no difference with the code disabled... yet. EdokterTalk 18:23, 30 November 2007 (UTC) reply
Right, nasty bug... In any case, I've put in a more robust client check, so it should not impact non-IE clients at all. EdokterTalk 23:33, 30 November 2007 (UTC) reply
It looks like the document.compatMode == "CSS1Compat" part depends on <!DOCTYPE declaration in the beginning of HTML page, and can be safely removed (as long as devs keep this declaration). Also, did you check that IE7 is affected by the bug as well? And can we please combine 3 separate checks for IE into just one? ∴ AlexSm 23:51, 30 November 2007 (UTC) reply
Browsing the net indicates this is a problem affecting all IE versions. I have been tinkering with the idea of restructuring common.js, but it would invlove some heavy editing; I'd have to do full inventory of all functions first and then prepare a proposal here. All in good time. EdokterTalk 00:31, 1 December 2007 (UTC) reply

More problems with SVG image rendering

(If this is wrong place to ask this question, please point me to the correct place.)

Here is a demonstration of a problem with SVG files converted to PNG by the server:

The SVG file was orginally generated by MS Visio, but I have then edited the SVG source code to try to fix the problems. There seem to be three problems:

  • "font-size" measured in em seems to be being interpreted as being measured in points
  • "letter-spacing" seems to be ignored
  • if "fill" is omitted it seems to default to "black" instead of "none".

Can these problems be fixed? (And will other clients have problems rendering Visio's SVG?)-- Dr Greg 18:30, 30 November 2007 (UTC) reply

This doesn't seem to be related to JavaScript at all (you can always check that by disabling JavaScript in your browser), so I'd say the correct place is either Wikipedia:Village pump (technical) or mediazilla:AlexSm 23:51, 30 November 2007 (UTC) reply

Adding functions to Common.js?

Hello, I am trying to add a slide-show template already operating on the French Wikipedia so that it can be used here, too. You can see a bit of background on this here.

So far, I have copied and translated the text of the French template from fr:Template:Images to en:Template:Slideshow, but the template relies on two functions (toggleImage and ImageGroup) in fr:MediaWiki:Common.js. What's the procedure for requesting that these be added to en:MediaWiki:Common.js or is there a better alternative (either for the template, or for these functions)? Sorry, but my knowledge of JavaScript and Wikipedia templates isn't up to answering these questions myself. Rupert Clayton 00:52, 4 December 2007 (UTC) reply

It's a bit shady area, and it's kind of difficult to have something added to Common.js (unless you're admin and can invert it from the start by saying "I will add this unless there's an opposition"). This particular template was already suggested at Wikipedia:Village pump (proposals)/Archive 5#Image gallery and then was also mentioned at Wikipedia:Village pump (proposals)#How about Not a picture book?. In any case, the official way is to start a new discussion at Wikipedia:Village pump (proposals), good luck with that. Personally I'm inclined to weak oppose this because I think a link to a Commons gallery should be sufficient ∴ AlexSm 20:56, 4 December 2007 (UTC) reply
Thanks, Alex. I have formally requested the necessary JavaScript functions at Wikipedia:Village pump (proposals)#Add a Slideshow template, based on existing functionality in French wikipedia. Anyone with suggestions or comments on this is welcome to join the discussion there. Thanks. Rupert Clayton ( talk) 18:21, 5 December 2007 (UTC) reply

Change in mainPageAppendCompleteListLink and removal of ts_parseFloat

{{ editprotected}} 1. Please replace mainPageAppendCompleteListLink() with this short version

function mainPageAppendCompleteListLink() {
 addPortletLink('p-lang', 'http://meta.wikimedia.org/wiki/List_of_Wikipedias', 
  'Complete list', 'interwiki-completelist', 'Complete list of Wikipedias')
}

this also requires a change in MediaWiki:Common.css:
.interwiki-completelist#interwiki-completelist
While at it, some obvious junk can be removed as well, like <noinclude>{{interwiki-all}}</noinclude>, <!--, '''<span style="color: #f00;">AlexSm 21:20, 4 December 2007 (UTC) reply

2. Please remove function ts_parseFloat() since it's already fixed in rev:27138AlexSm 21:20, 4 December 2007 (UTC) reply

Done. The parseFloat code was removed, and some other minor changes were made throughout. I added your name as a maintainer to one of the sections; the <noinclude> issues I couldn't find.... Cheers. -- MZMcBride ( talk) 00:55, 5 December 2007 (UTC) reply
Oh, I just understood what you meant about code cleanup (Common.css, not Common.js). I'll fix it in a bit. : - ) -- MZMcBride ( talk) 00:56, 5 December 2007 (UTC) reply

fix edit summary prompt for undo

The «fix edit summary prompt for undo» code in MediaWiki:Common.js does eliminate unnecessary prompt when you do simple undo-save, but at the same time it adds the prompt when you do undo-alter_summary-preview-save. That's because Function showEditForm in MediaWiki recreates empty wpAutoSummary on preview. See mediazilla:8912 for more info. Until devs fix that, I think the Common.js should use any other value instead of '' to solve this problem ∴ AlexSm 20:15, 6 December 2007 (UTC) reply

 Done I changed the blank string (which causes problems as you mentioned) to a '1'. Tra (Talk) 21:01, 6 December 2007 (UTC) reply

Special:Upload

Concerning Special:Upload, please see the discussion at

Someone suggested that we need to ask here about this.

Can the {{ Information}} template code in the Special:Upload form be placed in the form as at commons:Special:Upload?

I am talking about this template code:

{{Information
|Description=
|Source=
|Date=
|Author=
|Permission=
|other_versions=
}}

This would help tremendously in getting more images sourced and licensed correctly when uploaded. -- Timeshifter ( talk) 18:18, 11 December 2007 (UTC) reply

This should be an easy task, but for the life of me I can't find the message or whatever modifies what's in the box by default (delving through the html source usually works for this). I've looked around commons to check too. I guess I'll have to ask them what they did. - Royalguard11( T· R!) 22:43, 11 December 2007 (UTC) reply
It's commons:MediaWiki:Upload.js, but please consider other option first: non-Javascript solution with wpUploadDescription= URL parameter ( working example) ∴ AlexSm 03:46, 12 December 2007 (UTC) reply
The non-Javascript solution would be much better. We should also have the non-free image upload form automatically load in the skeleton code for Template:Non-free use rationale - that would help a lot. — Remember the dot ( talk) 03:53, 12 December 2007 (UTC) reply
AlexSm, what am I looking at here?:
User:Steinninn/upload
I don't see the {{ Information}} template text preloaded in an upload form as at commons:Special:Upload. -- Timeshifter ( talk) 06:30, 14 December 2007 (UTC) reply
The template should be preloaded if you follow any of the first eight links, like this one. Btw, why don't we move the discussion back to Wikipedia talk:Upload? ∴ AlexSm 16:03, 14 December 2007 (UTC) reply
Thanks. I see the preloaded template text now. Looks fine to me. Yes, let us move back to Wikipedia talk:Upload. -- Timeshifter ( talk) 16:48, 14 December 2007 (UTC) reply
From Wikipedia, the free encyclopedia

Internet Explorer bug fix

Discussing this diff and mediazilla:12157

I'm pretty sure that code was supposed to fix this IE6 horizontal scroll bug. The code was added on 19 January 2005 by User:Tom-, he has been asked about this on his talk page a year ago but there is no answer. The way I see it, there are 3 choices:

  • propose another solution (imho inlikely)
  • add browser detection (combine with 2 cases below?)
  • simply remove the code

AlexSm 17:30, 30 November 2007 (UTC) reply

I'm going to find out what it was supposed to fix in the first place, because I see no difference with the code disabled... yet. EdokterTalk 18:23, 30 November 2007 (UTC) reply
Right, nasty bug... In any case, I've put in a more robust client check, so it should not impact non-IE clients at all. EdokterTalk 23:33, 30 November 2007 (UTC) reply
It looks like the document.compatMode == "CSS1Compat" part depends on <!DOCTYPE declaration in the beginning of HTML page, and can be safely removed (as long as devs keep this declaration). Also, did you check that IE7 is affected by the bug as well? And can we please combine 3 separate checks for IE into just one? ∴ AlexSm 23:51, 30 November 2007 (UTC) reply
Browsing the net indicates this is a problem affecting all IE versions. I have been tinkering with the idea of restructuring common.js, but it would invlove some heavy editing; I'd have to do full inventory of all functions first and then prepare a proposal here. All in good time. EdokterTalk 00:31, 1 December 2007 (UTC) reply

More problems with SVG image rendering

(If this is wrong place to ask this question, please point me to the correct place.)

Here is a demonstration of a problem with SVG files converted to PNG by the server:

The SVG file was orginally generated by MS Visio, but I have then edited the SVG source code to try to fix the problems. There seem to be three problems:

  • "font-size" measured in em seems to be being interpreted as being measured in points
  • "letter-spacing" seems to be ignored
  • if "fill" is omitted it seems to default to "black" instead of "none".

Can these problems be fixed? (And will other clients have problems rendering Visio's SVG?)-- Dr Greg 18:30, 30 November 2007 (UTC) reply

This doesn't seem to be related to JavaScript at all (you can always check that by disabling JavaScript in your browser), so I'd say the correct place is either Wikipedia:Village pump (technical) or mediazilla:AlexSm 23:51, 30 November 2007 (UTC) reply

Adding functions to Common.js?

Hello, I am trying to add a slide-show template already operating on the French Wikipedia so that it can be used here, too. You can see a bit of background on this here.

So far, I have copied and translated the text of the French template from fr:Template:Images to en:Template:Slideshow, but the template relies on two functions (toggleImage and ImageGroup) in fr:MediaWiki:Common.js. What's the procedure for requesting that these be added to en:MediaWiki:Common.js or is there a better alternative (either for the template, or for these functions)? Sorry, but my knowledge of JavaScript and Wikipedia templates isn't up to answering these questions myself. Rupert Clayton 00:52, 4 December 2007 (UTC) reply

It's a bit shady area, and it's kind of difficult to have something added to Common.js (unless you're admin and can invert it from the start by saying "I will add this unless there's an opposition"). This particular template was already suggested at Wikipedia:Village pump (proposals)/Archive 5#Image gallery and then was also mentioned at Wikipedia:Village pump (proposals)#How about Not a picture book?. In any case, the official way is to start a new discussion at Wikipedia:Village pump (proposals), good luck with that. Personally I'm inclined to weak oppose this because I think a link to a Commons gallery should be sufficient ∴ AlexSm 20:56, 4 December 2007 (UTC) reply
Thanks, Alex. I have formally requested the necessary JavaScript functions at Wikipedia:Village pump (proposals)#Add a Slideshow template, based on existing functionality in French wikipedia. Anyone with suggestions or comments on this is welcome to join the discussion there. Thanks. Rupert Clayton ( talk) 18:21, 5 December 2007 (UTC) reply

Change in mainPageAppendCompleteListLink and removal of ts_parseFloat

{{ editprotected}} 1. Please replace mainPageAppendCompleteListLink() with this short version

function mainPageAppendCompleteListLink() {
 addPortletLink('p-lang', 'http://meta.wikimedia.org/wiki/List_of_Wikipedias', 
  'Complete list', 'interwiki-completelist', 'Complete list of Wikipedias')
}

this also requires a change in MediaWiki:Common.css:
.interwiki-completelist#interwiki-completelist
While at it, some obvious junk can be removed as well, like <noinclude>{{interwiki-all}}</noinclude>, <!--, '''<span style="color: #f00;">AlexSm 21:20, 4 December 2007 (UTC) reply

2. Please remove function ts_parseFloat() since it's already fixed in rev:27138AlexSm 21:20, 4 December 2007 (UTC) reply

Done. The parseFloat code was removed, and some other minor changes were made throughout. I added your name as a maintainer to one of the sections; the <noinclude> issues I couldn't find.... Cheers. -- MZMcBride ( talk) 00:55, 5 December 2007 (UTC) reply
Oh, I just understood what you meant about code cleanup (Common.css, not Common.js). I'll fix it in a bit. : - ) -- MZMcBride ( talk) 00:56, 5 December 2007 (UTC) reply

fix edit summary prompt for undo

The «fix edit summary prompt for undo» code in MediaWiki:Common.js does eliminate unnecessary prompt when you do simple undo-save, but at the same time it adds the prompt when you do undo-alter_summary-preview-save. That's because Function showEditForm in MediaWiki recreates empty wpAutoSummary on preview. See mediazilla:8912 for more info. Until devs fix that, I think the Common.js should use any other value instead of '' to solve this problem ∴ AlexSm 20:15, 6 December 2007 (UTC) reply

 Done I changed the blank string (which causes problems as you mentioned) to a '1'. Tra (Talk) 21:01, 6 December 2007 (UTC) reply

Special:Upload

Concerning Special:Upload, please see the discussion at

Someone suggested that we need to ask here about this.

Can the {{ Information}} template code in the Special:Upload form be placed in the form as at commons:Special:Upload?

I am talking about this template code:

{{Information
|Description=
|Source=
|Date=
|Author=
|Permission=
|other_versions=
}}

This would help tremendously in getting more images sourced and licensed correctly when uploaded. -- Timeshifter ( talk) 18:18, 11 December 2007 (UTC) reply

This should be an easy task, but for the life of me I can't find the message or whatever modifies what's in the box by default (delving through the html source usually works for this). I've looked around commons to check too. I guess I'll have to ask them what they did. - Royalguard11( T· R!) 22:43, 11 December 2007 (UTC) reply
It's commons:MediaWiki:Upload.js, but please consider other option first: non-Javascript solution with wpUploadDescription= URL parameter ( working example) ∴ AlexSm 03:46, 12 December 2007 (UTC) reply
The non-Javascript solution would be much better. We should also have the non-free image upload form automatically load in the skeleton code for Template:Non-free use rationale - that would help a lot. — Remember the dot ( talk) 03:53, 12 December 2007 (UTC) reply
AlexSm, what am I looking at here?:
User:Steinninn/upload
I don't see the {{ Information}} template text preloaded in an upload form as at commons:Special:Upload. -- Timeshifter ( talk) 06:30, 14 December 2007 (UTC) reply
The template should be preloaded if you follow any of the first eight links, like this one. Btw, why don't we move the discussion back to Wikipedia talk:Upload? ∴ AlexSm 16:03, 14 December 2007 (UTC) reply
Thanks. I see the preloaded template text now. Looks fine to me. Yes, let us move back to Wikipedia talk:Upload. -- Timeshifter ( talk) 16:48, 14 December 2007 (UTC) reply

Videos

Youtube | Vimeo | Bing

Websites

Google | Yahoo | Bing

Encyclopedia

Google | Yahoo | Bing

Facebook