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


June 2016

Insertable diacritics[edit]

I already posted this in May's Grease pit, but no one responded, so I'm saying it again here: Something's going on with the box of clickable characters governed by MediaWiki:Edittools. In Burmese and Devanagari, clicking any of the combining characters causes the character to appear twice. (For example, if I click on ा in Devanagari, what appears is ाा.) This doesn't seem to be happening for combining characters in the other scripts, though I haven't checked everything. Also, for Khmer, clicking any of the combining characters causes all of them to appear in the edit box.

I've also noticed a problem I was unaware of when I mentioned the above: the combining diacritics for Greek don't work anymore either: they're all bunched together instead of being separate, and clicking on them doesn't do anything. The combining diacritics for Cyrillic still work, though. —Aɴɢʀ (talk) 14:04, 1 June 2016 (UTC)

I fixed the Devanagari. Essentially the problem was that you nested some of the diacritics in two layers of class="charinsert Deva". I'll take a look at the others a bit later. --WikiTiki89 16:21, 1 June 2016 (UTC)
Thanks for your help! I think I fixed it for Burmese too (I was missing a </span> or two). The Greek and Khmer seem to be different issues. —Aɴɢʀ (talk) 16:25, 1 June 2016 (UTC)
I fixed Khmer (the problem was that there was no space between them). I cannot figure out what is wrong with Greek. I tried so many different things that I thought for sure would have worked, but they didn't. --WikiTiki89 20:48, 1 June 2016 (UTC)
Thanks for your help! It's weird that all of them used to work fine and then stopped even though the source text hadn't been edited. —Aɴɢʀ (talk) 22:07, 1 June 2016 (UTC)
  • FWIW, it seems like the MediaWiki folks are doing something that affects the underlying implementation of Edittools. See https://phabricator.wikimedia.org/T132741 for instance, where I posted about newlines -- these also used to work, and then suddenly the behavior changed without any edits to the relevant Edittools page here on Wiktionary. ‑‑ Eiríkr Útlendi │Tala við mig 20:46, 9 June 2016 (UTC)
  • Hmm, no changes to the Edittools page or any of my Javascript settings, yet suddenly Edittools isn't working: it renders correctly in the edit view, but now mousing over shows the text caret instead of the clickable cursor, and clicking doesn't do anything but move focus out of the edit textbox. Is someone mucking about with the EN WT server? ‑‑ Eiríkr Útlendi │Tala við mig 23:24, 9 June 2016 (UTC)

ISO code for Elfdalian[edit]

It now has a code: [1]. We should probably change our entries to reflect it. —CodeCat 22:15, 1 June 2016 (UTC)

Indeed we should. @-scheΜετάknowledgediscuss/deeds 22:30, 1 June 2016 (UTC)
I agree. Previous discussion and an explanation of where we got the non-ISO code dlc from is at Template talk:dlc. Like the switch of Dhuwal from duj to dwu, described at WT:RFM#Dhuwal, it seems like a boring rote busywork task a bot could do. - -sche (discuss) 23:02, 1 June 2016 (UTC)
I copied the existing language data to "ovd", and marked "dlc" as deprecated via a mechanism I just added to Module:languages. You can see all uses of the code here. —CodeCat 12:28, 4 June 2016 (UTC)


Hey. Can someone make me a page with all entries containing head|es|noun like in the link, please? --J19idf (talk) 11:33, 4 June 2017 (UTC)

how bout a search result --Dixtosa (talk) 11:38, 4 June 2016 (UTC)
Better search (yours also included noun forms). Redboywild (talk) 12:11, 4 June 2016 (UTC)

problem at [edit]

The bottom half of the page is filled with the error message Lua error: not enough memory ?? -- 11:00, 6 June 2016 (UTC)

Technical problems :( The solution has not been actively searched for. —suzukaze (tc) 11:11, 6 June 2016 (UTC)
I have commented out the usage of {{zh-pron}} until it gets optimized. I am sure it gets the content of the entry and applies some regex on it. --Giorgi Eufshi (talk) 11:18, 6 June 2016 (UTC)
Of which entry? Wyang (talk) 11:20, 6 June 2016 (UTC)
The entry that uses it? No? whatever it made the whole Japanese section useless so I had to remove it. --Giorgi Eufshi (talk) 11:21, 6 June 2016 (UTC)
No it does not. Wyang (talk) 11:24, 6 June 2016 (UTC)
It does seem to be rather resource-heavy though, calling on all sorts of data modules. —suzukaze (tc) 11:59, 6 June 2016 (UTC)

Unexplained attention category[edit]

Did I do something wrong here that is causing graciozzo to appear in Category:Ladino terms needing attention and Category:attention lacking explanation? —Aɴɢʀ (talk) 19:01, 8 June 2016 (UTC)

Nope. This was the problem. --WikiTiki89 19:10, 8 June 2016 (UTC)


How is the "___TOC___" and "___NOTOC___" here? Sobreira (talk) 11:55, 9 June 2016 (UTC)

Category for "Republic of the Congo"[edit]

Why isn't there any category for "Republic of the Congo"? ばかFumikotalk 01:24, 10 June 2016 (UTC)

I guess no one's made one yet. It's a wiki, {{sofixit}}. But I do find our country categories rather confusing. We have categories for most countries in Africa, but they aren't in Category:Countries of Africa; rather, they're in Category:Africa. Likewise for the other continents. It seems counterintuitive to me. —Aɴɢʀ (talk) 11:37, 10 June 2016 (UTC)
Countries of Africa is for terms that are names of countries of Africa. Terms related to the Republic of the Congo aren't a subset of that. —CodeCat 13:04, 10 June 2016 (UTC)
On a related note, there's been no distinct category for the dozens of French words that fr.Wikt says are specific to either the DRC or the ROC but not both, but the solution proposed in August 2015 could be implemented if anyone wanted to start adding more of those words. - -sche (discuss) 14:39, 10 June 2016 (UTC)

Template:der3 (etc.)[edit]

I would like to use this template with its self-balancing properties for Norwegian, but there's a problem with the letters æ, ø, and å which are sorted out of alphabetical order. These are the last three letters of the Norwegian and Danish alphabets (after z); for example "å" is automatically sorted under "a" which is totally unsatisfactory. Is there any way of amending the template to cater for this, or am I missing something? DonnanZ (talk) 10:36, 12 June 2016 (UTC)

The same problem occurs with Swedish, where the last four letters in the alphabet are z, å, ä, and ö. This problem doesn't occur in German, where words starting with ä, ö, or ü are included in dictionaries under a, o, and u respectively. Perhaps the answer is another template with the self-balancing facility, but without the self-sorting facility for certain languages. It would then be up to the editor to do the sorting into the correct alphabetical order for the language. DonnanZ (talk) 14:34, 12 June 2016 (UTC)

@Donnanz The module uses the sort key and entry name fields as defined in Module:languages/data2. Someone should be able to add the correct rules which will make {{der3}} sort as you expect. DTLHS (talk) 16:21, 12 June 2016 (UTC)
Thanks, but nothing has materialised yet. Another shortcoming with this template seems to be the inability to have more than one entry on the same line, e.g. different forms of the same word. DonnanZ (talk) 16:09, 18 June 2016 (UTC)
I would need a complete description of the sorting rules for Norwegian and Danish to add the proper sort keys. You can leave off the "lang" parameter and the terms won't be automatically linked, so you can put whatever you want on each line. DTLHS (talk) 16:14, 18 June 2016 (UTC)
The Danish and Norwegian alphabets are exactly the same, and are shown here in [2]. They are exactly the same as English up to Z, followed by Ææ, Øø, and Åå in that order. The Swedish alphabet is also mentioned in the article, where Z is followed by Åå, Ää, and Öö in that order. Is that what you require? DonnanZ (talk) 18:35, 18 June 2016 (UTC)
Just out of curiosity, have you checked to see |sort= parameter in {{der3}} has any effect? It looks like it's supposed to turn sorting on and off, depending on whether the value is 1 or 0 (though I'm not sure which is which). Chuck Entz (talk) 00:59, 24 June 2016 (UTC)

@CodeCat Could you help me out here? Category:Danish lemmas is sorted correctly without needing a sort key in Module:languages/data2, but doing table.sort in Module:columns produces

I can convert the compare function to bytes in Module:User:DTLHS/test to get


