text:
banānu

Noun

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

title: banānu


text:
micromachinery

Noun

 * 1) micromachines generally

title: micromachinery


text: игу хэкӏын

title: игу хэкӏын


text: banānam

title: banānam


text:
五等爵位

Proper noun

 * 1) the five ranks of Chinese aristocracy under the Zhou dynasty.

title: 五等爵位


text:
Wiktionary:Grease pit/2015/January

Right-to-left problem
Somehow Uyghur transliteration is skewed on Happy_New_Year (note the position of brackets) but no problem here: Uyghur:. --Anatoli T. (обсудить/вклад) 07:19, 1 January 2015 (UTC)
 * There was a right to left mark (U+200F) in the template- please make sure I fixed it correctly. DTLHS (talk) 16:54, 1 January 2015 (UTC)
 * Now I'm wondering if there's any context in which U+200E / U+200F in page text would be appropriate- can we just bot remove all occurrences? DTLHS (talk) 17:09, 1 January 2015 (UTC)
 * Thanks. The ocurrence would be appropriate if a translation into a RTL language had no transliteration or other Roman letters, such as gender, qualifiers, etc. E.g. see two identical translations into Persian without transliterations: دریا, فانوس. They now appear in the right order - LTR. --Anatoli T. (обсудить/вклад) 00:10, 2 January 2015 (UTC)

 * Todo/Pages containing LTR marks, Todo/Pages containing RTL marks, if anyone wants to help clean up the ones that don't need the LTR/RTL marks. - -sche (discuss) 18:20, 21 January 2015 (UTC)

Simplifying Catboiler Templates For Editors
I do a lot of category creation, and, though it's less arcane and complex now that User:CodeCat has luafied most of the infrastructure, there's still a lot of typing involved.

This is mostly unnecessary: we already have very strictly-enforced rigid constraints on the format of category names, and they generally contain most or all of the information needed in the name itself- so the modules that power the templates should be able to parse it from the page name using the modules that CodeCat has put in place (see Category:Pagename-based auto-fill-in templates for some templates that provide a substitutable front end for existing templates using such techniques).

Here are my ideas with regards to specific templates:

 * For language-specific cats, the first part of the name is the language code, followed by a colon, followed by the topic name. For the non-language-specific parent categories, the page name is the topic name. See, which was developed for me by User:Kc kennylau and User:Wyang. I found Wyang's version more useful and robust, so I modified it slightly to get
 * Implementation:
 * 1) If the name contains a colon:
 * 2) the language code is everything before the colon
 * 3) the topic name is everything after the colon
 * 4) If the name contains no colon, the language code is empty and the topic name is the page name
 * Problems:
 * 1) When the language code is "sms", the string "sms:" is converted to " sms&#58; " (apparently by the Lua string-function backend), and the colon isn't recognized.
 * 2) Any topic name containing a colon will cause parsing of the non-language-specific parent category to fail.

 * the first part of the page name is the canonical name of the language, followed by " words prefixed with ", followed by the suffix, followed by "-".
 * Implementation:
 * 1) the canonical language name is everything before " words prefixed with "
 * 2) the prefix is everything after " words prefixed with ", minus the "-" at the end

 * the first part of the page name is the canonical name of the language, followed by " words suffixed with -", followed by the suffix.
 * Implementation:
 * 1) the canonical language name is everything before " words suffixed with -"
 * 2) the suffix is everything after " words suffixed with -"

 * the page name is always the canonical language name, followed by " terms spelled with " followed by the character.
 * Implementation:
 * 1) the canonical language name is everything before " terms spelled with "
 * 2) the character is everything after " terms spelled with "
 * Note: As far as I know, there's no way to parse the sort parameter from the page name, so those would still have to be entered by hand where necessary.

These methods can be applied to just about every template that uses Module:category tree, with one important exception (below), and quite a few others.

 * the language-specific categories all consist of the canonical language name, followed by a space, followed by what currently goes in the template's second parameter.

This one is trickier to implement, because there's no unique delimiting text, and because of the potential for overlap between parts of language names and parts of the second parameters.

I came up with a kludgy workaround: require a single parameter consisting of the first few characters of the current second parameter. Everything before the first instance of a space + this string in the page name is the canonical language name, and the string + everything after the first instance of a space + the string in the page name is the current second parameter.

This workaround is potentially defeatable by new canonical language names that would contain a match for the string as originally entered, so it's probably best not implemented in itself, but in a substitutable fill-in template. I have a working proof-of-concept at, but I don't understand substitution and/or templates in general well enough to make it substitutable without a lot of clueless trial and error. Can someone do that for me?

Thanks! Chuck Entz (talk) 21:13, 1 January 2015 (UTC)
 * I think it would be more workable, at least in the short term, to provide only the language code. The module can then determine that everything else must be the label. I would rather not make things too dependent on "delimiters" because my goal for the long term was to integrate and company into . I believe that it's beneficial to have less templates, so that users don't have to remember which one does which. —CodeCat 21:18, 1 January 2015 (UTC)
 * Using the language code certainly looks like the only workable way to adapt itself, and may someday cause problems with converting other templates to, but I'm talking about the real short term here: I suspect that all the specific examples I gave here could be implemented in an hour by someone who really knows what they're doing (troubleshooting could drag that out much longer, of course). Since no one currently uses these templates without parameters, there's no problem with backwards-compatibility: you can either ignore any positional parameters, or you can use them instead of the pagename-based ones if they're present (the latter is probably better, just to be safe- see the problem with "sms:" in the  section, above). Chuck Entz (talk) 22:05, 1 January 2015 (UTC)
 * As for the philosophical issue: it's true that the proliferation of catboiler templates was a serious problem. I'm sure someone would eventually have come up with "rfquoteoldestylecatboiler" which would render quote-request categories for earlier authors in appropriate fonts to stylistically match their era, or "trreqsundaycatboiler" for translations requested on a specific day of the week. Reducing the number of templates is a worthwhile goal, but it needs to be kept in the context of the overall demand on the editor. It's nice not to have to remember 57 different catboilers, but it's also nice not to have to have to look up the language code- especially for the <canonical language name> terms derived from <language name or language family name> categories, which often have redlinks to more obscure language-family categories. Chuck Entz (talk) 22:35, 1 January 2015 (UTC)
 * I've added this to now (see the edits I made to Module:category tree and Module:category tree/poscatboiler). If you leave out the label, it will try to extract it from the page name. If the category doesn't begin with the specified language, or if the autodetected label doesn't exist, it shows a somewhat nondescript error message, but at least the basic idea works. —CodeCat 14:12, 2 January 2015 (UTC)
 * Very nice! If you create a new category that has multiple redlinks in the breadcrumbs, it's now possible to copy the wikitext from the first unchanged into all the redlinked categories with just a few clicks and keystrokes. The error handling is definitely a problem, though. Perhaps you could compare the expanded language code with the beginning of the page name and give a message along the lines of "The language code XX is for the language YYYY, which doesn't match the category name".Chuck Entz (talk) 18:18, 2 January 2015 (UTC)

missing important and common words
What kind of software solutions exist and which are we using to ensure we know which of the most common words are missing? I was very surprised to discover that, for example, news stream is completely missing in this and all other dictionaries. So Wiktionary has the chance to be the first dictionary to record one of the most important and common and descriptive words of our time. I found several lists like User:Brian0918/Hotlist and User:Robert Ullmann/Missing and User:Visviva/Tracking, but these don't seem to make any kind of frequency analysis. I don't understand what to do with the red links at the beginning of the last list. --Espoo (talk) 11:32, 7 January 2015 (UTC)
 * Those red links were part of Visviva's semi-automated system of generating new subpages for recent newspaper editions. No longer in use, but I come back to the existing subpages from time to time and try to complete them. I delete them when they are complete. SemperBlotto (talk) 10:03, 8 January 2015 (UTC)
 * p.s. I've attempted an entry for - feel free to improve. SemperBlotto (talk) 10:08, 8 January 2015 (UTC)

"hu-conjugation of" in verb form category
How do we change the template so that it isn't in Category:Hungarian verb forms but puts verb forms there? --Lo Ximiendo (talk) 15:02, 7 January 2015 (UTC)
 * Fixed. You have to put the category call inside the "includeonly" part and not inside the "noinclude" part. —Aɴɢʀ (talk) 15:11, 7 January 2015 (UTC)
 * but you should have taken a look at the list in Category:Hungarian verb forms and seen the template there. Besides, I wish got rewritten into Lua. --Lo Ximiendo (talk) 15:16, 7 January 2015 (UTC)
 * Hmm, I don't know why that's happening. It would be good for the template to be luacized, but that wasn't the problem you brought up. —Aɴɢʀ (talk) 15:22, 7 January 2015 (UTC)
 * I disagree with making add entries to the category. The category is already added by the headword template. —CodeCat 15:24, 7 January 2015 (UTC)
 * was created several years ago before the current categorization direction. There is no need to recreate the template in Lua. It could be replaced by applying the parameters needed for Hungarian. For example: vadászok
 * would become
 * . --Panda10 (talk) 17:39, 7 January 2015 (UTC)
 * I've added most of the grammar tags from to Module:form of/data. But there was a conflict in one case:   is already used to mean subjunctive, so it can't also mean sublative. Furthermore, the following tags shouldn't be added to the module, so some solution for them should be found: ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  . I'm not sure what to do with   and  . It also needs to be checked if any pages use  with a tag that it doesn't recognise (in which case it's shown as-is) but which  does recognise. —CodeCat 18:52, 7 January 2015 (UTC)
 * Ok, thanks. Those parameters are used by . This would be more complicated to replace (it is used in about 19,000 entries). In my above note I meant to replace only with  because it is used in a little over 200 entries. --Panda10 (talk) 19:41, 7 January 2015 (UTC)
 * now just calls . You can replace it if you want. —CodeCat 22:34, 7 January 2015 (UTC)
 * Thanks. Is it feasible to semi-automate the creation of Hungarian verb forms? Similar to the noun forms. It is very convenient to create a noun form entry just by clicking the declension table cell. --Panda10 (talk) 22:38, 7 January 2015 (UTC)
 * The biggest limitations of WT:ACCEL are that it only works for red links, and it can only create entries for one form at a time. So when the same form is actually several distinct forms that just happen to be identical, then it doesn't work either. This is likely a problem for verbs, which have a lot more forms than nouns do and so there is more risk of one form appearing more than once in the table. In theory, the table module (it would have to be a module; it's not feasible with a template alone) could be modified to alter the acceleration tags it puts in the links, so that WT:ACCEL is told that the entry is for multiple forms. But that would make it a lot more complicated as well. —CodeCat 22:54, 7 January 2015 (UTC)
 * Ok, it will just stay as is. However, the changes you made in the templates created a problem in the possessive forms, e.g. ablaka - the definition line contains a category name in wikilinks. It also emptied the Category:Hungarian noun forms - possessive. Can you reverse this? I appreciate your help but I really don't want more problems, it will be just too overwhelming for me to correct them. --Panda10 (talk) 00:25, 8 January 2015 (UTC)
 * I just removed the category for now. Having a category for every single kind of inflected form is just overkill, as I have mentioned before in other discussions. —CodeCat 00:29, 8 January 2015 (UTC)

