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


April 2016


In my computer hiders do not operate - key "show" does not exists and I can't open them. Please, correct it. Sic dixi REX NIGER 10:27, 2 April 2016 (UTC)

Do you have JavaScript disabled? -Xbony2 (talk) 11:34, 2 April 2016 (UTC)
I don't know. How can I find it? Sic dixi REX NIGER 14:13, 2 April 2016 (UTC)
Check here. -Xbony2 (talk) 14:25, 2 April 2016 (UTC)
Yes, Javascript is enabled! Sic dixi REX NIGER 14:49, 2 April 2016 (UTC)
What "hiders" are broken? Like here? -Xbony2 (talk) 16:11, 2 April 2016 (UTC)
adjoining screenshot
Yes, like there and like here. Sic dixi REX NIGER 17:11, 2 April 2016 (UTC)
Clear the cache and cookies. I would tell you how if you were not using Yandex browser :D--Dixtosa (talk) 17:22, 2 April 2016 (UTC)
Thank you, it helps. Sic dixi REX NIGER 19:55, 2 April 2016 (UTC)
This issue happens to me sometimes, but reloading the page fixes it. One cause is if the javascript which hides the content loads, but then something happens to go wrong before the javascript which generates the "show" button loads. If javascript is not enabled at all, the content is not hidden in the first place. - -sche (discuss) 18:10, 2 April 2016 (UTC)
I tried to investigate it, but the Javascript here is so convoluted that I had no idea where the error might be coming from. It doesn't help that there is no reliable way to generate the error either. —CodeCat 12:58, 3 April 2016 (UTC)
In Chrome Developers Tools there is a timeline feature that the Mediawiki JS pages offer as useful for JS. This MW page has more. Actually using this stuff is way beyond my paygrade. DCDuring TALK 13:56, 3 April 2016 (UTC)

Borrowing template[edit]

Is there any way to make the {{|bor}} not show up as the capitalized word "Borrowing", as in Borrowing from French? Sometimes this makes it inconvenient when doing the etymology. Like if you have it later in the sentence as opposed to the beginning, or if you put a qualifier such as "probably" or "likely" before. It would be more flexible if it just worked the same way as the {{|inh}} and {{|der}} ones, and you manually typed out borrowed or borrowing or whatever.

Another related problem is, what about words that were borrowed simultaneously from multiple languages? Like Romanian, when undertaking its "re-Latinization" efforts in the 19th century, started borrowing mass quantities of words from French. It also, in many cases, borrowed from both French or Italian, or a mix of them (cf. banchet, for example). The official etymological dictionaries of Romanian in many cases list a word as having been taken/derived from French, Italian, and literary Latin, and in some cases German too. I suppose this is when it was uncertain which particular language it was primarily taken from. Even though French is the most often listed, they are often adapted to a more Romanian "style", and this can be closer to looking like Italian (although a few words are taken almost unchanged in pronunciation from French). Older variants of some words may have been taken from different languages, like Greek, as well. Anyway, my point is that it doesn't look good in the etymology section, for example in incendiu, to have Borrowing from French incendie and Borrowing from Italian incendio and Borrowing from Latin incendium. Word dewd544 (talk) 16:00, 2 April 2016 (UTC)

Use the arguments nocap=1 and notext=1. For example:
Ungoliant (falai) 16:17, 2 April 2016 (UTC)
There's been some discussion of removing the wording from the templates (so that they only generate the language name, like {{etyl}} does), making them more flexible. - -sche (discuss) 18:07, 2 April 2016 (UTC)
Should we pick up that discussion in earnest? —CodeCat 12:59, 3 April 2016 (UTC)
Being able to auto-generate "Borrowing" seems somewhat handy, but it does not seem handy enough to outweigh the hassle with nocap and notext arguments, at least in terms of accessibility for new editors. --Tropylium (talk) 16:15, 22 April 2016 (UTC)

Linking to entries that start with the character /[edit]

To avoid linking to a subpage, it is necessary to write [[:/ameeni]] to link to entries like /ameeni that begin with the character /. The same is true for linking templates like {{m}} and {{l}}, but I don't see why that should be the case. Now that we have entries in the standard orthography of the Iraqw language, which uses </> for /ʕ/, it would be very helpful for them to be more straightforward to link to. Could somebody please improve those templates to facilitate linking? Thanks! —Μετάknowledgediscuss/deeds 17:44, 2 April 2016 (UTC)

