MediaWiki talk:Common.js/Archive 2

message: For the main page hack that removes stuff on the main page, why not just use the page title mentioned in the HTML header of every page?
For example, this was on this page in the html sourcecode:
		<script type= "text/javascript">
			var skin = "monobook";
			var stylepath = "/skins-1.5";
			var wgArticlePath = "/wiki/$1";
			var wgScriptPath = "/w";
			var wgServer = "http://en.wikipedia.org";
                        
			var wgCanonicalNamespace = "MediaWiki_talk";
			var wgPageName = "MediaWiki_talk:Monobook.js";
			var wgTitle = "Monobook.js";
			var wgArticleId = 725652;
                        
			var wgUserName = "GeorgeMoney";
			var wgUserLanguage = "en";
			var wgContentLanguage = "en";
		</script>
		               
.
GeorgeMoney  (talk) 22:03, 4 August 2006 (UTC)
replies: text: We in Kazakh wiki use like:
// BEGIN Remove weird mainPage titling
// var wgPageName - from global variables on HTML header of every page
var isMainPage = (wgPageName == "Main_Page");
var isDiff = (document.location.search && (document.location.search.indexOf("diff=") != -1 || document.location.search.indexOf("oldid=") != -1));
if (isMainPage && !isDiff) 
{
 document.write('<style type="text/css">/*<![CDATA[*/ #lastmod, #siteSub, #contentSub, h1.firstHeading { display: none !important; } /*]]>*/</style>');
}
//Main page tab no longer says article
function mainpg() {
      if ((isMainPage || /[\/=:]Main_Page/.test(document.location)) && document.getElementById('ca-nstab-main')) {
            document.getElementById('ca-nstab-main').firstChild.innerHTML = 'Main Page';
      }   
}
addOnloadHook(mainpg);
--AlefZet 11:17, 17 August 2006 (UTC)

text: I support this. Many browsers that have javascript disabled probably do not have css disabled. I have not used any browser that lets you disable CSS (if it has CSS in the first place) so the amount of users affected by this "hack" will be higher. It would also be much cleaner and easier to update by moving it to the monobook.css file. GeorgeMoney  (talk) 01:54, 18 December 2006 (UTC)
thread_title:  Main Page Hack 

message: Is javascript even needed for some of this anymore? Per rev:17119 there is now a css class for each page.
The following, hypothetically, could be added to MediaWiki:Monobook.css:
 body.page-Main_Page #lastmod, 
 body.page-Main_Page #siteSub, 
 body.page-Main_Page #contentSub, 
 body.page-Main_Page h1.firstHeading { display: none !important; }
As this section is UNDOCUMENTED and UNMAINTAINED, perhaps it should be removed and started over, with appropriate use of the javascript variables, as well as taking advantage of per-page CSS support. IMHO --Splarka (rant) 07:39, 17 December 2006 (UTC)
replies: text: I support this. Many browsers that have javascript disabled probably do not have css disabled. I have not used any browser that lets you disable CSS (if it has CSS in the first place) so the amount of users affected by this "hack" will be higher. It would also be much cleaner and easier to update by moving it to the monobook.css file. GeorgeMoney  (talk) 01:54, 18 December 2006 (UTC)
thread_title: Main Page Hack, pII

message: I'm not sure if this is the right place to report this, but the worst that can happen is someone will say 'This isn't the right place to post this'. Anyway, I'm using Internet Explorer 6, and the content boxes on the history pages, and 'My Contributions' are compressed so that I can't see the text. I'm wondering if this is a problem that everyone with Internet Explorer 6 gets, and if this is something that can be fixed here?--Jcvamp
: Erm, I don't know, but try Wikipedia:Village pump (technical). Snoutwood 21:23, 10 January 2007 (UTC)
thread_title:  History and 'My Contributions' 

message: Please change ta['ca-nstab-wp'] = new Array('c','View the project page'); to ta['ca-nstab-project'] = new Array('c','View the project page');. That is the name of the Project tab. Thank you. --Thunderhead 09:21, 16 August 2006 (UTC)
replies: text: Done, thanks for the note. -- Jitse Niesen (talk) 10:46, 16 August 2006 (UTC)
replies: text: Thank you. --Thunderhead 15:33, 16 August 2006 (UTC)
thread_title:  Accesskey for project page 

