Wiktionary:Grease pit/2010/October

= October 2010 =

Mediawiki:Common.js
Has the trial ended yet for User:Conrad.Irwin/editor.js? It seems like it's gained greater use nowadays. TeleComNasSprVen 04:56, 2 October 2010 (UTC)

MediaWiki:Isimage
Can an admin please change the wording to "file link" instead (see en:MediaWiki talk:Isimage) and delete the associated talkpage? Thanks. TeleComNasSprVen 18:44, 2 October 2010 (UTC)
 * Done, talk page kept (relevant). Mglovesfun (talk) 14:54, 4 October 2010 (UTC)

family codes at
I have created the codes for all the once codeless families listed at.

Then, as an attempt to introduce overall consistency, I have removed the names of families listed in that template, and replaced them by a big list of codes.

I have also improved a little how recognizes types of families, such as implementing the text "It is the reconstructed ancestor of all Germanic languages, [...]" at Category:Proto-Germanic language, as opposed to simply "It is a Germanic language [...]" --Daniel. 19:30, 2 October 2010 (UTC)

Topic cat cleanup stuff
I was wanting a list of all the categories that use and (separately). Most of the time something more specific would be better, for example "The following is a list of words related to yoruba derivations" is not a very good category summary (note the yoruba ). Oh, I managed to obtain these lists but including all the individual languages like :fr: and :hy: (etc.) meant they were massive. Any chance of only the English topical categories?

Furthermore, much much less important, some of the and description templates are orphans and should (in most cases) be deleted, but this isn't urgent. Mglovesfun (talk) 23:31, 3 October 2010 (UTC)

Template:etyl:ell
I quite like the idea, proposed most recent by Vahagn but also before then of displaying Modern Greek, but categorizing in

. So I've started the template as to avoid experimenting on a very large category. I just don't know how to get the display and the category name to be not identical. Help, please? Or objections, if there are any. Mglovesfun (talk) 14:04, 4 October 2010 (UTC)


 * I don't think that's what Vahagn was proposing, but maybe I misunderstood him. I thought he wanted to be exactly like what  and  currently are. He even raised the possibility of changing  to be Modern Greek. But to answer your question — you would do something like this:
 *    
 * ( generates a link with text   and target  w: , and categorizes in   . Someday I'll document that at Template:etyl/doc, if no one beats me to it.)
 * —Ruakh TALK 14:52, 4 October 2010 (UTC)
 * Do you mean deprecating Category:Greek derivations, apart from as a parent category? See WT:RFM. Mglovesfun (talk) 15:02, 4 October 2010 (UTC)
 * Re: "Do you mean deprecating Category:Greek derivations, apart from as a parent category?": Yes, exactly. —Ruakh TALK 17:01, 4 October 2010 (UTC)
 * I think it's mostly a good idea. I proposed the opposite on WT:RFM because Category:Greek derivations is our standard one, and Category:Modern Greek derivations only has 4 members in 4 years. I didn't propose it 'on principle' if you like. Mglovesfun (talk) 22:43, 4 October 2010 (UTC)
 * Understood. One major reason that Category:Modern Greek derivations has so few members compared to Category:Greek derivations is that there are so few words derived from Modern Greek, and the latter mostly contains miscategorized words from Ancient Greek. The other major reason, of course, is that categorizes into Category:Greek derivations; but that's easy to change, once existing entries are fixed. ( is working on that, and seems to have made a lot of progress in short order. There are now fewer than 400 words with  or, and of course some of those are using it correctly.) —Ruakh TALK 23:36, 4 October 2010 (UTC)
 * Coming a bit late here: I oppose the existence of the category Category:Modern Greek derivations. See also Beer parlour, the section "Modern Greek", September 2010. --Dan Polansky 07:02, 14 October 2010 (UTC)

Template:en-noun at Appendix:Star Wars/protocol droid
There is a recent and considerably large BP discussion named English appendix-only nouns, about the existence of appendices for certain constructed and fictional terms.

For example, there is Appendix:Pokémon/shiny, defining an English adjective ("shiny") clearly existing only in context of Pokémon. This page contains the template and other common aspects of entries, such as a language header and a part-of-speech header. en-adj is programmed to automatically recognize when it is being used in an appendix, so it may display the results accordingly, without the "Appendix:Pokémon/" part of the title.

One particular major template that is currently not programmed to be usable in appendices like this is. Therefore, the page Appendix:Star Wars/protocol droid displays various formatting errors instead of the proper appearance of an entry.

When I opened the BP discussion, I have expressively and specifically asked about the use of en-noun at Appendix:Star Wars/protocol droid. However, the discussion ended up covering various related subjects, notably the possible classifications of religion, well-known works and the merit of having "context-only" entries at all.

Given the nature of the Beer Parlour versus the nature of the Grease Pit, it seems natural to focus, in the BP, practical reasons and effects instead of technical means.

Therefore, setting aside the issues of whether and what certain entries should be appendicized, I would like to highlight here the possibility of using that particular template at that particular page.

One particular different suggestion that occurred at the BP discussion was of using glossaries of definitions (like, maybe, listing all words from Pokémon using the format of Glossary of golf?), completely replacing individual pages. I, personally, would oppose this suggestion, because it defeats the purpose of organization by effectively deprecating categories like this for certain English adjectives and also defeats the purpose of informativeness, by leaving a small space where pronunciations, translations, citations, etymologies and other sections would probably be absent.

Another, pretty old, proposal was of using a different template similarly named, but only for appendices, like (or, jokingly, in another discussion, ) I would like to point out to the fact that en-noun is now programmed to be used only in the main namespace, therefore if it is not adapted to work properly in Appendix:Star Wars/protocol droid, Appendix:Harry Potter/Patronus, Appendix:DC Comics/power ring and related pages, it would conceivably not be used in any other appendices whatsoever. Then, it is unnecessary to have another, different template just for appendices.

It also seems natural to use the same format to define and organize all words. Given my reasons, if there is no objection, I'm going to adapt en-noun for it to be used in Appendix:Star Wars/protocol droid. --Daniel. 06:13, 6 October 2010 (UTC)
 * I oppose your adapting en-noun. Above all, I oppose having one page per term from a fictional universe in the appendix namespace. --Dan Polansky 06:56, 14 October 2010 (UTC)
 * Yes, you've made that clear before, but that is not the issue here. The issue is whether there is a problem with allowing the possibility of the templates showing up correctly in those types of appendices for the time being, regardless of whether we will end up keeping them. As the change has apparently no effect whatsoever on normal pages, I don't understand what the problem would be. Could you explain exactly what is your reason for opposing? (Note that this is not about allowing or disallowing these pages; that discussion belongs in the Beer parlour.) --Yair rand (talk) 07:08, 14 October 2010 (UTC)
 * Well I have made this clear before, but Daniel Dot chooses instead to switch from Beer parlour to Grease pit (I usually do not monitor Grease pit, only Beer parlour), and pretends to be free to edit en-noun unless someone opposes in Grease pit. I am explicit here, to make things traceable for anyone who comes to this thread by accident, to a thread that has up to now looked unopposed.
 * Daniel Dot likes to act without consensus or even contrary to consensus, based on his own reasoning. After Daniel Dot demonstrates consensus for one page per term in appendix namespace, he can continue to proceed in this way; until then, he should stop immediately.
 * I know that you support Daniel Dot in his one-page-per-term-in-appendix, but two people are not consensus. When you have a hunch that you would lose a vote, you say that voting achieves nothing, despite plentiful evidence to the contrary. There is one thing that voting really does not achieve: enacting a proposal that has a minority support. --Dan Polansky 07:29, 14 October 2010 (UTC)
 * No. One-page-per-term-in-appendix is nasty. Templates should not be modified to support this. SemperBlotto 07:33, 14 October 2010 (UTC)
 * (after edit conflict) Even today, Daniel Dot has created Appendix:Conker_the_Squirrel/Anti-Gravity_Chocolate as if there were no significant opposition. I oppose his modification of "en-noun", as that is one way to prevent a practice with which I disagree: having in the appendix namespace pages that look like English entries in the mainspace. --Dan Polansky 07:36, 14 October 2010 (UTC)
 * You are ... opposing the template modification ... in order to support your side of the dispute? --Yair rand (talk) 07:45, 14 October 2010 (UTC)
 * I guess. Anything wrong with it? I think that mainspace-like English entries should not be in the appendix mainspace. Thus, this practice should be unsupported in . A widely used template should not be modified in order to support practice that is widely opposed, right? --Dan Polansky 07:56, 14 October 2010 (UTC)

Custom collation orders for categories
Currently, many languages use some kind of sort parameter with their categories so that entries are ordered correctly according to the rules of that language. However, it occurred to me that this could very well be made automatic, which would save a lot of hassle. Maybe there should a way for the default collation order for specific categories could be altered, so that it matches the order of the language in question. Perhaps via a Mediawiki extension? —CodeCat 17:40, 8 October 2010 (UTC)
 * There's a bugzilla bug about that. I think it is one of the first bugs submitted. -- Prince Kassad 22:42, 8 October 2010 (UTC)
 * I'm guessing most people forgot about it then. Shame, because this seems like a rather useful addition for a multilingual wiki. Does anyone know what would need to be done for this to work? —CodeCat 15:35, 12 October 2010 (UTC)


 * There's recently been some work on per-site Category collation (for the non-English Wikipedia's), which should be extendible to per-category if someone has a bit of time. http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg08230.html is the original mailing list post, and there are some good links (and a long discussion) if you're interested. Conrad.Irwin 22:10, 12 October 2010 (UTC)