Fonts
Why do the Navajo, pinyin and romaji words need to be written in those ugly and different fonts? --Biolongvistul (talk) 13:11, 8 January 2015 (UTC)
 * For Pinyin and Romaji, it happens when the software assumes that the word is being written in Hanzi/Kanji even though it really isn't: if I write  it shows up as  because it assumes that everything labeled "zh" is in Hanzi, so it uses a font that's better suited to Hanzi. I would have expected   to force it to show up using the default Latin font, but it doesn't; it still shows up as, which is annoying. (Interestingly, if I specify the language as "cmn" instead of "zh", Pinyin shows up using the default Latin font, even without being explicitly labeled "sc=Latn", so   shows up as .) For Navajo, I have no idea since Navajo is only written in the Latin alphabet, so the software shouldn't be assuming anything else. —Aɴɢʀ (talk) 20:59, 9 January 2015 (UTC)
 * If I remember correctly, that font was chosen for Navajo to accommodate its many diacritics, assuming that our standard fonts can't. can shed some light. --Vahag (talk) 00:36, 10 January 2015 (UTC)
 * That is correct. Navajo uses diacritics on some letters that are spaced incorrectly in regular Roman fonts, so we use the Aboriginal Sans Serif. —Stephen (Talk) 09:57, 10 January 2015 (UTC)

Confix template
There is a problem with this template where listings for the suffix don't appear in the correct alphabetical order, when there's a root word as well as a prefix. For example:. Donnanz (talk) 12:36, 9 January 2015 (UTC)
 * I don't see it, can you elaborate? —CodeCat 13:57, 9 January 2015 (UTC)
 * You can see it in the listings, in between prioritization and privatisation. (https://en.wiktionary.org/wiki/Category:English_words_suffixed_with_-ation) Donnanz (talk) 14:06, 9 January 2015 (UTC)
 * It looks like the module is stripping the prefix from the sort key for the prefix category and using this prefix-stripped sort key for the suffix category, too, where it should be using the whole word. Chuck Entz (talk) 17:19, 9 January 2015 (UTC)
 * I have found a workaround for repristination by altering it to {prefix|re|pristine|lang=en} {suffix||ation|lang=en} (doubled brackets shown as single). But the problem still remains for the unwary. Donnanz (talk) 21:28, 9 January 2015 (UTC)
 * Does it work if you use ? —CodeCat 21:36, 9 January 2015 (UTC)
 * Yes, that works OK. Donnanz (talk) 22:02, 9 January 2015 (UTC)
 * Please don't apply that workaround to lots of entries! We should fix confix rather than propagating hacks. Equinox ◑ 21:38, 9 January 2015 (UTC)
 * Hopefully there's not a lot of entries like this. Donnanz (talk) 22:02, 9 January 2015 (UTC)
 * I think confix only works properly when a prefix is linked to a suffix with no word in between. Donnanz (talk) 10:03, 10 January 2015 (UTC)
 * I commented on exactly the same problem at Template talk:confix. This really needs to be fixed. --Mormegil (talk) 11:26, 12 March 2015 (UTC)
 * Yeah, I have found it better to use the affix template (as mentioned by CodeCat above) in certain cases. The affix template is a relatively recent creation. Donnanz (talk) 11:38, 12 March 2015 (UTC)

Can anyone fix the tagging of the "Appendix" namespace, please?
See discussion here: http://sourceforge.net/p/kiwix/discussion/604122/thread/1eacb6d8/

Thank you.

No comments? :(
 * Could you state exactly what you are seeking and why? Generally speaking, only parts of Appendix namespace have content that meets minimum standards IMO. Separating the wheat from the chaff will take some time if contributors are willing to undertake the task. DCDuring TALK 15:17, 15 January 2015 (UTC)
 * We really need a separate namespace for reconstructions. —CodeCat 15:42, 15 January 2015 (UTC)
 * Maybe, but the link above is to a discussion about Appendix:Japanese verbs. I rather doubt that reconstructions are tops on the list of Appendix content that linkers seek. DCDuring TALK 16:01, 15 January 2015 (UTC)

Bot Request
Would someone with a bot please be so kind as to perform null edits on all the entries in Category:Pages with module errors? With over 2100 entries from a problem that was quickly fixed a day or two ago, the real module errors are very hard to spot (see błyskać for the one I know about). Thanks! Chuck Entz (talk) 19:47, 9 January 2015 (UTC)
 * I'm running it now. It's not actually performing null edits though, just hard purges. It's faster that way. —CodeCat 21:37, 9 January 2015 (UTC)
 * Thank you! It was fun watching the member count dropping rapidly every time I refreshed the page. I see that the problem with the Polish entries has been fixed, (the Chinese ones seem to have beenfixed earlier), and the pt-adj monstrosity has been dealt with, so we now have an empty category for the first time in what seems like a month or more. I can handle the new ones that will straggle in from the edit queue, but I gave up on these after clearing about 1,500 of them (what can I say- I'm stubborn!). Chuck Entz (talk) 22:17, 9 January 2015 (UTC)
 * Making a bot that does null edits is very easy. If you want, I can give you some Python code that does it? You'll need the Pywikibot package. You probably don't need a bot account as null edits aren't really edits, nothing is actually changed. —CodeCat 22:19, 9 January 2015 (UTC)

Template for variant spellings.
I would like to create a template that creates a collapsable table, replaces input strings according to a specific key and logs every single replacement. An example: The input of the template is "a, d, e". Each of these letters has two results according to the key, the alternatives being "ä, ð, 0". I would want to log the variants "ade", "aðe", "äde", "äðe", "ad", "äd", "að", "äð" in an annotated table. Basically an automated form-table like the one that can be seen at enmity. I tried to figure it out myself through the help pages, but they all seem to be for people who already know to some extent how it all works. For example I could find no help pages on Wiktionary on how to create a table that is collapsable. So if anyone could give me a link to a help page with the relevant formatting data and explain to me how to include a string-replacement into a template, I'd be grateful. Korn (talk) 10:08, 10 January 2015 (UTC) ps.: I'm aware the WT-templates page has a section giving the code to make a table collapsable. But what I meant is that if you've no prior Wiki-experience, making your baby steps here is at least a bit confusing. Korn (talk) 10:31, 10 January 2015 (UTC)
 * If I understand you correctly you would like to create a table for variant spellings without regard to whether they were actually attestable or sourced from a reference like the OED. That would be something we wouldn't want in entries. We already have some handmade tables like that which are not useful. The table at enmity might be useful, but the plethora of redlinks suggests that we haven't collected evidence and are relying exclusively on the OED. DCDuring TALK 11:09, 10 January 2015 (UTC)
 * Well, I was primarily intending to use it for IPA to translate the basic structure of a word into all the narrow transcriptions for different dialects for Middle Low German. Though, in modern Low German, 99% of words in almost all but one or two varieties are indeed not attestable, because people use German for written communication. And people use a pronunciation spelling for writing, so it could be used in that area as well.Korn (talk) 13:07, 10 January 2015 (UTC)

I triggered a spam filter?
I just tried to edit my userpage with a short introduction saying who I am and that I'm an admin and CU over at en.wikibooks. It seemed to have triggered a spam filter, I think. Can someone add this to my userpage?
 * I am an administrator and check user at English Wikibooks. I'm not very active at English Wiktionary.

Thanks. --Xania (talk) 23:14, 12 January 2015 (UTC)
 * ✅. — Ungoliant (falai) 23:18, 12 January 2015 (UTC)
 * For future reference, I believe the filter was triggered because you had few contributions and were adding an external link; because your target was another WMF site, you could have avoided the filter by using a link of the form English Wikibooks . Cheers, - -sche (discuss) 23:58, 12 January 2015 (UTC)
 * Thanks. I had thought that a WMF URL would have been exempt but I'd forgotten that I could have used a shortcut instead.--Xania (talk) 00:12, 13 January 2015 (UTC)

Module:Alternative forms
In e.g. indogermanisch, the name of the "dialect" to which the alt forms belong (in this case the qualifier is not a dialect but an explanation that the alt forms are abbreviations) should be in parentheses, like it would be if [//en.wiktionary.org/w/index.php?title=indogermanisch&diff=32045895&oldid=32045858 the old method of formatting] were used. - -sche (discuss) 01:46, 13 January 2015 (UTC)
 * Bump. - -sche (discuss) 20:26, 19 January 2015 (UTC)
 * See this discussion. --Vahag (talk) 10:42, 26 January 2015 (UTC)
 * Why are the forms listed in a different font face? —Aɴɢʀ (talk) 20:39, 19 January 2015 (UTC)

Template question
Hello,

I'm new to the Mediawiki markup language. I've already read several help pages about templates.

According to m:Help:Parameter_default, outputs "p", if "p" is defined. Otherwise "q".

I still don't get a particular syntax: gives c gives c - parameter b is undefined Can someone explain to me, why the result is "c"? In both examples, "a" might be defined?

 * The assumption in the examples is that there are no defined parameters.
 * is interpreted as
 * is parameter a defined?
 * Yes: return the contents of parameter a.
 * No: is parameter b defined?
 * Yes: return the contents of parameter b
 * No: return the literal string "c".
 * is interpreted as
 * is parameter a defined?
 * Yes: return the contents of parameter a
 * No: return the literal string "b"
 * what was just returned will now be interpreted as a parameter name, being either what was in a, or "b". Assuming that there are no defined parameters, this will be "b", so...
 * is parameter b defined?
 * Yes: return the contents of parameter b
 * No: return the literal string "c"
 * No: return the literal string "c"

I'm also struggeling with an expression like this one: If I understand the syntax correctly, the output will be "XXX" if any one the three variables "A", "B" or "C" is defined. Otherwise (if none of these variables are defined) "YYY" will be the output. Is my assumption correct?

 * Almost.
 * So #if has three elements: the truth statement, the return value if true, and the return value if false.
 * If the parameter A is defined, its contents will be returned as the truth statement. If it isn't defined, then parameter B will be evaluated. If it isn't defined, C. If that isn't defined either, then the empty string "" will be returned.
 * The truth value is then determined. Simply: if the return value is undefined or an empty string, then it evaluates as false, otherwise as true.
 * So if all of the parameters are undefined, the result of the #if statement will be "YYY". It will also be "YYY" if the contents of the first defined parameter in A, B, or C, is the empty string (that is, if it is called from an invocation like .) So you can force it to output a negative result, even if B and C are defined.
 * If you don't put a default value in an expansion, and the parameter is not defined, then the result will be the string unexpanded.
 * So if you have with no parameters defined, the result will be, which is, C is not defined, so the result is  , which is a valid string, which is what is passed back as the result. This is not an empty string, so it evaluates as true, and the result of  (that is, with no default for the C parameter) will be "XXX"

 * Have I confused you utterly? --Catsidhe (verba, facta) 12:09, 13 January 2015 (UTC)

 * Hello Catsidhe, thanks for your fast and extensive response! ;))) Thanks!
 * Just for clarity: works the same way  does?
 * I also learned, that a defined (but empty) parameter affects the logic flow. Until now I assumed, that empty values were input errors by user, but now I rescind that statement.
 * I think I've been way off with my interpretation of
 * I lost you at "(that is, with no default for the C parameter) will be "XXX"":
 * First you said, that if the variables A,B are not defined, the output will depend on the value of C. If C isn't defined either, the empty string will be returned and "YYY" will be the output.
 * On the other hand, you said that will be evaluated to  and that is not an empty string, independent of whether C is defined or not. Thus "XXX" will follow.
 * This is the point where I am confused. Lets assume C has no default value and no value is given for C, where the template is called. Will "XXX" or "YYY" follow?
 * Citronas (talk) 13:27, 13 January 2015 (UTC)
 * Recall that  means if x is defined, return " ", otherwise, return " ". So look at the evaluation step-by-step:
 * " " is what we start with. Is parameter A defined?
 * Yes? Then it becomes " ".
 * No? Then it becomes " ". Is parameter B defined?
 * Yes? Then it becomes " ".
 * No? Then it becomes " ". Is parameter C defined?
 * Yes? Then it becomes " ".
 * No? Then it becomes " " (empty string).
 * I hope this helps. —CodeCat 13:42, 13 January 2015 (UTC)
 * I hope this helps. —CodeCat 13:42, 13 January 2015 (UTC)

 * It's more like  evaluates to the contents of the parameter C, if it is defined. If it is not defined, then it evaluates to the string "  ". The   says that if C is not defined, then return the string "a".   says that if C is not defined, then return the empty string. I was contrasting the behaviour of   and  . With the alternate value of the empty string, the whole construction will return the empty string if none of the parameters are defined, and the empty string has the truth value "false". Without that pipe character, if none of the parameters are defined, it will return the string "  ", which has the truth value "true".
 * and  do not work the same. If a is defined, then the first will return the value of a. Else if b is defined it will return the value of b, else it will return the string "c". The second will first evaluate whether a is defined, and return either that value or the string "b", and then use that string (either a or "b") and see whether that is a defined parameter. If it is, it will return the contents of that parameter, otherwise it will return "c". So if the contents of a is "z", it will evaluate , which will return "z", which then becomes  . If parameter z is defined, then that value will be returned.
 * --Catsidhe (verba, facta) 19:49, 13 January 2015 (UTC)
 * I finally got it ;) Thanks Catsidhe and CodeCat!! I wasn't aware of the difference between  and  . I should have asked here earlier, instead of guessing for 2 weeks straight =) Citronas (talk) 10:10, 14 January 2015 (UTC)

