Wiktionary:Requests for deletion/Others: difference between revisions

From Wiktionary, the free dictionary
Jump to navigation Jump to search
Browse history interactively
← Go to previous editGo to next edit →
Content deleted Content added
VisualWikitext
Line 140: Line 140:
There are {{temp|in the plural}} and {{temp|plural only}}.&nbsp;<span class="user-mzajac">''—[[User:Mzajac |Michael]]&nbsp;[[User talk:Mzajac |Z.]]&nbsp;<small>2013-06-21&nbsp;19:09&nbsp;z</small>''</span>
There are {{temp|in the plural}} and {{temp|plural only}}.&nbsp;<span class="user-mzajac">''—[[User:Mzajac |Michael]]&nbsp;[[User talk:Mzajac |Z.]]&nbsp;<small>2013-06-21&nbsp;19:09&nbsp;z</small>''</span>


== [[:Category:Turkish third-person singular forms]] ==
== <s>[[:Category:Turkish third-person singular forms]]</s> ==


===[[:Category:Turkish third-person negative singular forms]]===
===[[:Category:Turkish third-person negative singular forms]]===
Line 149: Line 149:


: '''Empty and delete all per nom'''. —[[User: Ruakh |Ruakh]]<sub ><small ><i >[[User talk: Ruakh |TALK]]</i ></small ></sub > 07:51, 12 September 2013 (UTC)
: '''Empty and delete all per nom'''. —[[User: Ruakh |Ruakh]]<sub ><small ><i >[[User talk: Ruakh |TALK]]</i ></small ></sub > 07:51, 12 September 2013 (UTC)

* '''Deleted''' --[[User:Back on the list|Back on the list]] ([[User talk:Back on the list|talk]]) 14:42, 3 February 2014 (UTC)


