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)

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)

I have created the codes for all the once codeless families listed at {{langfamily}}.

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 {{langcatboiler}} 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)

I was wanting a list of all the categories that use {{topic cat parents/default}} and (separately) {{topic cat description/default}}. 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 {{lcfirst: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 {{topic cat parents/foo}} 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)

I quite like the idea, proposed most recent by Vahagn but also before then of {{etyl:el}} displaying Modern Greek, but categorizing in ] . So I've started the template as {{etyl:ell}} 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 {{etyl:el}} to be exactly like what {{etyl:ell}} and {{etyl:el-GR}} currently are. He even raised the possibility of changing {{el}} to be Modern Greek. But to answer your question — you would do something like this:

]

({{etyl|ell}} generates a link with text {{etyl:ell|disp}} and target w:{{etyl:ell|pedia}}, 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#Category:Modern Greek derivations. 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 {{etyl|el}} categorizes into Category:Greek derivations; but that's easy to change, once existing entries are fixed. (Vahagn Petrosyan (talk • contribs) is working on that, and seems to have made a lot of progress in short order. There are now fewer than 400 words with {{etyl|el}} or {{etyl|el|langcode}}, 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)

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 {{en-adj}} 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 {{en-noun}}. 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 {{apdx-en-noun}} (or, jokingly, in another discussion, {{en-nounjustforappendices}}) 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 {{en-noun}}. 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)

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/[email protected]/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)

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: {{m|n|p}} -> m pl or n pl —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 {{form of}}: neuter plural of xyz. 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)

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:

 ...{{tø|cmn|夜店|tr=yèdiàn|sc=Hans}} 

zh would work as this:

 ...{{t|zh|夜店|tr=yèdiàn|sc=Hans}} 

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)

{{look}}

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)

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 mw:Hit stats aggregation and mw:Extension:CentralNotice/Phase 2 . --InfantGorilla 09:58, 16 October 2010 (UTC)

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)

{{look}}

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 {{eo-proper noun|j}} to {{eo-proper noun|pl=1}}. This is because multi-word proper nouns can use something like {{eo-proper noun|Rusia|Federacio}} in which case, even if it's countable, {{{1}}} can't be j and Rusia at the same time. Mglovesfun (talk) 16:22, 15 October 2010 (UTC)

One of the functions of {{langcatboiler}} is pointing to the Wiktionary edition of a particular language.

• For instance, at Category:Spanish language, there is the text "Spanish language edition of Wiktionary http://es.wiktionary.orghttps://dictious.com/en/".

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.

• 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.orghttps://dictious.com/en/" at Category:Pennsylvania German language.

I hereby propose:

1. Deprecating the parameter {{{setwikt}}} (and other parameter, {{{nowikt}}}) of {{langcatboiler}}, thus sparing the burden of editing the link for every category.
2. Using {{wikimedia language}}, with all the Wiktionary versions listed, to feed {{langcatboiler}} with the correct values whenever necessary.

--Daniel. 17:32, 16 October 2010 (UTC)

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 {{wikimedia language}} 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, {{wikimedia language|vro}} produces fiu-vro even though there's no Võro Wiktionary.) Instead, we should create a new, separate template that "knows" which Wiktionaries exist. (Also, {{wikimedia language}} 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_TALK 16:41, 17 October 2010 (UTC)

This project is done. The parameters {{{setwikt}}} and {{{nowikt}}} are now meaningless for {{langcatboiler}}. 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 {{wiktionary edition}}. --Daniel. 08:12, 21 October 2010 (UTC)

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

{{param|1}} returns {{{1}}}.

Or, {{param|abc}} returns {{{abc}}}.

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 {{{1}}} in any other place just fine. —CodeCat 10:45, 18 October 2010 (UTC)

Oh but I like how {{param}} and {{temp}} format the resulting texts.

To point to a template called "abc", you can type Template:abc, abc, {{abc}} or even {{abc}}, but the best cosmetic choice to me is {{abc}}. --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 "{{param|abc}}" into "{{p|abc}}". (or any other name, since {{p}} is taken and I like {{param}} anyway)

However, I guess my math is different from yours, Martin:

<tt>{{{abc}}}</tt> totalizes 18 keystrokes.

