Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

It is said that while the classic beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit

December 2016


The Thai symbol has a broken head-word line and label. The formatting seems fine. I think it has to do with the symbol itself. Maybe it needs to be listed in the Module:th-translit? —Stephen (Talk) 07:28, 1 December 2016 (UTC)

@WyangΜετάknowledgediscuss/deeds 18:01, 5 December 2016 (UTC)
I'm not sure why this occurs - it seems to be a problem with a generic template or module. Wyang (talk) 01:21, 8 December 2016 (UTC)

Automatically generate topical labels from the categories[edit]

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

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

Another point to look at is set-type categories. Membership of a set, such as "days of the week", is not grounds for a context label {{lb|xx|days of the week}} or similar, because that's simply not a topical context. Wednesday is not used primarily when talking about days of the week. So we'll have to exclude set-type categories from the automatic process, which I suppose could be done simply by looking if the parent categories include "List of sets". —CodeCat 20:43, 1 December 2016 (UTC)

  • You're not thinking of the argument I had over the lack of {{lb|xx|languages}}, where I got absolutely nowhere? DonnanZ (talk) 22:22, 1 December 2016 (UTC)
    • That would be one of the cases that should be excluded, since "languages" is not a context. —CodeCat 22:32, 1 December 2016 (UTC)
  • I would prefer if the synonym, antonym, etc. information is subsumed under a single sense template too. Wyang (talk) 23:42, 1 December 2016 (UTC)
    • What does that have to do with this proposal? —CodeCat 00:19, 2 December 2016 (UTC)
      • Topical categories are appending properties of individual senses, so are synonyms, antonyms, etc. Wyang (talk) 00:22, 2 December 2016 (UTC)
        • But this has nothing to do with how entries are formatted. This is only about the underlying works of the label modules. —CodeCat 00:46, 2 December 2016 (UTC)
I like that this would more directly tie senses to categories. The display issue is my only concern, but that can be automated (maybe) or a component of the data. I do wish there was a better way to store the label data, the current structure is awful. - TheDaveRoss 13:53, 2 December 2016 (UTC)
Well, this idea would mean the label data is not stored at all, but derived on the fly from the category data. At least for topical categories, anyway. What is your concern about the label data specifically? —CodeCat 02:11, 5 December 2016 (UTC)
It is a bummer to have to store relational data in a flat file with no way to enforce structure. It would be idea if we could connect modules to an actual SQL database of some kind, so that the data could be stored in a more robust and easily maintained format. An example, there are a number of labels which are "deprecated," but there is no easy way to see which labels those are, or who deprecated them, or what they should be replaced with, etc. The more labels which are available the worse that situation will get. It isn't a design flaw, it is a platform limitation. - TheDaveRoss 14:24, 5 December 2016 (UTC)

Thai transliteration for SoP terms[edit]

It doesn't always transliterate Thai terms when there are more words separated by [ [ ] ]. What needs to happen so that คนลาว is transliterated automatically? คน(kon) and ลาว(laao) work fine separately. @Wyang, Octahedron80, CodeCat What are your opinions? Is it Module:links or Module:th? Hopefully you won't fight but offer a solution :) --Anatoli T. (обсудить/вклад) 02:08, 5 December 2016 (UTC)

Hi Anatoli, I haven't looked into this but AFAIK {{th-x}} offers a similar output - {{th-x|คน ลาว}}: คนลาว (kon laao). Wyang (talk) 01:14, 8 December 2016 (UTC)
@Wyang Thanks, Frank. I know {{th-x}} and other language specific templates work fine for this but unfortunately the other templates and templates don't. Having SoP terms with [ [ ] ] [ [ ] ] is quite common.--Anatoli T. (обсудить/вклад) 01:53, 8 December 2016 (UTC)

"Topic labels" are now always linked, leading to bad red links[edit]

See e.g. Reingold-Tilford algorithm, where "computing theory" is a red link. I have recently seen this on other topic labels too. Has someone introduced a bug here? Equinox 14:10, 5 December 2016 (UTC)

Not a bug so much as a feature that needs fine tuning. You can override the link by specifying display = in the data modules. —CodeCat 15:41, 5 December 2016 (UTC)
No, it's a bug, and I assume you did it. Where was the consensus for this change demonstrated? —Μετάknowledgediscuss/deeds 17:59, 5 December 2016 (UTC)
I also oppose this. --WikiTiki89 18:55, 5 December 2016 (UTC)
@Wikitiki89: Is this the edit in question? I would revert it, but I don't want to make more of a mess by accident. —Μετάknowledgediscuss/deeds 19:01, 5 December 2016 (UTC)
No, seemingly that edit only makes the label link to the English section if it is already a link. --WikiTiki89 19:05, 5 December 2016 (UTC)
Yes check.svg Done: diff. --WikiTiki89 19:23, 5 December 2016 (UTC)

@Wikitiki89 It seems like something went wrong, currently no topic labels are linked, even if they should be (see, e.g., dialog box). --Einstein2 (talk) 22:33, 10 December 2016 (UTC)

Apparently Metaknowledge considers the links a bug, so it was removed. —CodeCat 23:01, 10 December 2016 (UTC)
CodeCat, I find your behaviour very frustrating. I think you know that you are misrepresenting my viewpoint, and are doing so just because I disagree with the change that you made without consulting anyone else, which you have been repeatedly told by many editors in the past to stop doing. That status quo before your changes was perfectly fine. —Μετάknowledgediscuss/deeds 23:18, 10 December 2016 (UTC)
The status quo linked labels inconsistently. With my change, entries were linked by default unless overridden not to, so that labels that needed to be linked now were. What's wrong with that? Now, all links are removed, which is a step back from the former behaviour. —CodeCat 23:23, 10 December 2016 (UTC)
The inconsistency was useful; it linked them where appropriate, and didn't where it wasn't — and we could modify this as we saw fit. I'm not happy with the lack of links either. The problem is that we needed to be having this conversation before your edits, and not after them. —Μετάknowledgediscuss/deeds 00:33, 11 December 2016 (UTC)
All that has changed is that, whereas before, not linking was the default, now linking is the default. In the former case, it could be overridden by providing a linked form, in the new case it can be overridden by providing an unlinked form. So they are functionally equivalent, but because we want links on most terms, linking is a better default than not linking. —CodeCat 02:11, 11 December 2016 (UTC)
That would only be "all that has changed" if you had updated the existing categories to keep their link or non-link status. The sudden appearance of red links as a result of you not doing this is the problem and indeed is the title of this discussion thread. Equinox 11:43, 11 December 2016 (UTC)
Frankly, I would prefer if no topic labels were ever linked at all. --Dan Polansky (talk) 13:43, 11 December 2016 (UTC)
I think that ideally all labels should link to our appendix glossary. Linking to a main entry is a lazy temporary solution. Linking to main entries blindly when they might not even have the relevant content is a really bad solution, even worse than the redlinks. --WikiTiki89 15:10, 12 December 2016 (UTC)
Are you saying that even topic labels, such as Australian rules football or graphical user interface, should have their own lines at Appendix:Glossary instead of linking them to the entries Australian rules football and graphical user interface? – Einstein2 (talk) 14:20, 13 December 2016 (UTC)
Hmm... that is a good a point. Linking to their Wikipedia articles would also not be bad idea. In practice your particular examples are not much of a problem only because it is very unlikely that other new senses will be added to the entries Australian rules football and graphical user interface, so those are not the ones I would prioritize fixing. Certainly for topics whose entries are polysemous or even lacking the relevant sense, it is much more important that we either link to the glossary or the Wikipedia article instead. --WikiTiki89 16:03, 13 December 2016 (UTC)