which still isn't right. DTLHS (talk) 19:07, 18 June 2016 (UTC)

  • CodeCat seems to be studiously ignoring this, but thanks for trying. DonnanZ (talk) 09:55, 21 June 2016 (UTC)
  • Maybe the non-self-sorting idea (paragraph 2) would be a better and simpler option after all. DonnanZ (talk) 07:48, 22 June 2016 (UTC)
  • @Donnanz I don't understand how the sorting is working here, so I've created {{der3-u}}, which should be identical except for not sorting. DTLHS (talk) 20:05, 23 June 2016 (UTC)
  • @DTLHS: I have tried with tid (Bokmål) and tid (Nynorsk) to start with, and it worked wonderfully. Thanks a lot! I hope this template will be useful for other editors too; e.g. for Danish, Swedish and maybe other languages (I don't know which). There may be a need for {{der2-u}} and {{der4-u}} if anyone asks, but this'll do for now. Thanks once again. DonnanZ (talk) 20:48, 23 June 2016 (UTC)

{{der}} with "-" as the target language[edit]

So apparently {{der}} is just {{etyl}} with the source and target parameters reversed. (Related discussion: Wiktionary:Beer parlour/2016/March#Use of "inh" vs "etyl")

This works: {{etyl|fr|en}} = {{der|en|fr}}

But this does not work: {{etyl|fr|-}} = {{der|-|fr}}

If I want to show just the language name without categorization, do I have to use {{etyl}}? I was hoping {{etyl}} could be superseded by {{der}} at some point, but {{der}} does not seem capable of doing it. --Daniel Carrero (talk) 04:15, 15 June 2016 (UTC)

If {{etyl|fr|-}} is followed by a French term, you can replace it with {{cog|fr|(term)}}, e.g. {{etyl|fr|-}} {{m|fr|chien}} can be replaced by {{cog|fr|chien}}. I'm not sure why {{etyl|fr|-}} would ever not be followed by a French term. —Aɴɢʀ (talk) 11:36, 15 June 2016 (UTC)
Because you could theoretically say: "A {{etyl|fr|-}} borrowing, but the exact source is unknown". Such wording is common in Iranian borrowings. --Vahag (talk) 19:14, 15 June 2016 (UTC)
In that case, you would want to put it into the "terms derived from French" category, so you wouldn't use "{{etyl|fr|-}}" but "{{etyl|fr|en}}" (or whatever). And if you really didn't want to categorize, you could dispense with the tag altogether and just write "A French borrowing". —Aɴɢʀ (talk) 19:20, 15 June 2016 (UTC)
I tested this now: it seems {{cog|fr}} returns the same result as {{etyl|fr|-}}. So you can use: "A {{cog|fr}} borrowing, but the exact source is unknown", which is enough to me. --Daniel Carrero (talk) 06:39, 16 June 2016 (UTC)
{{cog}} "is used to indicate cognacy with terms in other languages that are not ancestors of the given term". - -sche (discuss) 07:52, 16 June 2016 (UTC)
Thanks for pointing that out, I missed it.
Can we edit all entries to replace {{etyl|aaa|bbb}} by {{der|bbb|aaa}}?
Can we edit all entries to replace {{etyl|aaa|-}} by something and kill {{etyl}}?
As far as the current output goes, we could use {{cog|aaa}} since it returns a link to the Wikipedia article and does not categorize the entry. I don't suppose {{cog}} will ever categorize entries? Do we really need a template especially for "cognacy with terms in other languages that are not ancestors of the given term"? Isn't this just to avoid using {{cog}} when we should use {{inh}}? --Daniel Carrero (talk) 08:05, 16 June 2016 (UTC)
For the record, some entries also have "of {{etyl|de|en}} origin" ("of German origin"). --Daniel Carrero (talk) 09:03, 17 June 2016 (UTC)
Sure, but it's straightforward to change those to "of {{der|en|de}} origin}}". —Aɴɢʀ (talk) 09:19, 17 June 2016 (UTC)
What should the template do when the term is not provided, but is needed? {{m}} adds a request for the term if you don't provide it, {{der}} should also support this. —CodeCat 18:53, 18 June 2016 (UTC)

courir and the wrong past particple IPA[edit]

courir has the wrong pronunciation for the past participle, though it has the right spelling. Hillcrest98 (talk) 20:45, 15 June 2016 (UTC)

Also, ordonner has the pronunciation /ɔʁ.dɔ̃/ for ordonne instead of /ɔʁ.dɔn/. Redboywild (talk) 12:54, 17 June 2016 (UTC)
courir should be fixed. I'm not sure what the problem with ordonne is, it looks like it's happening in donner too. I suspect Module:fr-pron. KarikaSlayer (talk) 01:12, 20 June 2016 (UTC)
You're right, the problem is with Module:fr-pron. Just doing {{fr-IPA|donne}} gives the wrong result (IPA(key): /dɔn/). --WikiTiki89 15:34, 20 June 2016 (UTC)
The problem may be with this line:
word = mw.ustring.gsub(word,'([mn][^aeiouàéèêâîôûäëïöü])e$','%1')
This deletes the silent e in mCe and nCe, but doesn't exclude mme, nne, mne.
Benwing2 (talk) 17:42, 20 June 2016 (UTC)
I added a new rule that looks like fixed it. KarikaSlayer (talk) 20:34, 20 June 2016 (UTC)
BTW this module needs a corresponding test module, like we have for Module:ru-pron (copy the machinery in Module:ru-pron/testcases to create Module:fr-pron/testcases). Benwing2 (talk) 17:46, 20 June 2016 (UTC)
There's a test page on {{fr-IPA}}. KarikaSlayer (talk) 20:34, 20 June 2016 (UTC)

Bengali Letter Template List[edit]

Would somebody help deal with Template:list:Bengali script letters/bn? --Lo Ximiendo (talk) 05:16, 16 June 2016 (UTC)

I don't know the letters, but I started the template. DTLHS (talk) 16:18, 18 June 2016 (UTC)

Unwanted blanks with substitution[edit]

If I do {{subst:gml-entry}}, every {{{|safesubst:}}}-clause (or maybe every if-clause) with an empty paramter in it gets turned into a blank space or blank line. Why is that and how can I fix it?Korn [kʰũːɘ̃n] (talk) 12:57, 18 June 2016 (UTC)

@Korn: I made some changes. Try it now. --WikiTiki89 15:23, 20 June 2016 (UTC)
Internal blank lines seem to get cut. This is the result. Korn [kʰũːɘ̃n] (talk) 16:26, 20 June 2016 (UTC)

3 small template fixes[edit]

  1. {{tr-verb}} should categorize into Category:Turkish lemmas.
  2. {{grc-IPA}} should categorize into Category:Ancient Greek terms with IPA pronunciation.
  3. {{hu-IPA}} needs to separate multiple pronunciations with pipes, not commas.

Can someone fix these please? Ultimateria (talk) 15:14, 18 June 2016 (UTC)

Done. DTLHS (talk) 16:11, 18 June 2016 (UTC)

Numismatics Context[edit]

Currently, adding the "numismatics" context to a word adds it to the appropriate daughter category of Category:Money. Shouldn't it instead automatically add the appropriate daughter category of Category:Coins, itself a subcategory of money? Would somebody well-versed in coding be so kind as to make that change? Purplebackpack89 17:35, 18 June 2016 (UTC)

  • @DTLHS @Daniel Carrero? Purplebackpack89 17:48, 18 June 2016 (UTC)
    • Words related to numismatics aren't coins, so it's not appropriate to subcategorise them there. —CodeCat 18:56, 18 June 2016 (UTC)
      • @CodeCat If it's not appropriate to categorize them as coins, it's even less appropriate to categorize them as money. Purplebackpack89 20:22, 18 June 2016 (UTC)
        • Money is a topical category, it contains terms and subcategories on the topic of money, not things that are money. Coins is a "set" category however, containing terms belonging in a particular set of things. The set of all coins in this case. —CodeCat 20:24, 18 June 2016 (UTC)
          • How are people supposed to tell the difference between topical categories and set categories? This is the first I've heard of such a distinction. —Aɴɢʀ (talk) 21:14, 18 June 2016 (UTC)
          • I can see how having the distinction between sets and topics is useful for structuring the category trees, but I don't think keeping them rigidly separate is always a good idea. Numismatics is indeed a topic, but it's a topic tied very closely to the set of things that are coins. There are a good number of these close connections between sets and topics that we need to be able be able to reflect: oink, pigtail, trotter, ham, bacon, lard, porcine, sty, pigpen, etc. aren't pigs, but they share them as a common theme. Having a separate topical category for pigs would increase category clutter in the entries and increase the risk of naming collisions between the two trees.
            Also, there are many cases where the density of terms is quite different between the two trees, so a topical category may not have enough members to merit subdivision, but each of those members is specific to a fully-populated subdivision of a set. In such cases, you either have very sparse topical categories or you lose information on which topics are connected to which sets. Chuck Entz (talk) 22:24, 18 June 2016 (UTC)
            • I don't agree with the assessment that coins is a different type of category than money; I think that's overthinking things. Almost all coins are money; coins is rightfully a subcategory of money. Not all money has to do with numismatics (paper money?). Therefore, it follows that an article tagged as numismatics should either a) generate the coin category, or b) generate no category at all. Also, @CodeCat, if your logic were followed to its logical conclusion, coins should not be a subcategory of money. (I disagree with doing this). Purplebackpack89 22:31, 18 June 2016 (UTC)
              • When we have, say Category:Colors, we don't want those to be diluted with all kinds of terms related to colours or colour theory or paint or anything like that. We'd want to keep it cleanly a category just for terms referring to colours. Just like we wouldn't want Category:Days of the week to have "weekday" or "weekend" or "long weekend" or any similar terms. —CodeCat 23:03, 18 June 2016 (UTC)
                • I'm not saying we should flood the set categories with topical terms- if there are enough to do that, a separate topical category is merited. It's just that most of the terms in Category:en:Money due to the label "numismatics" are, in fact, names for coins, and the number that aren't might not be enough to merit a separate numismatics category. Chuck Entz (talk) 23:37, 18 June 2016 (UTC)
                • That's essentially what I'm saying too. Purplebackpack89 00:14, 19 June 2016 (UTC)
                  • I certainly think that these terms belong in Category:Coins then. But perhaps they also belong in Category:Numismatics, if they have senses used primarily within that context? —CodeCat 00:16, 19 June 2016 (UTC)
                    • After looking through Category:en:Money, I think there are enough entries to merit creating Category:en:Numismatics, and that's without even touching w:Glossary of numismatics. One odd thing, though: numismatics can refer to not just coins, but also tokens, medals and paper currency, though by far the most usage treats it as just coins. I would favor the coin-only senses for the category, though a few of the senses tagged with the "numismatics" label seem to be based on the broader ones. Chuck Entz (talk) 01:14, 19 June 2016 (UTC)
                      • I started to create the category, but then I noticed that Category:Money and Category:Coins are currently both implemented as topical categories, and I'm not even sure we have a suitable place on the tree of sets to put a category for coins as a set, though I haven't looked through it, yet. Chuck Entz (talk) 01:27, 19 June 2016 (UTC)
                        • Sets are much harder to categorise as a tree than topics are, so you might as well just put it under the top-level category until someone has a better idea. —CodeCat 01:37, 19 June 2016 (UTC)
                          • Perhaps the solution to that is to allow sets to attach to nodes on the topical tree, and vice versa. If you still want to keep the trees separate, you could have some kind of placeholder nodes so you could navigate on either tree. Chuck Entz (talk) 02:02, 19 June 2016 (UTC)
                            • All categories are sets, and subcategorisation implies a subset. With topics, we have subtopics, and with sets, we have subsets. In principle, terms belonging to a particular set can also be relevant to a particular topic, so including a set as a subtopic just says "all terms belonging to this set are relevant to this topic". A good example would be Category:Planets of the Solar System as a subcategory of Category:Astronomy. The planets form a set, but they are also relevant to the topic of astronomy so the subcategorisation makes sense. But it doesn't work the other way around. A subcategory of a set forms a subset; all entries in a subcategory should be able to be placed in their parent (we may choose not to, but it it should be logically sensible). This principle applies across Wiktionary, not just with sets and topics. When you put Category:Numismatics as a subset of Category:Coins, this principle breaks down. "Coins" isn't a topic, but a set (by the nature of the name alone), but "Numismatics" is not a subset. At the same time, if you were to treat "Coins" as a topic somehow (anything related to coins?), then you run into the problem that the parent-child relationship is ambiguous. Is Coins a subdivision of Numismatics, or Numismatics a subdivision of Coins? Both topics are obviously related, but not in a way that makes subcategorisation sensible. Some other means is needed to link them. —CodeCat 20:54, 20 June 2016 (UTC)
          • (edit conflict) I just looked through the Category:All sets, and they've only been implemented for living things, celestial bodies, names, and a couple of other more minor sets. All of the categories we've been discussing except for Category:Pigs and Category:Days of the week (even those you gave as examples of sets) are currently implemented as topical categories. Making Category:Coins a set would require a massive reworking of our category trees that shouldn't be done without much broader discussions than this, so I propose that we make {{lb|xxx|Numismatics}} categorize to Category:Coins for now- we can always change it later, if we decide to. Chuck Entz (talk) 01:52, 19 June 2016 (UTC)
            • I agree with that. That was what I was trying to propose in the first place. Purplebackpack89 04:05, 19 June 2016 (UTC)
              • I disagree. Not all terms with the label "Numismatics" would necessarily belong in the "Coins" category. Such a label would be used to indicate that a term is used within the field of Numismatics, but nothing about the category "Coins" indicates this restricted usage or even anything about numismatics at all. Moreover, coins form a set, but not everything in the field of numismatics is a coin. However, coins are of relevance to the topic of numismatics, so Category:Coins ought to be a subcategory of Category:Numismatics, and the label should categorise only in the latter. If you want to place things in the Coins category, there should be a separate "coin" label (which may display "numismatics" in the entry), though I think that's a misuse of labels much the same way as the label "particle" is. Labels shouldn't be used to categorise members of a set, only to indicate usage within a field or topic. —CodeCat 21:02, 20 June 2016 (UTC)


Adding of glosses (trans-top) can only by using the latin script. Why does he not work with Cyrillic? -- DenisWasRight (talk) 23:29, 22 June 2016 (UTC)

It was designed for English Wiktionary, where glosses are generally in English. I'm sure making it script-agnostic would have added to the complexity. Chuck Entz (talk) 01:27, 23 June 2016 (UTC)
But If I want to use it for another dictionary with cyrillic script, where do I need to change that? -- DenisWasRight (talk) 09:50, 23 June 2016 (UTC)
Does nobody know that? -- DenisWasRight (talk) 11:45, 26 June 2016 (UTC)

{{ko-syllable-hangul}}, {{ko-defn-hangul}} and {{ko-IPA}} in monosyllabic Korean entries[edit]

@Wyang, TAKASUGI Shinji, KoreanQuoter See (jeok).

Should Korean syllables have this template? Will {{ko-IPA}} override it?