{{param|abc}} totalizes 13 keystrokes.

--Daniel. 17:22, 18 October 2010 (UTC)

(edit conflict) Technically, <tt>{{{1}}}</tt> is five characters longer than {{param|1}}. Even so, this doesn't sound particularly useful. --Yair rand (talk) 17:25, 18 October 2010 (UTC)

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

• 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 button that points to certain individual templates like Template:shortcatboiler/initialism, which controls all the initialisms. So, that 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 |description={{languagex|{{{lang}}}}} groups of words represented by their beginning parts pronounced separately. may be edited to change the description. --Daniel. 15:12, 18 October 2010 (UTC)

What about naming these boilers like {{rhyme-cat-boiler}} and {{short-cat-boiler}}, on the model of {{en-noun}}? My eyes are not particularly accustomed to looking for implied compoundworddivisionindications. Another option is to use spaces, on the model of {{en-proper noun}} and {{ws sense}}, so it would be {{rhyme cat boiler}} and {{short cat boiler}}. 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 {{topic cat}}. I think it would be good if all other boilerplate templates were named just like that one, i.e. {{rhyme cat}}, {{lang cat}}, {{pos cat}} and so on. It would also be nice if the parameters of {{topic cat}} 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 {{rhyme category boilerplate}}. 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 {{rhymecatboiler}} 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 {{part of speech category boilerplate}} and {{language category boilerplate}} in this case.

In addition, please note that {{poscatboiler}} 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 rhymecatboiler. --Yair rand (talk) 21:10, 18 October 2010 (UTC)

Why do you prefer names like rhymecatboiler? What is the benefit of such hard-to-decipher names? --Dan Polansky 21:27, 18 October 2010 (UTC)

Ease of typing it out. shortcat and rhymecat would be even better, IMO. --Yair rand (talk) 21:35, 18 October 2010 (UTC)

I don't find rhymecatboiler 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 "{{poscatboiler|es|adjective}}", I too prefer short but understandable versions such as rhymecatboiler (or even rhymecat, 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 {{infl}}, {{l}}, {{t+}}, {{en-noun}} and even the parser function {{#ifexist}}; wikisyntax such as ===Header 3=== also share the characteristic of being more clear to one who already knows what it means. By the way, {{short category boilerplate}} 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 {{the boilerplate for abbreviations, acronyms and initialisms supposed to be copied to categories named as a language followed by the pluralized version of the item, and functions between double curly brackets, blah blah blah}}. --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; {{pos cat boiler}} would already be an improvement. Further, {{part-of-speech category boilerplate}} 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 {{part-of-speech category boilerplate}}. —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)

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_TALK 17:30, 18 October 2010 (UTC)

You may as well recognize "What categories still do not have boilers?" as "What categories still do not have ?" 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.​—msh210℠ (talk) 20:00, 18 October 2010 (UTC)

Ditto. —Ruakh_TALK 20:04, 18 October 2010 (UTC)

The first issue can, I think, be solved by 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)

 Done. But if someone were to RFV it, I'm not absolutely positive that it would pass! —Ruakh_TALK 20:38, 18 October 2010 (UTC)

All subcats of Category:Contractions by language. --Yair rand (talk) 11:27, 6 December 2010 (UTC)

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_TALK 23:57, 18 October 2010 (UTC)

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 |, ||, {|, |} and |- 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: <table>, <tr>, <th>, <td>. I think they're much easier to read in that case. What do other people think? —Ruakh_TALK 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_TALK 17:31, 19 October 2010 (UTC)

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)

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

]

becomes

