—Ruakh_TALK 13:37, 1 September 2010 (UTC)

Unless I've made a bad click, Wiktionary has switched to beta, like Wikipedia has been for ages. Just a warning, last time I tried WT:ACCEL stopped working. Mglovesfun (talk) 19:00, 1 September 2010 (UTC)

For those of you have been doing so, you'll need to update the code to hide your logo and bring everything wlse upward to

#p-logo{display:none;}#mw-panel{top:0 !important}/*no wikt logo*/

and move your monobook.css/js files to vector.css/js.​—msh210℠ (talk) 19:51, 1 September 2010 (UTC)

Updated WT:PREFS. (FWIW I've haven't seen any ACCEL problems in my Vector usage.) --Bequw → τ 23:12, 1 September 2010 (UTC)

I have been getting warnings about losing my edits if I navigate away from the page, as when using wikilinks from a preview. (Which I do often.) That is new. Moreover, it seems to occur even when I turn off the new features. DCDuring TALK 23:23, 1 September 2010 (UTC)

Special:Preferences -> Editing -> Advanced -> " Warn me when I leave an edit page with unsaved changes ", right at the bottom. Every modern browser will remember what you typed in the box, making the preference somewhat pointless. Conrad.Irwin 23:28, 1 September 2010 (UTC)

Thanks. I hadn't remembered getting those warnings before or checking the box. DCDuring TALK 23:43, 1 September 2010 (UTC)

Yes, it's another new thing. Conrad.Irwin 23:44, 1 September 2010 (UTC)

• One effect of this on my setup is I lose one line or so of content in exchange for some white space at the top of the page. Does it work that way for everyone? I have spent an awful lot of time trying to squeeze content onto the first screen a user sees. DCDuring TALK 00:04, 2 September 2010 (UTC)

  Yes, for everyone. The sacrifices made in the name of aesthetics... Conrad.Irwin 00:07, 2 September 2010 (UTC)

  Do you mean the space below the "Personal tools" (my talk, my prefs, etc.) and above the tabs (Discussion, Edit, ...)? If so, yes. --Bequw → τ 05:52, 2 September 2010 (UTC)

Yes. I don't see the aesthetic benefit for Wiktionary. It seems OK for WP. DCDuring TALK 07:52, 2 September 2010 (UTC)

I'm sure it's possible to change it (at ]), but I've fiddled with it just a little and haven't figured out how.​—msh210℠ (talk) 14:58, 2 September 2010 (UTC)

We could shorten the gap by 1 line (em) in Vector by adding

#left-navigation {top: 1.5em;}
#right-navigation {margin-top: 1.5em;}
/* Could also use #mw-page-base below */
#mw-head-base {height: 4em;}

What do people think? --Bequw → τ 03:38, 3 September 2010 (UTC)

Thank you. Looks good. I've added it to my own stylesheet, but definitely think it should be added to the sitewide Vector.css.​—msh210℠ (talk) 15:04, 3 September 2010 (UTC)

Implemented. --Bequw → τ 16:23, 3 September 2010 (UTC)

If anyone knows why the #p-tb and #p-lang links start farther to the right (have a wider left margin, or padding, or whatever) than the #p-navigation links do, or how to change that, I'd love to know, please.​—msh210℠ (talk) 15:50, 2 September 2010 (UTC)

Ah, it's from http://bits.wikimedia.org/w/extensions/UsabilityInitiative/css/combined.min.css, and I undid it with #mw-panel .portal .body {margin-left:0 !important}.​—msh210℠ (talk) 18:07, 2 September 2010 (UTC)

• Is there a way to restore the ability to do non-headword search from the search box or should I go back to the old skin? DCDuring TALK 23:27, 4 September 2010 (UTC)
• Is the inability to do non-headword search for an exact term a feature recently added? I didn't think search always had used stemming. For a dictionary, especially a multilingual one, this may kill our ability to efficiently help users. It would have to be a very good stemming algorithm indeed to work in all languages. Exact search should always be first. DCDuring TALK 23:36, 4 September 2010 (UTC)

  You access the fulltext search (in monobook, the "search"-button, as opposed to the "go"-button) by clicking the "Containing...\search term" box at the bottom of the drop-down below the header search box when typing there (below the list of possible pages, if any). FYI, fulltext is also what is done on the search page. --Bequw → τ 14:57, 5 September 2010 (UTC)

Thanks. For something that is the immediate product of a funded usability effort, the pull-down presentation/wording is a little disappointing. Of course, the distinction on monobook between "go" and "search" was not obvious and was not documented conveniently. We seem to be adopting the approach of MS and Google in not documenting how features work and relying on learning mostly by experience. Is that now believed to be a more practical approach? I'm not accustomed to the need to experiment so much and fondly recall print documentation, often incomplete and of older versions of the product supposedly documented.

Related to search, do we have any prospect for getting wildcard search, especially for headwords? It would be acceptable for me from the toolserver. Are there search tools there besides CatScan that are usable for Wiktionary? DCDuring TALK 15:27, 5 September 2010 (UTC)

Another new thing on vector (I think) is that ] now shows the tabs (page, talkpage, history...) on top: they used to be hidden, didn't they? It can be done by adding

if ( wgPageName == 'Wiktionary:Main_Page' && wgAction == 'view' ) {
 addCSSRule('#right-navigation,#left-navigation','display: none !important;');
 addCSSRule('#mw-head-base','height:2.5em !important');
};

to ] IINM.​—msh210℠ (talk) 18:51, 7 September 2010 (UTC)

Are you sure they used to be hidden? I don't remember that, and neither http://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Main_Page?useskin=monobook nor http://web.archive.org/web/20091027194615/http://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Main_Page hides them. —Ruakh_TALK 18:57, 7 September 2010 (UTC)

I guess they weren't hidden, then. They were merely so much less obtrusive than the current ones, which are, well, very obtrusive. What do you all think about using that code to hide them, despite their not having been hidden hitherto?​—msh210℠ (talk) 19:03, 7 September 2010 (UTC)

In beta with Firefox, the fonts in <source> tags fonts seem to be about 80% of the size they are in IE/monobook. Why?

Compare this

to this

I corrected it in my vector.css but what about the unregistered users? —Internoob (Disc•Cont) 22:04, 1 September 2010 (UTC)

If others agree with you that it's too small (as I do (Firefox)), we should be able to fix it in ].​—msh210℠ (talk) 15:00, 2 September 2010 (UTC)

I have a hack now that targets every browser except any version of IE (up to and including IE8 for future reference):

pre:not(#ie8-asdfasdfasdf) { font-size: 125%; /*Every browser but IE8 and less*/ }

It should work so long as no one does

<pre class="something" id="ie8-asdfasdfasdf">

=P

Could I have confirmation that users with Opera or Chrome experience this text shrinking? —Internoob (Disc•Cont) 19:33, 2 September 2010 (UTC)

MediaWiki:Vector.css is all well and good, but we should probably file a bug report, no? —Ruakh_TALK 23:08, 2 September 2010 (UTC)

It's already at Bug 20706. —Internoob (Disc•Cont) 16:31, 3 September 2010 (UTC)

FWIW, I see no difference in text size in Safari. --EncycloPetey 01:45, 3 September 2010 (UTC)

In my Safari 5 for Windows I can... —Internoob (Disc•Cont) 16:26, 3 September 2010 (UTC)

Anyone feel like tackling the duplication between the "enhanced editing toolbar" (Special:Preferences→Editing) and MediaWiki:Edittools? There's lots of overlap in symbols included in both. One solution would be to move all the symbol stuff up into the toolbar (which we can add to) for those that have it enable (can check a users wgWikiEditorPreferences variable). Stuff like "Templates" and "Headers" could then stay in the bottom, and are hopefully different enough than the symbols to avoid confusion. --Bequw → τ 23:50, 1 September 2010 (UTC)

The {{was wotd}} template is no longer displaying in the top right corner as it should. It displayed correctly in the Preview window, but not in pages themselves. See roil for an example where the template is displaying below the top line, alongside the TOC for the entry. This is likely a problem created by the new skin. --EncycloPetey 03:42, 2 September 2010 (UTC)

Should be OK now in both monobook & Vector. I've moved the styling to Mediawiki:Common.css and Mediawiki:Vector.css if someone wants to change the pixel offsets a bit. --Bequw → τ 05:04, 2 September 2010 (UTC)

It's still below the line in IE, and is now on the left side of the screen instead of the right. We've had it in the top right corner in the past; it's now on the left, below the headword and above the TOC. --EncycloPetey 18:43, 2 September 2010 (UTC)

As I changed a few files, I saw this exact behavior (in IE 8 & FF 3.6) transitionally until my browser finally got all the new files. This *should* go away once the caches (browser & possibly servers) are refreshed. --Bequw → τ 20:15, 2 September 2010 (UTC)

Should it? It's displaying in the wrong location in Safari now as well. It wasn't in that location before, so the cache has changed, presumably, but is not correct. --EncycloPetey 01:42, 3 September 2010 (UTC)

What skin are you using? Is it there when you're logged out? Do other people see this problem? If so, what's your setup (skin & browser) and do you see it logged-out as well. --Bequw → τ 03:06, 3 September 2010 (UTC)

It's only when I'm logged in, and I'm using Vector. However, the problem appears in more than one browser (IE/PC and Safari/Mac) on more than one machine with different locations/addresses. So, this seems to be unrelated to the template itself now. --EncycloPetey 19:04, 3 September 2010 (UTC)

Does anyone have the skill (and time) to write a bot that would complete (and keep complete) all disambiguation "see also" templates. For example, kare points to several other entries, but käre doesn't. SemperBlotto 11:01, 2 September 2010 (UTC)

We should form a consensus on what characters merit disambiguation first. I've created Wiktionary:Character disambiguation, starting with the data Unicode gives on decomposition. Once everyone is happy with the list a bot can be run. Nadando 19:27, 2 September 2010 (UTC)

I'm not sure its best that necessarily if A links to B then B links to A. The purpose (if I understand it correctly) of {{also}} is to get people to the page they meant rather than the page they types: i.e., for mistypings, whether accidentally or due to a lacking keyboard. But will anyone ever type in cười when he means cuoi? If not, then why link to ] atop ]? (But we do need the link in the other direction.)​—msh210℠ (talk) 17:29, 3 September 2010 (UTC)

I think we should have these generally, going in both directions, and a bot maintaining them is an excellent idea. They take up a small amount of real estate, and can be quite useful, especially for words that have several different variations of capitalization and accenture. Regarding the example above, we should definitely link to cưới on top of cười, and it barely takes more space to have the unaccented form there. As for determining which character variations to include, we can always start with the samll and easily agreed upon set of diacritics os letters in the standard English alphabet, and then later discuss adding other forms. bd2412 T 18:39, 3 September 2010 (UTC)

It gets a bit tricky with terms that have enough variants to warrant a separate appendix page. On the top of those entry-pages we sometimes select a few key variants to show, and then link to the appendix for the rest (eg a). The links (eg in the appendix) could all be common (and therefore botable). The key variants however might not be. I don't think just because foo1 is a key variant on foo2’s page that foo2 should automatically be a key variant of foo1’s page. --Bequw → τ 17:05, 4 September 2010 (UTC)

We have Category:Limit of template reached to tell us when the header is "full" and requires an appendix. I think that generally, if foo1 is a key variant on foo2’s page that foo2 should automatically be a key variant of foo1’s page. There may be exceptions, but we can tell a bot to ignore certain circumstances where those exceptions are like to arise. I note, by the way, that French wiktionary has a way of doing this where all the terms are put in a template, but the template doesn't show the self-link to whichever page it is on. bd2412 T 15:28, 10 September 2010 (UTC)

How do I make it so that links show up better? I just switched to the Modern skin and the links are almost the same color as the rest of the text. — lexicógrafo | háblame — 17:06, 3 September 2010 (UTC)

Edit ], adding stuff like