Also, I think {{ko-defn-hangul}} could also be made redundant if some model could decompose hangeul into jamo symbols automatically and display them in monosyllabic Korean entries. --Anatoli T. (обсудить/вклад) 08:10, 19 June 2016 (UTC)

I removed the romanisation support in this template and made it automatically generate the romanisation, like all the other Korean headword templates. Korean needs a Lua overhaul like what has been done for Japanese. Wyang (talk) 08:16, 19 June 2016 (UTC)
I agree with Wyang on this one. And I also agree with Anatoly's comment on {{ko-defn-hangul}}. But for monosyllabic entries, I really don't know. But I know that Korean leetspeak (on the internet) would be problematic since a lot of them are monosyllabic or lack vowels, but only consonants. --KoreanQuoter (talk) 12:40, 19 June 2016 (UTC)
ㅎㅇ, I don’t think we will ever use auto-romanization for Internet slangs made of jamos. Isn’t it simply impossible? — TAKASUGI Shinji (talk) 02:00, 21 June 2016 (UTC)
@Wyang, TAKASUGI Shinji, KoreanQuoter Thanks for the answers. I think I didn't make myself very clear.
{{ko-syllable-hangul}} is often used on its own, without other templates. Now it only shows one romanisation - the Revised Romanisation. So we have a bit of information loss. See (gyeon). It lacks {{ko-IPA}}, so you can't see other romanisations. Is it a big loss? Perhaps instances of {{ko-syllable-hangul}} should be replaced with {{ko-IPA}} with a correct heading?
{{ko-defn-hangul}} decompiles hangeul into jamo, which can be done automatically. No need to romanise jamo. --Anatoli T. (обсудить/вклад) 03:33, 21 June 2016 (UTC)
{{ko-IPA}} probably cannot be added in an automated fashion as it requires length information too. (As a note, this template was copied to the Korean Wiktionary and added automatically to all articles - so it looks like the length was disregarded in the process, e.g. ko:멀다.) Personally I don't really find that much value in having alternative romanisations for single syllables, but I'm fine with temporarily restoring the support for alternative romanisations as well. Wyang (talk) 03:46, 21 June 2016 (UTC)
I don't find much value in having alternative romanisations for single syllables either. --Anatoli T. (обсудить/вклад) 04:23, 21 June 2016 (UTC)
One example of Korean leetspeek would be ㅇㅇ. But it is often pronounced 이응이응 and simply 응 It doesn't look well-organized to me. --KoreanQuoter (talk) 12:06, 26 June 2016 (UTC)

Misleading watchlist message[edit]

When adding/removing a watchlist page, the message states that the associated discussion page will also be watched. This does not make sense when the page in question is already a discussion page, e.g. "Talk:starter and its discussion page have been added to (removed from) your watchlist". Equinox 23:06, 19 June 2016 (UTC)


What should be the #invoke code for the autoTransliterate of bulgarian words. I used the {{#invoke:bg-translit|tr|{{{1|}}}}}, but didn't work that way. -- DenisWasRight (talk) 10:34, 20 June 2016 (UTC)

mw:Extension:Scribunto/Lua_reference_manual#Accessing_parameters_from_wikitextGiorgi Eufshi (talk) 11:11, 20 June 2016 (UTC)
You can't do that directly. Try {{xlit|bg|...}}. --WikiTiki89 15:26, 20 June 2016 (UTC)
Thanks, it helped a lot. I wish there was a chance for the IPA pronunciation. Many of the bulgarian words hasn't any. -- DenisWasRight (talk) 16:50, 20 June 2016 (UTC)

Inaccessible Redirect[edit]

I can't get to the redirect page of the diacritic of آ. I seek to repurpose the aforementioned redirect page so it can be added to Category:Arabic script characters. --Lo Ximiendo (talk) 06:17, 22 June 2016 (UTC)

Have you tried Special:WhatLinksHere/آ? Even if you can't click on the character itself, there's an edit link next to it. Chuck Entz (talk) 06:38, 22 June 2016 (UTC)
Vielen Dank! --Lo Ximiendo (talk) 06:44, 22 June 2016 (UTC)

Module:es-conj/data/-ar/errar/testcases - why are these tests failing?[edit]

As far as I can tell the output for the rows "érrate, yérrate", "érrese, yérrese", "érrense, yérrense" is identical to the expected output- why are these cases failing? DTLHS (talk) 05:41, 23 June 2016 (UTC)

Template:nb-noun-mu, Template:nn-noun-mu[edit]

These are potentially useful templates, and I would use them, but:

  • Neither template adds to the uncountable nouns categories automatically.
  • The Nynorsk template creates a lemma, but the Bokmål one doesn't.

The same could be true with {{nb-noun-cu}}, {{nb-noun-nu}}, {{nn-noun-fu}}, and {{nn-noun-nu}}, but I haven't checked those yet. DonnanZ (talk) 12:13, 24 June 2016 (UTC)

{{nn-noun-mu|bla}} just expands to {{nn-noun-unc|m|root=bla}}. So it seems rather redundant. —CodeCat 13:48, 24 June 2016 (UTC)
Um, what does that mean? DonnanZ (talk) 14:07, 24 June 2016 (UTC)
Obviously not. Is it needed? Most uncountable nouns have a definite singular, there's only a few that don't. DonnanZ (talk) 19:03, 25 June 2016 (UTC)
Well, as I pointed out, {{nn-noun-mu}} is implemented in terms of {{nn-noun-unc}}, so if there is an uncountable template for Nynorsk, why not for Bokmål? —CodeCat 19:28, 25 June 2016 (UTC)
Ah, is that what you meant. DonnanZ (talk) 19:54, 25 June 2016 (UTC)

I am currently working on the Bokmål uncountable templates. There may be redundancy, but the templates should work "normally" once I am done. --Njardarlogar (talk) 19:02, 25 June 2016 (UTC)

Okay, I think the two points have been addressed now. The template names themselves may still need som addressing. Possibly, there should just be one template for all nouns, or one for regular nouns (e.g. {{nn-noun-reg|mu}}) and one for irregular ones. Not sure what's best; but there's no haste, either way. --Njardarlogar (talk) 19:23, 25 June 2016 (UTC)
@Njardarlogar: Thanks for popping in and sorting things out. So you created lemmas as well, and Nynorsk should be OK too? Irregular uncountable nouns: I can think of kristendom. DonnanZ (talk) 19:54, 25 June 2016 (UTC)
Those things should be fixed now, yes. Uncountable nouns with more than one definite singular form could e.g. be handled with the templates for irregular nouns with something like a | unc = yes parameter (neither of those templates has been implemented in Scribunto/Lua, which they probably should be). --Njardarlogar (talk) 20:50, 25 June 2016 (UTC)
Working marvellously so far, cheers. DonnanZ (talk) 21:06, 25 June 2016 (UTC)
  • @Njardarlogar: With kristendom I tried "nb-noun-mu|definite singular|kristendomm" and that worked OK {"nb-noun-mu|kristendomm" didn't work); but Nynorsk may need a different solution. By the way, the Bokmål equivalent of {{nn-noun-comireg}} would be rather useful, any chance of a template? DonnanZ (talk) 08:08, 26 June 2016 (UTC)
I've now implemented the |unc= parameter for both the Nynorsk and Bokmål templates for irregular nouns. I've also created {{nb-noun-comireg}}. --Njardarlogar (talk) 09:12, 26 June 2016 (UTC)
I will have to see how that works. And thanks a lot for the comireg template. DonnanZ (talk) 09:19, 26 June 2016 (UTC)

{{nb-verb-comireg}} is now also in place. --Njardarlogar (talk) 15:04, 26 June 2016 (UTC)

Why are there so many Norwegian headword templates anyway? Why can't there just be one, like for English and most other languages? I think too much is being put into the headword line, there should be inflection tables like we have for Swedish. —CodeCat 15:43, 26 June 2016 (UTC)
Don't forget that English and some other languages are much simpler when it somes to inflections for nouns. Yes, inflection tables are used in Danish and Swedish for nouns, and genitive forms are being included as well, which doesn't happen in Norwegian, thank goodness, although they do occur of course - all you have to do is remove the "s" at the end when looking it up. The Danish system that is used for nouns is quite messy and needs revision; it is one reason why I hardly bother contributing to Danish. I prefer the "at a glance" approach which is used in Norwegian, without having to click on a hidden table. Much better. DonnanZ (talk) 16:07, 26 June 2016 (UTC)

Translations sections won't expand[edit]

Is anyone else finding that the Translations tables won't expand? We've recently started having edit window problems on Wikisource, and I wonder if there is a problem here as well from the last update. --EncycloPetey (talk) 02:27, 25 June 2016 (UTC)

Yes it has been a problem for several months, without anyone being able to diagnose the cause. DTLHS (talk) 02:29, 25 June 2016 (UTC)

Term requests using der, inh, cog, bor[edit]

I'm thinking whether it's possible to kill all instances of {{etyl}} (either by itself or used with {{m}}) and use only {{der}}, {{inh}}, {{cog}}, {{bor}} in all entries.

See this: {{der|en|grc|tr=kardiakós}} = Ancient Greek [script needed] ‎(kardiakós)

This works as a term request. The romanization of the Ancient Greek is known, not the term written in Greek letters.

But {{der|en|grc}} is not a term request. ({{der|en|grc}} = Ancient Greek [Term?])

Is there any way to make a term request like this without using {{m}}? If not, can we add this function: use "?" as the parameter 1 to make a term request: {{der|en|grc|?}} = {{etyl|grc|en}} {{m|grc}}

--Daniel Carrero (talk) 05:47, 25 June 2016 (UTC)

We can make it work that way, it's basically a matter of how we want {{der}} to behave in comparison with {{m}}. Personally, I think they should behave the same: with no term given, they should generate a request. That way there's less surprises and that makes them easier to learn for beginners. That leaves the question of how to indicate to {{der}} that no term request is wanted. —CodeCat 13:54, 25 June 2016 (UTC)
Maybe this:
{{der|en|grc}} = {{etyl|grc|en}} {{m|grc}} (request)
{{der|en|grc|-}} = {{etyl|grc|en}} (no request)
What do you think? --Daniel Carrero (talk) 13:59, 25 June 2016 (UTC)
That seems ok, as long as we're sure that those templates should never have to link to -. Additionally, when the language is a family, no term should be required, requested or even accepted. —CodeCat 14:03, 25 June 2016 (UTC)
To be fair, one could edit the entry -- or the entries of some emoticons like
-) and add "from -" in the etymology, but they would use {{m|mul|-}} anyway unless we have some reason to specify the language (Translingual).
Even if there are any rare exceptions that I didn't think of where one would want to see "from Translingual -", I think the benefit of having {{der|en|grc|-}} to disable requests outweighs them.
Plus, maybe {{der|en|mul|[[-]]}} with a bracketed link would be the best way to link specifically to the entry -, since we can already use bracketed links in the 1st parameter.
It seems that the underlying modules already recognize when the language is a family and generate a module error if one tries to add a term or a transliteration. I'm totally OK with it if the templates only generate term requests for languages. --Daniel Carrero (talk) 14:35, 25 June 2016 (UTC)
@CodeCat: Done and updated the documentation of the templates. --Daniel Carrero (talk) 07:15, 27 June 2016 (UTC)
See CAT:E. This is causing a module error with certain undefined "from" languages such as Iberian and Pre-Greek. These seem to be cases where there's no possibility of a term in the language, so the module can't find the information necessary to formulate a request. As long as you're trying to replace {{etyl}} with {{der}}, you have to allow for cases where there can't be a term. Chuck Entz (talk) 03:28, 28 June 2016 (UTC)
@Chuck Entz: Fixed. --Daniel Carrero (talk) 06:01, 28 June 2016 (UTC)
Here is my argument against. Cases where the term is intentionally omitted are supposedly permanent, while cases where the term is requested are supposedly temporary (until someone supplies the term). Permanent markup should not be uglier than temporary markup. --WikiTiki89 18:00, 28 June 2016 (UTC)
@Wikitiki89: Here is my counterargument. I believe that in {{der}} and others, usually you'll want to type the term or generate a term request, so cases where the term is intentionally omitted are special and rarer. (there are some exceptions: like, when the target is a family as in "from a Romance language", there can't be a term so it won't generate the [Term?] ever) We need some way to distinguish the usual case from the special, rarer case. Being 2 characters longer by the addition of "|-" is the best thing we have—we are already used to using the "-" in some places with supposedly permanent markup, like {{en-noun|-}}, {{en-adj|-}} and {{etyl|en|-}} (though I repeat that I intend to kill Template:etyl completely at some point if it's ok), not to mention that it needs the concious choice of the editor to override the term request. For these reasons, in my opinion it befits the cases where the term is intentionally omitted. --Daniel Carrero (talk) 03:22, 29 June 2016 (UTC)
Theoretically, all term requests will eventually be fulfilled and there will be zero of them, while the cases where the term is omitted will remain and thus be more common than term requests. But even in practice, I don't know the actual statistics at the moment, but I'm not convinced that term requests are more common than intentionally omitting a term. --WikiTiki89 20:19, 29 June 2016 (UTC)