message: fr.wikipedia.org uses a nice hack in its monobook.js to add a toolbar button which opens a little popup window to ask for table dimensions, and to insert the table as wikitext into the edit box. Try it out by editing a page and clicking the table button (first from the left). Should we copy this idea?--Eloquence* 14:14, 25 August 2006 (UTC)
replies: text: Well, if there is no objections to this, we should try it out. I do not see any harm in doing this as well. --Siva1979Talk to me 05:25, 26 August 2006 (UTC)
replies: text: Actually much of the stuff here would be very useful for basic editing too.Voice-of-All 10:12, 26 August 2006 (UTC)
replies: text: I've implemented all of these.Voice-of-All 19:13, 24 September 2006 (UTC)
thread_title:  Popup table generator 

message: See . Within these scripts there is also a simple script ("Reference divs") that makes the auto-generated references appear with a scrollbar so that they won't take up so much room. I'd like to add this here.Voice-of-All 10:05, 26 August 2006 (UTC)
thread_title:  Reference navbar 

message: The new "section 0 edit link" is really ugly and messes up alot of pages pushing text a long way. It is really obtrusive and messes with already installed scripts.
If you do want to add one please add it higher so it doesn't mess up anything else and remove that part from the monobook.css you can add it to the div's style.
Why not use Wikipedia:WikiProject User scripts/Scripts/Edit Top which is much better coded and more stable, and doesn't intrude.
This really messes everything up, especially userpages and some articles.
GeorgeMoney  (talk) 01:21, 3 September 2006 (UTC)
replies: text: OK, it was removed for now.  Let's see what other people say. —Mets501 (talk) 01:32, 3 September 2006 (UTC)

text: Yes, this new code created links in some odd places on some pages (in Safari 2.0.4). However, Edit Top, which I have been using, doesn't have a look consistent with the other edit tabs. I agree this should be part of the site software, however it also shouldn't be beta tested live on the site. I've been asking for two months to have my own codes tested and rolled in... Gimmetrow 01:46, 3 September 2006 (UTC)

text: I've tried the updated version of Edit Top and the edit tab seems to be consistent with the others on the page. The edit link is showing up on diff and history pages, however. Gimmetrow 03:53, 3 September 2006 (UTC)
replies: text: Well, for reference, here is the old Edit Top script:
function edittop() {
  if(document.getElementById("wikiPreview") || window.location.href.indexOf("/wiki/Special:") != -1) return;
  var pageTitle = document.title.split(" - ")[0].replace(" ", "_"); 
  var divContainer = document.createElement("div");
  divContainer.innerHTML = '[<a href="'+phpurl+pageTitle+'&action=edit§ion=0" title="'+document.title.split(" - ")[0]+'">edit top</a>]';
  if(window.location.href.indexOf("&action=edit") == -1)
    document.getElementById("content").insertBefore(divContainer, document.getElementsByTagName("h1")[0]);
  if(window.location.href.indexOf("&action=edit§ion=0") != -1)
    document.getElementById("wpSummary").value = "/* Intro */ ";
};
GeorgeMoney  (talk) 04:04, 3 September 2006 (UTC)

text: If people really want to do this, it should probably be on the right side of the page above the border-bottom for the headline for the section you will be editing, like the other section-edit edit links are. Personally I would never use it, but from answering help desk questions it does seem to be a point of confusion for at least a few people, some even thinking the top section was some locked section only editable by special people. - cohesion 17:46, 5 September 2006 (UTC)
thread_title:  oh no! 

message: I would like this funtion to be included so it's easier for users to include user scripts. —The preceding unsigned comment was added by AzaToth (talk • contribs).
/*Takes the wikipage "page" and includes it's raw text as javascript.*/
function import_external(page){
    if( document.createElement && document.childNodes ) {
        var url = 
            'http://en.wikipedia.org/w/index.php?title=' + 
            page + 
            '&action=raw&ctype=text/javascript';
        var scriptElem = document.createElement('script');
        scriptElem.setAttribute('src',url);
        scriptElem.setAttribute('type','text/javascript');
        document.getElementsByTagName('head')[0].appendChild(scriptElem);
    }
}
*I don't know, is this generally done for user scripts?  The script would break on non-monobook skins, and there is no common site-wide local javascript.  Would it be fine if users just added this helper script when they are using scripts that call it? —Mets501 (talk) 18:14, 21 September 2006 (UTC)
thread_title:  Helper function for user scripts 