Can we improve Wiktionary:Translation requests?[edit]

Whenever someone uses this feature we generate "From [insert source language] to [insert target language]" as the subject and "[insert text here]" as the text. Nobody ever (very slight exaggeration) changes "[insert source language]" or "[insert target language]" to actual languages, and neither do they change "[insert text here]" to actual text. Is there an easy way that we can show people what they are actually supposed to do? SemperBlotto (talk) 15:01, 5 December 2016 (UTC)

Oddly enough it seems to have been okay before mid-November or so. Did something change around that time? — Kleio (t · c) 15:27, 5 December 2016 (UTC)
  • It was an attempt by @Kc kennylau to improve the quality of translation requests that was a good idea, in my opinion, but ultimately a failure. I believe he announced it in the BP. —Μετάknowledgediscuss/deeds 18:01, 5 December 2016 (UTC)
  • IMO, a good idea would be to have two dropdown lists, for source and target language. They start off both defaulted to "English"; if the user does not change them such that the two languages differ, the edit is blocked with an explanatory message, telling the user to choose. (No idea if we can do this.) Equinox 19:01, 5 December 2016 (UTC)
  • We could instead block edits that contain the text "[insert text here]", using the abuse filters to provide an explanatory message. Equinox 14:35, 6 December 2016 (UTC)
I think a better idea would be to display a form when you click "Make a new request" which has a field for "Source language", "Target language", and "Text", which will automatically post a new section when submitted, but cannot be submitted unless all three fields are filled. Someone who's good at JavaScript should be able to do that. --WikiTiki89 15:25, 6 December 2016 (UTC)

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

What happens when you do it? Any error message? Equinox 17:56, 8 December 2016 (UTC)
@Equinox: I was unable to save my new section (an English->Japanese request). An error message appeared saying that my edit was recognized as "harmful". Then I disabled the abuse filter. --Daniel Carrero (talk) 16:39, 9 December 2016 (UTC)

In-page anchors at Category:English lemmas[edit]

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

