text:
Wiktionary:Grease pit/2016/December

๛
The Thai symbol ๛ has a broken head-word line and label. The formatting seems fine. I think it has to do with the symbol itself. Maybe it needs to be listed in the Module:th-translit? —Stephen (Talk) 07:28, 1 December 2016 (UTC)
 * —Μετάknowledge discuss/deeds 18:01, 5 December 2016 (UTC)
 * I'm not sure why this occurs - it seems to be a problem with a generic template or module. Wyang (talk) 01:21, 8 December 2016 (UTC)

 * When I compare ๛ with ๆ (both being Thai punctuation), ๆ works correctly; but ๛ is broken in as well as.
 * If I place the following lines as the only contents of ๛, then all four templates are broken. But if I place them as the sole contents of ๆ, then all four templates work correctly.
 * ===Punctuation mark===
 * punctuation
 * ===Punctuation mark===
 * punctuation
 * And if I change the language parameters to km, then there is no problem anywhere. So the problem seems to be the symbol ๛ itself, but only if it is marked as Thai.
 * Just for grins, I looked at Module:th. I don't know anything about Lua, but the symbol ๆ appears in Module:th as "ๆ"; while the symbol ๛ appears as [ก-๛] and [^ก-๛{}%-]. Could that be the cause? I also looked in Module:th-pron, but I did not think it was the cause of the problem. —Stephen (Talk) 17:45, 13 April 2017 (UTC)
 * And if I change the language parameters to km, then there is no problem anywhere. So the problem seems to be the symbol ๛ itself, but only if it is marked as Thai.
 * Just for grins, I looked at Module:th. I don't know anything about Lua, but the symbol ๆ appears in Module:th as "ๆ"; while the symbol ๛ appears as [ก-๛] and [^ก-๛{}%-]. Could that be the cause? I also looked in Module:th-pron, but I did not think it was the cause of the problem. —Stephen (Talk) 17:45, 13 April 2017 (UTC)

Automatically generate topical labels from the categories
Not long ago, someone was wondering why there was not automatically a label X for each Category:en:X. Of course, that's because the label data and category data are entirely separate, but I am thinking they could be combined. That way, a lot of our topical label data, currently in Module:labels/data/topical, becomes redundant. Whenever a new topical category is created, you get a label that puts entries in that category, "for free". While this is kind of a proposal, I am not expecting significant opposition to this and I am asking more about the feasibility of the idea.

There are, of course, some topical categories where the label and the category name don't match, such as analysis ~ Mathematical analysis or canoeing ~ Water sports. It can be argued that in these cases, they should be made to match. In the case of "analysis", it could be aliased to "mathematical analysis", which is clearer as a label anyway. And for "canoeing", if it warrants its own context, we could consider why it doesn't have its own Category:Canoeing either.

Another point to look at is set-type categories. Membership of a set, such as "days of the week", is not grounds for a context label or similar, because that's simply not a topical context. is not used primarily when talking about days of the week. So we'll have to exclude set-type categories from the automatic process, which I suppose could be done simply by looking if the parent categories include "List of sets". —CodeCat 20:43, 1 December 2016 (UTC)
 * You're not thinking of the argument I had over the lack of, where I got absolutely nowhere? DonnanZ (talk) 22:22, 1 December 2016 (UTC)
 * That would be one of the cases that should be excluded, since "languages" is not a context. —CodeCat 22:32, 1 December 2016 (UTC)
 * I would prefer if the synonym, antonym, etc. information is subsumed under a single sense template too. Wyang (talk) 23:42, 1 December 2016 (UTC)
 * What does that have to do with this proposal? —CodeCat 00:19, 2 December 2016 (UTC)
 * Topical categories are appending properties of individual senses, so are synonyms, antonyms, etc. Wyang (talk) 00:22, 2 December 2016 (UTC)
 * But this has nothing to do with how entries are formatted. This is only about the underlying works of the label modules. —CodeCat 00:46, 2 December 2016 (UTC)

 * I like that this would more directly tie senses to categories. The display issue is my only concern, but that can be automated (maybe) or a component of the data.  I do wish there was a better way to store the label data, the current structure is awful. - TheDaveRoss 13:53, 2 December 2016 (UTC)
 * Well, this idea would mean the label data is not stored at all, but derived on the fly from the category data. At least for topical categories, anyway. What is your concern about the label data specifically? —CodeCat 02:11, 5 December 2016 (UTC)
 * It is a bummer to have to store relational data in a flat file with no way to enforce structure. It would be idea if we could connect modules to an actual SQL database of some kind, so that the data could be stored in a more robust and easily maintained format.  An example, there are a number of labels which are "deprecated," but there is no easy way to see which labels those are, or who deprecated them, or what they should be replaced with, etc.  The more labels which are available the worse that situation will get.  It isn't a design flaw, it is a platform limitation. - TheDaveRoss 14:24, 5 December 2016 (UTC)

Thai transliteration for SoP terms
It doesn't always transliterate Thai terms when there are more words separated by [ [ ] ]. What needs to happen so that คนลาว is transliterated automatically? คน and ลาว work fine separately. What are your opinions? Is it Module:links or Module:th? Hopefully you won't fight but offer a solution :) --Anatoli T. (обсудить/вклад) 02:08, 5 December 2016 (UTC)
 * Hi Anatoli, I haven't looked into this but AFAIK offers a similar output -  : . Wyang (talk) 01:14, 8 December 2016 (UTC)
 * Thanks, Frank. I know and other language specific templates work fine for this but unfortunately the other templates and templates don't. Having SoP terms with [ [ ] ]  [ [ ] ] is quite common.--Anatoli T. (обсудить/вклад) 01:53, 8 December 2016 (UTC)

"Topic labels" are now always linked, leading to bad red links
See e.g. Reingold-Tilford algorithm, where "computing theory" is a red link. I have recently seen this on other topic labels too. Has someone introduced a bug here? Equinox ◑ 14:10, 5 December 2016 (UTC)
 * Not a bug so much as a feature that needs fine tuning. You can override the link by specifying  in the data modules. —CodeCat 15:41, 5 December 2016 (UTC)
 * No, it's a bug, and I assume you did it. Where was the consensus for this change demonstrated? —Μετάknowledge discuss/deeds 17:59, 5 December 2016 (UTC)
 * I also oppose this. --WikiTiki89 18:55, 5 December 2016 (UTC)
 * Is this the edit in question? I would revert it, but I don't want to make more of a mess by accident. —Μετάknowledge discuss/deeds 19:01, 5 December 2016 (UTC)
 * No, seemingly that edit only makes the label link to the English section if it is already a link. --WikiTiki89 19:05, 5 December 2016 (UTC)
 * ✅: . --WikiTiki89 19:23, 5 December 2016 (UTC)

It seems like something went wrong, currently no topic labels are linked, even if they should be (see, e.g., dialog box). --Einstein2 (talk) 22:33, 10 December 2016 (UTC)
 * Apparently Metaknowledge considers the links a bug, so it was removed. —CodeCat 23:01, 10 December 2016 (UTC)
 * CodeCat, I find your behaviour very frustrating. I think you know that you are misrepresenting my viewpoint, and are doing so just because I disagree with the change that you made without consulting anyone else, which you have been repeatedly told by many editors in the past to stop doing. That status quo before your changes was perfectly fine. —Μετάknowledge discuss/deeds 23:18, 10 December 2016 (UTC)
 * The status quo linked labels inconsistently. With my change, entries were linked by default unless overridden not to, so that labels that needed to be linked now were. What's wrong with that? Now, all links are removed, which is a step back from the former behaviour. —CodeCat 23:23, 10 December 2016 (UTC)
 * The inconsistency was useful; it linked them where appropriate, and didn't where it wasn't — and we could modify this as we saw fit. I'm not happy with the lack of links either. The problem is that we needed to be having this conversation before your edits, and not after them. —Μετάknowledge discuss/deeds 00:33, 11 December 2016 (UTC)
 * All that has changed is that, whereas before, not linking was the default, now linking is the default. In the former case, it could be overridden by providing a linked form, in the new case it can be overridden by providing an unlinked form. So they are functionally equivalent, but because we want links on most terms, linking is a better default than not linking. —CodeCat 02:11, 11 December 2016 (UTC)

 * That would only be "all that has changed" if you had updated the existing categories to keep their link or non-link status. The sudden appearance of red links as a result of you not doing this is the problem and indeed is the title of this discussion thread. Equinox ◑ 11:43, 11 December 2016 (UTC)

 * Frankly, I would prefer if no topic labels were ever linked at all. --Dan Polansky (talk) 13:43, 11 December 2016 (UTC)

 * I think that ideally all labels should link to our appendix glossary. Linking to a main entry is a lazy temporary solution. Linking to main entries blindly when they might not even have the relevant content is a really bad solution, even worse than the redlinks. --WikiTiki89 15:10, 12 December 2016 (UTC)
 * Are you saying that even topic labels, such as Australian rules football or graphical user interface, should have their own lines at Appendix:Glossary instead of linking them to the entries and ? – Einstein2 (talk) 14:20, 13 December 2016 (UTC)
 * Hmm... that is a good a point. Linking to their Wikipedia articles would also not be bad idea. In practice your particular examples are not much of a problem only because it is very unlikely that other new senses will be added to the entries and, so those are not the ones I would prioritize fixing. Certainly for topics whose entries are polysemous or even lacking the relevant sense, it is much more important that we either link to the glossary or the Wikipedia article instead. --WikiTiki89 16:03, 13 December 2016 (UTC)