message: I have removed the "add table" button from the toolbar. As a piece of code it is incomplete (the popup it generates is awful), and the tables it makes are equally poor. If you are going to develop new components, please submit them to the community for review and debugging before adding them to the core javascript. I don't object to have a table generator - but we can do much better than a quick hack. Thanks, ed g2s • talk 13:55, 29 September 2006 (UTC)
replies: text: As I noted on your talk. That button was already disabled (by me). --Ligulem 14:01, 29 September 2006 (UTC)
replies: text: Cross post: Hmm, odd. It was still showing up on my toolbar. After my edit I did a hard refresh and it went away - so unless my cache was two days old (possible) - your commenting might not have been enough. Anyway, no harm done. ed g2s • talk 14:04, 29 September 2006 (UTC)
replies: text: Cross post: :Yes, you did have had an outdated cache, as the button already went away thanks to my edit. I'm going to revert your edit, if you don't mind. We either disable that code on the top-most level (as I did it with my edit), or we remove that stuff completely. Keeping some brain dead code there serves not much purpose. --Ligulem 14:08, 29 September 2006 (UTC)

text: First a simple IE detector need to be added. If a user is using IE, then the button should be disabled. As for table appearance, anyone is welcome to fix it with something that looks prettier.Voice-of-All 20:01, 30 September 2006 (UTC)
replies: text:  My mentioned version has that feature, for IE (Opera too) the button makes only table sample syntax (from MarkS). (p.s. I don't tested IE for window open, because this function also don't works with my expanded function method) --Olliminatore 20:26, 30 September 2006 (UTC)
replies: text: Ok I simplified the code, and it does not seem to crash IE either. The talble now uses the pretty and simple wikiclasses.Voice-of-All 20:33, 30 September 2006 (UTC)
replies: text:  You forgot to remove   from TABLE CAPTION and |----- to |- --Olliminatore 10:37, 1 October 2006 (UTC)