https://en.wiktionary.org/w/index.php?title=Category:English_lemmas&pagefrom=word lists pages in the category starting from 'word'. Is that what you've looking for? —suzukaze (tc) 02:26, 9 December 2016 (UTC)
No, that particular page has quite a bit of content before it gets to the regular category listings, so I'm sure he's talking about specific parts of the page itself. All I can suggest is looking at the page source/inspecting the DOM and finding the closest id= (the body content is nested a number of levels in, so it may take a while if you go the inspecting route), which should work when linked to as something like [[:Category:English_lemmas#<the id>]]. Chuck Entz (talk) 04:24, 9 December 2016 (UTC)
Haha, I'm a user (here), I'm not going to "inspect a DOM". Is there any sane workaround? I can link to sections on most wiki pages, e.g. French or Noun. I am guessing the issue relates to the use of en-categoryTOC in some way...? Equinox 00:36, 14 December 2016 (UTC)
Well, I went ahead and looked at the source: CAT:English lemmas#mw-subcategories should get you to the Subcategories header, and CAT:English lemmas#mw-pages should get you to the 'Pages in category "English lemmas"' header. In most browsers it's just a matter of either right-clicking on the page body and selecting "view source" or hitting control-u if the right-clicking doesn't work, then control-f and search for "id=". Anything following "id=" in the html is an anchor you can link to. Chuck Entz (talk) 04:09, 14 December 2016 (UTC)
I don't really see this as a satisfactory solution because it seems less safe to rely on "internal" HTML ids staying the same than on the editable markup staying the same (all other factors being equal). But I'll use it, because it's only my stupid user page, and I appreciate you taking the time to check it out. (Another downside: apparently I have to use the absolute URI like this [1] and not a normal wiki link that can be red or blue.) Equinox 05:05, 14 December 2016 (UTC)

Displaying Special:WhatLinksHere/ numbers[edit]

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

This question has received answers at Wiktionary:Information desk/2016/December‎#Displaying Special:WhatLinksHere/ numbers. — I.S.M.E.T.A. 17:45, 9 December 2016 (UTC)

Language data edit[edit]

Please add the following to zu:

        entry_name = {
                from = {"[āàáâǎ]", "[ēèéêě]", "[īìíîǐ]", "[ōòóôǒ]", "[ūùúûǔ]", "ḿ", "[ǹńň]", MACRON, ACUTE, GRAVE, CIRC, CARON},
                to   = {"a"      , "e"      , "i"      , "o"      , "u"      , "m", "n"    }},

CodeCat 15:22, 11 December 2016 (UTC)

@CodeCat: Done. Also, what is the situation with hyphens like those in Zulu verbs? —JohnC5 16:45, 11 December 2016 (UTC)
Zulu verbs and adjectives are lemmatised with the bare stem, as is the norm in dictionaries and other reference works. The hyphen indicates that it's not a complete word. —CodeCat 16:47, 11 December 2016 (UTC)
But should we strip them out? —JohnC5 16:57, 11 December 2016 (UTC)
No, because there are genuine suffixes such as -isa as well. —CodeCat 17:15, 11 December 2016 (UTC)
Roger that. —JohnC5 18:12, 11 December 2016 (UTC)

Behaviour of template:lb[edit]

Surely {{lb}} should behave in the same manner with all of the following parameters:

  • Using "archaic"" - places the term in "Category: … terms with archaic senses"
  • Using "obsolete"" - places the term in "Category: … terms with obsolete senses"
  • Whereas "dated"" - places the term in "Category: … dated terms"
why not the Category: … terms with dated sensesSaltmarsh. 12:16, 13 December 2016 (UTC)
I'm asking for someone to modify {{lb}} - or justify this (IMHO) odd behaviour — Saltmarsh. 07:20, 14 December 2016 (UTC)


Template:wikibooks is broken. If you supply it with a language parameter |lang= it will not spit out the correctly displayed language in the description of what Wikibooks is being linked to, unlike the equivalent Wikipedia template.

Wikibooks has more about this subject:
Spanish Wikibooks has more about this subject:
Wikibooks es
Wikipedia has an article on:
Spanish Wikipedia has an article on:
Wikipedia es
{{wikibooks}} {{wikibooks|lang=es}} {{wikipedia}} {{wikipedia|lang=es}}

-- 09:37, 15 December 2016 (UTC)

Is there a template that takes an Wikimedia language code (or ISO-639 language code) and displays the language name? If so, I can fix this template simply. -- 06:47, 20 December 2016 (UTC)
There is a module, invocation as follows: {{#invoke:languages/templates|getByCode|en|getCanonicalName}} returns "English". - TheDaveRoss 14:39, 20 December 2016 (UTC)

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

Problem with Archiver[edit]

The Archiver tool is malfunctioning – I just got the following error message (tried it twice): "Error: The parameters "pageid" and "oldid" can not be used together. [code invalidparammix]". — SMUconlaw (talk) 19:04, 16 December 2016 (UTC)

Me, too. Some more detail: I just tried using aWa to archive wt:RFD#bacter- and got that error message. This happened both with the default (archiving to [[talk:bacter-]] and to [[talk:bacteri-]]) and also (after a reload) after I dropped [[talk:bacteri-]] from the set of targets. I'm running Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0. Does anyone know what's going on, or a fix, please?​—msh210 (talk) 11:43, 19 December 2016 (UTC)
  • I really don't know who is willing and able to fix this. Perhaps @Dixtosa, Giorgi EufshiΜετάknowledgediscuss/deeds 18:37, 19 December 2016 (UTC)
    Didn't Wonderfool write it? What's his current incarnation?​—msh210 (talk) 22:02, 19 December 2016 (UTC)
    No, it was named after him. Kephir wrote it and has long since left. I don't think WF has this kind of technical ability. —Μετάknowledgediscuss/deeds 00:22, 20 December 2016 (UTC)
Can we file a ticket at the Phabricator? Do they work on gadgets? — SMUconlaw (talk) 14:44, 20 December 2016 (UTC)
For future reference, no. Basically, anything we have control over is not the developers' responsibility. The right thing to do is exactly what was done (i.e. "file" a "ticket" at the WT:GP). --WikiTiki89 16:41, 20 December 2016 (UTC)
Fixed diff. --WikiTiki89 16:35, 20 December 2016 (UTC)
Thanks! — SMUconlaw (talk) 18:26, 20 December 2016 (UTC)

Category:etyl cleanup/en[edit]

There are many thousands of terms in this category. What are we supposed to do with them? SemperBlotto (talk) 15:15, 17 December 2016 (UTC)

Something like this. —Aɴɢʀ (talk) 16:49, 17 December 2016 (UTC)
Relatedly, is there any particular reason for which languages have their own etyl cleanup subcategories? Can I add new ones somehow? --Tropylium (talk) 17:34, 12 January 2017 (UTC)


This template produces incorrectly spelled forms. All the forms preceded by a definite or indefinite article should be capialized.

In addition, these same forms should not only be on erster and similar words. They need to be added to both erste and Erste and similar words. --Espoo (talk) 09:46, 18 December 2016 (UTC)

In German the capitalized forms are technically nouns. This template is however meant for the adjective forms i.e. der erste Tag not der Erste. I not sure if we should put an additional declension table for the derived nouns forms, as the only different feature would be capitalization. Matthias Buchmeier (talk) 11:16, 18 December 2016 (UTC)

Template:ISO 639[edit]

Template:ISO 639 appears to be broken

{{ISO 639|zh|zho}} ISO 639-1 code zh, ISO 639-3 code zho (SIL)
{{ISO 639||chy}} ISO 639-3 code chy (SIL)
{{ISO 639|fi}} ISO 639-1 code fi

The auto-generated SIL link gives a 404-not-found for any language code provided -- 05:50, 21 December 2016 (UTC)

Looks like SIL broke it themselves, even internal links on their site to the ISO 639 area are 404. - TheDaveRoss 12:44, 21 December 2016 (UTC)
I got the point. The URL www.sil.org is changed to www-01.sil.org . Looks like they are going to renovate their website. I will follow this until new version comes. --Octahedron80 (talk) 05:08, 22 December 2016 (UTC)


This was formerly a translit module that knew just one of the scripts used by this language. User:Octahedron80 moved that module to Module:Guru-translit and replaced it with:

local out_text
if (sc == 'Guru') then
out_text = require('Module:Guru-translit').tr(text, lang, sc, debug_mode)
elseif (sc == 'Deva') then
out_text = require('Module:sa-translit').tr(text, lang, sc, debug_mode)
elseif (sc == 'Arab') then
-- out_text = require('Module:Arab-translit').tr(text, lang, sc, debug_mode)
out_text = nil
error('Invalid script for Punjabi language.')
return out_text

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

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

The script is already auto-detection from prior module that uses this like headword, so sc input is not needed. It is really useable and the same script tr modules can share among languages. (That's we call 'module'.) Some times ago, I also did this to Module:khb-translit. None of them show error. I'd like to see which page show error. --Octahedron80 (talk) 04:31, 22 December 2016 (UTC)
Sorry, I forgot to add 'pa-Arab' as well. Now no error occur. Until someone make Module:pa-Arab-translit, this case is set to nil for now. --Octahedron80 (talk) 04:49, 22 December 2016 (UTC)

Template:senseid and invisible module errors[edit]

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


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

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


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

@Stephen G. Brown User:DTLHS/Telugu lemmas DTLHS (talk) 16:20, 28 December 2016 (UTC)
Beautiful! Thanks! —Stephen (Talk) 02:57, 29 December 2016 (UTC)

derivsee in Module:compound/templates[edit]

Multiple issues with the output of the derivsee function in the module compound/templates, which is used by {{suffixsee}} and {{prefixsee}}. It doesn't apply any language styles to the word in the title (for instance, ▼ Arabic words suffixed with جي, not ▼ Arabic words suffixed with جي) and italicizes the list of words with the suffix that you get when you click the down arrow. Ideally, both the suffix and the list should display with language-specific fonts, in the same way that the list of words in Cat:Arabic words suffixed with جي does. — Eru·tuon 09:30, 28 December 2016 (UTC)

I'm not sure if we can fix this- we could apply a global style to the header, but it wouldn't be language specific. DTLHS (talk) 01:51, 29 December 2016 (UTC)

Smartphone app?[edit]

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

Spaces needed in Lao translit for usexes with brackets[edit]

Using Module:lo-translit I need to make it work for usexes, please. E.g. ປະເທດລາວ‎ ― pa thētlāo ― Laos (country) has no space after the square brackets, it should insert a space, like this: "pa thēt lāo". Calling @Octahedron80, Wyang --Anatoli T. (обсудить/вклад) 01:47, 29 December 2016 (UTC)

January 2017

New template to replace magic words[edit]

Template:ISBN I have copied over w:Template:ISBN and w:Module:Check isxn from en.wp. Magic words as links are being phased out and although we don't have to replace all instances of them now, they will all be removed from MediaWiki in 2017. See mw:Requests_for_comment/Future_of_magic_links. We currently have over 27,000 entries in Category:Pages using ISBN magic links. A similar situation exits on a smaller scale for PMID and RFC. —Justin (koavf)TCM 03:26, 1 January 2017 (UTC)

Is it confirmed that this is actually going to happen? DTLHS (talk) 03:30, 1 January 2017 (UTC)
@DTLHS: Per mw:Help:Magic links, it's already disabled by default. It's my understanding that it will be removed entirely barring something extraordinary. Either way, it's probably useful to have a local version of the templates or use m:interwiki map links. (Note that pmid was recently added for this reason.) —Justin (koavf)TCM 03:43, 1 January 2017 (UTC)

en-PP doesn't work with head parameter[edit]

See in Abraham's bosom. Equinox 05:14, 2 January 2017 (UTC)

Fixed (it was using 1 as a head parameter, but both should work now). DTLHS (talk) 06:14, 2 January 2017 (UTC)

Phags-Pa script[edit]

Could someone make Phags-Pa display vertically as Mongol script does? Crom daba (talk) 05:28, 2 January 2017 (UTC)

Done (do we need the webkit and moz prefixes now or has writing-mode been fully implemented?) DTLHS (talk) 06:12, 2 January 2017 (UTC)
Unfortunately I'm only vaguely familiar with css/Unicode implementation of Phags-Pa, so I cannot answer that question meaningfully. However, I can confirm that the text displays as it should now, thanks! Crom daba (talk) 19:09, 2 January 2017 (UTC)


Could someone please have a look at {{calque}}? When applying it at king cake, I cannot get a gloss to appear, whether I put it in the fourth parameter position or use |gloss=. The documentation page seems out of date, as using |etyl t= generates an error. Thanks. — SMUconlaw (talk) 07:14, 2 January 2017 (UTC)

I can't figure it out either, and the documentation is definitely out of date. Calques are handled by Module:etymology/templates now, but I can't figure out how. Writing {{calque|en|fr|-|nocap=1}} {{m|fr|galette des rois||[[galette]] of the [[king]]s}} will work properly, but it seems clumsy. @CodeCat, can you help? —Aɴɢʀ (talk) 10:14, 2 January 2017 (UTC)
Looking at Module:etymology/templates makes me think that {{calque|en|fr|galette des rois||[[galette]] of the [[king]]s|nocap=1}} is supposed to work, but I'm not familiar with Lua. — SMUconlaw (talk) 13:59, 2 January 2017 (UTC)
You need to use etyl lang= when using etyl t=, no idea why this was implemented like that yet, but it works if you do it like that. Crom daba (talk) 17:13, 2 January 2017 (UTC)
Thanks. I do hope the template can be regularized and the documentation updated, though. — SMUconlaw (talk) 19:06, 2 January 2017 (UTC)
I had a similar problem in etymology sections of the Russian names of grammatical cases – for instance, винительный(vinitelʹnyj, accusative). I entered glosses into {{calque}} using the |t= parameter, but they didn't display. I added that parameter in the calque function of Module:etymology/templates, but that didn't do anything, since something has to be changed in the calque function of Module:etymology too. — Eru·tuon 23:06, 8 January 2017 (UTC)
It works now, now I just need to figure out how to make a tracking category for deprecated usage and change it, having two 'compat' variables can't be good. Crom daba (talk) 03:14, 10 January 2017 (UTC)
Turns out we already have a tracking template for this: Special:WhatLinksHere/Template:tracking/calque/etyl.
I removed all uses of deprecated lang=, but etyl lang= is too numerous, someone will have to do it by bot. Crom daba (talk) 09:52, 10 January 2017 (UTC)


Would an administrator please review and process the edit request on MediaWiki talk:ExtractFirst.xsl? Didn't know where else to post this. Xaosflux (talk) 00:00, 3 January 2017 (UTC)

Done. DTLHS (talk) 00:03, 3 January 2017 (UTC)

Etymology-only language whose parent is also an etymology-only language[edit]

At neenish tart I find that {{etyl|de-AT-vie|-}} displays correctly as "Viennese German", but {{cog|de-AT-vie|-}} creates a module error "attempt to index local 'parent' (a nil value)". I suspect that's because Module:etymology languages/data lists the parent of de-AT-vie as de-AT, which is itself an etymology-only language with de as its parent. The easy way to fix this would be to simply change the parent of de-AT-vie to de, but I wonder if it wouldn't be preferable to allow {{cog}} to accept etymology-only languages with etymology-only parents. —Aɴɢʀ (talk) 17:22, 3 January 2017 (UTC)

I'm not sure if that's the same problem, but at Albania I tried to change the part "From {{etyl|gkm|la}} {{m|grc|Ἀλβανία}}" to {{bor|la|gkm|Ἀλβανία}}, which didn't work because gkm (Byzantine Greek) is an etymology-only language. That doesn't really make sense. Why not allow this? --Florian Blaschke (talk) 17:35, 15 January 2017 (UTC)
Works fine for me. Did someone fix it in the meantime? Crom daba (talk) 00:59, 18 January 2017 (UTC)

Fixed your problem @Angr. Crom daba (talk) 01:13, 18 January 2017 (UTC)

Need for Template:der4-u[edit]

We have {{der3-u}}, which is very useful, but I think an additional template {{der4-u}} would be useful in cases like this one. DonnanZ (talk) 15:17, 8 January 2017 (UTC)

Why can't these templates automatically decide how many columns to use? —CodeCat 16:55, 8 January 2017 (UTC)
They could... what thresholds would you recommend for the number of columns? DTLHS (talk) 16:56, 8 January 2017 (UTC)
Four is usually adequate, five looks too crammed I think, but would be the absolute limit. DonnanZ (talk) 17:13, 8 January 2017 (UTC)
I meant, what thresholds for the number of entries in the list should a theoretical automatic template use to decide the number of columns. DTLHS (talk) 17:22, 8 January 2017 (UTC)
Ah, that's a tricky question. The list for yrke has over 100 entries and is still lengthy, so changing from 3 to 4 columns with about 40-50 entries I guess. From 2 to 3 columns with about 10-15 entries would be about right. Thanks for the template, I've got some work to do this evening! DonnanZ (talk) 17:41, 8 January 2017 (UTC)
It would probably also depend on how long the words are, and whether they have transliterations. That is important for Ancient Greek, in which words can be long and they always have transliteration. If a module could count the number of characters in the output of Module:links, then perhaps the number of columns could be based on that somehow. Then again, I have no idea if this is possible. — Eru·tuon 23:02, 8 January 2017 (UTC)
There's also the CSS column-count attribute- I don't know if there's a technical reason we couldn't just use that to balance the columns. DTLHS (talk) 23:04, 8 January 2017 (UTC)
A fixed column count won't work if the screen isn't wide enough to fit all the columns onto. —CodeCat 23:07, 8 January 2017 (UTC)
Apparently there is a column-width property as well. If you set that, then it automatically uses as many columns as can fit on the screen. It's still not ideal, because on a wide screen a list of 10 items might be spread over 10 single-item columns, which is pretty awful too. Ideally, there'd also be a minimum height: fill up the first column, then overflow to the second once the first exceeds the minimum height. Repeat this until all columns are full, and only then, if there are still more items, should the columns be made taller and rebalanced as necessary. —CodeCat 23:11, 8 January 2017 (UTC)
I think the French Wiktionary already uses column-width FWIW. —suzukaze (tc) 23:14, 8 January 2017 (UTC)
Can you give an example of a large list on fr.wiktionary that is split into columns? —CodeCat 23:28, 8 January 2017 (UTC)
fr:manger. —suzukaze (tc) 00:02, 9 January 2017 (UTC)
From what I can see, there is no minimum height, so you can end up with one item in each column. This appears several times in "manger", with very short columns. I'm not sure if there is a way around this, the column-fill property doesn't seem to be a solution. Now if only min-height worked with columns... —CodeCat 00:10, 9 January 2017 (UTC)
There's a third property, column-fill: auto, which makes the first column fill before the second, then the third, etc. There are some downsides with this too, though. Firstly, it seems to only work in Firefox. Secondly, it requires specifying a maximum height for the list, so that the algorithm knows when to start filling the next column. Thirdly, if there's too many columns, they continue off-screen rather than making the list taller, since the height is a hard limit (and min-height doesn't work). —CodeCat 23:32, 8 January 2017 (UTC)

Module:hyphenation and automatic syllable counting[edit]

An editor added an automatic syllable counting feature to Module:hyphenation which is great, but there needs to be a way to either suppress (e.g., with |nocat=1) or manually override (e.g., with |syllables=3) the category generated because (1) the feature doesn't work properly when an entry has two or more words (e.g., venire facias de novo); and (2) there may be instances where the preferred hyphenation does not accurately indicate the number of syllables (e.g., symbolism). Please see the discussion at "Module talk:hyphenation#Automatic syllable count". Thanks. — SMUconlaw (talk) 17:15, 8 January 2017 (UTC)

It would be better to base syllable count on IPA transcriptions. @CodeCat and I have made a module that does this – Module:syllables – but no one has integrated it into Module:IPA yet. — Eru·tuon 22:57, 8 January 2017 (UTC)
I agree. I don't know who activated the syllable count in Module:hyphenation – any idea? Perhaps we should turn it off first, and work on your Module:IPA project? Who can assist with this? — SMUconlaw (talk) 16:12, 9 January 2017 (UTC)
@Smuconlaw: It seems that @IvanScrooge98 recently activated this feature in mod:hyphenation for English with this edit. This certainly is not correct as English hyphenation does not always represent English syllabification but is actually an unrelated set of rules for typography. We should definitely turn this off. —JohnC5 21:39, 9 January 2017 (UTC)
Thanks. I reverted that edit for the time being. — SMUconlaw (talk) 07:54, 10 January 2017 (UTC)
Oh, I obviously didn't mean to cause any problems. Thanks for reverting my edit. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 13:25, 10 January 2017 (UTC)

Module:IPA and Module:syllables[edit]

@Smuconlaw: @CodeCat and I posted about the syllable-counting function earlier, but nobody seemed to be interested in helping. I am not sure who to ask: perhaps @DTLHS, who seems to understand module code well, though he hasn't edited Module:IPA yet? — Eru·tuon 21:10, 10 January 2017 (UTC)
@Erutuon Which function from Module:syllables should I be using? DTLHS (talk) 21:40, 10 January 2017 (UTC)
And should I enable it for English only or for all languages? DTLHS (talk) 21:41, 10 January 2017 (UTC)
Module:syllables was never really "finished off" and brought into a ready-to-use state. I have no reason to think it won't work, but there's several different functions still in there for testing out different approaches and displaying testcases. —CodeCat 21:54, 10 January 2017 (UTC)
OK, let me know when it's finished. DTLHS (talk) 21:59, 10 January 2017 (UTC)
@DTLHS: I'm a little more optimistic about the module than @CodeCat; I think the function getVowels, which CodeCat created, is ready for deployment in at least the languages that currently have their diphthongs defined in the module. It should only be applied to for phonemic transcriptions, which are likely to be better regulated than phonetic transcriptions. My functions are unlikely to yield anything and could be deleted or moved. — Eru·tuon 22:41, 10 January 2017 (UTC)
Now added. DTLHS (talk) 22:59, 10 January 2017 (UTC)
@Erutuon Could you keep an eye on the various syllable categories that will now be filling up? I've already noticed some mistakes like "abstractional" being marked as having 3 syllables (although it could be a mistake in the transcription). DTLHS (talk) 23:04, 10 January 2017 (UTC)
Also NCAA has 13 syllables for some reason. DTLHS (talk) 23:06, 10 January 2017 (UTC)
More oddities: adore, abear, abler, bacteria, avocation, Liberia, Nigeria, February, gargantuan. DTLHS (talk) 23:12, 10 January 2017 (UTC)
Hmm, the problems with abstractional, adore, and some of the others are due to the transcriptions (which in the case of abstractional could be respelled as ab-STRAK-shnull; in the case of adore, the diphthong /oə/ the non-General American transcription /əˈdoə/ is being interpreted as two-syllable /o.ə/, giving a three-syllable count). For NCAA, I suspect the problem is that the module is somehow counting the syllables inside the various templates that make up {{IPA letters}}. There should probably be a parameter for turning off syllable-counting: |syllab=-, perhaps. Or I could edit the transcription of adore to add a nonsyllabic diacritic (/oə̯/). — Eru·tuon 23:46, 10 January 2017 (UTC)
Sometimes a variant ending is given without repeating the entire transcription- not sure what the best way to deal with that would be. DTLHS (talk) 00:08, 11 January 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Some thoughts:

  • The syllables should be automatically counted based on the first full IPA transcriptions provided, ignoring variant syllables.
  • Syllables should be counted for separate language variants, for example, Received Pronunciation and General American. It is possible that pronunciation differences may lead to different syllable counts for the same word. In this case, it would make sense for the module to categorize the word as having, for example, both three syllables and four syllables.
  • The module should be able to deal with multiple-word entries, such as venire facias de novo (nine syllables altogether).
  • Consider whether it is desirable to (1) allow manual suppression of syllable counting using |nocat=1; and (2) allow manual overriding of the syllable counting using |syllables=3 if the module is generating an erroneous result (and probably automatic tracking of such cases in a category so that either the entry or the module can be fixed, if necessary).

SMUconlaw (talk) 06:37, 11 January 2017 (UTC)

The module is now counting the syllables in the complete transcriptions in venire facias de novo correctly, since it is transcribed as having ten syllables. There was an unrecognized diphthong in the earlier transcription, /ʌɪ̯/ which I should probably add to the module, since it's used by the OED. — Eru·tuon 07:30, 11 January 2017 (UTC)
Thanks! The syllable counting still seems a bit erratic, though. I was looking at "Category:English 10-syllable words", but don't carboxymethylcellulose and psychoneuroimmunology have only eight and nine syllables respectively? Also, perhaps the categories should be renamed "Category:English 10-syllable terms" as our entries often consist of more than one word. — SMUconlaw (talk) 07:55, 11 January 2017 (UTC)
Psychoneuroimmunology is now categorized correctly after I added the alternative transcription /ʌɪ/ to Module:syllables, but carboxymethylcellulose has a really odd transcription: /ˈkær.bɒks.ɪi.mɛɵ.əlˌsɛl.jʊ.ləʊz/. /ɪi/ and /ɛɵ/ added two extra syllables. The transcription was added by @Thryduulf, and I remember seeing another like it before. Fixed the transcription, and now it's counted as having 8 syllables. — Eru·tuon 08:41, 11 January 2017 (UTC)
Oh, and you're right, the categories should certainly say terms and not words! — Eru·tuon 08:42, 11 January 2017 (UTC)

I found a solution to the partial transcription problem. I changed the function in Module:syllables to return nil if there is a hyphen at the beginning or end of the transcription, but it results in a module error since Module:IPA still tries to add the category, so I will have to revert it. Can be reinstated once Module:IPA is made to recognize it. — Eru·tuon 07:21, 11 January 2017 (UTC)

@Erutuon Made you a template editor. DTLHS (talk) 16:27, 11 January 2017 (UTC)
@DTLHS Thanks! I'll try to use the ability responsibly. — Eru·tuon 20:40, 11 January 2017 (UTC)
Note the existence of Category:English 0-syllable words (and other languages). DTLHS (talk) 17:11, 11 January 2017 (UTC)

@Erutuon, note this version of knuckle sandwich. I think the module may need tweaking so that it only counts the syllables in the first parameter of each {{IPA}} template on each line, ignoring subsequent parameters or {{IPA}} templates. — SMUconlaw (talk) 16:54, 15 January 2017 (UTC)

I guess I don't agree with only syllable-counting the first transcription. If there are multiple pronunciations, and they have different syllable counts, the word should be placed in multiple categories. Now February has a lot of variant pronunciations, so it's categorized as four-, three-, and two-syllable. The standard pronunciation would be four-syllable, and the two-syllable pronunciation is probably considered incorrect and cannot be recommended to a second-language learner who wants to sound intelligent. Yet since Wiktionary has entries for common misspellings, it makes sense to show mispronunciations and categorize words by the syllable count in those mispronunciations, not just the syllable count of the more correct pronunciation.
However, we need a solution for that edit in knuckle sandwich, where an alternative transcription of one of the constituent words of the compound was having its syllables counted. I'll have to think more about that. — Eru·tuon 17:46, 15 January 2017 (UTC)
Good point. If it is impossible to distinguish between transcriptions that should be counted and those which shouldn't be, you may just have to allow editors to manually suppress counting of certain transcriptions by adding a parameter, or manually edit transcriptions (like I did in this case) to stop them from being counted. — SMUconlaw (talk) 18:10, 15 January 2017 (UTC)

Template:reply to[edit]

I just noticed that while {{reply to}} generates a final colon as expected, using the redirect {{ping}} causes the colon to be omitted. What gives? --Florian Blaschke (talk) 19:08, 10 January 2017 (UTC)

Oh, I see the problem. {{ping}} is actually a separate template, while {{Ping}} with upper case is a redirect. That's confusing. Instead, {{ping}} should be a redirect too. --Florian Blaschke (talk) 19:10, 10 January 2017 (UTC)

External links with accents[edit]

These used to work and I don't know what happened: see the link at xiïta or verosímil compared to colze or portavoz -- okay actually neither of the Spanish ones is working so...huh. Ultimateria (talk) 20:54, 10 January 2017 (UTC)

@Ultimateria: DRAE doesn't have an entry for "xiïta" which is a Catalan term anyway. If the "id" is changed to "w" in the URIs, it works correctly for verosímil, though. —Justin (koavf)TCM 20:59, 10 January 2017 (UTC)
Oh god this is what I get for using keyboard shortcuts haha. As for verosímil, I don't know why it wasn't working 5 minutes ago and now it is. Thanks! Ultimateria (talk) 21:08, 10 January 2017 (UTC)
@Ultimateria: This is why. For some reason, the RAE assigns another id to word, so that the same content is available at both http://dle.rae.es/?w=veros%C3%ADmil and http://dle.rae.es/?id=beuYWd7 and the former redirects to the latter. I guess I can understand why they would want unique URIs for non-ASCII terms but why "hola" needs two forms I don't know. Glad I could help~ —Justin (koavf)TCM 04:20, 11 January 2017 (UTC)

more intuitive templates[edit]

We should make all templates more intuitive. F.ex. the head template is so hard to use or so defective that whoever has edited lying so far, including me, was incapable of adding the only information users are looking for when they look it up: whether it is the correct spelling of the present participle of only one of the two homographs and homophones lie.

At the very least, the entry should have this information in two different entries. Now it is even more misleading by having an example for only one of these two verbs. --Espoo (talk) 00:18, 11 January 2017 (UTC)

What would you ideally like the page to look like? DTLHS (talk) 00:30, 11 January 2017 (UTC)
First easy explanations of only the important features, followed by details farther below. And in this case, also an easy explanation for adding links to different homographs in the etymology and head templates. I couldn't find any info on this and therefore had to remove the templates. --Espoo (talk) 00:41, 11 January 2017 (UTC)
Actually, first I would say human readable entries. I am appalled to see MewBot (and probably others) replacing {{label|... with {{lb|... since it clearly indicates the mindset of the developers/maintainers of the template infrastructure is focused on manually typing in abbreviated and obfuscated jargon rather than maintainable content. - Amgine/ t·e 05:56, 13 January 2017 (UTC)
The substitution of {{lb}} for {{label}} seems exactly the opposite of how we could educate new users about the intent of template.
At the time of initial entry an experienced user should be able to save keystrokes by typing "lb".
At the time of editing a new user should have more self-evident template names to speed natural learning.
A bot could and should help us achieve both desiderata by expanding the terse to the full form. Is doing the opposite supposed to reduce the storage requirements for en.wikt? I don't see any other advantage to it. Some ideal JS system might be able to achieve the same result with only terse template names, but full displays, but we don't have that system and we don't seem to have many users with the time, skills, and inclination to develop such a system. What we have is a system of templates that seems designed to intimidate any new user with its terseness. This seems to defeat our wikiness, which is the main competitive advantage we have over our commercial competitors as a monolingual dictionary. DCDuring TALK 19:24, 13 January 2017 (UTC)
And yet we have more contributors than ever in the past. Some actual evidence that new users are intimidated by templates is required. DTLHS (talk) 19:30, 13 January 2017 (UTC)
The point has been made that the new contributors are doing translations. My concern is with en.wikt as a monolingual dictionary. The quality of our English entries will not be sustained without many English language editor willing and able to improve definitions. I fear that the uneven, too often poor quality of our English entries will not sustain good translations. DCDuring TALK 00:02, 14 January 2017 (UTC)
What does that have to do with templates? Improving basic English entries is a highly technical and time consuming task, regardless of the data structures behind the entry, and requires experienced editors familiar with lexicography. I do not think that random IPs are going to contribute much in this area. DTLHS (talk) 00:12, 14 January 2017 (UTC)
I believe that any needless obscurity in the wikitext, such as {{lb}} instead of {{label}}, serves to discourage new contributors, who may or may not have registered, from contributing. I assert to that the quality of many of our definitions is such that many could be improved even by "random IPs". There is plenty of work for the more experienced editors to clean up entries which "random IPs" identify as lacking something by their efforts to add or revise definitions. {{m}}, {{l}}, and some others are similarly excessively cryptic. DCDuring TALK 00:43, 14 January 2017 (UTC)
Since we're asserting things without evidence, I assert that we should change our logo to a picture of a cat and make all our text red and with a font size of 60 points in order to attract new contributors. DTLHS (talk) 00:50, 14 January 2017 (UTC)
The Grease Pit is virtually a user-fact-free zone. There is virtually no element of our current layout, template design, category structure etc. that is supported by evidence, though some items are not controversial. The fact is that we have operated with the only effective input being from experienced editors (except when that too is ignored). What evidence we get of new-user dissatisfaction is at best anecdotal and of discouragement virtually non-existent. It would be a miracle if that fact were not to lead to a Wiktionary editing interface and design designed principally to suit the preferences, taste, and whims of the active experienced editors. DCDuring TALK 15:35, 14 January 2017 (UTC)
There's evidence like this. Just as we use spelling errors to tell us about ancient pronunciation, we may learn something from formatting errors. Chuck Entz (talk) 17:06, 15 January 2017 (UTC)
Such evidence is strictly anecdotal. We don't compile it in a useful way. My imagination fails me when it comes to collecting data by which how we can improve our understanding of the process by which we attract and retain new contributors. DCDuring TALK 20:50, 15 January 2017 (UTC)
It is easy to add a feature to replace short template names to full names in the editing box for users, and again replacing them with the original (short) form when saving the page, but are we sure that full template names make the page code more readable? For example, changing "l" to "link" would make the page even more unreadable without much benefit, unless you also add names for unnamed parameters, which would make the page quit unreadable. Changing "label" to "lb" may be not very necessary as it is not used frequently unlike m and l and saving keystrokes is not a priority there. What would you do about {{head}}? Users need to see the docs, I can't think of any alternative way. We can show users a full form asking them to enter data for templates which have a lot of parameters, like what en.wp does with its citation templates, but that's also time-consuming for editors. --Z 08:16, 14 January 2017 (UTC)
Thanks for giving the matter serious consideration. You may be right.
I still wonder how we could make our templates, especially the commonly used ones, more accessible and, especially, make their functions more intelligible. I don't think that Wiktionary:Templates, even after correction, updating, and addition of missing material addresses the need for giving less experienced and devoted editors some means to grasp what the templates are supposed to accomplish. I am pretty sure that the most common way of learning here and generally is to imitate something that seems to work, but documentation is also sometimes useful. We have documentation that, when done well, meets the needs of experienced editors and others facing situations new to them. One thing we don't have is documentation that provides an overview that would help with selection of templates for different purposes or parts of an entry. Such documentation and links thereto from edit windows might help users accept and learn our practices, at least the rational ones. DCDuring TALK 15:35, 14 January 2017 (UTC)
I think the biggest problem for newbies is reaching template documentation, it simply wouldn't occur to most people to type in "template:..." into the search bar. If we had a way to display documentation as a pop-up in the edit window I think it would go a long way. Crom daba (talk) 03:01, 15 January 2017 (UTC)
WikEdit on Wikipedia has the feature where you control–click on a template name to open up the template page. That would be sort of useful, though people would have to know how to use it. — Eru·tuon 05:03, 15 January 2017 (UTC)
As useful as such a means of access might be for someone like me, learning or relearning the workings of a template or template feature that I rarely use, something a little more obviously available would be useful for new users, especially unregistered users. For registered users we could at least provide them with a welcome message in principle with links to documentation helpful to them. I don't think our welcome message (Wiktionary:Welcome newcomers?) does this very well. DCDuring TALK 13:13, 15 January 2017 (UTC)
Looking back on my experience, when you're a new user, every template is a template you rarely use. I don't think anyone is interested in reading 1000 words of documentation to learn about the entry layout or whatever, you mostly just copy stuff from other pages and then try messing around with it, breaking something in the process because you didn't find the relevant template documentation. Crom daba (talk) 14:47, 15 January 2017 (UTC)
Of course this applies only to those newbies that start looking at the code at all, we could probably attract some folks by having more gadgets which allow contributing without looking at the code. Crom daba (talk) 14:47, 15 January 2017 (UTC)
The latter is what seems to have worked for translations, which seems to be the area generating the most activity from new contributors. The structured nature of the potential translation contributions must make it easier to have such relatively intuitive gadgets. And the contributors seem to be motivated to advocate for their culture by adding translations. How many are as motivated to add synonyms for each sense of a polysemic English term or fill in other gaps in our English sections? DCDuring TALK 15:06, 15 January 2017 (UTC)
Links to templates used can be found at the bottom of the page when you preview an edit. Previewing should be encouraged as much as possible, because it gives a better ability to try things and see how they work without making a mess. Chuck Entz (talk) 17:06, 15 January 2017 (UTC)
That's certainly useful, even indispensable, but is it sufficient to help rank newbies? I think not. DCDuring TALK 20:50, 15 January 2017 (UTC)
Agreed. But my point is: why are we ignoring the practice of developers? There is a mantra that to be maintainable - by many different people with differing degrees of familiarity with the over-arching code project - use descriptive (and if possible standardized) names for variables, for methods, use plenty of white space to make things simple to interpret, do one thing on a line, etc. The same should be true for wiki entries. Saving keystrokes now costs time later. By all means use gadgets and bots to simplify data entry, which means you do not need to save keystrokes because the gadget does it. - Amgine/ t·e 05:30, 16 January 2017 (UTC)
You make a very good point. Rather than having shortcut redirects to templates, we could offload this to JavaScript which could automatically expand the shortcuts when the user types them. —CodeCat 16:55, 16 January 2017 (UTC)
Many templates, such as the inflection table templates, don't even have documentation in the first place, even though they're hardly intuitive. Very annoying even for experienced contributors like me. Constant changes over the years in how Wiktionary works don't help, either. I remember that Dbachmann was very interested in contributing, but found all the technical mumbo-jumbo off-putting, and when even someone like him complains about excessively high obstacles for would-be contributors, it means things are bad. --Florian Blaschke (talk) 21:18, 17 January 2017 (UTC)

Categories for x-syllable terms[edit]

As Smuconlaw said above, it would be better if categories for syllable count were titled in the format English 2-syllable terms instead of English 2-syllable words, because many entries (for instance, venire facias de novo) contain multiple words, and there are also entries for bound morphemes (-ed) and clitics (-’s). I understand that the categories for number of syllables involve Module:category tree/poscatboiler/data/words by number of syllables, and presumably this should be moved to Module:category tree/poscatboiler/data/terms by number of syllables, but I do not know what else would be involved in a change like this. I imagine there are many categories that will have to be moved as well, which should be done by bot.

Would everyone agree with a change from words to terms in syllable-count categories? — Eru·tuon 22:08, 13 January 2017 (UTC)

  • Symbol support vote.svg Support! — SMUconlaw (talk) 13:05, 14 January 2017 (UTC)
  • Symbol support vote.svg Support --Daniel Carrero (talk) 13:08, 14 January 2017 (UTC)
  • Symbol oppose vote.svg Oppose. I don't think we should be categorising multiword terms by syllable count at all. —CodeCat 14:09, 15 January 2017 (UTC)
    • What about compounds such as the above-mentioned knuckle sandwich that are really a single word written as two? — Eru·tuon 17:55, 15 January 2017 (UTC)
      • Aren't those still "terms"? — SMUconlaw (talk) 18:11, 15 January 2017 (UTC)
        • Right, but I'm asking CodeCat for clarification on what multiword means. — Eru·tuon 18:46, 15 January 2017 (UTC)
          • The definition Wiktionary uses is anything with a space in between. —CodeCat 19:54, 15 January 2017 (UTC)
            • So you mean that single-word entries should be counted, but multiple-word entries should not be? Well, it's conceivable that knowing how many syllables there are in a multiple-word entry might be useful for someone composing poetry ... but of course I have no idea how often poets use the Wiktionary. — SMUconlaw (talk) 11:02, 16 January 2017 (UTC)
              • @Smuconlaw: Of course, this is a chicken and egg problem where no one could or would use Wiktionary for writing lyrics or poetry if we don't have those features. We should strive to have the most comprehensive dictionary in the world: etymologies, rhymes, appendices, thesaurus, definitions of all terms for all languages, etc. —Justin (koavf)TCM 17:45, 16 January 2017 (UTC)

Bug (ungrammatical text) in Alerts dropdown[edit]

It says "Your reverted." instead of "Your edit was reverted." This used to be correct, but it looks as though someone (presumably a developer outside of Wiktionary?) has broken it. Equinox 02:53, 17 January 2017 (UTC)

Is it fixed for you now? I think I found the message, but when I tested before changing it worked as expected. - TheDaveRoss 16:38, 17 January 2017 (UTC)
Yes (though the older message still exhibits the problem; I assume it was generated and permanently saved in that form). Equinox 16:41, 17 January 2017 (UTC)

Bug in rhyme-adding script?[edit]

Go to Rhymes:English/ɛstə(ɹ) and, using the automatic buttons, attempt to add wester. Unlike other words, this one fails with "ERROR:TypeError: Cannot read property 'parentNode' of undefined". (Actually, it seems to have worked, but my screen gave the error and did not visually add the word.) Equinox 23:48, 17 January 2017 (UTC)

There's also another bug: it doesn't use {{l}}. —CodeCat 00:04, 18 January 2017 (UTC)
Where is the rhyme adding script actually located? DTLHS (talk) 00:14, 18 January 2017 (UTC)
I followed a link after adding a rhyme, and came to the talk page User talk:Conrad.Irwin/editor.js, which mentioned rhymes. But the corresponding js page doesn't use the word "rhyme", though, so maybe the JS for the rhymes adder is located somewhere else. — Eru·tuon 04:49, 18 January 2017 (UTC)