Double translations[edit]

By which I mean something like this. Could someone detect them and remove the duplicates? I can help with removal if it's not on such a scale as to require a bot. —Μετάknowledgediscuss/deeds 20:45, 25 June 2016 (UTC)

@Metaknowledge User:DTLHS/cleanup/repeated translation languages DTLHS (talk) 22:00, 25 June 2016 (UTC)
  • No surprise about the number of duplicated Norman entries; Norwegian done. DonnanZ (talk) 22:17, 25 June 2016 (UTC)
  • @DTLHS: It says there's a problem with Maori at spread, but I'm not seeing it. —Μετάknowledgediscuss/deeds 00:23, 26 June 2016 (UTC)
    • The dump is from June 1, and there were two Maori translations at that time. DTLHS (talk) 00:26, 26 June 2016 (UTC)
  • I fixed all the entries. Thank you for generating the list. —Μετάknowledgediscuss/deeds 04:17, 26 June 2016 (UTC)

iPad bug re Arabic characters[edit]

Discussion moved from Template talk:etyl#iPad_bug.

On my iPad, the mobile version of e.g. יעני (https://en.m.wiktionary.org/wiki/יעני) displays the Arabic origin correctly, i.e. يَعْنِي , whereas the desktop version (https://en.wiktionary.org/wiki/יעני) displays the isolated forms of the letters: يَ عْ نِ ي – who could fix this? Dan Pelleg (talk) 21:54, 26 June 2016 (UTC)

(To clarify after this discussion was moved here): the bug is in Template:etyl. Dan Pelleg (talk) 06:06, 27 June 2016 (UTC)
I don't know what exactly happened. Please provide some screenshot? I guess that the problem is about the iPad's font itself that does not support some formation. If it's true, nobody can fix this other than Apple.--Octahedron80 (talk) 06:10, 27 June 2016 (UTC)
(To clarify why I moved the discussion here:) The bug is not in Template:etyl, which does not display any Arabic text. - -sche (discuss) 06:28, 27 June 2016 (UTC)
I have this issue with my iPhone as well. It seems that simply that the Iranian Sans font does not render properly on iOS anymore (although it used to render perfectly fine a few months ago). Iranian Sans is the default Arabic font in MediaWiki:Common.css and is supplied as a web font (i.e. is downloaded as a resource from our servers and used even if it is not installed on the client device). However, in the mobile view, that part of the CSS does not make it in. --WikiTiki89 18:09, 27 June 2016 (UTC)
Sorry – just realised the problem is not with Template:etyl but with Template:m. And no – the mobile view works, it's the desktop view that doesn't. Does the template force different fonts for mobile and desktop views respectively? And if so, why should it force a font at all? And what kind of Arabic font wouldn't support letters' connected forms? Makes no sense to me. Should this discussion be moved to Template talk:mention? Here's the screenshot, I hope it helps. Dan Pelleg (talk) 23:07, 27 June 2016 (UTC)

Wikt template etyl bug arabic.png

I have the same problem with formatted (templatised) Arabic and Urdu on my iPhone. iPhone supports Arabic well, as you know, it's the templates' font, which doesn't work. Persian appears normal. --Anatoli T. (обсудить/вклад) 23:16, 27 June 2016 (UTC)
To clarify, the reason the desktop view does not render properly on iOS, is because it is using the Iranian Sans font and the Iranian Sans font does not render properly on iOS anymore. The actual mobile view works fine because the part of the CSS that specifies the Iranian Sans font is missing from the mobile view. Thus, the problem is with iOS's rendering of the Iranian Sans font, not with any of our templates. --WikiTiki89 16:41, 28 June 2016 (UTC)
Could the part of the CSS that specifies the Iranian Sans font be removed also from the desktop view specifications of the mention template? Dan Pelleg (talk) 23:06, 28 June 2016 (UTC)
The mention template has nothing to do with anything. The problem is anywhere where there is properly tagged Arabic script text. We can remove Iranian Sans from the CSS, but that would affect desktop users as well and it is a really good Arabic font and more importantly is available as a web font (which means that users who don't have any Arabic fonts on their computer can still use this font). --WikiTiki89 20:16, 29 June 2016 (UTC)
Ok the culprit is actually 'Arial Unicode MS', not 'Iranian Sans' – I checked on my iPad. Could Arial Unicode MS be removed from the font-family list for Arabic? (The iPad ignores the entire font list except for Arial Unicode MS, which has the letters render isolated even if it's last on the list.) Dan Pelleg (talk) 05:38, 30 June 2016 (UTC)

Cleaning up {{given name}}[edit]

The |diminutive= parameter inserts a raw link instead of a language link using {{m}} or whatever. If someone feels like fixing it that would be great. Benwing2 (talk) 06:31, 27 June 2016 (UTC)

Done. DTLHS (talk) 23:21, 27 June 2016 (UTC)
Thanks! Benwing2 (talk) 05:25, 28 June 2016 (UTC)

borrowing, borrowed, loan, loanword → bor[edit]


  1. Replacing {{borrowing}}, {{borrowed}}, {{loan}}, {{loanword}} by {{bor}} in all entries.
  2. Using the format {{bor|fr|es|whatever}} in all entries, as opposed to {{bor|es|whatever|lang=fr}}. (that is, removing "lang=" from the template in all entries)


  • Looks nicer in comparison with {{der}}, {{inh}}, {{cog}}.

--Daniel Carrero (talk) 08:18, 27 June 2016 (UTC)

This is fine with me. Benwing2 (talk) 00:47, 29 June 2016 (UTC)
I have no objections. —CodeCat 00:48, 29 June 2016 (UTC)


I have a question about how using template coding like {{der}}, {{bor}}, and {{inh}} without a particular parent word within the bracket now generates [Term?]. Does the actual word itself matter (as in will it eventually be sorted into a category that shows that word being derived from the parent word?) I ask because sometimes I use these templates without it, such as when it comes from a set of words in an expression (of which only the last may be the desired lemma link, like with (mensis) maius), or a non-lemma or unattested term that doesn't warrant its own entry, or when it's certainly derived from a parent language word but we don't have an entry or attested term for it. I'm guessing the aforementioned example should be done like "From Latin (mensis) maius."? It doesn't look good now that [Term?] shows up in all these entries. Ugh, I don't want to go back and edit all of those... Oh well. Word dewd544 (talk) 01:46, 28 June 2016 (UTC)

That would be due to the recent edits to Module:etymology by @Daniel Carrero. DTLHS (talk) 01:49, 28 June 2016 (UTC)
Since "mensis maius" is intended as one single term, not two separate terms, they should be included together in one linking template. —CodeCat 01:51, 28 June 2016 (UTC)
I did the change that introduced [Term?] in {{der}}, {{bor}}, etc., per #Term requests using der, inh, cog, bor. Before that, I would usually add {{m|la}}, {{m|it}}, etc. (the template {{m}} without the word) to make term requests, when I found a derivation without the exact term. I find it a bit annoying that in many language sections of pizza, for example, some languages say "From Italian" instead of "From Italian pizza". --Daniel Carrero (talk) 01:53, 28 June 2016 (UTC)
But in most cases the term is right next to the template, so you have [Term?] followed by the term. I think this should be undone. DTLHS (talk) 01:56, 28 June 2016 (UTC)
I have a suggestion: Maybe a bot could replace all instances of {{der|xx|yy}} {{m|yy|term}} by {{der|xx|yy|term}}. (and the same with: {{bor}} and {{inh}})--Daniel Carrero (talk) 01:57, 28 June 2016 (UTC)
I hope you mean only in etymologies, because {{m}} has other uses. DCDuring TALK 02:29, 28 June 2016 (UTC)
No. You need to change the entries before you introduce this change. I won't run a bot before this is reverted. DTLHS (talk) 05:55, 28 June 2016 (UTC)
I oppose the new changes to these templates. [Term?] should not be displayed unless at least one part of the term or an empty parameter is provided. For example, {{inh|it|la}} should not display [Term?], but {{inh|it|la|}} and {{inh|it|la|t=foo}} should. --WikiTiki89 16:45, 28 June 2016 (UTC)
I disagree. These templates should behave the same as {{m}} with respect to requests. Why would they not? —CodeCat 17:15, 28 June 2016 (UTC)
So that you could do things like {{inh|it|la}} and then use a different template to display the term itself if it makes sense to do so. For example, I've found myself doing things like {{bor|en|he}} {{m/he|מסורת|dwv=מָסֹרֶת}} as at masoret. Another example is like at davanti: from the {{der|it|la}} locution {{m|la|[[dē]] [[ab]] [[ante]]}}. --WikiTiki89 17:27, 28 June 2016 (UTC)
You can still do that, you just need to provide an extra -. Not a big deal. It matters more that these templates work the same as {{m}} so that users don't run into unexpected surprises. Reducing the mental workload of learning our templates is important. —CodeCat 17:45, 28 June 2016 (UTC)
Ok, it's good that we have that as an option, so I'm not as opposed to it, although I still would prefer it the way it was. More importantly, you broke all the places that were already doing this and haven't fixed them. I recommend that we do a poll on whether we like this change, and if we do, then you need to go and fix all the places that didn't have a third argument before you made this change, if we don't then you need to undo it. --WikiTiki89 17:49, 28 June 2016 (UTC)
Yeah, I just now figured that out on my own (regarding the use of - to avoid [Term?] coming up). I suppose that's a fair compromise. There's still a lot of entries that need to be changed now, though. Actually, is there a way that these term requests could automatically generate a category, so it's known which ones need editing? Word dewd544 (talk) 18:23, 28 June 2016 (UTC)
I agree that these instances should have been fixed beforehand. It seems, though, that you missed the proposal and discussion that led to this change, as you weren't aware of the - option. Maybe you should go to the discussion above and read it? —CodeCat 17:51, 28 June 2016 (UTC)
Yes, I missed it. I just commented there. I still think we should do a poll in the WT:BP. --WikiTiki89 18:01, 28 June 2016 (UTC)
@Word dewd544: See Category:English term requests. --Daniel Carrero (talk) 22:48, 28 June 2016 (UTC)
@Wikitiki89: Do you want to create the poll? If you want to, ok with me. Bear in mind, some people are already using "-" to disable [Term?]. (or is it just @Word dewd544 for now?) If we just revert Module:etymology, the instances of "-" will become links to the entry -. (Linking to - was discussed in the previous discussion.) For the record, some people are fixing [Term?] in entries where needed: diff 1, diff 2, etc. I edited some of the entries in CAT:English term requests. (347 to go) Many of CAT:Ancient Greek term requests were requests I added willingly with a transliteration or translation, like in the entry empyreuma. --Daniel Carrero (talk) 00:09, 29 June 2016 (UTC)
The problem is that these templates are replacements for both {{etyl}} and {{m}}. The difference between these templates and {{m}} is that {{m}} is a single-purpose template that's only used for displaying and linking to terms. If the term is missing from {{m}}, it's quite logical to assume that one should be provided. {{etyl}}, on the other hand, is a single-purpose template that's only used for displaying names of and adding categories for languages. It has no provision for terms at all, so it's not logical to assume that the lack of a term in its replacement means that one should be provided.
There's simply no way to avoid increasing the cognitive load when converting to these templates: their dual purpose makes them inherently ambiguous when the term is missing. I think we should allow for this and only generate term requests when there are term-related parameters such as glosses and transliterations. Yes, that's different from the way {{m}} behaves, but {{m}} doesn't categorize, either, so it wouldn't really be the same, anyway (even with {{cog}}, we have to decide to use it rather than {{der}}, {{inh}}, etc.- which is an extra choice). Chuck Entz (talk) 03:03, 30 June 2016 (UTC)
The language parameters of these templates are already swapped compared to {{etyl}}, and {{der}} does not allow the first parameter (etyl's second) to be -. So the two are already clearly different in how their parameters work. They are very similar to {{m}}, however: {{cog}} takes exactly the same parameters as {{m}}, and {{der}} is the same as {{m}} except one extra positional parameter for the current language. When they are this similar, a small difference like this is jarring and confusing to users. Also consider that the difference with {{etyl}} is irrelevant, as they're intended to replace that template entirely, so they will not exist beside {{etyl}} in the long term and so the confusion is only in the short term, for users still used to {{etyl}}. {{m}} will continue to be used, however. —CodeCat 20:14, 2 July 2016 (UTC)

@Word dewd544 said above: "sometimes I use these templates without it, such as when it comes from a set of words in an expression (of which only the last may be the desired lemma link, like with (mensis) maius), or a non-lemma or unattested term that doesn't warrant its own entry, or when it's certainly derived from a parent language word but we don't have an entry or attested term for it."

I believe we would do it like this:

  • if it's a non-lemma:
    • {{der|en|la|foo|foos}} (to display "foos" and link to "foo")
  • unattested term that doesn't warrant its own entry:
    • {{der|en|la||foo}} or {{der|en|la||*foo}} (the 1st parameter is empty and so a link is not generated; you may want to use an asterisk)

--Daniel Carrero (talk) 23:05, 28 June 2016 (UTC)

@Wikitiki89 A little late, but I feel strongly, in regards to your suggestion above concerning empty parameters triggering [Term?], that there should never be a difference between an empty and a missing parameter. Benwing2 (talk) 00:46, 29 June 2016 (UTC)

I support this: there should never be a difference between an empty and a missing parameter. --Daniel Carrero (talk) 02:42, 29 June 2016 (UTC)
@Benwing2: I agree that it generally preferable to have an empty argument behave the same way as an omitted argument, but I don't think that there can't be exceptions to that rule. I think this is one case where such an exception makes sense. --WikiTiki89 20:21, 29 June 2016 (UTC)

Recent changes category[edit]

Why is recent changes categorized in Category:Undetermined language links? I didn't know it was even possible to categorize special pages. DTLHS (talk) 04:45, 28 June 2016 (UTC)

It was because WT:WE had a Undetermined link in the active list (livadus). I created the entry and removed the link. I don't know how to fix it so that RecentChanges stops being categorized like that. See Template:l. I populated Category:Undetermined language links in the first place, but it shouldn't categorize RecentChanges. --Daniel Carrero (talk) 05:01, 28 June 2016 (UTC)

Scots adverbs and nouns don't get added to cat:Scots lemmas?[edit]

Noticed this just now; for some reason {{sco-adv}} etc. do not add the lemmata to [[Category:Scottish lemmas]]. Case in point: groof, on one's groof. — Kleio (t · c) 00:34, 29 June 2016 (UTC)

Fixed. --Daniel Carrero (talk) 00:37, 29 June 2016 (UTC)
Gratias tibi ago. I fixed it for t:sco-noun as well based on how you did it. — Kleio (t · c) 00:45, 29 June 2016 (UTC)
These templates use quite horrible and outdated code, so if someone would like to bring them up to modern standards (using {{head}}) that would be great. —CodeCat 00:50, 29 June 2016 (UTC)
Scots in general seems a bit messy on Wiktionary, based on my very limited experience. For example, older stages of the language, like Middle Scots, have to be lumped in with regular Scots and an obsolete disclaimer as it stands right now. — Kleio (t · c) 00:55, 29 June 2016 (UTC)
I've altered {{sco-adj}}, {{sco-adv}}, and {{sco-noun}} to use {{head}}. I think I've done it correctly, but the behavior of these templates is fairly odd and there was no documentation. Could someone look these over? —JohnC5 04:46, 29 June 2016 (UTC)
Would be worth it to move Middle Scots terms like quhilk (with clearly obsolete orthography) to a new code gem-msc or something similar? KarikaSlayer (talk) 20:04, 2 July 2016 (UTC)

Entries for comparative forms of ölig (German)[edit]

Hi, could anyone with a script to generate pages take a look at ölig, especially the comparative forms? I just fixed the comparative forms to be öliger- instead of ölig-, and the öliger- pages don't exist yet. Wyverald (talk) 09:45, 29 June 2016 (UTC)

grc test tracking 1[edit]

What is CAT:grc test tracking 1? It appears in a lot of Ancient Greek entries, e.g. φρήν. Benwing2 (talk) 20:19, 29 June 2016 (UTC)

Preload a page with output of a module?[edit]

Is it possible, when creating a new page, to preload the edit window with wikitext that has been output by a module? We have the preloadtext= URL parameter (though it seems undocumented by MediaWiki?) which WT:ACCEL currently uses, but that text is static and therefore needs to be provided by the JavaScript creating the URL. I had hoped that it would be possible to leave the actual entry generation to a module, rather than being built into JS (User:Conrad.Irwin/creationrules.js) where nobody but administrators can edit it. However, it seems that this would only be possible if the JS called the module itself through template expansion, which would be very slow for page loading I think. Does anyone have a better idea? —CodeCat 19:39, 30 June 2016 (UTC)

I don't have a better idea, yours is the best I could come up with. But where do you plan to use this? --WikiTiki89 19:44, 30 June 2016 (UTC)
Like I said, to take the entry generation part out of JS and into Wikispace so that it can be edited more easily and keep the URLs short. —CodeCat 20:36, 30 June 2016 (UTC)
I got that, but where? Like to replace the current WT:ACCEL system? --WikiTiki89 20:40, 30 June 2016 (UTC)
Maybe, depending on how much is possible. Ideally, a replacement system could even insert the content into an existing page, which is possible with a module: it can get the wikitext of a page and modify it, then present the modified content in the edit window. But it doesn't seem likely. —CodeCat 20:46, 30 June 2016 (UTC)
I just wanted to know what your intent was in asking this question. Also, I'm pretty sure JS can fetch the page text as well, and I'm not sure modules would be any faster at doing any of this. --WikiTiki89 20:50, 30 June 2016 (UTC)
It's not about it being faster, but about having it as a module rather than JS. Then people can edit it freely. It would also make it much easier to run a form creation bot, as it would just be able to call the module. —CodeCat 20:54, 30 June 2016 (UTC)
Oh, ok. --WikiTiki89 20:55, 30 June 2016 (UTC)
[3], it looks like you can pass in templates with arbitrary parameters (haven't tried it). DTLHS (talk) 19:47, 30 June 2016 (UTC)
But the template/module itself doesn't get substed before loading the page. What I'd like is for the module to be called, then the edit window filled in with whatever the module puts out. —CodeCat 20:36, 30 June 2016 (UTC)
I don't use JavaScript much (at all), but can you send a GET request for a corresponding template to your module like this: https://en.wiktionary.org/w/api.php?action=expandtemplates&text={{TEMPLATE-NAME}}&prop=wikitext, then copy the relevant part of the response to your URL? Edit: Did I suggest exactly what you said in your initial note? Apologies if I (probably) did. I don't think it would be slow except in cases where Lua is an inappropriate solution, for example, a form creation robot creating pages that require Lua to keep reloading data per-page which the robot could more easily cache locally for the whole run. I have found mere template expansion of simple computation-only modules to take hundreds of milliseconds. Edited again: If the main cost is indeed in module and dependency loading, as is the case in my expensive modules, would some kind of batch-call template that takes advantage of per-page loading semantics amortise the cost? I am not sure if to cache multiple pre-formed edit window URLs would be feasible or sensible in a browser environment. I know so little about JS I would probably delete this note if I did not fear you may have already read it. Isomorphyc (talk) 14:52, 1 July 2016 (UTC)

July 2016


The template {{topic cat}} is generating an error at "Category:en:Parties", and I'm not sure why. — SMUconlaw (talk) 16:12, 1 July 2016 (UTC)

There is no "parties" topic in the Module:category tree/topic cat/data tree. It should probably be added to the Culture subpage. --WikiTiki89 16:43, 1 July 2016 (UTC)
Thanks. It looks pretty technical. I'd better leave this to one of the grease monkeys here. — SMUconlaw (talk) 17:56, 1 July 2016 (UTC)
Done: diff. Feel free to change the parent categories if you see fit. --WikiTiki89 18:03, 1 July 2016 (UTC)
Thanks, that looks fine! — SMUconlaw (talk) 18:25, 1 July 2016 (UTC)


I created {{coglist}}, a template for lists of cognates. See this diff where the template is being added in an entry. See also the data module for the list of cognates itself. --Daniel Carrero (talk) 11:58, 2 July 2016 (UTC)

I think it's too cumbersome to be useful. People aren't going to want to create a new list in a module (modules scary!) just to list a few cognates in an entry. Same as with {{etyltree}}, that never really got used much either, which is why I created {{desctree}} as a simpler replacement. —CodeCat 13:50, 2 July 2016 (UTC)
Also, if it were to become widely used, the parameter would have to be more language-specific. At the moment there are only two lists, both in reconstructed Vulgar Latin, but what if someday we wanted one cognate list for the descendants of Latin dolus and another for the descendants of Old Irish dolus? —Aɴɢʀ (talk) 14:29, 2 July 2016 (UTC)
The group names can be: dolus1, dolus2; dolus/la, dolus/sga. The group names can be anything. @CodeCat, you meant {{etymtree}}? Also, as long as people are ok with the existence of {{coglist}}, they can choose using it or not. That template exists mostly because I got tired of replacing the same instances of {{etyl|xx|-}} {{m|xx|qwerty}} by {{cog|xx|qwerty}} in multiple entries, and I'd like to use it. --Daniel Carrero (talk) 14:38, 2 July 2016 (UTC)
I just don't list cognates much at all. If people want to find cognates, they can look in the entry for the ancestor. No sense in duplicating all that. —CodeCat 14:46, 2 July 2016 (UTC)
As Code said, I've often found lists of cognates to be duplicative and often misleading. —JohnC5 17:07, 2 July 2016 (UTC)
When you choose to use a particular template, you're choosing not just for yourself, but for the next person who's going to making changes to what you've entered. If you get a Lithuanian cognate wrong, some poor Lithuanian IP is going to have to figure out how to change it in the module. I also agree that cognate lists are rife with excess. Listing all the cognates in every etymology would be like including the entire inflection table in the headword line of every inflected form. It's bad enough that you can't give a Danish cognate without having Swedish, Norwegian, Faroese and Icelandic added immediately. Chuck Entz (talk) 17:35, 2 July 2016 (UTC)
I think including cognates in an etymology is a good idea but I also don't really like this approach too much. One issue here is that it feels wrong to have the cognate lists all stuck together into a big file instead of more distributed. Benwing2 (talk) 20:36, 2 July 2016 (UTC)
There are two issues:
  1. Whether to have many (or all) cognates in the etymology of a given entry; or just 1, 2, 3 cognates; or no cognates in etymologies.
  2. Whether to use {{coglist}} with Module:coglist/data, or: "Compare {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}."
About both issues, I'm using {{coglist}} in pages where there already were already lots of cognates, cross-linked in most of the separate pages, as in the diff in my 1st message. If having a certain number of cognates in etymologies is not a desirable thing, should we delete the cognates altogether from these entries? Or maybe just trim all the long lists of cognates and keep only 1, 2 or 3 cognates in all pages? I don't think {{coglist}} would be very helpful in pages with few (maybe 1-3) cognates. (unless we make {{coglist}} show 3 cognates with a JavaScript [more] button to display more cognates) If all the many cognates were to be kept, and cross-linked in all entries, it seemed logical to me creating a separate list for them.
I tried just converting from:
"Compare Language ''[[link]]'', Language ''[[link]]'', Language ''[[link]]'', Language ''[[link]]'', Language ''[[link]]'', Language ''[[link]]'', Language ''[[link]]''."
"Compare {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}."
but got tired of editing the same cognates over and over in all the linked pages. --Daniel Carrero (talk) 23:44, 2 July 2016 (UTC)
Maybe the solution is to use a bot to convert to {{cog|...}}? It requires some cleverness but probably can be done for most cases. Benwing2 (talk) 02:53, 3 July 2016 (UTC)

Latvian accent marks[edit]

I think we should automatically remove/convert Latvian accent marks, as we do with other languages. For example, klât should automatically link to klāt. I don't know Latvian well but I think the three long-vowel tone marks are â ã à, which should all map to ā. Benwing2 (talk) 20:39, 2 July 2016 (UTC)

CodeCat (I think) and I had wondered about this before but also lacked the requisite knowledge. I'd love to know the answer. —JohnC5 20:47, 2 July 2016 (UTC)
I'd say just go ahead, and see if someone complains. —CodeCat 21:07, 2 July 2016 (UTC)
Done. Benwing2 (talk) 21:39, 2 July 2016 (UTC)
Except there's no such thing as ō in the standard orthography- only o (nor any variation on y whatsoever, for that matter). See w:Latvian orthography and WT:ALV. Chuck Entz (talk) 22:42, 2 July 2016 (UTC)
ō and ȳ removed. Chuck Entz (talk) 22:48, 2 July 2016 (UTC)
According to that Wikipedia page, ō is still used by some Latvian speakers, but not by the standard orthography. So entries with ō might theoretically exist as alternative spellings, and we need to be able to link to them. —CodeCat 23:03, 2 July 2016 (UTC)
Yes, but what we're talking about here is converting every accented o or O to ō or Ō. Links that have ō or Ō in the wikitext are still going to link to ō or Ō- we just don't want to link ÔÕÒôõò to ō or Ō. Why funnel everything to rare alt-forms? Chuck Entz (talk) 01:00, 3 July 2016 (UTC)
I understand that. But it would also mean that we're no longer able to link to these alt forms with additional accents. If you use ô instead of ō, it links to the wrong page. That's something to be aware about. —CodeCat 12:19, 3 July 2016 (UTC)
Yes, but there's no way to tell from the wikitext whether an accented o should link to an o with or without the macron. Assuming the rarer form means guessing wrong most of the time. Chuck Entz (talk) 15:01, 3 July 2016 (UTC)
Pinging Latvian native speakers @Čumbavamba, Neitrāls vārds. - -sche (discuss) 22:16, 2 July 2016 (UTC)

Links in template der[edit]

Hi. I noticed that when I use the der (derived) template, it doesn't always link to the correct language heading. For example, I added the following to the etymology of German Seide: Latin saeta ‎(horsehair; bristle; silk), which when clicked on, takes me not to Latin saeta, but to Spanish saeta. This may be due to Spanish being at the bottom of the page. Can this be made to link to Latin ? Leasnam (talk) 01:52, 4 July 2016 (UTC)

Is this a problem specific to that template? For me, the {{der}} link works exactly like saeta#Latin or saeta, and the link it generates is correctly to saeta#Latin. The issue AFAICT is a (longstanding) bug that when there's collapsible content further up a page, and one clicks any link that points to an anchor lower down on the page, the page may load and pull the browser to the anchor while the content is uncollapsed, after which the collapsible content collapses, leaving a different part of the page visible. (Sometimes the browser subsequently corrects for the shift and re-focuses on the anchor.) - -sche (discuss) 02:47, 4 July 2016 (UTC)
For me, too, these links all work exactly the same; they correctly use the anchor "Latin", but in all cases, because of the bug -sche mentioned, the link does take me to the bottom of the page, which is the Spanish section:
  • {{der|de|la|saeta||horsehair; bristle; silk}}
  • ''[[saeta#Latin]]''
  • {{m|la|saeta}}
When the page is already loaded (with Spanish showing up on my screen), if I click on the address bar (https://en.wiktionary.org/wiki/saeta#Latin) and press Enter, the page goes to the correct section (Latin) without loading again. (on Firefox)
If I click "Show quotations" and "Show inflection" on the left side of the screen, and then click on the link to ''[[saeta#Latin]]'', it goes directly to the Latin section, as it should, because there's nothing to collapse. --Daniel Carrero (talk) 04:34, 4 July 2016 (UTC)
Ok. Thank you for looking into this, and for the expalanation :) Leasnam (talk) 15:15, 4 July 2016 (UTC)

Pointing to #Verb from Template:en-past_of[edit]

Back in 2011, someone suggested making {{en-past_of}} link to the #Verb anchor, rather than the #English anchor. 3 years later, this was rejected on the basis that #Verb might not always be correct (but #English would). This does not seem accurate to me (as I explained on the linked talk page). Further discussion (and a change by an admin, once consensus is determined) would be welcome. JesseW (talk) 02:12, 5 July 2016 (UTC)

There could be a Translingual verb section. There could also be a different English verb; for example, if flied pointed to fly#Verb rather than fly#English, it would be confusing because it would be pointing to a verb that doesn't have a form "flied". If it points to fly#English, on the other hand, the reader knows that the form is there somewhere, even if it takes a little looking for. —Aɴɢʀ (talk) 12:40, 5 July 2016 (UTC)
The id= parameter, along with {{senseid}}, was introduced to allow templates to link to specific senses. It can be used here too. —CodeCat 12:47, 5 July 2016 (UTC)
That's close, but {{senseid}} only lets you point to a specific sense, while what is needed is a way to point to multiple senses (e.g. on desert, there are two senses, which deserted can refer to either.) Suggestions? (Angr -- very good point about fly.) JesseW (talk) 00:55, 6 July 2016 (UTC)
Just point to the first one? —CodeCat 01:03, 6 July 2016 (UTC)
I would do that if it was a pure anchor, but it also highlights the definition, which to me implies that the link doesn't apply to the other definitions, which is misleading. JesseW (talk) 03:34, 6 July 2016 (UTC)
Just how many Translingual verbs are there now? How would such things come about? DCDuring TALK
There are 3 currently in Category:Translingual_verbs (but only seems to actually have a Verb section). JesseW (talk) 03:40, 6 July 2016 (UTC)

w:Template:Multiple image[edit]

Is anyone able to create a version of w:Template:Multiple image here? Lua is beyond me. — SMUconlaw (talk) 17:55, 5 July 2016 (UTC)

I could really use such a thing for family- and higher-level taxonomic names. DCDuring TALK 21:50, 5 July 2016 (UTC)
Yellow cartouche
Red cartouche
Example images
{{multiple images}} should be set to go. KarikaSlayer (talk) 03:10, 10 July 2016 (UTC)
Thanks! Is there any reason why we don't use the same name as the English Wikipedia template, though? — SMUconlaw (talk) 13:30, 10 July 2016 (UTC)
The "s" is because I typoed. Should we have it as {{multiple image}} or {{Multiple image}}, though? KarikaSlayer (talk) 21:21, 10 July 2016 (UTC)
Since there are multiple images, why not keep the plural? It makes more sense to me. —CodeCat 21:31, 10 July 2016 (UTC)


Is there a specific reason why the tables are ordered right-to-left? Our Arabic templates don't do this, and neither does {{fa-basic}}. It's also pretty unintuitive on an English-language wiki. KarikaSlayer (talk) 00:26, 6 July 2016 (UTC)

It was just something the person who made it liked to do. I don't think anyone would mind much if you want to switch it to left to right. DTLHS (talk) 00:33, 6 July 2016 (UTC)

Category:English terms derived from Caranqui[edit]

There must be some error in Module:families/data that causes this incorrect categorization. DTLHS (talk) 17:43, 6 July 2016 (UTC)

Nope, the error was in Mod:languages/datax. I've fixed it and all the resultant module errors. —Μετάknowledgediscuss/deeds 18:25, 6 July 2016 (UTC)
Thanks. Btw, for anyone who wasn't aware, WT:DATACHECK tracks such clashes. - -sche (discuss) 18:58, 7 July 2016 (UTC)

Adding new rhymes[edit]

When I tried to use the "add new rhyme" tool at "Rhymes:English/æɹɪti", it gave the error message "ERROR:TypeError: (intermediate value).parentNode is undefined". "* {{rhymes|æɹɪti|lang=en}}" was successfully added to the entry page "tutelarity", though. — SMUconlaw (talk) 21:35, 6 July 2016 (UTC)

I get the error only when adding to the seven-syllable rhymes section; others are fine, oddly. Equinox 21:05, 7 July 2016 (UTC)

{{tooltip}} and {{l}}[edit]

I'm currently trying to add mouseover transliterations for {{el-decl-noun}}, but they aren't working in the template. Hard-coded {{l|el|αγγούρι|3={{tooltip|{{xlit|el|αγγούρι}}|αγγούρι}}|tr=-}} works just fine (αγγούρι), but {{l|el|{{{1}}}|3={{tooltip|{{xlit|el|{{{1}}}}}|{{{1}}}}}|tr=-}} just displays the link (with no tooltip). KarikaSlayer (talk) 15:51, 7 July 2016 (UTC)

I think it's more accessible if the transliteration is shown as text in the table, tooltips are too hidden and I have no idea how they're supposed to be accessed on systems without a mouse pointer. It doesn't have to be cluttery, look at how Russian, or even French, display it. —CodeCat 19:48, 7 July 2016 (UTC)

Pinging @Saltmarsh. KarikaSlayer (talk) 20:52, 7 July 2016 (UTC)

It is of course more accessible - but surely anyone looking at a table is going to be familiar with the syllabary in question and can hover (if enabled) or follow the link if they are interested. Showing the transliteration detracts from the effort taken to present a clear, easily read table.   — Saltmarshσυζήτηση-talk 05:00, 11 July 2016 (UTC)

Issues with pronunciation in {{fr-conj-auto}}[edit]

{{fr-conj-auto}} is throwing up some odd pronunciations in the verb errer (and verbs ending with it such as serrer), saying that erre, erres, errent are pronounced /e/ instead of /ɛʁ/. This only seems to happen with verbs with this spelling, as clairer which rhymes is shown correctly. I presume this is something going on with the code that makes final -er pronounced /e/.

Relatedly, I note that all three verbs are displaying with the stem vowel /e/ rather than the correct /ɛ/ in forms such as errons/clairons, errais/clairais, erra/claira (I know there's some metaphony going on with /ɛ/ being raised to /e/ before an ending containing /e/ or /i/ but it doesn't occur before other vowels and it's allophonic anyway). 18:55, 7 July 2016 (UTC)

The missing /ʁ/ should be fixed. KarikaSlayer (talk) 20:46, 7 July 2016 (UTC)
Module:fr-verb should really have test cases to detect things like this. DTLHS (talk) 20:49, 7 July 2016 (UTC)

Time zone bug![edit]

Recent Changes is showing the correct time, but (for example) WT:TR is showing all the time-stamps an hour earlier. It's about 04:20 now, but the message I just posted in the Tea Room is showing a time of around 03:20. Definite bug. Equinox 03:23, 8 July 2016 (UTC)

It's 8:31 UTC now, and my timestamp is showing that, so maybe it's been fixed. —Aɴɢʀ (talk) 08:31, 8 July 2016 (UTC)
My initial message in this subsection still shows 3:something for me, so nope. Equinox 08:31, 8 July 2016 (UTC)
The timestamp of your initial message is plain text now, so it's not going to change. But if the time registered in the history matches the real time, then the bug is fixed. —Aɴɢʀ (talk) 17:39, 8 July 2016 (UTC)

Strange invisible characters again[edit]

What did I just change with diff? I can't tell what it is, but it's blocking MewBot from adding in {{cog}}. —CodeCat 17:54, 8 July 2016 (UTC)

That's a nonbreaking space (U+00A0). DTLHS (talk) 17:58, 8 July 2016 (UTC)
String converters (like this) can be used to see what's going on. --Z 17:48, 9 July 2016 (UTC)
string.__repr__() in Python works too (yields {{etyl|fo|-}}\\xa0{{m|fo|-ligur}}) . --Njardarlogar (talk) 21:12, 9 July 2016 (UTC)

Rewrote {{given name}} in Lua and added features[edit]

{{given name}} now supports a new parameter |xlit= for an approximate transliterated name, in addition to |eq= for an equivalent name. For the difference, consider e.g. Михаил ‎(Mixail) with transliterated name Mikhail and equivalent name Michael. It also supports multiple transliterated and equivalent names, and multiple main forms of diminutives, along with alternate display text and manual transliterations of those main forms. Note that |xlit= isn't named |tr= because it's not used to represent transliterations in typical Wiktionary form but in "popular" (approximate) form. Benwing (talk) 17:17, 9 July 2016 (UTC)

I added support for dimtype= to specify endearing and pejorative diminutives (which exist in Russian). I tried to display the value of from= in the defn line, as someone requested, but it messes up lots of existing names like Ashley. Benwing2 (talk) 23:59, 9 July 2016 (UTC)
Seems useful. Thank you. :) - -sche (discuss) 03:55, 11 July 2016 (UTC)

Template for "see ..." in defns?[edit]

How do you put a definition that refers to another word? In this case the word is йо́ркский ‎(jórkskij), which is an adjectival version of York but also occurs as part of нью-йо́ркский ‎(nʹju-jórkskij), the adjectival version of "New York". One definition should say {{lb|ru|attributive}} [[York]], while another should say "See нью-йо́ркский ‎(nʹju-jórkskij)" or something similar. I know about {{only in}} but it doesn't seem right because the term has a definition on its own, just one that's not as common as when it forms part of the larger word. Benwing2 (talk) 03:21, 11 July 2016 (UTC)

If йо́ркский only means "New Yorkian" when it's in the form нью-йо́ркский, I have seen {{only in}} used even when there are other senses present on other lines. But if йо́ркский can sometimes be a synonym of нью-йо́ркский, then using {{synonym of}} seems like the thing to do. - -sche (discuss) 03:54, 11 July 2016 (UTC)
Yes, I'm pretty use that йо́ркский only refers to New York in the form нью-йо́ркский. Benwing2 (talk) 04:01, 11 July 2016 (UTC)
I wouldn't say that йо́ркский refers to anything at all in the form нью-йо́ркский ‎(nʹju-jórkskij). As our etymology section indicates, that form is Нью-Йорк ‎+‎ -ский, not нью + йоркский. The only definition of йо́ркский ‎(jórkskij) should be "pertaining to York (e.g. England or Ontario)"; it shouldn't also say {{only in|нью-йо́ркский}}. Likewise I wouldn't expect an English entry Yorker that's defined as {{only in|New Yorker}}. —Aɴɢʀ (talk) 14:58, 11 July 2016 (UTC)
OK, maybe a better example is яга́, which occurs primarily in баба-яга but also has some meanings of its own. Benwing2 (talk) 02:59, 12 July 2016 (UTC)


Hello. Can somebody fix it? Something went bad and now many transcriptions don't look the way they should (see Template:es-IPA). All I did was to remove excessive narrowness in phonetic transcription. Mr KEBAB (talk) 11:19, 11 July 2016 (UTC)
Besides, the example: "{{es-IPA|hielo}}: /ˈjelo/, [ˈjelo]", found here, was utterly wrong, as no diphthongs starting with /j/ can appear word-initially, only the /ɟ͡ʝV/ sequence can (see Martínez Celdrán - Problems in the classification of approximants (2004)). Therefore, initial <hiV> is the same as <yV> (where V stands for "vowel"). Mr KEBAB (talk) 12:59, 11 July 2016 (UTC)

Please add test cases to Module:es-pronunc/testcases, so we can have a better idea of the expected behavior and the current problems. DTLHS (talk) 19:10, 11 July 2016 (UTC)
Thanks, but that module should display both phonemic (between slashes //) and phonetic (between brackets []) transcriptions, or only phonetic ones. As of now, there are only phonemic transcriptions, and we don't have any problems with those - it's the phonetic transcriptions that are problematic, though JohnC5 helped me a bit with that (thanks man). Mr KEBAB (talk) 19:34, 11 July 2016 (UTC)
OK, I think. DTLHS (talk) 19:37, 11 July 2016 (UTC)
(Sorry, Firefox crashed and deleted my post, it pissed me off and I had to take a break).
Thanks for fixing it, it works as it should. Here's the list of the problems:
- First of all, we have a really weird problem of <ɟ͡ʝ> not being displayed correctly and therefore it is not detected as a single sound, so that the approximant allophone [ʝ] doesn't appear where it should. On the other hand, the other affricate, <t͡ʃ>, is displayed without a problem!
- The post-pausal, word-initial voiced plosives /b, d, ɡ/ are incorrectly transcribed as if they were approximants *[β, ð, ɣ], but they should be transcribed [b, d, ɡ] because they're not lenited unless a word-final non-nasal (in case of /d/ also not the lateral /l/) consonant directly precedes them - see [4].
- /o/ in the word cónyuge is incorrectly transcribed as not nasalized *[o]. It is nasalized, because it precedes coda /n/ - see [5]. I think that the fact that <ɟ͡ʝ> seems not to be detected by the module is directly influencing the non-nasalized transcription, because when I briefly switched the symbol <ɟ͡ʝ> to <ɟ>, the vowel was transcribed correctly...
- Word-initial prevocalic sequence <hi> is incorrectly treated as if it were a diphthong onset, but, as I said above, only /ɟ͡ʝ/ can appear word-initially. <hiV> is merely a spelling variant of <yV>, where "V" stands for "vowel". Mr KEBAB (talk) 22:24, 11 July 2016 (UTC)
All of these bugs should be fixed. KarikaSlayer (talk) 00:54, 12 July 2016 (UTC)
Thanks! Some of them are but, again, some of them aren't - see Module:es-pronunc/testcases. We also have a weird bug on pez#Pronunciation_2, where the Latin American pronunciation (/ˈpes/) is not listed at all... Mr KEBAB (talk) 00:58, 12 July 2016 (UTC)
I disagree with the statement that /j/ cannot occur word-initially in Spanish. Argentinian Spanish, at least, makes a clear distinction between word-initial hi- [j] and word-initial y- [ʃ]. A minimal pair is hierba vs. yerba (as in yerba buena, yerba mate). Benwing2 (talk) 03:08, 12 July 2016 (UTC)
Also hierro vs. yerro. Benwing2 (talk) 03:09, 12 July 2016 (UTC)
The source above disagrees. Mr KEBAB (talk) 05:05, 12 July 2016 (UTC)
The source above doesn't say which dialect of Spanish it's referring to. It seems to be treating Spanish monolithically, which is careless. —Aɴɢʀ (talk) 09:16, 12 July 2016 (UTC)
That's still much better than going with someone's OR. Mr KEBAB (talk) 13:49, 12 July 2016 (UTC)
This isn't Wikipedia. There's a huge amount of information such as pronunciation that can't be sourced to Wikipedia standards for many entries. Even when there's sourcing it takes quite a bit of synthesis (another dirty word at WP) to make it work in the entries. I don't know that it's a good idea to exclude regional pronunciations because speakers haven't checked the latest phonological research before having a conversation. Chuck Entz (talk) 14:01, 12 July 2016 (UTC)
Even if Benwing2 is right, we still have no idea how widespread that distinction is. I really don't think that his word is enough in this case. Mr KEBAB (talk) 14:45, 12 July 2016 (UTC)
FWIW, the Spanish Wiktionary itself (which one would expect might know a thing or two about Spanish) says es:hierro /j-/ and es:yerro /ʝ-/, and es:hierba /j-/ and es:yerba /ʝ-/, are not homophones. Lourdes Aguilar, Vocales en grupo (2010), page 57, has some information about this, commenting that "Desde este punto de vista, las palabras hierro y yerro serían homófonas en la norma castellana, aunque no en otras variantes." - -sche (discuss) 15:02, 12 July 2016 (UTC)
That's good to hear, because it fits perfectly with our European-Latin American distinction. Does the author say anything about the /ʝ-j/ issue before other vowels? Mr KEBAB (talk) 15:22, 12 July 2016 (UTC)
This phonemic contrast seems to be based on spelling pronunciations, since hierba and yerba are etymologically identical, both coming from Latin herba. —Aɴɢʀ (talk) 15:47, 12 July 2016 (UTC)
How the contrast originated is irrelevant. The question is only whether it exists. --WikiTiki89 17:28, 12 July 2016 (UTC)
Maybe not completely identical: the difference in spelling might be an indication of regional borrowing, or of a different register. Chuck Entz (talk) 03:23, 13 July 2016 (UTC)

CAT:Pages using invalid self-closed HTML tags[edit]

What is causing CAT:Pages using invalid self-closed HTML tags to show up on a bunch of pages? I'm finding it on several Irish entries (e.g. abhaill, abhainn, achar), but I can't find any HTML tags on those entries. Is it being triggered by a template? There's no template listed in the category, so if so, I don't know how to find the template causing the trouble, nor what exactly the trouble is. —Aɴɢʀ (talk) 15:22, 14 July 2016 (UTC)

<p /> used in {{ga-decl-f3}}. There may be other templates with the same problem. DTLHS (talk) 15:28, 14 July 2016 (UTC)
<p /> should be replaced with <br />. Can we do this by bot? --WikiTiki89 15:34, 14 July 2016 (UTC)
{{rfd}} uses a self-closed <span id="..." /> tag. I think this should be allowed. This is a bit ridiculous. In the Irish declension templates, <p /> is just superfluous and can be removed entirely. --WikiTiki89 15:43, 14 July 2016 (UTC)
Yeah, I'm going through them all now and removing it. For the life of me I can't remember why I ever put it in in the first place. —Aɴɢʀ (talk) 15:57, 14 July 2016 (UTC)
It might be ridiculous but if they're going to complain then it's easy enough to fix. DTLHS (talk) 15:59, 14 July 2016 (UTC)
Writing <span id="..."></span> instead of <span id="..." /> when you don't need to have any content between the tags is ridiculous. I refuse to fix these and will actively oppose the "fixed" syntax. --WikiTiki89 16:10, 14 July 2016 (UTC)
[6] It sounds like they are planning to make this syntax break totally in the future. So you may not have a choice. DTLHS (talk) 16:18, 14 July 2016 (UTC)
That's pretty nonsensical. <span/> is by definition allowed in XML and is considered more or less equivalent to <span></span>. Are they trying to break XML compatibility? —CodeCat 16:23, 14 July 2016 (UTC)
HTML has never been fully XML-compatible. That's what XHTML was for. --WikiTiki89 16:28, 14 July 2016 (UTC)
Breaking that compatibility on purpose is worse though. I think XHTML is the way forward. —CodeCat 16:40, 14 July 2016 (UTC)
In general, most of the ways HTML breaks compatibility are beneficial. However, this particular thing is pretty ridiculous. --WikiTiki89 16:46, 14 July 2016 (UTC)
I Googled around a bit more and found that <span id="..." /> was never valid HTML and was always interpreted as just an opening <span id="..."> tag. Supposedly this causes a lot of weird problems. Maybe fixing these to <span id="..."></span> will solve some of our weird formatting mysteries. --WikiTiki89 20:18, 14 July 2016 (UTC)
Right. HTML predated XML, and it's always had various elements where the end-tag is either optional (e.g. <p>; the element ends when it has to either due to a containing element ending, or due to a start-tag for an element that can't be contained in a <p> element) or actively forbidden (e.g. <br>; the element is inherently empty). XML doesn't allow that concept, but it has a "empty tag" concept (such that e.g. <foo/> is equivalent to <foo></foo>); and experimentation showed that existing (pre-XHTML) browsers simply treated e.g. <foo /> (note the space) as if it were <foo>; so with XHTML (a reworking of HTML to be XML) came the recommendation to use XML's empty-tag syntax for elements that are inherently empty, but otherwise to avoid it. That way XHTML pages would still work correctly with pre-XHTML browsers, even though it wasn't actually valid HTML. (And MediaWiki has, for years, supported using HTMLTidy to clean up bad (X)HTML, including converting XHTML that doesn't conform to this recommendation into XHTML that does.) —RuakhTALK 05:38, 15 July 2016 (UTC)
I've fixed all of the Irish declension templates. There are still other pages in the category, but I feel like I've cleaned up my own mess. —Aɴɢʀ (talk) 17:02, 14 July 2016 (UTC)

Is <references /> an invalid self-closed HTML tag? —Aɴɢʀ (talk) 09:28, 15 July 2016 (UTC)

Answering my own question: no, but <noinclude /> is. —Aɴɢʀ (talk) 09:42, 15 July 2016 (UTC)
I've cleared out the category all except for MediaWiki:ExtractFirst.xsl, mostly because I don't understand what it is for, what XSL even is, and why the page is wiki-rendered rather than rendered as source code like JS and CSS pages. --WikiTiki89 18:28, 15 July 2016 (UTC)
XSL is an XML-based transformation language. So it shouldn't be considered Wikicode; it's XML, and self-closing tags are perfectly valid for it. —CodeCat 18:37, 15 July 2016 (UTC)
FWIW, the purpose of the page is explained on the talk page. - -sche (discuss) 18:50, 15 July 2016 (UTC)

How to stop the option, Compact language links?[edit]

I noticed today that the languages list is compacted instead of leaving all (or allowing us to always show some languages). How to stop that option? I see no option to stop it. In Wikipedia we can enable of disable this option from the Beta features. --Mahmudmasri (talk) 19:47, 14 July 2016 (UTC)

It's in Preferences, under the Appearance tab. Keith the Koala (talk) 19:52, 14 July 2016 (UTC)

Number of language codes[edit]

would it be possible, without being too "expensive", to have WT:LOL or some other page (WT:STATS?) display a real-time count of how many language codes there are? This information would be of interest to people (such as me) examining how many languages there are and how many have entries. - -sche (discuss) 18:55, 15 July 2016 (UTC)

Yes check.svg Done (diff, diff). Feel free to change the wording. Also, let me know if you want separate counts for natural vs. reconstructed vs. constructed languages. Or if you also want a count of etymology languages, scripts, or language families. --WikiTiki89 19:16, 15 July 2016 (UTC)
Thank you! Counts of natural vs. reconstructed vs. constructed languages would be useful. However, there is a distinction between "constructed languages", some of which have no type= set (but which all have family = "art"), and "appendix-only constructed languages" (type = "appendix-constructed"). Counts of both would be interesting. Of the two, I'd be more interested in knowing the number of family = "art" languages vs actually-natural ( "art") languages, but it's easy enough for me to generate a count of family = "art" languages when I need one, so I can do without a real-time/automatic count if one would be too difficult to add. At this time, I don't see a need to count scripts or families. Our script codes overlap enough (Latn, Latinx) that a count of codes wouldn't have much relation to the number of distinct scripts we include. - -sche (discuss) 20:02, 15 July 2016 (UTC)


Why does risk appear in Category:Ancient Greek terms needing native script? Even if this can be explained and justified in someone's mind, it seems likely to waste someone's time, as it has mine. DCDuring TALK 22:07, 16 July 2016 (UTC)

Because of {{der|en|gkm|tr=riziko|t=sustenance obtained by a soldier through his own initiative, fortune}}. In this case, we treat gkm as an etymology-only variety of Ancient Greek, and the module adds these request categories whenever someone uses a linking template without the actual term to be linked. The alternatives would be to either throw a module error, which would be rather disconcerting for someone who doesn't know Ancient Greek and just has transliterations, or to ignore it and hope someone thinks to add an attention template. Chuck Entz (talk) 23:07, 16 July 2016 (UTC)
Nobody forced you to make this thread. In what way did it waste your time. DTLHS (talk) 23:10, 16 July 2016 (UTC)
Trying to track down the source of the problem so I could correct it. I won't make the mistake of trying to track down such problems again. DCDuring TALK 23:52, 16 July 2016 (UTC)

Category:Ratahan language[edit]

For some reason, I can't get Language family, ancestors, or script into the parameters. Could someone please help me out here? I think it may have something to do with internal coding rather than templates? Philmonte101 (talk) 21:15, 20 July 2016 (UTC)

That's because it was already all included in the data modules- no action required. Chuck Entz (talk) 03:31, 21 July 2016 (UTC)

Typographical error in user page template.[edit]

"User pages of accounts that do not contribute to the dictionary proper may be deleted after about a week." Isn't that supposed to be properly? Philmonte101 (talk) 03:34, 21 July 2016 (UTC)

No, see sense 2.3 of proper. DTLHS (talk) 03:41, 21 July 2016 (UTC)

Let's make audio recording easy![edit]

Hi! This was an actual Wikimedia student/intern project that came to naught, IIRC, but we have plenty of people here who can code pretty well, and (while I haven't kept up, and am gradually becoming Old Uncle COBOL) I believe that it's now fairly easy to do audiovisual stuff in HTML5. So what about it? We must have some hacking talent who can simplify the current horrible process of creating, uploading, licensing (!!) and entry-embedding our beautiful voices. See also [7]. xx, Equinox 18:36, 22 July 2016 (UTC)

Is your only complaint about User:Yair rand/AddAudio.js that it only works in Firefox? DTLHS (talk) 18:53, 22 July 2016 (UTC)
How does one use that? — SMUconlaw (talk) 19:03, 22 July 2016 (UTC)
Add importScript( 'User:Yair rand/AddAudio.js' ); to your common.js. By the way I was able to get it work in Chrome by enabling experimental web platform features in chrome://flags/. DTLHS (talk) 19:05, 22 July 2016 (UTC)
Thanks, will try it out! — SMUconlaw (talk) 19:48, 22 July 2016 (UTC)
Sorry that was the wrong link: try User:Smuconlaw/common.js. DTLHS (talk) 19:50, 22 July 2016 (UTC)
Ha, ha, too late. But I figured it out, and have tagged Talk:Smuconlaw/common.js for speedy deletion. — SMUconlaw (talk) 19:52, 22 July 2016 (UTC)
Not actually aware of that! (I use Chrome. I don't really want to install another browser, but I might do, for this purpose.) For the purpose of me installing Firefox purely to record shit for Wiktionary: 1. Does it work well and reliably? (Can regular Wiktionary users vouch for it?) 2. How do you actually use it? The page says it lacks documentation. Pretend I'm your grandmother. 3. Are we okay for the legal aspect, since Wikipedians regularly delete audiovisual media that lack the tiniest permission detail? (4. Brownie points only. I thought HTML5 was a standard and we didn't have BLINK and IF-IE6 any more. Why do I need to install a whole other browser just to record my voice?) Equinox 19:16, 22 July 2016 (UTC)
Like I said I'm pretty sure you can get it to work with Chrome now. DTLHS (talk) 19:23, 22 July 2016 (UTC)
@Equinox: Grandmother-level instructions on how to use it:
  1. To enable the script, go to Special:MyPage/common.js, click the "Edit" link (or "Create"), paste importScript( 'User:Yair rand/AddAudio.js' ); into the text box, and press "Save page".
  2. To add audio to an entry, navigate to the entry, and press the "⚫" button next to the "Add audio pronunciation" text. (It should be in the Pronunciation section, or where a pronunciation section would go if there was one.) If this is your first time using the tool, you may need to select a microphone from a list given in a box that pops up. Say the word into the microphone, and then press "⚫" again to stop recording. You can press "►" to listen to the recording to make sure it sounds right, and if it doesn't, you can press "⚫" to try recording it again. For certain languages, you can select a region/dialect code for the audio by clicking on one of the codes to the right of the "►" button. Press "✔" and then click the "Save page" button at the top-left corner of the screen to add the audio to the page and upload the file to Commons. Make sure to wait until the cursor stops showing the "loading" icon before navigating away, so as not to cut off the upload in the middle.
(Okay, maybe not quite grandmother level, but hopefully good enough?)
Re the legal aspect, I kind of just assumed that anyone using the script already knows/consents that content added is licensed under CC-BY-SA 3.0 and GFDL. The script makes the files uploaded have that added as their license by default. --Yair rand (talk) 18:58, 24 July 2016 (UTC)


I tried installing the tool and using it, but got this error message: "Error: NotSupportedError: Operation is not supported". I'm using Firefox 47.0.1. — SMUconlaw (talk) 19:57, 22 July 2016 (UTC)

Using Chrome I can record, but there seems to be a problem uploading: vulnerability @Yair rand DTLHS (talk) 20:06, 22 July 2016 (UTC)
I got the whole process to work on Firefox- I'm guessing there's some cross origin request issue with Chrome that prevents it from uploading. DTLHS (talk) 20:16, 22 July 2016 (UTC)
Presumably this represents either a vuln in Firefox or a bug in Chrome. Our tiny voices will be ignored for 3 years but is there anything we can report? Equinox 20:20, 22 July 2016 (UTC)
I think it's a security feature in Chrome- there are ways to disable it, but we should wait and see what Yair rand says. DTLHS (talk) 20:23, 22 July 2016 (UTC)
@Smuconlaw: The Firefox issue should be fixed now, I think. @DTLHS: Chrome currently doesn't support directly recording to .ogg, afaict, so Commons is returning a filetype-mime-mismatch. --Yair rand (talk) 18:31, 24 July 2016 (UTC)
Thank you, that's unfortunate. DTLHS (talk) 18:38, 24 July 2016 (UTC)

Audio into WT:FUN[edit]

I'd like to use the audios as part of a new WT:FUN competition. Not so sure on the ins and outs of the game, though. Something like X Factor??? --Turnedlessef (talk) 19:07, 24 July 2016 (UTC)