Neuter plural template
I think I noticed that in the Asturian language, there's a neuter plural form that's also the same as the masculine plural form. How do I make a template for that? - Lo Ximiendo 22:58, 13 October 2010 (UTC)


 * Try this: ->  —CodeCat 23:27, 13 October 2010 (UTC)

It has something to do with making a definition, such as "Template:masculine plural of". The template that I have in mind is "Template:neuter plural of". - Lo Ximiendo 23:41, 13 October 2010 (UTC)
 * Use : . Nadando 23:46, 13 October 2010 (UTC)

Thanks, Nadando. I had to make that kind of definition the hard way. - Lo Ximiendo 00:32, 14 October 2010 (UTC)

zh and cmn in Assisted translations, ø is undesirable
Hi,

Can somehow the symbol ø be removed for Assisted translations when using cmn as the language code? It removes the link from zh.wiki. We always use zh to add Mandarin Chinese translations because cmn creates this: ... zh would work as this: ...夜店 Note missing ø. Bots later change zh to cmn but they don't add ø symbol, which is fine. Random users sometimes use cmn, which removes the link from Chinese Mandarin Wiktionary as in the example.

zh code is actually abused, it stands for Chinese (Zhōngwén), not Mandarin (cmn = Chinese Mandarin) but that's OK, I think, welearned to live with it. We have an agreement to nest Mandarin and other translations under Chinese. --Anatoli 23:42, 13 October 2010 (UTC)

Edittools broken again
The customizable "Default" edittools has stopped working for me. It was working earlier today. I use this feature extensively and would appreciate it if someone could figure out where this became broken and correct the problem.

What's happening is that the custom section of the tools works only sporadically. When it works, it inserts the selected text. When it doesn't, it opens a new editing screen wheh the text to be inserted is clicked. --EncycloPetey 01:44, 14 October 2010 (UTC)


 * After nearly a month, the problem is still present and is making it difficult for me to do the kinds of work I do with Latin and pronunciations. --EncycloPetey 17:33, 12 November 2010 (UTC)


 * It works for everyone else, so there's not much we can do. -- Prince Kassad 17:45, 12 November 2010 (UTC)


 * Do we know that? Which other people have been successfully using a personalized #default section of the Edittools?  How many use Macs?  Does anyone technically proficient have an idea why this is working only a fraction of the time for me, and not working most of the time? --EncycloPetey 23:33, 14 November 2010 (UTC)

geoiplookup.wikimedia.org
What is this? I see a "waiting for it" message the start of each session. SemperBlotto 12:43, 14 October 2010 (UTC)
 * AFAICT it is to collect statistics and identify your country to display a localized banner. For my IP, http://geoiplookup.wikimedia.org/ shows country, latitude and longitude.  See Hit stats aggregation and mw:Extension:CentralNotice/Phase 2 . --InfantGorilla 09:58, 16 October 2010 (UTC)

Code for Recent changes by language
Is the code that shows recent changes by language available ? If it is maybe mirrors could be set up beside fraktionary, or it could be run locally by people who want to. It really is an indispensable tool for me, and for others as well I'm sure, the only one I know of that allows patrolling a single language at a time. Gougnafier 12:48, 15 October 2010 (UTC)
 * Per this. The fraktionary site really hasn't been working reliably at all lately, which is quite annoying if you want to keep track of changes in specific languages. Longtrend 13:53, 14 November 2010 (UTC)

Template:eo-proper noun/new
Have created this to solve the issue I pointed out on the talk page of eo-proper noun. I can't see any bugs right now. Main 'issue' would be changing the format of countable proper nouns, by changing to. This is because multi-word proper nouns can use something like in which case, even if it's countable,   can't be j and Rusia at the same time. Mglovesfun (talk) 16:22, 15 October 2010 (UTC)

The nonexistent Pennsylvania German edition of Wiktionary
One of the functions of is pointing to the Wiktionary edition of a particular language. However, langcatboiler expects that everybody who creates a new language category knows if there is a Wiktionary version and adds the link, or removes the link.
 * For instance, at Category:Spanish language, there is the text "Spanish language edition of Wiktionary http://es.wiktionary.org/wiki/".
 * Since most people do not add the proper link to the Wiktionary version, it shows an standard value in most categories, such as the erroneous text "Pennsylvania German language edition of Wiktionary http://pdc.wiktionary.org/wiki/" at Category:Pennsylvania German language.