Can we improve Translation requests?
Whenever someone uses this feature we generate "From [insert source language] to [insert target language]" as the subject and "[insert text here]" as the text. Nobody ever (very slight exaggeration) changes "[insert source language]" or "[insert target language]" to actual languages, and neither do they change "[insert text here]" to actual text. Is there an easy way that we can show people what they are actually supposed to do? SemperBlotto (talk) 15:01, 5 December 2016 (UTC)
 * Oddly enough it seems to have been okay before mid-November or so. Did something change around that time? — Kleio (t · c) 15:27, 5 December 2016 (UTC)

 * It was an attempt by to improve the quality of translation requests that was a good idea, in my opinion, but ultimately a failure. I believe he announced it in the BP. —Μετάknowledge discuss/deeds 18:01, 5 December 2016 (UTC)

 * IMO, a good idea would be to have two dropdown lists, for source and target language. They start off both defaulted to "English"; if the user does not change them such that the two languages differ, the edit is blocked with an explanatory message, telling the user to choose. (No idea if we can do this.) Equinox ◑ 19:01, 5 December 2016 (UTC)

 * : The link is Beer parlour/2016/November. : That is a good idea. I would not implement the dropdown lists though. --kc_kennylau (talk) 09:48, 6 December 2016 (UTC)

 * We could instead block edits that contain the text "[insert text here]", using the abuse filters to provide an explanatory message. Equinox ◑ 14:35, 6 December 2016 (UTC)

 * I think a better idea would be to display a form when you click "Make a new request" which has a field for "Source language", "Target language", and "Text", which will automatically post a new section when submitted, but cannot be submitted unless all three fields are filled. Someone who's good at JavaScript should be able to do that. --WikiTiki89 15:25, 6 December 2016 (UTC)

I am completely unable to create a new translation request. What seems to be wrong? I even believe I filled the source and target languages correctly in the predefined spaces in the section title. --Daniel Carrero (talk) 22:24, 6 December 2016 (UTC)

 * What happens when you do it? Any error message? Equinox ◑ 17:56, 8 December 2016 (UTC)

 * : I was unable to save my new section (an English->Japanese request). An error message appeared saying that my edit was recognized as "harmful". Then I disabled the abuse filter. --Daniel Carrero (talk) 16:39, 9 December 2016 (UTC)

In-page anchors at Category:English lemmas
I would like to link directly to a section of that page (so that it scrolls down to that section automatically when somebody follows my link), but there's no table of contents with section links. Is it possible? Equinox ◑ 17:55, 8 December 2016 (UTC)

 * lists pages in the category starting from 'word'. Is that what you've looking for? —suzukaze (t・c) 02:26, 9 December 2016 (UTC)

 * No, that particular page has quite a bit of content before it gets to the regular category listings, so I'm sure he's talking about specific parts of the page itself. All I can suggest is looking at the page source/inspecting the DOM and finding the closest  (the body content is nested a number of levels in, so it may take a while if you go the inspecting route), which should work when linked to as something like Category:English_lemmas . Chuck Entz (talk) 04:24, 9 December 2016 (UTC)

 * Haha, I'm a user (here), I'm not going to "inspect a DOM". Is there any sane workaround? I can link to sections on most wiki pages, e.g. French or Noun. I am guessing the issue relates to the use of en-categoryTOC in some way...? Equinox ◑ 00:36, 14 December 2016 (UTC)

 * Well, I went ahead and looked at the source: CAT:English lemmas should get you to the Subcategories header, and CAT:English lemmas should get you to the 'Pages in category "English lemmas"' header. In most browsers it's just a matter of either right-clicking on the page body and selecting "view source" or hitting control-u if the right-clicking doesn't work, then control-f and search for "id=". Anything following "id=" in the html is an anchor you can link to. Chuck Entz (talk) 04:09, 14 December 2016 (UTC)

 * I don't really see this as a satisfactory solution because it seems less safe to rely on "internal" HTML ids staying the same than on the editable markup staying the same (all other factors being equal). But I'll use it, because it's only my stupid user page, and I appreciate you taking the time to check it out. (Another downside: apparently I have to use the absolute URI like this and not a normal wiki link that can be red or blue.) Equinox ◑ 05:05, 14 December 2016 (UTC)

Displaying Special:WhatLinksHere/ numbers
Is there a function in existence that displays the number of pages that link to a given page, in a similar way to the   function for numbers of members in categories? — I.S.M.E.T.A. 21:31, 8 December 2016 (UTC)

This question has received answers at Information desk/2016/December. — I.S.M.E.T.A. 17:45, 9 December 2016 (UTC)

Language data edit
Please add the following to : entry_name = { from = {"[āàáâǎ]", "[ēèéêě]", "[īìíîǐ]", "[ōòóôǒ]", "[ūùúûǔ]", "ḿ", "[ǹńň]", MACRON, ACUTE, GRAVE, CIRC, CARON}, to  = {"a"     , "e"      , "i"      , "o"      , "u"      , "m", "n"    }}, —CodeCat 15:22, 11 December 2016 (UTC)
 * . Also, what is the situation with hyphens like those in Zulu verbs? — JohnC5 16:45, 11 December 2016 (UTC)
 * Zulu verbs and adjectives are lemmatised with the bare stem, as is the norm in dictionaries and other reference works. The hyphen indicates that it's not a complete word. —CodeCat 16:47, 11 December 2016 (UTC)
 * But should we strip them out? — JohnC5 16:57, 11 December 2016 (UTC)
 * No, because there are genuine suffixes such as as well. —CodeCat 17:15, 11 December 2016 (UTC)
 * Roger that. — JohnC5 18:12, 11 December 2016 (UTC)

Behaviour of template:lb
Surely should behave in the same manner with all of the following parameters:
 * Using "archaic"" - places the term in "Category: … terms with archaic senses"
 * Using "obsolete"" - places the term in "Category: … terms with obsolete senses"
 * Whereas "dated"" - places the term in "Category: … dated terms"
 * why not the Category: … terms with dated senses — Salt  marsh . 12:16, 13 December 2016 (UTC)
 * I'm asking for someone to modify - or justify this (IMHO) odd behaviour —  Salt  marsh . 07:20, 14 December 2016 (UTC)

 * Probably related: Merge euphemisms and euphemistic forms. --Giorgi Eufshi (talk) 07:22, 14 December 2016 (UTC)
 * Definitely related: Category talk:English dated terms. —msh210℠ (talk) 11:46, 19 December 2016 (UTC)

Template:wikibooks
Template:wikibooks is broken. If you supply it with a language parameter  it will not spit out the correctly displayed language in the description of what Wikibooks is being linked to, unlike the equivalent Wikipedia template. -- 65.94.168.229 09:37, 15 December 2016 (UTC)

 * Is there a template that takes an Wikimedia language code (or ISO-639 language code) and displays the language name? If so, I can fix this template simply. -- 65.94.168.229 06:47, 20 December 2016 (UTC)
 * There is a module, invocation as follows: returns "English". - TheDaveRoss 14:39, 20 December 2016 (UTC)

So, the immediate problem is fixed, thanks to Dave Ross. It's still not internationalized/localized completely, as there's a cookbook parameter that only works in English, and I don't know the detailed structure of how WikiBooks operates in multiple languages -- 65.94.168.229 05:31, 21 December 2016 (UTC)

Problem with Archiver
The Archiver tool is malfunctioning – I just got the following error message (tried it twice): "Error: The parameters "pageid" and "oldid" can not be used together. [code invalidparammix]". — SMUconlaw (talk) 19:04, 16 December 2016 (UTC)
 * Me, too. Some more detail: I just tried using aWa to archive wt:RFD and got that error message. This happened both with the default (archiving to talk:bacter- and to talk:bacteri-) and also (after a reload) after I dropped talk:bacteri- from the set of targets. I'm running . Does anyone know what's going on, or a fix, please? —msh210℠ (talk) 11:43, 19 December 2016 (UTC)

 * I really don't know who is willing and able to fix this. Perhaps —Μετάknowledge discuss/deeds 18:37, 19 December 2016 (UTC)
 * Didn't Wonderfool write it? What's his current incarnation? —msh210℠ (talk) 22:02, 19 December 2016 (UTC)
 * No, it was named after him. Kephir wrote it and has long since left. I don't think WF has this kind of technical ability. —Μετάknowledge discuss/deeds 00:22, 20 December 2016 (UTC)
 * Can we file a ticket at the Phabricator? Do they work on gadgets? — SMUconlaw (talk) 14:44, 20 December 2016 (UTC)
 * For future reference, no. Basically, anything we have control over is not the developers' responsibility. The right thing to do is exactly what was done (i.e. "file" a "ticket" at the WT:GP). --WikiTiki89 16:41, 20 December 2016 (UTC)

 * . --WikiTiki89 16:35, 20 December 2016 (UTC)
 * Thanks! — SMUconlaw (talk) 18:26, 20 December 2016 (UTC)

Category:etyl cleanup/en
There are many thousands of terms in this category. What are we supposed to do with them? SemperBlotto (talk) 15:15, 17 December 2016 (UTC)
 * Something like . —Aɴɢʀ (talk) 16:49, 17 December 2016 (UTC)
 * Relatedly, is there any particular reason for which languages have their own etyl cleanup subcategories? Can I add new ones somehow? --Tropylium (talk) 17:34, 12 January 2017 (UTC)

Template:de-decl-adj-notcomp
This template produces incorrectly spelled forms. All the forms preceded by a definite or indefinite article should be capialized.