text:  It crashed my version of IE (IE 6) about 5 minutes ago. Someone who know how should definitely disable the button in IE until the problem is fixed. (It doesn't always crash IE, just sometimes; it's worked for me before, so testing it once in IE isn't enough to indicate the end of the problem.) 147.188.147.47
Why not just the standard control for generating a table you get in word editors, like this? That's just a demo I knocked up in half an hour, but you get the idea. ed g2s • talk 11:08, 2 October 2006 (UTC)

text: Wow. Cool! --Ligulem 11:20, 2 October 2006 (UTC)
replies: text:  Yes, that looks cool, can "you" make this function (with headline and item column option) to a  corresponding popup window? That would be it. --Olliminatore 15:45, 4 October 2006 (UTC)
thread_title:  Table button 

message: Just a note to all. I have archived some of the contents of this page. If anyone has any objects over this, please feel free to state your concerns. --Siva1979Talk to me 04:38, 25 September 2006 (UTC)
thread_title:  Archive 

message: I propose we add:
addOnloadHook(function(){
if(document.getElementById('noarticletext')) {
var pgs = wgPageName.replace(/_/g, " ");
document.title = pgs+" - Page Not Found - Wikipedia, the free encyclopedia";
document.getElementById('searchInput').value = pgs;
}
});
Which does:
*Adds a "page not found" message to the page title (which is pretty useful, because sometimes I open many pages in tabs and want to know if any are non-existant)
*And adds the page title into the search box just incase someone typed something wrong and wants to fix their mistake.
GeorgeMoney  (talk) 05:56, 28 September 2006 (UTC)
replies: text: Both of these should be submitted to bugzilla as enhancements and implemented in PHP, not JavaScript hacks. ed g2s • talk 21:38, 7 October 2006 (UTC)
thread_title:  Page not found 

message: Is there a reason that the code here doesn't use addOnloadHook that's defined in wikibits.js?  Instead, addLoadEvent is defined and used.  They would seem to do the same thing, but I might be missing a difference since I'm not very knowledgeable about JS.  --68.142.14.91 14:59, 28 September 2006 (UTC)
replies: text: I think the sequencing is in some cases, sensitive and decisively. --Olliminatore 10:11, 3 October 2006 (UTC)
thread_title:  addLoadEvent versus addOnloadHook 

message: The extra buttons in the toolbar, though useful, are causing serious lag in the edit page load time. I first tried adding these extra buttons (stolen from the Hebrew Wikipedia) several months back, and noticed the problem then, as did others. The problem still exists. Currently, for me at least, the toolbar takes 5+ seconds to load. — BRIAN0918 • 2006-10-11 02:25Z
:I've never had them take 5 seconds, odd.Voice-of-All 04:50, 11 October 2006 (UTC)
replies: text: Me neither. IIRC I noticed a very minor lag the first time they had to load (but far below 5 seconds). Since then, they are in the cache of my Firefox 1.5.0.7 (Windows XP) and everything loads immediately (I still have them right now even though they have been removed already by Brian0918, because I didn't force a cache update yet). --Ligulem 08:42, 11 October 2006 (UTC)
replies: text: These should really be added back. The toolbar can be disabled via prefrences. Many other wikipedias, like RU and FR, already have such buttons. I don't see a need to remove a few very useful sitewide buttons due to one user having them take too long to load.Voice-of-All 16:21, 15 October 2006 (UTC)
replies: text:  Does the loading of the toolbar prevent editing? If not I don't see a problem with it loading so slowly. Even the standard toolbar can take 2 or 3 seconds to load when I'm running BitTorrent in the background. —Ruud 16:35, 15 October 2006 (UTC)
replies: text: No, it just loads in the background. Actually, the bar loads near instantly, its the images that take a while sometimes, but it does not hang the page or anything, they just appear one by one.Voice-of-All 16:39, 15 October 2006 (UTC)

text: Please restore the extra buttons. They were very helpful. I experienced no delay in the edit box opening, and did not notice any delay in the button graphics being rendered (but a 5-second delay in that, if there was one, would not delay my editing). Finell (Talk) 07:22, 16 October 2006 (UTC)
replies: text: I agree: Bring back the buttons! They are very useful, and the only delay present is caused by loading the images. Albany NY 13:22, 16 October 2006 (UTC)

text: I'd like for someone to add them back soon.Voice-of-All 22:45, 1 November 2006 (UTC)

text: Seems to work, except that it doesn't remove the "make table" button. —Ruud 23:22, 5 November 2006 (UTC)
thread_title: Toolbar extras

message: The access keys don't work in the newly released Firefox 2.0 :( 555pt | msg | msg on w:pt 04:27, 24 October 2006 (UTC)
replies: text: Use the Shift key as well. --TheParanoidOne 09:34, 24 October 2006 (UTC)
replies: text: Er... Shift? If I press Shift+P in a edit box I get the P, not the preview page o.0 555pt | msg | msg on w:pt 17:27, 24 October 2006 (UTC)
replies: text: You missed the "as well" part. Normally your would type Alt+P but with FF2 you need to do Shit+Alt+P. --TheParanoidOne 19:14, 24 October 2006 (UTC)
thread_title:  Firefox 2.0 

message: Please make this change so that collapsible tables will display correctly in Internet Explorer:
Line 278:	Line 278:                                                                          	Line 278:	Line 278:
    	var ButtonText = document.createTextNode( collapseCaption );                       	    	var ButtonText = document.createTextNode( collapseCaption );
    	                                                                              	    	 
-        	Button.setAttribute( "style", "float: right;" );                                   	+        	Button.style.styleFloat = "right";
    	                                                                              	+        	Button.style.cssFloat = "right";
    	ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );                    	    	ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
    	ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );	    	ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );
;Notes:
*Original code: Setting the style attribute works in Mozilla, but IE forgets it.  The result was that the triangle appeared immediately to the left of the header text in IE.
*Patched code: Assigning the style as an attribute forces IE to remember that the element should be floated.  Mozilla ignores "styleFloat" and will still display the triangle correctly; IE ignores "cssFloat" and will still display the triangle correctly.  
*I have tested this patch on a local, bleeding-edge copy of MediaWiki from SVN using IE6 and Ffx2: no browser recorded a javascript error.
*From my experience coding this and the above source, I believe that this patch will work on all browsers.
—Cheers, DavidHOzAu 05:58, 7 November 2006 (UTC)
replies: text: I "committed" your patch. —Ruud 19:41, 7 November 2006 (UTC)
thread_title:  Collapsible tables fix for IE 

