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


May 2016

Disabling MediaWiki keyboard shortcuts[edit]

How does one disable the MediaWiki-specific keyboard shortcuts?

I'm not sure if something has changed in the past couple months, or if my typing has gotten worse, but I have found myself running afoul of MediaWiki-specific keyboard shortcuts, which have caused me to lose considerable work. I will be editing a page and typing something, and mid-typing, I've apparently accidentally hit a key combo that is specially mapped just for MediaWiki, and up pops the "Confirm Navigation: Are you sure you want to leave this page?" dialog -- only since I'm mid-word, the next letter I type is accepted as OK, and unless I've hit Preview at some point, all of my work is suddenly lost. I touch-type at a decent clip so that I might not even see more than a flicker in the UI before suddenly my browser is showing a different page altogether. Going back in the browser doesn't work.

These shortcuts are apparently defined here. Alt-N, for instance, is apparently a keyboard shortcut to go to my own Talk page. How is this remotely useful? This only works on MediaWiki sites like Wiktionary or Wikipedia. I have *never* used these, and I didn't even know they existed until I started running into this usability bug. I have no interest in *ever* using them. I want them to go away completely.

Where do I give feedback on the usability issues presented by these poorly discoverable keyboard shortcuts?

How can I disable these? ‑‑ Eiríkr Útlendi │Tala við mig 23:13, 4 May 2016 (UTC)

This is really a browser issue. Which one are you using? Equinox 23:14, 4 May 2016 (UTC)
Add $( function () {$( "[accesskey]" ).removeAttr( "accesskey" );}); to your common.js. --Yair rand (talk) 23:16, 4 May 2016 (UTC)
  • @Equinox, I'm using Chrome primarily. However, these are shortcuts specific to MediaWiki sites: they don't do anything when I'm browsing the web in general. Alt+X on Wiktionary or Wikipedia takes you to a random entry. Alt+R takes you to Special:RecentChanges. These work in Chrome, but it seems they do nothing in Firefox or IE 11.
    • Accelerator keys ought to be supported by all browsers (though the exact modifier keys, e.g. Ctrl, Alt, Shift, may vary). They are a Web standard. Equinox 23:33, 4 May 2016 (UTC)
  • I agree that accelerators should be supported. I object, quite strongly, to how this has been implemented in MediaWiki, at least with regard to Chrome. When I hold Alt and press F, I expect to see the File menu, and indeed this works as expected in Chrome. I do not expect such an accelerator combo to suddenly whisk me away to another page entirely -- especially when these combinations are not discoverable, are not advertised anywhere, and only work here. ‑‑ Eiríkr Útlendi │Tala við mig 23:41, 4 May 2016 (UTC)
  • Re "only work here": sites can define their own keys; that's the whole point. Not every site has the same features. Re conflicts with built-in browser commands: yes, that sucks; Chrome won't let you change this, though Opera used to. Equinox 00:03, 5 May 2016 (UTC)
  • I wouldn't mind so much if the accelerators were not effectively destructive -- I've lost data due to the current implementation. Accelerator keys in regular apps first open a menu, and then you hit the second combo to execute the relevant command in that menu -- the user has visibility into what is happening. For MediaWiki, I'd vastly prefer if the first keypress just activated the relevant command / link, rather than immediately executing it. For example, Alt+X should activate the Random entry menu item on the left-hand menu; the user would then press Enter to actually go to that link. Similarly, Alt+N should activate the user's own Talk link at the top, and Enter would go to the link. But with no visibility into what's going on, and no clear advertising about the shortcuts, MediaWiki's behavior becomes mysterious and frustrating. ‑‑ Eiríkr Útlendi │Tala við mig 00:18, 5 May 2016 (UTC)
  • I agree. GUIs in general have gone down the toilet lately (probably because of pandering to mobile devices): look at the near-total removal of pull-down menus from Windows 10. However, I do use Chrome, and in most cases I find that if you go Back to a previous page with a textbox, it remembers which text was in there. Personally I use the Wiktionary shortcut keys a lot, even the ones for talk pages and stuff. (My only big Chrome issue is Ctrl+W closing the entire browser; this key was designed to close a single window in multiple-document interfaces in the early days of Windows, and nobody does MDI any more, so I have no idea why Google implemented it. Easy to hit when you mean Ctrl+A to select all.) As I say, Opera did let you customise all keystrokes, which was amazing, but Opera also committed suicide a few years back and has reduced itself to a worthless featureless browser, hence my switch to Chrome. Equinox 00:22, 5 May 2016 (UTC)
  • Never used Opera. I'm curious about your Ctrl+W experience; for me, it just closes the currently active tab. I've also defaulted to using Ctrl+F4 to close tabs, in part because Alt+F4 reliably closes apps in Windows, whereas Ctrl+Q doesn't (it closes some, but not others).