I hereby propose: --Daniel. 17:32, 16 October 2010 (UTC)
 * 1) Deprecating the parameter  (and other parameter, ) of, thus sparing the burden of editing the link for every category.
 * 2) Using, with all the Wiktionary versions listed, to feed  with the correct values whenever necessary.
 * Definitely a superior approach, AFAICT. DCDuring TALK 18:56, 16 October 2010 (UTC)


 * If it automates an error-prone process without reducing its usefulness, then sure, go for it. —CodeCat 21:07, 16 October 2010 (UTC)


 * It's a good idea in principle, but your exact suggestion won't work, because has to support all Wikipedias, which means that it can't distinguish languages that have Wikipedias but not Wiktionaries from languages that have both. (For example,  produces <tt>fiu-vro</tt> even though there's no Võro Wiktionary.) Instead, we should create a new, separate template that "knows" which Wiktionaries exist. (Also,  is used in tens of thousands of entries, so it wouldn't be a good idea to make it so much heavier by having it include a list of all Wiktionaries, even if that were easy to do.) —Ruakh <i >TALK</i > 16:41, 17 October 2010 (UTC)

This project is done. The parameters and  are now meaningless for. As a side effect, hundreds of categories still contain the unused parameters in their codes.

I have also introduced the ability of displaying two or more Wiktionary links simultaneously; and links to Wiktionaries that are at Wikimedia Incubator. And the name of the Wiktionary edition between parentheses when it differs from the name of the current language.

Here are some relevant examples.


 * Category:Portuguese language (one link)
 * Category:Isthmus-Mecayapan Nahuatl language (one link, to a language differently named)
 * Category:Cree language (one link, to incubator)
 * Category:English language (two links)
 * Category:Montenegrin language (two links, to languages differently named)
 * Category:Cantonese language (two links, including one to Incubator)
 * Category:Serbo-Croatian language (four links)

To see all the connections between languages and Wiktionary editions at once, or modify them, go to. --Daniel. 08:12, 21 October 2010 (UTC)

param
I think I still have not formally introduced one of my last simple templates, that is akin to and.

returns.

Or, returns.

That's it. --Daniel. 03:29, 18 October 2010 (UTC)


 * Count on you to make templates for everything. :P I'll see if it proves useful, but the only time it is strictly necessary is if it's used in a template itself. You can type in any other place just fine. —CodeCat 10:45, 18 October 2010 (UTC)


 * Oh but I like how and  format the resulting texts.


 * To point to a template called "abc", you can type Template:abc, abc, or even, but the best cosmetic choice to me is . --Daniel. 14:49, 18 October 2010 (UTC)
 * You've come up with a template that accomplishes the same thing, but in more keystrokes, not fewer. Mglovesfun (talk) 16:47, 18 October 2010 (UTC)


 * Hmmm, if keystrokes are an issue, we can transform "" into "". (or any other name, since is taken and I like  anyway)
 * However, I guess my math is different from yours, Martin:
 * <tt></tt> totalizes 18 keystrokes.
 * totalizes 13 keystrokes.
 * --Daniel. 17:22, 18 October 2010 (UTC)
 * (edit conflict) Technically, <tt> <tt></tt> </tt> is five characters longer than <tt> </tt>. Even so, this doesn't sound particularly useful. --Yair rand (talk) 17:25, 18 October 2010 (UTC)

rhymecatboiler and shortcatboiler
The last catboilers that I have created are and.


 * The former is for categories of rhymes and may be expanded with related subcategories, such as refractory rhymes and so on.
 * The latter is for categories of abbreviations, acronyms and initialisms. Maybe it can be expanded with contractions sometime in the future.

Examples of categories with these catboilers are Category:French rhymes and Category:Latin abbreviations.

One particularly beautiful new function is the addition of an [edit] button that points to certain individual templates like Template:shortcatboiler/initialism, which controls all the initialisms. So, that [edit] button may be used to change descriptions and categorization of all the related categories.

I have yet to properly document how to edit Template:shortcatboiler/initialism and others; it is a task of high priority for me, so it will be done soon. Anyway, their code is considerably simple and intuitive, like how <tt> |description= groups of words represented by their beginning parts pronounced separately. </tt> may be edited to change the description. --Daniel. 15:12, 18 October 2010 (UTC)


 * What about naming these boilers like and, on the model of ? My eyes are not particularly accustomed to looking for implied compoundworddivisionindications. Another option is to use spaces, on the model of  and , so it would be  and . Actually, these variants with spaces look better, and fit to great many templates used in Wiktionary. --Dan Polansky 16:05, 18 October 2010 (UTC)


 * I would agree with using spaces, since we already have . I think it would be good if all other boilerplate templates were named just like that one, i.e., , and so on. It would also be nice if the parameters of  worked the same as the others (numbered rather than named). —CodeCat 16:18, 18 October 2010 (UTC)


 * On another note, if "boiler" is rare, a template should better be called . As the name of the category can be added to the target place using copy-and-paste, the length of the name does no harm. --Dan Polansky 20:41, 18 October 2010 (UTC)


 * All right, I can see four different names for in this discussion. Please decide on which name to use. Or should all of them be redirects? In this case, you have to decide which one is to be the standard name.
 * Renaming "poscatboiler" to "pos cat" and "langcatboiler" to "lang cat" does not make seem the best actions if the goal is making these templates supposedly longer in a way to achieve instant readability. I would expect and  in this case.
 * In addition, please note that is a template widely used and mentioned in discussions; renaming it may require a vote. --Daniel. 21:04, 18 October 2010 (UTC)
 * Personally, I prefer names like <tt>rhymecatboiler</tt>. --Yair rand (talk) 21:10, 18 October 2010 (UTC)
 * Why do you prefer names like <tt>rhymecatboiler</tt>? What is the benefit of such hard-to-decipher names? --Dan Polansky 21:27, 18 October 2010 (UTC)
 * Ease of typing it out. <tt>shortcat</tt> and <tt>rhymecat</tt> would be even better, IMO. --Yair rand (talk) 21:35, 18 October 2010 (UTC)
 * I don't find <tt>rhymecatboiler</tt> hard-to-decipher, and possibly today Dan Polansky doesn't consider it difficult too, given that he already know what it means. Since I often type commands like "", I too prefer short but understandable versions such as <tt>rhymecatboiler</tt> (or even <tt>rhymecat</tt>, as suggested above).
 * And, as I commented in another conversation, the common practice is "choosing short, abbreviated, spaceless, lowercase names that vaguely resemble why said templates exist", like, , , and even the parser function <tt>  </tt>; wikisyntax such as <tt>===Header 3===</tt> also share the characteristic of being more clear to one who already knows what it means. By the way,  does not make the template completely clear unless one reads the documentation and learns about it, or see it in existing categories and figures out how to use it; the longer name is not inherently enlightening.
 * A much longer explanation would be necessary to replace documentations and certain knowledge of wikisyntax, such as possibly . --Daniel. 21:53, 18 October 2010 (UTC)
 * Yair rand, ease of typing is a really poor reason: you can cut-and-paste. Programmers who state ease of typing as a reason for inventing horrible identifiers for classes, methods, and variables should be reeducated.
 * Daniel Dot, re "possibly today Dan Polansky doesn't consider it difficult too, given that he already know what it means. ": the names of the template should be easy to decipher for a newcomer to the template. Second, allowing spaces is a minor concession for readability; would already be an improvement. Further,  is acceptably long with its 35 characters. Long names should be entered using copying and pasting. Even if you insist on typing, a template redirect can be created so that you can avoid typing the long name. The template system is not here to serve you; it is to serve all editors. Yet you act as if you were the sole client of your templates. The overlong example given in your last sentence is absurd, and requires no further comment. --Dan Polansky 07:15, 19 October 2010 (UTC)
 * To me, if a template's name is so long that it needs to be copied and pasted for convenience, I think its name needs to be shortened. I'm certainly opposed to a name like . —CodeCat 09:38, 19 October 2010 (UTC)
 * Dan, why would I ask for opinions about names of templates, then would you type "Daniel Dot, re", shortly followed by "Yet you act as if you were the sole client of your templates"? It does not seem to make any sense. --Daniel. 12:45, 19 October 2010 (UTC)
 * You speak of your often typing the names, as if your typing were more important than newcomer's understanding. You can copy and paste. --Dan Polansky 20:08, 19 October 2010 (UTC)
 * Identifiers that are easy to read need to be copy-and-pasted; there is no way around that. Copying-and-pasting is not more work; it is a different style of work. Identifiers that are hard to read favor their lazy creators who have memorized them to the disadvantage of newcomers who have not yet memorized them. But even if you insist on typing, there can be a redirect for you, as I have pointed out. From what I can see, you only care about your typing convenience stemming from a wrong habit of avoiding copying and pasting, disregarding the requirement of readability. Decent APIs use readable identifiers, ones that take long to type, and are better copy-and-pasted. --Dan Polansky 20:08, 19 October 2010 (UTC)
 * I have already explained how an overly long name is not a guarantee of enlightenment. I have informed my personal opinion, and I brought up the idea of employing redirections for the case of future conflicts of opinions; and I am still waiting for people to reach a consensus.
 * Dan, your tone is too dictatorial. Repeatedly. For what is worth, I am on your side, as I too care about newcomers. Please cease your erroneous psychological statements about me and go back to a fruitful discussion. --Daniel. 20:53, 19 October 2010 (UTC)

What categories still do not have boilers?
That's it. Please inform me what categories still do not have the benefit of category boilers, so it will make me easier to work on them. --Daniel. 15:12, 18 October 2010 (UTC)
 * I detect hidden assumptions in the question. Perhaps you might ask: Which categories does someone think might be proposed to have such boilerplate. I, for one, dispute the utility of such boilerplate for any English category and for any other language where there is an adequate community of users. Standard naming, where practical, is one thing; standard content is another. DCDuring TALK 17:20, 18 October 2010 (UTC)
 * Agreed. I would rather ask the question, "What categories still have boilerplate?", so we can set about removing it! —Ruakh <i >TALK</i > 17:30, 18 October 2010 (UTC)
 * You may as well recognize "What categories still do not have boilers?" as "What categories [that need catboilers] still do not have [them]?" In this case, I think some of the most natural replies would be Category:Italian combined forms and Category:English alternative forms.
 * If, nonetheless, the reply is "None." my work is automatically completed, thus it became easier than I thought. Now you may turn the subject around, discussing whether or not to remove catboilers from categories, if you want. I'll be watching it. --Daniel. 17:41, 18 October 2010 (UTC)
 * IMO, all category types that exist across languages should use category boilers. However, it might be useful for the boilers themselves to have the option to override the default text, for the few language-specific instances that it would be helpful for. --Yair rand (talk) 17:48, 18 October 2010 (UTC)
 * Actually, I think I like the idea of default boilerplate for categories of a given class, even in English, but I would like the access to the boilerplate text to be transparent to non-technical types, especially, but not limited to, me. If I do not have ready access to the default text and find it wrong in any detail, I am inclined to simply remove the boilerplate, copy what parts seem worthwhile, delete what seems wrong, and modify the content in other ways in accordance with my peculiar understanding of the consensus or the usual or best practice of the Wiktionary community (or the English-language portion thereof, when relevant).
 * Also, almost any category text - even at the level of an individual category - may need to be supplemented by notes about idiosyncrasies of a particular category or group of categories. The category talk pages are not sufficiently often read AFAICT to be a reliable way to communicate such information, especially as regards easy-to-make errors. DCDuring TALK 19:53, 18 October 2010 (UTC)
 * DCDuring has here expressed better than I can sentiments with which I agree. &#x200b;—msh210℠ (talk) 20:00, 18 October 2010 (UTC)
 * Ditto. —Ruakh <i >TALK</i > 20:04, 18 October 2010 (UTC)
 * The first issue can, I think, be solved by [edit] buttons like those in the new rhymecatboiler and shortcatboiler templates, once they are implemented in the rest of the category boiler templates? --Yair rand (talk) 20:10, 18 October 2010 (UTC)
 * Could somebody add the relevant sense to boiler? Lmaltier 20:14, 18 October 2010 (UTC)
 * ✅. But if someone were to RFV it, I'm not absolutely positive that it would pass! —Ruakh <i >TALK</i > 20:38, 18 October 2010 (UTC)
 * All subcats of Category:Contractions by language. --Yair rand (talk) 11:27, 6 December 2010 (UTC)

Encoding problem in the alpha-bar
Who is responsible for the alpha-bar? (I mean the thing shown at the top of an entry that lists the preceding and subsequent words in alpha order.) It has an encoding problem. Example: I go to négations and the bar shows "n�gatifve « n�gatifves « n�gationniste « n�gationnistes « négations » n�gative » n�gativement » n�gatives » n�glige"; those links do not work because the accented char has been mangled. Also, the alpha-bar is out of Vodka Mudshakes. Equinox ◑ 20:52, 18 October 2010 (UTC)


 * We're a wiki, so I don't know if anyone is "responsible" for it, but Hippietrail created it, and it's hosted on his tool-server account, so it won't be fixed until either (1) he fixes it or (2) someone moves it to their own tool-server space and fixes it. (Several of the recent discussions at User talk:Hippietrail center on things that Hippietrail's tool-server account is hosting. When he gets back to a full activity level, we'll have to engage in some nudging. :-)  ) —Ruakh <i >TALK</i > 23:57, 18 October 2010 (UTC)