Template:eo-head
Template:eo-head seems to be displaying noun and adjective inflections slightly differently: for adjectives, it presents them in the order "plural, accusative singular, accusative plural" (e.g., aĝa), whereas for nouns, it presents them in the order "accusative singular, plural, accusative plural" (e.g., ŝnuro). I think it is desirable to have the inflections presented in the same order for both adjectives and nouns, so I would appreciate it if someone could change Template:eo-head so that it uses the order "plural, accusative singular, accusative plural" for both parts of speech. This is the order that Template:eo-noun and Template:eo-adj both use. Thank you! —Mr. Granger (talk • contribs) 00:02, 16 January 2015 (UTC)
 * I think that putting the accusative singular first makes more sense, because the accusative plural is derived from the nominative plural. And what happens for nouns with no plural? With the ordering you propose, you would end up with the accusative singular changing positions because the plural before it disappears. It looks neater if the plural is just taken off the end instead. Furthermore, we already put singular cases before nominative plural in the headword lines of Russian and Slovene, and probably other languages too. —CodeCat 00:07, 16 January 2015 (UTC)
 * That's fine with me. I just want all three templates to use the same order for both parts of speech. —Mr. Granger (talk • contribs) 00:30, 16 January 2015 (UTC)
 * I think it's fixed now. —CodeCat 00:59, 16 January 2015 (UTC)
 * Thanks! —Mr. Granger (talk • contribs) 01:05, 16 January 2015 (UTC)

parameter id= has stopped working
The parameter id=, used in and  for linking to -generated targets, has stopped working. See for example in the etymology of. Please fix it. --Vahag (talk) 11:25, 18 January 2015 (UTC)
 * It works now.  wasn't broken, it was just being ignored for Appendix pages because we don't need to link to language sections. But we do need to be able to link to ids, so I changed that now. —CodeCat 12:37, 18 January 2015 (UTC)
 * I see, thanks. --Vahag (talk) 15:17, 18 January 2015 (UTC)

Category:Hungarian uncountable nouns - incorrect content
The above category is suddenly collecting suffixes, proper nouns, pronouns and noun forms. Any idea what may be the cause? Thanks. --Panda10 (talk) 19:28, 19 January 2015 (UTC)
 * They have a noun declension template with n=sg. You need some way to distinguish between declensions of nouns and other parts of speech in the template. DTLHS (talk) 19:33, 19 January 2015 (UTC)
 * Thanks! --Panda10 (talk) 20:04, 19 January 2015 (UTC)
 * I believe this problem is coming from the new Module:hu-nominals. Is there a way to correct it? --Panda10 (talk) 20:04, 19 January 2015 (UTC)
 * I've removed the category for now, but I'm confused what's wrong with showing proper nouns there. They are nouns after all. —CodeCat 20:44, 19 January 2015 (UTC)
 * Ok, thanks for the correction. The nominal inflection module is probably not the best way to do this type of categorization since we are using it for nouns, adjectives, numerals, pronouns, and even suffixes. I will add the category when needed using other methods. --Panda10 (talk) 21:01, 19 January 2015 (UTC)
 * I used the modules from other languages as a base when making it, so there were some remnants like that. —CodeCat 21:15, 19 January 2015 (UTC)

Tamil transliteration rules are incomplete
In அஃகம், you can see that a couple letters (namely ஃக) aren't transliterated. I presume this should be addressed. - -sche (discuss) 20:26, 19 January 2015 (UTC)
 * pls help if you can. --Anatoli T. (обсудить/вклад) 01:17, 20 January 2015 (UTC)
 * I think it should be "aḥkam". It's visarga + ka . --Anatoli T. (обсудить/вклад) 01:22, 20 January 2015 (UTC)
 * My didn't work in Module:ta-translit. --Anatoli T. (обсудить/вклад) 01:25, 20 January 2015 (UTC)

Redlinks by language
Is it possible to acquire a list of words wanted in a given language? That is, pages with a redlink encased in a template such as   leading to them?

As far as I can tell this is not possible within MediaWiki software, but it sounds like information extractable from a database dump perhaps. --Tropylium (talk) 14:38, 20 January 2015 (UTC)
 * It would be possible, but difficult. But much easier would be to find those enclosed in, , as all of these have a language parameter, position 1 for  and , lang= for . How are your skills with regular expressions? DCDuring TALK  15:50, 20 January 2015 (UTC)
 * For l and m this should be OK (in Python):

r"" #gives two groups: langcode and word.
 * As for term, as it can have kinda difficult expression I would first transform term's into l's or m's like this:

from r"" into r"l|\3\1\2\4"
 * P.S. I think regex will have hard time working on that huge file though.
 * --Dixtosa (talk) 18:11, 20 January 2015 (UTC)
 * I run a Perl script every month that extracts and counts instances taxa enclosed in (on 11K pages). It runs in less than 30 seconds, but virtually all instances are red links, so it doesn't have to compare the list of all terms enclosed in  (on 362K pages) and  (on 42K pages) with a list of all headwords, let alone a list of all entries in a given language. In addition all terms enclosed in  are Translingual lemmas.
 * There are also templates such as (223K pages) (Compare  (10K pages).) that enclose words from only a single language. IOW, it would be easy to generate, for example, l|es-, m|es-, and l/es- linked words in Spanish. I think they are supposed to all be lemmas. Subtracting members of Category:Spanish lemmas shouldn't be too hard. DCDuring TALK  19:47, 20 January 2015 (UTC)
 * I wouldn't assume that all terms linked with and  (and l/XX templates) are lemmas. There are all sorts of times when nonlemma forms might find themselves inside those templates. —Aɴɢʀ (talk) 20:39, 20 January 2015 (UTC)
 * If they mostly are, the exercise would still probably be worth it. But it would probably be worthwhile to subtract all entries in a given language, rather than just all lemmas. In any event the remaining entries would still have to be looked at one at a time for purposes of actually adding new L2 sections or new pages DCDuring TALK 22:04, 20 January 2015 (UTC)
 * "Take all links with a language code, subtract all existing entries" is the obvious brute force option, sure. I'm wondering more if it is possible to speed things up a bit: first acquire a list of redlinks in the main namespace, then retrieve the referring wikicode(s) for each? --Tropylium (talk) 11:12, 21 January 2015 (UTC)

 * We have Category:Terms having red links in their inflection table by language already, which works with various templates. Examples of such templates are Template:es-adj and Template:ast-noun. --Walled brick (talk) 11:25, 21 January 2015 (UTC)

Weirdness at これは何ですか
This module error wasn't here a couple of days ago, but the entry's edit history doesn't show anything since January 11, and when I look at "Templates used in this section:" for the section that has the error, none of the templates listed has any edits in the past week:

 * Template:ja-phrase last edit July 27, 2014 (my time zone)
 * Module:ja last edit December 24, 2014
 * Module:ja-headword last edit December 25, 2014
 * Module:languages last edit September 26, 2014
 * Module:languages/data2 last edit January 13, 2015

Can anyone explain where this module error came from? It looks like it materialized out of thin air. Has there been a system change that might explain this? Chuck Entz (talk) 03:47, 21 January 2015 (UTC)
 * Fixed. The function lua in Module:ja-headword tries to find from the arguments a pure kana parameter, and it fails to detect one if the fullstop ". " is included. Wyang (talk) 05:59, 21 January 2015 (UTC)
 * Thank you! Any idea why it waited a week from the last edit before the error showed up?. Chuck Entz (talk) 07:01, 21 January 2015 (UTC)
 * No idea, it might be the reason  were needed. Wyang (talk) 08:53, 21 January 2015 (UTC)