message: What do people think of the pl.wiki's "auto edit summary" thing? (See  for example, and try clicking on one of the green boxes below the edit summary field.)  Is it worth implementing here?  It might encourage people to use edit summaries more, because it'll be very easy to add.  It will probably also help newbies who aren't sure what to type in the edit field by giving examples. —Mets501 (talk) 18:22, 7 November 2006 (UTC)
replies: text: We now have that to some extent, thanks to Automatic edit summaries, which was recently checked in. What the Polish Wikipedia's doing sounds neat, though. – Minh Nguyễn (talk, contribs) 08:06, 20 November 2006 (UTC)
thread_title:  pl.wiki edit summaries 

message: According to the Signpost, this page is now deprecated.  All of this should be copied to MediaWiki:Common.js, and all of the stuff that we still want to keep specific only to Monobook.js should be added using a skin test with the skin variable. —Mets501 (talk) 21:19, 21 November 2006 (UTC)
replies: text: Looks like it's already working.  (eg.  mentions that it's pulling its data from both MediaWiki:Common.js and MediaWiki:Monobook.js).  If there's no monobook.js-specific code here, can we just move this page there?  --Interiot 21:36, 21 November 2006 (UTC)
replies: text:  I've moved the page, but it doesn't seem to work. Also  seems to be expanded now, I believe it didn't do that before. —Ruud 22:55, 21 November 2006 (UTC)
replies: text: Does this mean that now we can use show/hide boxes and they will work for everyone using any skin? —Mets501 (talk) 23:49, 21 November 2006 (UTC)

text: Copied (not moved) the JS back to MediaWiki:Monobook.js for now. If common.js suddenly does start working, the code might be included twice, perhaps with worse sideeffect than having no JS for a while. —Ruud 00:05, 22 November 2006 (UTC)
replies: text:  This edit shows up  for me.  I think it's working, but maybe needs some waiting time or an action=purge?  --Interiot 00:10, 22 November 2006 (UTC)
replies: text:  It now works here as well. —Ruud 00:16, 22 November 2006 (UTC)
replies: text:  Works here too. —Mets501 (talk) 00:22, 22 November 2006 (UTC)
thread_title:  Copying to [[MediaWiki:Common.js]] 

message: Exactly what does this do and why isn't it in /skins-1.5/common/IEFixes.js? —Ruud 15:22, 26 November 2006 (UTC)
thread_title:  IE fix? 

message: Should we remove adLoadEvent, as it only duplicates the functionality of addOnloadHook (defined in wikibits.js). This will break the user scripts of a few dozen users. —Ruud 15:51, 26 November 2006 (UTC)
replies: text: Maybe make it a thin wrapper around the latter at first, and add a comment about it being deprecated.  Do the same here and here, and fix the call here.  Then contact the [ users still using it] and suggest they change their scripts, and wait a bit.  Before finally removing it completely an admin can fix the remaining instances, but it's probably more polite to ask before poking around other people's user scripts.  —Ilmari Karonen (talk) 17:42, 26 November 2006 (UTC)
thread_title:  deprecating addLoadEvent 

message: Why is there no floating box for 'Featured content' in the sidebar? --Eleassar my talk 10:31, 28 November 2006 (UTC)
thread_title: Floating boxes

message: I get the error element has no properties when viewing my sandbox, after which the page is blanked. —Ruud 16:25, 28 December 2006 (UTC)
replies: text: I'm not getting an error... I guess we could put an if (!element) { return false } inside the inner function of hasClass() just to be safe. It's weird that you're getting that error and I'm not. Mike Dillon 16:42, 28 December 2006 (UTC)

text: Also, what browser are you testing and where does the page blank? That might give some indication of where the problem is. Mike Dillon 16:44, 28 December 2006 (UTC)
replies: text:  FF 2.0.0.1. I've added a test for a non-existant element, but now NavFrame is broken? (The show/hide button doesn't appear.) —Ruud 17:30, 28 December 2006 (UTC)
replies: text: I assume this is fixed, am I correct? I don't see an additional if statement and all of the collapsible elements seem to be working in your sandbox. ♠ SG →Talk 19:07, 28 December 2006 (UTC)
replies: text:  Yes, it's fix now . —Ruud 20:25, 28 December 2006 (UTC)