== [[:Template:defn#rfd-notice--|Template:defn]] ==
== [[:Template:defn#rfd-notice--|Template:defn]] ==

Revision as of 14:42, 3 February 2014

Wiktionary > Requests > Requests for deletion/Others

Wiktionary Request pages (edit) see also: discussions
Requests for cleanup
add new | history | archives

Cleanup requests, questions and discussions.

Requests for verification/English
add new English request | history | archives

Requests for verification in the form of durably-archived attestations conveying the meaning of the term in question.

Requests for verification/CJK
add new CJK request | history

Requests for verification of entries in Chinese, Japanese, Korean or any other language using an East Asian script.

Requests for verification/Italic
add new Italic request | history

Requests for verification of Italic-language entries.

Requests for verification/Non-English
add new non-English request | history | archives

Requests for verification of any other non-English entries.

Requests for deletion/Others
add new | history

Requests for deletion and undeletion of pages in other (not the main) namespaces, such as categories, appendices and templates.

Requests for moves, mergers and splits
add new | history | archives

Moves, mergers and splits; requests listings, questions and discussions.

Requests for deletion/English
add new English request | history | archives

Requests for deletion of pages in the main namespace due to policy violations; also for undeletion requests.

Requests for deletion/CJK
add new CJK request | history

Requests for deletion and undeletion of entries in Chinese, Japanese, Korean or any other language using an East Asian script.

Requests for deletion/Italic
add new Italic request | history

Requests for deletion and undeletion of Italic-language entries.

Requests for deletion/Non-English
add new non-English request | history | archives

Requests for deletion and undeletion of any other non-English entries.

Requests for deletion/​Reconstruction
add new reconstruction request | history

Requests for deletion and undeletion of reconstructed entries.

{{attention}} • {{rfap}} • {{rfdate}} • {{rfquote}} • {{rfdef}} • {{rfeq}} • {{rfe}} • {{rfex}} • {{rfi}} • {{rfp}}

All Wiktionary: namespace discussions 1 2 3 4 5 - All discussion pages 1 2 3 4 5
Shortcut:
WT:RFDO
This page is for the nomination (for deletion) of non-main namespace entries. General questions about categories, templates and the like should be posted at Wiktionary:Grease pit. Remember to start each section with only the wikified title of the page being nominated for deletion.
Oldest tagged RFDOs

July 2012

A Bunch of Turkish Inflected-Form Categories

Latest comment: 10 years ago27 comments13 people in discussion

I noticed these in the Special:UncategorizedCategories page, and was going to add the appropriate categories and move the misspelled ones, but then I noticed who created many - if not all- of these, and thought I should check whether this kind of categorization is appropriate. If the consensus is that they're ok, I'll happily withdraw the nominations and fix the problems. Chuck Entz (talk) 02:43, 21 July 2012 (UTC)Reply

We don't do this in any language I'm familiar with, except Latvian and Icelandic, and I'm pretty sure we stopped doing it there. Delete --Μετάknowledgediscuss/deeds 02:49, 21 July 2012 (UTC)Reply
I templatised Category:Turkish terms with homophones. — Ungoliant (Falai) 03:19, 21 July 2012 (UTC)Reply
These categories are very specific, but languages are all unique so they have to be judged as such. I think asking User:Sinek would be a good idea. User:George Animal is also listed as a native Turkish speaker, I think the other users Category:User tr-N aren't currently active. Mglovesfun (talk) 14:22, 21 July 2012 (UTC)Reply
I just realized: these seem to each have their own template that produces them, and the templates aren't language specific- one could just as easily find Category:French possesive singular forms someday. Chuck Entz (talk) 14:41, 21 July 2012 (UTC)Reply
Not all of them do, but the more specific ones seem to. Chuck Entz (talk) 14:54, 21 July 2012 (UTC)Reply
Now that I know what was populating them, I've orphaned and speedied the misspelled ones. Chuck Entz (talk) 16:21, 21 July 2012 (UTC)Reply
I think that a general useful template form for all languages is difficult - if not impossible -, but I propose to follow the way it is done in Hungarian, as this Finno-Ugric language is somehow similar to the Altaic Turkish. In Hungarian, words are formed also agglutinively, and I know that a word can have several cases at the same time. Sae1962 (talk) 07:43, 22 July 2012 (UTC)Reply
I think all that categories (the most of them; like:Turkish third-person singular possesive dative forms) are redundant because that templates exist not even at the Turkish Wiktionary.It is nonsense to create the pages (e.g.:my auto, my page, my father, of the father). It would be enough if the templates exist.They don't have to be created.The creation of the entries like (arabam:my auto) are also redundant because all that things are the same.Arabam (my auto), evim (my house) etc. It is better to create a page for the grammar part for the possessive nouns of the Turkish language.I'm in favour of this idea.GeorgeAnimal. 13:04, 22 July 2012 (UTC)Reply
PS:I am for the deletion of the pages.--GeorgeAnimal. 13:05, 22 July 2012 (UTC).But the templates shall remain in the entries.---GeorgeAnimal. 13:07, 22 July 2012 (UTC)Reply
These Turkish inflection forms can be all generated from simple grammar rules. Including them in the Wiktionary is totally useless. They don't even have exceptions like in English you have dog ->dogs but mouse->mice. Because Turkish is an agglutinative language, if you started including all possible Turkish constructs you would have no rational way to reject something like Çekoslovakyalılaştıramadıklarımızdanmışsınız which means "reportedly you are you one of those whom we could not make Czechoslovakian". Terms with definitions that are Sum-of-Parts are not included in the Wiktionary and with a similar reasoning, I believe grammatical constructs in agglutinative languages that follow simple rules should not be included either. For this reason the categories listed above and the words contained within them should be deleted. Same argument applies for the templates mentioned below. --İnfoCan (talk) 16:58, 22 July 2012 (UTC)Reply
Off-topic comments about whether there should be entries for all possible word-suffix combinations
Actually we do have a way of rejecting something like Çekoslovakyalılaştıramadıklarımızdanmışsınız, namely the requirement that words actually be attested in use (and not merely as mentions). I don't think Turkish is considered one of the limited-documentation languages, so Çekoslovakyalılaştıramadıklarımızdanmışsınız would have to be attested three times in published literature to be included. If not, it isn't included. If it is attested, however, there is actually no reason we shouldn't include it. —Angr 20:38, 22 July 2012 (UTC)Reply
OK, the country of Czechoslovakia does not exist any more, and the above is just an old joke that elementary school kids tell each other. But seriously, if you want attestation, no problem: Avrupalılaşmamıza is a down-to-earth example, it translates as "to our Europeanization" (as in "Islam is shown as an obstacle to our Europeanization", as used in a newspaper editorial). Google search gives me three independent attestations from newspapers [1]. Or, yapamamamızın ("of our inability to do"), 7 attestations just in Google Books [2]. So, is Wiktionary going to include such words now? If so, then probably 90% of the words in Wiktionary can potentially belong to Turkish or some other agglutinative language. This is ridiculous and calls for a proper definition of what a "word" is, to set an inclusion policy. I believe that the attestation part should come in only after you have "peeled off" all the generic inflections. --İnfoCan (talk) 03:07, 23 July 2012 (UTC)Reply
Why shouldn't Wiktionary include such words? We're not paper, we're not going to run out of space. On the contrary, the ability to include such things is one of our major selling points, what sets us apart from conventional dictionaries. I see no harm at all in including such forms, and they may be very helpful for people learning Turkish who haven't yet quite mastered all of the suffixes and so don't know exactly what to shave off to get to the lemma. —Angr 21:53, 23 July 2012 (UTC)Reply
Your argument is equivalent to saying that the Wiktionary should have translations of every four-word English phrase to Turkish. I could say there is no space limitation, and it will certainly be useful to Turkish speakers who don't know English. Yes it is doable but it is not efficient. WikiMedia is great for writing an encyclopedia and perhaps a traditional dictionary, but I don't think it is the right tool for doing what you propose. Rather than entering a translation of everything, you need a rule-based parsing system. I know such Turkish language parsers exist, I have seen them at academic Web sites in Turkey. It would be far less work to write software that parses Turkish than write all these translations! --İnfoCan (talk) 22:23, 23 July 2012 (UTC)Reply
It's not quite equivalent, because Wiktionary's goal is "all words in all languages", and yapamamamızın is a word, while a four-word English phrase isn't a word. Now if we had a parsing system like you're talking about, where someone could type in yapamamamızın and be given the information about its root and affixes, then I'd agree we wouldn't need it as an entry as well. But until we have such a parsing system here, if someone creates an entry for yapamamamızın, and someone else nominates it for deletion, I will vote keep. —Angr 22:36, 23 July 2012 (UTC)Reply
Someone may create an entry for yapamamamızın but will soon tire of creating such entries. This discussion reminds me of the joke about the person with the hammer seeing everything like a nail ;-). You have to admit that current WikiMedia software is not designed to deal with this kind of data. That's why the Foundation has started to move toward new concepts like WikiData [3].
To think that a word is a bunch of characters with a space character on either side is an English- (or rather, a non-agglutinative language) speaker's world view :-). For yapamamamızın and "of our inability to do", the important parts are yap and "do" and the rest is grammatical detail. English uses spaces to separate most morphemes, Turkish relies a lot more on grammar rules. If four words separated by spaces don't deserve to have an entry in the dictionary, nor does a lemma with three suffixes. --İnfoCan (talk) 02:11, 24 July 2012 (UTC)Reply
Let me elaborate. The grammatical rules I mentioned can be summarized in a few paragraphs on a special page in the Appendix: names space and this would be far more efficient than having a template for each inflection form of each Turkish word. On the other hand, it did occur to me that there are a few exceptions to these rules, mainly because of exceptions to the Turkish vowel harmony rules (for certain words of foreign origin (for example the dative case of sol, the musical note, is sole, but the dative case of sol, meaning "left", is sola). For such exceptions, and only for them, a specialized template would be useful to indicate that the usual rules do not apply. This minor point aside, I still stand by my view above. --İnfoCan (talk) 18:26, 22 July 2012 (UTC)Reply
Per İnfoCan--Sabri76'talk 17:45, 22 July 2012 (UTC)Reply
Actually I find it unnecessary to create articles every declined noun form and conjugated verb form, as it'd mean countless forms. Being quite different than English, there are so many possible situations that are expressed by a suffix in Turkish. But I also think of the users that have no knowledge of Turkish. We also have to take into account that, even someone without a basic knowledge should be able to find the definitions they needed. So if someone sees a word like evimizdeyiz ("we are at our house") and tries to look it up, they'll probably find nothing, as it has 3 different suffixes. And searching words like this is useless, as Did you mean ...? part can't always lead you to the right direction, as the forms on the declension templates are not shown on the searches.
Rather than creating each form, I guess we could edit the templates in order to give links to each suffix, something like that: evimizdeyiz. I guess this is more practical, as there are so many (and I mean it.) suffixes and there'd be millions of different combinations with all Turkish nouns. But I still have no idea about the search part, is there way to make it possible to show the info on the declension templates? Sinek (talk) 12:43, 23 July 2012 (UTC)Reply
More off-topic comments about whether there should be entries for all possible word-suffix combinations
Creating millions of pages for all possible combinations of Turkish words with their single, double and triple suffix combinations is very inefficient. It is like creating separate pages for every possible two-, three- and four-word phrases in English. If somebody needs to look up a word like evimizdeyiz ("we are at our house"), you need a parsing-based solution, not a catalog-based solution that WikiMedia provides. It is possible to write scripts that take a word like evimizdeyiz and split it into ev (house) + -imiz (possesive, 1PP) + -de (locative case) + y (vowel-vowel connector) + -iz (copula, 1PP). The output of such a script can then give the necessary links to a such a user. --İnfoCan (talk) 17:53, 23 July 2012 (UTC)Reply
That's exactly what I said. I just don't know how to link the user (who searches evimizdeyiz) to the bare noun, ev. Sinek (talk) 18:32, 23 July 2012 (UTC)Reply
Any chance of moving all the off-topic stuff to the Beer Parlor? The deletion debates has got lost among it. Mglovesfun (talk) 09:16, 24 July 2012 (UTC)Reply
Sorry. I collapsed my comments above. --İnfoCan (talk) 14:15, 24 July 2012 (UTC)Reply

I would favour deleting these in favour of an approach like that used in Hungarian noun form categorisation. To elaborate, categorise possessive noun forms in one possessive noun form subcategory, then perhaps for any further inflected forms based off a form that is possessive (should we include them) categorise them as basic noun forms; for example, evimizde could be included as "locative singular(?) of evimiz". I don't know how accepting of this people would be but I think it would be kind of ok to give some like a free pass to the basic inflections, except perhaps in the case of odd or rare words, so that we would generally have no qualms about the addition of the simple case forms and probably nominative possessive forms too but would maybe be more strict or watchful of additions of not so basic forms like non-nominative possessives and such. User: PalkiaX50 talk to meh 14:43, 24 July 2012 (UTC)Reply

April 2013

Template:hu-compound

Latest comment: 10 years ago8 comments7 people in discussion

Template:hu-prefix

Template:hu-suffix

From the code, I don't see any advantage in using these templates instead of the general {{compound}}, {{prefix}} and {{suffix}}. They do the same thing, with only the difference that they are coded specifically for Hungarian. —CodeCat 17:47, 23 April 2013 (UTC)Reply

Delete all three. — Ungoliant (Falai) 20:30, 23 April 2013 (UTC)Reply

The {{hu-prefix}} and {{hu-suffix}} templates are used in the etymology section, not in the headword section. Please do not delete them. It is unfortunate that hu-compound was deleted without consulting any Hungarian editor. There was a reason it was created. The Hungarian language has lots of compound words and they have different grammatical types. The template was eventually supposed to show the type of the compound word. This is no longer possible. --Panda10 (talk) 12:55, 29 November 2013 (UTC)Reply

How is that unique to Hungarian? English compounds have different grammatical types (noun, verb, adverb, adjective, etc.) Mglovesfun (talk) 13:08, 29 November 2013 (UTC)Reply
What I meant was the classification of the compound structure, not its PoS. "A compound can be subordinative: the prefix is in logical connection with the suffix. If the prefix is the subject of the suffix, the compound is generally classified as a subjective one. There are objective, determinative, and adjunctive compounds as well." Wikipedia: Hungarian language - Compounds. --Panda10 (talk) 13:17, 29 November 2013 (UTC)Reply
re "the template was eventually supposed to show the type of the compound word": in fairness, it existed for four and a half years without anyone adding that functionality, or even mentioning on the talk or documentation pages that adding it was a goal. But if and when such a functionality is added, the format of the templates is (as noted above) otherwise identical, so it's simple enough to bot-switch {{compound|foo|bar|lang=hu}} back to {{hu-compound|foo|bar}}. - -sche (discuss) 08:18, 30 November 2013 (UTC)Reply

May 2013

Template:de-form-adj

Latest comment: 10 years ago8 comments6 people in discussion

German adjectives have inflected forms that can be used in a bunch of ways, but displaying them on separate lines is just plain stupid. For example, at the adjective section of rechten, there are 26 definition lines using this template. Instead, we should switch over all German entries to use the format we already use for closely related languages like Yiddish, and which SemperBlotto already uses for German, which can be seen at a page like einzigen. —Μετάknowledgediscuss/deeds 05:42, 9 May 2013 (UTC)Reply

We've had this discussion before and I still agree: Template:l/de is the right way to do this; the current version of Template:l/de is the wrong way. The inflection tables at Template:l/de and Template:l/de are sufficient to show which forms exactly end in -en. Beyond seven lines or so it's an information overload and becomes unusable for the reader. —Angr 09:44, 9 May 2013 (UTC)Reply
I note that de.Wikt does spell out all of the forms each string constitutes (see e.g. de:einzigen). I have no strong opinion on whether en.Wikt should or not. What Angr suggests is the easiest thing to do. - -sche (discuss) 18:40, 16 May 2013 (UTC)Reply
Oppose. How is having a list with 26 definitions worse than forcing users to look for the word in a table? As I’ve suggested before, if the clutter is too troublesome, it’s better to merge definitions (e.g. “weak masculine singular genitive, dative and accusative form of recht.”) — Ungoliant (Falai) 18:59, 16 May 2013 (UTC)Reply
I'm fine with a merger like that, but it would still amount to the complete reconstruction of this template and editing of all of its uses (about the same as deleting it). Angr, what do you think about that suggestion? —Μετάknowledgediscuss/deeds 00:22, 17 May 2013 (UTC)Reply
Maybe something along the lines of {{got-nom form of}} would work? It has special parameters that allow you to combine cases and such. Aside from that it can be used for all nominal parts of speech, not just adjectives. —CodeCat 00:56, 17 May 2013 (UTC)Reply
I don't mind merging some of the senses if we can get it down to a maximum of seven lines. More than that and the reader's eyes will start to glaze over. One thing I think we can always eliminate is the "mixed" forms since these are always identical to either the strong form or the weak form. —Angr 14:05, 17 May 2013 (UTC)Reply
Oppose. I could live with a template though that hides all the definitions until you click on "Show all grammatical contexts" or something along those lines. Longtrend (talk) 09:24, 19 January 2014 (UTC)Reply

June 2013

Template:plural

Latest comment: 11 years ago5 comments2 people in discussion

Template:singular

I've never understood why these exist, they contain precisely ''plural'' and ''singular'', so they save precisely zero keystrokes, with no added functionality. Most of the transclusions are via inflection templates (like for Latin) where they can be simply subst:ed with no drawbacks. Mglovesfun (talk) 20:12, 7 June 2013 (UTC)Reply

I agree, delete them. But they also have some transclusions through {{context}}, and we can't get rid of those currently. —CodeCat 20:22, 7 June 2013 (UTC)Reply
Could change them to {{context|in the plural}} though. Mglovesfun (talk) 20:27, 7 June 2013 (UTC)Reply
MewBot is currently occupied, so could you do that? —CodeCat 20:30, 7 June 2013 (UTC)Reply
Done, though there are some legitimate uses of singular and plural in context labels that remain, but aren't harmful. Mglovesfun (talk) 09:28, 10 June 2013 (UTC)Reply

There are {{in the plural}} and {{plural only}}. —Michael Z. 2013-06-21 19:09 z

Category:Turkish third-person singular forms

Latest comment: 10 years ago3 comments3 people in discussion

Category:Turkish third-person negative singular forms

Category:Turkish negative imperative forms

Category:Turkish verb plural forms

Category:Turkish verb third-person forms

It seems to me that whoever created these categories was a bit too enthusiastic about copying the examples of other languages. Some of these categories may make sense for English, but not for Turkish (note that there are no categories for any other specific Turkish verb forms, just these five). If we really wanted to be consistent and create categories for every individual form, we'd end up with over a hundred of them. Note also (deprecated template usage) demek, which lists the 3rd person singular, apparently mirroring English entries but without any apparent significance for Turkish itself. Is it a principal part of Turkish verbs? If not, then why list it there? —CodeCat 16:24, 3 July 2013 (UTC)Reply

Empty and delete all per nom. —RuakhTALK 07:51, 12 September 2013 (UTC)Reply

Template:defn

Latest comment: 10 years ago6 comments5 people in discussion

I'm not sure why we have one template that shows a notice ({{rfdef}}) and one that doesn't. I think it's much more preferable to always show a notice. Compare rfdef with defn. —CodeCat 17:52, 3 July 2013 (UTC)Reply

One good reason might be to keep the various request categories from being cluttered, as there is no particular other way to prioritize. It would be better if we had a system for collected "likes" for requests and sorted by the number of likes. DCDuring TALK 19:36, 3 July 2013 (UTC)Reply
That might work if the typical use case was "person looks for some entries to fix". But the reality is more likely "person happens to visit entry, notices request to fix it". Because of that, I don't think adding a notice will have any negative effect whatsoever. And there is concrete evidence that adding notices in other cases has had a positive effect. For example, it has cause many more Dutch entries to have their genders/plurals fixed, compared to when those notices were not there. So they really do work. It's really just psychology: it is well known that humans are bad at noticing the absence of something, whereas the presence of something is more easily noticed, and something unexpected or unusual is noticed especially fast. —CodeCat 19:40, 3 July 2013 (UTC)Reply
I've wondered this myself. I agree that a notice should always be displayed. I support merging (redirecting) defn into rfdef. - -sche (discuss) 21:04, 3 July 2013 (UTC)Reply
I oppose the merger. The only noticeable effect will be to make Chinese character entries painfully messy and harder to use. —Μετάknowledgediscuss/deeds 23:40, 4 July 2013 (UTC)Reply
Not sure it's even possible to make Chinese character entries painfully messy and harder to use. Mglovesfun (talk) 11:37, 11 July 2013 (UTC)Reply

Template:Hira, Template:Kana

Latest comment: 10 years ago1 comment1 person in discussion

These codes are little used (less than 1000 transclusions each), and don't really have a very clearly defined use within Wiktionary anyway. The code used for Japanese is {{Jpan}}, which already encompasses Hiragana and Katakana alongside Kanji (ISO 15924 says: Jpan = Hani + Hira + Kana). So these codes aren't actually needed to provide any kind of formatting support, and they're already aliases of Jpan in the CSS. "Hira" is not set in Module:languages as the script of any language, but "Kana" is used by three languages: Ainu, Miyako, Yonaguni. —CodeCat 22:02, 17 July 2013 (UTC)Reply

Template:Hang

Latest comment: 10 years ago2 comments2 people in discussion

The code used for Korean on Wiktionary is {{Kore}}. ISO 15924 says that Kore = Hang + Hani, so it's kind of the same as above. It's already identical in the CSS. This code is used a little more than the kana codes, though still not nearly as much as "Kore". No language in Module:languages uses this code as its script. —CodeCat 22:02, 17 July 2013 (UTC)Reply

I dunno really, as long as Kore can handle both Hani script entries and Hang script entries correctly, then by all means delete. I'd like to hear some more comments first though. Mglovesfun (talk) 12:31, 18 July 2013 (UTC)Reply

Category:ISO 639

Latest comment: 10 years ago1 comment1 person in discussion

These transwikis aren't actually needed because the information was restored back on Wikipedia (see w:ISO 639:a). And I don't think it's really appropriate for Wiktionary because we have our own list of languages. —CodeCat 11:40, 18 July 2013 (UTC)Reply

Appendix:ISO 639-1 language codes, et al.

Latest comment: 10 years ago2 comments2 people in discussion

We already have our own Wiktionary:List of languages, which has information that is actually relevant to Wiktionary's own practices. Because of that, these lists are really just for general interest and therefore encyclopedic. Wikipedia already has its own lists, and it's probably better suited to maintaining them than Wiktionary is. —CodeCat 11:45, 18 July 2013 (UTC)Reply

I agree. - -sche (discuss) 19:12, 30 November 2013 (UTC)Reply
The sheer number of redlinks in the first one shows how badly out of synch it is with the rest of Wiktionary. There are capitalization problems, SOP names linked as phrases, and a variety if differences in spelling (though it's also true that we really don't seem to have any Uzbek entries for languages, including Uzbek itself, for instance- so it's not always something wrong with the page). I'm sure it's just as bad in the areas that aren't marked by the system.

Lots of templates by User:Sae1962

Latest comment: 10 years ago10 comments8 people in discussion

Propose deleting the following:

I don't even know where to begin with this...

  • These templates were meant only for Turkish, but instead they were created as general templates, even though they have no use except for Turkish. They are overly specific, which has necessitated creating many of them. For situations like this, a custom template (or {{inflection of}} or {{conjugation of}}) is highly preferred.
  • Even for Turkish, they're not even correctly named. It seems as if they were just created on a whim without any thought whatsoever.
  • All of these template add entries to their own category. This has flooded Special:WantedCategories with lots of categories that really serve no purpose. Why on earth would all these inflected forms need distinct categories, especially for a highly inflected language like Turkish (where a single noun might have dozens of forms)?
  • Barely any of the templates is categorised. Most of them can't be found through normal means, except by looking through his edits. Because {{documentation}} adds a category when the documentation page is missing, none of these show up on Special:UncategorizedTemplates. I removed that from {{documentation}}, so expect that page to be flooded with all of these soon.
  • Barely documentation about their usage or meaning. Intrusive form? What's that?
  • Putting pronunciation details in usage notes. The "suffix usage notes" template is redundant because that applies to all Turkish suffixes, so it's part of the grammar and should be familiar to anyone who knows basic Turkish. (Leaving aside the fact that it's really vague, and doesn't say what variant forms there are of the suffix!)
  • Some aren't even used on any pages. Some were actually errors that were created, then abandoned, and a replacement was created without deleting the error. Like Template:tr-conjugation which should have been Template:tr-conjunction, but was just left there.
  • This isn't even all of them! There are a lot more templates that he created, but have now been "lost" because they have no categories. Maybe someone should make a list of all the templates he created that have no category?

The newest of these was created only a week or two ago, and there have been other disputes with him in the past over the CFI-validity of a lot of his entries. So I've blocked Sae1962 as a form of "damage control". But what are we going to do to fix this mess... —CodeCat 15:17, 18 July 2013 (UTC)Reply

Speedy delete of all templates created by this user, and speedy validation of all entries this user has made. Razorflame 15:57, 18 July 2013 (UTC)Reply
  • Unblock him immediately. If you feel authorized to prevent him from creating templates, ask him on this talk page to no longer create templates or you will block him. Recall WT:BLOCK, a voted policy: "The block tool should only be used to prevent edits that will, directly or indirectly, hinder or harm the progress of the English Wiktionary. It should not be used unless less drastic means of stopping these edits are, by the assessment of the blocking administrator, highly unlikely to succeed.".

    As for the templates, they seem deletion worthy. --Dan Polansky (talk) 16:02, 18 July 2013 (UTC)Reply

In fairness Dan, I think that text supports the block; we've talked to him plenty so there's good reason to think that more talking won't help. Mglovesfun (talk) 18:46, 18 July 2013 (UTC)Reply
This shouldn't be that big of a surprise- see #A Bunch of Inflected-Form Templates, above. I nominated for deletion the nine I new about, but there was only one comment aside from mine and SAE1962's (a Turkish native speaker who argued for deletion) Chuck Entz (talk) 03:02, 19 July 2013 (UTC)Reply
I agree with the block (although I would have given a much broader / more encompassing rationale for it). We have to spend a lot of time cleaning up after this contributor: they create a lot of SOP terms, and terms with incorrect definitions (e.g. am Ende), and they make quite a few of the same formatting mistakes repeatedly, such as tagging things as the wrong language, or sometimes as two different wrong languages, as with WT:BJ#aktiven_galaktischen_Kerns. We could be spending that time on other things... - -sche (discuss) 07:26, 19 July 2013 (UTC)Reply
"less drastic means" have been employed several times in the past with no success. Block should stay. But who has got the time or inclination for such a massive cleanup operation? SemperBlotto (talk) 07:43, 19 July 2013 (UTC)Reply
Template:Seldom or unused Turkish plurals not is an interesting one. It seems to say that all nouns have plurals, if not attested then hypothetical. I suppose it's okay to link to such plurals but not to create them as everything has to meet WT:CFI. Mglovesfun (talk) 20:47, 19 July 2013 (UTC)Reply
I think the most common practice is to create entries for regular formations even if that specific form is not attested. I really doubt whether all of the verb form entries in the various Romance languages actually meet CFI. But we don't have a problem creating entries for them anyway. —CodeCat 20:57, 19 July 2013 (UTC)Reply

For the record, here are the list of templates and [categories TeleComNasSprVen (talk) 19:36, 13 January 2014 (UTC)Reply

Template:apdx-l 2.0

Latest comment: 10 years ago1 comment1 person in discussion

This has already been posted here, so this is not a real RFDO, but instead a reminder to people to go to #Template:apdx-l and (re)vote. With the new powers that {{l}} has, I think there are even better arguments for deleting this template. —Μετάknowledgediscuss/deeds 00:14, 23 July 2013 (UTC)Reply

Template:⅋

Latest comment: 10 years ago12 comments8 people in discussion

Unused template that's more problematic than the problem it's supposedly trying to solve (inserting an ampersand character). - dcljr (talk) 16:03, 25 July 2013 (UTC)Reply

Much easier to use &#38;. — Ungoliant (Falai) 16:12, 25 July 2013 (UTC)Reply
Hmm, I'll be damned if I know what the purpose of this is, or was, ever! Mglovesfun (talk) 17:10, 25 July 2013 (UTC)Reply
&amp; is probably clearer still. Delete. —CodeCat 17:14, 25 July 2013 (UTC)Reply
Keep, so long as it's still being used by WT:ACCEL. --Yair rand (talk) 19:25, 25 July 2013 (UTC)Reply
Nobody's going to delete it as long as it's still in use. I don't understand why that is a reason to want to keep it, though. You think this template is good and useful merely because it's used in WT:ACCEL? —CodeCat 19:28, 25 July 2013 (UTC)Reply
I coulda sworn I'd searched for "⅋" in User:Conrad.Irwin/creation.js and not found it (oh, nevermind: I had searched on the talk page), but there it is:

function clean_variable (va) {
    return va.replace (/([\\~])/g,"\\$1").replace(/&/g,'{'+'{subst:⅋}}').replace(/#/,'{'+'{subst:♯}}'); //Yucky HACK
}

So the question is... why? (That is, why is it there?)
In light of this, I guess the same objection can be raised about Template:♯, which is also only used there, AFAIK. (The names of both templates seem to have been deliberately chosen to make them difficult to "accidentally use" outside of that context.) See Wiktionary:Grease_pit/2012/January#Problem with accelerated entries for some related discussion.
My recommendation for both templates: userfy and delete from template namespace. - dcljr
Ha! Reminds me of my former workplace where we had an internal form of regular expression that was extended to accept the upside-down ("Spanish") question mark as some specialised form of what the standard question mark meant. This then broke a lot of scripts that weren't designed to read/write that character reliably. Probably delete or rename to something that isn't such a pain to type. Equinox ◑ 17:10, 26 July 2013 (UTC)Reply
Except this was created strictly to be used in scripts, etc., to solve a specific technical problem. No one should be typing this unless they have a very good reason to do so. It may be odd, and rarely-used, but it does no harm, since virtually no one is likely to even know it exists, and it doesn't take up much room on the servers. I say keep. Chuck Entz (talk) 17:38, 26 July 2013 (UTC)Reply
Meh, userfy... or keep... like Chuck, I don't see the harm in it, and if the script ain't broke, […] - -sche (discuss) 02:56, 27 July 2013 (UTC)Reply
Yes if it ain't broke... Mglovesfun (talk) 09:33, 30 July 2013 (UTC)Reply
If these templates were "created strictly to be used in scripts, etc., to solve a specific technical problem" then they shouldn't have been placed in the Template: namespace to begin with. <sarcasm>But, hey, let's not try to fix that now, right?</sarcasm> BTW, could the purpose of User:Conrad.Irwin/creation.js now be fulfilled with a Module:? If so, […] - dcljr (talk) 06:57, 11 August 2013 (UTC)Reply
Since it seems likely (to me) that no admin will actually userfy and delete this template and Template:♯, I've gone ahead and added Template:⅋/documentation and Template:♯/documentation to explain that the templates "should not be used", and removed the category from each template page to "hide" them further from the view of regular users. - dcljr (talk) 06:33, 22 August 2013 (UTC)Reply

Appendix:Proto-Indo-European/bʰago

Latest comment: 10 years ago5 comments2 people in discussion

Seems to have been reconstructed on the basis of a single branch (Indo-Iranian). Slavic *bagu (*bogъ) is usually considered an Iranian borrowing in the literature. Furthermore it contains phoneme */a/ which is of disputed status in the reconstruction of PIE segments. --Ivan Štambuk (talk) 16:19, 25 July 2013 (UTC)Reply

a and o merge in Balto-Slavic, so from the evidence of Slavic alone, *bʰogo- is equally valid. And there's nothing against replacing *bʰ with *b or *g with *gʰ either. So this reconstruction isn't really well founded enough to include it. —CodeCat 16:36, 25 July 2013 (UTC)Reply
They would lengthen by Winter's law which would yield Common Slavic **bagъ. And how you account for aspiration in Sanskrit bh? --Ivan Štambuk (talk) 16:57, 25 July 2013 (UTC)Reply
It's always possible it's not a cognate. The meaning is different enough. —CodeCat 19:30, 25 July 2013 (UTC)Reply
Bahuvrihi adjectives *ubogъ and *nebogъ "poor, miserable" and *bogatъ "rich" prove that *bogъ was originally also an adjective, and that it meant meaning something along "earthly wealth/well-being; fortune" and then "dispenser of wealth/fortune" and then "god". Exactly same thing happened in Iranian which according to some is too much of a coincidence to happen in parallel (hence the borrowing theory, postulated even before WL was discovered which on a more formal level implies the same).
However, I've found out that according to Beekes PIE *bʰ(e)h₂g- (LIV: bʰag-) would be the source of (deprecated template usage) ἔφαγον (éphagon) as well, but how the meanings match to II and Slavic escapes me. At any case, PIE noun *bʰago(s) "god, deity" seems worthy of deletion, because that meaning arose independently in two different subbranches. --Ivan Štambuk (talk) 21:42, 25 July 2013 (UTC)Reply

August 2013

Category:European French

Latest comment: 10 years ago5 comments2 people in discussion

This category seems like nonsense if you consider that France alone spans four continents by itself. It's mostly used in baseball terms to contrast with Category:Quebec French and spectacularly manages to completely ignore the French colonies in Africa (Reunion, Mayotte etc.), America (Saint Pierre et Miquelon and a few Caribbean islands) and Oceania (French Polynesia etc.). -- Liliana • 23:08, 1 August 2013 (UTC)Reply

French Wiktionary has this category too, and I'm sure they know quite a bit about their language. Are you contending that there are no French terms that are used primarily in Europe? —CodeCat 23:13, 1 August 2013 (UTC)Reply
Well it does suggest that French speakers living eg. in Reunion don't use these terms because Reunion isn't located in Europe, which I don't think is true. -- Liliana • 23:18, 1 August 2013 (UTC)Reply
Maybe the issue is the entries in the category then, and not the category itself. And we could always use it as a holder for different varieties of French in Europe, like we do with Dutch as well. —CodeCat 23:22, 1 August 2013 (UTC)Reply
I'm not really a fan of that kind of categorization because it clutters the regionalism category tree. -- Liliana • 23:34, 1 August 2013 (UTC)Reply

Appendix:List of Proto-Indo-European roots

Latest comment: 10 years ago6 comments6 people in discussion

I submitted this for RFC a few months ago in the hope that someone could improve these pages. The fact that nobody has done so makes me believe that these pages are beyond saving, and that it's not worth the effort to fix them all. This page is redundant to Category:Proto-Indo-European roots, the pages of which give a much better overview of these words. These lists also have no quality control whatsoever, so they are nothing more than long and hard-to-navigate lists of cognates. But probably the most pressing problem is that a substantial number of the "roots" listed are not roots at all but word stems or even fully inflected words. —CodeCat 23:45, 2 August 2013 (UTC)Reply

  • Keep. Do we have a separate PIE appendix entry containing every root and the corresponding reflex on that list? No. So it is worth keeping until we do because it contains (potentially) valuable information. Besides, I can spot some pretty doubtful roots and nominals inside th Category:Proto-Indo-European roots as well (*sū-, *sap-, *ǵénu-, *perḱ-, *pisḱ- - and that's just from the third column of the category!). --Ivan Štambuk (talk) 03:36, 3 August 2013 (UTC)Reply
  • Swan diving in for keep as well. Just because no one's come to fix it doesn't mean it's beyond saving. It's just that there seem to be so few PIE linguists around- if I knew more about what I was doing myself, I'd fix it. I just don't want to risk making a worse mess of it than it already is, although I can give it a go if someone wants me to... also, Ivan brings up a good point about it needing to stay until an index is complete. Polar Night (talk) 01:35, 11 September 2013 (UTC)Reply

Why would anyone want to delete this? Seriously ...— This unsigned comment was added by 201.15.55.98 (talk) at 01:19, 24 September 2013‎.

Keep for now, redirect to the category once every/most form has an entry. This is actually the only Wiktionary page whose link I’ve run into in a non-Wikimedia website, and two anons came out of nowhere to support keeping, so clearly this is a very popular page among our readership. — Ungoliant (Falai) 04:27, 24 September 2013 (UTC)Reply

Keep: I think it's usable as is and similar resources in print can be expensive (save for Calvert Watkins) --70.192.3.20 04:24, 10 January 2014 (UTC)Reply

KEEP. I use the links by sound quite often in research. The other appendix list you mention doesn't branch to those pages. If you think the page needs editing more than deleting, then be bold and edit it. 74.78.155.128

Category:Esperanto words suffixed with -a

Latest comment: 10 years ago18 comments6 people in discussion

Category:Esperanto words suffixed with -e

Category:Esperanto words suffixed with -i

Category:Esperanto words suffixed with -o

These are really just part-of-speech endings, so these categories don't seem terribly useful. "Esperanto words suffixed with -i" is really synonymous with Category:Esperanto verbs. —CodeCat 14:13, 5 August 2013 (UTC)Reply

These are there as a result of the automatic categorization of {{suffix}}. Is there any way to suppress the category? --Yair rand (talk) 14:24, 5 August 2013 (UTC)Reply
Don't use {{suffix}}. They're not suffixes. -- Liliana • 14:29, 5 August 2013 (UTC)Reply
They're not? Why is that? And what should be used instead? --Yair rand (talk) 15:27, 5 August 2013 (UTC)Reply
Indeed, if an adjective is formed by replacing the final -o of a noun with an -a, why not categorize it as such? All of Category:English words suffixed with -ize are going to be verbs, so what? How is that a reason for its deletion? Mglovesfun (talk) 19:29, 5 August 2013 (UTC)Reply
The difference is, not all English verbs are suffixed with -ize, while all Esperanto verbs are suffixed with -i. I agree with the first part of Liliana's statement ("Don't use {{suffix}}") but not with the second part. They are suffixes, but that doesn't mean we have to use {{suffix}} in their etymology sections. —Angr 20:38, 5 August 2013 (UTC)Reply
There is |nocat=1. Mglovesfun (talk) 11:37, 6 August 2013 (UTC)Reply
We've had this kind of debate about Category:English words suffixed with -s. It's obvious we don't want each and every English plural to end up in here, and it should be the same for other languages as well. -- Liliana • 20:49, 5 August 2013 (UTC)Reply
There was also Category:German words suffixed with -en, although there are also words with -en that are not verbs. In Esperanto, all (polysyllabic) words ending in -i are verbs, and all verbs end in -i, so they are one and the same set of words. —CodeCat 20:54, 5 August 2013 (UTC)Reply
I would argue that not all Esperanto verbs are stem + suffix, (deprecated template usage) pensi is borrowed from Latin (deprecated template usage) penso for example. Mglovesfun (talk) 07:51, 11 August 2013 (UTC)Reply
But it's still formed by with the stem pens- + the suffix -i. —CodeCat 19:17, 16 August 2013 (UTC)Reply
The way to test this concept is to look for Category:Esperanto words suffixed with -as, since that's probably a more widely-attested form than the infinitive. Notice the redlink. These words aren't suffixed with -i, they're converted to verbs, and -i just happens to be the suffix on the lemma. I suppose the lemma's suffix could be used as a stand-in for the whole set of conjugation suffixes in the same way the lemma itself is used as a stand-in for the whole conjugation, but I would argue against it. Having it categorized this way strongly implies that -i is a derivational suffix- something that would be followed by inflectional suffixes, rather than an inflectional suffix itself. We should have some way to indicate verbalization, nominalization, etc. in etymologies, without kluging something up with a framework designed for something else. What do we do in cases where there's no inflectional ending on the lemma- use a "words suffixed with -∅" category? Chuck Entz (talk) 21:45, 16 August 2013 (UTC)Reply
That problem happens in Dutch and German as well, and English too. All three of them, like Esperanto, can derive verbs without changing the stem of the word. Only the inflectional endings are changed from those of one PoS to those of another. In Dutch and German, the lemma form of verbs ends in (deprecated template usage) -en while the lemma forms of other parts of speech have no ending. That can give the impression that (deprecated template usage) -en is being suffixed when a verb is created, but that isn't the case because this ending isn't intrinsically part of the verb; only of the infinitive. The same is true of many Esperanto derivations as well. —CodeCat 21:51, 16 August 2013 (UTC)Reply
And then there's the matter of things like ablaut, umlaut, etc. that have no discrete surface morpheme to point to, e.g. with fall vs. fell and sit vs. set. Chuck Entz (talk) 22:06, 16 August 2013 (UTC)Reply
How about "Esperanto verbs derived from (PoS) stems" ? —CodeCat 22:11, 16 August 2013 (UTC)Reply
I think it would be better to have "LANGNAME POS-PLURAL derived from POS-PLURAL". Perhaps we could have a template like etyl that would take from-POS to-POS and lang as parameters, and produce something like "from the POS-SINGULAR " followed by the from-word. I'm not sure what we should do where the source is both a different language and a different POS, or where we don't know the exact source POS, though. Chuck Entz (talk) 22:41, 16 August 2013 (UTC)Reply
If we are going to add foreign etymologies to it, then we effectively end up with a template that combines {{term}} and {{etyl}}, along with PoS names. I'm not against that as such, but we have to be aware of this implication. —CodeCat 22:44, 16 August 2013 (UTC)Reply
Yes, I'm aware of the implications, which is why I hesitated to lump the other-language case in with the rest. As for term, I was envisioning a template like etyl, which adds the correct category, but is independent from the term itself and produces a string of text derived from the parameters that goes in front of the term template- sort of like a POS-based counterpart to the language-name based etyl. Chuck Entz (talk) 23:15, 16 August 2013 (UTC)Reply

Template:romanization of Hebrew

Latest comment: 10 years ago5 comments4 people in discussion

This seems like a template that goes back to earlier days, when multilingual support wasn't as neatly standardised as it is nowadays, and editors for each language had to make up their own things. I don't think it's really needed anymore. —CodeCat 23:58, 8 August 2013 (UTC)Reply

Unless I'm missing something, delete. Mglovesfun (talk) 07:48, 11 August 2013 (UTC)Reply
Well, ACCEL still relies on this template, AFAIK. —Μετάknowledgediscuss/deeds 19:09, 16 August 2013 (UTC)Reply
Which is an argument for updating it, right? And deleting this when it's safe to do so. Mglovesfun (talk) 21:48, 28 August 2013 (UTC)Reply
Most of these entries are left over from mistakes made during the orphaning of {{he-link}}. I think we should fix them, and once this is orphaned we should delete it; however, for the record, I think we should not bot-orphan this in the obvious way. The template is useful for finding the entries to fix, and a bot should be used only if it will really fix them. —RuakhTALK 07:19, 12 September 2013 (UTC)Reply

Template:unicode

Latest comment: 10 years ago6 comments3 people in discussion

This was originally intended to show text in fonts with wide unicode support, but it dates back to the times before there was proper script code support on Wiktionary. It has now ended up being used as a general "this text contains Latin script with some relatively rare characters" code. But we already have another script code for that: Latinx. So I propose moving any uses of this code to "Latinx", whenever the characters being used indeed just Latin with extended characters. If there are no more uses after that, we can delete this code. —CodeCat 18:59, 18 August 2013 (UTC)Reply

Can you read peoples' minds? I was thinking the exact same thing. -- Liliana • 21:52, 28 August 2013 (UTC)Reply
I remember nominating Latinx for deletion instead a year or so ago, but that didn't go through. I think that the name "Latinx" fits better so now I'm nominating this one. —CodeCat 21:59, 28 August 2013 (UTC)Reply
Anything that reduces our special-purpose code is good. —Michael Z. 2013-09-10 02:05 z
Delete. Seems bizarre to have a script template called unicode, aren't all our characters in Unicode anyway? Mglovesfun (talk) 15:53, 10 September 2013 (UTC)Reply
The idea was that this would specify fonts that include characters representing a large range of Unicode. As far as I can tell, this was only useful for MSIE 6, which won’t fall back to another font to display a character.
Since MediaWiki now has various IE fixes and webfonts built in, I’d be a little surprised if this template still serves any useful function. Has anyone tested en.Wiktionary in MSIE 6 in the last half decade? I can’t wait until that browser will be officially dead on April 8, 2014. —Michael Z. 2013-09-10 19:33 z
Sorry, but nope. Windows Server 2003 is still supported until 2015. -- Liliana • 19:50, 10 September 2013 (UTC)Reply
Which appears to run MSIE 7 and 8.[4] What indication is there that MS will support MSIE 6 after XP is gone?
More to the point: can anyone confirm that {{Latinx}} or {{unicode}} is required to make any text on this site render correctly, in any browser at all? —Michael Z. 2013-09-13 16:08 z
I've now changed all languages that use "unicode" as their script to use "Latinx". It is probably safe to remove the code from Module:scripts/data, but it's possible that some pages specify sc=unicode explicitly, and those will break then. Unfortunately I don't know of any way to find those pages except by allowing them to break and wait for them to show up in Category:Pages with script errors. The template {{unicode}} will need to be orphaned too, but that should be easier because template usage can be tracked down with transclusions. —CodeCat 21:02, 13 January 2014 (UTC)Reply

Wiktionary:Interesting new words/Archive

Latest comment: 10 years ago2 comments2 people in discussion

This looks like a random old collection of links.

Yeah delete, totally pointless. Mglovesfun (talk) 21:46, 28 August 2013 (UTC)Reply
Nobody is maintaining it and "word of the day" seems to serve the same role. Delete. Equinox ◑ 18:15, 29 August 2013 (UTC)Reply

Template:ro-past

Latest comment: 10 years ago3 comments2 people in discussion

I notice that since this edit in 2008, the template automatically adds the entry to Category:Romanian terms needing attention. Presumably because it doesn't have a function not already covered by {{past participle of}}. Mglovesfun (talk) 13:50, 29 August 2013 (UTC)Reply

I've changed it to add the entry to Category:Romanian entries using Template:ro-past instead, since there were a lot of these; they made up more than 75% of the entries in Category:Romanian terms needing attention. —RuakhTALK 07:10, 12 September 2013 (UTC)Reply
Although it's clearly intended to be a headword template, some entries use it as a form-of template. —RuakhTALK 07:12, 12 September 2013 (UTC)Reply

Wikisaurus:Dysnomia

Latest comment: 10 years ago1 comment1 person in discussion

Delete this entry for a moon in Solar System as too specific for a Wikisaurus page. The only two synonyms currently in the entry are redlinked Eris I and 2003 UB 313. If they ever get bluelinked, the three of them can be placed as meronyms of WS:Solar System or the like. A similar deleted Wikisaurus entry is Wikisaurus:Aldebaran, one for a star. --Dan Polansky (talk) 13:37, 31 August 2013 (UTC)Reply

Wikisaurus:Sheratan

Latest comment: 10 years ago1 comment1 person in discussion

Delete this entry for a single star, featuring only redlinkes synonyms, as too specific for Wikisaurus. The synonyms can be moved to Wikisaurus:Aries. --Dan Polansky (talk) 13:52, 31 August 2013 (UTC)Reply

September 2013

Category:Miguxês

Latest comment: 10 years ago1 comment1 person in discussion

Category:pt:Tiopês

These forms of chatspeak have too few citable terms to justify the need for individual categories. Category:Portuguese internet slang can host any that are citable. — Ungoliant (Falai) 14:46, 1 September 2013 (UTC)Reply

Template:ine-bsl-decl-noun-a-f

Template:ine-bsl-decl-noun-i-mf

Template:ine-bsl-decl-noun-o-m

Template:ine-bsl-decl-noun-o-n

Template:ine-bsl-decl-noun-u-mf

Latest comment: 10 years ago3 comments2 people in discussion

According to the creator, all of this is original research. Imaginative guesswork, just like Chinese phonosemantic interpretations. --Ivan Štambuk (talk) 10:30, 3 September 2013 (UTC)Reply

Postpone. Pereru and I have been discussing a possible change in practice concerning reconstructed terms. That would remove the need to delete these templates. He was going to make a BP post about it but he hasn't yet. In any case, if these are deleted, the categories they add should be maintained. —CodeCat 11:42, 8 September 2013 (UTC)Reply
I fail to see see what kind of relevance does the Wiktionary practice on reconstructed terms have with these templates. The endings used seem to be a synthetic work of a bunch of disparate theories you cherry-picked for your personal convenience. I've already told you how this can be solved: we can either use referenced paradigms (some of which are listed in Appendix:Proto-Balto-Slavic declension), or we can compile our own on the most recent scholarship but strictly with each ending being referenced and discussed. This kind of "educated guesswork" renders Wiktionary useless as a reference on etymologies, since it becomes impossible to separate established scholarship from whatever Wiktionary editors have decided to be true. --Ivan Štambuk (talk) 15:55, 12 September 2013 (UTC)Reply

Template:ja-suru etyl

Latest comment: 10 years ago1 comment1 person in discussion

This was used, but never widely adopted, before we settled on the current format for する (suru) verbs. For a random example of the current practice, see 鎮圧. Suru verbs are really nouns plus the verb suru ("do"), but only certain nouns can be used with suru. Previously, those verbs were on a separate page and it made sense to have an etymology making the connection explicit. Now they're on the same page, and {{ja-verb-suru}} serves to make the connection clear. It's not used anywhere now. I don't like the wording either. --Haplology (talk) 06:58, 8 September 2013 (UTC)Reply

Template:k

Latest comment: 10 years ago16 comments7 people in discussion

Do we still need this? It seems like it is well intentioned, but in reality having yet another linking template only confuses things more. —CodeCat 19:03, 9 September 2013 (UTC)Reply

I'm not sure we ever needed this. Did you orphan it or was it just unused? It seems like quite a bad idea, because if you want to make a linking template that simple, it's less useful than linking using square brackets. Mglovesfun (talk) 19:23, 9 September 2013 (UTC)Reply
It had about 10 transclusions, which I edited out. —CodeCat 19:28, 9 September 2013 (UTC)Reply
I found six in Special:Contributions/CodeCat. Please don't orphan immediately as it gives would-be commenters a chance to see how the template was used. Especially when there are so few transclusions as orphaning with a consensus is so easy. Mglovesfun (talk) 19:32, 9 September 2013 (UTC)Reply
In the past, people have opposed deletions purely because they were transcluded. —CodeCat 19:54, 9 September 2013 (UTC)Reply
Then they're idiots, what can I say? Mglovesfun (talk) 19:59, 9 September 2013 (UTC)Reply
Delete, I don't think it was ever needed, it was an experiment. Mglovesfun (talk) 12:45, 11 September 2013 (UTC)Reply
Delete. We already have the l/ templates for efficiency. — Ungoliant (Falai) 20:50, 11 September 2013 (UTC)Reply
In its original form it required no Lua or template calls etc. It simply linked to language sections. It provided all the required functionality for all terms that used the default (Latin) script of this wiki. Many seem to prefer totalitarian uniformity at any cost in complexity. DCDuring TALK 22:43, 11 September 2013 (UTC)Reply
That might make sense if this were a matter of freedom of expression. But to me, more templates adds to the mental burden of editing Wiktionary, rather than removing from it. You have often complained about template-itis. Is creating another template that duplicates the purpose of an existing one not an example of that? You think having many templates that fulfill the same task makes things easier? —CodeCat 22:48, 11 September 2013 (UTC)Reply
Are you claiming to have eased the cognitive burden? As with {{context}}? and {{l|en}}, or is that {{l/en}}? and requiring lang= even for lang=en? Some easing. DCDuring TALK 23:09, 11 September 2013 (UTC)Reply
I don't see how lang=en makes the template harder to use. And {{l/en}} was... maybe not as useful as we thought. I am not sure if we still need it, in any case. If typing too much is a problem, then use {{label|en|...}} which is shorter than {{context|...|lang=en}} and only one character more than {{context|...}}. —CodeCat 00:04, 12 September 2013 (UTC)Reply
Adding extra parameters tends to make things harder to use. Editors only editing English would previously not have needed to know that the lang parameter even existed. --Yair rand (talk) 03:22, 12 September 2013 (UTC)Reply
And {{context}} was designed so that one only had to type "context" when one was doing something not covered by the substantial number of labels for which templates were available. Were English contributors "spoiled" by having it too easy? Probably, though they ended up having to add lang= parameters to the items that were wrongly categorized as English. I find myself avoiding adding labels because of 1., the extra typing, 2., the ridiculous categorization based on the continuing ambiguity (or conceptual confusion?) between usage context labels and topic labels, and 3., the instability of our template behavior. I really have no interest in sorting out technical questions, but they do keep on interfering with ordinary contributions in English, IMO. That is the biggest reason why I have spent most of my time on taxonomic entries, which is a much simpler realm, which has little need for {{context}} and could have even less.
Further, I have never seen benefit, only cost, from requiring all links to have lang= parameters, other than to directing users following links to the proper L2 section. The script-setting was never relevant for any language using the default character set. English term links would benefit much more from a well-developed system of links to Etymology, PoS, and individual senses than anything else. The benefits would apply to the glosses that appear in non-English term translations, which remain riddled with erroneous and ambiguous glosses and use of terms that are not idiomatic, obsolete, archaic, dated, rare, or "false friends". {{sense-id}} is underused and lacks some capabilities, like operation with popups that would speed the evaluation of linked terms in glosses.
The extra typing is a pain, yes. I think it would make sense to assume a lang value of the current section's language as a default where no lang= is specified. Equinox ◑ 04:43, 12 September 2013 (UTC)Reply
That would be ideal, but it's not currently possible because templates have no "knowledge" of the page that they are added to. So they're not able to see what language section they are in. Something we could try, though, is making this a bot task. Editors could leave out the language, which would cause the template to withhold back some of its functionality (that which depends on knowing the language, like choosing a category name), but it would also add the template to a cleanup category. A bot could then regularly go through this category and add the language as necessary. I have already been doing this on a semi-regular basis with {{context}} and {{etyl}}. —CodeCat 15:47, 12 September 2013 (UTC)Reply
Delete --Z 06:19, 12 September 2013 (UTC)Reply

Template:en-verb form

Latest comment: 10 years ago6 comments4 people in discussion

The categorization should always be done by the definition-line template like {{en-past of}} or {{present participle of}}. This template serves to double-categorize entries by Category:English verb forms as well as the more specific category. Replace with {{head|en}} and delete. Mglovesfun (talk) 12:43, 11 September 2013 (UTC)Reply

I don't think this template adds much value, so I agree with deleting it. But why do we have categories for all of the individual verb form types? Are those really useful or necessary? —CodeCat 17:36, 11 September 2013 (UTC)Reply
I don't think they're either more or less useful than Category:English verb forms. Categories that are very small or very big aren't generally useful to human users. Mglovesfun (talk) 20:40, 11 September 2013 (UTC)Reply
Delete, there are similar templates for other languages, they should be deleted as well. --Z 06:52, 12 September 2013 (UTC)Reply
Delete per nom. (I'm not sure if all "similar templates" should go, but this one should.) —RuakhTALK 07:00, 12 September 2013 (UTC)Reply
Not all form-of templates categorise. In fact a lot of those used for languages other than English don't. {{inflection of}} and {{conjugation of}} don't, nor do {{feminine of}}, {{masculine plural of}} and such. I was hoping that we could make this more consistent by adopting a rule that the headword template always categorises, and the form-of template never does, but I don't know how realistic that is. —CodeCat 12:05, 22 September 2013 (UTC)Reply

Template:l/en

Latest comment: 10 years ago8 comments7 people in discussion

Too much trouble for too little benefit. Too little benefit because it's not that urgent to link to "English" section, as the section is usually the first one, and specifying lang="en" is not needed in 99% of cases (we can use {{l}} for the rest). Too much trouble because it complicates wikicode and 'adds to mental burden of editing.' If {{l/en|...}} is an improvement, we should replace all wikilinks ([[...]]) with {{l/en|...}} in the main namespace (I don't think anyone would support this?), otherwise all of its usages should be replaced with [[...]], because it causes inconsistency. Currently we are using [[...]], {{l/en|...}} (and even {{l|en|...}}), sometimes at the same time in a single page, what a mess. --Z 06:50, 12 September 2013 (UTC)Reply

Comment. ==English== is actually not always the first section: it follows ==Translingual==. Also, for those of us using Tabbed Languages, the gadget remembers the language section we last visited, and sends us there when we visit a language-unspecified link. As for your other comments . . . for some reason, we deleted the meaningful {{onym}} in favor of the meaningless {{l}}, so I'm no longer sure. I used to think it made sense to explicitly language-tag all mentions, but since we're no longer explicitly tagging them as mentions, I guess it might not make sense anymore. —RuakhTALK 06:59, 12 September 2013 (UTC)Reply
I think the idea was anything useful from {{onym}} could be incorporated into {{l}} rather than having them as rival, very very similar templates. Mglovesfun (talk) 11:18, 14 September 2013 (UTC)Reply
Keep While it often isn't necessary to link to the English section, explicitly linking to it tells us that the link isn't to a "foreign"/non-English word. You don't need to tell that, but it would be nice if you allowed other to tell it. --80.114.178.7 22:08, 27 September 2013 (UTC)Reply

Delete. --Vahag (talk) 07:07, 12 September 2013 (UTC)Reply

I prefer to delete all of these l/ templates. I think the best 'low cost' way of doing it is either [[foo]] or [[foo#English|foo]]. It depends how low cost you want to go. This is somewhere in the middle where {{l}} is at the top of the range, but hopefully improved by Lua and other changes. Mglovesfun (talk) 11:16, 14 September 2013 (UTC)Reply
Keep for the reasons I posted here. — Ungoliant (Falai) 20:46, 27 September 2013 (UTC)Reply
Keep, as per Ungoliant. Linking to the proper section may be not so important for the longer words (which are less likely to be available in more than one language), but comes very handy for the shorter ones (as in: a.) The importance of the proper xml:lang= coding may currently be low, but I’d expect it to steadly rise as time goes by. (And why, aren’t w:Word processors of today use that information for spell-checking?) — Ivan Shmakov (d ▞ c) 14:24, 15 November 2013 (UTC)Reply

Template:m

Latest comment: 10 years ago16 comments9 people in discussion

(Listing here because CodeCat has already begun bot-orphaning it for deletion. Previous discussion: Wiktionary:Grease pit/2013/September#Template:term/t.)

  • Keep, at least for the next several months. This has been a very widely-used template, and people are likely still using it; it would be folly to eliminate it overnight. (I'll abstain, however, on the question of whether it should be kept permanently.) —RuakhTALK 06:51, 12 September 2013 (UTC)Reply
    That's OK if people keep using it as a gender template for some time: when we orphaned the template, we will use it as {{term/t}}, and {{term/t}} has several required parameters. On the other hand, when {{m}} is used as a gender template, it would be used without specifying those parameters, so (for now) the module can simply return the old content of {{m}} and add the page to a cleanup category if no parameter is specified. --Z 07:05, 12 September 2013 (UTC)Reply
  • I don't think we should have a single {{m}} template with two unrelated purposes. We've done it before when there were excellent reasons (e.g. when we had to migrate from {{see}} to {{also}} because the language code see was assigned), but the reasons in this case do not seem to be so good. —RuakhTALK 07:56, 12 September 2013 (UTC)Reply
  • Orphan and then delete. I do think that bringing {{term}} in line with {{l}} is a good thing, and we know two things: {{m}} is a short name like {{l}} is, and we can't use {{term}} because the parameters are incompatible. Z is right that there is no danger of confusion. Someone who uses {{m}} as a gender template once the change has been completed will trigger a script error, so they will be notified of the problem and we can easily trace it. The suggestion of making {{m}} dual-purpose would not work, though, because it accepts parameters of its own, {{m|f}} for example. If this were done with the new template, the result would be a script error saying "f" is not a valid language code. —CodeCat 15:40, 12 September 2013 (UTC)Reply
    Actually we could special-case for that, but I agree that it would not be feasible. Keφr 15:46, 12 September 2013 (UTC)Reply
Keep, orphaning it so we can use {{m}} for the name of {{term/t}} is madness; can the template {{o}} because it's the next available letter alphabetically after {{l}} that's not already in use as a template name. Mglovesfun (talk) 15:50, 12 September 2013 (UTC)Reply
That's actually not the only reason to do it. But it's a reason to do it now rather than later. The truth is we don't need these templates anyway. Look at the code inside {{m}}, {{f}} etc and you'll see what I mean. They're all identical. —CodeCat 16:06, 12 September 2013 (UTC)Reply
  • Delete, as well as any other stupid one-letter-name template. {{g}} should be named {{gender}} to force editors to specify gender sparingly on its own, and instead only within proper templates with support for positional or named (g=) parameter for genders. --Ivan Štambuk (talk) 15:59, 12 September 2013 (UTC)Reply
Actually that's quite a good point. Though not a reason I don't think to make the name of the template longer. Mglovesfun (talk) 11:20, 14 September 2013 (UTC)Reply
  • I don't follow. Your stated reason for orphaning this template was that you want to delete it; so the RFDO discussion should come first, to determine whether that deletion is desired. I get the impression that you'd want to orphan the template even if we weren't going to delete it, so an alternative approach would be to start a BP discussion about orphaning it; I just figured it was simpler to combine the two discussions at RFDO. (That's a common practice, both for templates and for categories.) If you'd like to start a BP discussion, please be my guest. —RuakhTALK 20:52, 13 September 2013 (UTC)Reply
Changed my mind based on what Ivan Stambuk said; delete as then editors will not be so quick to user genders outside of templates that support them. Mglovesfun (talk) 12:10, 22 September 2013 (UTC)Reply
I think there are four deletes and two keeps, both of which say that it should be deleted only if nobody uses it anymore. I think that's enough of a reason to at least try to orphan the template, which in turn would affect how many people use it (they use it when they see it used elsewhere). —CodeCat 20:20, 15 January 2014 (UTC)Reply

Template:el-alternative form of

Latest comment: 10 years ago10 comments5 people in discussion

Should be merged into {{alternative form of}}; I see no reason to have a lang-specific version. —Μετάknowledgediscuss/deeds 06:16, 22 September 2013 (UTC)Reply

There are quite a few language specific templates for Greek. Mglovesfun (talk) 11:53, 22 September 2013 (UTC)Reply
Delete. Mglovesfun (talk) 10:59, 22 November 2013 (UTC)Reply
Deleted, thank you Kc_kennylau —Saltmarsh (talk) 06:12, 3 February 2014 (UTC)Reply
@Saltmarsh No problem, and please call me kc_kennylau or Kenny. --kc_kennylau (talk) 06:13, 3 February 2014 (UTC)Reply

Template:list:moons of Mars/en

Latest comment: 10 years ago7 comments3 people in discussion

A template for a two-item list. Looks like overkill to me. — Ungoliant (Falai) 00:10, 24 September 2013 (UTC)Reply

Delete. Mglovesfun (talk) 02:49, 24 September 2013 (UTC)Reply
Why aren't we using the Appendix: namespace for lists like these? Pages there can still be transcluded, if that's why templates were being used. - dcljr (talk) 03:04, 24 September 2013 (UTC)Reply
Because these aren't intended to be appendices. Not sure what else to say, it's a bit like asking why the entry house isn't Appendix:house. Mglovesfun (talk) 22:17, 27 September 2013 (UTC)Reply
Not really. More like asking why {{types of houses}} isn't at Appendix:Houses. In any case, now that I've looked through the list of "list:" templates more carefully, I guess I see the difference. Still, there is potentially much overlap in the kinds of topics covered by the two methods... (And note, BTW, that some "appendices" are in fact simply bare lists, as well.) - dcljr (talk) 00:26, 28 September 2013 (UTC)Reply
One notable example of the "overlap" I was referring to: Appendix:Days of the week vs. Template:list:days of the week/*. - dcljr (talk) 00:41, 28 September 2013 (UTC)Reply
Because it's intended to function as a template, so the template namespace is somewhat unsurprisingly the best choice. Mglovesfun (talk) 12:55, 2 October 2013 (UTC)Reply

Template:taxoninfl

Latest comment: 10 years ago5 comments3 people in discussion

This template is now being put in place of {{mul-proper noun}}. I don't know why. --Dan Polansky (talk) 11:00, 29 September 2013 (UTC)Reply

  1. It does all and only what currently seems needed for taxononomic names.
  2. It is not subject to the font-display problem that besets {{mul-proper noun}}.
  3. It provides a basis for subsequent specializations.
--DCDuring TALK 15:10, 29 September 2013 (UTC)Reply
  • taxoninfl is now placed as a headword-line template. It is preferable to keep the number of headword-line template limited, if only to ease the work of Wiktionary reusers. From what I can see, taxoninfl does not do anything that "mul-proper noun" cannot do. If "mul-proper noun" has some font problems, these should be fixed in the template; you don't go placing a new template name across the wiki only because you do not have the consensus to change an existing template. ---Dan Polansky (talk) 19:54, 2 October 2013 (UTC)Reply
The intent is to develop the ability of the template to accommodate formatting of subspecific taxa, which have mixed italic/non-italic formatting without overburdening our already overstressed technical resources who, when they get around to it, overgeneralize the problem.
You are the sole objector. When I have been the sole voice crying out in the wilderness, I did not try to impose my will, nor did I find others who would let me block someone's efforts. Perhaps you will be more fortunate or skillful. DCDuring TALK 21:01, 2 October 2013 (UTC)Reply
Keep. — Ungoliant (Falai) 00:23, 30 September 2013 (UTC)Reply

Category:en:Energy medicine

Latest comment: 10 years ago11 comments7 people in discussion

Did he mean "emergency medicine"? SemperBlotto (talk) 15:14, 30 September 2013 (UTC) p.s. You don't seem to be able to RfV a category. is that correct? SemperBlotto (talk) 15:14, 30 September 2013 (UTC)Reply

It's technically possible to RFV categories, but it's not encouraged... it's not sensical. This (RFDO) is the right place to discuss whether or not categories are valid. - -sche (discuss) 05:24, 3 October 2013 (UTC)Reply
Why so doubtful, Robin? If anyone here wants my opinion on what's supposed to constitiute medicine, I believe that certificates and vouchers are preferable to licenses. --Lo Ximiendo (talk) 17:09, 12 November 2013 (UTC)Reply

October 2013

Appendix:Proto-South Central Dravidian/cow-ar

Latest comment: 10 years ago1 comment1 person in discussion

'Proto-South Central Dravidian' entry with no descendants and nothing links to it. A proto entry with no descendants is pointless. I would speedy delete it but perhaps here are some descendants and they should be added instead of speedy deletion. I also couldn't find a Wiktionary code for this; is there one? Mglovesfun (talk) 12:51, 8 October 2013 (UTC)Reply

Template:nn-decl-noun-m1

Latest comment: 10 years ago2 comments2 people in discussion

Any ideas? --ElisaVan (talk) 10:43, 11 October 2013 (UTC)Reply

Whatlinkshere has some, but I don't understand them.​—msh210℠ (talk) 18:41, 16 October 2013 (UTC)Reply

Template:lang-plural noun

Latest comment: 10 years ago2 comments2 people in discussion

An undesirable half way between using {{head}} and creating language specific plural noun templates. Some languages already cover this; {{fr-noun}} has a type=plural parameter, for example. Mglovesfun (talk) 09:51, 30 October 2013 (UTC)Reply

If this is undesirable, then {{head}} should add "type=plural", and {{en-noun}} should have this option as well, instead of having {{en-plural noun}} . Having different types of templates for every language is inconsistent, if some support "type=plural" others don't but the language still has these plural-only forms, and others still, have entirely separate templates for them, while {{head}} shows no indication of such use. -- 70.49.124.77 04:41, 31 October 2013 (UTC)Reply

November 2013

Template:talk header

Latest comment: 10 years ago9 comments8 people in discussion

I think we are better off without such a template. Luckily enough, the template currently clutters less than 40 talk pages, as per Special:WhatLinksHere/Template:talk_header. --Dan Polansky (talk) 11:56, 3 November 2013 (UTC)Reply

Orphan and delete per nom. —RuakhTALK 04:54, 4 November 2013 (UTC)Reply
Instead of adding this to talk pages, can't this just be included in the display of talkspace pages? (editintro, or otherwise) -- 70.24.251.36 06:46, 4 November 2013 (UTC)Reply
Delete especially per 70.24.251.36. Put it automatically at the top of every talk pages as a editintro, or don't include it at all. Mglovesfun (talk) 11:05, 4 November 2013 (UTC)Reply
Orphan it, after that it may be deleted, but it is useful for exposing people who think that telling others to
  • Be polite
  • Assume good faith
  • Avoid personal attacks
is polite, assuming good faith, and avoiding personal attacks. Telling people to be polite before they have showed any kind of impoliteness is neither polite, nor assuming good faith, it borders a personal attack. --80.114.178.7 22:47, 5 November 2013 (UTC)Reply
It's not quite a personal attack if it's displayed for everyone at the top of the page. But I agree it's not necessary since no one every follows those rules anyway. --WikiTiki89 22:51, 5 November 2013 (UTC)Reply
So you have exposed me, 80. Around when I created that template (emulating Wikipedia:Template:Talk header), Talk:santorum was receiving some acrimonious posts. I did indeed intend that template to be a polite, good-faith, peaceful reminder. Abstain. ~ Röbin Liönheart (talk) 15:39, 6 November 2013 (UTC)Reply
At Talk:santorum the template is understandable, at user talk pages it often is less understandable, at Talk:unicorn you just acted as I described. --80.114.178.7 01:51, 14 November 2013 (UTC)Reply
Delete. (What Dan and Mg said.)​—msh210℠ (talk) 19:25, 6 November 2013 (UTC)Reply

Appendix:Roger Rabbit

Latest comment: 10 years ago7 comments7 people in discussion

More Piles Of Crap. Also nominating Appendix:When They Cry, Appendix:The Mask, Appendix:The Fairly OddParents and basically everything in Category:Appendices of works of fiction that looks like a Big Pile Of Crap Created By Daniel Carrero (BPOCCBDC). --ElisaVan (talk) 11:19, 12 November 2013 (UTC)Reply

Delete the four appendices that you have named. (And probably the others, but I haven't looked.) Equinox ◑ 20:33, 12 November 2013 (UTC)Reply
Toontown seems like something that might used without specific reference to WFRR, but that's about it. ~ Röbin Liönheart (talk) 22:42, 12 November 2013 (UTC)Reply
Delete all. Wiktionary's job is not to house all information, no matter how irrelevant. Mglovesfun (talk) 22:58, 12 November 2013 (UTC)Reply
Delete the four pages you name, and Appendix:Avatar: The Last Airbender, and Appendix:Bludgeoning Angel Dokuro-Chan, and indeed everything else in the category you name except Appendix:A Clockwork Orange and Appendix:Harry Potter and its subpages. - -sche (discuss) 17:23, 13 November 2013 (UTC)Reply
Delete Appendix:Roger Rabbit, Appendix:When They Cry, Appendix:The Mask, Appendix:The Fairly OddParents, Appendix:Avatar: The Last Airbender, Appendix:Bludgeoning Angel Dokuro-Chan, Appendix:The Mask, Appendix:The Life and Times of Juniper Lee, Appendix:SpongeBob SquarePants, Appendix:Serial Experiments Lain; keep Appendix:A Clockwork Orange. --Dan Polansky (talk) 18:44, 13 November 2013 (UTC)Reply
Please delete them. Sorry for the trouble. --Daniel 11:21, 14 November 2013 (UTC)Reply

Template:trans-see-flw

Latest comment: 10 years ago2 comments2 people in discussion

Old failed experiment --ElisaVan (talk) 11:42, 12 November 2013 (UTC)Reply

Delete. Mglovesfun (talk) 12:54, 12 November 2013 (UTC)Reply

Appendix:fr:Zodiac

Latest comment: 10 years ago1 comment1 person in discussion

Created and then later nominated for speedy deletion by Wonderfool. I would say... delete. Not enough information here to justify an appendix. The individual entries can cover it. Mglovesfun (talk) 12:41, 12 November 2013 (UTC)Reply

Category:Serbo-Croatian imperfective forms and Category:Serbo-Croatian perfective forms

Latest comment: 10 years ago16 comments4 people in discussion

These seem redundant to Category:Serbo-Croatian imperfective verbs and Category:Serbo-Croatian perfective verbs. Apparently those categories were never created, which is strange as most other Slavic languages do have them. Compare Category:Slovene imperfective verbs and Category:Russian imperfective verbs. Also note that the categories up for deletion are categorised as lexical, meaning they are considered by their meaning/connotation rather than grammar. I think that's a bit strange. —CodeCat 23:05, 27 November 2013 (UTC)Reply

I think they should they be moved, rather than deleted and entries formatted accordingly, if it makes it any easier. We should invite Ivan Štambuk (talk • contribs). Category:Imperfective forms by language (and perfective) are only used by Serbo-Croatian, Category:Imperfective verbs by language used by other Slavic languages + Georgian (Ukrainian and Belarusian were modeled from Russian, anyway). Bulgarian and Macedonian verbs could also be categorised by imperfective/perfective, nobody bothered, though. --Anatoli (обсудить/вклад) 23:26, 27 November 2013 (UTC)Reply
Perfective/imperfective distinction is lexical (i.e. meaning-based), but I don't see how is that relevant. Those categories are supposed to contain alternative forms only, i.e. not full-blown entries, but those that have {{perfective form of}} and {{imperfective form of}} as their definition lines. Yes They should also categorize in Category:Serbo-Croatian imperfective verbs and Category:Serbo-Croatian perfective verbs but it's useful to have them as well. --Ivan Štambuk (talk) 23:35, 27 November 2013 (UTC)Reply
IMO, it's a grammatical difference, not lexical, even if Serbian or Croatian grammarians haven't describe it yet (I really don't know). There are substantial differences in usage and forms between perfective and imperfective, which are similar but not the same across Slavic languages, e.g. absence of present tense for perfective verbs, e.g. написа́ть (napisátʹ) has no present but писа́ть (pisátʹ) does, future tense for imperfective is made using auxiliary verbs (e.g. бу́ду писа́ть) but perfectives are solid (e.g. напишу́) (Ukrainian has a unique alternative future for imperfective - e.g. писа́тиму).
Admittedly, perfective forms (and sometimes the other way around) often add to the original meaning (start an action, end an action, semelfactive verbs, etc.) and it can be at times difficult to determine what perfective verb is an equivalent of an imperfective one, e.g. цвести́ (cvestí, “to bloom”) has various perfective equivalents, which substantially change the original meaning of "to bloom" but for majority of verbs it's easy. Perfective and imperfective verbs are in separate entries and any lexical difference can ALSO be defined. Both писа́ть (pisátʹ) and написа́ть (napisátʹ) mean "to write", the variations are implied by the aspect itself - "на-" in this case implies completed action. --Anatoli (обсудить/вклад) 23:43, 27 November 2013 (UTC)Reply
When you say that the difference is grammatical, it means that there are some specific grammatical markers (prefixes, suffixes, ablaut) that ensure that the verb is perfective or imperfective based on its form (present and infinitive stem), regardless of its meaning. Since there are both perfective and imperfective verbs belonging to the same inflectional class in Russian, it is the meaning which dictates whether the verb is perfective or imperfective, and which possible slots in the entire hypothetical paradigm "make sense". E.g. you cannot guess that цвес-ти/цвет- is "inherently" imperfective, whereas сес-ть/ся́д- is "inherenty" perfective, on the basis of their spelling. In SC in some verbs the only difference is tone (e.g. poglédati impf. vs. pògledati pf. - the entire paradigm is identical, the only difference is accent).
Regarding the soft-redirection: it's for pragmatic reasons. SC has the problem of two scripts, Ijekavian/Ekavian pairs, and in the worst cases you get 6-8 entries which should then duplicate all of the definitions, usage samples....keeping them in sync is painful and time-wasting for editors, and probably confusing to readers. Note that only the verbs where there is no difference in meaning other than perfectiveness/imperfectiveness of action are redirected this way, All forms built through prefixation such as (deprecated template usage) pisati - (deprecated template usage) napisati are treated as separate entries with different definitions because all of those prefixes such as na- can create several subtle variations in meaning of the base verb. Same goes semantically marked suffixation (e.g. creating pejorative or diminutive verbs) or generally changing the meaning (e.g. iterative forms built through various suffixes) - they all have separate entries. --Ivan Štambuk (talk) 01:22, 28 November 2013 (UTC)Reply
I agree with Ivan here. --WikiTiki89 23:56, 27 November 2013 (UTC)Reply
Can you elaborate, please? Does that mean that all Russian/Polish/Czech, etc. verbs are formatted/categorised incorrectly, in your opinion or one of the forms doesn't need definitions? --Anatoli (обсудить/вклад) 00:07, 28 November 2013 (UTC)Reply
The way I understood it is that Ivan is not saying that Category:Serbo-Croatian imperfective verbs and Category:Serbo-Croatian perfective verbs are wrong and Category:Serbo-Croatian imperfective forms and Category:Serbo-Croatian perfective forms are right. He is saying that they mean two different things and therefore should be created and kept, respectively. --WikiTiki89 02:36, 28 November 2013 (UTC)Reply
I see. Do we really need both categories, though? --Anatoli (обсудить/вклад) 01:32, 29 November 2013 (UTC)Reply
Currently SC verbs are not categorized by perfectiveness, and {{sh-verb}} has no parameter for it that would enable autosort. My reasoning behind the categorization introduced by {{perfective form of}} and {{imperfective form of}} was that all soft-redirect templates ({{alternative form of}}, {{abbreviation of}}, {{diminutive of}} etc.) autocategorize on the basis of their function. --Ivan Štambuk (talk) 21:41, 29 November 2013 (UTC)Reply
Not all of them do. {{inflection of}} and {{conjugation of}} don't, nor do {{feminine of}} or {{definite of}}. —CodeCat 21:55, 29 November 2013 (UTC)Reply
But those are all for inflected forms. Entries redirected by {{perfective form of}} and {{imperfective form of}} are lemma entries, and only definition lines are missing. Soft-redirected lemmas always categorize according to the criteria of redirection. --Ivan Štambuk (talk) 22:33, 29 November 2013 (UTC)Reply
Even so, is it useful to have these categories in preference to Category:Serbo-Croatian imperfective verbs and the like? In the current categorisation, at most half of all verbs will be appropriately categorised for perfective/imperfective, which doesn't seem useful at all. —CodeCat 03:36, 30 November 2013 (UTC)Reply
I never said it wouldn't. Reread my answers above. --Ivan Štambuk (talk) 13:53, 30 November 2013 (UTC)Reply
I'm going to reiterate my vote to delete these categories. I really don't understand why they're needed. From what I've understood, Ivan wants them to contain, specifically, all imperfective or perfective verbs that are the less-common of each pair of imperfective and perfective verbs. He hasn't yet expressed any intention to create a category for the more-common of each pair, nor a category for all imperfective and one for all perfective verbs. So it seems like this is more a case of categorising for the sake of categorising, without any real purpose in mind. If we have both Category:Serbo-Croatian imperfective verbs and Category:Serbo-Croatian imperfective forms side by side, what is the value of the latter over the former? What use does it add, even if the contents are different? Not to mention the names are confusingly similar, and "imperfective forms" doesn't do much to clarify the real purpose (whatever it is). —CodeCat 22:07, 18 December 2013 (UTC)Reply
The more common form is used as a lemma, the less common as a redirect. They mean exactly the same thing, apart from being modified for perfectiveness. There is no need to categorize the unmarked form (the more common one). It is done for practical purposes, to reduce content duplication due to SC being written in two scripts, and often having Ijekavian/Ekavian pairs. As I've expressed above, I have nothing against creating the category of all perfective or imperfective verbs - though I find it less useful. It's exactly one of those categories for the sake of categorizing that you mention. (Like categorizing nouns by gender, verbal meanings by transitivity and so on). The value of the latter is that it would contain only verbs who have perfective base lemma. All alternative forms lemmas for all language categorize into their own special categories so I don't see why these shouldn't as well. The usage criterion is used by paper dictionaries and not made up by me - that's how in most of the cases user lands on an entry that has definition lines (as opposed to our American/British spellings which soft-redirect randomly). --Ivan Štambuk (talk) 16:19, 19 December 2013 (UTC)Reply

Template:la-conj-form-gloss

Latest comment: 10 years ago6 comments4 people in discussion

Glossing inflected forms is inappropriate and could cause error if it falls out of synch with the lemma page. The whole point is that conjugated forms point to the lemma, not defining it there. Moreover, these are somewhat inaccurate because Latin grammar sometimes requires that, for example, a subjunctive be translated as an indicative in English. I think it would be better to do away with this template and all its subtemplates. —Μετάknowledgediscuss/deeds 23:32, 27 November 2013 (UTC)Reply

I agree, and had been about to nominate this myself. (There must be some sort of Baader-Meinhof effect at work.) Delete. As I wrote on WT:RFC#Latin_inflected_forms_which_contain_definitions, for the dozens of inflected forms of Latin verbs to display all of the verbs' (potentially dozens of) senses "is a uniquely terrible idea and I can only hope there are already policies against it". The duplicated content is unmaintainable, prone to falling out of sync with the lemma. - -sche (discuss) 00:42, 28 November 2013 (UTC)Reply
You should also take a look at Special:WantedPages, page 1, items 324-600, beginning Template:la-conj for some other detritus of this effort. For some reason those don't show up on Special:WantedTemplates. There are other pages with both higher and lower numbers on Wanted Pages, but the concentration between 324 and 600 is notable. The listing might help track some of this down. DCDuring TALK 01:16, 28 November 2013 (UTC)Reply
This was a fairly major effort by User:AugPi, though not part of his recent contributions. He should be informed by e-mail. DCDuring TALK 01:24, 28 November 2013 (UTC)Reply
Note something else I wrote on RFC: "not all entries use la-conj-form-gloss in conjunction with our usual short "x-form-of" glosses; some (especially participles) use only la-conj-form-gloss... which makes it less than straightforward to remove by bot. But the sheer number makes it impractical to do by hand." perhaps a bot could strip la-conj-form-gloss from entries that also use the usual "form of" templates, and leave us to decide what to do with whatever was left. (Simply removing it from all entries, including entries that didn't use "form-of" templates, would leave the latter entries definitionless.) - -sche (discuss) 02:34, 28 November 2013 (UTC)Reply
Delete, I've never liked this. Adds a lot more information to the pages in question without adding useful information. Mglovesfun (talk) 14:54, 28 November 2013 (UTC)Reply

December 2013

{{wikitable}}

Latest comment: 10 years ago9 comments4 people in discussion

About 450 transclusions and redirects. This is unnecessary. It merely adds the text class="wikitable" to a table. Every instance should be replaced with the literal text. The actual effect of the class is set by CSS that is now built into the MediaWiki software, and can be overridden by putting CSS in our local style sheet MediaWiki:Common.css.

Disadvantages of keeping this template include:

  1. An unnecessary transclusion
  2. Standard literal HTML code is being hidden behind a layer of wiki template, but its function is controlled in style sheets, not in the template
  3. The danger of applying multiple class attributes to a table, which could cause broken and unpredictable styling, and could be difficult to diagnose

When replacing, multiple class attributes should be combined. For example: 

{| {{wikitable}} class="someclass"

Resolves as: 

{| class="wikitable" class="someclass"

And should be replaced with 

{| class="wikitable someclass"

 —Michael Z. 2013-12-14 21:34 z

Definitely delete. —CodeCat 21:42, 14 December 2013 (UTC)Reply
Aye. Mglovesfun (talk) 00:51, 15 December 2013 (UTC)Reply
I've gone ahead and deprecated the template. It now needs to be orphaned. --WikiTiki89 04:22, 2 February 2014 (UTC)Reply
Template:prettytable and Template:prettytable100 also need to be orphaned and deleted. --WikiTiki89 04:35, 2 February 2014 (UTC)Reply
I'll use my bot to orphan them, if you allow me to. --kc_kennylau (talk) 07:50, 2 February 2014 (UTC)Reply
I think that would be fine, as long as you follow the example that Michael gave above of when there is another class= after the {{wikitable}}. --WikiTiki89 07:54, 2 February 2014 (UTC)Reply
Started doing it with Kennybot (talk • contribs). Please check his contributions if there is any mistake, and tell me at once, I'll be watching this page. --kc_kennylau (talk) 08:27, 2 February 2014 (UTC)Reply
@Mzajac, Wikitiki89, CodeCat Finished. --kc_kennylau (talk) 09:34, 2 February 2014 (UTC)Reply
Excellent! Deleted. --WikiTiki89 09:44, 2 February 2014 (UTC)Reply

Category:en:National symbols of Bangladesh

Latest comment: 10 years ago4 comments3 people in discussion

What possible relevance to a dictionary does this have? Mglovesfun (talk) 00:49, 15 December 2013 (UTC)Reply

I wondered that too. It's not a lexical category. We should leave the sociopolitics to Wikipedia. Delete. Equinox ◑ 16:36, 16 December 2013 (UTC)Reply
Delete. - -sche (discuss) 01:53, 26 December 2013 (UTC)Reply

Category:en:National symbols of Pakistan

Category:en:National symbols of India

There are also these two... - -sche (discuss) 01:53, 26 December 2013 (UTC)Reply

Template:ko-form of

Latest comment: 10 years ago4 comments2 people in discussion

We don't really need it anymore, we can use {{form of}}. —CodeCat 18:23, 17 December 2013 (UTC)Reply

The italicisation isn't an issue because {{form of}} only italicises the English. The bolding debatably is. Mglovesfun (talk) 12:57, 18 December 2013 (UTC)Reply
That is done by CSS, not by the template. —CodeCat 14:30, 18 December 2013 (UTC)Reply
It's bold by default though, or else why would I be seeing it as bold? Mglovesfun (talk) 15:07, 18 December 2013 (UTC)Reply

Template:place:Brazil

Latest comment: 10 years ago4 comments3 people in discussion

Tagged but not listed. I don't know what this is for, we already have {{accent:Brazil}} so it's not that. Documentation is empty too. Mglovesfun (talk) 15:05, 18 December 2013 (UTC)Reply

Apparently for {{place}} (abandoned project?). — Ungoliant (falai) 23:54, 19 December 2013 (UTC)Reply
I think it may have been created as a context label type template, so that we can distinguish terms used in Brazil from terms related to Brazil. Our current labels don't distinguish these, and place names are normally considered dialect specifiers rather than topical labels. So if we ever wanted a label to specify "when talking about (place)", we'd have to devise a workaround. —CodeCat 23:59, 19 December 2013 (UTC)Reply
The documentation says it’s for definitions of placenames. — Ungoliant (falai) 00:18, 20 December 2013 (UTC)Reply

Template:yi-conj-d

Latest comment: 10 years ago2 comments2 people in discussion

Tagged but not listed. No transclusions, perhaps replaced by updates to {{yi-conj}}? Also I object to the title yi-conj-d as Yiddish does not use the Latin letter d. Mglovesfun (talk) 15:06, 18 December 2013 (UTC)Reply

It has been replaced because it has been deemed regular (google books:"ער רעדט" gets way more hits than google books:"ער רעט", meaning the irregular spelling is much less common, to the point that it could be considered an error). Anyway, the reason I used Latin letters in the template names is because I think it is wrong to use non-ASCII characters in the name of a template. But, if you want to move all such instances to the equivalent of {{yi-conj-ד}} and have {{yi-conj-d}} be a redirect, I would not object. --WikiTiki89 15:20, 18 December 2013 (UTC)Reply

Category:Terms with alpha privatives

Latest comment: 10 years ago3 comments2 people in discussion

I think Category:English terms with alpha privatives‎ could be merged upward into this, but I'm unsure about what the new title should be. The single category could be titled Category:English terms with alpha privatives‎ or Category:Terms with alpha privatives, or if it can be demonstrated that other privatives exist in languages other than English, we could move it to Category:Terms with alpha privatives by language per this precedent. The deletion would not seem to have a very large effect on its parent categories Category:English appendices and Category:Etymology. TeleComNasSprVen (talk) 21:27, 19 December 2013 (UTC)Reply

We should use Category:English terms with alpha privatives and Category:Terms with alpha privatives by language. The former is really just a large subset of Category:English words prefixed with a-, so maybe we should put it there instead. —CodeCat 20:14, 15 January 2014 (UTC)Reply

Category:Derived terms

Same reasons. TeleComNasSprVen (talk) 23:06, 19 December 2013 (UTC)Reply

Template:appendix

Latest comment: 10 years ago1 comment1 person in discussion

"created for standardisation of appendix links" -- Guess it never gained traction. TeleComNasSprVen (talk) 21:35, 19 December 2013 (UTC)Reply

Certain geographic language families

Latest comment: 10 years ago9 comments3 people in discussion

Central American Indian (cai)

North American Indian (nai)

South American Indian (sai)

Australian Aboriginal (aus)

These are geographic groupings rather than genetic families. The codes should be deleted as groups (i.e. nothing should declare cai as its family, and the categories can be deleted). It might be worth keeping them as prefixes, however, and continuing to use them in that capacity (i.e. keep Chinookan as nai-ckn rather than renaming it qfa-ckn, and if a new North American language family is recognised, assign it the code nai-foo rather than qfa-foo). - -sche (discuss) 02:01, 20 December 2013 (UTC)Reply

I have deleted cai, nai, sai and aus but left notes explaining that they can continue to be used as prefixes in creating exceptional language codes and family codes. - -sche (discuss) 04:57, 14 January 2014 (UTC)Reply

Caucasian (cau)

Papuan (paa)

Khoisan (khi)

There's also "cau" (Caucasian), "paa" (Papuan) and "khi" (Khoisan) that have "qfa-not" as their family. —CodeCat 02:47, 20 December 2013 (UTC)Reply
Abstain on Caucasian. Keep Papuan for convenience — I realise that's not an entirely consistent or defensible position, but we even disambiguate some lects (which otherwise have the same names as other lects) by their membership in the Papuan family, so it seems worth keeping. Delete Khoisan. - -sche (discuss) 10:29, 21 December 2013 (UTC)Reply
delete all except Khoisan -- Liliana • 09:33, 21 December 2013 (UTC)Reply
Papuan and Khoisan struck as "no consensus for deletion". ("cau" not dealt with at this time because it is still in use.) - -sche (discuss) 04:57, 14 January 2014 (UTC)Reply

Kordofanian (kdo)

There's also Kordofanian, an amalgamation of some probably-Nilo-Saharan languages and some probably-Niger-Congo languages. - -sche (discuss) 09:04, 24 December 2013 (UTC)Reply

Hell no! This one should definitely be kept. -- Liliana • 09:38, 24 December 2013 (UTC)Reply
Kordofanian struck as "no consensus for deletion". - -sche (discuss) 04:57, 14 January 2014 (UTC)Reply

Template:new surname

Latest comment: 10 years ago5 comments3 people in discussion

Superseded.

"Shouldn't this now use {{surname|lang=lang}}? Mglovesfun (talk) 16:54, 29 December 2009 (UTC)"Reply

- from Template talk:new surname

TeleComNasSprVen (talk) 23:21, 20 December 2013 (UTC)Reply

It seems the documentation is wrong. This template, when substed, creates an entire language section. {{surname}} is only the definition line. --WikiTiki89 23:29, 20 December 2013 (UTC)Reply
Is there a reason to delete this that anyone can think of? Mglovesfun (talk) 22:12, 22 December 2013 (UTC)Reply

Kept TeleComNasSprVen (talk) 19:43, 29 December 2013 (UTC)Reply

Template:ja-rom

Latest comment: 10 years ago2 comments2 people in discussion

Deprecated in favor of our more standard usage of {{ja-romaji}} and {{ja-romanization of}}. On the issue of romanization, I brought up Wiktionary:Transliteration and romanization and Haplology brought up Wiktionary:About Japanese/Transliteration, and I believe that as with words we cannot control language and should go with the most commonly used words and therefore the most commonly used romanization system, which is in this case the Hepburn Romanization. TeleComNasSprVen (talk) 05:17, 22 December 2013 (UTC)Reply

Delete a thousand times over. This template was never widely used and was abandoned before I joined this wiki. Using other romanizations was brought up Wiktionary:Beer_parlour/2013/May#Japanese_Romanization and roundly rejected. I don't see much value in including obsolete and misleading romanization styles, and in fact when I see し romanized as "si" instead of "shi" or ち romanized as "ti" instead of "chi" it makes my blood pressure rise. I absolutely abhor it. It's ugly, nasty, and bad, and all it does is confuse beginners. On seeing si, one might assume that it is homophonous with English "see", but no. Every departure from our version of Hepburn romanization is like that. It subtracts from the sum total of human knowledge. Yet if anyone wants entries to make a note of such perversities then it would be relatively easy to do with Lua. In fact it might be easier because those styles are less nuanced. Haplogy (話) 01:06, 27 December 2013 (UTC)Reply

Category:en:Federally Administered Northern Areas

Latest comment: 10 years ago4 comments3 people in discussion

and Category:en:Divisions of Khyber Pakhtunkhwa, and Category:en:Dera Ismail Khan Division, Category:en:West Punjab, and all the other categories for provinces and smaller administrative units of Pakistan and India which have been created by a certain POV-pushing IP over the past year. (I'm sure someone could make a list if necessary, though it would take a while, since the categories are not all sorted into any particular place in the category tree.) Most are empty, or contain only the entry for the place the category is named for; e.g. Category:en:Dera Ismail Khan Division contains only Dera Ismail Khan Division. They're encyclopaedic categories which, on Wikipedia, serve the valuable role of gathering in one place all the articles on famous musicians, artists, etc from Dera Ismail Khan Division — on Wiktionary, they have no place. We don't have comparable categories for any other states, as far as I can tell: we don't have Category:en:New York, Category:en:Worcestershire, Category:de:Brandenburg or Category:ru:Moscow Oblast. - -sche (discuss) 01:52, 26 December 2013 (UTC)Reply

Making a list isn't that hard, since they only seem to have used three IP addresses:
here, here and here. There's overlap between the lists, and a few edits are to categories created by others. For what it's worth, I think that they've tried to tone down the POV at least a bit, but they and/or their sources are so steeped in it that they may not realize how strong their bias is. Still, they have the same fatal combination of bad judgment and prolific output that marks some of our worst headaches- though not the willful stubbornness of, say, Drago (talk • contribs) or Gtroy (talk • contribs)/Luciferwildcat (talk • contribs), or our English sub-par supernatural/anime fan. Chuck Entz (talk) 02:40, 26 December 2013 (UTC)Reply
  • In case it's not clear, I'm not suggesting that the categories are POV. A few might be (I think some categories were created for regions of Bangladesh that were named as if they were regions of Pakistan?), but the problem with the lot of them is that they are not useful to a dictionary. - -sche (discuss) 03:31, 26 December 2013 (UTC)Reply
Strong delete as not relevant or useful. Mglovesfun (talk) 21:54, 26 December 2013 (UTC)Reply

Template:str len

Latest comment: 10 years ago3 comments3 people in discussion

Template:str ≥ len

Template:str index

These have no transclusions and aren't really needed anymore because we have Lua to do this now. There's also Template:str left but that's still used on a few pages. —CodeCat 23:10, 26 December 2013 (UTC)Reply

They're also very expensive. So, yes, now that we have Lua, we should orphan and delete these templates. We should make sure User:Heyzeuss isn't still using these via subst: (as they were the last time these were RFDed), though, and make sure they know what Lua code to use to get the same effect. - -sche (discuss) 23:22, 26 December 2013 (UTC)Reply
I am not currently using any of these, even with subst. As long as there is some alternative, I have no objections. Lua looks interesting, and I suppose that I will have need of it sooner than later. ~ heyzeuss 13:33, 23 January 2014 (UTC)Reply

ber-tam

Latest comment: 10 years ago3 comments2 people in discussion
Previous discussion: Template talk:etyl:ber-tam.

For some indeterminable reason, Module:families/data includes not only a code for the Berber language family (ber) but an exceptional code for the Tamazight language family (ber-tam)... which is the same thing as the Berber language family. Therefore, I propose to delete ber-tam. There are a few entries which use it, such as argan (where there's a good chance it's actually the [Central Atlas] Tamazight language tzm, not the family, that's meant); those will need to be updated. - -sche (discuss) 10:32, 27 December 2013 (UTC)Reply

As the original creator... no objections. Mglovesfun (talk) 13:30, 27 December 2013 (UTC)Reply
Removed. - -sche (discuss) 19:36, 6 January 2014 (UTC)Reply

Module:arguments

Latest comment: 10 years ago3 comments2 people in discussion

Along with Module:math. Imported by User:Mxn for the sake of having a two-line rounding function (which does not even depend on most of this code) for his archive navigation module. I doubt we will ever need this in the dictionary proper. Not nominating Module:yesno, but we seem to have managed without it until now, so it might go as well. Keφr 14:04, 30 December 2013 (UTC)Reply

I'm inclined to say keep, but remove what we don't really need. I think it would be nice to be able to avoid the constant "if x == "" then x = nil end" on all parameters, it does get tedious. I've thought of writing a module like this before. There's also something else I've wanted to add, which is checking arguments for usage, and a global category tracking system.
Checking arguments for usage would mean that each argument that gets used by the module is marked "used", and at the end if any arguments remain unused, this adds a category or error or something like that. That would allow us to find out easily which pages are using modules with mis-typed parameter names, or parameters that aren't actually recognised or supported by the template.
Tracking categories globally would make it much easier for any module to add tracking categories and such. In templates, you can just put a category anywhere and it works, but in modules you can't do that, which is a limitation. —CodeCat 14:21, 30 December 2013 (UTC)Reply
I cannot imagine why we would ever write something that would require Module:math. It mostly wraps basic mathematical functions so that templates can use them: we would probably do most of the work inside modules, making the wrappers unnecessary.
As for Module:arguments… I am unsure what that thing actually does. Looks like some kind of input sanitisation. For now I would prefer to do it directly in the modules which receive a frame. I actually do have one idea for a module for tracking argument usage, categories and errors, but this module would not be of much help there. Keφr 18:38, 28 January 2014 (UTC)Reply

Template:protected

Latest comment: 10 years ago1 comment1 person in discussion

Imported from Wikipedia, unused. Special:ProtectedPages and a short custom message serves to replace this, so it should be deleted as unnecessary. TeleComNasSprVen (talk) 21:18, 30 December 2013 (UTC)Reply

January 2014

Template:list:territories of Asia/en

Latest comment: 10 years ago1 comment1 person in discussion

Used only in one entry, Asia, which is, needless to say, not a territory of Asia. I discovered it because of Category:en:Territories of Asia, which is added by this template.

This has only one actual transclusion, so, since it uses the resource-devouring monster innocuously named {{list helper}}, it should be substed if necessary (it seems a bit encyclopedic to me), then deleted. Chuck Entz (talk) 01:12, 5 January 2014 (UTC)Reply

Template:list:states of Austria/en

An unused list template.

Latest comment: 10 years ago4 comments2 people in discussion

This empty category would only ever have entries for German adjectives (not adjective forms) that have been created but not yet botified (the bot doesn't run every day, but quite frequently). SemperBlotto (talk) 09:56, 8 January 2014 (UTC)Reply

Why is this here? Deleted. Mglovesfun (talk) 11:51, 8 January 2014 (UTC)Reply
I've left a message on user talk. That seems to be the way to go here. Mglovesfun (talk) 11:55, 8 January 2014 (UTC)Reply
I should also have said that the contents were generated by an undocumented change to {{de-decl-adj}} that needs to be reverted. SemperBlotto (talk) 11:58, 8 January 2014 (UTC)Reply
Latest comment: 10 years ago1 comment1 person in discussion

Parent of the above. SemperBlotto (talk) 09:59, 8 January 2014 (UTC)Reply

Template:el-decl-adj-template

Latest comment: 10 years ago4 comments2 people in discussion

It actually takes more to type the template name than the text it returns, so I don't think it was created to make things easier. But then I don't know what it was for... —CodeCat 23:22, 12 January 2014 (UTC)Reply

Well actually it automates replacement of text within another template - enabling a choice of other templates! If someone can show another (easy) way of doing this please tell me. Saltmarsh (talk) 16:07, 23 January 2014 (UTC)Reply
Don't delete Saltmarsh (talk) 06:17, 3 February 2014 (UTC)Reply
Why not? —CodeCat 13:18, 3 February 2014 (UTC)Reply

Template:NOINDEX

Latest comment: 10 years ago2 comments2 people in discussion

I don't even know... —CodeCat 23:32, 12 January 2014 (UTC)Reply

Theoretically could be used as part of another template, i.e. a way of nesting __NOINDEX__ without explicitly "transcluding" (I guess you could say "calling") the magic word. TeleComNasSprVen (talk) 23:36, 12 January 2014 (UTC)Reply

Template:tr-archive-talk

Latest comment: 10 years ago2 comments1 person in discussion

Redundant to {{archived from tea room}} and confusingly conflates the {{tr}} (Turkish) langcode. TeleComNasSprVen (talk) 00:56, 13 January 2014 (UTC)Reply

Actually, {{archived from tea room}} should redirect to {{rft-archived}} now. TeleComNasSprVen (talk) 02:14, 13 January 2014 (UTC)Reply

Template:abbr

Latest comment: 10 years ago1 comment1 person in discussion

Template:c.

Template:circa3

Created last November, but never used since then it seems. —CodeCat 23:30, 13 January 2014 (UTC)Reply

Template:languageshift

Latest comment: 10 years ago1 comment1 person in discussion

This isn't needed anymore, because there is now a Lua equivalent. —CodeCat 23:22, 14 January 2014 (UTC)Reply

Latest comment: 10 years ago1 comment1 person in discussion

These were used before we had Lua to allow templates to automatically link parameters if they didn't already contain links in them. Now that we have Lua we don't really need these anymore, we can just use {{l}} or something similar. {{makelink}} has already become orphaned, {{wlink}} isn't yet but probably could be. —CodeCat 20:11, 15 January 2014 (UTC)Reply

Appendix:Latin suffixes

Latest comment: 10 years ago2 comments2 people in discussion

This doesn't add anything beyond Category:Latin suffixes. —CodeCat 18:47, 16 January 2014 (UTC)Reply

Not correct. It shows that there are some Latin inflectional endings that we have and some that we lack.

Template:metaphor

Latest comment: 10 years ago2 comments1 person in discussion

Needs unlinking to migrate to Module:labels/data, also I tried using {{context|idiomatic|metaphor|lang=en}} at other fish in the sea and neither the category Category:English metaphors nor the wikilink is popping up so we need to fix that too. TeleComNasSprVen (talk) 03:38, 17 January 2014 (UTC)Reply

Say, why do we need Category:English metaphors anyway when it's populated by only three entries? And Category:English live metaphors? TeleComNasSprVen (talk) 03:38, 17 January 2014 (UTC)Reply

Category:Idioms

Latest comment: 10 years ago1 comment1 person in discussion

Tagged but not listed. Should be at Category:Idioms by language anyway, redirecting it to English idioms doesn't even make sense. TeleComNasSprVen (talk) 03:40, 17 January 2014 (UTC)Reply

Category:Human gaits

Latest comment: 10 years ago1 comment1 person in discussion

Empty category. TeleComNasSprVen (talk) 16:21, 17 January 2014 (UTC)Reply

Category:English metaphors

Latest comment: 10 years ago3 comments2 people in discussion

Delete. This is largely superflous to Category:English idioms, IMHO. Currently has 7 entries: angels dancing on the head of a pin, bite, fox in the henhouse, god, one's marbles, piss more than one drinks, raised by wolves. --Dan Polansky (talk) 07:19, 18 January 2014 (UTC)Reply

Category:English live metaphors

I think this is also relevant, so might as well add. TeleComNasSprVen (talk) 07:49, 18 January 2014 (UTC)Reply

Delete Category:English live metaphors as well. --Dan Polansky (talk) 07:51, 18 January 2014 (UTC)Reply

{{hangulization of}}

Latest comment: 10 years ago4 comments2 people in discussion

I suggest to move {{hangulization of}} to normal {{etyl}}. Hangulization is not a very common term, Korean loanwords are no different from others, Hangeul is the only current writing system in both Koreas (with occasional Hanja) and Cyrillic based loanwords are not called "cyrillization of", we don't have arabization, katakanization, etc.

The spelling "hangul" is based on McCune–Reischauer romanisation of 한글 (hangeul) "hangŭl", the official spelling in South Korea is "hangeul", so is the more modern spelling. North Korea uses the term "Chosŏn'gŭl" - 조선글 (joseongeul). --Anatoli (обсудить/вклад) 03:59, 19 January 2014 (UTC)Reply

Yeah, but "Hangul" is by far the more common spelling in English. But either way, I agree the template should be deleted. (This is more of an WT:RFDO thing, but I personally don't really care which page the discussion is on.) --WikiTiki89 04:02, 19 January 2014 (UTC)Reply
OK, I moved the page here, since it's not simply a deletion, {{hangulization of}} should be orphaned first. --Anatoli (обсудить/вклад) 05:45, 20 January 2014 (UTC)Reply
Well it is simply a deletion. We always orphan templates before deleting them. It's not a move, because we're not moving the template. --WikiTiki89 08:24, 20 January 2014 (UTC)Reply

Template:imperative of

Latest comment: 10 years ago10 comments4 people in discussion

An old Sae1962 creation. This template is redundant to {{conjugation of|...||imp|lang=xyz}}, and it categorizes forms into "Category:Foobar imperative forms" even though no such category exists for any language (even Category:Imperative forms by language doesn't exist). It's utterly unnecessary. —Aɴɢʀ (talk) 18:13, 23 January 2014 (UTC)Reply

It's also used for Danish, Swedish and Norwegian. It's not really necessary, but then again we also have many other form-of templates, some very common like {{plural of}} or {{feminine of}}, that could also be "converted" into {{inflection of}}. So the question is really if we want to do that. —CodeCat 18:21, 23 January 2014 (UTC)Reply
Keep: Well, typing {{imperative of|keep|lang=en}} is easier or typing {{conjugation of|keep||imp|lang=en}} is easier? If they have the same function, isn't it better to type less? --kc_kennylau (talk) 09:17, 24 January 2014 (UTC)Reply
Only if the template is edited so that it doesn't automatically sort things into nonexistent and unwanted categories. Also, a large number of languages (though not English) distinguish between singular and plural imperative forms, and many also have 1st and 3rd person imperatives in addition to 2nd person imperatives, and this template doesn't accommodate any of that. It just labels things "imperative" without specifying person and number. —Aɴɢʀ (talk) 11:17, 24 January 2014 (UTC)Reply
I agree with that, but it's likely that removing the category will orphan many entries. We'd have to make sure that all of them add a part-of speech category through some other means first, like with {{plural of}}. —CodeCat 19:53, 30 January 2014 (UTC)Reply
Why don't we just have it redirect to {{conjugation of|...||imp|...}}? (I don't mean a hard redirect, but just have {{imperative of}} call {{conjugation of}}.) --WikiTiki89 16:03, 24 January 2014 (UTC)Reply
There's not much benefit in that over just having it call Module:form of directly and tell it to display "imperative". —CodeCat 16:05, 24 January 2014 (UTC)Reply
The benefit would be if we ever change how {{conjugation of}} categorizes, then we won't have to also change {{imperative of}}. --WikiTiki89 16:21, 24 January 2014 (UTC)Reply
Still doesn't solve the problem of the template's not specifying which imperative form the term is. —Aɴɢʀ (talk) 17:12, 24 January 2014 (UTC)Reply
Actually, it does solve that problem. If you do this the right way, {{imperative of}} will support any arguments that {{conjugation of}} supports. --WikiTiki89 17:26, 24 January 2014 (UTC)Reply

A list of unused and recurring templates to be deleted

Latest comment: 10 years ago1 comment1 person in discussion

Category:ltc:All topics

Category:ltc:Communication

Category:ltc:Language

Category:ltc:List of topics

All topics and List of topics contain all of the above list (excluding themselves but including one another) and Communication contains Language. Moreover, All topics and List of topics are solely recursion. --kc_kennylau (talk) 01:47, 29 January 2014 (UTC)Reply

More unused modules

Latest comment: 10 years ago4 comments3 people in discussion

Module:sh-utilities

Module:sq-utilities

Module:Stem

To my knowledge, none of these three modules are currently used anywhere. The functionality of the former two might be integrated into Module:languages/data2. Some time ago I messaged User:Xoristzatziki about the latter, it did not respond. Keφr 17:49, 30 January 2014 (UTC)Reply

Delete all three. —CodeCat 17:56, 30 January 2014 (UTC)Reply
I speedy deleted the first one as I was the only contributor there. --Z 19:45, 30 January 2014 (UTC)Reply

Redundant to Module:links; most users have been converted to use the functionality of Module:headword (which calls Module:links in turn) instead. Keφr 10:36, 1 February 2014 (UTC)Reply

February 2014

Category:Gender and number templates

Latest comment: 10 years ago3 comments2 people in discussion

And all the templates inside. They're all orphaned now, so we can delete them if there are no bots or scripts that still rely on them. —CodeCat 17:31, 2 February 2014 (UTC)Reply

{{inv}} is not orphaned. --kc_kennylau (talk) 17:35, 2 February 2014 (UTC)Reply
It is now. There were only a few transclusions, and I fixed them like this: diff. It actually passed RFD before, but I'm not sure why, when entries like that one are all it's used for. —CodeCat 19:30, 2 February 2014 (UTC)Reply
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Requests_for_deletion/Others&oldid=25462199"