Mismatch between L2 and language declared in etymology
Is [//en.wiktionary.org/w/index.php?title=scioccare&diff=32086418&oldid=30831230 this] and [//en.wiktionary.org/w/index.php?title=reclutar&diff=32086416&oldid=32085131 this], i.e. the use of a language code as the lang= parameter of or as the second parameter of  that doesn't correspond to the L2 header, something a bot could check for periodically? It doesn't always need to be cleaned up to the language code that corresponds to the L2; sometimes it needs to be switched to use "-", as [//en.wiktionary.org/w/index.php?title=Steig&diff=32086419&oldid=31995717 here]. - -sche (discuss) 17:58, 21 January 2015 (UTC)
 * User:DTLHS/bad etymology. I have excluded Chinese from the list. DTLHS (talk) 01:24, 22 January 2015 (UTC)
 * Some of the pages in the list use and related templates with nocat=. Those should really be excluded. —CodeCat 01:38, 22 January 2015 (UTC)
 * Excluded. DTLHS (talk) 01:42, 22 January 2015 (UTC)
 * Thank you! - -sche (discuss) 02:13, 22 January 2015 (UTC)
 * I really don’t like the way works. I think it should work the same way as . — Ungoliant (falai) 02:36, 22 January 2015 (UTC)
 * It seems that people expect to work the same way as, too. - -sche (discuss) 02:38, 22 January 2015 (UTC)
 * I wonder if should have multiple parameters, for the probable language of the etymology (if you knew it was Latin) as well as the requesting entry language. DTLHS (talk) 02:45, 22 January 2015 (UTC)

 * The next time this is run should also be included, though it has only about 80 transclusions so far. DCDuring TALK  02:53, 22 January 2015 (UTC)

Wiktionary talk:AutoWikiBrowser/CheckPage
Since I don't expect that page is monitored that well, I'm posting here requesting that someone take a look at my request on Wiktionary talk:AutoWikiBrowser/CheckPage. Thank you. Technical 13 (talk) 20:59, 21 January 2015 (UTC)

Partial string search
Is it possible to search for partial string with regular expressions or something else? Currently, I need to find all Russian words with Cyrillic "-вств-" in them (e.g. to fix a pronunciation rule in Module:ru-pron. I have mistakenly defined the rule with a silent first "в", as in,  but there are cases when it's pronounced, I forgot what those words are! One example is.

I think the advanced search functionality would be useful in various case, e.g. when looking for words having the same stem or suffix, etc. --Anatoli T. (обсудить/вклад) 22:56, 21 January 2015 (UTC)
 * AWB search returned 31 results.
 * безнравственность, Соединённое Королевство Великобритании и Северной Ирландии, королевство, Соединённое Королевство, чувствовать, почувствовать, чувствоваться, почувствоваться, здравствуйте, здравствуй, чувство, девственник, колдовство, предчувствие, девственница, кумовство, девственность, воровство, здравствовать, девственная плева, да здравствует, сочувствовать, сочувствие, нравственный, чувствительный, лукавство, нравственность, отцовство, рыболовство, самочувствие чувствительность --Panda10 (talk) 00:45, 22 January 2015 (UTC)
 * Thanks a bunch! Is that a complete list? (As it turns out, silent "v" in the beginning of the cluster is less common than pronunciation "/fstv/.) --Anatoli T. (обсудить/вклад) 02:10, 22 January 2015 (UTC)
 * Yes and it is very easy if you are on unix-like machine (for example Linux). You just download the "List of all page titles"(it is only 55MB). And run command
 * $ grep вств enwiktionary-20150102-all-titles
 * but it doesn't filter by language.
 * Yes this is a complete list as of 2015-01-02. --Dixtosa (talk) 08:46, 22 January 2015 (UTC)
 * Special:Search/insource:/вств/ (warning: slow!) — Keφr 09:24, 22 January 2015 (UTC)

 * Thank you all! --Anatoli T. (обсудить/вклад) 14:09, 22 January 2015 (UTC)

Alternative font for alternative forms?
Why does and/or Module:Alternative forms display forms in a font different from the default font? How do we fix that? —Aɴɢʀ (talk) 12:56, 25 January 2015 (UTC)
 * Maybe because lua? — Keφr 18:06, 25 January 2015 (UTC)
 * So what should it say? —Aɴɢʀ (talk) 18:30, 25 January 2015 (UTC)
 * Probably this. What is the actual point of anyway?  paired with  works well enough for me. — Keφr 18:42, 25 January 2015 (UTC)
 * I dunno, I've never used it myself. I just noticed that it looked funny when other people use it. —Aɴɢʀ (talk) 19:10, 25 January 2015 (UTC)

 * It still has the problem that it doesn't display the qualifier label in parentheses; see Grease_pit/2015/January. If it can't be fixed soon, I'm tempted to start restoring functional manual formatting in entries that use it. - -sche (discuss) 19:18, 25 January 2015 (UTC)

Automating removal of Category:German lemmas categories (and presumably other languages)
I've never really dabbled in the automation side of Wiktionary, so I thought I'd ask here: is it possible, using AWB or a bot, to go through the German parts-of-speech categories and remove categories like Category:German nouns/Category:German adjectives etc from pages that already has template:head or one of its descendants? The problem is that template:head automatically parses German words with special characters in order to correctly alphabetise them in dictionary order (so it puts gären between garen and garnieren). However, putting a lemma category on the page then overrides this and causes the default sort to take precendence, which puts non-ASCII characters after ASCII (which means gären gets sorted after gustieren, between gähnen and gönnen). Simply removing the category where it's unnecessary would ensure that terms including special characters get correctly sorted. I've corrected a few entries by hand (eg., ) but it's hard to find these improperly categorised pages manually when they don't start with an umlaut.

Presumably other languages have this problem too. Category:Spanish adjectives has ñango (which is only categorised through template:es-adj) next to namibio, but ñoño (which is explicitly categorized) is sorted next to zurdo. I'm using German as an example solely because that's a language with collation rules I know fairly well. Smurrayinchester (talk) 09:39, 26 January 2015 (UTC)
 * I've been going through the German topic categories and fixing the ones with diacritics to use instead of bare   for the same reason:  uses smart sorting, and the bare Category: code doesn't. —Aɴɢʀ (talk) 20:19, 26 January 2015 (UTC)

title: Wiktionary:Grease pit/2015/January


text: Wiktionary:Foreign Word of the Day/2015/January 2


text:
micropolyphony

Noun

 * 1) A polyphonic musical texture consisting of many lines of dense canons moving at different tempos or rhythms.

title: micropolyphony


text:
banānā

Noun

title: banānā


text:
Wiktionary:Grease pit/2015/December

Demoting Korean and Vietnamese Han characters entries to non-lemmas
Can entries in Category:Korean Han characters and Category:Vietnamese Han characters be made non-lemmas?
 * 1) Because they are not lemmas.
 * 2) It also makes difficult to track newly created lemmas. --Anatoli T. (обсудить/вклад) 03:41, 1 December 2015 (UTC)
 * Category:Zhuang Han characters probably belong there too. The choice for Japanese lemmas is not always straightforward (kanji, hiragana or katakana or all three). --Anatoli T. (обсудить/вклад) 03:43, 1 December 2015 (UTC)
 * (According to Wikipedia . Category:Zhuang lemmas in Sawndip script?) —suzukaze (t・c) 19:15, 8 December 2015 (UTC)
 * Thanks, Korean hanja are not completely out of use either but are they lemmas? --Anatoli T. (обсудить/вклад) 00:57, 10 December 2015 (UTC)
 * I do not know enough about Korean to say. Although, I note that Korean Wikipedia, , and 여진 (如津, Yeojin, "son of "") —suzukaze (t・c) 01:04, 10 December 2015 (UTC)
 * Yes, you're right but hangeul entries is the main Korean writing system, so they get pronunciations, synonyms, expanded definitions and topical categories. Hanja entries only serve as soft redirects and yes, disambiguations of numerous homophones. --Anatoli T. (обсудить/вклад) 01:12, 10 December 2015 (UTC)

Sense-ids for multiple linked words in a template
Is there a way to add a sense id to individually linked words in a template, such as ? If there isn't, should there be, and what should the syntax look like? Pinging CodeCat. --WikiTiki89 15:04, 1 December 2015 (UTC)
 * A section link  is probably the most intuitive. —CodeCat 15:22, 1 December 2015 (UTC)
 * But then the language name must be written manually. And the link must be piped manually as well if it was not already. --WikiTiki89 15:43, 1 December 2015 (UTC)
 * Not necessarily. Module:links can be modified so that it fixes these things. —CodeCat 16:29, 1 December 2015 (UTC)
 * So how will the module tell the difference between a sense-id and a language name? In fact, these could happen to coincide. --WikiTiki89 16:30, 1 December 2015 (UTC)
 * Senseids include the language name, such that generates and  links to #English-asdf. — Ungoliant (falai) 16:32, 1 December 2015 (UTC)
 * Depends how you look at it. I would consider "asdf" to be the sense-id and "English" to be the language name that would have been part of the link anyway. You wanna be able to do and not have to do ; and in fact maybe it's a good idea to indicate the sense-id by beginning it with  . --WikiTiki89 16:41, 1 December 2015 (UTC)
 * Why would that be necessary? —CodeCat 16:54, 1 December 2015 (UTC)
 * So that would link to Deutsch, while  would link to Deutsch. --WikiTiki89 17:59, 1 December 2015 (UTC)
 * Our templates have never supported mixing of languages. To introduce that would be hard. —CodeCat 20:59, 1 December 2015 (UTC)
 * I thought that they did. At least in the sense that they allowed links like the one above. --WikiTiki89 21:05, 1 December 2015 (UTC)
 * No, that never worked. The section link would go to the right place, but the word would still be tagged as English. —CodeCat 21:10, 1 December 2015 (UTC)
 * That's exactly what I just said. It worked in the sense that the link worked. And I would oppose breaking that functionality. --WikiTiki89 21:24, 1 December 2015 (UTC)

Automatic Khakas Transliteration
I don't think the parameter for transliteration in is working. (See the entry пӱӱр to see why.) --Lo Ximiendo (talk) 10:31, 2 December 2015 (UTC)
 * The documentation in Template:kjh-noun says you need to supply 1 for the translit to be respected. Benwing2 (talk) 10:49, 2 December 2015 (UTC)
 * : What's your take on this? --Lo Ximiendo (talk) 07:39, 6 December 2015 (UTC)
 * I haven't designed Khakas headwords or the empty do-nothing Module:kjh-translit, of course it's not working: . --Anatoli T. (обсудить/вклад) 07:55, 6 December 2015 (UTC)
 * An IP blanked out the whole module back in October. I reverted it, but it doesn't look like that's where the transliteration was coming from, anyway. Chuck Entz (talk) 08:21, 6 December 2015 (UTC)
 * Thanks, Chuck. I have enabled Khakas transliteration in Module:languages/data3/k. The entry now has automatic transliteration. If the transliteration should stay 100% automatic (and override manual), then it should also stay in Module:links (override_translit list). --Anatoli T. (обсудить/вклад) 10:08, 6 December 2015 (UTC)

Unhide Category:xxxxx maintenance
I request that "Category:xxxx entry maintenance" (such as Category:Portuguese entry maintenance) not be hidden. It serves as the umbrella category for other maintenance categories of a certain language, I don't see any reason to make it hidden. I was unable to do it by editing Module:category tree/poscatboiler/data/entry maintenance. --Daniel Carrero (talk) 23:04, 2 December 2015 (UTC)
 * This is actually a bug that's caused by a deficiency in the module. The module doesn't currently allow for any particular way to indicate that a category should be hidden, so as a "hack" I added  to the descriptions of some of the categories. However, since categories also include a list of subcategories with their descriptions, this also brings in the hidden tag, and hides the parent category. It should be fixed for sure. —CodeCat 23:12, 2 December 2015 (UTC)
 * Ok it's now fixed. Categories can now be given the property  in the data module; much more straightforward. —CodeCat 23:23, 2 December 2015 (UTC)
 * That's great! Thanks. --Daniel Carrero (talk) 23:24, 2 December 2015 (UTC)

 * Just to let you know know, English has a subjunctive, so you have to say "I request that X not be hidden." What you said sounds awkward because it sounds like you are requesting that they are already not hidden, which makes no logical sense. --WikiTiki89 00:14, 3 December 2015 (UTC)
 * Ok, thanks. I fixed that mistake in my initial message. --Daniel Carrero (talk) 00:24, 3 December 2015 (UTC)
 * I wouldn't call it a mistake. Some dialects of English prefer "I ask that they not be hidden" while others prefer "I ask that they are not hidden". Context and pragmatics permit the latter to be interpreted correctly rather than in a nonsensical way. —Aɴɢʀ (talk) 08:45, 6 December 2015 (UTC)
 * I guess you're right, but I think that that is more common with verbs other than . --WikiTiki89 16:55, 7 December 2015 (UTC)
 * I have heard this is partly an American vs. British thing, with British English avoiding the subjunctive, although I don't know as I speak American English. Certainly, "I ask that they are not hidden" sounds strange to me as a request. Benwing2 (talk) 13:24, 10 December 2015 (UTC)
 * I speak American English and would require the subjunctive to understand what was evidently intended. DCDuring TALK 13:45, 10 December 2015 (UTC)

template help
If anyone is willing and able to help write a template or two, Borovi4ok says that he has been long in need of a template for Bashkir nouns and verbs. User: Sinek has attempted to do some, such as, but there were some problems that he could not handle. Borovi4ok can provide all the details and just needs somebody to make the actual template(s). Can anybody help? Contact Borovi4ok. —Stephen (Talk) 04:18, 3 December 2015 (UTC)
 * write the documentation first so that everybody can see. Then link the page here. --DixtosaBOT (talk) 05:50, 3 December 2015 (UTC)
 * ,, thanks a lot for your help.
 * Let me describe the situation, as I see it.
 * The Bashkir noun template already exists, and it works fine in most cases. I need someone to help me correct the error in it. Dixtosa, can we do that?
 * I am ready to write up a documentation for it. When we're done with the noun template, I can create the documentation for the verb template, so we can create it.
 * I need an example or a master of noun declension template, regardless of the language. Borovi4ok (talk) 14:48, 15 December 2015 (UTC)
 * You can look over Georgian noun declension template
 * If you notice you have hard time coming up with the documentation then you can just succinctly describe the grammar of Bashkir.--Dixtosa (talk) 16:48, 15 December 2015 (UTC)
 * There are currently two noun templates for Bashkir: (for nouns that end in a consonant) and  (for nouns that end in a vowel). —Stephen (Talk) 05:20, 16 December 2015 (UTC)

Removing RTF code by a progammmer
I am currently trying to escape my bête noire. There are currently 232 entries with the oldest rft tags, listed down the right side of WT:TEA. This stems from the implementation of archiving WT:TEA in order to avoid "yet more completely wasted time." "There is a thread in the Beer Parlour about that..." "The problem is, the rft tags don't seem to have taken off any of the pages..."

The discussion in July 2012 led to a proposed solution from DCDuring TALK ; "I had imagined a template that had a given archive subpage as an argument and could be subst'ed at the bottom of an entry's talkpage. It would be nice to include a user-friendly identifier like month and year of the discussion in the talk page heading, eg, "==Tearoom discussion March 2012==". This would both help users directly and serve to distinguish multiple discussions. As we don't want discussions to continue in the archive, we might want to provide some kind of message to encourage anyone interested in trying to continue the discussion to do so on the talk page." "Even better, if you're willing to do the work, I'll make a template that will make it pretty fast..." said

To recap; "While tea room items don't "require" resolution, it is annoying to see a tag on an entry saying "The Tea Room is currently discussing this word" only to find that the tea room hasn't been discussing this word for months or even years." But it is even more so to eventually see a "required" solution only to find that Wmg iktionarians haven't been discussing this tea room resolution for months or even years, and it has grown cool. Though a template was create, it was soon deleted, noting that "...would have no problem with the recreation/restoration of the template by anyone interested in using it." Meanwhile in February 2014 the template was edited to include /2024/July In December 2014  deleted "a  template which doesn't have to be subst:ed". Also about this time, July, I attempted to reheat the discussion, and failed.

I would like to propose renewing documentation, and implementation to a programmer(s) with know how in WT:GP? Riverstogo (talk) 01:28, 6 December 2015 (UTC)
 * Here is another piece of archived discussion from WT:RFDO. Many templates were deleted because like "templates can be simply substituted to yield their replacement".  This discussion appears to have been archived in a way that makes it difficult to find and impossible to edit? All of which has increased the size of my bête noire. While still wondering if all of my pings failed I would like to suggest an approach starting by editing rft template Usage documentation, perhaps  ? Riverstogo (talk) 08:54, 6 December 2015 (UTC)
 * I didn't get your ping. As I understand it, the ping has to be in the same paragraph as a signature. —Aɴɢʀ (talk) 09:46, 6 December 2015 (UTC)
 * To again send out pings that failed    . Riverstogo (talk) 22:25, 6 December 2015 (UTC)
 * Please don't mistake my comment for a technical recommendation about how to implement something that would achieve the result, which I still think is worthwhile. I am not competent to give truly technical advice other than the generic KISS. DCDuring TALK 13:14, 6 December 2015 (UTC)
 * To KISS I will continue to summarise my mistakes, though I am neither competent to assess truly technical advice about how to implement something, nor which is worthwhile . Riverstogo (talk) 22:25, 6 December 2015 (UTC)
 * The discussion; aWa: Archiving discussion to Template talk:archive box by User:Kephir, January 2015 "is no longer live and is left here as an archive. Please do not modify this conversation, though feel free to discuss its conclusions."
 * One conclusion was discussed in June, "And this is what you get when you archive discussions the "relaxing" way. (You might want to look at WT:RFDO.)" User:Kephir said referencing with the same now inaccurate link, that the aWa archiving tool made inaccurate, in a somewhat arbitrary and less "relaxing" way. At least from where I stand at the bottom of the steep learning curve. Riverstogo (talk) 22:25, 6 December 2015 (UTC)

 * Yes, I've said this before that should take a year-and-month timestamp as an argument. This would both make it link to the correct archive page and make it easier to find and remove really old ones. --WikiTiki89 16:58, 7 December 2015 (UTC)
 * Going forward this would be very useful, especially if it could be automatic. Retrospectively, would it be worth the effort to have a bot find each archived TR discussion (with a well-formed title) and insert links to it on the appropriate talk page? Ideally, the links would only be inserted where the talk page did not already contain or reference the discussion. DCDuring TALK 17:34, 7 December 2015 (UTC)

 * I support the idea of having a template which can be subst'd on the talk page along the lines of "==Tea room discussion== This item was discussed in the Tea Room at such-and-such a date." Also, I'm not sure if this is being suggested, but the  tags should also expire and hide themselves after a month or so, and then be deleted by a bot or human. —Pengo (talk) 05:50, 10 December 2015 (UTC)

 * I've started to work on Module:tearoom. It's very rough so far, but as a proof of concept, it shows the date functions work for working out whether a tearoom discussion has been archived, and it can generate an url to the archived discussion (from the year and month expressed as numbers). See examples here User:Pengo/tearoom2 ("edit" to see source and get an idea of what it's doing). WIP. I don't know if I'm reinventing any wheels here, but it seems to be easier to start from scratch than to even begin to search for existing code/modules (really, I have no idea where to look). If anyone wants to push it ahead faster then please feel free to continue on it. Pengo (talk) 07:56, 10 December 2015 (UTC)

Reconstruction talk namespace
So, the "Reconstruction:" namespace has been implemented, but there's a problem: the "Reconstruction talk:" namespace has a stray comma after the word "talk", e.g. Reconstruction talk,:Proto-Indo-European/albʰós. This should be fixed before any more pages are moved, but I don't know whom to report it to. —Aɴɢʀ (talk) 17:50, 7 December 2015 (UTC)

Pinging, who seems to be making a lot of the moves. —Aɴɢʀ (talk) 17:52, 7 December 2015 (UTC)
 * I stopped just in case it's a problem. I don't think it will be to rename them but still. —Justin ( koavf ) ❤T☮C☺M☯ 17:53, 7 December 2015 (UTC)
 * OK. Other things that need to be fixed: (1) The headword line templates like head and its language-specific equivalents need to put words in Reconstruction: namespace into categories (Reconstruction:Proto-Indo-European/albʰós is currently uncategorized). (2) The link templates like l and m need to point to Reconstruction: namespace instead of Appendix: namespace. Obviously this can wait until all pages have been moved, since for now the links to Appendix: simply redirect to Reconstruction: and thus nothing is broken. —Aɴɢʀ (talk) 18:00, 7 December 2015 (UTC)
 * I've updated the modules I could find, except Module:links. —CodeCat 18:13, 7 December 2015 (UTC)
 * The talk namespace has been fixed, thanks for getting that fixed, CodeCat! Can a bot now start moving the pages, or do we want to have a discussion and possible vote about how to name Reconstruction pages ("Reconstruction:Proto-Indo-European/albʰós" vs. "Reconstruction:albʰós#Proto-Indo-European" vs. whatever) first? —Aɴɢʀ (talk) 07:36, 9 December 2015 (UTC)
 * I'd prefer the latter option, but I do not know whether we need to have a vote. Also wasn't there some question about the whether the namespace would be marked as content that needed voting? — JohnC5 19:17, 9 December 2015 (UTC)

Inter-wiki linking
Hello from en.Wikisource. I had edited a page on Wikisource with a link to Wiktionary for an archaic word. A very useful and allowed annotation. I checked the link and left the Wikt page open, finished editing and later wanted to get back to the Ws page—thought I would be clever and clicked on "What links here" on the Wikt page. Disappointed it didn't show my link in Ws. Is this because there is a time delay for inter-wiki links to happen or do they just not show up on "What links here"? If the latter, this seems an opportunity lost... My link could provide context? Cheers, Zoeannl (talk) 23:12, 7 December 2015 (UTC)
 * Special:WhatLinksHere does NOT link to other WikiProjects. Not other Wiktionaries nor other English WikiProjects. I think what you're proposing sounds like a Toolserver thing. Renard Migrant (talk) 23:20, 7 December 2015 (UTC)
 * I have wished for over 10 years that there was a way to see links from other Wikiprojects. It would make cleaning up broken links much easier. And it must be possible, since Commons does show usage of its files on all Wikiprojects. —Aɴɢʀ (talk) 06:47, 8 December 2015 (UTC)

Is there anyone we can ask at Commons? Toolserver? Totally out of my league. Cheers, --Zoeannl (talk) 20:14, 10 December 2015 (UTC)

 * The request would have to be at Phabricator, and from memory there was a similar sort of request made, and the fact is that they are separate data bases and unable to be interconnected by the system to the amount of backend processing. ToolLabs or Quarry could both generate the data and hold it outside of the wiki. Couldn't you put in as a quotation to the use of the word, eg. vespertine. One of the aspects of Wikidata is that it is able to manage a better link process for primary links. The other process that has recently had traction is the Community Wishlist that is run from meta: — billinghurst  sDrewth  11:32, 18 December 2015 (UTC)

Retiring the "form of" gadgets
There are currently 4 different gadgets for slightly changing the formatting of "form of" definitions, i.e. definitions such as "First-person singular (eu) present subjunctive of dançar". According to Special:GadgetUsage, these are among the least used gadgets on the project. Of the four, only FormOfPlain is used by any active editors, and it's only used by 2. The content of these gadgets is just a trivial snippet of CSS which could easily be added to a user's custom CSS. See for example, MediaWiki:Gadget-FormOfPlain.css. Since these gadgets aren't being actively used, I propose that they be retired. Kaldari (talk) 00:38, 10 December 2015 (UTC)
 * Is there any point to this? Why do we need to cut down on gadgets? —Μετάknowledge discuss/deeds 23:29, 13 December 2015 (UTC)
 * The reasons are, , and . Basically, having more options leads to a worse user experience. In this case, the gadgets in question aren't being used by anyone, and only serve a very obscure (and rather pointless) purpose. The cost of listing them (per the 3 sources above) is far greater than the cost of removing them. Kaldari (talk) 00:35, 16 December 2015 (UTC)
 * Here's an even better source that lists numerous resources on the topic: http://uxmyths.com/post/712569752/myth-more-choices-and-features-result-in-higher-satisfac. Kaldari (talk) 00:41, 16 December 2015 (UTC)
 * No offence intended, but that's a rather silly misuse of those studies. I am struggling even to estimate how low of a priority this is. —Μετάknowledge discuss/deeds 00:45, 16 December 2015 (UTC)
 * You don't need to estimate the priority. I can remove them myself. I just wanted to make sure no one objected. Kaldari (talk) 00:51, 16 December 2015 (UTC)

Retiring the was-WOTD gadget
There is currently a gadget to move the was WOTD template to the absolute top-right position on the page (rather than the top-right of the body content). According to Special:GadgetUsage this gadget has only been turned on by 20 users, none of which are currently active. The gadget consists of a 2-line snippet of CSS which could easily be added to a user's custom CSS instead. Since this gadget isn't being actively used, I would like to propose that it be retired. Kaldari (talk) 00:50, 10 December 2015 (UTC)
 * To quote Metaknowledge (just up the page): "Is there any point to this? Why do we need to cut down on gadgets?" —msh210℠ (talk) 19:29, 15 December 2015 (UTC)
 * See my reply above. Kaldari (talk) 00:36, 16 December 2015 (UTC)

System message edit request
Someone please capitalize the following (marked) characters in the MediaWiki:loginprompt system message:
 * Meta-Wiki, Media w iki, Wikibooks, Wikimedia  c ommons, Wikimedia  i ncubator, Wikinews, Wikipedia, Wikiquote, Wikisource, Wikispecies, Wikiversity.

Thanks. - dcljr (talk) 18:29, 11 December 2015 (UTC)

 * ✅ Equinox ◑ 18:31, 11 December 2015 (UTC)

Loglan
Can an administrator (or someone of similar power) add...

to Module:languages/datax for me?

Additionally, Loglan should be probably set as the ancestor for Lojban (jbo) in Module:languages/data3/j. Thanks for your time :) -Xbony2 (talk) 21:19, 12 December 2015 (UTC)
 * We don't include constructed languages without getting consensus first, and so far there's never been consensus to include a conlang that doesn't have an ISO 639 code (nor for many that do have ISO 639 codes); see Criteria for inclusion. —Aɴɢʀ (talk) 21:39, 12 December 2015 (UTC)
 * That's not exactly true. There's no consensus to add Loglan entries in mainspace, but they could be added in an appendix (once the code is added, of course). —Μετάknowledge discuss/deeds 23:28, 13 December 2015 (UTC)
 * I don't think there should be any appendixes either. Our current practice is two-faced: we say no, you can't include it, but then we let it be included anyway. —CodeCat 23:48, 13 December 2015 (UTC)
 * I think that appendix entries linked to from the mainspace are useful. For example, many mainspace languages have borrowed terms from languages like Sindarin and Klingon that are appendix-only, and having entries for the terms they are borrowed from adds depth to the etymologies. —Μετάknowledge discuss/deeds 00:23, 14 December 2015 (UTC)
 * That's a good point. Last summer I created an entry for as an English word, but its etymology is the appendix-only language Lapine. However, I didn't use etyl for it since we haven't made up a code for Lapine; instead I just put the link to the appendix in the See also section. —Aɴɢʀ (talk) 07:09, 14 December 2015 (UTC)

To mid2 or not to mid2
How come we still need to use a, like this:

... half the items ... ... the other half of the items ...

When Wikipedia gets to do it like this:

... all the items to be listed in two columns ...

This has bugged me for ages. Can't we steal their  related stylesheets and templates? —Pengo (talk) 22:27, 13 December 2015 (UTC)
 * Agreed, definitely. The first thing we should use it for is translation tables. —CodeCat 22:42, 13 December 2015 (UTC)
 * I believe WP's "div col" thing only works on some browsers (e.g. it doesn't work on Internet Explorer), while our method works everywhere. —Aɴɢʀ (talk) 07:06, 14 December 2015 (UTC)
 * Apparently it's supported in IE since 2012, version 10 and up, which leaves us with 3.55% of Wikimedia traffic in June 2015 with versions of IE that don't support it. Enosh (talk) 08:36, 14 December 2015 (UTC)
 * In that case, make it so. In fact, come to think of it, der3 and rel3 already make columns automatically, so why not have a tra2 for a two-column translation table? It wouldn't even need a separate div end. —Aɴɢʀ (talk) 10:51, 14 December 2015 (UTC)
 * and the rest work entirely differently, using Lua to balance the columns. Using it on translation tables isn't a good idea for performance reasons. DTLHS (talk) 16:30, 14 December 2015 (UTC)

 * We already have that does this. See how it is used at WT:Wanted entries. --WikiTiki89 18:09, 17 December 2015 (UTC)
 * How does it look when it's unsupported is the question. Enosh (talk) 18:43, 17 December 2015 (UTC)
 * There would just be one column. --WikiTiki89 18:47, 17 December 2015 (UTC)
 * Not that bad, I guess. Enosh (talk) 18:57, 17 December 2015 (UTC)
 * Unless you're loading water. —suzukaze (t・c) 08:13, 23 December 2015 (UTC)