a{color:#002bb8}
a:visited{color:#5a3696}
a:active{color:#faa700}
a.new,#p-personal a.new{color:#ba0000}
a.new:visited,#p-personal a.new:visited{color:#a55858}
#bodyContent a.extiw,#bodyContent a.extiw:active,#bodyContent a.external{color:#36b}

There, the first line is for links, the second for visited links, the third for links while they're being clicked, the fourth for links to pages that don't yet exist, the fifth for visited links to pages that don't yet exist, and the sixth for links to outside of English Wiktionary. The color is specified as #XXXXXX (or #XXX) for X a hexadecimal digit; fiddle with colors until you find what you like. Google:rgb color can help you decide. (The colors above are from the "monobook" skin.)​—msh210℠ (talk) 17:21, 3 September 2010 (UTC)

thanks — lexicógrafo | háblame — 17:23, 3 September 2010 (UTC)

I think this wiktionary or in general the wikis of the wiki project, would profit from an searchbox, which automatically receives the autofocus, which enables users to quickly and without to switch between mouse and keyboard enter new searches, as imho this is the primary thing one would want to do in an encyclopedia, at least I find myself enter all the time new searches after I have finished reading the current article(s). Obviously if the next article is navigated to by not another unrelated search but a link in the text, it will still be clicked, means theres no difference for the text links, but the activating of the search box when needed would ommitted, which would speed up browsing and imho be a more convinient way for users, who make extensive use of this site.

Cheung TakWah 08:20, 4 September 2010 (UTC)

You just need to paste w:MediaWiki:Gadget-searchFocus.js in your appearance page (probably here). JackPotte 13:49, 4 September 2010 (UTC)

Or Special:Preferences → Gadgets and check "Focus the cursor in the search bar on loading the Main Page". --Bequw → τ 17:07, 4 September 2010 (UTC)

If you hover your mouse over the the search-box the tooltip will tell you the hotkey to jump to that element. For example, in Firefox it's "Alt-Shift-F" (in Chrome it would be "Alt-F", sadly the application steals it). It's usually not good to steal the cursor on every page so the home screen is probably all that's appropriate (even Google doesn't autofocus the search bar on it's subsequent search pages). --Bequw → τ 03:33, 6 September 2010 (UTC)

Thank all of you, for the kind advice, seems like I missed some features. -- Cheung TakWah 07:22, 9 September 2010 (UTC)

We currently have 945 Esperanto adjectives, and since all adjectives are regular, we should have 945 x 3 = 2835 adjective forms. One of our adjectives doesn't end in -a, so that gets us to 2832. owever we currently have 2792 - 40 short. Can anyone find the 40 missing forms in order to create them? Mglovesfun (talk) 10:40, 5 September 2010 (UTC)

Can we do this for the main page? —Internoob (Disc•Cont) 21:55, 5 September 2010 (UTC)

Gosh, two in as many days. Would anyone object to inserting the gadget code into Mediawiki:Common.js so that the search box is auto-focused on the main page? One objection may be that if the page loads slowly, the autofocus might interrupt something the user had begun doing. But the only thing I can envision them doing with the cursor is maybe text-search the front page, which I think is rare. --Bequw → τ 03:39, 6 September 2010 (UTC)

Oops. Sorry for the duplicate. I didn't even realize. —Internoob (Disc•Cont) 16:51, 6 September 2010 (UTC)

I oppose. It disrupts input, especially when you want to directly type something into the address bar. de.wiktionary has it and it's extremely annoying. -- Prince Kassad 18:08, 6 September 2010 (UTC)

Per Prince Kassad. It's especially annoying when using backspace to go back several webpages and then you can't go on because of the autofocus. Longtrend 18:36, 6 September 2010 (UTC)

I've been adding some entries for Proto-Germanic, and I'm now seriously noticing a problem in the existing setup we have for templates. Proto-languages currently lack language templates, which is a major problem in itself, as it renders many templates useless for linking to and between appendix entries. {{l}} and {{term}} in particular are sorely missed and really need to be fixed for things to be workable; boilerplate templates for categories also don't currently work. There are templates prefixed with etyl: (e.g. {{etyl:gem}}) that are perfect this purpose, since they are used for language families which by definition always have a common proto-language. The two templates above can be easily changed to support such templates and automatically prefix Proto- to their output. I've already done this on a test page and it works just fine, but the final edit was reverted for somewhat unclear reasons, so I'm trying to see if anyone has a better idea. (Note: the idea is to make existing templates work with proto-languages. Creating entirely new linking templates would create a huge duplication of code, and that is highly undesirable from a maintenance point of view, so that's not a feasible solution.) —CodeCat 20:13, 6 September 2010 (UTC)

IMO, some duplication of code would be preferable to having {{l}} have an ifexist built into it. --Yair rand (talk) 20:24, 6 September 2010 (UTC)

Hmm, true. But it could be replaced with a template similar to {{Xyzy}} that switches on the language code. What exactly that template should do I don't know, it could be made to do all kinds of things. The simplest I think would be for it to return blank for a regular language code, and etyl for a proto-language. Perhaps it could also be made to return the proper page name prefix (Appendix: Proto-foobar *) for a given language code. Then it might even render {{proto}} obsolete in favour of plain old {{term}} with minimal effort. (But that's just a possibility, not what I'm after) —CodeCat 20:47, 6 September 2010 (UTC)

I had a closer look at the templates and noticed that many templates rely on three possible ways to handle language templates: {{language}} (used by {{l}}), {{langname}} and {{langname/cat}}. The latter contains three ifexists so it's not really suited to a template like {{l}}. However, the problem is that the other two won't recognise non-mainspace language codes, because that's what those ifexists are for. So my suggestion is to change {{langname/cat}} from using ifexists to using a simple switch on the language code. This does have one important requirement: Each language code may have only one language template. So there can be no cases where {{xx}} exists and {{conl:xx}} also exists, or similar for any other prefix that {{langname/cat}} recognises (which would include a prefix for proto-languages, etyl:, proto: or something else). But it does eliminate the ifexists and makes it possible for {{l}} to use something similar {{langname/cat}} (perhaps {{language/cat}}?). Any objections? —CodeCat 09:50, 7 September 2010 (UTC)

Re: "There are templates prefixed with etyl: (e.g. {{etyl:gem}}) that are perfect this purpose, since they are used for language families which by definition always have a common proto-language": That's half-true. We do use the etyl: prefix for language families, but we also use it for other things; the only common factor in all etyl: templates is that {{etyl}} uses them. Your edit, therefore, implied a serious change in the meaning of the etyl: prefix.

Re: "Creating entirely new linking templates would create a huge duplication of code, and that is highly undesirable from a maintenance point of view, so that's not a feasible solution": Not necessarily. There are plenty of ways for two templates to share common code; for example, it can be factored out into a helper template that they both share. In this case, I think the best approach is probably to make {{l}} a bit more flexible, and have {{proto-l}} invoke it with appropriate arguments; but if that turns out to be too ugly, then we can move most of the logic to {{l/meta}}, and leave {{l}} and {{proto-l}} to handle just the part that differs (i.e., the link itself).

—Ruakh_TALK 20:18, 7 September 2010 (UTC)

In that case I propose we introduce a new prefix, proto:, for use for proto-languages. The code following proto: would be an ISO 639 language, as used by etyl:. I'm not sure whether I should just go ahead and create {{proto:gem}} and {{proto:ine}} or whether a vote is in order. Thoughts?

As for the second part, the real problem lies not in {{l}}, but in every other template that uses language codes as well. There are dozens of those, and I don't think duplicating every single one of them is a workable solution, even if most code is shared. A discussion I had with PrinceKassad mentioned simply adding a small {{Xyzy}}-like switch to {{language}} (much like {{langname/cat}} has, but without the ifexist), so that any template would automatically recognise and use non-mainspace templates. However, he did mention that since {{language}} is used so frequently across Wiktionary, even a small increase in code could cause performance problems. I think in this case 'the only way to know is to try', and there is always the undo button if we find that it causes too much overhead. So I think we should at least give it a try and see what effects it has. If it ends up causing everything to seize up, we revert and start thinking of alternatives. —CodeCat 20:37, 7 September 2010 (UTC)

Re: creating {{proto:gem}} etc.: Creating them doesn't require a vote, but you might want to hold off until you have a clearer picture of how exactly they're going to be used.

Re: everything else: Something about this feels really "off" to me. It doesn't make sense to, on the one hand, treat terms in reconstructed proto-languages exactly like attested terms (giving them their own entries, using the same templates and categories and so on, and expecting those templates to automagically distinguish reconstructed proto-languages from attested languages), while on the other hand treating them completely differently (putting their entries into appendices, including the language name in the appendix name, hardcoding an asterisk inside the link, and so on). One Perl philosophy that I've always liked is "different things should look different"; obviously different languages take different attitudes toward this, and Perl itself is famous for doing things automagically (especially via the "do what I mean" principle, which works better than you'd expect), but I've found that it's nearly always the best approach to start with. Only once you understand the problem domain better — which requires experience, not just forethought — can you start to make the software accordingly "smarter".

—Ruakh_TALK 21:51, 7 September 2010 (UTC)

I agree to an extent, but one can still disagree on what is 'different'. A proto-language is like any other language: it has parts of speech, grammar, etymology, descendants, derived and related terms and so on. On Wiktionary, it also has a category of its own and templates to handle language-specific issues. What is different is only where we place the entries, and how we format their names. And that is the only issue that is preventing existing templates from working for them. Templates which, mind you, are needed for all the other things I mentioned that proto-languages share with regular languages. So what we really have is a case where technical limitations are preventing proto-languages being treated the same in those areas where they differ from regular languages, but also in those areas where they are the same. And it's the latter point that I'm trying to solve. —CodeCat 22:02, 7 September 2010 (UTC)

My point is that if we want to treat proto-languages like all other languages in the ways that you describe, then it doesn't make sense to shunt them off into appendices, and if we want to shunt them off into appendices, then it doesn't make sense to treat them like all other languages in the way that you describe. Modifying templates to automagically handle the shunting is really just papering over this discrepancy. —Ruakh_TALK 11:11, 8 September 2010 (UTC)

But I have to restate my point again: while reconstructed languages are different in some respects, they are not different in all respects. We already treat them differently where they are different (putting them in appendixes), why should we artificially create more differences that don't really exist? If you bring up the philosophy of Perl, then you should also be familiar with the object-oriented approach of polymorphism: different things don't have to look different, as long as they appear to work the same on the outside. A link is still a link, even if it links to a different kind of language, so it should appear as a link (i.e. use {{l}}). —CodeCat 14:05, 8 September 2010 (UTC)

I am certainly familiar with polymorphism — I'm a Java programmer by trade — but I don't really see how it relates. In object-oriented terms, {{l}} is a "non-member function" (or, in languages like Java where all functions are methods, I suppose it's a "static method"); you want it to perform an explicit test on the "run-time type" of one of its arguments, and run different code accordingly. That's not polymorphism. Polymorphism would be if {{de}} and {{gem}} etc. actually provided the underlying functionality, and {{l}} etc. simply invoked it without having to know what they're doing under the covers. (Of course, the template language is not object-oriented, which means that if we want object-oriented semantics, we have to tack them on in ugly ways. Personally, I think we're usually better off without tacked-on attempts at object-oriented semantics; the template language actually allows a halfway-decent imitation of functional programming styles, so if we want to do complicated stuff, that's a better way.) —Ruakh_TALK 12:41, 10 September 2010 (UTC)

So what if each template itself contained the necessary info to create a link? I.e., you call the template with some parameter and it returns a prefix to be attached to the name of the article. It would of course mean editing all the language templates (bot?) but it's as polymorphic as it'll get. —CodeCat 15:59, 12 September 2010 (UTC)

Yesterday and today I wanted to hide a vandalised revision where the edit summary contained personal information. However when I click on show/hide revision it just does a 'diff' with no option to either show or hide. Mglovesfun (talk) 11:10, 7 September 2010 (UTC)

Still true? I just tried clicking the "show/hide" link on a diff page (&diff= in the URL), and it worked fine. Where are you clicking "show/hide" from?​—msh210℠ (talk) 19:08, 7 September 2010 (UTC)

The page history. Mglovesfun (talk) 16:12, 8 September 2010 (UTC)

Ah, Compare_link was incompatible with Vector. It's been updated, though, so you need merely replicate this change at ].​—msh210℠ (talk) 20:38, 8 September 2010 (UTC)

My Special:Watchlist has not been working for most of the last few hours. It takes a long time to load, and then I finally get a generic browser error ("Remote server or file not found" in Opera). Is this a known issue at the moment? Equinox ◑ 19:29, 7 September 2010 (UTC)

P.S. If anyone knows about this, please comment on my talk page as well, because for obvious reasons I can't get notifications about changes here. Equinox ◑ 22:02, 7 September 2010 (UTC)

Been working for me in Chrome. --Bequw → τ 02:18, 8 September 2010 (UTC)

For whatever reason, it seems okay again now. Equinox ◑ 10:10, 11 September 2010 (UTC)

Our WT:Per-browser preferences currently has about 70 options, which on my setup takes over 3 screens of vertical space. I, and others, think that this is too big to easily use. I think we should pair down PREFS to a few classes of customization :

1. those important to the non-registered user (eg possible the BC/AD vs BCE/CE pref)
2. those that need to be browser specific (eg the mobile one)
3. those for proposing new changes (eg Yair has several of these)

(We could in theory move some to a /more subpage, but that strikes me as not the most helpful change.) Those preferences commonly desired and of high-quality can be moved to Special:Preferences, which currently only has 14 (a couple have been already). The rest we can document at WT:CUSTOM and have users add the details to their own skin files. I suspect this has already happened for the frequent editors as I imagine they wouldn't want to have to recheck all the options every 30 days. There may be some borderline cases, but in my opinion a bunch of formatting ones can get moved out. If this is the desired course, we could propose specific ones here and then give editors a week or so to edit their own skin files. --Bequw → τ 02:15, 8 September 2010 (UTC)

Categorizing and ordering the items seems like a very good idea for all users. Paring down the list seems essential for unregistered users. Should experimental changes really be per-browser rather than offered only to registered users? Shouldn't per-browser preferences not important for anons be concealed from and/or unavailable to them?

I would think that it would be good for us to use the prospect of durable customization to encourage more users to register. The per-browser preferences page text seems like a good place for such a sales pitch. It seems to me that the difference between per-browser and registered-user customization should be explained on the text of both pages, too. DCDuring TALK 11:58, 8 September 2010 (UTC)

I agree with DCDuring. Do we have a specific proposal for the Beer parlour? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 10:56, 9 September 2010 (UTC)

Experimental customizations could be gadgets. The only reason I said they should be cookie-based is that one day, WT:PREFS may get fewer eyeballs than Special:Preferences so maybe hiding the experimental ones a bit is good. Not sure, though. I've added a bit of text about cookie-prefs needing refreshing. Expand if desired. As for proposals, I'd like to remove the following from WT:PREFS (most now at WT:CUSTOM):

• Hide the special character input beneath the edit field.
• Hide the display of site-wide notices at the top of the screen.
• Show a link to a web-based IRC client in the top right-hand corner.
• Make the second half of the heading of Special:RecentChanges smaller
• Put the checkbox onto the left of the translation bars.
• Hide the copyright warning in the edit window.
• Hide the horizontal separator between each language section.
• Hide the parentheses around list item qualifiers.
• Italicize the punctuation (parentheses and colon) around italic text.
• Hide the maximal amount of parentheses.
• Hide the boxes that link to Wikipedia.
• Hide the boxes containing word frequency rankings.
• Show the translation sections expanded, instead of having them collapsed.
• Hide the translation sections entirely.
• Highlight the inflection line of some entries
• Indent the “See also” lines more than usual.
• Show “form of” definitions with a plain (only wikilinked) lemma. (Default is with a bold lemma.)
• Show “form of” definitions with an italic definition (“qualifier”) and plain (only wikilinked) lemma. (Default is with a bold lemma.)
• Show “form of” definitions with an italic lemma. (Default is with a bold lemma.)
• Show “form of” definitions with an italic definition (“qualifier”) and bold lemma. (Default is with a bold lemma.)
• Show other Latin (Roman) script mentions in bold. (Default is in italics.)
• Show English glosses for mentioned terms in single quotes. (Default is in double quotes.)
• Hide parentheses around transliterations and glosses.
• Hide parentheses around glosses.
• Show parenthesized plain (non-italic) transliterations.
• Display words in quotations that have been emboldened with {{q}} with a square box instead
• Change the bullets in unordered lists to be round.
• Use User:Connel_MacKenzie/reformat.js to reformat pages semi-automatically.

More, less? --Bequw → τ 02:33, 10 September 2010 (UTC)

Why are all these going to WT:CUSTOM rather than Special:Preferences? — This unsigned comment was added by DCDuring (talk • contribs).

I tried to pick the most minor ones plus the ones we probably wouldn't want to advertise (such as the one that make our pages "ungrammatical"). The possible customizations of this magnitude are endless, so better to treat them in the howto-style of CUSTOM so people make their own type of changes. Adding these 28 to Special:Preferences would just shift the problem, and I think make that page unmanageable. Would you like to make a few of these gadgets, or perhaps some of the ones that I didn't mention (there's still about 40 at PREFS that I have not proposed)? --Bequw → τ 13:55, 10 September 2010 (UTC)

I personally have enjoyed the convenience of checkbox customization and prefer it to continue (at least for all the features that I use now or might want in the future.). I regretfully concede that my desires are not determinative. Do we know how many folks use the various bits of customization?

Shifting the problem to a place where it was only available to registered users seems like an adequate solution to me. Grouping related items a bit better might go a long way toward making such a page less daunting. And the wording could be improved. (I still don't understand what "Show parenthesized plain (non-italic) transliteration." might refer to or mean.) But even a badly organized page with badly worded text is less daunting for many than CSS and JS customization. WT:CUSTOM might benefit from similar attention to grouping and wording.

Is it your intent to deprecate such customization by putting it in the class of use-at-your-own-risk? Does it become too hard to maintain all these things as Mediawiki and other software changes? DCDuring TALK 14:29, 10 September 2010 (UTC)

FWIW, I think we should keep "Display words in quotations that have been emboldened with {{q}} with a square box instead" in the main list, as I imagine that it's something that might have some appeal for the general user. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 15:23, 12 September 2010 (UTC)

My fevered imagination has all the features I have ever used or been involved with advocating as absolutely indispensable for the silent majority of unregistered users. DCDuring TALK 16:35, 12 September 2010 (UTC)

Yeah, it think it's hard to let go of customizations that one was involved in. Probably the only good way to do it would be collect some objective usage data. Ergo User talk:Conrad.Irwin#PREFS usage statistics --Bequw → τ 03:24, 13 September 2010 (UTC)

• Hadn't we some kind of consensus on limited visibility by default of quotations and all but the first usage example? I don't see that now. Some of the configuration of usage examples depends on that.
• I also note much white space between sections of the frame on the left. Why does "Scripts" appear with even more space before, large and bold? DCDuring TALK 16:35, 12 September 2010 (UTC)

• Re: limited visibility of quotations: Yes, but that's handled through a separate interface. To wit, when you visit an entry with hidden quotations, one of the sections of the sidebar at left will be titled "Visibility", with a pseudo-link to disable quotation-hiding. (That mechanism is relatively generic; the same thing is used for hidden translations and derived terms and possibly other things; see ] for example.) —Ruakh_TALK 03:59, 13 September 2010 (UTC)

It would make sense to show common classes of visibility on the prefs page. I've implemented a really basic collection of data (whenever someone sets their prefs cookie, it will get copied to http://toolserver.org/~enwikt/prefs_stats. There are privacy implications, but note that no-one can see timestamps, ip addresses or usernames, so it shouldn't leak too much — please disable it if you think it's too bad. I'm not sure how much time I'll have to work on this at the moment, but converting the raw data into useful output shouldn't be too hard. I also considered adding a date column — would that be useful? I'd encourage anyone who wants to fix the code to do so and email me a new version — or sign up for a toolserver account yourselves :). Conrad.Irwin 23:11, 23 September 2010 (UTC)

I've taken a look at a little more than a month's worth of data and ordered it below. It includes 725 uses of WT:PREFS. This should be a representative sample of users of that page and include all such regular contributors. We should consider removing from WT:PREFS those items that aren't used often and don't need to be set via cookies. As a point of reference, Yair's experimental rhymes editor was only added half way through the logging period (rank 54) and there are eight preferences less commonly used. I think these should be removed. Others from the low end of the ranking could be removed as well if a more nuanced consensus can be reached. What do others think? --Bequw → τ 02:03, 28 October 2010 (UTC)

I believe {{langname}} was originally meant as a stopgap measure to help transit from language names to language codes. I believe at this point it's all but obsolete in favour of the simpler {{language}}; I don't see a pressing reason to keep using it anyway. So I am trying to find out which pages still call it with a language name instead of an ISO 639 code, and fix those names, so that we can then try redirecting {{langname}} to {{language}}. But I don't know how I would do that, so can anyone help? —CodeCat 15:47, 8 September 2010 (UTC)

See Special:Contributions/Keenebot2 for a good chunk of the langname-based entries. --Yair rand (talk) 15:59, 8 September 2010 (UTC)

Oooh boy. Please tell me that bot got fixed since then! In any case, I'm sure those are not the only occurrences, so is there a sure-fire way to get all instances? —CodeCat 16:08, 8 September 2010 (UTC)

Probably not. The simplest way to clear it out would probably be to first take care of all the large available groups of problems (such as the Keenebot2 contribs), then fix templates that have things like {{langname|{{{lang|English}}}}} (there are a lot), then redirect/orphan the template and clear out Special:Whatlinkshere/Template:French and such. Even then, there would likely be a few entries missed, but those will be fixed eventually. --Yair rand (talk) 16:28, 8 September 2010 (UTC)

One thing we can do, if people agree that we want to, is edit {{langname}} from this:

{{{{#ifeq:{{{1}}}|{{lc:{{{1}}}}}|language|#if:1}}|{{{1}}}}}<noinclude>{{documentation}}</noinclude>

to this:

{{{{#ifeq:{{{1}}}|{{lc:{{{1}}}}}|language|langname/name}}|{{{1}}}}}<noinclude>{{documentation}}</noinclude>

Then, once the job queue has cleared, Special:WhatLinksHere/Template:langname/name will be the list you want. (I've created {{langname/name}}, consisting of simply {{{1}}}, so this change will not have any visible effect aside from populating Special:WhatLinksHere/Template:langname/name.)

Personally, I'm on board with such a change, but given that {{langname}} is one of our most widely transcluded templates, you should wait a day or two first to make sure no one objects!

(Technical note: the reason the above works is a bit subtle — #ifeq: and other conditional-like parser-functions don't work the way you'd naively expect — if anyone wants me to explain, please ask.)

—Ruakh_TALK 18:25, 8 September 2010 (UTC)

That looks like a good solution to me. Anyone object? —CodeCat 19:58, 8 September 2010 (UTC)

I'm not against this, but what are the advantages of converting (for example) Italian to it. It seems like a lot of effort, hundreds of thousands of pages, to fix something that actually already works ok. Mglovesfun (talk) 12:16, 9 September 2010 (UTC)

It works ok in the short term, but it's really just a relic of the past that we're trying to get rid of. {{langname}} was a temporary measure, and its talk page attests to that. There just never has been a focused effort to fix the last few stragglers. And it also brings up things like which one people should use, {{language}} or {{langname}}? Removing the latter will remove some ambiguity and will also help consistency, because as long as people can still use language names, they will. —CodeCat 13:35, 9 September 2010 (UTC)

Consistency is nice, but doesn't this push us even farther away from allowing ordinary users to contribute? This kind of thing needs to accompanied by more effort to remove format and template technicalities as a barrier to contribution. DCDuring TALK 14:33, 9 September 2010 (UTC)

That's essentially what I mean - that, and the enormity of the task. Mglovesfun (talk) 14:41, 9 September 2010 (UTC)

There are always going to be some templates that don't accept names, but only codes. {{Xyzy}} and anything that uses it, for example. So rather than having to learn which templates accept which kind of argument, I think it's easier to just use only language codes for everything. It's not really that big a deal for new users, since we expect them to look at existing articles for examples. And if they get it wrong, we could get a bot to fix it? —CodeCat 15:51, 9 September 2010 (UTC)

I think there are two separate questions here: (1) Are language codes preferable in all cases? (2) Do we want to force all editors to use language codes in all cases? I think the answer to #1 is "yes"; but I think the answer to #2 is probably "no". (Sometimes there's basically no choice — we've made language codes an integral part of our structure — but sometimes there is a choice.) So, I support modifying {{langname}} to make these cases trackdownable and fixable, but I don't think I support eliminating {{langname}} or modifying it to not support these cases. —Ruakh_TALK 19:19, 9 September 2010 (UTC)

I've downloaded the latest XML dump and did a search for all occurrences of |English}}}, then replaced English with en in those templates, and also added a call to {{langname}} where needed. So I think that takes care of those cases. —CodeCat 15:55, 9 September 2010 (UTC)

I second what Ruakh just said. Mglovesfun (talk) 19:25, 9 September 2010 (UTC)

...{{ttbc}} uses {{langname}}. Is this template normally supposed to use language names or codes? --Yair rand (talk) 17:57, 14 September 2010 (UTC)

I would support forcing all editors to use language codes by disabling language names in templates. Back then when I started in Wiktionary, I sometimes did not know whether to use a language code or a language name. If the template had turned red on language name or something, that would have helped me. A new editor can use existing entries as a model, without the need to look into guidelines or anything. If the existing entries are all consistent, picking them as a model is easy. Language codes are now a prevalent practice easy to pick up IMHO. There are much higher barriers to entering content into Wiktionary than language codes, such as the mandatory use of {{etyl}} and {{term}} in the formatting of etymologies. --Dan Polansky 18:22, 14 September 2010 (UTC)

I agree completely, you just worded it better than I could. I am 100% in favour of obsoleting and removing any remaining uses of language names. However, since it seems to be a somewhat contentious issue, I think we might need to have a vote on it. —CodeCat 20:49, 14 September 2010 (UTC)

Oh yes, ttbc should definitely use codes (as should trreq). The entire ttbc/trreq category system is currently a mess because of the millions of language names in use. -- Prince Kassad 20:57, 14 September 2010 (UTC)

I've made the change. So far I've found a few interesting things:

• {{ttbc}} uses {{langname}}. Honestly, I didn't realize that it supported language codes!

  I don't see much benefit to {{ttbc|fo}} over {{ttbc|Foobar}}, and I don't think I'd support a bot to convert the latter to the former; but so many pages use {{ttbc|Foobar}} that it makes Special:WhatLinksHere/Template:langname/name useless at the moment. I'm not sure how we want to address this.

• {{en-verb}} uses {{categorize|English|verbs}} to categorize its entries. Other templates might do similarly.

  {{categorize}}, like most of Daniel. (talk • contribs)'s templates, is undocumented, but inspecting its code reveals that it does the following:

  • If used in an entry, it adds the entry to Category:English verbs (or whatnot).
  • If used in an appendix, it assumes the appendix is a sub-page of Appendix:Group (or whatnot), and adds the appendix to Category:Group and Category:English appendix-only verbs.
  • If used in any other page, it does nothing.

  So I assume it's only intended to be called via inflection templates. Therefore, assuming we want this template at all — which is already a significant assumption (past discussions suggest that many editors dislike many of Daniel.'s templates) — I think it's reasonable to require that such templates either always use the language-name, or always use the language-code. (In the latter case, though, we'd still probably want {{categorize}} to support language-names in case it's called from {{infl}}-like templates that get their language-codes directly from entries.)

—Ruakh_TALK 18:27, 14 September 2010 (UTC)

I don't really see much use for {{categorize}} right now, especially if it's not used much to begin with. I'm not at all surprised to see {{ttbc}} use {{langname}} though; it's the principle of least surprise. People (myself at least) expect everything to use language codes, so that's what they'll probably try first given the fact that almost everything else uses it. Also see Dan's post above. —CodeCat 20:46, 14 September 2010 (UTC)

Re: {{categorize}}: I agree. (I'm not surprised you feel that way, given that you recently wanted to edit {{infl}} to categorize appendices in a completely different way!)

Re: people trying {{ttbc}} with language-code first: Not at all. You're thinking like a programmer who's aware of a function and needs to call it; but here, the way people learn of {{ttbc}} is by coming across it in the wikitext of entries that use it. Except in rare cases, no one ever finds out "there is a template called 'ttbc'" without simultaneously finding out "its argument is the name of the target language".

—Ruakh_TALK 21:34, 14 September 2010 (UTC)

But there are two kinds of editors here, more or less: Those that don't know how Wiktionary works and those that do. The former category won't care either way how a template works; everything is new to them, so they will follow documentation and examples. The latter category, however, will expect a template that needs a language to take a language code, because almost all templates take language codes. That's what I mean by principle of least surprise. —CodeCat 22:08, 14 September 2010 (UTC)

I know exactly what you mean, and I said why I think you're mistaken. I think consistency is good, and that's definitely related to the principle of least surprise, but I simply will not believe that any editor will learn about {{ttbc|French}} and go, "oh! cool! So, if I want to request that a French translation be checked, I should use {{ttbc|fr}}!" —Ruakh_TALK 23:29, 14 September 2010 (UTC)

Which is why we should eliminate {{ttbc|French}} altogether, so they won't even be able to follow that example. They would only see {{ttbc|fr}} everywhere they go. —CodeCat 17:53, 16 September 2010 (UTC)

I looked across all templates for the parameter lang= and found the following values with capitalized initial. --LA2 22:46, 14 September 2010 (UTC)

358124 Italian
 72215 French
 11761 Danish
  7738 Finnish
  2090 German
  1334 Spanish
   630 Dutch
   628 Hungarian
   544 English
   456 Romanian

   332 Scots
   295 Irish
   241 Classical Nahuatl
   221 Old English
   196 Norwegian
   186 Czech
   144 Manx
   133 Icelandic
   104 Portuguese
    93 Swedish

    93 Sicilian
    90 Latin
    82 Breton
    80 Galician
    68 Hebrew
    66 Welsh
    65 Macedonian
    58 Nahuatl
    52 Ewe
    51 Serbian

    47 Japanese
    43 Cornish
    43 Arabic
    40 Russian
    32 Old French
    31 Anglo-Norman
    30 Croatian
    29 Catalan
    28 Greek
    27 Polish

    26 Bosnian
    25 Indo-European
    24 Slavic
    24 Germanic
    24 Faroese
    22 Middle English
    22 Interlingua
    22 Celtic
    22 Ancient Greek
    21 Old Irish

    20 Pulaar
    18 Scottish Gaelic
    18 Asturian
    16 West Frisian
    16 Norwegian Nynorsk
    16 Ido
    15 Persian
    15 Bulgarian
    14 Korean
    14 Esperanto

Looks like Semper has been doing it all the time. You might want to nudge him. -- Prince Kassad 18:10, 16 September 2010 (UTC)

I just have, if anyone wants to re-nudge him, feel free. BTW I'd prefer language names to still work, but if Im in the minority, so be it. Mglovesfun (talk) 18:31, 16 September 2010 (UTC)

There are places where language names should be allowed to work in the interests of easing participation by newer users and simply appearing less forbidding. This is not a matter of our preferences or programmer convenience, it is a matter continuing to get some fresh contributors to work on our vast definition quality problem, our consistency problems, our lack of coverage of actual words, etc. DCDuring TALK 18:40, 16 September 2010 (UTC)

• If we had a bot insert a comment in every language section saying something like 'Please insert "lang=XXX" in any Category:Common Templates you use in this section.' we could be more sanguine about contributors' mistakes. We would also be reminding them of the existence of useful templates. DCDuring TALK 22:14, 16 September 2010 (UTC)

Of course the Category link doesn't work inside a comment. Perhaps a link to such a category could appear in the left frame for entries with language sections that have no lang= parameter anywhere in their templates. Or the edittools could be revised to include more now-common templates like {{context}} and {{term}} and {{etyl}} or even language-specific declension and conjugation templates. DCDuring TALK 22:22, 16 September 2010 (UTC)

I agree, lang=English should ideally still work, but perhaps trigger {{rfc-auto}} or something of that nature. Mglovesfun (talk) 23:03, 16 September 2010 (UTC)

I think a vote is way premature. There are lots of ways to use our supposed technical capabilities to make newcomer editing less error prone. less daunting, and thereby a better way of gaining long-term recruits and greater variety of input. The technical issues about langname vs langcode are easily solved, but the very easiest solutions continue to make life harder for would-be contributors. If we really have technical capability it should be used for all of our goals. Making contributing easier for us is certainly good, but getting recruits to replace those who go on to other things is important. We need folks to word on English definitions so that folks with less than en-5 can rely on our definitions to do translations and so that our English stuff is not so full of laughable definitions for all users. DCDuring TALK 23:44, 16 September 2010 (UTC)

Making everything code-based is good in the long term — it makes it easier to build tools like WT:EDIT, improves consistency, and hopefully increases the chance that someone can learn the language code immediately (as described above, the first time you make a template call, you copy the parameters from elsewhere). Removing the language names by bot seems sensible, but removing support from the templates is very premature — once they've all been removed by bots, it should be left for a few months before turning off the templates. Conrad.Irwin 23:14, 23 September 2010 (UTC)

For some reason this has a cat parameter allowing the user to place the entry in a category other than Esperanto nouns. Is this actually used in any entries? The example in the documentation is to add Category:Esperanto animals, which isn't even valid. If it is used, hopefully it can be removed and we can go back to categorizing Esperanto nouns as erm, Esperanto nouns. Mglovesfun (talk) 09:20, 13 September 2010 (UTC)

Done. Mglovesfun (talk) 18:11, 16 September 2010 (UTC)

For a language (like Swedish) with many forms to each word, is there any tool to make sure that all forms have the proper form entries? Starting from the verb hålla (“to hold”) or from the noun håll (“a hold”), the form hålls appears three times and all three forms are now covered by that form entry. If no form entry existed, this would be a red link. But if only one or two of the forms were covered in the form entry, how could this be detected? --LA2 13:07, 14 September 2010 (UTC)

There is no reliable way to detect it, other than actually going to the entry and checking whether the information that should be there is actually there or not. It would be a good task for a bot (MewBot does this, for example). —CodeCat 14:22, 14 September 2010 (UTC)

At the Dutch wiktionary, we successfully installed the interwiki translation extension, which is named here "Translate sidebar interwiki links to English" in Special:Preferences. We are very happy with it. Yesterday, I extended the original script so that it now sorts the interwikilinks (technically spoken it overwrites all links with a sorted copy). I just wanted to mention it, as it might also be of interest for en.wikt. You can find my modifications here. Basically if you're interested, you could duplicate the code from this page (nl:User:Bequw/sidebartranslate.js), and change "ongedefinieerd" again in "undefined". Annabel 18:46, 14 September 2010 (UTC)

I've merged your update into ours. Thanks. --Bequw → τ 00:06, 16 September 2010 (UTC)

What's the benefit of using {{ {{{sc|Xyzy}}}|...}} (in various templates, like {{infl}})), which allows for only certain languages to have their scripts specified, rather than {{ {{{sc|{{langscript|{{{lang|}}}}}}}}|...}}, which allows any language? AFAICT each uses one #switch and one template call (the latter being to Xyzy or langscript).​—msh210℠ (talk) 20:12, 14 September 2010 (UTC)

So you're saying that Xyzy is redundant to langscript? I think langscript is a bit more of a performance hog. -- Prince Kassad 20:19, 14 September 2010 (UTC)

For each case in a switch above the one that is taken, there is one string comparison between the switch parameter and the case string. That means that on average, a switch will take in the order of the amount of cases to complete. So switches with fewer cases are faster. —CodeCat 20:37, 14 September 2010 (UTC)

I think this was the argument put forward for having a bot add sc= to relevant templates, rather than using either of these. Mglovesfun (talk) 11:09, 15 September 2010 (UTC)

I believe it would be a good idea to forego templates like {{Xyzy}} and bring up a different system. Instead of having one template that is huge and handles all languages, why not simply 'ask' the language template in question which script it uses? The same principle can be extended in other ways too, i.e. to return the language family rather than using {{langfamily}}. Granted, it would mean editing every language template each time we add a new parameter, but that could be done easily by a bot (provided the templates are formatted nicely) and it's faster in use and easier to maintain than the current mess. —CodeCat 14:54, 15 September 2010 (UTC)

I think I agree. I recently raised the same possibility at ]. —Ruakh_TALK 15:34, 15 September 2010 (UTC)

Hmm, I think I like that prefix idea even more. How is this: {{xx}} returns the language for code xx, {{xx/script}} returns the script for code xx, {{xx/family}} returns the family, and so on. It would be even faster load-wise than my previous idea (which was to have a switch in each lang template) and having separate subpages makes bot-based maintenance and adding new 'parameters' a piece of cake. —CodeCat 15:47, 15 September 2010 (UTC)

I agree with the basic idea of using {{xx/script}} and {{xx/family}}. More specifically, I believe xx/script should contain a script code (as opposed to containing a script name), to call script templates; and, for languages with more than one script, like Latin and Cyrillic for Russian, perhaps we should use various separate templates, like {{ru/script}} and {{ru/script2}}. --Daniel. 15:55, 15 September 2010 (UTC)

Or, perhaps, have {{xx}} return the script if the first unnumbered parameter is set to 'sc' (or something), à la the etyl: templates. This way, if a template needs to call xx for both the language name ans the script, then it is calling the same template twice rather than two templates. (I assume that that means it will actually only retrieve it once, cutting down on expense. Can anyone confirm?)​—msh210℠ (talk) 16:14, 15 September 2010 (UTC)

That was my first idea, but it means that all language templates need to have a switch in them. Having several distinct templates should, in theory, be faster, because it optimises the most common case: retrieving the language's name. Page retrieval is the most common operation in the whole wiki software, so you can bet on it being optimised to death. I don't think that's a significant performance bottleneck.

And as for Daniel's suggestion, the problem with having an extra subpage like /script2 is that it has to exist for all language codes, not just some. If it only exists for some languages, then we'll be forced to use #ifexist to detect which languages have one, and that defeats a lot of the speed bonus we're attempting to get with this. —CodeCat 16:18, 15 September 2010 (UTC)

Re: "Page retrieval is the most common operation in the whole wiki software, so you can bet on it being optimised to death. I don't think that's a significant performance bottleneck": Er, um, well … it's about as cheap as it can possibly be, but on average, it's still way, way more expensive than (say) a #switch: in an already-loaded page. —Ruakh_TALK 17:01, 15 September 2010 (UTC)

Allright. Then I think the best way to go about it is this. The first template parameter specifies the type of info you want in the form of a short string (the shorter the better). Leaving it empty will return the language name, as it always did. The template itself then does this: {{#switch:{{{1|}}}|=(language name)|sc=(script code)|fam=(family)}} and so on. The most common cases go at the top to improve speed. —CodeCat 17:37, 15 September 2010 (UTC)

(Re CodeCat's comment of 20:37, 14 September, UTC:) So shouldn't langscript and similar templates list the most common languages first, at least the extent easily done? (Viz, maybe don't go crazy analyzing which is most common, but at least put en before aak and yue before saw.) I know alphabetical order is easier for human editors, but browsers have the ability to search a page, so I don't think it's a big deal. The display can warn people of the 'misordering'.​—msh210℠ (talk) 16:40, 15 September 2010 (UTC)

It still has to load the entire template each time it's called, so this won't really change a lot, if anything. -- Prince Kassad 20:16, 15 September 2010 (UTC)

What does everyone think of my proposal above? Specifically: Adding all language-specific information currently found in templates (such as {{Xyzy}} and {{langfamily}}) directly into language templates, so that each language template may be queried about various kinds of information about that specific language. —CodeCat 10:58, 18 September 2010 (UTC)

Support for scripts. However I'm not too sure about families, especially as families are not queried very frequently. -- Prince Kassad 11:09, 18 September 2010 (UTC)

It doesn't have to be queried frequently. The purpose of this change is to eliminate any templates that switch on the language code, as they are very performance-heavy and hard to maintain. It would also allow new language-specific information to be handled in the same way, perhaps information we don't currently provide or use yet. So it is also easy to extend, unlike the current practice (which entails creates a huge switch-template for each piece of information we think about). —CodeCat 11:20, 18 September 2010 (UTC)

The problem is that the language family categorization is not yet finalized, and likely to change as we include more languages. This would require frequent bot use if we were to accept your suggestion. I think it's better to keep {{langfamily}} for now. -- Prince Kassad 18:38, 19 September 2010 (UTC)

In addition to what Kassad said above, if someone wants to run a bot to distribute parameters like "sc=Latn" or "sc=Kore" among entries, that bot can use {{langscript}} as a resource. --Daniel. 01:05, 20 September 2010 (UTC)

I would like to see a page for the Dinka Language, and also a Dinka/English translator. Dinka is the name of the language and also the largest tribe in Sudan. Also... does Wikipedia contract "specialists" for pay for a job like this? Thanks — This unsigned comment was added by 67.235.160.94 (talk).

We currently have no entries in the Dinka language, save for a single translation of water in this language. Note that this wiki is maintained and expanded entirely by volunteers, so it really depends on whether you find a person willing to contribute (there is some material available, but most people here are busy with other projects at the moment) -- Prince Kassad 07:01, 15 September 2010 (UTC)

The seems to be a problem with ths template (viz. July)
o/p = July (plural Julys)] —Saltmarsh^{απάντηση} 05:32, 16 September 2010 (UTC)

Fixed. --Yair rand (talk) 05:41, 16 September 2010 (UTC)

I noticed that the templates used for Catalan and Spanish are almost carbon copies of each other. Yet while Spanish has most form-of entries done, Catalan doesn't. Is there anyone who has a Catalan formbot that is currently taking requests? And if not, maybe the Spanish one (I think there is one) can be adapted to Catalan? —CodeCat 08:55, 16 September 2010 (UTC)

Specifically this version of it. I'm trying to find out which template is causing it. I think it's {{catlangname}}. Anyone who could fix it could fix hundreds or even thousands of entries. Mglovesfun (talk) 11:29, 16 September 2010 (UTC)

Special:UncategorizedPages is way over 5000 entries. Mglovesfun (talk) 16:27, 16 September 2010 (UTC)

Fixed. I would support blocking Daniel. (talk • contribs), by the way. —Ruakh_TALK 16:38, 16 September 2010 (UTC)

Yes, see my comments on his talk page (over a long period). Mglovesfun (talk) 16:39, 16 September 2010 (UTC)

And see Wiktionary:Votes/sy-2010-09/User:Daniel. for desysopping. Mglovesfun (talk) 16:54, 16 September 2010 (UTC)

Ruakh, I don't see how you changing a reference from languagex to langname is related to the suggestion of blocking me; notably, I made sure that languagex had all the functionalities of langname last time I edited it. Since someone else edited it since then, perhaps these functionalities of languagex should simply be restored, to allow people use names of language names (rather than codes) in a few dozens of other related templates. --Daniel. 17:02, 16 September 2010 (UTC)

{{language}} and {{languagex}} don't handle language names, only codes. {{langname}} handles names as well. Maybe you could create {{langnamex}} if needed. But to be honest I don't think that's a good idea, because I'm in favour of phasing out language names entirely (see the above discussion). So the less templates that remain to support language names the better, IMO. —CodeCat 17:31, 16 September 2010 (UTC)

I'm currently orphanining a load of full language name but until we do orphan them, that leaves thousands on uncategorized pages. And even more that are lacking some sort of category that they had before. Mglovesfun (talk) 17:48, 16 September 2010 (UTC)

The frame on the left hand side of the page has a few rough edges:

1. There is a full space between each of the groups of links: a half-space would be better.
2. On my edit pages the link group header "Scripts" appears large, bold and unpadded. "Custom regex", the sole item beneath it, appears with an asterisk and large.
3. Links to Wikipedias are not differentiated by language.

--DCDuring TALK 18:28, 16 September 2010 (UTC)

1. Try this CSS

   .portal {margin-bottom:8px !important;}
   

   .portal h5 {padding-top: 0px !important;}
   

2. That gadget gets its code from m:User:Pathoschild/Scripts/Regex menu framework.js. We could make a local copy and customize it, but it would be good if someone watched the original for bug fixes.
3. I see the LHS wikipedia links with the language code superscripted (cf A). Do you not see that? Sometimes there will be multiple wiki links for the same language (cf port) and then those LHS links are undifferentiated, but I'm not sure what we can do about that.

--Bequw → τ 01:57, 27 September 2010 (UTC)

1. Thanks. I will try it.

   (It seemed to add more space, even when I set px=0. Can it be a negative #? DCDuring TALK 03:21, 27 September 2010 (UTC))

2. Does anyone actually use it here?
3. I see the superscripted language code. What I thought I saw was a hoverlink to a different language pedia. But my eyesight may have failed me then or my memory may be failing me now. If I catch it again, I will try to be more observant.

Thanks for getting to all those. DCDuring TALK 03:09, 27 September 2010 (UTC)

Maybe that's because I pasted the CSS wrong. Try it now. And yes CSS #s can be negative. As for the regexp, I turn it on every once in a while. --Bequw → τ 03:30, 27 September 2010 (UTC)

What suited me was:

.portal {margin-bottom:-16px !important;}

.portal h5 {padding-top: 0px !important;}

Thanks. DCDuring TALK 04:51, 27 September 2010 (UTC)

The arguments on how to recognize individual languages in most (or all) templates, by their codes or names, are being scattered over various discussions, to the point that they are becoming a little repetitive.

So, I think it's better to create a vote on this issue, where people can focus their arguments before it starts, then hopefully reach a conclusion soon. --Daniel. 18:58, 16 September 2010 (UTC)

Agreed. This is getting a bit messy now, so I'm all for it. Never created a vote though... —CodeCat 19:27, 16 September 2010 (UTC)

Are we going to have the option for no-code => English? DCDuring TALK 19:29, 16 September 2010 (UTC)

Almost all templates already work like that, so I don't think it's a big issue. The best we can do in that respect is build the behaviour straight into {{language}}, so that all templates support it by default. —CodeCat 19:35, 16 September 2010 (UTC)

Wiktionary:Votes/2010-09/Language codes in templates. --Daniel. 20:41, 16 September 2010 (UTC)

Looks ok. I think it would be useful to mention that while many templates can support both code and name, some templates must have a code and can never have a name, because they depend on the code for the XML lang= parameter and script code lookups. This affects most notably {{infl}} and {{term}}, and I believe anything else that uses {{Xyzy}}. So this implies that we can never reach a situation where we support names on all templates. —CodeCat 21:00, 16 September 2010 (UTC)

All templates that have a lang= parameter, and return text from that language, use scripts for formatting purposes, or they should, given that the text should be formatted in the first place.

So, a way to format text from language names should be developed, or they simply should always use language codes. --Daniel. 03:44, 17 September 2010 (UTC)

I don't think that's the case CodeCat. If we so decided we could bot-create/maintain templates such as {{lnames2codes:Spanish}} that outputted "es". We've built up templates for one side of the code<->name mapping, why not for the other? This would allow people to use non-colliding alternative names (which are already stored like {{ab/names}}). The hate that my head is full of ISO 639 arcana. If I thought normal users found categories useful, I'd push for their titles to have no traces of language codes also. --Bequw → τ 04:02, 17 September 2010 (UTC)

I have created another maintenance box: {{stub}}.

I intend to use it regularly in templates before their formal introductions. However, of course, if someone is willing to extend the concept of "stub" to entries, appendices, rhyme pages and others, the {{stub}} may be expanded accordingly.

Please note that it is substantially different from {{attention}}, {{rfexp}}, {{rfc}}, {{rfd}} and {{delete}} due to their visibility, proposals and messages. --Daniel. 06:40, 17 September 2010 (UTC)

The following group of templates is now complete, by the recent addition of "family":

• {{langscript}}
• {{langfamily}}
• {{script}}
• {{family}}

They can handle all or most automatic relations between languages, families and scripts that I can think of. If I forgot something, please let me know. --Daniel. 18:29, 17 September 2010 (UTC)

By adding {{catlangname}} to {{en-verb}}, in addition to its main function of categorizing into "Category:English verbs" or "Category:English appendix-only verbs", I have made the resulting links (e.g., "evolved", "evolving" and "evolves" in evolve) point to the English sections of each word.

Before this edit, the links simply pointed to the respective entries, without specifying sections. --Daniel. 07:08, 19 September 2010 (UTC)

What? {{catlangname}} did that? I thought replacing the links with {{makelink}} did that. --Yair rand (talk) 07:16, 19 September 2010 (UTC)

Oops, sorry. Seems like I twisted my words in the first message. A correct message would be I added catlangname to make the categorization and makelink to make the links. --Daniel. 07:22, 19 September 2010 (UTC)

Under what circumstances in which {{en-verb}} is now used would that help? It would be more valuable if the section link was to the first Verb section in the entry. For a long entry with multiple PoS sections users may not readily find the Verb section. What's more, in a multiple-etymology English entry, which may have multiple Verb sections, it would almost certainly be more valuable for the user to be directed to the ToC. DCDuring TALK 09:08, 19 September 2010 (UTC)

Linking to the language header seems commonplace, as it is done by most language-specific templates ({{es-adj}}, etc.) and some high-use templates ({{t}}, etc.) This phenomenon may be changed upon discussion, of course, and linking to the TOC seems to be another nice proposal, which I would equally support. The main reason to link to the English section of evolves would be, as I see, the fact that this section contains every relevant information for someone who reachs this page through a link from the conjugation of evolve. --Daniel. 21:31, 20 September 2010 (UTC)

I am generally very much in favor of section links in templates. For example, the links from English verb-form entries to the verb lemma entry with a single verb section should be to that verb section. But section links do not always actually provide a benefit.

Entries for 3rd person singular present indicative form of English verbs are very short, usually consisting of just the form, sometimes also containing the plural of a homograph noun. In addition, the only L2 section that could precede it would be translingual. Now I don't doubt that diligent search could find or construct some such entries, but they will be far fewer than one percent of the total number of English verb entries. Why bother increasing the size and complexity of the code even minimally for no benefit? Is there a maintainability benefit?

The situation for simple past is the same, except there is even less possibility of another PoS section.

Combined past and past participle entries, past participle-only, and -ing form entries are also usually short and rarely (probably never) preceded by Translingual sections. Some may have valid adjective and/or noun sections that precede the verb section. But these, too are usually short. The small benefit to a small portion of entries must be paid for with a larger template for all English verb entries.

In short, there seems little if any net benefit of making such a change for {{en-verb}}. The effort should be applied to the English verb form templates, providing a default link to the verb section of the lemma. Similar reasoning probably applies to the alphabetically first common language each distinct script. DCDuring TALK 22:58, 20 September 2010 (UTC)

According to your comments and proposals, the verb-form lies would link to which section of lie? --Daniel. 14:18, 23 September 2010 (UTC)

The default could be the first Verb section, Translingual never (?) having a Verb section. I would prefer to allow a switch that would allow an editor to decide to have the link send the user to the neighborhood of the ToC. This would possibly be better in some cases with Verb sections in multiple etymologies. Can we allow the editor to specify the target section header by name (eg, English, Etymology N, Pronunciation N, etc.)? DCDuring TALK 15:38, 23 September 2010 (UTC)

Of course it is possible to allow the user to specify the target name. You may simply edit the link in most templates, like this:

• {{en-verb|lies#Verb|lying#Verb|lied#Verb}}

Alternatively, possibilities like these can be easily programmed into the discussed templates:

• {{en-verb|lies|lying|lied|section=Etymology}}
• {{third-person singular of|lie|section=Verb}}
• {{third-person singular of|lie|section=English}}
• {{third-person singular of|lie|section=Etymology 1}}
• {{third-person singular of|lie|s=lang}}
• {{third-person singular of|lie|s=etym}}
• {{third-person singular of|lie|s=pos}}

As for the default section, I would rather choose "English", because, as I said, that's where all the relevant information may be found, including etymologies and pronunciations, which I find very valuable, especially for irregular verbs.

--Daniel. 20:30, 27 September 2010 (UTC)

I've recently created {{navbox}} and intend to expand it with more optional formats, such as colors and cells. This project will require the creation of some new classes at MediaWiki:Common.css. --Daniel. 08:16, 19 September 2010 (UTC)

Why are the codes of Template:vo and Template:etyl:gmq so different in essence?

By default, vo links to an entry and gmq links to nothing. vo displays a clever way to do its linking job by using parameters and brackets, while gmq uses a #switch that expects the value "pedia" somewhere and even includes the value "disp" that seems to be never directly used. --Daniel. 10:34, 19 September 2010 (UTC)

ISO 639-5 codes aren't permitted as language headers, as they refer to language families. Other than that... Mglovesfun (talk) 10:44, 19 September 2010 (UTC)

But some of those codes are used to refer to the reconstructed ancestor of that family, and are used in appendixes. —CodeCat 15:27, 19 September 2010 (UTC)

It's because sometimes the wikipedia article link can't be automatically constructed from the display name. Cf Template_talk:etyl#Accomodating_language_families. --Bequw → τ 17:20, 19 September 2010 (UTC)

The statement "sometimes the wikipedia article link can't be automatically constructed from the display name" is true for language names too, like how {{etyl|az|en}}, , {{etyl|cpe-mar|en}}, {{etyl|si|en}} and {{etyl|waq|en}} all display incorrect links generated automatically by the "etyl" template. They rely on Wikipedia redirects to reach each correct page.

Anyway, I asked the initial question because I intend to create new templates for codes. However, in the end, the existence of two standard situations (non-link or Wiktionary link) and two programming quirks (brackets or switch) simply does not seem important enough for me to care, because they are interchangeable. --Daniel. 01:37, 20 September 2010 (UTC)

I was including redirects in my statement. While we do create Wikipedia redirects sometimes, we don't create illogical ones just so our templates link correctly. --Bequw → τ 04:36, 20 September 2010 (UTC)

I have not suggested the creation of illogical redirects for templates to link correctly. I have just commented that the same results can be conceivably achieved through the clever trick with brackets, then concluded that it doesn't matter after all. --Daniel. 05:10, 20 September 2010 (UTC)

Yeah, that #switch setup was unnecessary: {{etyl:gmq}} was created by a bot, so didn't come out as clever as it could have been. I've simplified it now. —Ruakh_TALK 21:50, 20 September 2010 (UTC)

Looks better; I've removed some white spaces as a last touch. Thanks! --Daniel. 22:21, 21 September 2010 (UTC)

Just a notice, at Wiktionary:Recent changes, the http://www.fraktionary.com/rc/ site is giving page not found errors. -- OlEnglish ^(Talk) 20:19, 19 September 2010 (UTC)

I know! Not happy, Jan! ---> Tooironic 01:56, 21 September 2010 (UTC)

Does anyone have more information about this? Like why it is down, if it is being worked on, or how long it will take to fix it? The language-specific changes lists are extremely useful and it is next to impossible to follow changes in a language other than English without them. --Zeitlupe 07:46, 24 September 2010 (UTC)

It's working again. Longtrend 22:48, 25 September 2010 (UTC)

Hi folks. Sorry to bug you again with my wiki-ineptitude. I'm working on Appendix:Snowclones and am wondering if someone could help me make a template (I would if I knew how to). Something along the lines of {{new alt}}, which would let me easily create a new snowclones subpage w/o having to type everything out (formatted along the lines of Appendix:Snowclones/to X or not to X), with five parameters: origin (for the text under the Origin header), frequency (which would specify the frequency of the snowclone), url (to link to a Google Books search), uses (for the most common phrases of that form), and notes (self explanatory). The "frequency" parameter would need to have all the options listed at here, and the "notes" parameter would need to be optional.. Leave me a message on my talk page if you want. — lexicógrafo | háblame — 22:22, 21 September 2010 (UTC)

As a related question, why to X or not to X (or another page similarly named) is not in the main namespace? --Daniel. 22:29, 21 September 2010 (UTC)

Doesn't necessarily have to not be in the main namespace, but I'm running on the assumptions that 1) most people wouldn't be looking these up anyway and 2) some of them might not be attestable enough. — lexicógrafo | háblame — 22:32, 21 September 2010 (UTC)

All of them seem attestable enough, though, especially to X or not to X. As for your statistical argument, most people wouldn't be looking up most entries individually anyway. --Daniel. 23:05, 21 September 2010 (UTC)

I suppose I phrased that wrong; I meant that most users wouldn't know to look such phrases up with the "X"s and "Y"s and all, and that anyone who does is probably doing linguistic research of some sort, to whom an appendix page would be more useful than a normal entry. — lexicógrafo | háblame — 23:19, 21 September 2010 (UTC)

Done: {{new snowclone}}. --Yair rand (talk) 22:33, 21 September 2010 (UTC)

Sweet, thanks. So will I need to put the colors and stuff into the frequency parameter or are those already there? — lexicógrafo | háblame — 22:35, 21 September 2010 (UTC)

Hm, looks like I made a mistake with the template, actually. Perhaps you could give me a list of words corresponding to standard number sets and colors, so it could do it automatically? --Yair rand (talk) 22:38, 21 September 2010 (UTC)

User:Lexicografía/Snowclones — lexicógrafo | háblame — 22:41, 21 September 2010 (UTC)

Done. --Yair rand (talk) 22:50, 21 September 2010 (UTC)

Thank you! — lexicógrafo | háblame — 23:02, 21 September 2010 (UTC)

Oh, one more thing; Is there a way to get the PAGENAME to display just the title of the snowclone, and not the "Snowclones/" part as well? — lexicógrafo | háblame — 23:19, 21 September 2010 (UTC)

Done. --Yair rand (talk) 23:26, 21 September 2010 (UTC)

Anyone know what happened to WT:EDIT? Everything gives a "Could not connect to the server." error. --Yair rand (talk) 23:55, 21 September 2010 (UTC)

I'm getting the same. Rather annoying... —CodeCat 08:34, 22 September 2010 (UTC)

It has been disabled indefinitely. -- Prince Kassad 09:28, 22 September 2010 (UTC)

Erm, why? Mglovesfun (talk) 09:46, 22 September 2010 (UTC)

Seems to be working again. --Yair rand (talk) 19:21, 22 September 2010 (UTC)

Some commons tool was killing the API servers, https://bugzilla.wikimedia.org/show_bug.cgi?id=25238, all should be re-enabled now. Conrad.Irwin 22:01, 23 September 2010 (UTC)

I just noticed that {{en-adv}} does not produce blue links in multi-word terms in constructions such as this: {{en-adv|pos=] ] ] ]|-}}. See also, for example, up the river or all of a sudden. I think it used to work. -- Ghost of WikiPedant 18:37, 23 September 2010 (UTC)

I see. It is working now. --Daniel. 18:49, 23 September 2010 (UTC)

Ah, back in business. Thanks. -- Ghost of WikiPedant 19:01, 23 September 2010 (UTC)

Is it just some aspect of my configuration or was all the styling removed from the NavBoxes since I was last around? Conrad.Irwin 22:04, 23 September 2010 (UTC)

The translation tables are normal to me (yellow background, blue and red links, collapsible, etc., as I know and love) in my Firefox 3.6.9, even after clearing the cache. --Daniel. 01:55, 24 September 2010 (UTC)

I have created Template:names to generate lists of "Alternative names:" of templates.

It is being used in {{en-proper noun}} to display links to {{en-proper-noun}} and {{en-pnoun}}.

(Alternatively, its introductory text could be "Shortcuts:", but most names of templates are similar in length, so, well...)

--Daniel. 01:46, 24 September 2010 (UTC)

Can any of you geniuses tackle this? BTW it would be nice to fully deprecate all the {{es-noun}} templates apart from {{es-noun}} itself. Spanish inflection isn't dependant on gender. I think at one point we had {{fr-noun-m}} and {{fr-noun-f}} which were deleted as they had no advantage over the unified template. Does anyone object to this? Does it require some sort of vote, or just someone with the patience to actually start replacing these on tens of thousands of pages? Mglovesfun (talk) 12:05, 26 September 2010 (UTC)

As far as I can see it's only transcluded directly in {{es-noun}} itself; it's just a 'helper' template. Not quite sure what your intention is. You want to move its code directly into {{es-noun}}? —CodeCat 12:08, 26 September 2010 (UTC)

And as far as I can see, one problem with getPlural is that it uses {{{1}}} but the calling code doesn't provide that parameter. —CodeCat 12:16, 26 September 2010 (UTC)

Sorry, it what? I mean fully deprecated {{es-noun-f}} and {{es-noun-m}} (this is already the case for {{es-noun-f-unc}} and {{es-noun-m-unc}}). You're right about the switch, but I don't know how to relay from the template to the subtemplate. Mglovesfun (talk) 12:18, 26 September 2010 (UTC)

Each template has its own set of parameters, they are not 'inherited' from one template to the next through transclusion. So to relay it, you need to pass it on as the first parameter in the inclusion of {{es-noun/getPlural}} in {{es-noun}}. E.g. {{es-noun/getPlural|{{{1}}}|

As for deprecating those gender-specific templates, I think a bot could do this nicely, or maybe AWB running on autopilot. I think replacing {{es-noun-m with {{es-noun|m should do it. Also a note: you might want to allow g= to specify the gender; either in addition to {{{1}}} or instead... most templates on Wiktionary use g=. —CodeCat 12:56, 26 September 2010 (UTC)

Could you do that relay for me (as I'm not 100% confident I'll get it right). Yes, it seems quite likely that doing it by bot will work, I also support adding g to be the same as 1, again with switches, I'm not sure how to do that. Outside of switches, I do know. Mglovesfun (talk) 17:05, 26 September 2010 (UTC)

Ok, done. See this diff. I replaced all occurrences of {{{1}}} with {{{1|{{{g|}}}}}}. —CodeCat 09:26, 27 September 2010 (UTC)

Turns out it's really easy to change these by bot to alternative forms. If someone can send me a txt file with these (as up-to-date as possible, please) I'll happily do the whole lot, leaving AutoFormat free to do other thing. Mglovesfun (talk) 17:03, 26 September 2010 (UTC)

Sent. The rate at which AF is correcting them has dropped. In August, 9k were cleaned up, but in September it's only on track to cleanup 2k. There are ~17k left. I imagine most of those are those entries infrequently edited. --Bequw → τ 18:13, 26 September 2010 (UTC)

Can we please add luxo's tool to the contributions of ip addresses? I'd like to monitor cross-wiki disruption here and on wikipedia. You can see an example of its use on the "Global contributions" link on the bar at the bottom of this ip address' contributions. :| TelCoNaSpVe :| 06:59, 27 September 2010 (UTC)

 Done since I can't imagine anyone objecting to this. —Internoob (Disc•Cont) 22:56, 27 September 2010 (UTC)