Alternative table wikisyntax
I find convenient listing my actions here at the GP, where other people and I may or may not comment, discuss and improve them. Thank you for your attention.

Well, I have recently created (where necessary) short documentations for, , , and , which return <tt>|</tt>, <tt>||</tt>, <tt>{|</tt>, <tt>|}</tt> and <tt>|-</tt> to generate tables that don't ruin parser functions.

I also linked them to each other through the "Supplementary templates" box, among other 20 indirectly related templates. --Daniel. 21:19, 18 October 2010 (UTC)


 * When a given row or cell is to be included or excluded based on a parser function, I prefer the HTML(-like) syntax for tables: &lt;table&gt;, &lt;tr&gt;, &lt;th&gt;, &lt;td&gt;. I think they're much easier to read in that case. What do other people think? —Ruakh <i >TALK</i > 23:48, 18 October 2010 (UTC)


 * I've never used HTML to create a table on a wiki, so I prefer Daniel's method. —CodeCat 09:35, 19 October 2010 (UTC)


 * Have you used to create a table on a wiki? :-P   —Ruakh <i >TALK</i > 17:31, 19 October 2010 (UTC)

Estonian conjugation template
Has anyone ever created a template for a conjugation table before? I wish there's a conjugation template for Estonian verbs. - Lo Ximiendo 01:19, 21 October 2010 (UTC)
 * Can you please list the information that should be at Estonian conjugation tables? That is, the possible tenses, grammatical persons, etc. It would probably help people to help you. --Daniel. 08:50, 21 October 2010 (UTC)
 * Estonian is very similar to Finnish, so you can use the Finnish templates as a base. I'm also willing to help out although I know very little Estonian (though I do know the basics of Finnish). —CodeCat 09:03, 21 October 2010 (UTC)

Help with regex
I've come up with a system for removing blue links from wanted entries pages (or indeed any page). It's basically the following:

foo becomes foo