and Han characters
Could it be made so that single Han characters are not lumped in with other entries? For example, see Category:Korean entries needing definition where I guarantee that over 90% of these are hanja.

This is different from ; I am requesting that sort into something like Category:Korean Han characters needing definition rather than Category:Korean entries needing definition when used on a page like 乤. —suzukaze (t・c) 06:30, 14 December 2015 (UTC)

 * User:Suzukaze-c/T:test seems to be functional, if ugly. Tests: 㗎 (Han character), 𠂝 (exotic Han character), 𪛖 (exotic Han character) 胃腸 (not a Han character), 경비 (not a Han character). would still produce Category:Translingual Han characters needing definition. —suzukaze (t・c) 22:25, 19 December 2015 (UTC)

Make templates aware of the language heading they're under
So there was this discussion on Wiktionary's user-unfriendliness. I already wrote a couple of comments on some issues with the development process and documentation there. But somewhat unrelated to those comments, I think one the largest things we could do to improve the editing experience would be to get rid of the redundant parameters on templates.

Many templates repeat the language code from the heading of a section. It's repeated over and over again. This makes editing error prone and tedious. The unneeded parameters should simply be inferred from the language heading.

Let's simplify templates hugely and remove all the redundant  parameters.

 * Current redundant style for templates:

(all bold parameters are redundant)