In addition, these same forms should not only be on erster and similar words. They need to be added to both erste and Erste and similar words. --Espoo (talk) 09:46, 18 December 2016 (UTC)
 * In German the capitalized forms are technically nouns. This template is however meant for the adjective forms i.e. der erste Tag not der Erste. I not sure if we should put an additional declension table for the derived nouns forms, as the only different feature would be capitalization. Matthias Buchmeier (talk) 11:16, 18 December 2016 (UTC)

Template:ISO 639
Template:ISO 639 appears to be broken The auto-generated SIL link gives a 404-not-found for any language code provided -- 65.94.168.229 05:50, 21 December 2016 (UTC)
 * Looks like SIL broke it themselves, even internal links on their site to the ISO 639 area are 404. - TheDaveRoss 12:44, 21 December 2016 (UTC)
 * I got the point. The URL www.sil.org is changed to www-01.sil.org . Looks like they are going to renovate their website. I will follow this until new version comes. --Octahedron80 (talk) 05:08, 22 December 2016 (UTC)

Module:pa-translit
This was formerly a translit module that knew just one of the scripts used by this language. User:Octahedron80 moved that module to Module:Guru-translit and replaced it with:
 * local out_text
 * if (sc == 'Guru') then
 * out_text = require('Module:Guru-translit').tr(text, lang, sc, debug_mode)
 * elseif (sc == 'Deva') then
 * out_text = require('Module:sa-translit').tr(text, lang, sc, debug_mode)
 * elseif (sc == 'Arab') then
 * --	out_text = require('Module:Arab-translit').tr(text, lang, sc, debug_mode)
 * out_text = nil
 * else
 * error('Invalid script for Punjabi language.')
 * end
 * return out_text

The problem is that this very simple-minded code doesn't use the script-detection logic in our modules, and it throws a module error in any entries that don't have a sc parameter, falsely stating that they're in the wrong script. Given that the script detection in the modules has made sc parameters basically obsolete in most languages, this is guaranteed to cause confusion and frustration for anyone unlucky enough to be adding content in Punjabi.

Can someone fix this? Thanks! Chuck Entz (talk) 04:23, 22 December 2016 (UTC)

 * The script is already auto-detection from prior module that uses this like headword, so sc input is not needed. It is really useable and the same script tr modules can share among languages. (That's we call 'module'.) Some times ago, I also did this to Module:khb-translit. None of them show error. I'd like to see which page show error. --Octahedron80 (talk) 04:31, 22 December 2016 (UTC)

 * Sorry, I forgot to add 'pa-Arab' as well. Now no error occur. Until someone make Module:pa-Arab-translit, this case is set to nil for now. --Octahedron80 (talk) 04:49, 22 December 2016 (UTC)

Template:senseid and invisible module errors
This template uses Module:languages/templates to generate a language name that's part of the text fed to. This is great most of the time, but any module errors are converted into corrupted, but invisible html. The page goes in CAT:E, but there's nothing at the page itself to show where the error is. Unless you notice that there's something wrong with the lang parameter, looking at the wikitext doesn't help much, either. Is there some way to make it possible to see the error without having to look through the html? Chuck Entz (talk) 07:24, 24 December 2016 (UTC)

Template:&lit
Can this template be made to (optionally) suppress adding to Category:English idioms? I don't think it's right but if there are oppositions, please make it optional with a parameter. --Anatoli T. (обсудить/вклад) 00:45, 28 December 2016 (UTC)
 * Did you have a specific entry in mind? DTLHS (talk) 00:46, 28 December 2016 (UTC)

 * I meant that we don't need to add to idioms category. If it's not idiomatic, it's not kept, right? For entries like freedom of speech or be silent (currently in RFD) it definitely doesn't make sense. --Anatoli T. (обсудить/вклад) 00:52, 28 December 2016 (UTC)
 * Good catch. That seems eminently sensible. DCDuring TALK 20:05, 28 December 2016 (UTC)

dump
Is there a way to get a dump of Telugu lemmas? I'm sure I've seen something in regard to this before. I need a list which I can place in User:Rajasekhar1961/Appendix:List of Telugu words. It's for the purpose of populating Index:Telugu. —Stephen (Talk) 07:41, 28 December 2016 (UTC)
 * User:DTLHS/Telugu lemmas DTLHS (talk) 16:20, 28 December 2016 (UTC)
 * Beautiful! Thanks! —Stephen (Talk) 02:57, 29 December 2016 (UTC)

derivsee in Module:compound/templates
Multiple issues with the output of the  function in the module compound/templates, which is used by  and. It doesn't apply any language styles to the word in the title (for instance, ▼ Arabic words suffixed with جي, not ▼ Arabic words suffixed with جي) and italicizes the list of words with the suffix that you get when you click the down arrow. Ideally, both the suffix and the list should display with language-specific fonts, in the same way that the list of words in Cat:Arabic words suffixed with جي does. — Eru·tuon 09:30, 28 December 2016 (UTC)
 * I'm not sure if we can fix this- we could apply a global style to the header, but it wouldn't be language specific. DTLHS (talk) 01:51, 29 December 2016 (UTC)

Smartphone app?
Anyone ever used our app? Apparently it has a lousy interface. --Derrib9 (talk) 23:44, 28 December 2016 (UTC)

Spaces needed in Lao translit for usexes with brackets
Using Module:lo-translit I need to make it work for usexes, please. E.g. has no space after the square brackets, it should insert a space, like this: "pa thēt lāo". Calling --Anatoli T. (обсудить/вклад) 01:47, 29 December 2016 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2016/December


text:
Wiktionary:Grease pit/2016/January

Template:fr-conj-auto failures
Fails on fuir, luire. Hillcrest98 (talk) 16:50, 2 January 2016 (UTC)
 * Can you take a look at this? Benwing2 (talk) 01:47, 8 January 2016 (UTC)
 * : Sure. --kc_kennylau (talk) 14:04, 11 January 2016 (UTC)
 * Thanks! Benwing2 (talk) 17:50, 11 January 2016 (UTC)

Template:frm-noun/Luacized
Could we have one last push on this, please? Everything I've tried so far with it has worked except you can't specify a second plural or a feminine (specific example: and  will no longer work). If we can fix this, it's ready to go AFAICT. Renard Migrant (talk) 18:23, 2 January 2016 (UTC)
 * I just tested this and it looks like you can specify a second plural. Can you provide a test example where you get the problem? And I'll fix the issue with the second feminine. Benwing2 (talk) 02:01, 8 January 2016 (UTC)
 * I misread what you said; I see now you meant the feminine didn't work. Fixed, along with problems with the feminine plural and some other bugs. Benwing2 (talk) 02:24, 8 January 2016 (UTC)

Lua help: "Chunk has too many syntax levels"
Please see Module:ne-conj. The code at the moment is functioning. However, if I replace it with the code in Module talk:ne-conj and preview Template:ne-conj, it will return "chunk has too many syntax levels". Please help! Thanks. Wyang (talk) 04:34, 5 January 2016 (UTC)
 * The very first result from Google saying is applicable.--Giorgi Eufshi (talk) 06:27, 5 January 2016 (UTC)
 * Thanks, solved (embarrassingly). Wyang (talk) 06:38, 5 January 2016 (UTC)

(??? please provide Mongolian spelling!) in Mongolian entries
Can a good Samaritan please remove these message from Mongolian headword templates, like, etc.? Please make it optional.
 * 1) It doesn't look nice.
 * 2) Cyrillic and traditional Mongolian don't always match. Inner Mongolian and Outer Mongolian dialects have big differences.
 * 3) We don't have active editors or available online resources to provide this info.

FYI,. --Anatoli T. (обсудить/вклад) 07:18, 6 January 2016 (UTC)

 * The idea is that any reader who comes across it and happens to know the Mongolian spelling can add it in. So in my opinion, unless there you are sure that the Mongolian spelling does not exist, the ??? should be left there. For cases in which you are indeed sure that the Mongolian spelling does not exist, we can provide an override. But again, this is only my opinion. --WikiTiki89 15:48, 6 January 2016 (UTC)

 * I understand the idea but shouting messages have always been frowned upon and were removed from Russian headwords and others. There are much more matches (and resources) between Hindi and Urdu spellings, let alone Serbo-Croatian (Cyrillic and Roman spelling) but the entries don't demand any input from users or editors - the other spelling is and should be optional. --Anatoli T. (обсудить/вклад) 22:12, 6 January 2016 (UTC)
 * They're not demanding input, they are politely asking for it. For Russian, it is less important, specifically because we have more editors and resources. For Mongolian, we have to rely on the chance that a reader who happens to know will see the request and contribute. In other words, without this request, there really is no hope. --WikiTiki89 22:24, 6 January 2016 (UTC)
 * I agree with Anatoli here — many Mongolian learners will not have any familiarity with this script anyway, and providing it should not be among our primary goals with Mongolian entries. —Μετάknowledge discuss/deeds 00:13, 7 January 2016 (UTC)
 * I am all for adding the traditional Mongolian spellings but we don't even have enough working examples, let alone reliable data. I think we'll be able to upload it in one go when we have it. --Anatoli T. (обсудить/вклад) 01:13, 7 January 2016 (UTC)
 * It is shouting and demanding and adds correct entries into Category:Mongolian terms needing attention. E.g. is a correct minimal entry. The editor doesn't need to know the Mongolian traditional script in order to create a Mongolian Cyrillic entry. It puts unnecessary stress to editors (have I done something wrong?) and discourages them, like any mandatory parameters (which are often justified). Besides, it's not visually appealing. I think I won't convince you, so maybe this thing is a matter of a vote or a minivote. There's no proof that these visual requests will add editors input. --Anatoli T. (обсудить/вклад) 00:25, 7 January 2016 (UTC)
 * After seeing that there is an exclamation point and an attention tag (with the red "!!", if you have that enabled), I will agree that it does seem to be demanding. But those can be removed, and it can be made to look much calmer. However, I am not steadfast against removing the request entirely. If you have considered all my arguments and still disagree, that is ok with me. Does look better? --WikiTiki89 00:50, 7 January 2016 (UTC)
 * For some reason I can't see the change. has the traditional Mongolian spelling  but I am not able to add it using m=. --Anatoli T. (обсудить/вклад) 01:13, 7 January 2016 (UTC)
 * It's supposed to be added (not exactly the best design, but it wasn't me who designed it). Do you still not see the change? You can at least see it at the  template itself (which is the only template I changed). --WikiTiki89 19:34, 7 January 2016 (UTC)