This sort of substitution is easy with AWB, just I need it to give me the word in double square brackets twice, that's the only thing I don't know how to do. Regex probably tells me how, but I'm not seeing it. Mglovesfun (talk) 11:06, 21 October 2010 (UTC)


 * I don't know about wiki-specific regexes, but in at least some notations you can "capture" a match in parenthesis and then use it in the replacement, e.g. (untested head code) &mdash; s/l(.)st/b$1t/ should produce bet from lest and bat from last. Equinox ◑ 11:52, 21 October 2010 (UTC)


 * Indeed, that is how AWB does it. (See w:Wikipedia:AutoWikiBrowser/Regular expression.) Also, <tt>[</tt> and <tt>]</tt> have special meaning in AWB regexes, and must be quoted. So, in Mglovesfun's example, he would want to replace <tt>\[\[(foo)\]\]</tt> with <tt> $1 </tt>. (But I'm not sure how well that would work in practice, since on many wanted entries pages, there's some discussion after a lot of words. It would engender a lot of confusing to remove a bluelinked word while leaving the discussion about it. Also, just because a word is a bluelink, that doesn't mean the request has been fulfilled: the entry may be in a different language.) —Ruakh <i >TALK</i > 12:39, 21 October 2010 (UTC)
 * I'm aware of that. And you know it . Mglovesfun (talk) 17:46, 21 October 2010 (UTC)

fr-noun templates

 * Moved to Template talk:fr-noun

Suffix and prefix categories within entries
This is another recent major change: and  have been modified by me, Nadando, DCDuring and other editors, either through directly editing them or by suggesting and discussing improvements.

To see the last results, clean your cache and take a look at the "Derived terms" section of -ity. It should be displayed as a light-blue collapsible list of words that are members of Category:English words suffixed with -ity. The most recent change was making the category appear above all its members. --Daniel. 11:52, 22 October 2010 (UTC)


 * It's a good start, but it has some usability issues especially with large categories. Even the link you provided has a veeeery long list. So I don't think it would be particularly useful in many cases. —CodeCat 14:12, 22 October 2010 (UTC)
 * I preferred the version that presented the list in three columns, which is then at most veery long, usually not very long at all. It is handy that clicking on the category name itself gives the complete category, not just the first 200 members. It is a shame that we don't provide users with some idea of whether or not they are looking at a complete list and what to do to get a complete list. DCDuring TALK 15:17, 22 October 2010 (UTC)
 * It should still be in three columns- try clearing your cache. Nadando 16:54, 22 October 2010 (UTC)
 * Indeed, thanks. DCDuring TALK 18:11, 22 October 2010 (UTC)

The problem with white space has been reintroduced. See. --Vahag 17:38, 29 October 2010 (UTC)

Wikipedia and Commons templates for langcatboiler
I have two suggestions very similar to the recently finished project WT:GP:


 * I propose creating a new template to list all the Wikipedia articles for languages together, returning the article "Guernésiais" at Category:Guernésiais language, but "Mandarin Chinese" at Category:Mandarin language, and so on.
 * I also propose creating another template for Commons categories of languages to be listed together.

As a result, the parameters and  (and, and ) from  would be deprecated. --Daniel. 14:43, 22 October 2010 (UTC)

wtf is wrong with en-noun?
See smoker's cough, it's displaying a plural in bold, but not linking to it. I used instead. Mglovesfun (talk) 16:29, 23 October 2010 (UTC)
 * Daniel has been playing with it again. SemperBlotto 16:35, 23 October 2010 (UTC)
 * fains seems to be broken too. Mglovesfun (talk) 20:54, 23 October 2010 (UTC)
 * Can we give Daniel some kind of sandbox environment so he doesn't break important stuff every couple of weeks? Equinox ◑ 21:15, 23 October 2010 (UTC)
 * That's the point of things like, then you test on a couple of mainspace (attestable?) entries and if it works, move the code to the real template. I think the problem might lie with , which sometimes erm, doesn't. Mglovesfun (talk) 21:20, 23 October 2010 (UTC)
 * Yes, I've created and I'm regularly editing User:Daniel./Sandbox and qwertyqwerty to make relevant tests. I probably could not have predicted that <tt>  </tt> returns TRUE but <tt>  </tt> returns FALSE at smoker's cough, because these results apparently make no sense. I blame MediaWiki for this error. Or, rather, I blame my previous lack of knowledge about this obscure aspect of MediaWiki. It has been fixed. Once more, sorry for the trouble. --Daniel. 23:36, 23 October 2010 (UTC)
 * Interesting. It looks like <tt> </tt> at [[smoker's cough]] evaluates to <tt>smoker&amp;#39;s cough</tt>, which remains intact when it's in a simple link, but which gets converted back to <tt>smoker's cough</tt> when it's used in a template transclusion that's treated as a simple link. I would never have guessed that that would happen. (But then, I don't go around making major unnecessary changes to templates that already work perfectly …) —Ruakh <i >TALK</i > 03:05, 24 October 2010 (UTC)
 * I have never worked with the templates, but would it be possible/desirable for each template to have full documentation, including any quirks of encoding or behaviour, the responsibility for this documentation lying with the author? If anyone can create any old template and not fully test or document it, we will end up with this situation where nobody dares to change anything because it might bring the house of cards down. Equinox ◑ 03:09, 24 October 2010 (UTC)
 * The problem is that the MediaWiki parser has a lot of weird quirks, and no amount of documentation will prevent that. The solution is for editors to keep changes to an absolute minimum, and to advertise all necessary changes in a way that other editors can readily find. 's changes, overall, have had the effect of making that very difficult, because he's modified a lot of templates to depend utterly on several levels of meta-templates. He then breaks a deeply buried meta-template, and there's simply no way that an editor who notices the broken entry can even figure out which template changed, let alone do anything about it. (I mean, one can often find the relevant change by looking through 's recent contributions, but occasionally it's actually someone else who broke something, and occasionally has made too many recent changes for such examination to be feasible. He never uses edit summaries, so there's really no guessing.) —Ruakh <i >TALK</i > 03:17, 24 October 2010 (UTC)

Where's Autoformat been since October 5th?
According to Special:Contributions/AutoFormat, it hasn't run since October 5th.

Am I looking at the wrong source for that information?

If it hasn't run for 18 days, why?

Can it be restarted? DCDuring TALK 20:20, 23 October 2010 (UTC)
 * Simple answer is Robert Ullmann is ill, and nobody can fix it until he comes back. Mglovesfun (talk) 20:54, 23 October 2010 (UTC)
 * ...or someone has enough free time to travel to Kenya and restart RU's computer. -- Prince Kassad 21:27, 23 October 2010 (UTC)


 * Code is available at User:AutoFormat/code SemperBlotto 21:38, 23 October 2010 (UTC)
 * Autoformat still hasn't restarted and Tbot hasn't been going since September 23. Strangely, Interwicket is working perfectly... --Yair rand (talk) 23:37, 1 November 2010 (UTC)
 * I don't know what modification he's done in his pywikipedia but I can:
 * try to run a kind of hybrid of the French Autoformat
 * except if another volunteer wants to warranty a greatest implication. JackPotte 05:20, 2 November 2010 (UTC)
 * In a first time, I've requested the Bot flag. JackPotte 16:22, 4 November 2010 (UTC)
 * Why not run AF's code itself? &#x200b;—msh210℠ (talk) 18:29, 4 November 2010 (UTC)
 * I can try but I've read on its page that it wasn't advised as the pywikipedia was modified. Moreover I dislike modifying a page just to set two cosmetic carriage returns instead of one. JackPotte 18:45, 4 November 2010 (UTC)

(removed previous message) AutoFormat now provisionally runs under User:KassadBot. -- Prince Kassad 20:56, 9 November 2010 (UTC)

Perpetual redlinks at Wikisaurus headers
According to common practice, Wikisaurus pages are supposed to contain a rectangular header from the template, that contains a link to a policy, a search box, among other objects.