==English== ==French==

 * Suggested style:

(without redundant parameters)

== == ==  ==

To get a  template working as above, we'd need to install Extension:Variables. Here's the discussion on mediawiki.org where I initially brought it up and got the suggestion of this particular solution. I've also made a larger diff, just to see how much code would be reduced. (I count 28 redundant language parameters or parts of template names on the page "action". I chose that page an example just because it's a word in both English and French).

There would be a lot of work in editing existing templates to use the heading section variable as the default language, and I don't know if "section" would be the best name for the template, and also we'd have to work out what the variables it creates should be called and what syntax we want to use, across templates, to override them, etc.

For now I'm just looking to get a rough idea of what people think of this idea, and if the  format is acceptable or if we should try to make a MediaWiki extension which does the same thing invisibly on the backend, allowing the headings to stay as they are, but making the H2 header language name and code available to the templates under it.

All those redundant  parameters just seem to weigh down the wikitext so much. The code without them seems much clearer, and more intuitive to write and edit, and much easier to memorize the syntax for. Thoughts? —Pengo (talk) 07:38, 20 December 2015 (UTC)

 * I can vouch for Variables' potential since I've coded stuff for Wikia wikis before (where Variables can be enabled if one asks). But can it cooperate with Lua? —suzukaze (t・c) 07:56, 20 December 2015 (UTC)
 * If we do this (and I don't know enough about it to say whether it's feasible but it seems like a good idea), I'd rather the parameter for section (or whatever equivalent we end up using) be  than  . There's less potential for screwing everything up because of a little typo; I'm far more likely to remember   than to remember how to spell Djambarrpuyngu. —Aɴɢʀ (talk) 08:07, 20 December 2015 (UTC)
 * I went for "French" over "fr" mainly to keep it as similar to the existing headings as possible. It also keeps it more user-friendly as you don't need to know the code to create a language heading. The idea would be to then pass that heading to a lua module which spits out the language code for use elsewhere in the code. e.g. you'd end up with variable  and   OR you'd end up with an error (if the language was not found). Currently to use a language code for a heading you can do this:   but uh, maybe we could find a nicer way. I don't know how well the extension integrates with Lua but I'm pretty sure you could pass the variables to Lua via a template. —Pengo (talk) 08:40, 20 December 2015 (UTC)
 * I bet it would even be possible to accept either one and have the module distinguish them on the basis of whether the first letter is capitalized or not. Then Ari would be interpreted as the Trans-New Guinea language Ari, while ari would be interpreted as the Caddoan language Arikara . —Aɴɢʀ (talk) 11:26, 20 December 2015 (UTC)
 * This seems like a great idea to me; I had no idea it was possible. Even better would be if there was a way for one template to store its parameters to be used by another template. For example, currently in both Russian and Arabic, the noun headword and noun declension templates have exactly the same info in them, and the same goes in Arabic for the verb headword and verb declension templates. I've been using a bot to keep them in sync but it would be a lot nicer if the headword (which comes first) could somehow store the full set of parameters used in it and have them retrieved by the declension. Forgive me if this is exactly what the Variables extension does; I'm not familiar with it. Benwing2 (talk) 12:23, 20 December 2015 (UTC)
 * BTW, I like Angr's idea of allowing both language name and code to be used. I personally find it hard to remember the 2-letter or 3-letter (or sometimes 6-letter or 9-letter) language code, esp. for obscure languages, and it's not always that easy to look it up. Benwing2 (talk) 12:25, 20 December 2015 (UTC)
 * I like the idea of allowing both code and full language name, but I'm worried more that we'd end up with an inconsistent style, with some pages having  and some with , and some with a mix of the two styles throughout. I guess we could allow both and see if a general style emerges, and vote on it down the line. Using the module for other things like declension tables sounds plausible. We need to be careful to document such things well, so we don't end up with too many undocumented global variables. Pengo (talk) 14:44, 20 December 2015 (UTC)
 * I'd prefer we use language codes, but that's not especially newbie-friendly, to be honest. I think allowing both to work and periodically having a bot fix them to a standard would be good. —Μετάknowledge discuss/deeds 18:00, 20 December 2015 (UTC)
 * Yep. That sounds ideal. —Pengo (talk) 22:31, 20 December 2015 (UTC)
 * Wow, I had no idea this was possible. Support 200%! The extra 100% is for just in case. —CodeCat 15:30, 20 December 2015 (UTC)
 * This seems like a change well worth, 1., the risk of some inconvenience from unanticipatables in the transition and, 2., some manual effort to bring our headings up to the standard required. DCDuring TALK 16:37, 20 December 2015 (UTC)
 * Support, let's do it. --Daniel Carrero (talk) 16:40, 20 December 2015 (UTC)
 * Make it so. — JohnC5 17:47, 20 December 2015 (UTC)
 * Support fully. —Μετάknowledge discuss/deeds 18:00, 20 December 2015 (UTC)

