Misplaced Pages

Revision as of 00:48, 12 May 2006

What is the use of this message? Each tooltip had a message formerly. I tried to give a translation in the Spanish Misplaced Pages (es:MediaWiki:Monobook.js) but something is broken and now the tooltips are not shown there. Any help is appreciated. Thank you. ManuelGR 19:06, 14 Jun 2004 (UTC)

pref system/ access key update

• accesskeys and tooltips moved to js, needs to be customized/localized at MediaWiki:Monobook.js (copy everything below /* tooltips and access keys */ from . Saves many calls to wfMsg, reduces page size, shows access key prefix depending on browser/os. Easy to customize in your own Monobook.js by changing the ta array.
• skinphptal underline and justification wired up to produce generated css- users have to adjust their prefs to get the default Monobook behaviour unfortunately
• MediaWiki:Monobook.css used for anons as well (-> underlined for them now)
• addcss call removed from header
• separate js var file included that holds things like the stylepath and the tooltip/accesskey array
• rtl css included from generated css

Translators: Many translated accesskey-XY and tooltip-XY messages need to be moved to the Monobook.js array, they are now deprecated. The remaining ones might follow soon.

I also changed the wording and key of the 'clear your cache' message as it's now also displayed above the prefs as well. A new string is qbsettingsnote.

To get the new files, a reload might be necessary (the usual reload in moz, ctrl-f5 in IE/Opera, cmd-r in safari). -- Gabriel Wicke 15:02, 9 Jun 2004 (UTC)

Tooltip for the "+" tab

Currently, the tooltip for the little "+" tab, which adds a section to a talk page, reads "Add a comment to this discussion". This is misleading for new users, however, since replying to somebody else's comment is also "adding a comment to the discussion", and this is not what the new section feature is intended for. The result is that new users who are not used to talk pages will add a heading just to say "yes", or somesuch. Here's an example.

Perhaps we could reword it to "Add a new section to this discussion page", or "Add a new heading to this discussion page", to highlight that a)individual comments don't usually have headings and b)the page is not necessarily one discussion. Thoughts, anyone? - IMSoP 14:56, 22 Sep 2004 (UTC)

It is a good idea. Do changes made here ever get back into MediaWiki or do improvements only benefit the English Misplaced Pages? Angela. 05:14, Oct 4, 2004 (UTC)

Good suggestion. I changed it to read "Start a new discussion." dbenbenn | talk 30 June 2005 13:43 (UTC)

Overloading of "d" shortcut

Currently, the "d" shortcut has two uses: (un)deleting pages and "show changes" on edit pages. I find this pretty confusing, so I turned off the first use in my personal Javascript. Perhaps this should be done site-wide, or one of them should be moved (e.g., "-" for delete)? -- Jitse Niesen (talk) 11:40, 20 August 2005 (UTC)

How about putting the FA stars after the language names?

imo the current positioning makes the list look rather odd. Plugwash 00:34, 30 September 2005 (UTC)

At the Vietnamese Misplaced Pages, we instead set the list-style-image property to be the star image, instead of the background-image. It seems to look a bit better. – Minh Nguyễn (talk, contribs, blog) 05:17, 11 October 2005 (UTC)

Featured article icon on vi:

Crossposted from Template talk:Link FA and Misplaced Pages talk:Featured articles. See those pages for more discussion on this proposal.

All featured articles and future feature articles at the Vietnamese Misplaced Pages have been marked with the Sao chọn lọc template, which adds a little star icon in the "namespace icon area" (various namespaces at vi: display icons at the top-right corner of the page). This can be accomplished thusly:

Assuming that the Link FA code has already been added to MediaWiki:Monobook.js, the following code should be added to the script, just below the Link FA code:

/* Configuration for "star" logo at the top of Featured Articles */ function StarFA() { if (document.getElementById("FA")) { // Monobook.css will take over styling from here document.body.className += " FA"; // Iterate over all <h1> elements - this loop is optional for (var i = 0; a = document.getElementsByTagName("h1"); i++) { // Apply a tooltip to the article title, which includes the little star if (a.className == "firstHeading") { a.title = "This article has gained featured status"; } } } } addLoadEvent(StarFA);

---

Then, add the following code to MediaWiki:Monobook.css:

/* Namespace icon area */ h1.firstHeading { background-position: bottom right; background-repeat: no-repeat; } /* Featured articles */ body.FA h1.firstHeading { background-image: url('http://upload.wikimedia.org/wikipedia/en/thumb/8/8c/Featured_article_star.png/16px-Featured_article_star.png'); }

---

Finally, create a template Template:Star FA that contains the following code:

<span id="FA" style="display: none" /> ]

And add transclude it into each page:

{{Star FA}}

This little logo isn't as intrusive as the meta-template that used to appear at the top of featured articles, but it still makes it easy to figure out if the article is of high quality, without having to load the Talk page.

If you are concerned about any potential impact on page loading time, just exclude or comment out the section marked "optional" in the JavaScript code above. If you enough people find this tip useful, I'll move it to a more widely read Talk page like Misplaced Pages talk:Featured articles.

You can see what this looks like in action at vi:Đệ nhị thế chiến.

 – Minh Nguyễn (talk, contribs, blog) 04:53, 6 October 2005 (UTC)

A function to help users install tools

I've written the following function to allow users to easily install tools written by other users. The function includes the specified .js page and sets the specified global variables, using code from Misplaced Pages:Tools/Navigation_popups#Installation. So, do we want such a function? Zocky 00:12, 1 November 2005 (UTC)

Usage

include_js (page_name,option1,value1,option2,value2, ...)

Arguments

page name:

the name of the .js page to be included, without the "User:" prefix and the ".js" extension.

option1, value1, ...

Pairs of option names and their values to set

Example

include_js ( 
 'Lupin/popupsdev',
 'popupAdminLinks', true,
 'popupStructure', 'menus', 
 'popupActionsMenu', true
);

Error messages

The user is alerted if they provide inappropriate arguments.

Caveats

Variables are set before the included script is run. Developers of tools should take care to check whether variables have been set by the user and set defaults only where necessary; use something like optionvar==undef && optionvar=defaultvalue;

Issues

• The name should maybe be changed to something like install_tool().
• Using globals for this doesn't sound like a good idea. Maybe options for all tools should be stored in an array, something like tools_options.

Source

function include_js(includedscript) 
{
  var i;
  if (include_js.arguments.length>0) 
  {
    document.write('<script type="text/javascript" src="'
                 + 'http://en.wikipedia.org/search/?title=User:' + includedscript + '.js'
                 + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
    i=1;
    while (i < include_js.arguments.length)
    {
      if (typeof(include_js.arguments) == "string" )
      {
        i++;
        if (i < include_js.arguments.length)
        {
          window] = include_js.arguments;
          i++;
        } else {
          alert ("Variable "+ include_js.arguments +" specified, but no value provided."); return; 
        } 
      } else {
          alert ("Bad name for variable"); return;
      }
    }
  } else { 
    alert ("No script name provided."); 
  }
}

Sorry, but this is hopelessly insecure. What's to stop me making a really useful tool, getting thousands of users to use it, and then replacing the tool script with an account hijacking script, stealing passwords and vandalising pages? The only way round this is some kind of secure accredited script inclusion system, but that would be quite a bit of work. Tom- 10:36, 1 November 2005 (UTC)

• The method of inclusion is already widely used by users. Puting it in a function doesn't make it any less secure than the current practice of users copying the chunk of code that does the same thing. There is nothing stopping you now from doing what you describe above and this function would not change that. OTOH, encouraging users to use a function like this would at least confine the scripts that get included to userspace.js pages, which are protected by default and are thus less prone to abuse.
• As for the other issue, about accredited scripts. We already list some tools on WP:TOOLS. I don't know if we have any formal process for quality assurance of tools included there. I would definitely support having such a system, especially if it provided a sane way for users to install tools. The technical side - a rudimentary API for installation and configuration - is quite straight-forward, but it would also require some kind of workflow guideline/policy for QA in order to work. Is there interest in such a project? How would we go about it? Zocky 11:27, 1 November 2005 (UTC)

Hey, good idea... :P Lupin|talk|popups 03:18, 6 January 2006 (UTC)

A very similar idea is already being discussed at Misplaced Pages talk:WikiProject User scripts#Towards a plugin system. One issue besides security is performance. Perhaps we can discuss the details further there? -- Jitse Niesen (talk) 13:13, 1 November 2005 (UTC)

Security need not be an issue. We can change the function so that it (optionally) links to a specific revision for the paranoid; besides, as others have already said, this is simply a utility function to make things slightly easier to install. It adds nothing new to exploit. I'm not sure I see the advantage of setting variables by passing them to this function over setting them in the file itself, though; this functionality could be removed. For example,

function include_js(script, oldid) 
{
    document.write('<script type="text/javascript" src="' +
                   'http://en.wikipedia.org/search/?title=' + includedscript + '.js' +
                   (oldid ? '&oldid=' + oldid :  ) +
                   '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
}

This function would allow safe inclusion of scripts in non-userspace (such as those in WP:WPUS) with a specific revision id.

I'd like to see a helper function of this type installed in a site-wide javascript file, not a skin-specific one like Monobook.js. Can we do that? Lupin|talk|popups 03:18, 6 January 2006 (UTC)

IE alpha transparency

If you add the following code to your personal monobook.js it fixes the internet explorer alpha transparency problem, why has not this been done before?

function correctPNG() // correctly handle PNG transparency in Win IE 5.5 & 6.
{
   var arVersion = navigator.appVersion.split("MSIE")
   var version = parseFloat(arVersion)
   if ((version >= 5.5) && (document.body.filters)) 
   {
      for(var i=0; i<document.images.length; i++)
      {
         var img = document.images
         var imgName = img.src.toUpperCase()
         if (imgName.substring(imgName.length-3, imgName.length) == "PNG")
         {
            var imgID = (img.id) ? "id='" + img.id + "' " : ""
            var imgClass = (img.className) ? "class='" + img.className + "' " : ""
            var imgTitle = (img.title) ? "title='" + img.title + "' " : "title='" + img.alt + "' "
            var imgStyle = "display:inline-block;" + img.style.cssText 
            if (img.align == "left") imgStyle = "float:left;" + imgStyle
            if (img.align == "right") imgStyle = "float:right;" + imgStyle
            if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle
            var strNewHTML = "<span " + imgID + imgClass + imgTitle
            + " style=\"" + "width:" + img.width + "px; height:" + img.height + "px;" + imgStyle + ";"
            + "filter:progid:DXImageTransform.Microsoft.AlphaImageLoader"
            + "(src=\'" + img.src + "\', sizingMethod='scale');\"></span>" 
            img.outerHTML = strNewHTML
            i = i-1
         }
      }
   }    
}
window.attachEvent("onload", correctPNG);

To test it out use Internet Explorer and log in as Username: AchilleIEtest Password: IE

Cheers —This user has left wikipedia 15:48 2006-01-30

Sounds like something that should be a normal part of one of the MSIE-specific style sheets. —Michael Z. 2006-01-30 18:14 Z

Stylesheet? I'm confused... can you execute Javascript from a stylesheet? —This user has left wikipedia 19:09 2006-01-30

The above works great for me on IE6. Why can't this be included in the main sheet? I've heard quite a few complaints about SVG backgrounds in IE, and having this by default would help a lot. Would it break non-MS browsers? Crotalus horridus (TALK • CONTRIBS) 06:16, 31 January 2006 (UTC)

It shouldn't mess up non-IE browsers as the code above detects IE before doing anything (so non-MS browsers with an unmodified user-agent should ignore it). This is assuming the window.attachEvent code is universal of course. —Locke Cole • t • c 06:36, 31 January 2006 (UTC)

If you wanted to modify the mediawiki, you could do this automatically. All that is happening here is that the image is wrapped in a span tag that includes 'filter:progid:DXImageTransform.Microsoft.AlphaImageLoader'. But this JS is an easy fix —This user has left wikipedia 07:29 2006-01-31

I guess I wasn't paying attention when I wrote "style sheet". I don't think everyone should be served up an extra 1.4 kB of code because Microsoft won't support PNG transparency. This belongs in the MSIE-specific javascript at /skins-1.5/common/IEFixes.js, but I have no idea where to edit that (maybe it's part of the MediaWiki software?). Also, many people do set their browser strings to MSIE so that they can use ignorant banking sites, etc. which don't want to support other browsers—will this script try to execute for these users? —Michael Z. 2006-01-31 16:04 Z

Sadly, 70% or so of Internet users are running IE. I think that having 1.4 kB of code served to users of standards-compliant browsers is a lesser evil than 70% of our users seeing PNGs (and SVGs, too, due to the way these are converted) rendered with an ugly blue background instead of transparency. Maybe I can cut down on the code by removing comments, shortening variable names, etc. Crotalus horridus (TALK • CONTRIBS) 17:28, 31 January 2006 (UTC)

I've only checked in firefox, but I'd expect the test for document.body.filters to exclude browsers which are just pretending to be IE. Lupin|talk|popups 16:52, 31 January 2006 (UTC)

Shouldn't there be a test for the existence of window.attachEvent, before you call it? I thought this wasn't defined in Firefox. -- Jitse Niesen (talk) 17:48, 31 January 2006 (UTC)

I don't mind this being put in here temporarily, to support MSIE users, but

1. It should be purely an interim measure, with a reference to a relevant MediaWiki bug report requesting that this be added to IEFixes.js, which is served only to MSIE.
2. Doesn't it belong in the main javascript rather than monobook, to work in all skins?

—Michael Z. 2006-02-08 18:41 Z

I found that this fix causes a weird text display bug. Look at this page in Internet Explorer with the IE Alpha Transparency fix, scroll all the way to the bottom and you'll see the text is all screwed up. In addition, if you try editing the entire page, it doesn't work because the edit box becomes completely broken. I don't know what in the above javascript code could be causing this bug, but it's not good... –T_if_eg_{o 00:46, 20 March 2006 (UTC)}

Autofocus

I removed the autofocus script for blank pages, per talk at Misplaced Pages:Village pump (technical)#Focus. It was very annoying and inconsistent—I already know how to use my browser; it only interrupts my work if a web site tries to grab the mouse and click a field for me, and only on some pages at that. That edit field already has an accesskey assigned too, control-comma focuses it in my browser (Safari). —Michael Z. 2006-01-30 18:13 Z

Special characters menu, removed

Why does this javascript write HTML which adds another javascript, which in turn writes HTML to add a menu to the page? This seems inefficient and fragile; shouldn't the HTML just be added to the page template?

And it appears to be added to pages chosen by a common word in their title! So this is intended to be added to the article about the "Hypertext Editing System"? Sloppy.

Finally, what does this do? I can't see any menu for secial ("special"?) characters in either Safari of Firefox. If no one can explain the purpose of this script, I will remove it. —Michael Z. 2006-01-31 16:17 Z

/* add menu for selecting subsets of secial characters */
//if(document.title.indexOf("Editing ") == 0) {
//document.write('<script type="text/javascript" src="' 
//             + 'http://en.wikipedia.org/search/?title=MediaWiki:Charset.js' 
//             + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
//}

The two slashes at the start of each line indicate C++ style comments, so this is not executed. The indirection is probably to save bandwidth: there is no need to transmit the script in Charset.js if it is not needed. And the condition in the if statement does not hold for the article Hypertext Editing System, only for articles whose title starts with "Editing". User:Brian0918 can probably fill you in on the details if you need to know more, as he has worked on it. But I agree that it can be removed, as it is dead weight at the moment anyway. -- Jitse Niesen (talk) 16:44, 31 January 2006 (UTC)

thanks for the explanation. I'll remove it; since it's now archived here, and can be replaced when it's ready. —Michael Z. 2006-01-31 16:52 Z

By the way, this test for Editing is still a poor way to detect edit pages. For example, see . Lupin|talk|popups 16:55, 31 January 2006 (UTC)

Bloat

I figure the entertainment that's been had by one or two authors in recent days on this page is the cause of th re-bloat to the editing tools box. Could someone please de-bloat that, quickly? It's really very unnecessary, and already met with resistance last time this was tried in the far more accessible edittools page. I'm on the point of reverting all the recent changes to achieve this.

Also, PLEASE STOP PLAYING WITH SUCH PAGES LIVE. Test it somewhere, in a local install or something. Mediawiki space IS NOT YOUR PLAYGROUND. -Splash 13:41, 17 February 2006 (UTC)

I looked at the history; the last edit was made on January 31, 2006. Are you sure you're on the right message? MediaWiki:Edittools might be where you meant to place this. —Locke Cole • t • c 13:43, 17 February 2006 (UTC)

Actually no, I have no idea what's changing the edit tools. But there's been no recent edits here or at MediaWiki:Edittools. —Locke Cole • t • c 13:46, 17 February 2006 (UTC)

Yes, I've been very confused by the strange appearances in the edittools box. I figured it must be this because it wasn't edittools, and I got month-lag looking at the history here. Apologies. -Splash 13:59, 17 February 2006 (UTC)

Broken templates - why?

This change broke a whole freakin’ lot of templates.( See Misplaced Pages:Village pump (technical) here and here for details.)
Why was this change made? Can that value please be changed back from 0 to 1? In fact, rather a lot of users would be happy to see it changed to 2 or even 3. -- WikidSmaht (talk) 04:59, 16 March 2006 (UTC)

Okay, I changed it back to 1. In my opinion, changes to this page should always be discussed first. I'm considering adding a warning to that effect, like the message at the top of MediaWiki:Monobook.css. -- Jitse Niesen (talk) 06:18, 16 March 2006 (UTC)

Thanks! Now maybe we should discuss changing it to 2 or 3... -- WikidSmaht (talk) 06:37, 16 March 2006 (UTC)

I'd like to change it to 3. -- User:Docu

Main Page

The Main Page hack needs to be tightened. It currently triggers for both history mode and anything which starts with "Main Page" (like Main Page alternate (Classic 2006)). It should both check the full page title and avoid doing anything if there is an action= parameter. --cesarb 05:23, 20 March 2006 (UTC)

Update Monobook.js to reduce redundancy

Please see "Updates to CSS and JS pages to reduce redundancy". --Melancholie 00:45, 24 March 2006 (UTC)

Suggest removing tooltips

The tooltips serve little purpose and take up a couple KB of the file. I suggest removing them. — ₀₉₁₈ • 2006-03-30 13:03

What a usability improvement! especially because all icons are really self-explaining...like this #R --Elian 09:37, 25 April 2006 (UTC)

Cologneblue.js

I was trying to make some changes to the above (see MediaWiki_talk:Cologneblue.js) to include features added here. How does it work? -- User:Docu

According to Misplaced Pages:Catalogue of CSS classes, only Monobook-derived skins have editable global javascript. Cologne Blue is not Monobook-derived. See also the discussion at MediaWiki talk:Edittools#Replacing charinsert with dynamic JavaScript, where this is mentioned. --cesarb 16:45, 9 April 2006 (UTC)

Main page

I know this is minor, but I think the main page tab should say "main page" and not "article", I've changed my JS so it says that, but want to ask around first before fooling with this one. I just don't think that the main page is really an "article". It links to many articles, and previews a few, but "main page" is not an article in itself.Voice-of-All 03:39, 13 April 2006 (UTC)

It is in the article namespace.Geni 17:26, 13 April 2006 (UTC)

Technically, it is in "article" namespace, since there is no "main page" namespace. Still, the URL just sais Wiki/ so nothing seems contradictory there. Also articles are named based on their title, there is no article called "main page"...it does not explain "main pages"...it is one, so it should be considered "Main Page" and not "article" I suppose.Voice-of-All 23:19, 13 April 2006 (UTC)

I'm fine either way. I don't mind the way it is now, but I would also be fine with changing it.--Alhutch 17:27, 13 April 2006 (UTC)

It's not a big deal, and just like Alhutch, I don't mind either way. Thanks! Flcelloguy (A note?) 19:21, 14 April 2006 (UTC)

Redirect edit button

I've changed how the redirect edit toolbar button gets added. The toolbar generation has been updated so the buttons show for current versions of Safari and Konqueror which support the necessary bits, and while I was in there I made it easier to add custom buttons in a slightly less hacky manner. (The extra button no longer will show in browsers which are detected as unable to run the toolbar.)

Note that the old code caused some weird incompatibility where the other buttons didn't function correctly in Safari or Firefox, I'm not totally sure why. --Brion 11:07, 17 April 2006 (UTC)

Move/rename

I think the name "move", while technically correct, is not the exact right choice to use. From what I get, the page history is moved to the other page, but it is basically renaming—and would be a simpler concept for new users to grasp, no? Would people be opposed to calling it "rename", or something along those lines? -Mysekurity 02:15, 18 April 2006 (UTC)

Renaming is "moving" pretty much. However moving is slighty more general. Moving from place to place in one namespace is like renaming. "Userfying" or any other namespace to namespace change is more like a "move". Still, I don't care much either way.Voice-of-All 07:18, 28 April 2006 (UTC)

I made a simple script that renames it to "rename" for all article namespace pages. I would support that.Voice-of-All 22:27, 11 May 2006 (UTC)

Thanks for responding. Maybe take this to the Village Pump (things usually get lost there unless you have concrete ideas). -Mysekurity 00:48, 12 May 2006 (UTC)