One particular, conspicuous header is the one of Wikisaurus:beautiful woman, which contains a bold redlink to the sum-of-parts entry beautiful woman. Other Wikisaurus pages named after sums of parts, such as Wikisaurus:ugly woman, also display a redlink at their headers. This leads me to make a formal suggestion.


 * I hereby propose the possibility of turning the red link at the header of Wikisaurus:beautiful woman (and, by extension, any other pages with a redlink at the header) into a black nonlinked text.

Compare examples of revisions with red link and with black text. There are multiple reasonable ways to attain the effect of the latter, but I have not seen any implemented yet. Then, I suggest this one:


 * Using without parameters at Wikisaurus:woman to link to the entry woman, but using  at Wikisaurus:beautiful woman, with an hyphen as the first unnamed parameter, to display the nonlinked text beautiful woman.

This is akin to how one uses to list the page without linking to the related entry. --Daniel. 08:54, 24 October 2010 (UTC)
 * I support. &#x200b;—msh210℠ (talk) 15:33, 25 October 2010 (UTC)
 * I support having a way to switch off the redlink, but oppose having the format . I support or something of the sort, on the model of nodot=1 found in some templates. --Dan Polansky 18:43, 25 October 2010 (UTC)
 * After reading your opinion, I personally still prefer the option : It is true that multiple templates use <tt>nodot=1</tt>. However, other templates use the dash meaningfully, including the examples, and . If copying the behavior of other templates is a good practice (that I agree in essence), then we should preferably copy other templates of the Wikisaurus suite, whose behavior with a dash can be seen in my last example. --Daniel. 19:05, 25 October 2010 (UTC)
 * I disagreed with designing on the model of  to disable hyperlinks, but Conrad Irwin and you had it your way. I tried to explain why the use of dash is opaque (not transparent), but to no avail. The second parameter of  is a gloss definition--and gloss definition has nothing to do with whether there should be a hyperlink, but overloading of a parameter with multiple meanings is okay with you and Conrad Irwin. Overloading a parameter with multiple meanings is not okay with me. --Dan Polansky 19:56, 25 October 2010 (UTC)
 * I disagree with the statement "gloss definition has nothing to do with whether there should be a hyperlink". There is a relevant relationship: All instances of that do not return a link to an entry also do not display glosses.
 * That said, one way to reasonably cause me to reconsider the format of would be proposing the use of  to simultaneously display a gloss and not link to any entry. --Daniel. 21:46, 25 October 2010 (UTC)
 * Re "All instances of that do not return a link to an entry also do not display glosses": How is that the case in principle? They currently don't, because the design that you and Conrad Irwin (two Wikisaurus non-contributors) have chosen makes it impossible, but it makes sense to provide a gloss for each occurrence of, regardless of whether it has a hyperlink or not. But even if it were true, what you have done to  is still overloading of a parameter with two different meanings, such ones that are merely accidentally related.
 * Anyway, as I said, I disagree with the syntax of that would mean "no hyperlink". --Dan Polansky 05:42, 26 October 2010 (UTC)
 * You could have said this before. In this case, I agree with your proposal of deprecating the format of (though I do not necessarily agree with avoiding "overloading of a parameter" everywhere).
 * To facilitate any future cleaning up, I have programmed to populate Category:Usage of ws with - with pages that use this format to be deprecated.
 * Now to the new proposal: the option <tt>nolink=1</tt> is unfriendly, like <tt>nodot=1</tt>, that is commonly replaced by <tt>dot=</tt>. I will now suggest one similar approach:
 * Using to link to Wikisaurus:woman with a gloss but not link to the entry beautiful woman.
 * Equally implementing <tt>link=no</tt> as the parameter that makes return a black nonlinked text instead of linking to an entry. --Daniel. 06:08, 26 October 2010 (UTC)
 * (unindent) I do not think that "nolink=1" is necessarily unfriendly. I still recall having used "nodot=1". Was there a discussion after which "nodot=" has been changed to "dot="? What templates are using "dot=" and what templates are still using "nodot="? What is the syntax of "dot="? --Dan Polansky 06:50, 26 October 2010 (UTC)
 * There was the short discussion here between me and Conrad, where he informed me about a certain preference of dot over nodot, which resulted in me implementing both of them into my subsequent templates when applicable.
 * Various templates (either created by me or not) accept either or . The syntax of the former is <tt>dot=,</tt> to return a comma, <tt>dot=!</tt> to return an exclamation point and <tt>dot=</tt> to return nothing; by extension, you may add any symbol to that parameter, to return it in the end of the resulting text.
 * Notably, , is a little longer than .
 * Also note that both suggestions ' and ' are based on binary distinctions: effectively, either you add the parameter, or you don't add it. The mental process is arguably the same in both, but the former is closer to human speech, by effectively conveying "no link" instead of "1 is true, so no link".
 * --Daniel. 07:18, 28 October 2010 (UTC)
 * (unindent) Quoting Conrad Irwin from the discussion you have linked to: "There was a move to support cap= and dot= instead of nocap= and nodot=, they are more pleasant for editors, you can see arrangments and rottweillers for how they were (ab)used. Conrad.Irwin 10:20, 31 March 2010 (UTC)". Where was the move to support cap=; where is the community discussion that has lead to switching from nodot= to dot=? Again, what templates are using "dot=" and what templates are still using "nodot="? As an aside, "dot=," is a semantic non-sense; "," is a comma rather than a dot. To answer myself at least in part, still supports "nodot=1". --Dan Polansky 07:53, 28 October 2010 (UTC)
 * There are this and this other discussions with proposals and criticisms for the purpose of using rather than . I don't know any discussion with a formal decision of definitely deprecating ; I simply personally agree with other users that  is shorter and more useful, thus better, and I support the existence of the other parameter too, for conveniency of whoever wants to use it, apparently including you.
 * There is also this related discussion where is simply recommended as a normal parameter to be used for a template.
 * As examples,, and  all support both  and.
 * My mind is trained to recognize the symbol "=" as attribution in context of programming, so I personally can naturally read "<tt>dot=,</tt>" as "I command the dot to turn into a comma". --Daniel. 09:36, 28 October 2010 (UTC)
 * One more question: what other template is using "=no" to refer to the boolean value of "false" or "0"? Put differently, is "=no" your invention, to be pioneered in Wikisaurus templates? --Dan Polansky 07:58, 28 October 2010 (UTC)
 * If I remember correctly, "=no" in Wiktionary is my invention, implemented as the <tt>setwiki=no</tt> of years ago. --Daniel. 09:36, 28 October 2010 (UTC)
 * (unindent) None of the discussions that you have linked to seems to contain a proposal to switch away from "nodot=" to "dot=", asking other people for approval, unless I have overlooked something, which has happened to me a couple of times. So correct me if I am wrong, but this seems to be basically an action of Conrad Irwin and you, without a clear community approval.
 * Now to the format of Wikisaurus template: If you dislike "nolink=1", then I think a better format than "link=no" would be ; when the hyperlink would be empty, this would mean there is no hyperlink. So instead of, the user would write . As a benefit, this provides more function than just the boolean; another benefit: the name "link=" does not in any way indicate that it is boolean, unlike "nolink=". --Dan Polansky 10:03, 28 October 2010 (UTC)
 * I have added a "hyperlink=" parameter to, and to the documentation of the template. --Dan Polansky 07:49, 2 November 2010 (UTC)
 * From one of these discussions, there is the comment "The problem is that 'nocap' and 'nodot' are very poor design, they use a parser conditional instead of parameter defaults, and are (obviously!) backwards." from Robert Ulmann, followed by a suggestion to use, which qualifies as what I called "proposals and criticisms for the purpose of using rather than ".
 * The parameter looks good. I support this recent proposal, with one small change: I have added an alternative shorter parameter  (resulting in, for example). I also support editing  to support . --Daniel. 03:23, 4 November 2010 (UTC)
 * I disagree; there should be no "link=" parameter. Let a parameter "hyperlink=" be added to rather than "link=". If you are too lazy to type a few characters or to copy and paste from models, you are probably also too lazy to do the proper tedious research that Wikisaurus entries require, and should better avoid Wikisaurus anyway. --Dan Polansky 07:45, 4 November 2010 (UTC)
 * Enforcing tediousness or avoiding laziness are not good reasons to choose a parameter. I maintain that is the best choice. --Daniel. 07:55, 4 November 2010 (UTC)
 * Why is "link=" a better choice than "hyperlink="? The term "hyperlink" is less ambigous, and still a short one, with mere 9 characters. The term "hyperlink" is used in the texts of user interface of computer programs; a menu item reads "open hyperlink" rather than "open link". --Dan Polansky 08:07, 4 November 2010 (UTC)
 * Because "link" is shorter, synonymous with "hyperlink" and not ambiguous at all. We have pages named Wiktionary:Links and Help:Internal links, and multiple instances of the word "link" in Entry layout explained and other places. Conceivably, none of them results in confusion with the concept of linking between pages of hypertext.
 * Specifically, clearly handles a link to an entry (on the other hand, it fundamentally can be confused with the link to the policy or to the search, but "hyperlink=" would not fix that, if fixing is necessary). It does not have a parameter referring to "(mathematics) A space comprising one or more disjoint knots.", "(Sussex) a thin wild bank of land splitting two cultivated patches and often linking two hills." or any other definition from the entry link. --Daniel. 08:38, 4 November 2010 (UTC)
 * That a name is shorter is hardly ever a good reason alone to choose the name, as long as both candidates are rather short, which is the case with 9 characters of "hyperlink". As I have said, user interfaces use the term "hyperlink". Generally, "hyperlink" is less ambiguous, although I admit that the context in which is used serves to disambiguate fairly well. --Dan Polansky 09:09, 4 November 2010 (UTC)
 * What the heck? Why are you listing the most improbable definitions of "link"? The major definition is "A connection between places, persons, events, or things"; it is this definition that gives rise to all sorts of specific reuses of the term "link". Smells of sophistry, to me anyway. --Dan Polansky 09:22, 4 November 2010 (UTC)
 * Any "major definition" does not matter, because I have already linked to the entry within my last message and specifically mentioned that "any other definition [does not cause the parameter 'link=' to be ambiguous]". The definition that you have mentioned does not change that fact, since I do not see any implied places, persons, events, or things to cause confusion.
 * The most common lengths of parameter names in Wiktionary are from 0 to 2 characters, rarely reaching 5 characters; "hyperlink=" is very very long, when compared to them. --Daniel. 09:46, 4 November 2010 (UTC)
 * Look, the point of explicitly listing "(mathematics) A space comprising one or more disjoint knots" when there is "A connection between places, persons, events, or things" is a deception or an oversight that is hard to understand. Either you should be listing no definition explicitly, or you should list that definition that is most relevant to the discussion. Instead, you have listed two definitions that are least relevant to the discussion; you should not be doing that. --Dan Polansky 09:59, 4 November 2010 (UTC)
 * I don't think so. Either every definition, or none of the definitions, is relevant, because they equally share the characteristic of not causing confusion within . An alternative analysis is that only "(computing) Shortened form of hyperlink, especially one implemented in HTML." is relevant, because that is the one that I would like to implement as a parameter of that template. However, the part especially one implemented in HTML. is not strictly true, so it's reasonable to avoid quoting it directly and completely, and I have already clearly mentioned this definition, as "the concept of linking between pages of hypertext." --Daniel. 10:21, 4 November 2010 (UTC)
 * (I'm not sure if this is still relevant, but link= is even used in the Mediawiki itself ([ [File:Example.JPG|link=targetpage]]).) --Yair rand (talk) 23:13, 9 November 2010 (UTC)
 * This is relevant, thanks. I have readded to ; I'm going to add that parameter to  later, if no one does that before me. --Daniel. 02:32, 10 November 2010 (UTC)

MediaWiki:Histlegend
Can someone please say [or point me to a web page that explains] what would be the possible purpose of having a page named MediaWiki:Histlegend? --Daniel. 06:50, 28 October 2010 (UTC) Legend: ' = difference with current revision, ' = difference with preceding revision,  = minor edit.
 * The content appears between the "Browse history" box and the "ltest |earliest" links on any history page (of an existing page). Currently it contains:
 * Diff selection: mark the radio boxes of the revisions to compare and hit enter or the button at the bottom.
 * &#x200b;—msh210℠ (talk) 15:01, 28 October 2010 (UTC)
 * I see. Thanks. --Daniel. 20:43, 3 November 2010 (UTC)

Definitions
Hi y'all. I looked through Feedback recently and saw many comments that Wiktionary definitions are not easy enough to find. I would definitely agree with this, having used this site for several years, and have two suggestions–


 * 1) Move the definitions to (or nearer to) the very top of the entry. Most of the other popular online dictionaries that I checked quickly on OneLook have the definitions very close to the top of the page, save for a line (in small text) of the headword, POS and pronunciation. This would probably be pretty hard to implement though, since I would think most users and editors are quite ingrained with the current order as stated in Entry layout explained.


 * 2) Highlight all definitions in a light color (pink, blue, yellow etc.). I don't know the technical details of how or how easy it would be to implement this, but color does certainly draw attention quickly.