Would simply modifying {{l}} and {{m}} to generate links starting with : fix the issue? (I don't know.) - -sche (discuss) 18:05, 2 April 2016 (UTC)
It appears to work in the main namespace but not elsewhere: /ameeni, /ameeni DTLHS (talk) 18:16, 2 April 2016 (UTC)
I should've tested that. I still think it should work everywhere, though. —Μετάknowledgediscuss/deeds 18:43, 2 April 2016 (UTC)
I really wish writing system designers wouldn't use punctuation marks as letters. The ideal solution to this problem is for Unicode to create a separate code point for a MODIFIER LETTER SLASH and for us to use that instead, but that's probably too much to hope for, and even if it happened, we'd still have to do something to accommodate Iraqw in the meantime. —Aɴɢʀ (talk) 19:55, 2 April 2016 (UTC)
I've never come across a language that does this before, but there's also /b/tard in English (and quite possible more terms that we haven't documented yet). —Μετάknowledgediscuss/deeds 19:58, 2 April 2016 (UTC)

Russian Church Slavonic[edit]

Can someone create an etymology-only language for Russian Church Slavonic? I'm pretty sure it should be treated as a dialect of Old Church Slavonic (code cu). Not sure what code to use, maybe cu-ru? (Although most such codes seem to have 3 letters after the hyphen.) While we're at it, we might want similar entries for other Church Slavonic dialects; Wikipedia mentions three: Old Moscow, Croatian and Czech, but all of them in rather limited usage. Benwing2 (talk) 03:53, 3 April 2016 (UTC)

This is more of a Beer Parlour issue, since the real question is whether we want to have these. User:Ivan Štambuk probably has some opinions about it. --WikiTiki89 04:02, 3 April 2016 (UTC)
Church Slavonic has several recensions (separate sets of phonological rules). I think this would make it more complicated. --KoreanQuoter (talk) 04:58, 3 April 2016 (UTC)
I'm not sure why it would be more complicated. There are only about 4 recensions, and each of them is clearly distinct from Old Church Slavonic; they are similar to Medieval Latin vs. Classical Latin. Benwing2 (talk) 06:36, 3 April 2016 (UTC)
The differences are much greater, though. Lots of words are spelled differently. —CodeCat 12:55, 3 April 2016 (UTC)

Category:Plurals with a red link for singular[edit]

Would it be possible to split this category by Language? Or, at least, to split off the English entries? SemperBlotto (talk) 08:37, 3 April 2016 (UTC)

And limit the namespaces to main and reconstruction. {{plural of}} should not be included! Renard Migrant (talk) 12:11, 5 April 2016 (UTC)

{{lb|fro|Old Northern French}} should categorize[edit]

In Category:Old Northern French (not Category:Old Northern French Old French). And I no longer know how to do that. Renard Migrant (talk) 12:01, 5 April 2016 (UTC)

Trouble loading MediaWiki:Common.css[edit]

For a while now, I've had trouble loading MediaWiki:Common.css (i.e. the page itself, not its CSS on other pages). It seems that there is some JS that runs in an infinite loop when I load the page (but I'm not 100% sure). Does anyone else have this problem, or better yet, know how to fix it? --WikiTiki89 19:51, 5 April 2016 (UTC)

Sometimes instead of getting stuck, the whole page turns blank. --WikiTiki89 00:03, 6 April 2016 (UTC)
It loads perfectly fine when I'm not logged in, so it must be a bug either in my personal JS or in a gadget I have enabled. --WikiTiki89 15:03, 8 April 2016 (UTC)
Deleting my person JS and CSS did not fix the problem, so it must be a gadget I have enabled. --WikiTiki89 15:12, 8 April 2016 (UTC)
The culprit is the "Make wikilinks inside JavaScript, Lua and CSS comments clickable" gadget. --WikiTiki89 15:19, 8 April 2016 (UTC)
Thanks for resolving it and thanks for letting us know. DCDuring TALK 15:28, 8 April 2016 (UTC)
I didn't resolve it, all I did was identify the gadget in which the error is occurring. I disabled it for myself and hope that someone who is better at JavaScript will take a look at it. --WikiTiki89 17:11, 8 April 2016 (UTC)
  • I have investigated the case. It was partly due to OrangeLinks and partly "Make wikilinks ...." gadget. The latter made wiki style links in anchors' hrefs like this <a href="https://en.wiktionary.org/wiki/w:someWikipediaPage">[[w:someWikipediaPage]]</a>). But OrangeLinks gadget assumed href's contained 'normal' links (i.e. "https://en.wikipedia...."). That's reasonable because when parsed [[w:someWikipage]] is rendered as a 'normal' link. I corrected OrangeLinks so that now it skips external links. The corrected version is at its talk page.
You are welcome.--Dixtosa (talk) 18:23, 10 April 2016 (UTC)
Thanks! The strange thing is, though, that when I was trying to identify which gadget was causing the problem, I tried disabling orange links, but that alone didn't help. --WikiTiki89 14:42, 11 April 2016 (UTC)

Customizing CharInsert[edit]

I tried to use the instructions on the Wikipedia page on CharInsert to create a custom menu in my common.js, but it doesn't seem to work. Is this functionality not available on Wiktionary, or did I do something wrong? — Eru·tuon 22:01, 5 April 2016 (UTC)

You might find this useful.--Giorgi Eufshi (talk) 07:32, 6 April 2016 (UTC)
@Giorgi Eufshi: Hmm, thanks for the suggestion. Just tried it, but it doesn't work. Is it current or outdated? — Eru·tuon 02:45, 7 April 2016 (UTC)

{{nap-conj}} table formatting[edit]

No matter what I do, I can't get the text in the 3rd person imperfect subjunctive and imperative cells to center like the rest of the table. No idea why it's doing that in just those two spots. KarikaSlayer (talk) 00:53, 6 April 2016 (UTC)

Fixed: diff. --WikiTiki89 01:13, 6 April 2016 (UTC)

Sorting in Module:columns[edit]

Template:rel3 and Template:der3 don't seem to correctly sort Greek words. If you look at the lists in the Derived and Related forms of πείθω ‎(peíthō), ἄπειστος ‎(ápeistos) and ἀνᾰπείθω ‎(anapeíthō) should be at the top of their respective lists, but they're somewhere in the middle of the first column. The rest of the words are in seemingly random positions, even though the words are alphabetized in the source code. I don't know much about module coding, but I guess Module:columns is implementing some bizarre kind of sorting, which undoes the sorting of the parameters input into the template. Adding |sort=0 fixes it, but could the module be fixed so that sorting actually alphabetizes? — Eru·tuon 02:54, 7 April 2016 (UTC)

I set it to use the sort key as defined in the languages module. Does it produce the correct sorting now? DTLHS (talk) 03:14, 7 April 2016 (UTC)
Wow! Quick response. For the most part, yes. It's having trouble with letters with breves ‎(a), though, which are ordinarily removed when creating links. πᾰρᾰπείθω ‎(parapeíthō) is alphabetized after προπείθω ‎(propeíthō), when it should be before πειθαναλογία ‎(peithanalogía), as if it were written παραπείθω ‎(parapeíthō) (which would be the entry name if there were an entry). Perhaps the words could be put through the entry-name determining apparatus, to remove breves and macrons, before they are sorted? — Eru·tuon 03:26, 7 April 2016 (UTC)
OK, added that as well. DTLHS (talk) 03:30, 7 April 2016 (UTC)
Great! Looks right now. Thanks a ton! — Eru·tuon 03:33, 7 April 2016 (UTC)

Replace table markup with {{der4}}[edit]

There are 211 Swedish entries with table markup in the sections “Derived terms”, “Related terms” and “Synonyms”. I propose replacing it with {{der4}}, {{rel4}} and {{syn4}}. It could be another option with fewer ({{der2}}, {{der3}}) or more ({{der5}} columns. I just guess the four column template is a good choice. Editors should never have to choose the number of columns anyway. The template should do it automatically based on user preference and number of list items.

I also propose changing “Related terms” to “Derived terms” when appropriate, since a lot of Swedish entries have derived terms incorrectly labeled as related terms.

For examples of what I have already started, see: kvinna, pojke, silver, symbol, musik

I have put all code on a single line since the template fails when adding newlines between arguments, unless wrapping arguments in another template. I do not think it really matters, so I will keep making it a single line unless there is a good reason not to.

I have a bot that can change all entries. Any comments before I proceed? Do I need to register a bot account for this?

Chokladkaka (talk) 02:27, 8 April 2016 (UTC)


This Russian adjective is in a category "plural only adjectives". I think this needs to be "Russian plural only adjectives" or something similar. SemperBlotto (talk) 10:28, 8 April 2016 (UTC)

special:diff/37981044--Giorgi Eufshi (talk) 10:42, 8 April 2016 (UTC)

Proposal of templates automatically choosing the number of columns[edit]

Templates for listing derived terms and related terms are now a mess, because the number of columns to display has to be specified manually when using them. I propose to introduce the following two templates that automatically select an appropriate presentation instead of requiring it to be specifying manually when using them. The current implementation automatically selects a number of columns to display based on the number of items in the list. If we ever want to change the presentation or the algorithm for selecting the number of columns, we can simply modify Module:term list, and we will not have to change thousands of pages using the templates.

Usage example code:

{{derived terms|lang=de
| Golfkrieg
| Golfkrise
| Golfmonarchie
| Golfregion
| Golfstrom

More examples at User:Chokladkaka/Sandbox.

I would like to get feedback on anything that needs to be changed, and then ask for approval to begin to use these templates.

Chokladkaka (talk) 20:19, 8 April 2016 (UTC)

Support, though the language parameter should be parameter 1, not lang=. But why do we even need two templates? Is a column of derived terms any different from a column of related terms? Also, we should do the same with translations, but fixed at 2 columns. So that we no longer need to manually balance them? —CodeCat 20:22, 8 April 2016 (UTC)
I just went with lang because that is how the currently used templates work. It could easily be changed to 1. The reason we have two templates is that they have a different text in the headline to click to expand/collapse the box. I see no real point in that though. The headline could just say Show/Hide and nothing else. Chokladkaka (talk) 20:42, 8 April 2016 (UTC)
The column count should really depend on the screen size, rather than the number of words. That maybe can be done with CSS, which would be preferable to being done by a module. Anyway, I will oppose any term list template that takes the terms as parameters rather than just surrounding the terms. Thus, I think the {{col-top}} and {{col-bottom}} templates should be used (or a collapsible version of them). --WikiTiki89 20:27, 8 April 2016 (UTC)
That is why I emphasize that the implementation can be changed at any time. I made it count the items simply because that is the easiest thing I could come up with for now. None of this is possible with templates that surround the terms. If we have a top and bottom template, then the editor must select the number of columns manually and use the top2, top3 or top4 template, and must count the items and insert mid2, mid3 and mid4 templates at precisely the right positions. Chokladkaka (talk) 20:42, 8 April 2016 (UTC)
@Chokladkaka: On the contrary, if you look at {{col-top}} and {{col-bottom}}, you will see that they are auto-balancing and work without any kind of {{col-mid}} template. --WikiTiki89 22:28, 8 April 2016 (UTC)
@Wikitiki89: I just noticed that. {{col-top}} and {{col-bottom}} are auto-balancing, because they use CSS columns instead of HTML columns, but they do not automatically select how many columns to display, and whether to display columns at all. Chokladkaka (talk) 08:01, 9 April 2016 (UTC)
If there aren't enough words in the list to require columns, then there doesn't need to be a template at all. The number of columns cannot be decided by a module anyway, and if we decide to use CSS or JS for that, they would work fine with template pairs like this. --WikiTiki89 15:44, 11 April 2016 (UTC)
What value does this add? It will complicate editing and consume resources, the "value" that we can change how many columns are displayed is not particularly important to me. I (obviously) am a huge proponent of derived and related sections being contained within templates, I am not sure this treatment is the best method. If there were similar gadgets applied to this as are applied to the translation sections I might be OK with it. - TheDaveRoss 20:29, 8 April 2016 (UTC)
1. It removes the need for editors to count the list items and select between rel2, rel3, rel4 and rel5. 2. It allows changing the implementation to take screen size into consideration. Chokladkaka (talk) 20:42, 8 April 2016 (UTC)

Support and comment: I like the idea of consolidating {{der3}} and {{rel3}} and their compatriots. Like @CodeCat, I also don't see any need for two separate templates for Derived and Related terms, unless they are differentiated in some way.

However, perhaps the number of columns should also be based on the length of the words and the size of the user's screen (or more specifically the size of the bodyContent area). If there are a lot of words, but some of them are very long, then there should be fewer columns to accommodate this. And if the user is on a smartphone, or happens to be using less of their screen, it would be nice if there were fewer or no columns. If the module decides to use four or five columns, but the words are long, or the content area is narrow, then the text box will display with a scroll bar, which is sub-optimal. However, I'm not much of a programmer, and don't know how easy or costly it would be to implement these features.

Another thing to be fixed: {{der3}} displays the Greek word in italics in the header. Instead it (or its successor) should display it the way {{m}} would display the term. — Eru·tuon 22:16, 8 April 2016 (UTC)

Hmm, another idea: perhaps the template could also decide whether to create a collapsible box at all, based on the number of entries. Then a Derived forms section with just a few entries would display without a box, but if there are more than a certain number of entries, the box will appear. That would also remove the necessity of deciding whether to put Derived or Related terms in a bulleted list or to use a column template: you just always use the template.

However, using a bulleted list has a benefit: you can provide glosses and genders or create a tree showing derivation. — Eru·tuon 22:22, 8 April 2016 (UTC)

For this last reason I think the people above are right, the template should accept the entire list as one parameter, rather than each one separately. As for deciding the number of columns, that should really be done client-side, because server-side Lua modules can't determine how wide text will be. —CodeCat 22:40, 8 April 2016 (UTC)
@CodeCat: Why would the list have to be one parameter? See the example code I added above and at User:Chokladkaka/Sandbox. It looks just like a list, except you start each line with “|” instead of “*”. – Chokladkaka (talk) 08:37, 9 April 2016 (UTC)
To repeat what @CodeCat and I said above, the reason is so that you can present a tree of derived forms or classify them in some way, and perhaps provide translations for each term. You can't do that when each word is a parameter. I just did this at φαίνω. — Eru·tuon 02:06, 13 April 2016 (UTC)
@Erutuon: Use {{l}} if you need a translation, whether it is inside a parameter or not. Making a parameter of list items just improves processing and does not hinder. – Chokladkaka (talk) 07:09, 14 April 2016 (UTC)
@Chokladkaka: I'll try that, I guess. Still, no way to do derivational trees. — Eru·tuon 07:17, 14 April 2016 (UTC)
@Erutuon: I'm not familiar with how derivational trees are formatted. Could you please give me links to a couple of examples? – Chokladkaka (talk) 07:23, 14 April 2016 (UTC)
@Chokladkaka: Well, here's the portion from φαίνω ‎(phaínō) that I was referring to. To be honest, I might be the first person to use derivational trees in Derived terms sections, and not sure if it's an acceptable practice (though I think it makes the list easier to understand). But basically, terms are bulleted and terms that derive from another term are indented one more than that term. — Eru·tuon 07:34, 14 April 2016 (UTC)
@Erutuon: I like the idea of using derivational trees. I think more entries could use them if there were just a standard way to do it. I think the proper way to do it is to use nested templates (instead of nested lists). That way we can specify in a machine readable way how the branches of the tree are related to the trunk of the tree. It would require some discussion though to come up with the format. – Chokladkaka (talk) 07:53, 14 April 2016 (UTC)
@Erutuon: I change my mind about nested templates. I think it would be better to make it more human readable by simply having one template, giving it all related terms as separate arguments, and prefixing entries with * just like when making a list, to indicate that they belong to a deeper level of the tree. A top level term would then start with | and nested entries would start with |*, |** and so on. It's like an ordinary list, and the difference is just that the first * is replaced by |. – Chokladkaka (talk) 09:42, 14 April 2016 (UTC)
@Erutuon: Now I'm unsure about having trees in related terms. I just made a tree of hyponyms for Gebäck ‎(pastry). It's quite daunting to see. Maybe it would be better to remove all indirect hyponyms and just have a flat list of direct hyponyms. – Chokladkaka (talk) 13:56, 14 April 2016 (UTC)
@Chokladkaka: Yeah, the list there is pretty hard to read. I think the hyponyms could be limited to a couple levels of derivation, or alternatively only the most common ones could be listed. That's what I did at φαίνω ‎(phaínō) with the derivatives of the combining form -φανής ‎(-phanḗs), most of which are pretty uncommon.
Adding asterisks to {{der3}} doesn't seem to work: it just displays asterisks, and doesn't create a nested list. — Eru·tuon 00:45, 15 April 2016 (UTC)
@Erutuon: {{der3}} is the old template I want to get rid of. The new template I propose supports adding one asterisk. See User:Chokladkaka/Sandbox#Example_with_nested_items. – Chokladkaka (talk) 05:24, 15 April 2016 (UTC)
Aha, there we go. That's better, though could you make a way to create a bullet point with plain text, no link (so that the textwith prepositional prefixes and suffixed can be used to categorize the list items)? — Eru·tuon 00:55, 16 April 2016 (UTC)
I agree that the template should also decide automatically whether to create a collapsible box at all. The purpose of the template is precisely to eliminate decisions and guesswork by the editor of each page and introduce the possibility to consider the preference of the user viewing the page. Right now I avoid editing lists of related terms, because I do not know when to make a list, when to use a template instead and which template to use. Chokladkaka (talk) 08:01, 9 April 2016 (UTC)
I just changed the module to make the box collapsible only when there are more than 8 list items. I put some usage examples above and at User:Chokladkaka/Sandbox. – Chokladkaka (talk) 08:37, 9 April 2016 (UTC)
Symbol support vote.svg Support --Giorgi Eufshi (talk) 07:28, 14 April 2016 (UTC)

Re: Red "D" delete button no longer works in recent changes[edit]

This issue was pointed out almost a year ago, and is still the case: [1]. Can we just hide the red "D" at this point? I don't know where to find the code, or I could probably manage it myself. Equinox 06:40, 9 April 2016 (UTC)

Well, I found the code: MediaWiki:Gadget-PatrollingEnhancements.js. I have commented out the part that adds the D button. I notice no difference; perhaps some kind of cache purge is required? Equinox 21:38, 21 April 2016 (UTC)
Strange, I no longer see the D button, but I still see the deletion reason box at the bottom right, even though I commented out that part after you. --WikiTiki89 21:51, 21 April 2016 (UTC)
And I don't see it anymore. Maybe it just takes a while to kick in (although I don't know why that should be the case). --WikiTiki89 21:54, 21 April 2016 (UTC)

Bug in per-browser preferences[edit]

I turned off per-browser preferences a while ago because some of the gadgets were buggy, but they keep turning back on, and I keep on having to go back to the page again to turn them off. I'm always using the same browser (Chrome) on the same computer. Is there a way to keep them from turning on? It's really annoying. — Eru·tuon 19:25, 9 April 2016 (UTC)

@Yair rand: Did you break something? --WikiTiki89 14:41, 11 April 2016 (UTC)

I untick the box that says "Replace text in deletion log comment" and it lasts for about a minute then reverts to the way it was - annoying. Can anything be done? SemperBlotto (talk) 08:00, 12 April 2016 (UTC)

Is this perhaps related to the bug User:Erutuon reported above? —CodeCat 13:38, 12 April 2016 (UTC)
And is it related to WT:Grease pit/2016/March#WT:PREFS cookies? Chuck Entz (talk) 13:51, 12 April 2016 (UTC)
I don't understand exactly what broke it, but I've reverted my recent changes to the PREFS script. Is the issue fixed now? --Yair rand (talk) 15:43, 12 April 2016 (UTC)
Nope. SemperBlotto (talk) 08:12, 13 April 2016 (UTC)
It's acting stranger now. The preferences are working (and turned off) when I'm on my watchlist, but not working (and on) when I'm editing this page. — Eru·tuon 08:35, 13 April 2016 (UTC)

fr-conj-auto failure on nourrir and other -rir[edit]

Complaint in tea room: Wiktionary:Tea room#French nourrir

Apparently fr-conj-auto puts nourrir in the labiodental + -rir group instead of the second group -ir verbs (where it's supposed to go) for some extremely odd reason. Mglovesfunbot put in fr-conj-auto recently... Hillcrest98 (talk) 02:29, 10 April 2016 (UTC)

It's even worse - all miscellaneous -rir verbs are thrown into the ouvrir group for absolutely no rhyme or reason; they all should be second-group. Hillcrest98 (talk) 18:29, 11 April 2016 (UTC)

Problems in charinsert MediaWiki extension[edit]

I finally got around to looking further into some of the edittools annoyances. In the process, I tracked down the likely cause of the problem I ran into some months ago, where &13; newlines in <charinsert> sections suddenly became � (Unicode character &#xfffd;) -- the underlying cause seems to be an update in the charinsert MW extension.

The documentation still says to use &#13; to insert newlines, but this is clearly non-functional.

I tried using &#10; instead, but charinsert doesn't seem to support this fully -- it will insert, but <nowiki> does not suppress autoindentation and numbering or bullets when using # and * in charinsert strings. For example:


renders as:


  1. other text

The <nowiki> tags should suppress the linebreak and numbering, but it's clearly not working correctly.

An alternative possibility is that something changed in how MediaWiki renders?


  1. Who do I talk to to find out if the cause is in charinsert or in MW rendering?
  2. Where would I look for past related bugs?
  3. Where would I file a bug report for this?

TIA, ‑‑ Eiríkr Útlendi │Tala við mig 05:47, 10 April 2016 (UTC)

"Where would I file a bug report for this?" Maybe Phabricator. —suzukaze (tc) 03:40, 11 April 2016 (UTC)

Old Hindi[edit]

Can Old Hindi be made into a full fledged mainspace language with code ohi (not taken by any other language so far)? See WT:Beer Parlour#Old Hindi for discussion. —Aryamanarora (मुझसे बात करो) 15:23, 10 April 2016 (UTC)

As discussed before, we don't assign codes that ISO could potentially assign. It'll have to be inc-ohi. —Μετάknowledgediscuss/deeds 17:23, 10 April 2016 (UTC)
Also, before it's added: what translit module should it use? —Μετάknowledgediscuss/deeds 17:27, 10 April 2016 (UTC)
MOD:sa-translit, please. Script is Deva, of course. —Aryamanarora (मुझसे बात करो) 19:29, 10 April 2016 (UTC)

Inherited terms using findetym[edit]

@Yair rand, CodeCat and anyone else with the technical know-how: is it possible to edit {{findetym}} or the modules it invokes so that it will categorize into "inherited from" categories rather than (or in addition to) "derived from" categories? —Aɴɢʀ (talk) 20:02, 10 April 2016 (UTC)

The module uses the {{etyl}} template. Is a different template supposed to be used for inherited terms? If so, should it always use it? --Yair rand (talk) 20:44, 10 April 2016 (UTC)
Direct inheritances are now supposed to use {{inh}}, which categorizes as Angr mentioned. Benwing2 (talk) 00:42, 11 April 2016 (UTC)

ha-verb as inspired by lv-noun[edit]

In my sandbox, I based {{ha-verb}} loosely on {{lv-noun}}. (Hausa verbs are categorized by grades; the asterisk is for irregular grade verbs and rare grade verbs.) If anyone would like to give me some assistance, that's good. --Lo Ximiendo (talk) 23:27, 12 April 2016 (UTC)

Editable title[edit]

I don't know about you but I often find myself copying the title of a page to the search bar changing a little thing (a typo often times) and searching again. So, just in case you face the same issue often and want to ease your life add this to your common.js

$(function() {
	$("#firstHeading").prop("contenteditable", "true");
	$('#firstHeading').keypress(function (e) {
		var key = e.which;
		if(key == 13) {
			window.location = "https://en.wiktionary.org/w/index.php?search=" + $('#firstHeading').text() + "&title=Special%3ASearch&go=Go";
			return false;

The script makes entry's title area editable. Hit enter to search the modified title. --Dixtosa (talk) 18:38, 15 April 2016 (UTC)

You just made me so happy!!!! --WikiTiki89 18:41, 15 April 2016 (UTC)
Swell. - TheDaveRoss 18:54, 15 April 2016 (UTC)
One thing though: You should have it fetch the actual title of the page when you first click on it, because in some cases it's not the same as what is displayed. I found two different examples of this so far: At Special:Watchlist, the displayed title is just "Watchlist". When editing a page or viewing a diff, extra text is added to the title. --WikiTiki89 19:47, 15 April 2016 (UTC)
And it would also be nice if it could load search suggestions. --WikiTiki89 19:59, 15 April 2016 (UTC)
Then copying the title directly to the search box would make more sense for you. This is what you want
$(function() {
--Dixtosa (talk) 20:14, 15 April 2016 (UTC)
Yeah I guess. But it's not as cool as editing the title. --WikiTiki89 20:36, 15 April 2016 (UTC)
Ooh, really nice! I do that a lot too. Thanks so much! — Eru·tuon 20:15, 15 April 2016 (UTC)

WebRef bookmarklet and RefTag citation tools?[edit]

Hello! I'm wondering if there is a Wiktionary version of two tools that are useful for contributing citations to citation tabs.

The Wikipedia-formatted versions are:

  1. WebRef bookmarklet https://en.wikipedia.org/wiki/User:V111P/js/WebRef - you install the code snippet as a bookmark in your browser, surf to the webpage you want to cite, highlight the quote you want to cite, and click the bookmarklet. It pops up a textedit panel that has the wikicode for the citation. I'm looking for something similar where the wikicode is in the style of a Wikitionary Citations:for_some_word page.
  2. Google books tool http://reftag.appspot.com/ - you take the Google book URL of the book you want to cite and it builds the citation wikitext for you in the form of quote book template. Example:

Given a Google books URL like: http://books.google.com/books?id=ZagUswEACAAJ ...the tool would give: *{{quote-book |year=2016 |author=Dan Lyons |title=Disrupted: My Misadventure in the Start-Up Bubble |url=http://books.google.com/books?id=ZagUswEACAAJ |isbn=9780316306089 |page= |publisher=Hachette Books |passage= }}

Thanks! SageGreenRider (talk) 11:37, 16 April 2016 (UTC)

The Quiet Quentin gadget can do something kindof similar to #2. —suzukaze (tc) 11:39, 16 April 2016 (UTC)
Thanks! That's helpful. Is there a way to make it output structured data in the {{quote-book}} template rather than a single, flatten text string?


It froze. --Romanophile (contributions) 15:10, 19 April 2016 (UTC)

Was just about to say the same thing. --WikiTiki89 15:10, 19 April 2016 (UTC)
Jolly. Notice how largo a isn’t anywhere to be seen. --Romanophile (contributions) 15:11, 19 April 2016 (UTC)
Basically any edit after the database was unlocked and before 15:10 UTC isn't showing up there (the database was locked at 14:01 I presume and unlocked sometime between 14:47 and 14:51). --WikiTiki89 15:18, 19 April 2016 (UTC)

Indicating two third-person singular simple present forms using "en-verb"[edit]

The word sgraffito has two possible third-person singular simple present forms: sgraffitoes and sgraffitos. Is it possible to indicate this using {{en-verb}}? There's nothing in the documentation about this. — SMUconlaw (talk) 15:58, 19 April 2016 (UTC)

The documentation is pretty badly out of date, but it's in part because a change was cut short by other editors half way through and it was just left hanging. To specify a second present form, use pres_3sg2=. —CodeCat 16:21, 19 April 2016 (UTC)
Thanks. Hope the documentation can be updated soon! Because the template uses Lua (which I have no clue about), there's no way to figure out what the parameters are by looking at the wikitext source. — SMUconlaw (talk) 16:54, 19 April 2016 (UTC)


For some reason (page caching?), this isn't linking to Maastrichtian like it should be, even though the relevant code is in Module:labels/data/subvarieties. KarikaSlayer (talk) 19:05, 19 April 2016 (UTC)

Module:labels/data/subvarieties is not called upon by anything. I've moved the Maastrichtian label and protected that page against further additions. - -sche (discuss) 19:22, 19 April 2016 (UTC)

Unicode character \u200e[edit]

I have been finding this character randomly included in dates and quotations on various pages. Does anyone know where it is coming from? Does it serve any useful purpose on this wiki or can I just replace them all? - TheDaveRoss 15:28, 20 April 2016 (UTC)

  • Is it a left-to-right mark?SemperBlotto (talk) 15:31, 20 April 2016 (UTC)
    That is the character, as far as I know. An example is gouda, |date=‎Apr 8, 2009| becomes \u007c\u0064\u0061\u0074\u0065\u003d\u200e\u0041\u0070\u0072 \u0038\u002c \u0032\u0030\u0030\u0039\u007c when converted to unicode codepoints. I combined the date and year parameters and that extraneous character causes a parser error. - TheDaveRoss 15:35, 20 April 2016 (UTC)
Looking at the page histories, do the additions have anything in common? (For example, could they be the citations listed automatically by User:Walled gardener and then manually added to entries by users?) Equinox 16:52, 20 April 2016 (UTC)
I would say that it's totally unnecessary in any text that doesn't include both a right-to-left script such as Arabic/Persian/Urdu or Hebrew/Aramaic and a left-to-right script. If the text contains both types of scripts, it's only needed where both are present next to each other. It has no reason whatsoever to be in entry names, as far as I can tell (perhaps if there were an entry name with mixed scripts, but I don't think we've ever done that), and there's no need for it in the context you mentioned
If there were mixed scripts in a document, I can see how word-processing software might add this character to everything, just to be on the safe side: for most uses, it does no harm, since it's invisible, but it could prevent all kinds of text-order weirdness if left-to-right and right-to-left scripts happen to end up on the same line. If text were copypasted from such a document, this character would be included. Chuck Entz (talk) 01:21, 21 April 2016 (UTC)
We encountered some other problems caused by stray left-to-right and right-to-left marks last year, and I proposed removing them all (or most of them) by bot or AWB. They also cause display problems. Here are old lists of pages containing them: Wiktionary:Todo/Pages containing LTR marks, Wiktionary:Todo/Pages containing RTL marks. They can safely be removed from most contexts, as Chuck says. PS another character which randomly, inappropriately shows up and should be checked for and removed (especially from page titles!) is the soft hyphen. - -sche (discuss) 04:42, 21 April 2016 (UTC)
This character is included in the timestamps on history pages (by the framework itself, I think, for whatever reason). When these timestamps are copy-and-pasted, it goes along with them. --WikiTiki89 15:51, 21 April 2016 (UTC)

Unsupported titles in MediaWiki:Common.js[edit]

Instead of maintaining the map at MediaWiki:Common.js, why not create a simple template placed at the top of each unsupported title entry that will tell the JS what to replace the title with. --WikiTiki89 21:27, 21 April 2016 (UTC)

Because (1) it is nice to have all unsupported titles and real titles together at one place; and (2) with this way we can also replace titles on the history pages; and (3) it works? --Dixtosa (talk) 19:10, 25 April 2016 (UTC)
(1) Why? (2) Good point. (3) But it requires editing MediaWiki:Common.js every time a new unsupported title is created, while MediaWiki:Common.js should really be modified as rarely as possible. Can we at least move the list to something like MediaWiki:UnsupportedTitles.js? That would solve half of my problem with it. --WikiTiki89 19:22, 25 April 2016 (UTC)

Wikimedia Individual Engagement grant: A graphical and interactive etymology dictionary based on Wiktionary[edit]

I have submitted an IEG proposal and need your feedback. This is the link to the grant proposal, and this is the demo of the visualization. The aim of the project is to visualize the etymological tree of words using data from Wiktionary and an interactive tool. If you think the project is interesting and feasible, and or if you feel you would like to volunteer, please post at the end of the new grant page here.

The interactive web page uses d3.js - a JavaScript library for manipulating documents based on data - where you search a word and then you visualize the etymological tree of the word (ancestors, cognates, on the same tree). Right now I have only developed a demo for 10 words (the graphical interface needs some polishing still) and I am developing a java code based on dbnary to extract etymological relationships from Wiktionary.

More precisely, for interested users only, the output of the java extractor is an rdf file (a sample is available here) that I will query to identify etymological trees. Once I have extracted etymological trees, I plan on writing a JSON file of the tree that I will feed to the javascript code that uses d3.js to create an interactive web page. I am discussing with the Multimedia team what is the best way to integrate this into Wikimedia and they suggested two alternatives: either making this a parser extension (i.e. you type <etygraph> and then a bunch of JSON data, and then </etygraph>, which creates the graph) or a parallel namespace which will simplify the data storage part.

A screenshot of the etymological tree of the English word 'butter' as produced by 'etytree'

Please contribute to the grant proposal with a comment if you think it is interesting. -- Epantaleo

Lua frame arguments[edit]

Something seems to be broken.

The first line is a module which sets an additional frame argument 'form', then reads the frame arguments out into a string.

The second line is another module which manually creates a table 'args', setting the same values to the same keys.

In both cases args['form'] works correctly, but only in the second case does the pairs() function seem to recognize that the value 'form' has been set.

What am I missing? —ObsequiousNewt (εἴρηκα|πεποίηκα) 18:31, 25 April 2016 (UTC)

The args table has a metatable set on it, so it's not a regular table of values the way you're used to. —CodeCat 18:38, 25 April 2016 (UTC)
If you need to modify the args table, as I have had to do numerous times, I recommend just making a copy of it. --WikiTiki89 18:52, 25 April 2016 (UTC)
How is that done? —ObsequiousNewt (εἴρηκα|πεποίηκα) 19:50, 25 April 2016 (UTC)
Iterate over it and copy the results into a new table. DTLHS (talk) 19:54, 25 April 2016 (UTC)
(Edit conflict) If you're looking specifically to process template arguments, you may find Module:parameters useful. In the general case (which is what that module does internally), you create a new empty table, and then go over the args with pairs, copying each value over to the new table. —CodeCat 19:54, 25 April 2016 (UTC)
local args = {}
for key, value in pairs(frame:getParent().args) do
    args[key] = value
You can even take the opportunity to filter out blank arguments:
local args = {}
for key, value in pairs(frame:getParent().args) do
    if value ~= "" then
        args[key] = value
--WikiTiki89 19:55, 25 April 2016 (UTC)
But, as I have just demonstrated, using pairs() doesn't work Ah, I see—it will work for the values that have already been set. Thanks. —ObsequiousNewt (εἴρηκα|πεποίηκα) 20:00, 25 April 2016 (UTC)

Wiktionary:Beer parlour and onlyinclude[edit]

It looks like somehow my use of "onlyinclude" tags in Wiktionary:Beer parlour/2016/April#Cascading protection of the main page, despite being wrapped in "nowiki" tags, is preventing the April 2016 BP page from being transcluded properly onto the main WT:BP page. Anyone know how to fix this? --WikiTiki89 20:23, 27 April 2016 (UTC)

Did this do the trick? If not, I'm out of ideas. —Aɴɢʀ (talk) 20:53, 27 April 2016 (UTC)
Yes it worked (can't you see for yourself?). But I'm still curious what the problem was in the first place. --WikiTiki89 21:09, 27 April 2016 (UTC)
My guess is that onlyinclude tags get interpreted before nowiki tags do? —CodeCat 21:19, 27 April 2016 (UTC)
Yeah it seems so. Is it a bug? I think I had intended to write "includeonly" anyway. --WikiTiki89 21:21, 27 April 2016 (UTC)
Looks like it's working as intended (as counterintuitive as it sounds). KarikaSlayer (talk) 13:14, 28 April 2016 (UTC)

Problems with mobile site when rendering tables with show/hide functionality[edit]

Specific tables, those that implement the show/hide features from the ===View Switching=== section of MediaWiki:Gadget-legacy.js, do not render correctly when viewed in the mobile version of the Wiktionary website (https://en.m.wiktionary.org/). I had previously assumed it was a problem with my phone's browser, but I have since confirmed that it actually seems to be in the mobile site itself.

View, for example, the conjugation table at verdedigen. This exhibits some nice collapsing behavior -- when the page is first loaded, the table shows just the minimum of useful information. When the user clicks more ▼, the summary header disappears, to be replaced with the full conjugation paradigm. The user can click less ▲ to toggle back to the minimal table format.

Meanwhile, the mobile version of this same page at https://en.m.wiktionary.org/wiki/verdedigen shows the entire behind-the-scenes table content, with the minimal table header displayed as the first three rows of table content, after which we have the full conjugation paradigm. This is a bit confusing, as the first three rows duplicate information found elsewhere in the table, with the infinitive appearing twice just in the header. We also have no more ▼ or less ▲ to click on, suggesting that JavaScript either hasn't loaded for some reason, or is disabled outright.

I don't understand enough of how our site infrastructure works to be effective in resolving this problem. I'd greatly appreciate it if someone savvier could have a go at a fix. ‑‑ Eiríkr Útlendi │Tala við mig 21:04, 28 April 2016 (UTC)

The bizarre thing is that the "minimum" table rows have the vsShow CSS class, and in MediaWiki:Common.js this is set to be hidden by default. So a browser with no JS support should never show the minimum table rows, only those belonging to the full table. —CodeCat 21:09, 28 April 2016 (UTC)
Mobile devices do have JS support. The difference is the MediaWiki framework serves up different CSS and JS for the mobile site. The problem is most of our custom CSS and JS is not included in that, because none of us bother to take it into account. --WikiTiki89 21:20, 28 April 2016 (UTC)
  • This bug is still an issue.
One quick-and-dirty fix would be to tweak the hard-coded CSS specified in Module:hu-nominals, from width: 40%; to max-width: 400px;. Would anyone object to this? ‑‑ Eiríkr Útlendi │Tala við mig 21:47, 5 May 2016 (UTC)
@Eirikr: I tested the Module:hu-nominals changes in three browsers (Firefox, Chrome, and Safari) on a desktop computer. The first issue is that the main declension table width no longer matches the possessive table which is immediately below the main declension table. The second, bigger issue is that because of the fixed width, long words are simply chopped off and there is no way to horizontally scroll to see the end of the right side in the second column. Take a look at one of the longer words such as bányaszerencsétlenség. It's interesting that the horizontal scroll bar disappeared from both tables. I'm not sure how to resolve this, but I'd be curious to know why you picked Hungarian, it's not listed in your Babel box. :) --Panda10 (talk) 17:55, 9 May 2016 (UTC)
I see. Good luck to your studies, hope you'll enjoy it. --Panda10 (talk) 14:43, 10 May 2016 (UTC)
Using max-width is generally a bad idea. I've always used min-width. —CodeCat 18:07, 9 May 2016 (UTC)
  • Ah, yes, I'm reminded why I didn't suggest that before -- with min-width, the table stretches across the whole page. I inferred from the previous hard-coded width values that this was possibly undesirable. I don't have any specific problem with it, but folks should have a look and comment / edit as deemed appropriate.
I'll also see if I can figure out where to find the guts of the possessive table, and I'll make a similar change there. ‑‑ Eiríkr Útlendi │Tala við mig 22:21, 9 May 2016 (UTC)
I just noticed that the Hungarian tables are using the old system, the one with wrapping divs. That system isn't capable of taking the width of the contents of the table into account, so you're stuck with either a fixed width or a percentage. I'll work on converting it to the new system now. —CodeCat 23:42, 9 May 2016 (UTC)
Done. —CodeCat 23:56, 9 May 2016 (UTC)
  • Cheers! One note -- would it be possible to add a couple pixels of padding to the left and right of the listed terms? Things look a bit squished in the two tables at bányaszerencsétlenség, for instance, squished enough to be a bit hard to read on the most-crowded rows. ‑‑ Eiríkr Útlendi │Tala við mig 00:07, 10 May 2016 (UTC)
That's normal. If you can read Hungarian words line "bányaszerencsétlenség", you shouldn't have any problem with the padding. —CodeCat 00:09, 10 May 2016 (UTC)
  • There's shouldn't, and there's don't, and those two don't always align. If you're saying you won't make the change yourself, I may have a go later: the current layout presents a sub-optimal usability experience. ‑‑ Eiríkr Útlendi │Tala við mig 00:29, 10 May 2016 (UTC)
It was a bit of a joke. I was saying that if you can read the jumble of letters that is Hungarian, then surely you have no problem with a bit of padding. :p —CodeCat 01:23, 10 May 2016 (UTC)
@CodeCat: Thanks for making the changes. Is there a reason the possessive table appears half as long as the other when the two are closed? --Panda10 (talk) 14:43, 10 May 2016 (UTC)
It's because the content in the tables isn't the same width. —CodeCat 18:12, 10 May 2016 (UTC)
@CodeCat: Actually, the content in the tables is the same width. When I open both tables, they jump to the same size (not an exact size, but very close). --Panda10 (talk) 18:50, 10 May 2016 (UTC)
Expanding the tables changes the content, though, doesn't it? Browsers determine the width based on what's visible, so when the forms are hidden, they no longer "count" towards the width. What's left is the single table cell at the top of the table. —CodeCat 19:04, 10 May 2016 (UTC)
  • Could min-width be used to good effect here? It's a minor aesthetic issue, but having both tables the same width when closed and when open would present a cleaner interface. ‑‑ Eiríkr Útlendi │Tala við mig 19:12, 10 May 2016 (UTC)
It could, yes. It's what I had in mind originally. However, a more practical solution might be to just integrate both tables into one? —CodeCat 19:15, 10 May 2016 (UTC)
@CodeCat: When I look at Leonardo, the content of the single table cell at the top is much shorter than the table width, but I've just double checked and I think {{hu-decl-table}} is still having the old structure. Maybe that's caused my confusion. Is this something that would need updating, as well? About combining the two tables: It's a possibility, but it would be a huge table, might be too confusing for a student of the language. --Panda10 (talk) 19:23, 10 May 2016 (UTC)
I've updated that table now too. —CodeCat 19:33, 10 May 2016 (UTC)
Thanks! --Panda10 (talk) 21:10, 10 May 2016 (UTC)
I noticed you re-added the "of PAGENAME" bit to the table. I think it's kind of redundant, that's why I removed it. —CodeCat 21:56, 10 May 2016 (UTC)
Yes. I am trying to make the header longer to make the possessive table a little wider. --Panda10 (talk) 23:15, 10 May 2016 (UTC)
You can set a min-width on the table to make it wide without adding content to the header. —CodeCat 00:39, 11 May 2016 (UTC)
Unfortunately, setting min-width will not make the two tables the same width again. I am thinking now that the only solution is to change both tables to full length. The increased real estate will also allow to add the case names in Hungarian after the English. I've seen this done at other languages. As for the possessive tables, I've found an interesting structure in Quechua, see patacha. This table within table would eliminate the need to add declension tables to each possessive sublemmas. --Panda10 (talk) 14:00, 11 May 2016 (UTC)
I don't understand what the issue is. It works fine for me. —CodeCat 14:15, 11 May 2016 (UTC)
Yes, it does. Thanks for adding it. --Panda10 (talk) 14:22, 11 May 2016 (UTC)

Autoexpand various elements and templates on page load[edit]

Is there a way for me to auto-expand (or prevent the collapse of) more of the various collapsed elements? I'm particularly interested in the "Quotations" and "Derived terms" elements, e.g. -pathy has 3 "quotations" elements and a "derived terms" section. I'd like to read these parts without having to click anything.

I tried experimenting in my common.js, and managed to get the {{suffixsee}} "Derived terms" section to open automatically, but I cannot figure out how to work it for the Quotations elements... Can anyone help? Thanks! Quiddity (talk) 04:18, 29 April 2016 (UTC)

There's a "Visibility" section in the sidebar that should do what you want. DTLHS (talk) 04:29, 29 April 2016 (UTC)
Aha! Perfect, thank you. Quiddity (talk) 19:04, 30 April 2016 (UTC)


As pointed out on WT:TR, Module:fr-verb which is causing a lot of problems does not deal with this correctly. It imposes the wrong conjugated form disez for the imperative and since Module:fr-verb/documentation contains no information about how the module works (that's, right none) I am unable to fix the problem. Renard Migrant (talk) 12:53, 29 April 2016 (UTC)

Strange behaviour of mw.ustring.find[edit]

At [2] you see a function that fetches a page from the wiki (Reconstruction:Proto-Germanic/fuhsaz in this case) and searches for a string. It then displays 20 characters from the point where the string is found. This works ok, it finds the Descendants header correctly and shows the characters. But while it has no problem finding the header with the equals signs after the name, I'm not able to search for the equals signs before the name. The search string =Descendants turns up nothing, even though it's quite obviously on the page. Does anyone know what's going on? Am I missing something obvious? —CodeCat 00:02, 30 April 2016 (UTC)

expandTemplate changes the code - 'Descendants===' is preceded by '"`UNIQ--h-6--QINU`"'? in content. Wyang (talk) 00:15, 30 April 2016 (UTC)
This is oddly similar to a problem I was dealing with, where it turns out that the <poem> tag replace the content with some kind of unique id (and this happens before being passed to a template). For example, {{code||<poem>foo</poem>}} produces '"`UNIQ--poem-00000015-QINU`"'. --WikiTiki89 19:45, 10 May 2016 (UTC)

Template:desctree template loop[edit]

I created this template as a simpler alternative to {{etymtree}}. It fetches the contents of another page and transcludes the descendants onto the current page. It works well, see *tréyes for an example. However, the software doesn't seem to like recursive transclusion of the same template. So when one of the transcluded descendants uses this template itself, an error shows up. This appears in the Italic section, since the Proto-Italic page *trēs uses {{desctree}} to transclude all the Latin descendants. Is there a way around this? —CodeCat 16:37, 30 April 2016 (UTC)

I managed to work around it, by replacing the template with a module invocation. —CodeCat 19:18, 30 April 2016 (UTC)

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)

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." Nicole Sharp (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? Nicole Sharp (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)


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}}: [3], [4]. @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: [5]. 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)

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


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)

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