Jump to content

MediaWiki talk:Common.js/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3→Archive 5

What is the use of this message? Each tooltip had a message formerly. I tried to give a translation in the Spanish Wikipedia (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 [1]. 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 Wikipedia? 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)

I would love to have d moved to something else, like "-". I frequently use alt-d to access my address bar. — xaosflux Talk 23:12, 30 June 2006 (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 Wikipedia, 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 Wikipedia talk:Featured articles. See those pages for more discussion on this proposal.

All featured articles and future feature articles at the Vietnamese Wikipedia 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]; 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" /> [[Category:Wikipedia featured articles|{{PAGENAME}}]]

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 Wikipedia 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 Wikipedia: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://wiki.riteme.site/w/index.php?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[i]) == "string" )
      {
        i++;
        if (i < include_js.arguments.length)
        {
          window[include_js.arguments[i-1]] = include_js.arguments[i];
          i++;
        } else {
          alert ("Variable "+ include_js.arguments[i-1] +" 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 Wikipedia 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://wiki.riteme.site/w/index.php?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[1])
   if ((version >= 5.5) && (document.body.filters)) 
   {
      for(var i=0; i<document.images.length; i++)
      {
         var img = document.images[i]
         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... –Tifego(t) 00:46, 20 March 2006 (UTC)

This fix, in our Windows 2003 host environment, caused the edit article toolbar to break. The buttons no longer applied syntax to highlighted code. Did not affect Firefox. The toolbar buttons worked when the code was commented-out. Cedarrapidsboy 16:37, 17 July 2007 (UTC)

Autofocus

I removed the autofocus script for blank pages, per talk at Wikipedia: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

Autofocus is one of the worst usability choices one can make, I believe. I'm glad that we're not doing it. —Michiel Sikma, 12:29, 21 May 2006 (UTC)

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://wiki.riteme.site/w/index.php?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 [2]. 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. -Splashtalk 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. -Splashtalk 13:59, 17 February 2006 (UTC)

Broken templates - why?

This change broke a whole freakin’ lot of templates.( See Wikipedia: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
In the meantime, it was changed to 3 (May 10). A change that was reverted 10 days later (May 20) as another template (Template:Hidden) depens on the setting as well. Maybe we can find a way to arrange both. Not sure if a template hidden should depend on a parameter with a number .. -- 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. — 0918BRIAN • 2006-03-30 13:03

What a usability improvement! especially because all icons are really self-explaining...like this #R --Elian Talk 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 —The preceding unsigned comment was added by Docu (talk • contribs) 11:03, 9 April 2006 (UTC).

According to Wikipedia: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-AllT|@|ESP 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-AllT|@|ESP 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 [m!] 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-AllT|@|ESP 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-AllT|@|ESP 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 [m!] 00:48, 12 May 2006 (UTC)
I think this can also be changed by editing the text at MediaWiki:Move. That's probably a cleaner solution than a script, but it does change it for everybody. -- Jitse Niesen (talk) 01:13, 12 May 2006 (UTC)
I guess I just like tradition, but I prefer "move" better, and I'm not sure why. Perhaps it's the tone, or the monosyllabic appeal, but I like "move" better than "rename", though I don't mind either way. Thanks! Flcelloguy (A note?) 01:38, 12 May 2006 (UTC)
The purpose of a script would be that non-article space pages would have different text for those accustomed to it (like how article space pages say Article, the Main Page says Main Page, MW pages say Message, and WP namespace pages say Project on their tabs). I know you guys are all apathetic, and I care only slightly, but I think it'd be a good step towards more usability. When one right-clicks (or alt-clicks for our Mac bretheren) on an icon within their operating system, it says "rename". It would only be right to have this apply to WP as well. -Mysekurity [m!] 01:49, 12 May 2006 (UTC)
Certainly, IMO, rename seems more clear to newbies. I already use the script myself just to see what it is like.Voice-of-AllT|@|ESP 02:01, 12 May 2006 (UTC)
I agree that "rename" is clearer. Mysekurity, do I understand you correctly that you want different texts depending on the namespace? If so, could you please explain? It seems rather confusing to me to use different descriptions for the same function. -- Jitse Niesen (talk) 02:10, 12 May 2006 (UTC)
The script I made would make articles have a "rename" tab, where as project, help and portal pages (where moves are more serious (like AfD) and likely to result in double redirects and confusion and should not likely be moved by newbies anyway). Renaming articles is more likely a spelling/formality thing that for things like MediaWiki (where moving is really like file moving) and Images (when moving is supported).Voice-of-AllT|@|ESP 02:55, 12 May 2006 (UTC)
You seem to have forgotten the end of the first sentence, but I assume that your script does not change the name of the tab for project, help and portal pages. That would be confusing, in my opinion. You make a good point for MediaWiki name space, but that's a very special case: how often are those pages moved? -- Jitse Niesen (talk) 06:44, 14 May 2006 (UTC)
Rename is more clear and suggest that is is somewhat more minor that move. Project/portal pages are the true location of their topic, so renaming them is like moving them, and it creates a ton of double redirects, guarenteed. Articles are about a topic, but they are not the topic, there are usually 1 or a few correct possible titles. Articles are just articles, were as other namespaces either have serious technical effects to moving (MediaWiki, user JS, Images when they support it) or have a sense of location. WP:PP is at WP:PP, George Bush is not at Wikipedia's George Bush page. At any rate, new users shouldn't be moving projects anyway.Voice-of-AllT|@|ESP 06:54, 14 May 2006 (UTC)
I personally disagree. To me, "move" is more clear, as that's how I visualise it: the article being sort of pushed to a new location, leaving a redirect trail. IMHO, "rename" sounds like the article sort of stays in the same place, which it doesn't. Also, I guess I like "move" for historical reasons. I'm not diehard opposed to the change, but I certainly prefer "move" for my own preferences as well as being clearer.
As a further note, I don't really understand the logic of not having the tab be the same for all pages. Isn't that even less newbie friendly than it is now? "Why do I have these two different tabs for different pages? They seem to do the same thing, but they must be different because the label is different, etc..." In addition, you'd have to have another MediaWiki page, one that said "rename page" for the articlespace, one that said "move page" for everything else. I don't really get why we'd want that. Snoutwood (talk) 07:21, 14 May 2006 (UTC)
Oh, another note: If this goes through, don't forget to change the other skins to the new version as well. Snoutwood (talk) 07:22, 14 May 2006 (UTC)
My small script also changes "history" to "revisions" for articles, since that makes it more clear.Voice-of-AllT|@|ESP 19:10, 13 May 2006 (UTC)
  • Move sounds more approriate to me. I'd support implmentation of a Rename function, but would want to limit it's use to admins as the potential for vandalism would be high with it. Page moving may not be the most newbie friendly function, but it is also a function that can cause signifigant problems when done incorrectly, maybe it shouldn't be as friendly as the edit button. — xaosflux Talk 11:27, 14 May 2006 (UTC)
    • Page moves really should be like 95% semi rather than 99% of users, that would avoid much page moving nonsense. If anything is to be less freindly, it would be page moves for project pages/portals/help ect...that would cause even more trouble than the usual article move.Voice-of-AllT|@|ESP 19:36, 14 May 2006 (UTC)
  • The rename is fine by me. BrokenSegue 18:23, 14 May 2006 (UTC)
I prefer "move", perhaps because I am used to it, but... Prodego talk 21:30, 14 May 2006 (UTC)
I would keep "move" per Prodego, but I'd be in support of a rename function to be given to admins only which would be equivalent to a move w/o a redirect trail (or a move + deletion of the created redirects). I think this would be useful most espically in the case of userfication. --Charlie(@CIRL | talk) 23:56, 14 May 2006 (UTC)
Perhaps...but I would see "move" as the one that one that created no redirects, "moving" a templatate would make inline refs to it break and become red, whereas renaming them would just make the redirect work so it still shows inline. "Renaming" an article will make redirects to its new name; moving it would break links IMO. Either way, this is even more complicated than my original idea, which is what I would like to stick to. "Rename" for naming things that talk about things and can only have certain correct names, "Move" for pages that are their topic and are the location of the topic, that we at Wikipedia can rename, and that moving is more even likely to cause double redirects (try moving WP:AFD).Voice-of-AllTalk 03:17, 20 May 2006 (UTC)
  • shrugs* It seems to be simply a matter of intrepretation on how to define the terms at this point. Thinking abstractly about these actions, I think of "Rename" being an action where the article (file) has stayed in one place, just changed names, whereas "move" actually moves the article to a new location (therefore should create a pointer to the new location). Regards Charlie(@CIRL | talk) 04:41, 20 May 2006 (UTC)

I support renaming it "rename". "Move" implies relocating something in physical space, which is a decent UI metaphor for the process, but "rename" is direct, not metaphorical, and in my opinion provides for a more intuitive user interface. — Phil Welch (t) (c) 11:44, 15 May 2006 (UTC)

In this case short=better.Geni 12:04, 15 May 2006 (UTC)

Request: Edit L/R for diffs

I'm not sure how easy of a hack this would be, but I think it would be a really cool feature if when viewing diffs instead of having a single (slightly ambiguous) "edit this page", we could have an "edit left version" and "edit right version". I would find it very helpful espically when viewing diffs for fighting vandalism. Thoughts/Comments? Charlie(@CIRL | talk) 04:46, 20 May 2006 (UTC)

And perhaps a revert to this version of the current (good for diffs where several editors vandalized)...I was thinking about this for a while...but just used popups....I'll get to work on the script (though it would be a personal thing), I will also make an edit button, (not just revert).Voice-of-AllTalk 04:50, 20 May 2006 (UTC)
Awesome! You rock --Charlie(@CIRL | talk) 05:15, 20 May 2006 (UTC)
I actually programmed this a while ago. The following fragment adds "edit" links to the left and right diffs, when inserted in your monobook.js :

function addOneEditLink(hd)
{
   // first node is <strong><a href="..."> ... </a></strong>
   var node = hd.childNodes[0];
   var href = node.childNodes[0].attributes.getNamedItem('href').value;

   // add a space and a link to the edit page
   var link = document.createElement('A');
   link.href = href + '&action=edit';
   link.appendChild(document.createTextNode('(edit)'), null);
   hd.insertBefore(link, node.nextSibling);
   hd.insertBefore(document.createTextNode(" "), node.nextSibling);
}

function addEditLinks() 
{
   if (window.location.href.indexOf('&diff=') != -1) {    
      // in a diff page, so add edit links 
      addOneEditLink(findthe("//TD[@class='diff-otitle']"));
      addOneEditLink(findthe("//TD[@class='diff-ntitle']"));
   }
}

addOnloadHook(addEditLinks);


Is this similar to what you were looking for? -- Jitse Niesen (talk) 06:07, 20 May 2006 (UTC)

I've finished a script that adds "edit this version" and "restore" to the older version (left side) for all admins. I would like to implement this in MediaWiki.Voice-of-AllTalk 18:07, 20 May 2006 (UTC)


It would IMHO be preferable to implement this directly in MediaWiki rather than by JavaScript.  I've submitted a patch for this at bugzilla:6125.  —Ilmari Karonen (talk) 22:24, 28 May 2006 (UTC)



Proposal: striped table CSS class + JS


Hey all. I thought that people who watch this page may be interested in a proposal that I've posted on Wikipedia:Village pump (proposals) about striping wikitables. It involves changing CSS and JS. It's posted here: Village_pump_%28proposals%29#Proposal:_striped_table_CSS_class_.2B_JS. —Michiel Sikma, 05:21, 22 May 2006 (UTC)



Dynamic Navigation Bars - default setting


How can I set a dynamic navigation bar's default setting to "Show" rather than "Hide"? Thanks, Rfrisbietalk 07:57, 25 June 2006 (UTC)



I'm working on some modifications to the NavBar code, and a way to do this can be supported if/when those changes are rolled in. Gimmetrow 13:13, 4 July 2006 (UTC)


User Logs in toolbox


I've shown the js to Xaosflux, who suggested I mention it here for possible inclusion:

Basically, the code adds "User logs" to any userpage or talkpage. I've used it for a while now and it looks stable.



/* Adds "User logs" to the toolbox. */
/* Coded by [[User:Bookofjude]], requested
   by [[User:Kylu]]. */
addOnloadHook(function () {
	if (document.getElementById('t-contributions')) {
		z=document.getElementById("content").childNodes;
		for (var n=0;n<z.length;n++) { 
			if (z[n].className=="firstHeading") var username = z[n].textContent.replace(new RegExp('User(?:[ _]talk)?:([^/]*)', 'g'), '$1');
		};
		var toolbox = document.getElementById('p-tb').getElementsByTagName('ul')[0];
		var link = document.createElement('a');
		link.href = '/w/index.php?title=Special:Log&user='+username;
		link.appendChild(document.createTextNode('User logs'));
		var li = document.createElement('li');
		li.appendChild(link);
		toolbox.appendChild(li);
	}
});



(Other location: User:Kylu/userlog.js) ~Kylu (u|t)  04:31, 27 June 2006 (UTC)



  • Strong Oppose - GeorgeMoney (talk) (Help Me Improve!) 18:18, 29 June 2006 (UTC)

    • Why? Voting is evil, especially when there's no comments to indicate why you don't like it. Titoxd(?!?) 22:33, 30 June 2006 (UTC)

      • Why?. Because a) if we really wanted to do a user log thing, we should integrate it into mediawiki just like the "user contributions" link. b) this is really useful, yes (and I have a different version in my monobook), but some people might not like it; if we keep putting "useful" stuff in the global js file, then there will be so many scripts running, that it will be useless. c) I really don't get this "coded by bookofjude, requested by kylu" business; First of all, "requested by anyone" is not very important and it should be removed; also, i'm sure that not only bookofjude could have written that; for example, I could go ask any of the JS programmers here "can you make a script that adds a user log button to the toolbox" and they would be able to do it, and if I added "requested by GeorgeMoney" it would kinda seem like an easy way to get my name into the global js file; it would be like saying "1/342 of the code was written by bob", completely irrelevant. d) if people disable js in their browser, then they won't be able to use this; like I said before, we don't want the entire project running on JS. --GeorgeMoney (talk) (Help Me Improve!) 00:42, 1 July 2006 (UTC)


  • An easy way to get my name into the global js file? I rather assumed to trim down the size of the loaded scripts that unneeded comments were pruned anyway. Hadn't actually looked, but way to assume good faith. :) The main reason the comments are there is so that people understand:


  1. Bookofjude wrote it and this is where the skill came from, and
    2. 

  2. I requested it, so while it's my responsibility, I don't quite understand it all (the regexes give me trouble, I'm sad to say.)


It's convenient, but not strictly needed. If it doesn't fly with people in this discussion (it's not a vote), the code's still sitting here and people are free to copy-paste into their own monobook and use it.


~Kylu (u|t)  05:34, 2 July 2006 (UTC)



  • It's still not a vote, but thanks. c.c;; Hey, George, if you've got a similar script, maybe we could take a peek at it, hey? Drop a direct link so the lazy among us don't have to dig through your monobook. :) ~Kylu (u|t)  23:06, 2 July 2006 (UTC)


      • The script was in my monobook until I installed lupin's antivandal tool, and that added 4 more links to the toolbox, so I had to remove it, and remove some links through CSS. GeorgeMoney (talk) 01:45, 4 July 2006 (UTC)


  • Oppose - I'm changing back to oppose, because it adds an extra link to the toolbox, and the only "benefit" is that it saves 1 less click. All you have to do is press the "user contributions" link, and then press the "logs" link at the top. I really don't think we have to sacrifice an entire space, to save a click. Also, nobody added any id's to it, so people can't make it disappear through CSS even if they wanted to. GeorgeMoney (talk) 01:45, 4 July 2006 (UTC)


  • Okay George, you don't like it. It probably won't get included, then. You're good at this CSS/JS stuff, so can you show some changes so those of us who do like it can make it better? I seem to recall you said something about you having your own version of it, but atm I can't check. (wikipedia'ing instead of working! :D ) Thanks! ~Kylu (u|t)  16:39, 4 July 2006 (UTC)





  • Happened the first time I used it also, I've not quite figured that out, but on a hard refresh the problem went away and hasn't come back. Suggestions welcome. :) ~Kylu (u|t)  05:34, 2 July 2006 (UTC)


  • I don't support this because it will cause all kinds of people's user scripts to mess up or have duplicates. What I would support is making custom JS more accessable to new users, like having a good centralized place for all major scripts, and what they do, kind of like the nagivation popups project page.Voice-of-All 03:18, 5 July 2006 (UTC)


  • I still like the idea of having an inc(); function available globally, myself. I know the security concerns, but think people should be responsible for their own js security. Worst case scenario, they log out and post anonymously that their js is broken?  ~Kylu (u|t)  18:00, 7 July 2006 (UTC)


Dynamic Navigation Bars


I wanted to do inline toggle switches but was unable with the current navbar code. The toggle text style.display really should be 'inline' rather than 'block' to allow for this.  It would be nice to be able to specify alternate hide/show texts, and I was able to hack that though the title attribute. What's the better way? Also, the NavHead tags seem to need a nbsp, but the toggle text is placed after the nbsp, and this causes some odd alignments especially for left-justified text. (Using .insertBefore instead of .appendChild, would cause the same problem for right-justified text.)  Suggestions? Is the experimantal (sic) navbar code still open to experiments? This is what I have so far. Since this uses the title attribute to do what I want, I don't think it breaks existing templates or anything that doesn't use titles, but of course this would need testing. Gimmetrow 01:15, 1 July 2006 (UTC)

[obsolete code removed by Gimmetrow]



Playing with it now, I'll get back to you on it. ~Kylu (u|t)  05:51, 2 July 2006 (UTC)


Cool. Just so it's clear, I want to be able to have a line that looks like:



That expands to look like:



The idea of my code is to allow this to be implemented with something like below.  Gimmetrow 10:33, 2 July 2006 (UTC)


<div class="NavFrame" title="Compress"><span class="NavHead" title="Group1"> </span>
First:<div class="NavContent" title="inline" style="font-size:80%;">Some : Text :</div>Last</div>




Also, it would be nice to be able to specify some NavBars as shown, others as hidden. The current code hides all if there are more than one. This seems slightly odd, because a NavBox could be designed with one toggle intending text to be shown by default, but if it is used on a page with an unrelated NavBox it will be hidden by default. One way of doing this is to create another tag, <span class="NavShow"> </span>, that indicates the code to toggle this NavBox, but it would have to be ignored (or treated as a "hide") when there is only one NavBox on the page. Gimmetrow 13:25, 4 July 2006 (UTC)



I'm afraid I had to disable it. I'm not sure why, but for some reason it seemed to slow down my browsing considerably. Perhaps it doesn't like some of my other scripting? I didn't leaktest it yet, but will check soon. ~Kylu (u|t)  16:20, 4 July 2006 (UTC)

What do you mean by "it"?  What can we do?  I've tested the code given above mostly using a local version with different function names - if anything is slower this should be noticeable as it creates a different type of navbox.  Didn't notice anything substantial on two different systems. I've made some changes that reduce the amount of string processing, which might help. If you want to try my local version, see User:Gimmetrow/dynabars.js  Test samples at User:Gimmetrow/sand  Gimmetrow 16:39, 4 July 2006 (UTC)


Sorry I wasn't more clear: I meant "it" as in my local copy of the script I was playing with. Considering I'm loading around 1.2MB in scripting (yes, seriously) across three domains (last I checked) while wikibrowsing, I imagine it may well be more of this being the straw that broke the camel's back, rather than anything actually wrong with the scripting. I'll retest the script later, thanks! ~Kylu (u|t)  17:08, 4 July 2006 (UTC)

No, it is probably the getAttribute calls, I just didn't think this would be that much worse than what the code already does. I will work on a different approach over the next few days. Gimmetrow 03:06, 5 July 2006 (UTC)

Trying a different approach.  Could you give User:Gimmetrow/dynabars.js a try and let me know if it still causes a major slowdown?  Also, is there an easy way to identify popup windows so the dynabar code not try to process them? Gimmetrow 16:45, 7 July 2006 (UTC)


Will do. As far as Popups goes, I know Lupin uses a custom css for popups... User:Lupin/navpop.css I think? There's also a "development" version of the css, though, and I don't recall where it is. I figure, check and see if his css tags are extant in the window, and if so, don't use the dynabars. I'm css-retarded, so will let you figure out what I'm trying to say. Oh, you might want to talk to him too. :D ~Kylu (u|t)  18:05, 7 July 2006 (UTC)


Another thing that would be great if we can 'expand/collapse' certain things with a + and - instead of show/hide. GeorgeMoney (talk) 18:45, 9 July 2006 (UTC)

For your own use, just put in your monobook.js



  • NavigationBarShow = '[+]'; NavigationBarHide = '[-]';


Then every hide/show box will use these texts. As far as I know, with the current code there is no way to have these texts vary with different navboxes. This is another feature supported by my test code as shown above. However, using a specific text for hide/show in a navbox would prevent users from choosing different language texts. Although this is an English wikipedia, such a feature may not be desirable. Gimmetrow 18:44, 17 July 2006 (UTC)



Just FYI, the new code seems to work fine. Figured I'd let you know. (Testing off-wikipedia, btw) ~Kylu (u|t)  23:24, 5 August 2006 (UTC)


Where can I find out more


Where can I learn more about my Monobook.js file, such as neat tools I can install and how to write my own?  --Ideogram 06:28, 3 July 2006 (UTC)



Check out WP:JS. ~Kylu (u|t)  07:02, 3 July 2006 (UTC)


Oooh, cool.  I have a lot of reading to do :-). --Ideogram 07:43, 3 July 2006 (UTC)








Retrieved from "https://wiki.riteme.site/w/index.php?title=MediaWiki_talk:Common.js/Archive_1&oldid=1017836081"