Opinions, plz. — lexicógrafo &#124; háblame — 14:17, 28 October 2010 (UTC)
 * Re item 1, cf. my suggestion at [[user:Msh210/ELE]]. &#x200b;—msh210℠ (talk) 14:55, 28 October 2010 (UTC)
 * Cool, thanks. — lexicógrafo &#124; háblame — 16:02, 28 October 2010 (UTC)
 * I always thought the etymology should appear somewhere after the definition. -- Prince Kassad 15:12, 28 October 2010 (UTC)
 * Agreed. It's strange that we give more importance to some historical information than to the current meaning of a term. Longtrend 15:12, 29 October 2010 (UTC)
 * What if we auto-hid the etymological info (and put the show/hide toggle on the same line as the heading)? --Bequw → τ 21:03, 29 October 2010 (UTC)
 * (after e/c) I dunno … I think the space taken up by etymology is really the least of our problems. Imagine that you came across the sentence “some jerk punched a hole in the tire of my car!”, and went to [[punch]] to try and find the relevant sense. This is guaranteed to be difficult in any dictionary, because has a lot of senses, and you have to read all of them to try and see if they fit the sentence; but it's especially hard here, because you first have to scroll past a table of contents that doesn't really tell you anything useful (I mean, unless "Etymology 3" is more meaningful to you than it is to me …), and then you find yourself in a mess of horizontal gray bars, headers of various minimally-distinguishable sizes, seemingly repeated information (the page informs you in several places that "punch" is a noun, but unless you actually read the table of contents — and let's face it, you didn't — you won't understand that each time is grouped under a different etymology), and so on. Even the overall etymological breakdown is confusing, since there are two groups of senses that come from the same Old French etymon, and I'm sure there are sound reasons for them to be distinguished etymologically, but that distinction doesn't benefit any reader except the one who's specifically looking for the etymology. Fortunately, [[punch]] has only one language section; if it had multiple, you could easily end up in some other language without noticing, since the blocks of translation-bars stand out much more than the language headers. When you finally give up on finding information by scanning the page, you then hit Ctrl+F and type "definition" to find where the definitions are, only to discover that we don't actually label our definitions. Fortunately, that particular barrier need be surmounted only once — once you learn that our definitions appear in an ordered list, that's easily remembered for the future — but all the other barriers are always there. I actually never consult Wiktionary for highly polysemous words, because I know from experience that we have the second-worst possible interface for them. (The worst, of course, would be if definitions were behind a show/hide bar. When we reach that point, I'm leaving the project!) —Ruakh <i >TALK</i > 21:36, 29 October 2010 (UTC)
 * Very nice example. Definitely it would be a good thing if the maze of Wiktionary headers was easier to get through (on pages with more than the basic few it is near-impossible), and if the table-of-contents was hidden by default or on the right so that the content wasn't pushed a few pagescrolls down on every reasonably sized page. The French wiktionary is nice with pictures beside the important headers and coloured boxes around the language headers, and the Spanish wiktionary is okay too (it's just English here which is stark and hideous...) Etymology before the definition doesn't bother me too much, as it's used in Merriam-Webster, a source I consult often. But I know how easily a small thing can draw attention. Perhaps the definition-line numbers could be bolded and/or made larger, and everything under a part-of-speech heading put in a box. — lexicógrafa &#124; háblame — 22:03, 29 October 2010 (UTC)
 * I too like the French Wiktionary's icons. NB, however, that when the idea of remodeling the English Wiktionary along French lines was raised in the past, it was pointed out that due to the icons breaking the headers, French Wiktionnaristes can only edit language-sections &mdash; not e.g. part-of-speech sections (as can be edited here). At the time, that argument was persuasive and swayed even me, although I've since started to feel that the usefulness of the icons may outweigh the need to be able to edit individual subsections. — Beobach972 02:52, 5 November 2010 (UTC)
 * One simplification, which could supplement or substitute for what lexicógrafa suggests above about collapsing the tables of contents: list only the most important divisions in the table of contents. For example, in de:man in the German Wiktionary, the TOC lays out only the languages (German, English, etc), parts of speech (e.g. under English, Noun is separated from Verb), and (arguably unnecessarily) translations sections. Contrast that with the English Wiktionary entry for man, which lists Usage Notes, Synonyms, and See Also in the TOC. A user who goes to the German Wiktionary's section for the English noun sense/use of man finds a section listing its Synonyms, Antonyms, Uses, Hypernyms, etc, but those don't clutter the TOC. (For an extreme case, contrast de:iron with en:iron, an entry I provided with every possible semantic relation section.) This shortens the TOC so the reader reaches the actual information more quickly, and it helps the reader if he's using (clicking on) the TOC to get to the definitions, since he will in most cases know the language and even the part-of-speech he's looking for. The German Wiktionary also provides the etymology after the definitions. — Beobach972 02:52, 5 November 2010 (UTC)


 * What if we put the etymology at the bottom, made the pronunciation right-floated and simplified, made the inflection line go on the same line as the pos header, implemented a modified version of tabbedlanguages (I'd prefer a tabs-on-the-left or headers-as-buttons format over the current tabs-on-top), increased the text size of the definitions slightly, made example sentences hideable like quotations, added some styles to the ol to make defs stand out more, and dumped the toc? Voila, problem solved. (While we're at it, we should enable all my javascript tools in PREFS by default and solve the editing difficulties problem too. And senseids. And targetedtranslations.) :) --Yair rand (talk) 21:18, 29 October 2010 (UTC)
 * Good idea (in theory), but would it be easy to implement without thoroughly baffling all the editors here? I know from experience elsewhere how hard it is to overthrow long-established standards... — lexicógrafa &#124; háblame — 21:24, 29 October 2010 (UTC)
 * But as with all things, the best time to start is now. It's only going to get worse. —CodeCat 11:10, 2 November 2010 (UTC)
 * I can't imagine how that could work for words with multiple etymologies and/or multiple pronunciations. --EncycloPetey 03:47, 5 November 2010 (UTC)