I'm not sure what the particular key combo is, but something in MediaWiki causes a reload of the current page, in edit mode, but with the edit box reverted to the last edit -- basically reloading the page, where hitting Back just gets you to the page in reading mode. Very frustrating.
After testing, I think it might have been Alt+O, defined as Login -- if you're already logged in, it just reloads the page you're on, wiping anything in the edit window buffer in the process. I'm guessing that Alt+E Edit might do the same thing. ‑‑ Eiríkr Útlendi │Tala við mig 00:39, 5 May 2016 (UTC)
(Continuing on your talk page since I've taken this a bit off topic.) Equinox 01:00, 5 May 2016 (UTC)


@kc kennylau A bit confusing. I had to fix the past participle myself, and I don't know where the "assis" conjugations for the present tense came from, any sources/attestation for them? Hillcrest98 (talk) 23:39, 5 May 2016 (UTC)

@Hillcrest98: Fixed. I copied those from the deleted template Template:fr-conj-asseoir, in which those erroneous forms were added by Wonderfool's account User:Rising Sun. --kc_kennylau (talk) 12:13, 6 May 2016 (UTC)

Bug with translations boxes[edit]


I often find that, when I load a page, translations boxes are automatically closed, but no link appears to open them (even if I click on the heading, the box doesn't open). Sometimes the "show" link appears, sometimes it doesn't.

My Javascript is always enabled of course, and I use Windows 7/FF latest version (46.0.1): I guess that I'm not the only one to encounter this bug, and that the average visitor doesn't know he should reload the page to make the translations appear (he could think there isn't any translation in the page).

Does anyone have any idea how to fix this bug? — Automatik (talk) 14:22, 6 May 2016 (UTC)

When this happens to me, refreshing the page usually fixes the problem (sometimes a cache-bypassing refresh is necessary). --WikiTiki89 15:20, 6 May 2016 (UTC)
The average visitor doesn't have necessarily this reflex: maybe it could be considered not to close by default translations boxes. — Automatik (talk) 11:08, 8 May 2016 (UTC)
Does it really occur to you "often"? Glad I met you! Could you please open the console (by pressing F12) and make a screenshot of the console error next time it happens to you?--Dixtosa (talk) 12:31, 8 May 2016 (UTC)
Dixtosa: there isn't any console error when it happens, but it just happened to me right now on botany (that said, if I reload the page, it doesn't happen again). Recently, it happened from time to time, not often. But on the French Wiktionary where we do not close by default translation boxes, it never happens. — Automatik (talk) 12:17, 18 May 2016 (UTC)

Right now again, I was unable nor to see nor to edit translations in the scholasticism entry. It's really disturbing, and giving the poor quantity of Javascript gadgets I enabled, I'm probably not the only one to encounter this issue. — Automatik (talk) 02:15, 19 June 2016 (UTC)

Entries not automatically leaving category (Cat:Gothic romanizations without a main entry)[edit]

Lately I've been adding a lot of Gothic terms, both lemmata and non-lemma forms, but the number of pages in Category:Gothic romanizations without a main entry does not appear to be going down, it's stuck at 7,499. How can I see the real number/when does this update? Kleio (t · c) 17:19, 6 May 2016 (UTC)

You might have to make a null edit to the page with the romanization on it to refresh the category. —Aɴɢʀ (talk) 17:34, 6 May 2016 (UTC)
Lordy. That's a lot of pages to refresh. Will it not sort itself out in time/are there no shortcuts? Kleio (t · c) 17:40, 6 May 2016 (UTC)
You don't have to refresh all the pages in the category, just the ones that should be disappearing from the category, i.e. the ones you've created Gothic-script entries for. —Aɴɢʀ (talk) 17:42, 6 May 2016 (UTC)
It should sort itself out over time. --WikiTiki89 17:51, 6 May 2016 (UTC)
FWIW, the category now has 7487 entries when I look. —Aɴɢʀ (talk) 17:55, 6 May 2016 (UTC)
I've been fixing it for some of my contributions, I'm an impatient person Kleio (t · c) 18:04, 6 May 2016 (UTC)

translation-entry error for Classical Hebrew (ISO 639-3 HBO)[edit]

I get the following error message when attempting to add translations for Classical Hebrew (ISO 639-3 HBO): "Lua error in Module:languages/templates at line 28: The language code 'hbo' is not valid.: Lua error in Module:parameters at line 110: The parameter "<strong class" is not used by this template." NicoleSharpRFS (talk) 21:22, 7 May 2016 (UTC)

@NicoleSharpRFS Wiktionary:About_Hebrew#Dialects_and_languages DTLHS (talk) 21:31, 7 May 2016 (UTC)
@DTLHS Thanks for the info; I did not know that Wiktionary did not differentiate entries in Modern versus Classical Hebrew. Perhaps the translation box can have the error message changed to inform users of that when attempting to enter HBO translations? NicoleSharpRFS (talk) 21:51, 7 May 2016 (UTC)
One thing we can do is have check whether the language code exists as an etymology-only code and produce a more descriptive error message based on that (such as "The language code 'hbo' is an etymology-only code"). @CodeCat: What do you think? --WikiTiki89 14:42, 9 May 2016 (UTC)
That could be done, but the difficulty is that the error message isn't actually generated by the language module but by each individual module that uses it. The getByCode function just returns nil if the language isn't found. So a lot of modules would have to be changed. Also consider that for templates like {{etyl}}, the code tries different modules in turn when looking up a code; if one of them returns nil, then it tries the next, and only when none of them return anything is an error triggered. So we can't really change the nil-return behaviour. —CodeCat 16:15, 9 May 2016 (UTC)

Formatting error in Module:io-conj[edit]

There is a formatting error in a new module that I made with the name Module:io-conj which causes some pages to show incorrectly. Could somebody help me fix this formatting problem? I looked at the HTML and Lua code for quite some time and I don't see what I did wrong. Here is an example. Robin van der Vliet (talk) (contributions) 22:38, 7 May 2016 (UTC)

I saw "amote|}" in the final cell, a sign that the table wasn't being closed properly. I added an extra newline to the code and it seems to be okay now. —suzukaze (tc) 22:42, 7 May 2016 (UTC)
Thank you, it looks like it works perfectly now! Robin van der Vliet (talk) (contributions) 15:12, 8 May 2016 (UTC)

Category:Horse racing and Category:Horses[edit]

Could somebody make Category:Horse racing (and its language-based subcategories) a subcategory of Category:Horses (and its language-based subcategories)? Thanks! Purplebackpack89 23:04, 7 May 2016 (UTC)

Horses is a category for terms for horses. Terms found in horse racing aren't a subset of that. —CodeCat 23:14, 7 May 2016 (UTC)

My Wiktionary programs don't work any more[edit]

Example: User:Equinox/Antiblue. Using the DotNetWikiBot library. The error is: "Login failed. Check your username and password." Is this to do with the switch from HTTP to HTTPS, possibly? Any ideas on how to fix it? (Just changing the login URL to use HTTPS doesn't help. P.S. It really annoys me that nobody cares a crap about backward-compatibility any more. It used to be considered a big deal.) Equinox 14:02, 8 May 2016 (UTC)

Which version of the library are you using? 3.15 targets MW 1.27 but we are still on 1.26.x so this might be it.--Dixtosa (talk) 15:58, 8 May 2016 (UTC)
Just upgraded from 3.10 to 3.15. Now it logs in but says an XML "root element is missing". Hmm. Never seen that before. Equinox 17:53, 8 May 2016 (UTC)
Aha. Using the new version and using an HTTPS URL fixed it. Equinox 17:55, 8 May 2016 (UTC)

Subtle etymtree problems[edit]

I just ran into a module error at stella caused by the changing of {{l|la|stella}} to {{l|la|stēlla}} in {{etymtree/la/stella}}. This made it so the module was no longer able to find a match for "stella" (without the macron) in the tree. Changing the branch term to stēlla (with the macron) didn't work, either, because it's not a valid Latin entry name. The solution I finally arrived at was to change {{l|la|stēlla}} to {{l|la|stella|stēlla}} in {{etymtree/la/stella}}.

The problem with the way etymtree is currently set up is that perfectly innocent edits in one place can cause module errors somewhere else that the performer of those edits doesn't see- and may even may be completely unaware of.

That may not be so easy to deal with in the short term, so can we at least make it so the module compares the branch term to the the spellings actually linked to by the tree's terms (i.e., after the diacritics have been stripped, etc.)? Or, if that introduces too much overhead/complexity, at least add an explanation to the documentation so people either won't cause the problems in the first place, or so that people encountering the module errors know what to look for? Thanks! Chuck Entz (talk) 05:15, 9 May 2016 (UTC)

I've been working on a new template called {{desctree}} that replaces {{etymtree}} altogether, so it may be a solution in the long term. The new template doesn't use a centralised page for the entire descendants tree, but it re-uses the descendant list already present in the entry. Simply said, it allows you to transclude one entry's descendants as part of another entry's descendants, reducing duplication. The template isn't entirely mature yet, there are some things that need to be changed before it can be used generally. —CodeCat 16:19, 9 May 2016 (UTC)

Help with etymtree template[edit]

I'm new to this; I took a stab at doing an etymtree template for Latin canto (https://en.wiktionary.org/wiki/Template:etymtree/la/canto), using that of stella (https://en.wiktionary.org/wiki/Template:etymtree/la/stella). But when I insert it the same way under "Descendants" on the canto page, I get the error message "Lua error in Module:etymtree at line 84: Branch not found." If I change the 'o' at the end to a macron 'ō', I get a different error message: "Lua error in Module:etymtree at line 21: Invalid root". I'm not sure what I'm doing wrong here. The pages look identical as far as I can tell; am I missing something? Word dewd544 (talk) 00:27, 10 May 2016 (UTC)

Wow, never mind; I just realized the thread above pretty much answered my question. Word dewd544 (talk) 00:30, 10 May 2016 (UTC)
Yep. The fact that I was working with stella at all was due to a module error caused by your edits, and I started the thread above precisely because it struck me as for too easy to make the error you made (if one can really call it an error) and far too hard to figure out what went wrong afterwards. I'm glad the time I spent racking my brains to figure out why suddenly 2+2≠4 was of benefit to someone... Chuck Entz (talk) 01:41, 10 May 2016 (UTC)

Torlakian Serbo-Croatian[edit]

Could someone add the following for w:Torlakian to Module:labels/data/regional?

labels["Torlakian"] = {
        display = "[[Torlakian]]",
        plain_categories = {"Torlakian Serbo-Croatian"},

We already have the other three major divisions (Chakavian, Kajkavian, Shtokavian), and Torlak seems to have been left out by happenstance. Thanks, Vorziblix (talk) 05:14, 10 May 2016 (UTC)

Done, except I made the display link to the Wikipedia article instead of our rather uninformative entry. —Aɴɢʀ (talk) 10:03, 10 May 2016 (UTC)
Thanks! Vorziblix (talk) 11:50, 10 May 2016 (UTC)

1 alert, 8 messages, yet "You have no notifications."[edit]

Hi there! I seem to have both the notice indicators lit, red and blue at the top of the page but when I click those I'm told I have no messages. I wonder what's up. Weird. Palosirkka (talk) 12:07, 13 May 2016 (UTC)

Maybe they’re notifications and messages from other wikis. This feature was introduced recently. — Ungoliant (falai) 14:38, 13 May 2016 (UTC)
I noticed this too the other day. I got welcome messages from the Vietnamese and Bavarian Wikipedias from 8 months ago (I've never been to either wiki). KarikaSlayer (talk) 14:42, 13 May 2016 (UTC)
I was just notified that edits of mine to various obscure Wikipedias were reverted—three years ago. —Aɴɢʀ (talk) 14:44, 13 May 2016 (UTC)
Thanks guys! So we wait and see. They say nothing is contant except change... :) Palosirkka (talk) 17:16, 13 May 2016 (UTC)
I got some of the same kinds of message notifications today. DCDuring TALK 17:32, 13 May 2016 (UTC)
I blame annoying welcome bots. -Xbony2 (talk) 22:31, 13 May 2016 (UTC)
I had a welcome message from the Arabic site, and I've never ever been there. Needless to say it was all Greek to me... Donnanz (talk) 12:26, 18 May 2016 (UTC)

Need help with Gothic declension templates[edit]

There's a problem with Gothic declension templates which list two options for a certain form, separated by a comma: the link in the template will then be to both options with the comma between them, instead of two separate links for the individual option.

You can see an example of this happening here, at 𐍅𐌰𐌿𐍂𐌸𐌰𐌽𐍃 ‎(waurþans). As you see, the neut. nom. and acc. sg. strong forms have two possible options suggested by the template, which in the Gothic script are linked separately as they should, but in romanization they are treated as a single link to waurþan, waurþanata instead of two links to waurþan and waurþanata separately.

This happens in a bunch of Gothic inflection table templates which list two possible forms together and has the unfortunate consequence of making it difficult to see if a given form is attested or not, as all attested forms have been imported in romanization. If someone could fix this for the affected templates I should be very grateful, I myself am pretty much code illiterate unfortunately. — Kleio (t · c) 02:01, 14 May 2016 (UTC)

What's really needed is additional parameters to specify the second form. I don't have the time to do it now, but I'll look tomorrow. —CodeCat 02:08, 14 May 2016 (UTC)
I think the culprit might be {{xlit}} stripping the links out of the transliteration. KarikaSlayer (talk) 02:41, 14 May 2016 (UTC)
Doing this solves the problem, but ideally that shouldn't be necessary. —Aɴɢʀ (talk) 08:20, 14 May 2016 (UTC)

Edit request: Template:was wotd[edit]

The template does not work well with {{wikipedia}}. Adding this style padding: 4px; to the wrapper div helps. --Dixtosa (talk) 16:02, 15 May 2016 (UTC)

Where and how do you put padding: 4px;? Donnanz (talk) 12:29, 18 May 2016 (UTC)
Donnaz, replace the whole content with the one from here--Giorgi Eufshi (talk) 11:26, 19 May 2016 (UTC)
I'm not sure whether I can make head or tail of that, but thanks anyway. Donnanz (talk) 22:45, 19 May 2016 (UTC)

'term' appears as a placeholder[edit]

In Template:etymtree/sem-pro/maʾ-, {{l|lsd|tr=ṃāye}} results in term ‎(ṃāye). 'Term' seems like a poor placeholder because it's a word, and it shouldn't be linked in any case. Better might be [...] which IIRC was what it previously displayed. - -sche (discuss) 23:29, 16 May 2016 (UTC)

It's because you're viewing a template page. Module:links displays "term" as a placeholder on template pages. —CodeCat 23:54, 16 May 2016 (UTC)
There are two problems: 1. This list probably shouldn't be in the template namespace. 2. Module:links/templates currently assumes that its uses in the template namespace are on the pages of the term templates themselves. Both of these problems should be fixed. --WikiTiki89 13:49, 17 May 2016 (UTC)
I fixed the second issue. I still think the first one should also be addressed. --WikiTiki89 13:58, 17 May 2016 (UTC)
Thanks for the explanation, CodeCat, and for fixing the second issue, Wikitiki. - -sche (discuss) 17:01, 17 May 2016 (UTC)

Module:vo-conj weirdness[edit]

There are currently 7 Volapük entries at CAT:E due to "not enough memory" errors in their conjugation tables. At first I thought this was due to the sheer size of the conjugation table combined with the tendency for Volapük to be stuffed full of "Related terms" and "See also" items by the obsessively over-thorough editor Hans-Friedrich Tamke.

Then I looked at zütävön, which has very little more than the bare bones, content-wise, yet overruns the memory limit. When I edit and preview the Conjugations section, the stats at the bottom say it uses 14.84 MB/50 MB. When I do the same for the Verb section, which includes the Conjugations section, it says 43.68 MB/50 MB.

Now, here's where it gets weird: if I comment out {{vo-conj}} and preview the Verb section, the number drops to 2.03 MB/50 MB. If I uncomment {{vo-conj}} and comment out the headword and definition lines, the number is 14.84 MB/50 MB.

It looks like the regular modules and vo-conj are interacting somehow. I did notice that the module uses very generic variable names, so there might be a variable-name or reserved-word conflict, but that's just a wild guess, since I know very little about Lua. Could someone have a look? Thanks! Chuck Entz (talk) 03:49, 17 May 2016 (UTC)

I would guess that it's the string concatenation operations, specifically the 720 iteration loop. String concatenation in Lua is not efficient. It would be better to make a table and then concatenate the table when the loop is complete. DTLHS (talk) 04:02, 17 May 2016 (UTC)
I managed to get the page down to 3-4 MB memory usage by replacing most of the concatenation with table.insert(). KarikaSlayer (talk) 04:12, 17 May 2016 (UTC)


I'd like to add Uralic Phonetic Alphabet proficiency templates (similar to {{User IPA-1}} etc.) Looks like we'd need a new script entry for that, though. Can someone add the suitable script module entry? ("Finno-Ugric Transcription" should probably be an alternate script name.)

Alternately though, it looks like the {{User script-1}} (etc.) templates are also doing some kind of special handling of IPA. Perhaps adjusting them would be sufficient, since we probably don't want to actually use UPA around much. --Tropylium (talk) 22:19, 17 May 2016 (UTC)

I don't think we really need a script code for it. You can add special handling to {{User script-1}}. First, though, you would need to create a template ({{UPA}} or something) that would be used for displaying UPA text, which would also require adding a CSS class for it at MediaWiki:Common.css. --WikiTiki89 14:53, 18 May 2016 (UTC)
Do we need that either, or could we stash that inside the script templates too? Again, we probably aren't going to be regularly using UPA for anything, this would be mainly a "hi, I know how to read the sources if you need stuff converted to IPA" kind of a template. --Tropylium (talk) 19:23, 18 May 2016 (UTC)
I mean, you could probably use "Latinx" for a script code, then you won't need a separate CSS class and all you would need is a template, with essentially the code {{lang|und|sc=Latinx|{{{1}}}}}. That is, if you ever actually want to use UPA anywhere. If all you want is the Babel box, then you can hard-code {{lang|und|sc=Latinx|{{{2}}}}} into {{User script-1}}. But then again, if you never intend to use UPA anywhere, why do you need it on your userpage? --WikiTiki89 19:30, 18 May 2016 (UTC)
The main scenario I'm thinking of is that we probably want IPA pronunciation for various Uralic and neighboring languages, but sources fairly commonly only use UPA.
Though there's also a secondary issue over creating entries for unwritten Uralic languages. Currently e.g. our Ter Sami entries are entered in an inconsistent mixture of UPA (ji̮ɯ̭̄n̜ɛ), IPA (kɨkt) and even mixed IPA-UPA (vɨennče) transcription. (This particular discussion should probably continue over at WT:ASJT though.) --Tropylium (talk) 19:47, 18 May 2016 (UTC)
There is no reason not to include both IPA and UPA in the pronunciation sections. There seems to be a common misconception that all pronunciations must be in IPA. So it wouldn't hurt to create an infrastructure of templates to support UPA. --WikiTiki89 19:58, 18 May 2016 (UTC)
It's not a misconception; all pronunciations do have to be in IPA. But they don't have to be only in IPA. —Aɴɢʀ (talk) 10:02, 19 May 2016 (UTC)
@Angr: Where does it say that? --WikiTiki89 14:56, 19 May 2016 (UTC)
I'm not sure if it's actually written down anyplace, but it seems to be common consensus that pronunciation sections should contain at least the IPA, and may contain other systems (e.g. enPR for English) as well. Wiktionary:Pronunciation#Ad hoc transcription sort of implies this, and Wiktionary:Entry layout#Pronunciation says "Use an established system of pronunciation transcription, such as IPA." That said, however, it looks like Tropylium above isn't talking about Pronunciation sections, he's talking about entry names. —Aɴɢʀ (talk) 15:04, 19 May 2016 (UTC)
Both of those links clearly imply that as long as it's an unambiguous and established transcription system, it doesn't have to actually be IPA. And if you read carefully, the Tropylium said the entry name issue is "a secondary issue over creating entries for unwritten Uralic languages". However, I agree that whenever possible, it's better to also include IPA. --WikiTiki89 15:10, 19 May 2016 (UTC)
That's all well and good in principle, but UPA is neither unambiguous (as a system of phonetic transcription, it comes in varying degrees of closeness, and it also suffers from lacking some distinctions made by IPA), nor established in normal lexicographical use. I would oppose using anything except, perhaps, highly broad transcription, where it actually provides some kind of benefit over IPA (e.g. ś in cases where it is not known if this is [sʲ] or [ɕ]). For example, the pronunciation for ji̮ɯ̭̄n̜ɛ should probably be given simply as IPA(key): [jɨʉ̯nʲɛ]. --Tropylium (talk) 17:05, 19 May 2016 (UTC)

Protected edit request: Template:ja-def[edit]

Template talk:ja-def#Code update. —suzukaze (tc) 06:41, 19 May 2016 (UTC)

Done. Wyang (talk) 10:04, 19 May 2016 (UTC)

Unexplained removal of diacritics[edit]

This template creates a noun table. If I enter characters with macrons into it, the words in the table link to pages without macrons. For exampe water#Middle Low German. This is desirable behaviour for me, but why does it happen? Korn [kʰũːɘ̃n] (talk) 09:52, 19 May 2016 (UTC)

Because Module:languages/data3/g automatically strips all macrons and circumflexes from links tagged as being gml. —Aɴɢʀ (talk) 10:01, 19 May 2016 (UTC)
Well, nice to see that someone had the right idea long time ahead. I'd like to request that an addition is made so that the following glyphs are also stripped: ÄÄ̂Ǟ ää̂ǟ ÖÖ̂Ȫ öö̂ȫ ÜÜ̂Ǖ üü̂ǖ. Korn [kʰũːɘ̃n] (talk) 10:25, 19 May 2016 (UTC)
Yes check.svg DoneAɴɢʀ (talk) 10:42, 19 May 2016 (UTC)

something is wrong with suffix categories containing accents[edit]

Something recently changed that broke suffix categories containing accents in the {{suffixcat}} call. Example: Category:Russian words suffixed with -атый. There's now a big ugly warning that didn't use to be there. Benwing2 (talk) 23:03, 19 May 2016 (UTC)

@CodeCat Do you know what's going on? Benwing2 (talk) 03:20, 21 May 2016 (UTC)
I don't know why it's happening, but I removed the displaytitle override from the module, so the error should be gone. —CodeCat 13:18, 21 May 2016 (UTC)
@CodeCat BTW thanks for doing this, it seems to have solved the problems. Benwing2 (talk) 02:25, 27 May 2016 (UTC)


There are a lot of Norman translations that are out of alphabetic order. I assume that the original problem has been fixed (I have not tested it), but there are still many Translation sections that have the Norman out of order. Often I see where another language, such as Mongolian, was entered after the Norman, and it was placed ahead of the Norman, making it out of place as well. Other examples are: voter, catamaran, bicarbonate, first person, quart, Christ, pâté, grammatical. I just wonder if there is a way to fix these automatically, such as User:AutoFormat (which I don’t think is in use anymore). —Stephen (Talk) 18:42, 21 May 2016 (UTC)

The "original problem" is simply that Norman used to be known as Jèrriais and Guernèsiais, so Norman translation lines are often still alphabetized under G or J, depending on which variety was originally listed. I have no idea if there's any way to fix this other than manually. —Aɴɢʀ (talk) 21:08, 21 May 2016 (UTC)
It can, indeed, be done by a bot: Ive seen many a bot task that involved rearranging whole lines. Chuck Entz (talk) 07:24, 22 May 2016 (UTC)
I correct the order for Norman whenever I come across it, as I have occasionally made the mistake of entering Norwegian just after it when it's in the wrong order, and then I have to move both. I hope that makes sense. Donnanz (talk) 08:58, 22 May 2016 (UTC)

‘Add country flags next to language headers’ breaks the pages.[edit]


The left side is when the flags are off, the right is when the flags are on. --Romanophile (contributions) 08:46, 22 May 2016 (UTC)

Apart from the page being heavily customised I can see a difference, but I haven't got a clue what you're talking about. What kind of flags? Donnanz (talk) 18:58, 22 May 2016 (UTC)
There is an option in Preferences, under Gadgets, called »Add country flags next to language headers«. Before last night, this option added small images of flags next to the headers of the appropriate language sections of each entry. Since last night, it has broken the site by getting rid of the left sidebar and the toolbars at the top of each page. It’s not a consequence of his customizations; the same thing happened to me with default typography. Was there some recently changed code that could have caused this? Vorziblix (talk) 19:12, 22 May 2016 (UTC)
Try now. — Ungoliant (falai) 19:25, 22 May 2016 (UTC)
Seems to work, thank you ^_^ -Xbony2 (talk) 19:32, 22 May 2016 (UTC)
OK, found it. My opinion of the English flag is unprintable. Donnanz (talk) 20:52, 22 May 2016 (UTC)
You can add a different one to your personal css. That’s what I do; using the flag of the Commonwealth to represent English is dumb. — Ungoliant (falai) 20:56, 22 May 2016 (UTC)
As is using flags to represent languages at all! Equinox 21:35, 22 May 2016 (UTC)
That's what I thought. I'll probably end up switching the damned thing off again. Donnanz (talk) 21:46, 22 May 2016 (UTC)

Doubling diacritics[edit]

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. Any thoughts how to fix this? —Aɴɢʀ (talk) 20:01, 22 May 2016 (UTC)

and [edit]

Both of these pages currently run out of memory about halfway down the page. No idea why only these specifically, though I'd guess it's the tables using {{l}}. KarikaSlayer (talk) 21:12, 22 May 2016 (UTC)

It must be caused by {{ja-r}}: [1], [2]. @Haplology, why is this template so memory-hungry? — TAKASUGI Shinji (talk) 14:07, 24 May 2016 (UTC)
Personally I think the Chinese templates are more suspect. —suzukaze (tc) 14:40, 24 May 2016 (UTC)
You are right. It’s {{zh-l}} that is the heaviest: [3]. The Chinese “Compounds” section uses 8.8 MB in the allotted 50 MB per page. The Chinese section uses 27.02 MB while the Japanese one uses 6.75 MB. (You can check it by viewing the HTML source of a preview.) We must modify Module:zh. — TAKASUGI Shinji (talk) 16:17, 24 May 2016 (UTC)
Looks like it's fixed now. KarikaSlayer (talk) 03:02, 25 May 2016 (UTC)
Because one of the less important templates has been hidden... it's not over yet orzsuzukaze (tc) 03:08, 25 May 2016 (UTC)
  • @Wyang: is still running out of memory partway down the page. This really needs to be fixed so that {{zh-l}} doesn't crash big pages. —Μετάknowledgediscuss/deeds 07:55, 26 May 2016 (UTC)
    I don't know how to reduce the memory usage unfortunately. Wyang (talk) 08:19, 26 May 2016 (UTC)
    All the Chinese compounds have been removed, and there is still insufficient memory. Wyang (talk) 00:45, 27 May 2016 (UTC)

Change in function of DISPLAYTITLE Magic Word[edit]

{{DISPLAYTITLE}} no longer allows changing the displayed title to anything that isn't closely equivalent to the actual title. instead, it shows:

Warning: Display title "<title that would have been displayed>" was ignored since it is not equivalent to the page's actual title.

As I understand it, we have a number of templates that depend on the previous behavior of {{DISPLAYTITLE}}, including the ones for our unsupported title entries. This change in behavior seems to be due to the introduction of the configuration setting $wgRestrictDisplayTitle, which defaults to true. Can we change this to false, or get someone to change it for us if we don't have access to it? Chuck Entz (talk) 23:14, 22 May 2016 (UTC)

Has {{DISPLAYTITLE}} ever allowed it? I don’t think so. I correctly see pages like “ . ” and “#”, but I don’t know where the template is. Similarly, Wikipedia has w:Template:Correct title, and the French Wiktionary has fr:Modèle:titre incorrect. — TAKASUGI Shinji (talk) 13:52, 24 May 2016 (UTC)
Yeah, that's never been allowed. Unsupported titles do it through JavaScript. --WikiTiki89 15:19, 24 May 2016 (UTC)
You may want to set a category in MediaWiki:Restricted-displaytitle to track any such wrong usage of DISPLAYTITLE. — Dakdada 08:48, 25 May 2016 (UTC)
Yes check.svg Done: CAT:DisplayTitle errors. --WikiTiki89 15:26, 25 May 2016 (UTC)
It would be nice, but by no means essential, to be able to display taxonomic names in italics (viruses, genera, subgenera, species, some subspecies) or mixed italic and ordinary type (some subspecies, sections, varieties). How could that be done? Would it consume significant programming resources or server resources? DCDuring TALK 16:24, 25 May 2016 (UTC)
Wikipedia does italics for taxonomic names. However, I would oppose that here (although I would support italicizing headwords of taxonomic names). --WikiTiki89 16:46, 25 May 2016 (UTC)
Hunh? Do you mean you support current practice for normally italicized taxonomic names on their inflection line, as well as all other uses of such names here? DCDuring TALK 21:48, 25 May 2016 (UTC)
I didn't know that it was current practice in headword lines, but yeah I support it. My point was that I oppose it for the page title (and I was clarifying that that doesn't mean I oppose it in other places). --WikiTiki89 22:01, 25 May 2016 (UTC)

Automatic welcome message at id.wikipedia[edit]

FYI, it seems you get an automatic welcome message on your talk page at https://id.wikipedia.org/wiki/ just by visiting the project for the first time. (My welcome message is here: https://id.wikipedia.org/wiki/Pembicaraan_Pengguna:Daniel_Carrero)

This could be annoying for some people, because they get a notification here on Wiktionary about that welcome message. --Daniel Carrero (talk) 06:48, 25 May 2016 (UTC)

Formatting changes with verbs that are centred aligning to the left when they are printed[edit][edit]

Hi Wiktionary is brilliant. I am preparing for Polish exams and am finding my new printer does not print the page as is when I select and copy and print.

Anything that is centred is aligned to the left when printed. How can I stop this happening?

However, if i print the whole page with the conjugation not hidden the title conjugaiton appears on the first page and everything on the second and it is perfectly aligned. i just want the title conjugation on the same page as the actual conjugation - it looks neater.

I will be making a contribution to wiktionary as it has been invaluable. Thank You Anne marie

You're very welcome.
I'm not sure how much control we have over printing, this may be a Wikimedia issue, anyone know? Benwing2 (talk) 02:27, 27 May 2016 (UTC)


Could a kind admin remove pra from MOD:families/data and add it to MOD:languages/data3/p? Also, the following languages need to made etymology-only:

  • pmh
  • pka
  • psu
  • pgd

(pinging those involved in the discussion at WT:Beer parlour#Merge all Prakrits: @CodeCat, -sche, Metaknowledge) —Aryamanarora (मुझसे बात करो) 18:34, 25 May 2016 (UTC)

@Aryamanarora: I'm not sure this has reached agreement yet. I'm not saying I disagree―I'm just not sure that we have a consensus on what, if any, action should be taken. —JohnC5 19:41, 25 May 2016 (UTC)

updated since my last visit[edit]

The "updated since my last visit" text on history pages of pages in my watchlist is now highlighted bright green. Why? And can we disable it? --WikiTiki89 19:43, 25 May 2016 (UTC)

You can remove the highlighting by adding span.updatedmarker { background-color:transparent; } to your css, or the site css. - -sche (discuss) 01:44, 26 May 2016 (UTC)
Would people support adding that to MediaWiki:Common.css? And why did it change in the first place? --WikiTiki89 14:52, 26 May 2016 (UTC)
I think "updated since my last visit" has some sort of highlighting on most other wikis. Makes it easier to see where to start if you want to see all changes since the last time you looked at the page. I like it. —Aɴɢʀ (talk) 15:04, 26 May 2016 (UTC)
I just think it's way too bright. We could highlight with a more mellow color. --WikiTiki89 15:16, 26 May 2016 (UTC)
I agree with both of you: yes, it's handy to have highlighting, but this particular color is burning holes in my retinas. Please make it stop!!! Chuck Entz (talk) 01:58, 27 May 2016 (UTC)
I've softened it to "tea green". (I tried the predefined css color "pale green", but it was still too garish IMO.) - -sche (discuss) 08:11, 28 May 2016 (UTC)

My new entry marked as spam[edit]

I just created a definition for the word : Collectory and it keeps reporting it as spam. The definition is:

1. a collection of beloved items and their stories 2. the password for entry on Twicemore.co

Please let me know what I can do to avoid this from happening.

Thanks so much, Nikki

Hi Nikki. That is spam. Stop adding it, and learn how to advertise in an appropriate way without wasting other people's time. —Μετάknowledgediscuss/deeds 16:16, 26 May 2016 (UTC)

Diminutive parameter for lb-noun[edit]

The template {{lb-noun}} ought to have a parameter for diminutive forms, like {{de-noun}} does. Also, who would like to create the module lb-headword, not just for nouns but also for other lemmata? --Lo Ximiendo (talk) 18:15, 26 May 2016 (UTC)

@Lo Ximiendo: I was considering making a module after seeing your earlier request. I would make it similarly to mod:de-headword, but I'm not very familiar with Luxembourgish and might need some guidance. —JohnC5 18:41, 26 May 2016 (UTC)
@JohnC5: You could consider consulting Kolmiel (talkcontribs); knowledge of Franconian forms of language at least. --Lo Ximiendo (talk) 18:48, 26 May 2016 (UTC)
Yes. You can get most of the guidance you need from me, I hope :) Luxemburgish should definitely have diminutives in the template. I've often thought about requsting that, too. Now, the regular form is stem + -chen, but there's much variation (umlaut and other things), so generally the forms will have to be added by hand. An important thing is that Luxembourgish diminutives, unlike the German and Dutch, generally keep their gender and don't become neuter. Plural diminutives are somewhat irregular, or at least there's not one simple rule like in the aforementioned two languages. We might consider putting the plural diminutive into the template as well. But on the other hand, plural diminutive will be found in the respective diminutive lemmas. So it may not be necessary. Kolmiel (talk) 22:52, 26 May 2016 (UTC)
@Lo Ximiendo, Kolmiel: Could you both look at User:JohnC5/lb-sandbox and mod:lb-headword and give comments on things you'd like added/removed/changed/etc? Please fiddle around with the functionality and tell me what template behaviors you prefer. Also, should verbs have more principle parts? Is there any need for |head2=, |head3=? Do verbs ever take both hunn and sinn? —JohnC5 05:26, 27 May 2016 (UTC)
The nouns look very good, I think. I forgot to say that diminutives should not be obligatory and that alternative forms should be possible, but that's the case already. Thanks. --- Verbs: 1.) Yes, they can have both auxiliaries. 2.) I think it would be good to have the third-person singular present as principle part. It's very often irregular and in this case generally enables you to figure out the 2nd person singular and 2nd person plural. --- Adjectives: 1.) We should probably get rid of the feminine because it's always the same as the basic form. I'm 99,9% sure that there's no exception whatsoever. However, we could leave it as a non-obligatory entry for some strange word that might pop up. 2.) The comparative - but not the superlative - is usually analytic (méi XY = "more XY"). So there should be some short key for this, and only the word "méi" should be clickable (if at all). 3.) The superlative is given in the predicative/adverbial form, which as in German has the prepositional element am before it. So superlatives should automatically be preceded by a non-clickable am. Kolmiel (talk) 11:07, 27 May 2016 (UTC)
@Kolmiel: Check it out now. If you think these are fine, we can start switching the current templates over, but the verbs and adjectives would certainly be broken for current entries. If we left them broken for too long, Chuck would leave a message on my page saying there are a bunch of errors. So, if you are prepared to fix all of the verbs or adjectives at one time, we can do it; though I don't know how much help I'll be. Alternatively, we can create {{lb-adj-new}} and {{lb-verb-new}}, switch the lemmata over, replace the code in {{lb-adj}} and {{lb-verb}} with then new template, then rename everything back. Whichever you think is most appropriate. —JohnC5 17:20, 27 May 2016 (UTC)
I generally don't bug people if I know they're working on the problem, though I've been known to complain when someone does the equivalent of shutting off the regional power grid so they can rewire their kitchen... Chuck Entz (talk) 21:33, 27 May 2016 (UTC)
@Chuck Entz: ;) I know. I just was floating options on the best way to do this and would also like for you to get early notice for what may of may not happen. —JohnC5 21:42, 27 May 2016 (UTC)
Thanks guys. I'll check them on Monday or Tuesday, God willing. It's three at night around here, and I don't think I'll get to it during the next two days. Kolmiel (talk) 01:04, 28 May 2016 (UTC)
I'll be away from the internet for about a week starting Sunday, so do whatever you want. I think the operation of the module is fairly straightforward, but otherwise I can help when I get back. —JohnC5 01:26, 28 May 2016 (UTC)
Looks pretty good. Just one thing doesn't seem to exist yet: the analytic "méi"-comparative with another alternative comparative. That happens a lot. (For example, al "old" has méi al and eeler, the latter of which is often used in the sense of "rather old" as in "older people".) Kolmiel (talk) 11:30, 30 May 2016 (UTC)
@Kolmiel: Ok, I'm back. how would you like this to be input? Do most irregular comparatives have analytic counterparts? I can think of several ways of implementing this behavior but don't know which if best. One would be to have all extra usage of |comp= appear along with the analytic comparative unless the analytic one were explicitly turned off (with something like |comp-irreg-only=). Or we could have something like |comp=m represent the analytic comparative, similarly to what has been done with |1=s in {{en-noun}}. What do you think? —JohnC5 17:27, 5 June 2016 (UTC)
@JohnC5: Most adjectives have only the analytic form. Just three (good, much, little) have only the irregular form. A certain number (10, 20, 30?) have both forms. -- Maybe your first idea would be then best then? Kolmiel (talk) 18:29, 5 June 2016 (UTC)
@Kolmiel: I'll work on that. Also is there a rule that predicts when the superlative takes -schten vs. -sten vs. -ten? —JohnC5 18:45, 5 June 2016 (UTC)
@Kolmiel: I've made some updates. —JohnC5 19:16, 5 June 2016 (UTC)
@JohnC5: Yes, good. Thanks again. But preferably the analytic form should be given before the irregular one since the analytic one tends to be the actual comparative (more than someone else) while the irregular one has a less literal sense (e.g. more than average). — -schten is not an ending of the regular superlative. It only occurs in bescht ("best") and meescht ("most"). Kolmiel (talk) 18:29, 5 June 2016 (UTC)
@Kolmiel: I've reversed the comparatives. As for -ten, it seems like this is added to adjectives ending in -s (groussgroussten). Are there any other examples? Also, what is the general rule for generating the masculine and the neuter (stem + -en and stem + -t)? I'd like to get this as streamlined as possible. —JohnC5 23:47, 5 June 2016 (UTC)
@JohnC5: Sure. The superlative of "grouss" is "am gréissten" with an umlaut. Such forms and some others must definitely be added manually. Otherwise it's -sten, but -ten after -s, -x, -z. (Btw, can we do alternative superlatives? That should be possible too. [Actually all forms should allow alternatives to be safe, I think.]) The regular masculine is stem + -en. The regular neuter is stem + -t, but unchanged after -d, -t. Kolmiel (talk) 18:29, 5 June 2016 (UTC)
@Kolmiel: Yeah, I should have guessed grouss would be a bad example. I've already written the module to accept alternatives for all parameters except the headword itself (I can add alternative headwords if you think it will be useful). I noticed when reading the code for {{lb-decl-adj}} that adjectives ending in -f have a -w- alternation and those ending in -e take -ën in the masculine. I'll probably encode this, but are there any other such rules? —JohnC5 02:47, 6 June 2016 (UTC)
@JohnC5: There are other alternations, but no rules that I'm aware of. Also f/w is not a rule; it depends on the etymology. I think it shouldn't be included in the code. In what words have you seen the trema? I think it's just after -ee. Where your words with -ee? — Does "headword" mean the lemma, i.e. the basic form? In that case, no, I don't think we need alternatives for these. Kolmiel (talk) 03:18, 6 June 2016 (UTC)
@Kolmiel: Yeah, I guess the rule is for -ee. Does it always hold for -ee? If so, I'll just keep that one. Otherwise, I think it may be done. —JohnC5 03:23, 6 June 2016 (UTC)
@JohnC5: Yeah, for -ee it's right. Kolmiel (talk) 03:18, 6 June 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Kolmiel: Ok, I think these are ready for usage. As I said, it's gonna cause a lot of errors. Shall we begin changing them over? I suggest doing {{lb-noun}} and {{lb-proper noun}} first. —JohnC5 03:32, 6 June 2016 (UTC)

@Kolmiel, Chuck Entz: I've changed {{lb-noun}} and {{lb-adj}} over. CAT:E has ~200 broken adjectives. I've fixed a bunch already but am unsure which have irregular comparatives and superlatives. Kolmiel, if you could check all the adjectives with irregular forms (whether they have errors or not), then we can continue fixing the template errors (this usually involves deleting all the parameters and using the auto-generated forms). Sorry to dump this work on you. —JohnC5 05:32, 6 June 2016 (UTC)
@JohnC5: I've checked the category. Those in it now should all regularly work with the template. The others I've changed manually. The template works very well, but because of the complicated spelling rules and the irregular superlatives I'd like to check those which you already did. Is there a list? (I spotted and corrected mistakes in kuerz and I think one other word. So there might be a few more.) And there's one thing we've forgotten: predicative-only adjectives (for which masculine and neuter don't exist and don't apply). Can we still add that? Otherwise we'd have to use {head|lb|adjective} for these. They are not very many.
PS: So far I've come across 6 adjectives with two comparatives. So they may be fewer than I'd thought, just 10 or 15 probably. And it was good that we left the feminine as a non-obligatory form. I had to use it once on futti. (I didn't think it existed, but okay, we're good.) Kolmiel (talk) 17:03, 6 June 2016 (UTC)
@Kolmiel: I'd say check my recent history. They should all be in there. I can add |pred-only= which will remove all gendered forms. I also noticed the spelling that [aiou] followed by a single consonant or nothing represent a long vowel that must be must be separately marked if a word ends in multiple consonants (kalkaalt & kaalsten). I could probably add functionality to generate the odd neuters and superlatives if you think it is useful. —JohnC5 17:12, 6 June 2016 (UTC)
@JohnC5: Yes, amazing how you figured out this rule, which many Luxembourgish people can't remember even when they're taught it :) I thought about it too. The rule affects the neuter and superlative of adjectives with a, i, o, u not preceded by another vowel and followed by a word-final single consonant. And it affects the superlative only of adjectives with a word-final a, i, o, u not preceded by another vowel. -- I thought this would be very difficult to encode, but if you can do it and want to it, it would be quite useful I think. Kolmiel (talk) 17:24, 6 June 2016 (UTC)
@Kolmiel: I've made the changes for predicate-only adjectives and for lengthening. Could you check out fit to see if its superlative is correct? Also, could you give me an example of a predicate-only adjective? And should it be predicate(-)only, predicative(-)only? —JohnC5 20:23, 6 June 2016 (UTC)
PS: May I suggest just running through everything in cat:Luxembourgish adjectives to make sure they have the correct irregular forms? Some of them may have had no parameters specified previously, which would cause them not to have errors, but would still be generating regular, potentially incorrect forms. —JohnC5 20:46, 6 June 2016 (UTC)
@JohnC5: Great! Seems to work fine. Yeah, fit has "am fitsten", but it needn't bother us. If it were an originally Luxembourgish word it would have to be spelt "fitt". I fixed it. -- I can't think of a predicate-only adjective right now. Sorry. But I'm sure they exist. I s'pose "predicate-only" is fine. (In the end it doesn't matter, but this has two letters less.) Okay, yeah. I'll go through the list, but it's gonna be a couple of days before I can. Kolmiel (talk) 17:24, 6 June 2016 (UTC)
@Kolmiel: Any news here? We still need to do the verbs. —JohnC5 18:04, 13 June 2016 (UTC)
@JohnC5: No news so far. I haven't forgotten about checking the adjectives, but I haven't had the time. Maybe tonight or so. -- Yes. The verbs. Luxembourgish verbs generally have only a present conjugation and a past participle. Just over 20 verbs have a preterite and/or a subjunctive (= conditional tense). The principle parts would be past participle and perfect auxiliary + (as I proposed) the 3rd person singular present, which is irregular in ca. 70 verbs. The preterite and subjunctive would be non-obligatory items that we add when applicable. Kolmiel (talk) 13:56, 14 June 2016 (UTC)
PS: I've checked the adjectives from A to E now. Will do the rest some time soon, I hope. -- And I have a predicate-only adjective for you now: eleng. I wasn't able to use the right code though. Add it for me please and I'll see. Kolmiel (talk) 22:20, 14 June 2016 (UTC)
@Kolmiel: I'd already added it (|pred-only=). I really need to write some documentation. I've also added |subj= and |pred= to the lb-verb code; though that hasn't been added to the mainspace. You can still test it out at User:JohnC5/lb-sandbox. —JohnC5 00:35, 15 June 2016 (UTC)
@JohnC5: I'm done with the adjectives now. What should I do next? :) Kolmiel (talk) 17:01, 28 June 2016 (UTC)
@Kolmiel: —JohnC5 22:54, 28 June 2016 (UTC)
Great, and thanks for all your work! Next is the verbs, which is going to be interesting. If I change the {{lb-verb}} over to the code in mod:lb-headword, all of the lb verbs are going to be wrong or create errors. We can do it if you'd like, but we'll have to change them over fairly quickly, with which I won't be much help. The new template has two required params:
  • |1=: the 3rd singular present (further with |3s pres2=, ...),
  • |2=: the past participle (further with |pp2=, ...)
And several optional params:
  • |3=: auxiliary ("hunn", "sinn", "both") with "hunn" as default
  • |pret=: irregular preterite form (further with |pret2=, ...)
  • |sunj=: irregular subjunctives (further with |subj2=, ...)
I can change it over if you want to start fixing them, or I can create {{lb-verb-new}}, you move them from the old template to the new (with added information), then I go through and move lb-verb-new > lb-verb. What do you think? —JohnC5 22:53, 28 June 2016 (UTC)
@JohnC5: Yeah, it should be the latter. I'll work on it, but I won't be very quick, I think. -- Now I suppose we want to optimize the verb template like we did the adjective one: 1.) Verbs are given as infinitives, whence we get the (regular) stem by subtracting -en. The 3rd singular present takes -t and has the same spelling rules as the neuter adjective, with just one difference: Verbs with a stem in -d aren't left unchanged, but rather replace -d with -t (waarden > waart). 2.) The past participle is usually the same as the 3rd singular but with a prefix ge- (> gewaart). Sometimes ge- is missing, however. Maybe a shortcut for this. 3.) Finally, there are separable verbs. The Afrikaans verb template has a thing for this (cf. opskryf). For a Lux. verb "ofwaarden" it would mean that I enter a parametre sep=of or the like, and it would give me the forms "waart of" and "ofgewaart". (I.e. the separated syllable comes after the 3rd singular and the prefix ge- becomes an infix). Kolmiel (talk) 00:31, 30 June 2016 (UTC)
PS: A) The infinitive ending can also be -ën, so that should be deletable too. (Forms in -n(n) without -e occur only in a handful of verbs, all of which are irregular anyway, so this doesn't need to be considered.) B) Verbs with a stem in -dd make that -tt (bidden > bitt). C) Verbs with a stem in -w make that -ft (schreiwen > schreift). C) When the stem begins with e- or i- the prefix ge- becomes gë-. Kolmiel (talk) 00:46, 30 June 2016 (UTC)
@Kolmiel: I've made the appropriate changes. You may find the new template at {{lb-verb-new}}. So, you're going to change all the verbs over to this one, then I'll switch the code at {{lb-verb}} and use AWB to change the entries back to original template? —JohnC5 03:00, 30 June 2016 (UTC)

@CodeCat, Luxemburgish lemmas will be easier to manage using mod:lb-headword. --Lo Ximiendo (talk) 17:51, 30 May 2016 (UTC)

Support for etym-only languages in {{affix}}?[edit]

It's awesome that {{affix}} supports derivations from other languages; this happens all the time in Russian, for example, where foreign adjectives routinely get -ный ‎(-nyj) added to them to form a Russian adjective. But this template doesn't yet support etym-only languages; can this be added (maybe by @CodeCat)? See эквивале́нтный ‎(ekvivaléntnyj) for an example using Late Latin. Benwing2 (talk) 02:25, 27 May 2016 (UTC)

This would be easy to add, and I'm glad you like this feature, but it was added before we had templates/categories distinguishing inherited, borrowed and miscellaneously derived terms. The template doesn't currently distinguish these. I'm thinking, though, that the only cases where this feature would be used would be in borrowings. If it were used with an inherited term, then surely there would be no need for the language parameter, and I'm not sure when a miscellaneous derivation would be appropriate either. So would it be ok to automatically use the borrowing category? —CodeCat 12:31, 27 May 2016 (UTC)
I'm fine with this. I did use an inherited language in one case, see взрачный. This is probably a misuse of the {{affix}} template, though; presumably the word itself was constructed in Old East Slavic (or earlier) even if not attested. Benwing2 (talk) 05:39, 28 May 2016 (UTC)
In fact the source I took the etymology from, ruwikt, says this:
Др.-русск. образование от зракъ «вид, облик», заимствованное из ст.-слав.; восходит к праслав. *zьrěti и праиндоевр. ǵerh₂-.
which seems to indicate exactly what I just said. Benwing2 (talk) 05:40, 28 May 2016 (UTC)
It would be strange for a nonexisting word to be used in word formation, so I think this is a misuse. While the general intent is clear, it's not really accurate. Either the word survived into modern Russian and was used for the derivation before it fell out of use, or the derivation took place in Old East Slavic. Dating attestations would be the key. —CodeCat 16:13, 28 May 2016 (UTC)
I've added support for etymology-only languages. I also changed the categorisation to use "borrowed". —CodeCat 16:58, 30 May 2016 (UTC)
Thank you! Benwing2 (talk) 19:14, 30 May 2016 (UTC)

Different parsing in template?[edit]

In this template, the combined character ü̂ gets interpreted as uA, i.e. if you click sü̂, you get directed to suA. Can that be fixed? Korn [kʰũːɘ̃n] (talk) 14:05, 29 May 2016 (UTC) This seems to be true for all templates. Korn [kʰũːɘ̃n] (talk) 14:19, 29 May 2016 (UTC)

Use {{l|gml|su|sü̂}}. — Ungoliant (falai) 14:30, 29 May 2016 (UTC)
That's not possible everywhere, because the verb template is made out of switches. Korn [kʰũːɘ̃n] (talk) 16:03, 29 May 2016 (UTC)
This is because the entry_name parameter in the language data for gml has combining characters in the regexes, which actually need to be treated differently. I will fix this when I get a chance unless someone beats me to it. --WikiTiki89 16:39, 29 May 2016 (UTC)
I would much appreciate that, thank you. Korn [kʰũːɘ̃n] (talk) 19:10, 29 May 2016 (UTC)
Yes check.svg Done --WikiTiki89 01:13, 30 May 2016 (UTC)

sc= still needed?[edit]

Many templates accept a sc= parameter, a leftover from the days before automatic script detection. I'm wondering if this parameter is still needed? Are there still cases where overriding the script manually is necessary? —CodeCat 22:41, 29 May 2016 (UTC)

I don't know of any cases although theoretically I suppose it could happen with mixed scripts. Benwing2 (talk) 00:43, 30 May 2016 (UTC)
Min Nan can be written in Latn (Peh-oe-ji) or Hani. —suzukaze (tc) 01:31, 30 May 2016 (UTC)
But would script detection not be able to work that out? —CodeCat 01:32, 30 May 2016 (UTC)
I suppose script detection could figure it out.
This reminds me, sometime script detection seems to fail if there is enough template code (I suppose it's being detected as Latn); I remember having to use sc=Jpan at some point in the last few weeks, such as at 4649. —suzukaze (tc) 01:37, 30 May 2016 (UTC)
Would you give us several examples when it is detected as Latn when there is enough template code? I think it's easy to fix. --Z 09:37, 30 May 2016 (UTC)
There's also 圏点. I can't think of any more off the top of my head. —suzukaze (tc) 23:03, 30 May 2016 (UTC)
I note that Serbo-Croatian Cyrillic in some templates seems to display in a different font for me depending on the presence or absence of the sc=Cyrl parameter; I don’t know whether this is the intended behaviour. Same with Old Church Slavonic and sc=Cyrs. Old Novgorodian entirely fails to display Glagolitic without sc=Glag in Template:l, instead giving »Lua error in Module:Cyrs-Glag-translit at line 129: This module can only transliterate Old Cyrillic (Cyrs) and Glagolitic (Glag).« Vorziblix (talk) 02:57, 30 May 2016 (UTC)
Old Novgorodian doesn't have Glagolitic as one of its scripts, so it won't be detected. —CodeCat 13:05, 30 May 2016 (UTC)
Should it be added? We have a number of Old Novgorodian entries attested in Glagolitic (generally from Савва Михайлович, "22 Древнерусских глаголических надписи-граффити XI–XII веков из Новгорода"), but overall, most of the Novgorodian corpus is exclusively Cyrillic. We could just standardize on Cyrillic given the preponderance of Cyrillic sources and the effort needed to maintain duplicate entries. Or we could add Glag to Module:languages/datax if we want to strictly stay with the attestations. Vorziblix (talk) 19:38, 31 May 2016 (UTC)
Yes, every language should have a code added for every attested script, even if it's only used in quotations and there are not actual entries in the script. --WikiTiki89 19:41, 31 May 2016 (UTC)
Also, can you give an example where the sc=Cyrl makes a difference? —CodeCat 17:02, 30 May 2016 (UTC)
Any Serbo-Croatian inflection table does it; the version without sc=Cyrl displays using my browser-default serif font, while the version with sc=Cyrl displays with a particular sans-serif font that’s presumably set by Wiktionary (not any of my default fonts). Here’s one of each:
And here’s a screenshot of how it looks for me: [4]. It’s not particularly significant, though; either one is perfectly fine. Vorziblix (talk) 19:20, 31 May 2016 (UTC)
That template still uses really poorly written template code. It essentially doesn't wrap the text in any templates if the sc is Latn, and wraps it in {{lang|sh|sc=Cyrl}} if the sc is Cyrl. It should be fixed. --WikiTiki89 19:33, 31 May 2016 (UTC)
I've fixed it up now. The sc= parameter of that template is no longer used at all. —CodeCat 19:53, 31 May 2016 (UTC)
But there are still more SH templates that need to be fixed. And it's not simple either, because many of the forms have parenthesized parts that cannot just be linked haphazardly, for example adjectives often have things like новог(а). --WikiTiki89 19:57, 31 May 2016 (UTC)
What I would say is that even if there were no cases where this parameter is necessary, it should still be kept. You never know when you'll want to intentionally use the wrong script code for testing or for whatever reason. --WikiTiki89 19:33, 31 May 2016 (UTC)
But if you wanted to test something you could just manually wrap it in the appropriate class. DTLHS (talk) 19:56, 31 May 2016 (UTC)
The only thing I can think of is that certain languages (Frankish, Proto-Norse, Gothic) are attested in one script and reconstructed in a different one. —Aɴɢʀ (talk) 15:52, 14 June 2016 (UTC)


In Κυπριώτης it gives as transliteration "• ‎(Kypriótis)". Should't it give Kypriótes (e) or am I wrong (only for old grc)? Sobreira (talk) 13:01, 30 May 2016 (UTC)

It's i in modern Greek. —CodeCat 13:04, 30 May 2016 (UTC)

inh and VL.[edit]

Just noticed this. When using inh and VL., there are no longer any categories generated for Vulgar Latin at the bottom of a page, for example, with aguja. I don't know if I missed something in a policy discussion about this, but what happened? Was this changed because generally if a term comes from Vulgar Latin, it's assumed it's inherited? But it doesn't even show up as a derived from category. Are we just doing away with it altogether? Word dewd544 (talk) 22:51, 30 May 2016 (UTC)

It was a bug in Module:etymology, fixed now. —CodeCat 00:30, 31 May 2016 (UTC)
Oh, okay. Thanks! Word dewd544 (talk) 01:19, 31 May 2016 (UTC)

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: [5]. 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 [6]. 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)

@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)

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)
[7], 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)