text: Not according to the comment in the code just above that line, I'll look into it. —Ruud 13:24, 29 December 2006 (UTC)
thread_title:  hasClass doesn't work with NavFrame 

message: I think it's a bad habit of using innerHTML as it's a rather expensive operation, following code should work as well I belive:
 function mainPageRenameNamespaceTab() {
 	try {
 		document.getElementById( 'ca-nstab-main' ).firstChild.textContent = 'Main Page';
 	} catch(e) {
 		return;
 	}
 }
→AzaToth 13:48, 29 December 2006 (UTC)
replies: text: Fixed. —Ruud 14:45, 29 December 2006 (UTC)
replies: text: Actually, Internet Explorer does NOT support textContent, but rather uses innerText. You need to test for innerText first, and then use textContent if that fails. I suggest setting a global var for this, so you don't have to keep testing every time you want to change the text of something. ♠ SG →Talk 18:28, 29 December 2006 (UTC)
replies: text: Oh, I thought also IE did handle DOM level 3. We dont need to test for it before, we just do it in the catch →AzaToth 18:45, 29 December 2006 (UTC)

text: This needs to use var node, or else it leaks out of the function. Mike Dillon 19:45, 29 December 2006 (UTC)

text: innerHTML works fine, maybe the problem lies in IE's try/catch handling? —Ruud 00:05, 30 December 2006 (UTC)
replies: text: Don't use innerHTML; use innerText. It's much, much faster for modifying the text of a node. ♠ SG →Talk 05:14, 30 December 2006 (UTC)
thread_title:  mainPageRenameNamespaceTab() 

message: Because  is an ugly hack, and messes up screen readers, etc. why not make a JS version?
The benefits would be:
*If something like a screen reader was being used, it would just not execute the js and no harm done
*There are some browsers that have trouble rendering things like this, but would have no problem using js
*..please add more..
Here is a prototype: 
 /** Click on Image ***********************************************************
  *
  *  Description: Make images clickable to a different location
  *               than the one set by MediaWiki
  *  Maintainers: User:GeorgeMoney
  */
  
 addOnloadHook(function() {
 	var usebody = document.getElementById('bodyContent') || document;
 	var divs = usebody.getElementsByTagName('div');
 	for(var i = 0; i < divs.length; i++) {
 		try {
 			if(divs[i].getAttribute('class') != 'click') continue;
 			var titleurl =  divs[i].getAttribute('title').split('URL=');
 			divs[i].getElementsByTagName('a')[0]
 				.setAttribute('title', titleurl[0]);
 			divs[i].setAttribute('title', );
 			if(typeof titleurl[1] == 'undefined') continue;
 			var useurl;
 			if(titleurl[1].substr(0, 2) == '[[' 
 			&& titleurl[1].substr(titleurl[1].length-2) == ']]') {
 				useurl = titleurl[1].substr(0, titleurl[1].length-2).substr(2);
 				useurl = wgServer + wgArticlePath.replace('$1', useurl);
 			} else
 				useurl = titleurl[1];
 			divs[i].getElementsByTagName('a')[0]
 				.setAttribute('href', useurl);
 		} catch(e) { }
 	}
 });
so you would type Image:Myimage
Which would then set the href (url) of the link which contains the image to http://example.com, and link's title to "title to be set after javascript parses".
Using wikilinks on the link works too.
I know this might sound complicated, but it is actually quite simple.
GeorgeMoney  (talk) 04:52, 3 January 2007 (UTC)
replies: text: This doesn't solve the copyright info problem. — Omegatron 15:21, 3 January 2007 (UTC)
replies: text: I guess to solve the copyright problem we could set the title of the link to the old link's href, like "Please see foo for copright info", or maybe even have it append fromimage=true&oldimage=foo which could add in the contentSub "For information on the image that refered you here, see: foo", etc..  GeorgeMoney  (talk) 23:54, 3 January 2007 (UTC)
replies: text: That wouldn't work on the Main Page, where  is used to link a picture of Wiktionary's logo to Wiktionary, etc.. --ais523 15:17, 9 January 2007 (UTC)
thread_title:  Possible solution to {{tl|click}}?