Ruakh makes the very good observation above that "the blocks of translation-bars stand out much more than the language headers". Is there a way we could make the language divisions stand out like the translation sections do? The French Wiktionary (v. fr:man) does it &mdash; and (unlike what happens because it put pictures next to the noun-headers) even does it without making it impossible to edit the individual language-sections. — Beobach972 03:03, 5 November 2010 (UTC)


 * Perhaps this would be a good time to mention my javascript which now highlights the definitions in pink.... —Internoob (Disc•Cont) 03:33, 5 November 2010 (UTC)


 * I find that the definitions are easier to spot when there is an example sentence and/or quotation beneath each definition. --EncycloPetey 03:45, 5 November 2010 (UTC)


 * What if the definitions had a (colored perhaps) box around them? — lexicógrafa &#124; háblame — 12:14, 5 November 2010 (UTC)

Citations for Marvel Comics and more
I have added the parameter to the template.

As a result, there are two L2 headers at the page citations:mutant: one for main uses, and other for uses in the context of Marvel Comics. --Daniel. 11:07, 29 October 2010 (UTC)

Template and substitution
Can a template be forced to be a substitution one? Like, I would create a template that would get substituted to  even when I write not "" but rather "". --Dan Polansky 07:42, 30 October 2010 (UTC)
 * I don't think so. But I have seen templates that break if not substituted, so if you could some how make them break in a very obvious way, you have at least a partial solution. —CodeCat 09:06, 30 October 2010 (UTC)
 * (but, re Dan, no it's not possible) Conrad.Irwin 19:54, 30 October 2010 (UTC)

Template:term
If you look at hanjaeo (permanent link), adding sc=Latn isn't working properly; it's allowing italics, but still default to. Does anyone know why? Mglovesfun (talk) 13:52, 31 October 2010 (UTC)
 * Does this problem also happen with other templates, such as or ? If so then the problem might be in . —CodeCat 13:58, 31 October 2010 (UTC)
 * I believe it does. Why don't we try and find out? Mglovesfun (talk) 14:02, 31 October 2010 (UTC)
 * Hmmm. Mglovesfun (talk) 14:08, 31 October 2010 (UTC)
 * The template seems to be behaving as it's intended to; the generated XHTML is <tt> <a href="/wiki/hanjaeo#Korean" title="hanjaeo">hanjaeo</a> </tt>, which is exactly right. The problem is that some browsers, including mine (Firefox) and yours (?), are smart enough to notice the <tt>lang="ko" xml:lang="ko"</tt> and choose a font appropriate for Korean text, even though we're not using CSS to instruct them to do that. —Ruakh <i >TALK</i > 16:43, 31 October 2010 (UTC)
 * (Actually, in this case the real problem might be the existence of Latin-script entries for Korean. We do allow that for some languages, but I don't remember Korean being one of them. —Ruakh <i >TALK</i > 16:47, 31 October 2010 (UTC))
 * Mine is Firefox. I can open IE to have a look. Mglovesfun (talk) 17:08, 31 October 2010 (UTC)
 * Seems like this is a case of Firefox being too smart for its own good. Then again it is a bit of a grey area. Is hanjaeo actually Korean text? It is and it isn't. —CodeCat 18:55, 31 October 2010 (UTC)