{{subst:#ifexist: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. w: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) — 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, have special meaning in AWB regexes, and must be quoted. So, in Mglovesfun's example, he would want to replace \\] with {{subst:#ifexist:$1||]}}. (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_TALK 12:39, 21 October 2010 (UTC)

I'm aware of that. And you know it ;o). Mglovesfun (talk) 17:46, 21 October 2010 (UTC)

Moved to Template talk:fr-noun#fr-noun templates

This is another recent major change: {{suffixsee}} and {{prefixsee}} 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 -ութիւն (-utʻiwn). --Vahag 17:38, 29 October 2010 (UTC)

I have two suggestions very similar to the recently finished project WT:GP#The nonexistent Pennsylvania German edition of Wiktionary:

• 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 {{{setwiki}}} and {{{setsister}}} (and {{{nowiki}}}, and {{{nosister}}}) from {{langcatboiler}} would be deprecated. --Daniel. 14:43, 22 October 2010 (UTC)

See smoker's cough, it's displaying a plural in bold, but not linking to it. I used {{new en plural}} 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 {{en-noun/sandbox}}, 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 {{makelink}}, which sometimes erm, doesn't. Mglovesfun (talk) 21:20, 23 October 2010 (UTC)

Yes, I've created {{en-noun/sandbox}} and I'm regularly editing User:Daniel./Sandbox and qwertyqwerty to make relevant tests. I probably could not have predicted that {{#ifeq:]|{{raw:Special:Whatlinkshere/smoker's cough}}|TRUE|FALSE}} returns TRUE but {{#ifeq:]|{{raw:Special:Whatlinkshere/{{PAGENAME}}}}|TRUE|FALSE}} 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 {{PAGENAME}} at ] evaluates to smoker&#39;s cough, which remains intact when it's in a simple link, but which gets converted back to smoker's cough 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_TALK 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. Daniel. (talk • contribs)'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 Daniel. (talk • contribs)'s recent contributions, but occasionally it's actually someone else who broke something, and occasionally Daniel. (talk • contribs) has made too many recent changes for such examination to be feasible. He never uses edit summaries, so there's really no guessing.) —Ruakh_TALK 03:17, 24 October 2010 (UTC)

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?​—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)

According to common practice, Wikisaurus pages are supposed to contain a rectangular header from the template {{ws header}}, 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 {{ws header}} without parameters at Wikisaurus:woman to link to the entry woman, but using {{ws header|-}} 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 {{ws|beautiful woman|-}} to list the page without linking to the related entry. --Daniel. 08:54, 24 October 2010 (UTC)

I support.​—msh210℠ (talk) 15:33, 25 October 2010 (UTC)

I support having a way to switch off the redlink, but oppose having the format {{ws header|-}}. I support {{ws header|nolink=1}} 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 {{ws link|-}}: It is true that multiple templates use nodot=1. However, other templates use the dash meaningfully, including the examples {{en-noun|-}}, {{en-adj|-}} and {{ws|beautiful woman|-}}. 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 {{ws}} on the model of {{ws|beautiful woman|-}} 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 {{ws}} 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 {{ws}} 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 {{ws|beautiful woman|-}} would be proposing the use of {{ws}} to simultaneously display a gloss and not link to any entry. --Daniel. 21:46, 25 October 2010 (UTC)

Re "All instances of {{ws}} 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 {{ws}}, regardless of whether it has a hyperlink or not. But even if it were true, what you have done to {{ws}} 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 {{ws header|-}} 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 {{ws|beautiful woman|-}} (though I do not necessarily agree with avoiding "overloading of a parameter" everywhere).

To facilitate any future cleaning up, I have programmed {{ws}} to populate Category:Usage of ws with - with pages that use this format to be deprecated.

Now to the new proposal: the option nolink=1 is unfriendly, like nodot=1, that is commonly replaced by dot=. I will now suggest one similar approach:

• Using {{ws|beautiful woman|a woman who is beautiful|link=no}} to link to Wikisaurus:woman with a gloss but not link to the entry beautiful woman.
• Equally implementing link=no as the parameter that makes {{ws header}} 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 {{{dot}}} or {{{nodot}}}. The syntax of the former is dot=, to return a comma, dot=! to return an exclamation point and dot= to return nothing; by extension, you may add any symbol to that parameter, to return it in the end of the resulting text.

• Notably, {{alternative spelling of|abcdefg|nodot=1}}, is a little longer than {{alternative spelling of|abcdefg|dot=,}}.
• Also note that both suggestions {{ws|beautiful woman|a woman who is beautiful|link=no}} and {{ws|beautiful woman|a woman who is beautiful|nolink=1}} 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, {{alternative spelling of}} 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 {{{dot}}} rather than {{{nodot}}}. I don't know any discussion with a formal decision of definitely deprecating {{{nodot}}}; I simply personally agree with other users that {{{dot}}} 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 {{{dot}}} is simply recommended as a normal parameter to be used for a template.

As examples, {{alternative spelling of}}, {{obsolete form of}} and {{initialism of}} all support both {{{dot}}} and {{{nodot}}}.

My mind is trained to recognize the symbol "=" as attribution in context of programming, so I personally can naturally read "dot=," 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 setwiki=no of {{langcatboiler}} 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 {{ws|term|gloss definition|hyperlink=target term of the hyperlink}}; when the hyperlink would be empty, this would mean there is no hyperlink. So instead of {{ws|term|gloss definition|hyperlink=no}}, the user would write {{ws|term|gloss definition|hyperlink=}}. 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 {{ws header}}, 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 {{{dot}}}, which qualifies as what I called "proposals and criticisms for the purpose of using {{{dot}}} rather than {{{nodot}}}".

The parameter {{{hyperlink}}} looks good. I support this recent proposal, with one small change: I have added an alternative shorter parameter {{{link}}} (resulting in {{ws header|link=}}, for example). I also support editing {{ws}} to support {{ws|beautiful woman|a woman who is beautiful|link=}}. --Daniel. 03:23, 4 November 2010 (UTC)

I disagree; there should be no "link=" parameter. Let a parameter "hyperlink=" be added to {{ws}} 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 {{{link}}} 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 Wiktionary:Entry layout explained and other places. Conceivably, none of them results in confusion with the concept of linking between pages of hypertext.

Specifically, {{ws header|link=}} 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 {{ws header}} 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 ". 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 {{ws header}}. 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 (]).) --Yair rand (talk) 23:13, 9 November 2010 (UTC)

This is relevant, thanks. I have readded {{{link}}} to {{ws header}}; I'm going to add that parameter to {{ws}} later, if no one does that before me. --Daniel. 02:32, 10 November 2010 (UTC)

Can someone please say what would be the possible purpose of having a page named MediaWiki:Histlegend? --Daniel. 06:50, 28 October 2010 (UTC)

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.
Legend: (cur) = difference with current revision, (prev) = difference with preceding revision, m = minor edit.

​—msh210℠ (talk) 15:01, 28 October 2010 (UTC)

I see. Thanks. --Daniel. 20:43, 3 November 2010 (UTC)

Hi y'all. I looked through Wiktionary: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 Wiktionary: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 | háblame — 14:17, 28 October 2010 (UTC)

Re item 1, cf. my suggestion at ].​—msh210℠ (talk) 14:55, 28 October 2010 (UTC)

Cool, thanks. — lexicógrafo | 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 ] to try and find the relevant sense. This is guaranteed to be difficult in any dictionary, because punch 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, ] 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_TALK 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 | 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 — 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 | 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 — 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 | háblame — 12:14, 5 November 2010 (UTC)