I created a vote: Wiktionary:Votes/2015-12/Install Extension:Variables. —CodeCat 19:51, 20 December 2015 (UTC)
 * IIRC, the devs have rejected requests to enable Extension:Variables in the past. --Yair rand (talk) 20:31, 20 December 2015 (UTC)
 * What were their specific objections to it? DTLHS (talk) 22:41, 20 December 2015 (UTC)
 * I found the discussion from 2011: Grease_pit/2011/January with CodeCat looking to reduce other types of redundancy in pre-Lua templates. That discussion links to discussion from 2006 which is found on phabricator where Brion Vibber wrote:
 * Would strongly recommend against this sort of meta-programming features in wikitext.
 * Tim Starling replied with further objections:
 * I'm against it on the grounds of interaction with caching, the need to maintain flexibility of parser implementations, and expected application (wikitext is not a programming language).
 * So I'm guessing the "metaprogramming" or "expected usages" concerns are less of an issue now (there's no need to use lualess wikitext to create "a horizontal clade tree in a single table" any more). I'm guessing the caching problems are less of an issue now too (Lua would have the same issues). However, the desire to "maintain flexibility of parser implementations" is still an issue, as using this extension will likely break anyone's re-implementation of wikitext-parsing. For example, Xowa, an offline Wiki reader which stores compressed Wikitext in its database and renders it to HTML with its own Java code. Xowa would need to update their parser just for us (I searched the source code and it looks like the extension is not currently supported). There's a list of alternative parsers here, though Xowa is the only one I've seen that can actually handle a modern lua-containing Wiki page. The rest would not be able to render much of Wiktionary's templates anyway. There's only one other listed that mentions Lua (also written in Java), but there's possibly others. Apart from full parsers, there'd also be plenty of simpler scripts which are hardcoded to expect  or whatever. These are the things I was initially more concerned about, and was looking if we could even roll our own extension which keeps the heading syntax identical but quietly has the same effect of creating a "language section" variable. Though now I'm divided on the approach, as using Extension:Variables would at least be using an existing somewhat standard extension (and it already exists). Whichever approach, I'd say it's more of a roll-out issue. We should give warning about the change, and perhaps restrict the usage of the extension to headings initially to give third-parties time to catch up. The objections were from 2006. the context is quite different. The requested extension has been around since at least then. It would be worth requesting it again. —Pengo (talk) 00:00, 21 December 2015 (UTC)
 * Could the template use MediaWiki:Gadget-WiktCountryFlags.css? --Lo Ximiendo (talk) 00:04, 21 December 2015 (UTC)
 * It would be nice if it worked like Conrad Irwin's Translation editor, where the language code is preferred, but you can also enter the language name, which will be automatically converted to the correct code. —Stephen (Talk) 01:36, 21 December 2015 (UTC)

 * If this is actually doable, I love it! The template should definitely accept a language code and not a language name. --WikiTiki89 15:50, 22 December 2015 (UTC)

 * If this doesn't happen we could always just move pages to titles that include the language name as a prefix. No more language codes needed. DTLHS (talk) 05:13, 23 December 2015 (UTC)
 * And link them from the term's entry. Kind of like our Beer parlour and discussion pages.
 * But I oppose moving 4m entries just to reduce redundancy. --DixtosaBOT (talk) 07:22, 23 December 2015 (UTC)
 * Yeah, I've always been saying that each language should be on its own page. We've had many BP discussions on this in the past and none of them led anywhere. --WikiTiki89 15:20, 23 December 2015 (UTC)
 * Do you have a specific naming system in mind? Examples: pizza could be en/pizza or pizza/en. --Daniel Carrero (talk) 15:28, 23 December 2015 (UTC)
 * I think both of those have been considered. --WikiTiki89 15:31, 23 December 2015 (UTC)
 * I believe the naming format pizza/en has one technical advantage: If we have pízza/en, pízza/pt, pízza/es and also pízza to transclude them all, it should be easy enough to add a single template to pizza to transclude the other pages automatically as they are created, or create a bot to update pizza if needed. --Daniel Carrero (talk) 15:37, 23 December 2015 (UTC)
 * Although I agree that moving  to   would be an overall better design for Wiktionary (and I was considering bringing it up myself as an alternative to this proposal), ultimately I think it would be too disruptive to change over any time soon. The redundancy problems in the templates are a symptom of a mismatch between what we want to display at once to the user (the meaning of a string of text across languages) and the type of record most bits of data belong to (a word in a single language). Using   would help resolve that mismatch. There's a host of small and large benefits that would flow on from doing that. e.g. It'd be great if I could add just   to my watchlist (which gets very few of the edits to minor), or start a discussion page about a word in a specific language, and I bet it would even make Wikidata integration easier. But changing to this format would be hugely disruptive. Basically it breaks everything that uses , breaks up the "history" view of every entry on Wiktionary, and creates many issues and questions around linking. To me it's almost like saying "let's make a Wiktionary 2.0". It's not a change that lends itself to being done incrementally. So I'd support it over the current system if it were 2002 and Wiktionary just launched, and I'd support it if Wiktionary had a dedicated army of template coders and QA who could work towards moving all templates and entries across in a fell swoop, and I might support it in future after Wiktionary manages to develop a stable machine-readable format for its entries (which could remain the same during the change), but in reality I just don't see it being a practical change, even if everyone agreed to it. I suggested the  proposal instead because I think it would be far less disruptive and can be done incrementally (i.e. old templates with   will still work just fine until they're updated), and everything works the same as everyone expects it to, and there should only be minor breakages during the switch over with third party tools/scripts. It might also be a good middle step to moving to the   format, as templates which are aware of the "section language variable" could be more easily switched over to be aware of the   in the url instead, if we wanted to consider it in the future. Pengo (talk) 00:23, 24 December 2015 (UTC)
 * Some thoughts:
 * "add just  to my watchlist" -- I agree: being able to do that would be great!
 * "Basically it breaks everything that uses " -- A possible problem/obstable to overcome: I used   in the page pizza/en, but the result was pizza/en, not pizza. Subpages seem to be disabled in the main namespace, probably because otherwise AC/DC would be considered a subpage of AC. If we are able to enable subpages in the main namespace, does it mean that AC/DC/en is going to be a subpage of AC and as well as AC/DC? That does look bad. We can always keep subpages disabled and use Lua to create a proper replacement for   (suggested name: ), but it would be weird using subpage-like pages ("pizza/en", "pizza/fr") if they aren't actual subpages.
 * --Daniel Carrero (talk) 14:11, 26 December 2015 (UTC)
 * Hmm... the AC/DC problem. You'd think MediaWiki would have added something like a __NOTSUBPAGE__ switch to solve this problem by now. E.g. something you could add to AC/DC so that it would not show the breadcrumbs and so AC/DC/en would work as expected (linking to AC/DC but not to AC). Instead they suggesting bad hacks like using a backslash instead, or weird unicode slash-like characters (ugh). A neater hack that could work for us might be to build our own exception list, which could check against. It wouldn't fix the breadcrumbs (at least without some additional javascript hackery), but at least other templates could automatically show "AC/DC" instead of "AC". I've just realised though, the biggest problem with the format is if Norwegians adopt the word yes, and then what would we do with yes/no? I guess we could move it to Unsupported titles/yes/no and keep yes/no for the Norwegian "yes" page. Probably not the end of the world. I made a list of all the pages that currently use a slash and couldn't see any non-hypothetical conflicts with the pizza/en naming scheme though. —Pengo (talk) 01:06, 27 December 2015 (UTC)
 * Languages could be namespaces as well, although that just brings on another set of complications. Personally I like the idea of subpages down to the definition level, so that a definition page includes the definition, quotations, translations and usage notes (and anything definition specific I am not thinking of) which then flows into a heirarchy of subpages (def => POS => etym => language => string).  This would resolve the complications around keeping definition specific content together and make great strides towards machine-readability.  It is technically and practically very daunting though. - TheDaveRoss 19:25, 6 January 2016 (UTC)
 * That seems like an awful lot of namespaces- at least a couple of orders of magnitude more that all the ones we've used so far. Any way you look at it, there are going to be tradeoffs between time spent creating/manipulating/navigating-between subpages and page complexity. The problem is that what we're modeling is inherently rather complex and difficult to simplify. Parts of it are very regular, but there are areas with all kinds of mutually-interacting and/or recursive levels/groupings- not to mention patterns that apply one way in some circumstances, but another way in others. I'm not very optimistic about finding The Right Way to structure our entries. Chuck Entz (talk) 02:35, 7 January 2016 (UTC)
 * It's going to be a little off-topic, but maybe it would be a good idea making all definitions use a unique ID number, rather than separate definition-level namespaces? Say bat means "nocturnal flying mammal" (ID 1789994) and "club used in sports" (ID 1789995), among other definitions. There could be some way to visualize only contents (quotations, translation tables, etc) specific to a single definition. Also: if we added "ID 1789995" in all mentions of the word "bat" with that meaning in etymologies of all entries, maybe it could fill in the gloss automatically. The word batter (meaning: the player attempting to hit the ball with a bat) would be etymologically bat (ID 1789995) + -er (with another ID).  --Daniel Carrero (talk) 04:00, 7 January 2016 (UTC)
 * And now we're getting into the territory of why a dictionary is better off as a database than as a wiki... --WikiTiki89 17:01, 7 January 2016 (UTC)
 * Unless we want to throw everything out and start from scratch, the movement to a fully normalized data structure has to be in increments. - TheDaveRoss 17:05, 7 January 2016 (UTC)

 * If we transclude all the existing languages from the main entry, how will this affect a? Will it load faster or slower? --DixtosaBOT (talk) 06:19, 24 December 2015 (UTC)

The fundamental problem with Extension:Variables is that it requires the whole page to be parsed in order. So it prevents asynchronous or parallel parsing, incremental parsing and various sorts of caching. It makes implementation in Parsoid difficult since it is fundamentally asynchronous. It would be much better to have a scoped, immutable declaration in which information is propagated down the parse tree:

Or even just expose the current <h2> section title. If we implement T114072 then sections will have a fixed scope in the parse tree. You could theoretically attach attributes to that scope:

== ==

This looks a lot like Extension:Variables except that declarations are automatically terminated at the end of the section, and you can't set the same property more than once in the same section. Declarations would need to come immediately after the heading. -- Tim Starling (talk) 17:16, 3 January 2016 (UTC)
 * I don't think many people here care about the specific underlying details. The most important point is to make templates aware of the L2 section they appear in, so that we can get rid of the collection of template parameters that are currently needed to specify it instead. Personally, I think the best implementation would be if templates/modules could access the whole tree of sections. Templates could retrieve this with something like  (to retrieve the L2 section name), while Modules might be given this information as a table that is part of the frame object. —CodeCat 17:24, 3 January 2016 (UTC)
 * Thanks very much for your input. It's much better to get an explanation like this why Extension:Variables is a problem rather than simply "we won't do it". I agree with CodeCat that any solution that avoids the duplication of parameters is a good one. If you can implement one of the other solutions that you describe, that would be great. Benwing2 (talk) 18:54, 3 January 2016 (UTC)
 * I filed T122934 for this. -- Tim Starling (talk) 18:58, 6 January 2016 (UTC)

run a bot to add language codes to calls
Speaking of language codes, I'm thinking of running a bot to add language codes to calls based on the language section that the audio call is within.
 * 1) Any objections to doing this? Should I skip doing this for English?
 * 2) What's the magic invocation to convert a language name to a language code? Benwing2 (talk) 12:28, 20 December 2015 (UTC)
 * Given the proposal immediately above this one, I think we should wait with this. —CodeCat 19:53, 20 December 2015 (UTC)
 * That proposal might take some time. I can't see any harm to doing this if Benwing wants to put the time into it. —Μετάknowledge discuss/deeds 19:56, 20 December 2015 (UTC)
 * I'm running this now; it only took maybe 20 minutes, if that, to write the code. Benwing2 (talk) 02:08, 21 December 2015 (UTC)
 * Special:Contributions/WingerBot Great job! --Anatoli T. (обсудить/вклад) 02:11, 21 December 2015 (UTC)

About quotations
I have a couple of questions regarding quotations:

 * 1) If the source material uses scribal abbreviations (e.g. a Medieval text abbreviating 🇨🇬 to cū, with the superscript implied nasal), is it best to follow the original style and reproduce (where possible) the abbreviations in the quotation, or to just write all complete words?

 * 1) Often in older Italian printed texts are words, which — in modern Italian — would be separated by an apostrophe, that appear tied together (e.g. laltro for ). Would it be okay, in such cases, to add apostrophes for the sake of clarity (for example, “l'altro”) — perhaps even between square brackets (“l[']altro”) to indicate it is an addition — or is it best to just reproduce the source material?

— GianWiki (talk) 18:19, 20 December 2015 (UTC)
 * In quotations it is always best to reproduce the original style as much as possible. So in other words, follow the abbreviations used in the original text and do not include apostrophes not found in the original text. --WikiTiki89 15:51, 22 December 2015 (UTC)

Templates and links to specific sections
I was looking at malo, and I noticed that the links to the lemma in inflection of in the 'Etymology 2' section did not link directly to the appropriate section of malus (the lemma) and instead simply took you to the language header. I attempted to remedy this by setting the first parameter in inflection of (the parameter that controls what exactly will be linked to) in the template calls there to "malus#Etymolgy_2', but when I did so, the link was actually to 'malus#Etymology_2.23Latin', which obviously doesn't exist. At first, I thought there was simply a problem with inflection of, but when I attempted to do the same thing in the etymology section itself, which uses term, I ran into the same problem. What's going on here? Esszet (talk) 21:23, 20 December 2015 (UTC)
 * You need to use the  parameter to link to specific parts of a language section, and then place  in front of the appropriate sense. —CodeCat 21:27, 20 December 2015 (UTC)
 * That seems rather annoying; can't the templates just be made to properly interpret parameters such as 'malus#Etymology_2' for links? Esszet (talk) 23:23, 20 December 2015 (UTC)
 * No, because that feature of the software has always been broken. If there are multiple Etymology sections on the page, it always links to the first one. So if someone else then adds another one, all links break. —CodeCat 23:28, 20 December 2015 (UTC)
 * What do you mean? The first two 'Etymology' sections on si have distinct URL's and can thus both  be linked to: si and si. Esszet (talk) 01:32, 21 December 2015 (UTC)
 * This is a wiki. People add, remove, and rearrange things all the time. What is now "Etymology 2" could become "Etymology 1" or "Etymology 3" without warning. Language sections get added and/or split into multiple etymologies all the time The only header that you can guarantee won't be duplicated or replaced with something else is the language header. Chuck Entz (talk) 07:10, 21 December 2015 (UTC)
 * I realize that, but does it really happen so often that adding links to specific sections is pretty much useless? Esszet (talk) 17:53, 21 December 2015 (UTC)
 * Perhaps templates which use the  parameter could be made to give an error and automatically suggest the preferred solution to the user when they detect this kind of link? —Pengo (talk) 00:46, 23 December 2015 (UTC)
 * is not actually affected by this. On the contrary, it is the solution to this. --WikiTiki89 00:55, 23 December 2015 (UTC)
 * Maybe I wrote it confusingly, but that's what I meant. Templates where it is available as a solution it should be offered. Pengo (talk) 14:55, 23 December 2015 (UTC)
 * I still don't quite get what you mean, but for a module to actually check the page it is linking to would be way too time-consuming to do for every link on a page. --WikiTiki89 15:21, 23 December 2015 (UTC)
 * It's not checking the contents of the target page, it's just checking if there's a # in the link. If there is then it can suggest using  in an error message. Pengo (talk) 22:50, 23 December 2015 (UTC)

Definitions in other languages
Do we allow definitions in other languages on this Wiktionary? I've compared other similar lists and I can't come to terms with this page User:BAICAN XXX/Protologisms (Romanian). Shouldn't the definitions be in English? --Robbie SWE (talk) 14:02, 23 December 2015 (UTC)
 * In normal entries, the definitions should be in English, not in a foreign language. User:BAICAN XXX/Protologisms (Romanian) is a user page. We don't have any rule concerning the language of definitions in a userpage list AFAIK.
 * In the future, please use WT:ID for questions like "I would like to learn how this aspect of Wiktionary works."
 * WT:GP is for development/templates/CSS/JavaScript and so on. --Daniel Carrero (talk) 14:35, 23 December 2015 (UTC)
 * (edit conflict) This is really a Beer parlour (policy) issue. The Grease pit is for technical matters. Yes, definitions should be in English, but it's user space and if it keeps that garbage out of the dictionary proper, it might be worth it. Chuck Entz (talk) 14:40, 23 December 2015 (UTC)
 * Ok, thank you for your answers and I apologise for posting in the wrong forum. I'll be more careful next time. --Robbie SWE (talk) 16:21, 23 December 2015 (UTC)

Out of Memory Error at a
Starting in the Portuguese section, everything that uses Lua gets an out of memory error. This has nothing to do with recent edits to the page- old revisions have the same problem. There are only two possible explanations: either a change has been made to one or more of the templates/modules used in the entry that increased memory usage, or the behavior of the system has changed. Someone needs to track this down. I tried previewing a few of the sections, and none of them uses less than a megabyte of Lua memory. Given that there's apparently a limit of 50 MB of available memory, and there are far more than 50 sections on the page, the obvious question is: why is this only starting to happen now? Before you ask, I'm aware that sections probably share some of their overhead, but it still looks like the numbers aren't adding up. Chuck Entz (talk) 04:52, 30 December 2015 (UTC)
 * You should rather be looking into "Related changes" not in its history itself. And I am seeing half a megabyte increase in those related Lua codes. This might be it. Not sure.--DixtosaBOT (talk) 06:55, 30 December 2015 (UTC)
 * What am I supposed to be seeing in the Related changes that could've caused this? The edits to the Chinese modules? In any case, this is a major issue. —Μετάknowledge discuss/deeds 07:03, 30 December 2015 (UTC)
 * It seems like Module:zh/data/skeys was the culprit, because commenting out seems to have fixed it... Is there a way of making it so that the ugly things doesn't load unless needed? —suzukaze (t・c) 07:04, 30 December 2015 (UTC)
 * The "thing" part is only loaded when necessary. Is there any practical and common function in Module:zh that does not use m_data? --DixtosaBOT (talk) 10:48, 30 December 2015 (UTC)
 * Also, in response to this. Yes, it would. Do separate them.--DixtosaBOT (talk) 11:02, 30 December 2015 (UTC)
 * I believe that most of the functions of Module:zh use Module:zh/data, but I'm new to Lua and I didn't write Module:zh (and my Module:zh/data/skeys [a good faith update of insufficient data; why isn't sensible collation of Han characters a part of MediaWiki!?...] seems to be the source of the problems). However it seems like 1. Moving  to inside the skeys function is fine (see Module:Sandbox), and 2.  has no need for Module:zh/data/skeys, and  (present in a) also calls on a lot of unnecessary stuff such as Module:zh/data and Module:zh/data/cmn-hom just to convert pinyin to bopomofo (if I am interpreting "Templates used in this preview" correctly), which may have also contributed to problems. —suzukaze (t・c) 11:12, 30 December 2015 (UTC)
 * 3. zh-hanzi-box uses very large yet awkward chunk of data (at Module:zh/data/glosses). The data is only shown in title (that is, when you hover the main text). How can one allow that? But I guess small entries can enjoy that luxury. --Dixtosa (talk) 19:04, 30 December 2015 (UTC)

 * "Lua memory usage: 15.39 MB/50 MB" I imagined servers groaning but not something like this... —suzukaze (t・c) 07:12, 30 December 2015 (UTC)
 * 50MB isn't much these days. Even my laptop has 16GB. Although maybe the limit is there so they can run many page updates in parallel ... Benwing2 (talk) 17:38, 30 December 2015 (UTC)
 * Servers generally have less RAM than personal computers, and yes, of course they are doing many things at once, so 50MG adds up. --WikiTiki89 17:46, 30 December 2015 (UTC)
 * Depends on the server. Maybe a server devoted to low-intensity tasks would have less RAM, but a compute-intensive server will have more RAM than personal computers. Benwing2 (talk) 17:58, 30 December 2015 (UTC)
 * I meant the average web server, and I don't think Wiktionary is doing anything unusually computation-intensive. --WikiTiki89 18:12, 30 December 2015 (UTC)

Watchlist: pagetitle linking to subsection
When an edit is made to only a subsection we are more likely to want to move to that subsection. And I, personally, find → this symbol difficult to locate xD. So I present a userscript called RushToSubsection, that can make page titles link to the subsection. --Dixtosa (talk) 19:24, 30 December 2015 (UTC)

title: Wiktionary:Grease pit/2015/December


text:
micropolyphonic

Adjective

 * 1) Exhibiting or relating to micropolyphony.

title: micropolyphonic


text: brotsverka

title: brotsverka


text: brotsverket

title: brotsverket