Thanks, I see. My opinion stands. No other language headword demands (asks) for alternative scripts in the headwords. --Anatoli T. (обсудить/вклад) 22:14, 7 January 2016 (UTC)
 * ✅. --WikiTiki89 22:33, 7 January 2016 (UTC)
 * Thanks. --Anatoli T. (обсудить/вклад) 01:51, 8 January 2016 (UTC)
 * Sorry, was on vacation for a while and just got back. We do have the resources to provide the Mongolian script. www.bolor-toli.com has all the Cyrillic to Mongolian script conversions. I've verified as many as I can and they seem reliable. The Mongolian script uses spellings that more match Classical Mongolian phonology, while the Cyrillic script uses spellings that more match modern Mongolian phonology. DerekWinters (talk) 01:54, 11 January 2016 (UTC)
 * Modern inner Mongolian words may have different etymologies, even if the words are related. So and  have different pronunciations. Outer Mongolians will render the outer Mongolian cognate as, the word not used in Mongolia (the reverse can also be true). A number of traditional Mongolian letters don't even have mappings in Cyrillic and Cyrillic letter pairs may be rendered with the same letter in traditional Mongolian, which is less phonetic. --Anatoli T. (обсудить/вклад) 02:23, 11 January 2016 (UTC)
 * Is it right to say that is, which "ulus", not "uls" as in outer Mongolian? --Anatoli T. (обсудить/вклад) 02:29, 11 January 2016 (UTC)
 * I honestly have no clue. DerekWinters (talk) 04:27, 13 January 2016 (UTC)

Template:trans-see
Can this template be improved, so that two fields have to be entered? For example at  "trans-see|instalment|installment" - otherwise it appears as "installment - see installment" which is illogical and aggravating, I think. Donnanz (talk) 13:50, 6 January 2016 (UTC)
 * Two fields can already be entered. But the idea is that "if you mean 'installment', then see the translations at 'installment'", so it is perfectly logical that they are the same. --WikiTiki89 15:51, 6 January 2016 (UTC)
 * The spellings aren't the same, that's what I'm on about - it can look rather silly. I realise that one can already enter two fields, but a lot of editors have neglected to do this, all except me it seems. After I wrote the above I came across usage in translation tables where there's more than one sense, where two fields are not necessary, so I suppose my idea is dead in the water. At least I have highlighted the problem. Donnanz (talk) 18:13, 6 January 2016 (UTC)
 * I disagree that there is a problem. I think that "installment - see installment" is the right thing to say and that "instalment - see installment" is wrong. --WikiTiki89 18:29, 6 January 2016 (UTC)
 * Well, I disagree with you, and there was absolutely no need to revert the edit. Has anyone else got an opinion? Donnanz (talk) 18:35, 6 January 2016 (UTC)
 * The way it's supposed to work is that the part before the dash clarifies which sense the see link is talking about, and the part after points to another page. "Instalment" is not defined as "instalment", that would be redundant and nonsensical. Let me give you a better example: teetan. "Teetan" is defined as "pipit", so the translation table says essentially, "for the sense "pipit", see "pipit", even though there is only one sense. --WikiTiki89 18:47, 6 January 2016 (UTC)
 * I agree with Wikitiki on this. However, in this specific case, we're dealing with an alternative form, which requires additional considerations. Should alternative forms even have translation sections? —CodeCat 18:56, 6 January 2016 (UTC)
 * Now that I think about it, they probably shouldn't. --WikiTiki89 18:58, 6 January 2016 (UTC)
 * We obviously don't share the same philosophy. The entries are for instalment and teetan respectively, not installment and pipit, and there is only one sense for both. Don't you get it?
 * As regards translation sections under alternative forms, that idea is bound to be a non-starter, and severely jumped on by some. Donnanz (talk) 19:16, 6 January 2016 (UTC)
 * Take a look at dumbledore and you will see what I'm trying to say. Yes, the entry is for "dumbledore", but that is already known by the reader. The part before the dash just disambiguates which sense is referred to. The fact that some entries only have one sense does not mean we should abandon the standard format. --WikiTiki89 19:31, 6 January 2016 (UTC)
 * Yes, it makes sense in that case. That is what I was referring to above (where two fields are not necessary). But it doesn't always make sense to stick to your "standard format" in other cases. Donnanz (talk) 19:43, 6 January 2016 (UTC)
 * I don't see how it suddenly stops making sense when there is only one sense. Yes, it may be a little redundant, but why does it not make sense? --WikiTiki89 19:52, 6 January 2016 (UTC)
 * If there were a specific idea about, for example, how to improve the wording or to clean up the translations at alternative forms (or even about new reasons to have duplicate translations), we could have a more productive discussion. Personally, I somewhat dislike the wording as it is now and so would be favorably disposed to a good alternative. DCDuring TALK 22:31, 7 January 2016 (UTC)

Duplications are much worse than having to decide where to host translations - at color or at colour. While it's not possible to keep both entries in sync, we should maintain translations at one entry. (Synonyms are also a problem for synchronising translations.) --Anatoli T. (обсудить/вклад) 04:25, 8 January 2016 (UTC)
 * Where there's different Am. and Br. spellings the translatons section usually ends up under the Am. spelling. Is that just a coincidence? But with synonyms it's probably easier to have one translations section under the more common version, unless there's a good reason for not doing so. Donnanz (talk) 16:44, 8 January 2016 (UTC)

 * I have found a baffling example where child prodigy has been shunted off to wunderkind. Why on earth? Donnanz (talk) 13:15, 12 January 2016 (UTC)
 * I agree that was probably not a good decision, but what does that have to do with the text of the template? --WikiTiki89 15:49, 12 January 2016 (UTC)
 * It's a bit off-topic and should be dicussed in the Tea Room, but I mentioned it as an example of the use of the template. Donnanz (talk) 16:48, 12 January 2016 (UTC)

Templates and modules
Is there a way to write templates into a module or even invoke modules directly in the mainspace? It seems pointless to have separate pages for templates like this one, which consists of a single line of code. Esszet (talk) 18:29, 7 January 2016 (UTC)
 * I'm not sure what you mean by "write templates into a module", can you explain? As for invoking modules directly from userspace, that can certainly be done, but it's discouraged. Preferred practice is to create a template, exactly as in this case, and in many cases it's required because of the way the module is written -- many modules look at the parent arguments, i.e. the arguments of the template invocation that called the module, and not the arguments of the module invocation itself. Benwing2 (talk) 01:45, 8 January 2016 (UTC)
 * I mean take the code from the template, put it into the module, and create the template from within the module itself. Is that possible? Esszet (talk) 03:22, 8 January 2016 (UTC)
 * If what you mean is invoking a template from a module, yes this is possible using frame:expandTemplate or frame:preprocess, although it's discouraged, probably because it's slow. Generally, preferred practice is for the modules that implement a template to provide interfaces for both template calls and calls from other modules. If you're worried about having lots of templates like, I think a better idea is to have a single interface named e.g. (or maybe just ), which takes the declension type as the first argument. (At one point I suggested an interface of this sort that auto-detected the noun class as much as this is possible, e.g. it would assume that nouns in -us are 2nd declension unless told otherwise ... although it's possible the Latin editors might prefer to have the declension always explicitly notated.) Benwing2 (talk) 05:22, 8 January 2016 (UTC)
 * It is discouraged also probably because it is nice to have "what links here" list all of the usages of the template. I also prefer one interface. --Giorgi Eufshi (talk) 06:25, 8 January 2016 (UTC)
 * You still don't get what I'm trying to say; I mean use the module to create the template. Is that possible? Esszet (talk) 14:55, 8 January 2016 (UTC)
 * Creating a template dynamically? How would you use it?--Giorgi Eufshi (talk) 16:04, 8 January 2016 (UTC)
 * I don't know exactly what you mean, but you'd use it by calling it just as you would any other template. Esszet (talk) 17:36, 8 January 2016 (UTC)
 * Sorry, I'm not sure what you mean by using a module to create a template. Can you give me an example? Do you mean to do what a user would do in creating a new template like Template:la-decl-1st? Modules can't do edits like this. Benwing2 (talk) 19:52, 8 January 2016 (UTC)
 * No, I mean:
 * taking the code  (or something similar)
 * putting it in the module
 * adding additional code to the module to create the template from there
 * Is that possible? Esszet (talk) 21:40, 8 January 2016 (UTC)
 * You can invoke template code from inside a module by calling frame:preprocess. In the case of the invoke code you quoted above, there's no need to do so because you could just call the function directly, but if there were other sorts of template code, you could potentially do this. I still don't understand what you mean by "create the template". The only way to invoke code in a module is through . You either wrap this in a template or call it directly from user code; there's no other way. Benwing2 (talk) 22:09, 8 January 2016 (UTC)
 * However, I still don't quite understand *why* you want to do this ... Benwing2 (talk) 22:10, 8 January 2016 (UTC)
 * I'm using very crude code here, but I mean something like:
 * That way, you would be able to call the template from the module as opposed to its own page, and we could thus get rid of separate pages for templates that could easily be written into modules. Esszet (talk) 00:42, 9 January 2016 (UTC)
 * I think you're misunderstanding the way the system works: at an early stage in the interpretation of the wikicode by the system, the system temporarily (or permanently, if there's a "subst:") replaces in the wikicode with the result of executing the code at template:examplexyz . Likewise, modules can only produce text, which is fed back to whatever executes the module. It's only when the system processes the wikicode for the entry after it's been modified by the templates and modules that anything shows up on the actual page. A module can't create anything by itself. It can only call existing templates and modules and then feed the resulting text to whatever called it. What you're proposing would be like a TV program creating a television to show itself on.
 * By the way, I think the reason why accessing templates from modules is discouraged is because the part of the system that executes modules has to create a simulation of the part of the system that executes templates and execute the template within that simulation, which adds layers of system overhead in terms of all kinds of system resources, not just execution time. Chuck Entz (talk) 03:40, 9 January 2016 (UTC)
 * Alright then, I guess it isn't possible. Thank you. Esszet (talk) 15:40, 9 January 2016 (UTC)
 * By the way, I think the reason why accessing templates from modules is discouraged is because the part of the system that executes modules has to create a simulation of the part of the system that executes templates and execute the template within that simulation, which adds layers of system overhead in terms of all kinds of system resources, not just execution time. Chuck Entz (talk) 03:40, 9 January 2016 (UTC)
 * Alright then, I guess it isn't possible. Thank you. Esszet (talk) 15:40, 9 January 2016 (UTC)