I have added the parameter {{{ct}}} to the template {{citation}}.

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)

Can a template be forced to be a substitution one? Like, I would create a template {{OHG.}} that would get substituted to {{etyl|goh}} even when I write not "{{subst:OHG.}}" but rather "{{OHG.}}". --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)

{{safesubst:#if:{{subst:NS:0}} | <big class="error">You MUST substitute this template: {{template|subst=t|template}}</big> | <!-- do useful stuff --> }} (but, re Dan, no it's not possible) Conrad.Irwin 19:54, 30 October 2010 (UTC)

If you look at hanjaeo (permanent link), adding sc=Latn isn't working properly; it's allowing italics, but still default to {{Kore}}. Does anyone know why? Mglovesfun (talk) 13:52, 31 October 2010 (UTC)

Does this problem also happen with other templates, such as {{infl}} or {{l}}? If so then the problem might be in {{Xyzy}}. —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 <span class="Latn mention-Latn" xml:lang="ko" lang="ko"><a href="https://dictious.com/en/hanjaeo#Korean" title="hanjaeo">hanjaeo</a></span>, which is exactly right. The problem is that some browsers, including mine (Firefox) and yours (?), are smart enough to notice the lang="ko" xml:lang="ko" and choose a font appropriate for Korean text, even though we're not using CSS to instruct them to do that. —Ruakh_TALK 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_TALK 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)