Confix template bug
Someone reported a sorting bug here: Feedback

I've called attention to this on the confix template page itself, but nothing seems to be happening, so I'm reporting it here as well.

"No references tag" warning
Would it be possible to turn off the "no references tag" warning ("Warning: You're trying to save page with a tag but no { | | | |etc.} for,  ,  ,   (possibly more?). It seems like this parameter indicated the scripts the entry's spelling used for categorization purposes, but this is now automatic.

Replacing  and   with   would be nice too, but the output would have to be checked against the old manual romaji; for example   straightforwardly becomes , but   becomes   (the romanization is generated from the kana, with half-width spaces in the kana stripped from the headword line's " " but converted to spaces in the romanization) —suzukaze (t・c) 03:34, 13 January 2016 (UTC)
 * This is something I might be able to do. You'd have to give me some more info here:
 * First, you want 1= stripped from, , , if it equals h, k, hk, kk, any more? What happens to the remaining numbered parameters? Do they get moved down by one (so that 2= becomes 1=, 3= becomes 2=, etc.)? What's the maximum number of numbered parameters, is it less than, say, 10 or 20?
 * As for converting hira= to 1=, what I could do for the moment is one of two things:
 * Either: Generate the romaji from the hiragana in hira=, and if it's equal to the romaji in rom=, change hira= to the proper numbered param and remove rom=. There are 3 issues here: (1) To do this I'd need to know the proper template/#invoke statement to convert hiragana to romaji. (Is it ?) (2) Should I ignore case when comparing the romaji? E.g. hira=やよい would presumably generate yayoi but for proper nouns the rom= is written Yayoi. (3) I'd also need to know what the proper numbered param is to put the hiragana into. Will it always be 1= for, , and 2= for  (assuming that I've already removed the h/k/hk/kk code), or is it more complicated? E.g. will there ever be an h/k/hk/kk code still present?
 * Or: Alternatively, I could just check if there's a space in the rom=. If so, leave things alone, otherwise, change hira= to the proper numbered param and remove rom=, as above. This depends on there not being any special cases where a single-word hiragana has an unusual romaji that needs to be left alone. To do this, I'd still need to know what the proper numbered param is to put the hiragana into, as above.

Benwing2 (talk) 18:36, 14 January 2016 (UTC)

 * Examining the old code of these templates, it seems like possible input for  was r, h, ka, k, s, ky, and kk. They don't have any effect on the template anymore, and in addition it seems like the templates ignore any pure Latin text that is given as an unnamed parameter if it isn't a recognized part of speech.
 * would become  upon removal of the old useless  . It doesn't look like ja-pos has any limits except for script execution time.
 * Romaji can be generated like this:
 * kana_to_romaji
 * I think that in most cases capitalization can be ignored, but particles (which may appear in a proper noun, I suppose) are not usually capitalized and needs manual overriding.
 * It looks like prefers  pos, but  pos (  is also fully acceptable (see the template code).
 * For and friends, all unnamed parameters (numbered parameters?) are for kana readings. It's similar for, except part of speech must be included as either   or  . —suzukaze (t・c) 06:47, 15 January 2016 (UTC)
 * Don't remove "ky"! It's still needed to show kyūjitai forms.--Anatoli T. (обсудить/вклад) 07:26, 15 January 2016 (UTC)
 * The documentation for talks about it, but 國際 (and shinjitai 浜) seems to be displaying fine without it...? :s —suzukaze (t・c) 07:30, 15 January 2016 (UTC)
 * Looking through Module:ja-headword, I can't find anywhere that pays attention to a first parameter with a value of ky. Benwing2 (talk) 07:42, 15 January 2016 (UTC)
 * I think I will have to expose the function  in Module:ja-headword to properly know whether it's safe to remove romaji.
 * I think what I will do when converting hira= to a numbered parameter is to put the hira= value after any existing numbered parameters rather than replacing any of them, in case there are existing kana values. It looks like that should work fine.
 * If I end up leaving the romaji, is it OK to still convert hira= to a numbered parameter? I think this should be fine from looking at the code, but I can't tell for sure. Benwing2 (talk) 07:53, 15 January 2016 (UTC)
 * i don't know what that means, i don't know much about lua/normal coding. whatever works...
 * As in → ? ←It works, but in my opinion it looks odd.
 * 天叢雲剣 has  and it works fine.
 * —suzukaze (t・c) 08:10, 15 January 2016 (UTC)
 * Sorry for not updating the documenation... The templates ignore s and ky. Module:ja (used by all ja- templates) displays the term as shinjitai if the   named parameter is set and kyūjitai if the   parameter is set.  Unless something has been altered recently, all of the templates ignore anything that is not kanji or kana, including h,ka,k,kk,r,s, or ky.  The current situation is exactly the same as if they were all removed tomorrow.  The templates also ignore which choice of   or   is used: the user can make a mistake like  and it will be displayed correctly (this happens sometimes.) Therefore   and   could also be removed with no visible change.
 * Sorry for not updating the documenation... The templates ignore s and ky. Module:ja (used by all ja- templates) displays the term as shinjitai if the   named parameter is set and kyūjitai if the   parameter is set.  Unless something has been altered recently, all of the templates ignore anything that is not kanji or kana, including h,ka,k,kk,r,s, or ky.  The current situation is exactly the same as if they were all removed tomorrow.  The templates also ignore which choice of   or   is used: the user can make a mistake like  and it will be displayed correctly (this happens sometimes.) Therefore   and   could also be removed with no visible change.

 * The manual Latin transliterations or romaji could be replaced with automatic transliterations (the code for romanizing Japanese kana is in Module:ja) with the exceptions of these: Category:Japanese terms with romaji needing attention, but those could also be replaced if the kana were tweaked. You could set the template to ignore   stuff and nothing would change except for the terms in that category. --Haplogy (話) 08:12, 15 January 2016 (UTC)
 * As for #2, no, it would be . After removing the k parameter, there would be no numbered parameters left, so the hira= value would end up in parameter 1. Benwing2 (talk) 08:17, 15 January 2016 (UTC)
 * The original sentence confused me >_< —suzukaze (t・c) 08:24, 15 January 2016 (UTC)
 * Thanks! This definitely helps. So you're saying that I can safely remove rom= unless the page is in Category:Japanese terms with romaji needing attention? That would probably avoid the need to expose and call  in Module:ja-headword. Benwing2 (talk) 08:20, 15 January 2016 (UTC)

Apologies, I meant "kyu", not "ky". Try removing "|kyu=" from and 中國 is not displayed any more. Equally, "shin=" is needed on kyūjitai entries. --Anatoli T. (обсудить/вклад) 08:45, 15 January 2016 (UTC)
 * FORM is staying; what will be removed is  (as in this diff). —suzukaze (t・c) 08:58, 15 January 2016 (UTC)
 * The code is written and I did a small testing run. Can you look at Special:Contributions/WingerBot around 00:51 and 00:52 UTC time on January 16 and check out the changes to see if they look OK? Benwing2 (talk) 00:54, 16 January 2016 (UTC)
 * It looks great! It also reminded me that  is also useless and can be safely removed. (I see this parameter so infrequently that I've forgotten about its existence...) It used to be for category sort keys, which is also now fully automatic. —suzukaze (t・c) 20:23, 16 January 2016 (UTC)
 * The run should be done in a couple of hours or so. Hopefully nothing got messed up. Benwing2 (talk) 12:15, 17 January 2016 (UTC)

Translation Adder Language-Code Errors
Could someone figure out a way to add language-code checking to the translation adder so it doesn't spew module-error text into the translation sections if someone uses a bad language code? Chuck Entz (talk) 14:36, 14 January 2016 (UTC)

Year in Usenet citations showing up as 2016
I found a number of Wiktionary entries that cite Usenet posts apparently from this year. These pages (e.g. fandumb), when calling quote-newsgroup, specify both "year" and "date", with "date" set to something like "11 May", which does not include the year. A change by affected the way this is handled by converting the template to a wrapper around quote-web. Now the "year" argument ("2003") is ignored, and the "date" argument is passed through the  parser function. PHP assumes the date is in the current year, so "2016 May 11" shows up instead of "2003 11 May".

The same change removed the "group" alias for the "newsgroup" parameter, so the Usenet citations on grouse are also broken in another way.

Could these issues be fixed? PleaseStand (talk) 16:13, 14 January 2016 (UTC)

 * OK, let me look into it. Smuconlaw (talk) 16:15, 14 January 2016 (UTC)
 * I think the problem has been fixed. You may need to reload the pages to see the changes take effect. Thanks for pointing the issues out. Smuconlaw (talk) 17:30, 14 January 2016 (UTC)
 * Thanks. I took a look at your fix and may have found a small problem. Right now, the current year (2016) is a leap year. Because only the "date" argument is passed through  when converting it to Y-m-d format, PHP would assume the date is in the current year, so next year (2017), "February 29" would become "March 1". One simple way I can think of to handle this is to add a space, then the year, to the date before parsing it, so both "29 February [2000]" and "February 29 [2000]" would work. However, I have not tested this, particularly with pages that actually specify a full date in some format along with the year (e.g. bright shiny object). There would also still be pages with broken, unparsable dates (e.g. Citations:batpoop). PleaseStand (talk) 19:02, 16 January 2016 (UTC)
 * I'll have another look at the template. However, I don't think it can be expected to deal with situations where editors provide the parameters with unexpected values such as in the examples you provide (bright shiny object – both year and full date provided; Citations:batpoop – en dash inserted into date). These will just have to be manually corrected. Smuconlaw (talk) 21:23, 16 January 2016 (UTC)
 * Tried your suggested fix; it seems to work. Thanks. Smuconlaw (talk) 21:29, 16 January 2016 (UTC)

Multiline usage examples (typically quotations)
Is there any way to format multiline usage examples without doing so manually? I can't see how to do this using or. (If it matters, this is for Russian, where translit needs to be supported.) Benwing2 (talk) 05:40, 15 January 2016 (UTC)

--Giorgi Eufshi (talk) 06:35, 15 January 2016 (UTC)

 * Thanks! That seems to work fine. Benwing2 (talk) 07:45, 15 January 2016 (UTC)

 * You can also use <br> :

 * - -sche (discuss) 02:09, 17 January 2016 (UTC)
 * Thanks. Benwing2 (talk) 02:12, 17 January 2016 (UTC)
 * Thanks. Benwing2 (talk) 02:12, 17 January 2016 (UTC)

Template:standard spelling of
On, specifying both British and UK both display 'Britain', leading to the rather stupid looking Britain standard spelling of. Renard Migrant (talk) 16:13, 16 January 2016 (UTC)

 * For spellings (cases like this), the labels "British spelling" and "American spelling" and "Canadian spelling" should be used: = . The difference in appearance also happens if you use these labels in  (or  before it):  = . (Note that "Britain" and "British spelling" also link to two different Wikipedia articles.) It would be nice if the template could interpret "Britain" or "British" or "UK" in the from= field the same as "British spelling", but I don't know if that's technically feasible. - -sche (discuss) 02:03, 17 January 2016 (UTC)

Renaming of "cite meta" to "quote-meta"
I have been working on bringing some coherence to the and  templates. Essentially, the former are now for citing references in "Reference" sections and on talk pages, whereas the latter are for quotations in dictionary entries. I would like to propose that, which is used by many of the templates, be renamed  for consistency. Smuconlaw (talk) 18:18, 16 January 2016 (UTC)
 * Good idea. Thanks for sorting out our messy and messily named cite-/quote- templates. If no-one raises substantive objections or boldly moves this template, ping me in a few days and I'll move it. - -sche (discuss) 02:07, 17 January 2016 (UTC)
 * Great! Will do. Smuconlaw (talk) 16:57, 17 January 2016 (UTC)
 * I've moved it, leaving a redirect so that existing uses (in 24 templates) still work. - -sche (discuss) 03:25, 21 January 2016 (UTC)
 * OK, thanks. I'll be changing those existing uses as well. Smuconlaw (talk) 06:05, 21 January 2016 (UTC)

Parameter on Template:usex
There are many entries that provide this parameter now showing up as module errors. However, the original module code (before I made any changes) did not implement this parameter. So it's a no-op. Should it just be removed from these entries? —CodeCat 15:00, 17 January 2016 (UTC)
 * Hmm, is the parameter useful? If so maybe it should be implemented. Benwing2 (talk) 20:33, 17 January 2016 (UTC)
 * No, it's not useful. DTLHS (talk) 20:46, 17 January 2016 (UTC)

lit= param to, new template ?
A couple of ideas, what do people think?

Benwing2 (talk) 20:35, 17 January 2016 (UTC)
 * 1) Adding a lit= param to  to specify the literal meaning. I'm surprised this isn't there already.
 * 2) Creating a  template that is the same as  but has inline=y auto-specified; that parameter is too long. (Or alternatively I suppose we could supply i= as an alias.)
 * Both seem nice. Enosh (talk) 20:45, 17 January 2016 (UTC)
 * I still think it would be better to reduce the need for, by making the module choose it automatically based on the length of the text. —CodeCat 21:01, 17 January 2016 (UTC)
 * I agree, but how do we do this? Benwing2 (talk) 21:14, 17 January 2016 (UTC)
 * We just need to decide on a threshold length. If the usex is longer, inline is turned off, otherwise it's on. —CodeCat 21:20, 17 January 2016 (UTC)
 * I think we ran into this issue before ... ideally, it should never do inline if on a cell phone, and otherwise it should depend on the size of the browser window. There's the  CSS directive that's supposed to be used for this ... unfortunately I'm not a CSS wizard so I don't quite know whether this can be inserted into an inline CSS directive and more generally how exactly to structure this for Wiktionary but I imagine it should be possible. Benwing2 (talk) 22:50, 17 January 2016 (UTC)
 * BTW could you implement the lit= param when you have a chance? There are a bunch of Russian usage examples where it would come in very handy. Benwing2 (talk) 22:54, 17 January 2016 (UTC)

 * This should only be done if it is possible to do it with CSS. This should not be done by counting characters or anything silly like that, since character counts cannot predict the display size. --WikiTiki89 16:40, 18 January 2016 (UTC)
 * Here's another idea for : A sub parameter that allows for (non-displayed) phonetic substitutions prior to transliteration. The idea is to phonetically respell words that have irregular pronunciations, so that their transliteration shows up correctly without the need to manually transliterate the entire expression--especially useful for long quotations and such. I implemented this for Russian, where it takes the form FROM/TO,FROM/TO,... where FROM and TO are as in Lua patterns (but will usually be fixed strings); but I imagine it would be useful for Yiddish (e.g. to respell Hebrew words), Arabic (e.g. to specify places where -ة is pronounced /t/) and other languages where automatic transliteration is possible but there are exceptions. Benwing2 (talk) 22:37, 18 January 2016 (UTC)
 * I've been thinking about that myself for Yiddish and it never occurred to me that it should be generalized, but I guess there's nothing wrong with that. One problem is that it won't solve everything. For example מקדש spells both "mekadesh" and "mikdesh", and could be used within the same usex. I'm sure the same can happen with Russian, and especially with Arabic. But such cases are probably fairly rare overall. --WikiTiki89 00:15, 19 January 2016 (UTC)
 * The lit parameter was causing module errors in two places at a, so I temporarily added it to the list in Module:usex/templates of parameters for Module:parameters to ignore. I'm not sure if that will interfere with anything- if it does, you know where to find it. Chuck Entz (talk) 06:29, 21 January 2016 (UTC)

Vietnamese nouns without classifiers
Category:Vietnamese nouns without classifiers is a useful category for nouns having classifiers, however, not all nouns do have classifiers (aka measure words, counters). E.g.:

The first noun ếch needs a classifier but not the second one bệnh viện (most if not all Sino-Vietnamese nouns don't require classifiers). Such nouns could use a different parameter, e.g. "cls=-", which could add them to a different (unhidden) category to separate nouns, which don't have classifiers because nobody added them from those, which don't need them. , do you think it would be useful. What should be the name of the category? --Anatoli T. (обсудить/вклад) 23:09, 17 January 2016 (UTC)

Code from thin air.
drepen asks for a documentation subpage in the entry. It's template Template:gml-conj-st2a is a 1:1 copy of Template:gml-conj-st1 whose test entry riden does not ask for a documentation subpage. Help. Korn [kʰʊ̃ːæ̯̃n] (talk) 00:09, 18 January 2016 (UTC)
 * Fixed both. —CodeCat 00:54, 18 January 2016 (UTC)
 * But the error at drepen seems to remain. Korn [kʰʊ̃ːæ̯̃n] (talk) 01:08, 18 January 2016 (UTC)
 * I did a null edit, and it went away. Chuck Entz (talk) 01:23, 18 January 2016 (UTC)

Module errors on the vote box
The vote box currently has 2 module errors. I won't be able to fix them right now because I'm at my new job and I'll be busy for a few hours. :)

Reasons:
 * Unsigned vote at Votes/2015-11/term → m; context → label; usex → ux by User:DCDuring.
 * Unsigned line starting with # at Votes/pl-2015-12/Translations by User:DCDuring. (signed in the line below)

In both cases I'm not blaming User:DCDuring, the vote box should behave gracefully even in those events. I'll fix the vote box to accept these things later when I have the time. --Daniel Carrero (talk) 19:39, 16 January 2016 (UTC)
 * I fixed the issue with unsigned votes, although the code in question should also be defensive about properly formatted links (e.g. a link with a colon but no vertical bar may cause issues). Benwing2 (talk) 19:58, 16 January 2016 (UTC)
 * In one case I forgot to sign. My bad.
 * In the other case I signed after a multi-paragraph explanation of my vote, which put a couple of newlines between the template and the signature. Is that a bug or a feature? Even if it is a bug, is it worth fixing? DCDuring TALK 20:01, 16 January 2016 (UTC)
 * This is a bug, as far as I'm concerned. At the moment, people don't have the ability to sign only after a multi-paragraph vote and have their vote counted in the vote box. People have to sign in the same line they start with a single, as you have noticed.
 * But I don't think it could get fixed so easily. Consider this mock vote:
 * Proposal: Rewrite Wiktionary completely in Morse code.
 * Vote:
 * I want to use Wiktionary on my telegraph, Foo made her case and convinced me.
 * You guys should listen to her, too. --Bar (talk) 00:00, 1 January 2016 (UTC)
 * The problem is that the module looks for the last user link in the vote line. The actual voter linked to another user, so the module would interpret this as a vote by the linked user. I'm not really sure how to fix this, maybe looking for the "(UTC)" in the end. --Daniel Carrero (talk) 02:16, 17 January 2016 (UTC)
 * You can paper over the problem with a few extra words on the vote instructions. Not ideal, but good enough. DCDuring TALK 02:49, 17 January 2016 (UTC)
 * I think what you said is the only available option, really. Here's another flaw in the logic that would probably happen if we tried to fix the code. Suppose the first voter forgot to sign the vote and somebody else responded to him.
 * Proposal: Add translation tables in all foreign-language entries.
 * Vote:
 * And remove translation tables from English entries, too.
 * You shouldn't say that, that's going too far. --Voice of reason (talk) 00:00, 1 January 2016 (UTC)
 * If the module recognized the unsigned vote line and looked for a signature in the next lines, then the module would interpret this as a vote by the user who replied to the actual voter. --Daniel Carrero (talk) 03:24, 17 January 2016 (UTC)
 * This is WT:GP material. --WikiTiki89 16:29, 18 January 2016 (UTC)
 * Moved it from WT:BP. --Daniel Carrero (talk) 17:21, 18 January 2016 (UTC)

Section header strangeness
For some reason, when I load pavus, the edit links next to the section headers are not surrounded by angle brackets and are the same size as the section text. Does this happen to anyone else, and if so, why does it happen and does it happen on any other page? — JohnC5 20:46, 18 January 2016 (UTC)
 * I have been noticing this as well. It seems to have been some kind of wikitext processing glitch that confused the mobile interface with the desktop interface, which has since been fixed but left residue in the cache. To fix these pages, just purge or null edit them. Disclaimer: my explanation is pure speculation. --WikiTiki89 20:50, 18 January 2016 (UTC)
 * Yep, that worked. Weird. Sometimes I imagine what it would be like if we hard purged all of Wiktionary at once. That would be very exciting. — JohnC5 20:55, 18 January 2016 (UTC)
 * It was happening intermittently to me before; I've noticed that the link structure of the edit links are reminiscent of the VisualEditor (!?), but nothing happens when you click on the links, probably because the VisualEditor isn't enabled... —suzukaze (t・c) 20:56, 18 January 2016 (UTC)
 * It's been happening to me today too. —Aɴɢʀ (talk) 21:40, 18 January 2016 (UTC)
 * Ah, so this wasn't just me. Andrew Sheedy (talk) 00:46, 21 January 2016 (UTC)
 * It's happening again today. Andrew Sheedy (talk) 02:21, 2 February 2016 (UTC)

Merging 'Place names old' and 'Module:category tree/topic cat/data/Place names'
Is there any plan to merge Module:category tree/topic cat/data/Place names and Module:category tree/topic cat/data/Place names old? --KoreanQuoter (talk) 12:31, 19 January 2016 (UTC)

Template:pi-noun
The template needs a parameter for a second gender, such as for the noun. --Lo Ximiendo (talk) 23:41, 22 January 2016 (UTC)
 * Done. --kc_kennylau (talk) 12:51, 23 January 2016 (UTC)
 * Now it seems to place all Pali noun entries into the category for Pali nouns in Latin script, as I noticed from editing . (Also, what just happened to ?) --Lo Ximiendo (talk) 21:50, 4 February 2016 (UTC)

and simplified Chinese forms
The abuse filter  prevents changing entries to the simplified format (since it has no L3 headers) and messy things must be done. It's problematic. Can an exception be made if is present? —suzukaze (t・c) 05:15, 23 January 2016 (UTC)
 * Yes, please. Anonymous users can't create or edit Chinese simplified form entries.--Anatoli T. (обсудить/вклад) 05:20, 23 January 2016 (UTC)
 * A related vote on the structure of Chinese simplified entries: Votes/pl-2014-12/Making simplified Chinese soft-redirect to traditional Chinese --Anatoli T. (обсудить/вклад) 10:23, 23 January 2016 (UTC)
 * Well yes, here's the text of the vote: "Making simplified Chinese soft-redirect to traditional Chinese. Thus, hosting definitions and other content in traditional Chinese entries, and no longer in simplified Chinese entries." Assuming that the vote passed (which by my lights it did not), the vote does not stipulate that soft-links are the miniature markups that we now see in Chinese simplified entries. --Dan Polansky (talk) 10:37, 23 January 2016 (UTC)
 * The Beer Parlour discussion linked to in the vote seems to once have featured example entries that use, such as User:Wyang/历史. It looks like voters knew fully well what they were voting for. —suzukaze (t・c) 22:56, 23 January 2016 (UTC)

Maybe it's time simplified Chinese entries start honoring our proven practices, along the lines of the vote Votes/pl-2013-03/Romanization and definition line. Format like the following does not fit the results of the vote:

Chinese
Yes, the vote was about Japanese romanization entries, but one would guess the voters would also support that Chinese entries follow the standard format. --Dan Polansky (talk) 09:41, 23 January 2016 (UTC)
 * One would guess, but Chinese isn't as similar to Japanese as one would expect. Simplified forms aren't romanizations; compare and . Besides, I believe the Chinese entry layout has been voted on already (correct me if I'm wrong). —Aryamanarora (मुझसे बात करो) 00:28, 2 February 2016 (UTC)

Special:UncategorizedPages finds almost entirely categorized pages
That's about it, really. 209 results as of 10:51, 22 January 2016, but almost all of them categorized. It used to be a really useful tool to find broken formatting, now it's almost unusable. There are probably about 20 uncategorized pages in there, but which ones? And why is this happening? Renard Migrant (talk) 11:55, 26 January 2016 (UTC)
 * I am not certain, but I think it has to do with the fact that they were created through the API and never "touched" which allowed them to fall through the categorization cracks. - TheDaveRoss 14:12, 26 January 2016 (UTC)
 * I don't think this is a real-time list.
 * The first three that I looked at were created on January 23. I suspect that the master list of category-entry associations was created before then, but the list is created as a subtraction of entries with such associations from all entries as of January 26. The hypothesis could be tested by inspecting a list of pre-January-26, post-January 23 new entries to see whether they are on the page in question. DCDuring TALK 15:19, 26 January 2016 (UTC)
 * The ones I looked at were mostly created before the listed cache date. - TheDaveRoss 15:23, 26 January 2016 (UTC)
 * What is the API? Renard Migrant (talk) 15:43, 26 January 2016 (UTC)
 * The API is the interface which bots (and any other methods which are not using the Mediawiki interface) use to interact with the database. Here is a lot of information about it. - TheDaveRoss 15:55, 26 January 2016 (UTC)
 * Any item on any cached special page must have been around before the time of the caching. I was wondering whether the process of list creation had latency delays. On further inspection I could show my hypothesis to be mostly wrong. I didn't find many latency delays based on my limited inspection. I did find that many of the entries on the list show 0 wikilinks, which probably has something to do with the means the bots used to create the entries (API?). Those entries also did not appear on Special:NewPages. The bot-created entries were mostly Russian and French. The other entries seem to be on the list by reason of not having an inflection line template. But some entries defy my explanations, such as Bakuninist. DCDuring TALK 15:47, 26 January 2016 (UTC)

Broken links to Species and Commons
The links to Wikspecies and WikiCommons aren't working. Attempts to reach either by urlname don't seem to be working. Any information on why? DCDuring TALK 19:09, 26 January 2016 (UTC)
 * Thanks for reporting this. There are multiple issues which are currently being investigated by the Operations team of the WMF. The corresponding bug report is T124804. --AKlapper (WMF) (talk) 19:29, 26 January 2016 (UTC)
 * Thanks for monitoring this page. I don't have enough reason to try to get the hang of IRC. DCDuring TALK 20:24, 26 January 2016 (UTC)

Searching in Greek script
Can someone make it so that when you search in the Greek script, accented and unaccented characters show up in each other's results? (Like we have in Latin script.) For example, if I see a Greek word written in Latin as "pethainw" and I search "πεθαινω", there are zero results or hints that would point me to the correct word, "πεθαίνω", which is only an accent mark away. Ultimateria (talk) 19:46, 26 January 2016 (UTC)
 * I think that this should be reported on Phabricator as a feature request for CirrusSearch. —suzukaze (t・c) 19:48, 26 January 2016 (UTC)

 * (e/c) Unfortunately, this is something only the devs can do. We've already requested it in the past at least for Cyrillic, but no luck. Maybe if enough people complain to them... --WikiTiki89 19:50, 26 January 2016 (UTC)

 * Here is an old related bug if you would like to roll it into your new one: Devanagari and Arabic combining character handling - TheDaveRoss 21:24, 26 January 2016 (UTC)
 * Similar issues exist for Cyrillic with accented vowels too, although the accents are generally separate combining characters in that case. If you search for unaccented Cyrillic, it will not find any accented Cyrillic on the same page. This is actually a much bigger problem since the major Cyrillic languages are generally not written with accents, unlike Greek. —CodeCat 21:27, 26 January 2016 (UTC)
 * I think we should complain a lot more vigorously about this one. Otherwise it makes the whole foreign-language component of enwikt much harder to use. Benwing2 (talk) 22:35, 26 January 2016 (UTC)
 * Yes, fully agree. This has been bugging me, for Russian searches should include words spelled with е and ё. It also applies to Arabic words with and without diacritics, Hindi words with and without nuqta and "chandra". --Anatoli T. (обсудить/вклад) 23:56, 26 January 2016 (UTC)
 * Oops, I just realised that this is about my old complaint. --Anatoli T. (обсудить/вклад) 23:58, 26 January 2016 (UTC)

Categorize or track alternative forms of redlinks
We already track at least some instances of "form of"-type templates linking to a redlink, e.g. Category:Plurals with a red link for singular. If it wouldn't be too "expensive", I think it would be useful to also track cases where something is defined as an alternative form of a redlink: e.g. praedaturus currently defines itself as an "Alternative form of praeurus", which is currently a redlink. It seems like every case would need attention, either to create the linked-to entry or to clean up the linking entry. It could also be useful to track inflected forms ("third person singular", etc) of redlinks. - -sche (discuss) 03:56, 27 January 2016 (UTC)
 * Good idea, and I don't think this is too expensive to do. Benwing2 (talk) 05:46, 27 January 2016 (UTC)
 * It should probably be done with all form-of templates, shouldn't it? —CodeCat 22:31, 4 February 2016 (UTC)
 * Yup, I agree. Renard Migrant (talk) 22:32, 4 February 2016 (UTC)
 * Yes. It would be especially good (but not absolutely necessary) if we could figure out how to stop entries like Appendix:Proto-Algonquian/mehɬali from going in the category, or at least if we could put non-NS:0 pages into a separate subcategory. - -sche (discuss) 22:48, 4 February 2016 (UTC)
 * Can't this be done from the dump rather than in near-real time? Then it imposes no cost on the servers, except for the download. DCDuring TALK 00:47, 5 February 2016 (UTC)

Minor cosmetic bug in watchlist
In the watchlist, pages with new changes are highlighted in bold. Recently I've noticed that the bold formatting is removed when I click an item (i.e. it suddenly goes "unbold"). Since I often middle-click, to open pages in separate tabs, this can be a bit disconcerting. Bug? Equinox ◑ 17:03, 27 January 2016 (UTC)
 * I think this was intended to be a feature, not a bug (since after clicking, it's no longer a new change). But I too find it very annoying and would like this feature removed. --WikiTiki89 18:52, 27 January 2016 (UTC)
 * Yeah, it's bad for usability because it unexpectedly changes the size of a click target. Equinox ◑ 18:58, 27 January 2016 (UTC)

Alternative title for entry with forbidden character?
I want to create an entry for C|N>K (computing slang for "coffee through nose to keyboard", i.e. laughing hard at a posted message); cf. snark, splork. The pipe character | cannot be used in page titles. What should I call the entry? Equinox ◑ 23:19, 28 January 2016 (UTC)
 * Probably this: Unsupported titles/C vertical line N greater than K. (short link: C|N>K)
 * Compare: Unsupported titles/Vertical line and Unsupported titles/Greater than. --Daniel Carrero (talk) 23:27, 28 January 2016 (UTC)

 * I don't really like that: "greater than" is not what the sign means here. Perhaps "C through N to K" is better. But I still don't get how to do it. How do I give the page its proper display title, since I can't put | inside the template? And how do I make display it properly? Equinox ◑ 23:33, 28 January 2016 (UTC)

 * Create the page with the descriptive title starting with Unsupported titles/, like in the examples we discussed. I don't mind if you use Unsupported titles/C through N to K.
 * You can use, I tested it.  generates the | usable in templates.
 * Edit Template:unsupported imitating the entries already there. They are redirects from the normal form (C|N>K) to the descriptive entry name (C through N to K). I suggest setting up "CNK" as a usable shortcut. If you do this, then later people can use which would be the same as C|N>K.
 * Edit MediaWiki:Common.js, look for the list that starts with "Left_curly_bracket" and add the new entry there. This changes the displayed entry title. Clean your cache (Ctrl+F5 or whatever) to see the results.
 * Also list the new entry in Appendix:Unsupported titles.
 * --Daniel Carrero (talk) 23:54, 28 January 2016 (UTC)
 * Done steps 1 and 2. Did not understand step 3 so stopped there. Equinox ◑ 23:59, 28 January 2016 (UTC)
 * I'll explain. See this line from Template:unsupported:
 * |.|period|full stop = Unsupported titles/Full stop
 * It means that people are able to use ".", "period" and "full stop", yielding the same result: a link for the right page, with the right title.
 * So you can add a line like this:
 * |CNK|C|N>K|C through N to K| = Unsupported titles/C through N to K
 * This would make these three template calls work:
 * --Daniel Carrero (talk) 00:08, 29 January 2016 (UTC)
 * |CNK|C|N>K|C through N to K| = Unsupported titles/C through N to K
 * This would make these three template calls work:
 * --Daniel Carrero (talk) 00:08, 29 January 2016 (UTC)
 * --Daniel Carrero (talk) 00:08, 29 January 2016 (UTC)
 * --Daniel Carrero (talk) 00:08, 29 January 2016 (UTC)
 * --Daniel Carrero (talk) 00:08, 29 January 2016 (UTC)

 * Coo. I never thought I'd see an uglier programming language than mIRC script! Equinox ◑ 00:18, 29 January 2016 (UTC)
 * LOL. That should probably be Luaziced at some point. --Daniel Carrero (talk) 00:30, 29 January 2016 (UTC)
 * It would be faster too. Large switches are rather slow, I remember that from the pre-Lua days. —CodeCat 00:39, 29 January 2016 (UTC)
 * I've been trying, but I cannot get unsupportedpage to actually display C|N>K as the title of the page. Any ideas? —Aɴɢʀ (talk) 16:36, 29 January 2016 (UTC)
 * ✅. I used MediaWiki:Common.js as explained above. is just a , it does not appear to be able to change page titles anywhere. --Daniel Carrero (talk) 16:50, 29 January 2016 (UTC)
 * In that case, it's unfortunate that its documentation says, "The effect is to change the displayed header on the page". —Aɴɢʀ (talk) 16:52, 29 January 2016 (UTC)
 * You're right. That template should probably be orphaned+deleted, but I don't have much time to look into it carefully right now. For the moment, I edited the documentation to remove false information. --Daniel Carrero (talk) 17:10, 29 January 2016 (UTC)

polish noun head template
i don't know if i'm missing something, but it seems like the template:pl-noun doesn't have a parameter to display a plural form, like the english entries do. if the layout policies say that foreign language entries shouldn't have such an option, please correct me, but i think it would be beneficial (at least a little bit). that said, i'm not really skilled in writing templates, only some simple wikipedia ones, so should we decide that it will be implemented, someone will have to do it properly.

profesjonalizm • reply 06:35, 30 January 2016 (UTC)
 * : I think it is not there because it can be found in the declension tables. --kc_kennylau (talk) 07:23, 30 January 2016 (UTC)
 * : ok, you're right, thanks for the info profesjonalizm • reply 09:47, 30 January 2016 (UTC)
 * For Russian, we include gen sg and nom pl in the headword line (as well as gender and animacy); that's done because these two forms help relatively experienced speakers figure out the rest of the declension. Perhaps for Polish the gender and animacy is enough; one of the main things the gen sg and nom pl help with is pinpointing the accent pattern, which doesn't really have an equivalent in Polish. The nom pl also helps with the many nouns that have irregular nominative plurals; perhaps such nouns aren't so common in Polish? (I don't know Polish so I can't say.) Note that Russian entries also come with a full declension table. Perhaps some additional forms should be added to the Polish noun headwords? Benwing2 (talk) 06:59, 1 February 2016 (UTC)
 * I have been experimenting in a few languages with a different format, in which the inflection table doesn't fully collapse but shows only the principal parts. It's currently used for Dutch, Finnish, Northern Sami and a few more Finnic languages. —CodeCat 22:26, 4 February 2016 (UTC)
 * I've even been planning to use CodeCat's new format for Yiddish adjective declension tables. --WikiTiki89 01:14, 5 February 2016 (UTC)

title: Wiktionary:Grease pit/2016/January