Open main menu

Wiktionary β

Wiktionary:Grease pit

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".

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 2017

Category:en:Maize (food)Edit

Why is there a trailing ]] at the end of the category description? —Μετάknowledgediscuss/deeds 22:08, 1 April 2017 (UTC)

A typo when @Chuck Entz entered the category in Module:category tree/topic cat/data/Food and drink. — Eru·tuon 22:17, 1 April 2017 (UTC)
Thanks for fixing that. In the category modules I always copypaste another section and rewrite it, but I forgot to completely replace the wikilinked word at the end. Chuck Entz (talk) 22:27, 1 April 2017 (UTC)

Error messagesEdit

I was trying to replace a post I made as an IP at WT:RFV but there was an error (my IP hadn't changed between the post and the trying). And even if I tried to add a new post instead of overwriting the old post, there came an error:

"Warning: This action has been automatically identified as harmful. Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it. A brief description of the abuse rule which your action matched is: probably vandalism. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit."

When I tried to submit it (cp. "you may submit it again to confirm it"), this error appeared:

"This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: probably vandalism".

The same errors appeared when trying to report these errors in the Grease pit (cp. "you may report it on the Wiktionary:Grease pit") or on talk pages, which is why I created this temporary account for the single purpose of reporting these errors. -Tmp-acc-xf (talk) 22:48, 2 April 2017 (UTC)

What was the original IP address? DTLHS (talk) 22:53, 2 April 2017 (UTC)
I also tried to post what I wanted to add, but the same errors appeared as when I tried to post as an IP.
-Tmp-acc-xf (talk) 23:00, 2 April 2017 (UTC)
It looks like one of the spam filters we have decided something in your post was "gibberish" (abuse filter 35 first line- can we make any improvements to this regex based on this example?) DTLHS (talk) 23:07, 2 April 2017 (UTC)
What is was trying to post where three links (two to but without the http and www part, each followed by a short quote (1 or 2 sentences). While the first edition I mentioned had "Stlat-ta" another one had "Stlat-a" (two and not three t) with a slightly different text. This would have looked like this:
The edition at [link] has: [quote]
The edition at [link] has: [quote]
The translation at [link] has: [quote]
This was in no way vandalism or spam. In the end I tried to summarize my post with this: "Looks like Paul. ex Fest. doesn't use the word.".
One of the quotes contained multiple dots which might stand for unreadable text, which I quoted with 5 dots following each other. -Tmp-acc-xf (talk) 23:25, 2 April 2017 (UTC)
It's ok, you don't need to justify yourself. This is just a spam filter that got triggered by something in your post. That doesn't mean that your post was actually spam, just that the filter had a false positive. —CodeCat 00:17, 3 April 2017 (UTC)

Navigation links on discussion pagesEdit

The layout of nav links that appear on monthly discussion pages has changed recently. I think the previous layout was more compact and I want it back. Am I the only one? --Dixtosa (talk) 19:31, 4 April 2017 (UTC)

Are these the changes? I don't mind them so much, but it might be nice to get them back to two lines tops... - TheDaveRoss 19:35, 4 April 2017 (UTC)
I also think it was fine before. —suzukaze (tc) 23:20, 5 April 2017 (UTC)
I have reverted the changes. --Dixtosa (talk) 07:57, 9 April 2017 (UTC)
Discussion room navigation at a large font size
Oh, I didn't notice this post. Huh. I had changed it because it didn't display well for me: the time navigation part was squished up over two lines next to the list of discussion rooms. It was probably related to my screen size. It looks okay on a different screen and browser, though I did like the other layout better. — Eru·tuon 08:47, 9 April 2017 (UTC)
Screenshot showing what I was trying to correct. — Eru·tuon 08:53, 9 April 2017 (UTC)
@Erutuon I added CSS so that each line wouldn't break, is it better now? —suzukaze (tc) 08:56, 9 April 2017 (UTC)
@Suzukaze-c: Oh yeah, that looks better. I liked the other way, but I can live with it now. Thanks. — Eru·tuon 11:01, 9 April 2017 (UTC)

Renamed audio files on Commons stemming from AddAudio.jsEdit

It seems like we might have a bunch of redlink audio files now since they were renamed on Commons from .ogg to .opus: diff, [1]. (@Yair rand) —suzukaze (tc) 03:39, 5 April 2017 (UTC)

They kept the old .ogg files as a redirect. So there should be no redlinks. --Panda10 (talk) 21:55, 5 April 2017 (UTC)
I don't think it works: (tc) 22:04, 5 April 2017 (UTC)
However, there are pages in Category:Pages with broken file links like 大肚黃 where .ogg needed to be updated to .opus. - -sche (discuss) 22:06, 5 April 2017 (UTC)
I wonder if a bot could check if there is a corresponding .opus file for links in that category and change the links if so. @DTLHS? — Eru·tuon 22:07, 5 April 2017 (UTC)
Unless the category is not catching all of these, there were so few that I opted to just start fixing them manually rather than writing a script to assist. I got about half of them done thus far and will finish up tomorrow probably. There are also a number of missing images and other similar problems in there, so I can hit those as I go. - TheDaveRoss 23:08, 5 April 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @-sche, Panda10, Suzukaze-c, TheDaveRoss: is the renaming of the files causing technical issues? An anonymous user just reported at Wiktionary:Feedback that the English sound file at autochthon no longer works, and indeed I couldn't get it to play, either here or at the Wikimedia Commons. — SMUconlaw (talk) 12:45, 11 April 2017 (UTC)

I have spot checked the ones I have changed and haven't encountered any that were broken. It might be specific to that file. - TheDaveRoss 13:14, 11 April 2017 (UTC)
I did not rename any of the Hungarian audio files from .ogg to .opus. There are about 20 of them created with this method. They are still working fine. --Panda10 (talk) 13:24, 11 April 2017 (UTC)
Anon's problem might be a lack of browser support for .opus files. —suzukaze (tc) 21:49, 11 April 2017 (UTC)
My browser is also not playing the referenced file, but is playing the others. - TheDaveRoss 21:54, 11 April 2017 (UTC)

Language subvariety labelsEdit

I've just added a bunch of language codes to labels in Module:labels/data/subvarieties. So now most of them have a language code, which means they will be accessible in entries.

There are quite a few labels that have the same name in the regional module (Module:labels/data/regional) and the subvarieties module. Currently, the label in the subvarieties module will replace the one in the regional module, because of the way in which the labels are collected by the main data module, Module:labels/data.

Go to Module:labels/documentation#Conflicts for the full list. Below is the current form of the list. It just checks for labels that have the same name; it doesn't check whether they have different content. (One difference is that the subvarieties labels have a language code, while the regional labels don't.)

Correct any errors by editing the label in the subvarieties module. Regional labels with the same name should be deleted from Module:labels/data/regional after the subvarieties label has been corrected. — Eru·tuon 04:49, 5 April 2017 (UTC)

So how do I decide whether something belongs to regional data or subvarieties data? Crom daba (talk) 18:05, 8 April 2017 (UTC)
Regional data is supposed to be language-agnostic. —CodeCat 18:14, 8 April 2017 (UTC)
That is, if it's a regional subvariety of a particular language (say, American English), it should go in the subvarieties module, not the regional one. — Eru·tuon 11:00, 9 April 2017 (UTC)

Module editor not workingEdit

The module editor is no longer loading on Module:zu-verbs. Can this be remedied please? —CodeCat 19:47, 5 April 2017 (UTC)

If it is any consolation (it is not), the module editor doesn't appear to be working on any module. —JohnC5 20:12, 5 April 2017 (UTC)
Possibly related, I was able to edit modules earlier today but the editor persisently reset from "plain wikitext mode" to that line-numbered mode every time I reopened the editor, e.g. on going to edit a new module or even just "previewing" the module I was editing. I am apparently now able to edit modules normally again. - -sche (discuss) 21:35, 5 April 2017 (UTC)
I've been having this problem regularly for perhaps two weeks now. I've just been reloading or reloading and clearing cache until the editor worked again. It is, however, a problem with all the JavaScript and not just the code editor, because it affected my TemplateScript functions and the CharInsert toolbar as well. — Eru·tuon 22:10, 5 April 2017 (UTC)

Interwiki bot task - link certain categoriesEdit

I would like an interwiki bot to go through the subcategories of fr:Catégorie:Langues and Category:All languages, and link the ones that are not linked. One possible way of doing this might be to link every not-yet-linked case where fr.Wikt has a category that contains (code <tt>[[FOO]]</tt>) and en.Wikt has one that contains {{langcatboiler|FOO|. Later other wikis' formulaically-named categories might be tackled, but fr.Wikt and en.Wikt are the ones with the most languages and I've noticed a lot of missed interwikis. Later it might be possible to extend the bot to find and link formulaically-named subcategories, like fr:Noms communs en alutiiq‎ = Category:Alutiiq nouns. - -sche (discuss) 05:53, 6 April 2017 (UTC)


I checked on multiple browsers, and the "expand" button appears outside the template itself, next to the definition (in apparently any Chinese entry). Ultimateria (talk) 10:58, 6 April 2017 (UTC)

I was noticing the same thing yesterday, sometimes it is placed where it belongs, other times it can be quite far outside of the box. - TheDaveRoss 11:17, 6 April 2017 (UTC)
Template_talk:zh-pron#Template_does_not_function_properly_in_conjunction_with_template:wikipediasuzukaze (tc) 03:22, 8 April 2017 (UTC)
Waiting for someone more technically adept to kindly fix the roaming button. Btw, the whole module should be reformatted and rewritten. Wyang (talk) 06:34, 9 April 2017 (UTC)

Recent changes -listEdit

I often patrol anon edits on this page [2]. Most of the content is unwanted from my point of view because I'm only interested in pages that are in languages which I know. Would someone be able to program a feature on that page which would allow the user to choose which language entries he wants to see? --Hekaheka (talk) 17:01, 6 April 2017 (UTC)

Wiktionary:Beer parlour/2016/April#Filter watchlists and recent changes by language--Dixtosa (talk) 17:19, 6 April 2017 (UTC)

New ?fromrc=1 parameter in urlsEdit

This now appears when you click links from recent changes. Does anyone know if this has any effect or will have any effect? DTLHS (talk) 21:07, 7 April 2017 (UTC)

I guess it's . —suzukaze (tc) 03:57, 8 April 2017 (UTC)

Possible bot task: checking of translation templatesEdit

i.e. making sure {{trans-top}}, {{trans-mid}}, and {{trans-bottom}} are all found together in an entry, instead of content like diff and diff or all these entries missing trans-mid. —suzukaze (tc) 03:25, 8 April 2017 (UTC)

There are a shit ton of these. I guess I'll finally get around to writing a translation table parser / repairer (which is really annoying to try and do). DTLHS (talk) 03:46, 8 April 2017 (UTC)
If we implement my suggestion at Wiktionary:Grease_pit/2017/March#Autobalancing_translation_tables, then there's no need to fix entries missing trans-mid. —Aɴɢʀ (talk) 07:38, 8 April 2017 (UTC)
That would require a more complicated bot rather than a less complicated one (although I am not opposed to your suggestion). - TheDaveRoss 13:17, 8 April 2017 (UTC)
I think Angr's suggestion should be implemented, in any case. And I'm not sure if it would be more complicated; the change would make {{trans-mid}} redundant anyway, so a bot could just remove it. —CodeCat 13:35, 8 April 2017 (UTC)
Once {{trans-top}} is made auto-balancing, all content can be removed from {{trans-mid}} so that it has no effect whatsoever. That way, it doesn't even have to be removed quickly. —Aɴɢʀ (talk) 15:18, 8 April 2017 (UTC)
Sorry, I mistook the method of balancing, it wouldn't increase complication at all. - TheDaveRoss 16:30, 8 April 2017 (UTC)

Module editor gone?Edit

Wyang (talk) 06:15, 8 April 2017 (UTC)

@Wyang:, did you accidentally turn it off by pressing the <> button on the top left corner of the editor box? — justin(r)leung (t...) | c=› } 06:50, 8 April 2017 (UTC)
Refer to #Module editor not working just above. —Μετάknowledgediscuss/deeds 06:51, 8 April 2017 (UTC)
@Justinrleung Yes... thanks! That fixed the problem - it's working well now. Wyang (talk) 07:03, 8 April 2017 (UTC)

Lua error message - but where's the error?Edit

It's popped up for derived terms at little which I reformatted last night. Metaknowledge edited it afterwards, but I can't spot any obvious error. DonnanZ (talk) 09:27, 8 April 2017 (UTC)

It seems to be in {{der3}}, related to changes in Module:columns. I think I've fixed the problem. — Eru·tuon 10:02, 8 April 2017 (UTC)
Thanks, it's fine now. It must have affected other derived terms sections too. DonnanZ (talk) 10:11, 8 April 2017 (UTC)

Testing changes to the translation adderEdit

I intend to work on the translation adder so that it works with User:Angr's proposal to make it autobalancing. But I don't know how I could test my changes without making them public first. Does anyone know? —CodeCat 17:01, 8 April 2017 (UTC)

I did some reading, and it looks like the easiest way to do this would be for an admin to add User:CodeCat/TranslationAdder.js to the list of gadgets. Then I can enable it and mess with it at will, and other editors can enable it if they wish for testing. So can this be done? —CodeCat 18:52, 8 April 2017 (UTC)
I believe a gadget has to be in the mediawiki namespace. DTLHS (talk) 20:40, 8 April 2017 (UTC)
Can you not load it using your common.js page using mw.loader.load(script)? - TheDaveRoss 11:58, 9 April 2017 (UTC)

Default font for certain character rangesEdit

Can we apply certain default non-Latin fonts to some character ranges? For example, Korean fonts to Hangul characters, Hani to Han characters, Thai for Thai characters, Deva for Devanagari characters, etc. I'm trying to clean up 하다 (which is a pain), and much of the cleanup is avoidable script formatting. Wyang (talk) 06:49, 9 April 2017 (UTC)

I don't understand the problem; are the font specifications in MediaWiki:Common.css insufficient? —Μετάknowledgediscuss/deeds 06:51, 9 April 2017 (UTC)
For example, in this revision, the unformatted Korean characters are in Sans-serif (14px), and every single occurrence of Korean characters needs to be individually formatted to make it appear consistently with the other template-formatted Korean texts (Gulim 15px). Can a default non-Latin font be applied to these non-Latin characters in running text? Wyang (talk) 06:58, 9 April 2017 (UTC)
I imagine that would require a JavaScript function, since there is no way to do that with CSS and HTML. — Eru·tuon 07:22, 9 April 2017 (UTC)
I suppose it's possible if you had CSS like font-family:Arial, Gulim (Arial doesn't have Korean characters and the browser would turn to Gulim next to display text). However, I think it is best if the text is tagged as Korean (lang="ko") using {{l}}/{{lang}}, because browsers and their users are also able to set certain fonts for certain languages (for example, I can tell Firefox to use Dengxian for any lang="zh" text). —suzukaze (tc) 07:28, 9 April 2017 (UTC)
Well, all Korean characters should be marked as lang="ko" by default, unless they are tagged as other languages for some reason. Hangul only lists Korean as the language using the script (cf. Wiktionary:Requests for verification#All words in Category:Cia-Cia lemmas in hangeul). Wyang (talk) 07:56, 9 April 2017 (UTC)
The tagging is part of the HTML markup. Wiktionary by itself is automatically tagged as lang="en", so lang="ko" must be added separately (which is why {{lang}}) exists. I suppose JavaScript is another option but automatically guessing languages doesn't sound like an easy task. —suzukaze (tc) 23:19, 9 April 2017 (UTC)

Sorting problem with der3Edit

I have only just noticed a sorting problem with {{der3}} and possibly the other variants. It doesn't seem to put hyphenated words and compound words in strict alphabetical order when there are also two-word terms, see little mentioned above. When converting derived terms at heavy to {{der3}}, as it contains many entries with hyphens I decided to use {{der3-u}} instead to get around the problem. DonnanZ (talk) 10:02, 9 April 2017 (UTC)

Fixed. Wyang (talk) 10:15, 9 April 2017 (UTC)
That was quick, thanks. The problem was obviously elsewhere. DonnanZ (talk) 10:23, 9 April 2017 (UTC)
What happens now is Module:columns removes spaces and punctuation marks before sorting the list items. So, heavy drinker and heavy-duty (from heavy) sort as heavydrinker and heavyduty. — Eru·tuon 03:15, 10 April 2017 (UTC)

Wikimedia Tech NewsEdit

I have been subscribed to the Wikimedia Tech News bulletin on my talk page for a while now, and there is often useful information to be found there. It is also possible to subscribe a project page so that we can have on delivery here and everyone can watch that page. Is there interest in having such a page on Wiktionary? Should it be the Grease Pit or some specific page (Wiktionary:Grease pit/Tech News)? It is a weekly delivery so I doubt that it would end up flooding this page, and it might be nice to have discussions directly under some of the topics. - TheDaveRoss 19:08, 10 April 2017 (UTC)

What sorts of things do they talk about? --WikiTiki89 19:22, 10 April 2017 (UTC)
You can see the most recent dozen or so on my talk page. In general they talk about changes needed and made to Mediawiki as they apply to Wikimedia wikis, as well as the API, gadgets, back-end architecture, etc. - TheDaveRoss 19:32, 10 April 2017 (UTC)
I think it wouldn't be a bad idea to have a WT:Wikimedia tech news page, perhaps with monthly subpages, otherwise we'd have to clear it when it fills up. --WikiTiki89 19:37, 10 April 2017 (UTC)
They are only weekly, so it wouldn't fill up too fast, but your point is well taken. The delivery is automated, and it looks like you can use magicwords to direct it dynamically. - TheDaveRoss 20:09, 10 April 2017 (UTC)
I like Wikitiki's idea. Other people might be encouraged to post there, to leave the GP for more local bugfixes, etc. —Μετάknowledgediscuss/deeds 21:58, 10 April 2017 (UTC)
I created a page and subscribed it (Wiktionary:Wikimedia Tech News) with annualized subpages. - TheDaveRoss 20:09, 17 April 2017 (UTC)

Roman to Arabic numeral templateEdit

Can someone create a template that converts Roman numerals to Arabic numerals? I'd like to use it in {{quote-meta/source}} and {{cite-meta}} to check for a chapter number that is expressed in Roman numerals. (At the English Wikipedia there is w:Template:Roman that converts Arabic to Roman numerals, but not the other way around.) — SMUconlaw (talk) 19:19, 11 April 2017 (UTC)

@Smuconlaw Module:roman numerals. Valid up to 3999. DTLHS (talk) 20:04, 11 April 2017 (UTC)
@Smuconlaw, DTLHS: I've created a function in the module and the template {{R2A}} to allow the use of the module from a template. — Eru·tuon 21:18, 11 April 2017 (UTC)
Can the module be categorised, please? —CodeCat 21:21, 11 April 2017 (UTC)
Wonderful! Thanks so much, everybody. I have categorized the new templates into "Category:Maths templates". — SMUconlaw (talk) 05:20, 12 April 2017 (UTC)
It has been moved to "Category:Mathematics templates". @Smuconlaw: how are you intending to use these templates? I'm just wondering what further upgrades we can add. I've added uppercase and lowercase matching to {{R2A}} and the ability to output lowercase in {{A2R}}. —JohnC5 14:11, 12 April 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Actually I just had the rather modest goal of allowing our citation and quotation templates to recognize chapter numbers expressed in Roman numerals (see this diff at {{quote-meta/source}}). Compare the following examples:

  • 2017, J. Testing, chapter 17, in Just Testing:
    Testing one, two, three.
  • 2017, J. Testing, chapter XVII, in Just Testing:
    Testing one, two, three.
  • 2017, J. Testing, “Experimenting Here”, in Just Testing:
    Testing one, two, three.

Previously, the template could not distinguish a chapter number expressed in a Roman numeral from a chapter name, and so would display the latter as “XVII” (instead of as chapter XVII). {{R2A}} is currently sufficient for this purpose, but perhaps I can suggest some improvements to it and to {{A2R}}:

  • {{R2A}} currently does not check for malformed Roman numerals, for example: {{R2A|VVV}}{{R2A|VVV}} [edited: issue now fixed]; {{R2A|XIM}} → 1009.
  • {{A2R}} does not accept numbers containing commas, for example: {{A2R|2,017}} → MMXVII [edited: issue now fixed].

SMUconlaw (talk) 14:29, 12 April 2017 (UTC)

@Smuconlaw: I've fixed the second issue. The first issue would be easy if we had regular expressions instead of patterns, but without that, this issue is much more complicated to fix. —JohnC5 14:50, 12 April 2017 (UTC)
Thanks! Yes, as I said, {{R2A}} works perfectly for present purposes. — SMUconlaw (talk) 14:55, 12 April 2017 (UTC)

Have you people seen Module:foreign numerals? --Vahag (talk) 05:16, 13 April 2017 (UTC)

Is it worth merging the two templates? — SMUconlaw (talk) 13:11, 13 April 2017 (UTC)
@Vahagn Petrosyan: Well that's frustrating/embarrassing. I'll merge these together soon. —JohnC5 15:00, 13 April 2017 (UTC)

Lua memory error at waterEdit

water currently begins to have a memory error near the end of the first Translations list. I couldn't figure out anything in the list of required modules on the edit page, or any recent module changes, that would have caused this. There have been changes at Module:columns, but as that module is not invoked on the page above where the memory error occurs, it can't be the reason. — Eru·tuon 21:00, 11 April 2017 (UTC)

There seems to be some element of randomness to how much memory is used at any given time; this has happened before, also apparently without anything have changed to cause it. I suggest in the BP that we move the translations of water. - -sche (discuss) 21:15, 11 April 2017 (UTC)
Lua has automatic garbage collection and therefore slightly unpredictable memory behavior. It would be good to run the page through a profiler to see where the memory is actually allocated/held; I don't have much experience doing this but can give it a go. – Jberkel (talk) 07:33, 12 April 2017 (UTC)

Help creating Mi'kmaq language templateEdit

I hope I'm in the right place to ask for help here. I want to start adding Mi'kmaq nouns to Wiktionary and so need a template that would look something like this:


(I don't know how the animacy bit would work as Wiktionary seems only to be set up for European languages with things like gender and case.)

I've read through the template documents but I don't understand coding and the more I read, the more confused I get. Setting up a template seems really complicated. Can anyone help me? Thanks Llusiduonbach (talk) 20:42, 11 April 2017 (UTC)

I've created a basic {{mic-noun}} template with some rudimentary documentation. Is this what you had in mind? Also, should every noun have a plural and obviative form, or are there nouns without them? —CodeCat 21:05, 11 April 2017 (UTC)
@Llusiduonbach ? —CodeCat 16:05, 12 April 2017 (UTC)
Thank you so much! I don't have sufficent knowledge of Mi'kmaq to answer your question, but I assume that all have obviatives but not all have plurals. I may be able to answer your question the more I study. Llusiduonbach (talk) 21:18, 12 April 2017 (UTC)
I've just come across an issue where a noun has two obviatives. Is it possible for the template to deal with nouns that have more than one plural and/or obviative? Llusiduonbach (talk) 21:24, 12 April 2017 (UTC)
In answer to your question, yes, some nouns don't have either plurals or obviatives from what I can see. Llusiduonbach (talk) 21:33, 12 April 2017 (UTC)
I've added the parameters pl2=, pl3=, obv2= and obv3=. If you need more, you can have a look at the template code and I think you can probably figure out the pattern to add them. —CodeCat 21:38, 12 April 2017 (UTC)
Thanks, yes I see. This was the noun withou a plural or obviative. I can't get the tag (?) "inan" to work for it for some reason. Llusiduonbach (talk) 21:40, 12 April 2017 (UTC)
Oops, it should be just in for inanimate nouns. It's fixed now. —CodeCat 21:42, 12 April 2017 (UTC)
Many thanks for your help. I really appreciate it! Llusiduonbach (talk) 21:44, 12 April 2017 (UTC)

content after Template:ux gets put on a new lineEdit

I have noticed that writing e.g.

  • {{ux|en|fließen}} {{q|Germany, Austria}}
  • {{ux|en|fliessen}} {{q|Switzerland, Liechtenstein}}

results in

  • fließen
    (Germany, Austria)
  • fliessen
    (Switzerland, Liechtenstein)

i.e. the qualifiers appear on separate lines from the usexes. I don't know if there are any cases where it's desirable for content which is intended to show up on the same line as the {{ux}} to be placed outside of the {{ux}} template, but nonetheless it seems undesirable and possibly unintentional for {{ux}} to force such content onto a new line. - -sche (discuss) 07:17, 12 April 2017 (UTC)

Notice how you intentionally used the wrong language code to get this to show up how you think you wanted it? That's a hint toward what the problem is. When you have a properly formatted usage example, meaning with a translation to English, where is this qualifier supposed to show up? Logically, putting it after the {{ux}} template should make it show up after the entire usage example and its translation, which is probably not where you want it. You want it to show up after the original language. I think the best solution would be to build a |q= parameter into the {{ux}} template, or something of the sort. --WikiTiki89 14:38, 12 April 2017 (UTC)
Yup, that makes sense. — SMUconlaw (talk) 14:40, 12 April 2017 (UTC)
OK, I'll add a qualifier parameter to {{ux}}. – Jberkel (talk) 11:02, 13 April 2017 (UTC)
@-sche done, Special:Diff/42696900. – Jberkel (talk) 01:53, 25 April 2017 (UTC)

Quiet QuentinEdit

I noticed that User:TheDaveRoss has been manually going through and properly formatting quotes. I don't know how many other people use the QQ gadget for quotes, but I think it should be updated with proper format. Also, if you search for a common word such as "día", the entire first page of results does not contain a single quotation, just books with the word in the title. I wonder if this can be fixed. Ultimateria (talk) 15:18, 12 April 2017 (UTC)

Kephir, who left some time ago, was the creator of Quiet Quentin; I don't know if anyone else with the ability to improve it is willing to do so. Your second issue is a problem with Google Books itself, and has nothing to do with QQ. —Μετάknowledgediscuss/deeds 18:56, 12 April 2017 (UTC)

Strange page notice at "Wiktionary:Sandbox"Edit

This is a really minor point, but when one clicks the edit link at "Wiktionary:Sandbox", a strange page notice with the single word "yes" appears above the edit window. Can this be removed or changed to something more meaningful? I can't figure out how to edit the edit notice. — SMUconlaw (talk) 17:59, 12 April 2017 (UTC)

The contents of the edit notice are controlled by this page: MediaWiki:Editnotice-4-Sandbox. It contains a reference to {{sandbox}} which appears to be used by many (including myself) as a place to test templates. We should move the message we want to display from the template page to the editnotice message page so that people don't test with it. - TheDaveRoss 18:34, 12 April 2017 (UTC)
I suspect something got mixed up during the discussion at Template_talk:sandbox. —suzukaze (tc) 01:51, 13 April 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Suzukaze-c, TheDaveRoss: actually, I tried editing MediaWiki:Editnotice-4-Sandbox but didn't seem to be able to change the contents of the edit notice at Wiktionary:Sandbox. Did I do it correctly? — SMUconlaw (talk) 12:21, 21 April 2017 (UTC)

I don't know why this warren of templates and conditional statements exist, but I just replaced the message with a static version and it worked fine. I think the issue is in one of the #if statements which evaluates to empty when at the Sandbox, if you think they are important feel free to track that down. - TheDaveRoss 12:46, 21 April 2017 (UTC)
@TheDaveRoss: thanks. Yeah, I couldn't figure out what the templates and conditional statements were for either, but didn't want to break anything by just removing them. — SMUconlaw (talk) 20:26, 6 May 2017 (UTC)

Screen readers and transliterationsEdit

It just occurred to me, that transliterations are completely useless for users relying on screen readers to read out words for them. A good screen reader will pronounce foreign words properly, so the transliteration doesn't add anything and might even confuse the user because they will end up hearing the word pronounced twice (possibly incorrectly the second time, too). So how can we make transliterations "invisible" to screen readers so that they just get skipped? —CodeCat 18:49, 12 April 2017 (UTC)

And what will happen when the language is one that the screen reader doesn't know how to read? --WikiTiki89 18:53, 12 April 2017 (UTC)
Would it know how to read the transliteration, then? —CodeCat 18:56, 12 April 2017 (UTC)
It could at least try and read it wrongly. --WikiTiki89 18:57, 12 April 2017 (UTC)


I created this very simple little template to help with making templates. If you give it text with embedded wikilinks, it will return it unchanged. If there are no embedded wikilinks, then it will put square brackets around it. It's essentially what {{l}} does, but suitable for embedding into another template like {{l-self}} without resulting in double-tagging. —CodeCat 22:11, 12 April 2017 (UTC)

Column templates made autobalancingEdit

I have made {{der-top}}, {{hyp-top}} and {{rel-top}} (and variants with a number) autobalancing, so that they automatically split their content into columns evenly. This means that the -mid templates are no longer needed, and can be removed from entries. —CodeCat 20:39, 13 April 2017 (UTC)

Why not have the column numbers be a parameter? --WikiTiki89 20:42, 13 April 2017 (UTC)
I was going to propose that soon, but I haven't been able to finish this task as some of the templates are protected from editing. Consequently, entries with {{rel-top3}} are currently broken until it's unprotected and I can fix it. {{top2}}, {{top3}}, {{top4}}, {{mid2}}, {{mid3}}, {{mid4}} and {{bottom}} need to be unprotected as well. —CodeCat 20:46, 13 April 2017 (UTC)
@CodeCat: I've unprotected them. Go ahead. --WikiTiki89 20:48, 13 April 2017 (UTC)
Done. Thank you! —CodeCat 20:55, 13 April 2017 (UTC)
Are you going to remove the mid templates with your bot? DTLHS (talk) 20:44, 13 April 2017 (UTC)
I have a script ready to run, is it ok to run it? What we've done so far is easy to reverse, but removing these templates from lots of entries isn't. —CodeCat 21:25, 13 April 2017 (UTC)
We should probably wait a week or so to see if anyone reports any problems. DTLHS (talk) 21:48, 13 April 2017 (UTC)
Or any conscientious/principled objectors *cough*Dan*cough* —CodeCat 21:50, 13 April 2017 (UTC)
But regardless, I agree we should give it some time. --WikiTiki89 22:00, 13 April 2017 (UTC)
There's currently a problem at WT:RFDO#Template:nv-top2, Template:nv-mid2, Template:nv-bottom2. Columned tables in some entries were designed so that there would be a header at the top of each column, and the autobalancing breaks this. I think the solution lies here but I'm not sure how it would best be applied. —CodeCat 21:59, 14 April 2017 (UTC)
I experienced slightly odd behaviour with {{top3}} with 25 entries in Jefferson County, and get the same result if {{mid3}} is removed. However with 17 entries in Union County there's no problem, and I left {{mid3}} out. DonnanZ (talk) 10:04, 16 April 2017 (UTC)
Also with {{top2}} with 9 entries in Benton County balancing 4/5 with or without {{mid2}}. If I insert a fictitious 10th entry it balances 5/5. DonnanZ (talk) 12:19, 16 April 2017 (UTC)
That's an issue of your browser. —CodeCat 12:31, 16 April 2017 (UTC)
Why, do you get a different result? DonnanZ (talk) 12:36, 16 April 2017 (UTC)
No, but the columnisation is done with CSS and CSS is always processed client-side. —CodeCat 12:46, 16 April 2017 (UTC)
It has been a week now. Are the problems mentioned above serious enough to postpone orphaning the mid-templates? —CodeCat 16:12, 20 April 2017 (UTC)
They do the job after a fashion, but balancing of columns is not what I would call perfect. I am convinced more than ever that templates like {{der3}} are the ultimate answer; they can be made to work very well, even with hidden notes and qualifiers. DonnanZ (talk) 12:16, 5 May 2017 (UTC)
I strongly oppose using the {{der3}} method; I much prefer either the markup/style method which CodeCat has suggested or else the old-fashioned balancing we have been doing all along. - TheDaveRoss 12:45, 5 May 2017 (UTC)
Every one to their own. Anyway the mid-templates are superfluous now, so I guess they can be removed, unless there are other objections. DonnanZ (talk) 13:07, 6 May 2017 (UTC)


Can we please create this gadget with the code in User:Wyang/Switcher.js? I would like to try this on {{zh-dial-map}} (displaying and hiding low-frequency labels, etc.). Thanks! Wyang (talk) 00:34, 15 April 2017 (UTC)

@Wyang:   DoneΜετάknowledgediscuss/deeds 05:44, 15 April 2017 (UTC)
@Metaknowledge Thanks! It's not working though- see for example User:Wyang/sandbox. Perhaps it needs to be listed somewhere to allow it to be enabled, but I'm not sure. Wyang (talk) 10:58, 21 April 2017 (UTC)
I don't know how it works, but you have to enable the gadget for yourself. —Μετάknowledgediscuss/deeds 16:12, 21 April 2017 (UTC)
@Metaknowledge I think all the steps at Wikipedia:Gadget#Installation have to be followed.—suzukaze (tc) 00:22, 23 April 2017 (UTC)
@Wyang, suzukaze-c (For future reference, that link should actually go to w:WP:Gadget#Installation.) All that I seem to have to do is add it to MediaWiki:Gadgets-definition, but I don't know if there are any dependencies. What is the exact line I should add, and where should it go? —Μετάknowledgediscuss/deeds 03:03, 23 April 2017 (UTC)

Etymology-only languagesEdit

Why does contro categorise into Category:Italian twice-borrowed terms? Old Italian is an etymology-only language, so can't Italian terms be derived from it? —Μετάknowledgediscuss/deeds 05:42, 15 April 2017 (UTC)

Etymology-only languages are always treated as part of their parent language. So as far as our templates are concerned, Old Italian is a form of Italian. This means that if an Italian term is derived from Old Italian, it's essentially derived from itself. —CodeCat 12:37, 15 April 2017 (UTC)
But should that be the case? In principle, even if Old Italian is considered a "dialect" of Italian, shouldn't it be possible to write the modules so that {{der|it|roa-oit|...}} categorizes into CAT:Italian terms derived from Old Italian just as {{der|en|roa-oit|...}} categorizes into CAT:English terms derived from Old Italian? I think that would be beneficial. —Aɴɢʀ (talk) 14:15, 15 April 2017 (UTC)
Yeah, it is obviously better for it to work as one might expect, like Angr described. @Erutuon, maybe? —Μετάknowledgediscuss/deeds 18:41, 15 April 2017 (UTC)
Hmm, there is probably a way to fix this. I will look at it when I have time. — Eru·tuon 00:13, 16 April 2017 (UTC)
@Erutuon, a reminder. I'm still hoping someone will fix this. —Μετάknowledgediscuss/deeds 03:11, 26 April 2017 (UTC)
@Metaknowledge: Thanks for pinging me; I had forgotten. I've come up with a solution for contro at least. I'm questioning whether it might cause problems in other entries, though. There might be cases in which we might want a word coming from a word in a subvariety of the same language to be categorized as double-borrowed. If so, the solution would have to be more complex. — Eru·tuon 03:43, 26 April 2017 (UTC)
In some cases, people add labels as etymologies; it is good to catch such errors somehow, although I suppose patrolling "Latin twice-borrowed terms" is as much a way to do it as looking for "Latin terms borrowed from Late Latin". - -sche (discuss) 04:51, 6 May 2017 (UTC)
Whereas, this apparently should be (but isn't) in the "twice-borrowed terms" cat. - -sche (discuss) 04:58, 6 May 2017 (UTC)
Related: it would possibly make sense for Category:Spanish terms derived from Lunfardo to work. Likewise, there are a number of German terms, and some Bavarian terms, derived from Rotwelsch, which I would add an etymology-only code for and category if I knew it was desired and would work. - -sche (discuss) 02:54, 14 May 2017 (UTC)


The parameter "|num=sg" doesn't work in quisque in the line {{la-decl-multi|quis<irreg>que|num=sg}} which creates this:

Number Singular Plural
Case / Gender Masculine Feminine Neuter Masculine Feminine Neuter
nominative quisque quidque quīque quaeque
genitive cuiusque
quōrumque quārumque quōrumque
dative cuique quibusque
accusative quemque quidque quōsque quāsque quaeque
ablative quōque quibusque

where under "Plural" one can see plural forms which shouldn't be there. The examples at Template:la-decl-multi show that "|num=sg" should work. - 14:08, 16 April 2017 (UTC)

Problem with cookies?Edit

Is there some new problem with the cookies that Wiktionary uses? The website has suddenly stopped remembering certain states, such as the fact that I have marked notices read, and that I want quotations to be shown by default. I am using Mozilla Firefox 52.0.2. — SMUconlaw (talk) 16:48, 16 April 2017 (UTC)

Yes, there is a long-standing problem with cookies in Firefox that stems back to a change made in a recent Firefox update. The long story is here at Phabricator. There are a couple of workarounds specifically you can increase the number of global cookies and domain-specific cookies which Firefox will retain and that has been fixing the issue for most everyone. - TheDaveRoss 23:41, 16 April 2017 (UTC)
Ah, thanks. The problem went away after I restarted the browser, but if it happens again I'll try the solution mentioned above. — SMUconlaw (talk) 05:59, 17 April 2017 (UTC)
The problem happened again when I tried to add translations to an entry. I followed the advice at the Phabricator and it seems to have worked, though I started with 200 but had to increase it to 500. — SMUconlaw (talk) 18:45, 21 April 2017 (UTC)

water is brokenEdit

This technical discussion was split off of the originally policy/content-based discussion at Wiktionary:Beer_parlour/2017/April#Moving_the_translations_of_water.

Even with the (biggest chunk of the) translations moved off the page entirely, the page is still broken! It makes it as far as the first "Derived terms" section before "The time allocated for running scripts has expired." Whereas, the subpage with the translations on it (newly switched to use a less-module-heavy template) is fine. So something besides (just) the translations is eating up memory. But what? - -sche (discuss) 02:33, 17 April 2017 (UTC)

This is probably related to the new sorting code that {{der4}} uses in Module:columns. DTLHS (talk) 02:29, 17 April 2017 (UTC)
I made an empty edit and the error messages went away (at least for me). — Ungoliant (falai) 02:32, 17 April 2017 (UTC)
There's a certain amount of randomness in whether or not Lua runs out of memory, which I think someone said was due to the manner in which garbage collection is done. In any case, I would guess that the removal of the error is a temporary artefact of that, and that it may return. I'll try copying the contents of the page into a bunch of subpages of mine, to see if (and how often) Lua runs out of memory. - -sche (discuss) 02:38, 17 April 2017 (UTC)
If the problem is related to {{der4}} then we should switch that page back to the old method of manually sorted columns, or switch to a CSS solution. I think we should probably avoid using Lua to change the display of contents and either maintain such things by bot or leverage the browser to do it via CSS. Just because it is possible to do something via JS or Lua does not mean that it is the best way, or even a sensible way. - TheDaveRoss 15:30, 17 April 2017 (UTC)
When I moved the translations back into the main entry, it broke again, this time running out of memory at the Middle English section for both Erutuon (see Talk:water) and me. This suggests that the improvements to {{t-simple}} may have helped (the error was previously midway through the translations table), but not enough. - -sche (discuss) 09:58, 25 April 2017 (UTC)
Looks like {{der4}} is the next place to look for problems:
 79.45% 7172.432      1 Template:der4
 12.66% 1142.925    650 Template:l
  1.99%  179.528     81 Template:t+
  1.51%  136.079     53 Template:t
  1.51%  135.997    130 Template:t-simple
While execution time (per call and net) is not a perfect analog for Lua memory issues, it can be a good indicator. - TheDaveRoss 11:09, 25 April 2017 (UTC)
I wonder if turning off sorting in {{der4}} would remove the problem. A bot could do the sorting manually instead. — Eru·tuon 21:51, 25 April 2017 (UTC)
I have changed the template from {{der4}} to {{der4-u}}. DTLHS (talk) 22:07, 25 April 2017 (UTC)
That seems to fix the problem. I guess sorting takes quite a bit of memory. — Eru·tuon 22:11, 25 April 2017 (UTC)
Even with {{der4-u}}, the translations have to be on a separate page, because if I re-add them to the main entry, it runs out of memory at the start of the Limburgish section (see this revision). I suppose I should file a Phabricator bug report: what should it say?
"Many users have confirmed that Lua runs out of memory ("Lua error: not enough memory") on one of en.Wikt's most complete and module-heavy pages, water (see revision history and [3]), resulting in some sections of the entry needing to be housed on a separate page. Testing suggests there may be an issue with Lua's garbage collection, with a large number of individually not-that-intensive tasks do not release memory when they finish. The issue persists despite simplification of the most common (module-invoking) template (Template:t is now Template:t-simple in many cases) and of the apparently next-most resource-hungry template (Template:der4, now Template:der4-u). Because other entries will one day be as complete as water, this issue will affect more pages if not addressed. If Lua cannot be changed, an alternative bit of assistance would be to help us identify which pieces of code are using the most memory."
? - -sche (discuss) 16:03, 27 April 2017 (UTC)
I filed T165935 about this. - -sche (discuss) 04:33, 21 May 2017 (UTC)

error reportEdit

Wiktionary's "you may submit it again to confirm it" doesn't work.
While I tried to add a missing dot to end a sentence, this message appeared:

"Warning: This action has been automatically identified as harmful.
Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it.
A brief description of the abuse rule which your action matched is: Adding xxx and nothing else. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit."

And when trying to submit it again, this came up:

"This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Adding xxx and nothing else"

- 08:48, 17 April 2017 (UTC)

Which entry were you trying to add the full stop to, what was the sentence you were adding to, and were you only trying to add the full stop or the whole sentence? — SMUconlaw (talk) 09:17, 17 April 2017 (UTC)
It was in quisquis. There was a sentence without a full stop and I wanted to add it. While doing it, I also tried to change "quote<ref>reference</ref>," into "quote,<ref>reference</ref>", that is, I tried to move the comma.
As for the entry, it got fixed now (diff).
As for the message, it's annoying that even the "you may submit it again to confirm it" doesn't work. - 09:44, 17 April 2017 (UTC)
The message which was served was the generic warning message, and for non-"disallow" filters it is true that re-submitting will work. For filters which both warn and disallow, a specific message is needed which does not indicate that re-submitting will work. I have created such a message for the filter in question. - TheDaveRoss 15:44, 17 April 2017 (UTC)

Template:grc-IPA bug at φεῖEdit

A screenshot of a bug in the location of the "more" expansion button from the template Template:grc-IPA at φεῖ.

As can be seen in the image at right, the "more" button to expand the pronunciations displays in the completely wrong location. --WikiTiki89 12:51, 21 April 2017 (UTC)

@Erutuon: I grow weary of dealing with this problem. Shall we just remove the collapsing functionality? I believe this was also a condition @CodeCat had before she would support using a bot to convert all the instances of {{grc-ipa-rows}} to {{grc-IPA}}. —JohnC5 15:08, 21 April 2017 (UTC)
I personally like the collapsibility. --WikiTiki89 15:10, 21 April 2017 (UTC)
I usually like the collapsibility too, but not when it becomes more trouble than it's worth. If things like this are possible, I'd rather get rid of it. —Aɴɢʀ (talk) 15:52, 21 April 2017 (UTC)
Is this the same problem as zh-pron above? —suzukaze (tc) 18:49, 21 April 2017 (UTC)
So, the issue is that we are manually calculating the width of the table so that the "show" button will sit immediately to the right of the first row. If we could get it to autoscale with css, that would be the best option. —This unsigned comment was added by JohnC5 (talkcontribs).
Try wrapping everything in a div with style="display: inline-block; overflow: auto" and then get rid of the manual width and make any other block div inside it "display: inline-block". --WikiTiki89 22:27, 21 April 2017 (UTC)
@Wikitiki89: I tried that on a user page of mine, and it doesn't seem to give a good result. The unexpanded content gets wrapped. Perhaps it can be fixed, though. See this revision. Feel free to experiment further. — Eru·tuon 19:15, 22 April 2017 (UTC)

Template:mention and Citations:/b/tardEdit

The output of Template:mention on Citations:/b/tard is broken: it links to "/b/tard/b", and displays "/b". Note that passing in an unnamed parameter with the correct page name to Template:citation doesn't fix this; while it does correct the displayed text to "/b/tard", it changes the link target to "/b/tard/b/tard" instead. Digging in a bit further I suspect the actual problem is with Module:links/templates, but my command of Lua is nowhere near good enough to debug that without some serious effort on my part, and probably not even with. Dinoguy1000 (talk) 05:19, 22 April 2017 (UTC)

It's not a module problem; you simply need to link to it with a colon in front. I left a note on the talk page some years ago to remind people of this. —Μετάknowledgediscuss/deeds 05:52, 22 April 2017 (UTC)

New template {{uxi}}Edit

I created the template {{uxi}} as a shorter equivalent of {{ux|...|inline=1}}. I've been meaning to do this for awhile, as inline usage examples are extremely common and it's annoying to have to type so many characters (and frequently forget to do it). Benwing2 (talk) 20:44, 23 April 2017 (UTC)

I still think this should be done automatically by the template. —CodeCat 21:38, 23 April 2017 (UTC)
I agree, but I have no idea how to decide where to set the cutoff, esp. as it ought to vary depending on your screen size (and hence should properly use some CSS magic). Benwing2 (talk) 21:39, 23 April 2017 (UTC)
True, but it's a start. Right now, everyone will insert inline=1 based on their own individual judgement, which will lead to a lot less consistent results. —CodeCat 21:41, 23 April 2017 (UTC)
I think all of Wiktionary should be written automatically with a template. Unfortunately that would be hard to implement. We do what we can. --WikiTiki89 16:53, 24 April 2017 (UTC)

Param sub= to {{ux}}, {{uxi}}, {{quote}}Edit

Usex and quote templates can now take a sub= parameter. This is used for languages like Russian, Yiddish, Arabic, Hindi, etc. that have auto-transliteration but sometimes require exceptional transliterations of particular words in a usex. Previously, if any word required exceptional transliteration, you had to give a manual transliteration of the entire usex or quote, which is annoying and error-prone when the text to be transliterated is long. The sub= parameter fixes this by letting you supply phonetic respellings of individual words prior to transliteration being invoked. Here is an example:


#: {{ux|ru|Полицейские огородили середину шоссе́ на гора́х, '''всле́дствие чего́''' бегле́ц был на воле.|Police officers blocked the middle of the highway '''as a consequence that''' a fugitive was on the loose.|subst=шоссе́/шоссэ́}}


  1. Полицейские огородили середину шоссе́ на гора́х, всле́дствие чего́ бегле́ц был на воле.
    Policejskije ogorodili seredinu šossɛ́ na goráx, vslédstvije čevó begléc byl na vole.
    Police officers blocked the middle of the highway as a consequence that a fugitive was on the loose.

In this case, we want the word шоссе́ to be transliterated šossɛ́ instead of šossé, which is the auto-translit. the sub= param phonetically respells шоссе́ as шоссэ́ to match its pronunciation, causing it to be correctly transliterated as šossɛ́.

In Yiddish this would be especially useful in conjunction with Hebrew words.

The sub= expression is actually a Lua pattern substitution.

An alternative to the way I set up sub= is to apply the substitution *after* transliteration. This has the advantage that it works even if there are letters used in transliteration that have no ways of being represented in the source script; but it could potentially run into problems in languages like Arabic, where certain examples of source script can't be transliterated at all (typically if the vowel markers are missing). What do people think? Should I change sub= to apply after translit?

Benwing2 (talk) 21:30, 23 April 2017 (UTC)

Could the parameter be named subst= instead? It would be a little clearer, so as to not be confused with the meaning "below". —CodeCat 21:37, 23 April 2017 (UTC)
Sure. Benwing2 (talk) 21:39, 23 April 2017 (UTC)
Making the substitution apply to the transliteration would be less understandable, because the transliteration does not show in the wikitext, but only in the resulting HTML. However, applying the substitution to the transliteration might be more useful in other languages.
What about making the module detect which script is being used in the substitution parameter? If it's the native script of the language, the substitution would have to be applied to the text used to produce the transliteration; if it's the Latin script, the substitution would have to be applied to the transliteration. — Eru·tuon 22:05, 23 April 2017 (UTC)
Changed to use subst= instead of sub=, and to take multiple parameters instead of a single comma-separated param. Benwing2 (talk) 02:17, 25 April 2017 (UTC)
Changed back to using a single comma-separated parameter, but still named subst=. --WikiTiki89 14:41, 25 April 2017 (UTC)
I'm not fond of the name "subst=" since that string already has an entirely different meaning in connection with templates. How about "sptr=" for "specific (or special) transliteration"? —Aɴɢʀ (talk) 15:16, 25 April 2017 (UTC)
I was thinking "trsub=". --WikiTiki89 15:22, 25 April 2017 (UTC)
That'll work too. —Aɴɢʀ (talk) 15:43, 25 April 2017 (UTC)
I'm ok with that. —CodeCat 15:48, 25 April 2017 (UTC)
@Benwing2: Do you have anything against |trsub=? --WikiTiki89 19:23, 25 April 2017 (UTC)
My objection to this is that trsub= or trsubst= ought to be used for a substitution that applies to the transliteration rather than to the source text. I was actually thinking of adding a parameter with this exact name, which works like sub=/subst= but applies to the translit. Benwing2 (talk) 02:16, 26 April 2017 (UTC)
I honestly don't see why either sub= or subst= is a problem. We already have, for example, param gloss= and template {{gloss}}, which do different things. And I don't see why sub= would be confused with the meaning "below". Benwing2 (talk) 03:37, 26 April 2017 (UTC)
It's a substitution that applies in order to generate a translit. I don't see why that's such a problem. If you just say "sub" or "subst" then it is not obvious what the substitution is for. --WikiTiki89 14:14, 26 April 2017 (UTC)
It's a problem in that I wanted to implement trsub=/trsubst= with a different meaning. Another possibility is respell=; IMO that makes it even clearer what is going on, since it's respelling the word phonetically in order to generate proper translit. Benwing2 (talk) 03:32, 27 April 2017 (UTC)
@Benwing2: Have you considered my idea above, of making the substitution function detect the script before deciding whether to apply the substitution before or after transliteration? — Eru·tuon 03:46, 27 April 2017 (UTC)
@Erutuon This is possible but feels a bit hacky to me. Let me think about it more. Benwing2 (talk) 04:05, 27 April 2017 (UTC)
You could have trsubst= and trsubstafter= or something like that. --WikiTiki89 14:51, 27 April 2017 (UTC)


It's not even humorous how many examples of bad spellings we have in Wiktionary. Anybody have a friendly spellobot who can change all (most?) instances of humourous to "humorous", please? There's too many for me. --WF April 2017 (talk) 21:37, 23 April 2017 (UTC)

Are all of these errors, though? We should not generally be changing spellings that occur in quotations, for example. The spelling could occur in an old text at a time when there was less consensus about what the "correct" spelling was. — SMUconlaw (talk) 08:07, 24 April 2017 (UTC)
  Fixed. Actually, the list wasn't too long, so I changed all the ones that were obviously errors. — SMUconlaw (talk) 08:14, 26 April 2017 (UTC)
I tagged the quoted uses with {{sic}}. --WikiTiki89 16:51, 2 May 2017 (UTC)
Thanks. Did you check if they were actually spelled that way in the sources, though? I wasn't able to, so that's why I didn't do anything to them. — SMUconlaw (talk) 16:53, 2 May 2017 (UTC)
Yes I did. In one case, the Google Books title even spelled it correctly, while in the actual scan of the book it was spelled incorrectly. --WikiTiki89 16:55, 2 May 2017 (UTC)
Great! — SMUconlaw (talk) 17:57, 2 May 2017 (UTC)

Wikitext classEdit

It seems to me it would be valuable to have a class "wikitext" to mark examples of wikitext with. For instance, Module:template link could add it to examples of template syntax created by {{temp}}. When someone finally comes up with a wikitext syntax highlighter, some of the text marked with this class could be switched over to that.

Unless there are objections, or better ideas for the name that the class should have, I will make {{temp}} add <code class="wikitext"></code> around the template code (in place of what it currently adds, just plain <code></code>), and perhaps also make {{para}} do the same. — Eru·tuon 08:03, 26 April 2017 (UTC)

Sounds like a good idea to me. The only alternative name which jumps out is wiki markup. I believe that technically wikitext is a document written in wiki markup, but that is a pretty trivial distinction in this case. - TheDaveRoss 11:25, 26 April 2017 (UTC)
Well, I kind of like being nit-pickingly correct, and so do many other Wiktionarians. Perhaps "wiki-markup" would be a better class name. — Eru·tuon 11:34, 26 April 2017 (UTC)
Before we argue about names, why do we need this in the first place? Maybe we should wait until there actually is a wikitext highlighter before worrying about it. --WikiTiki89 14:16, 26 April 2017 (UTC)
To make it clear what a given instance of the code tag actually is being used for. At the moment, we have it being used for wiki markup, URLs, and Lua code. It is a good idea to make distinctions using classes, even though there aren't any visual differences to these classes encoded by MediaWiki:Common.css yet. There are other semantic classes that we could add. One that we already have is "etyl", used for language names in etymologies. (Unfortunately, it's used for all etymology types alike; that is unsatisfactory.) — Eru·tuon 19:14, 26 April 2017 (UTC)
Lua code is normally tagged (and syntax highlighted). URLs don't use code tags at all. --WikiTiki89 19:36, 26 April 2017 (UTC)
I recall URLs using code tags (or maybe kbd tags) in one of the citation or quote templates, but I can't recall which right now. Lua code uses syntax highlighting when there's enough for the highlighter to work; but I have been using <code class="n"></code> to format individual variables at certain points. (Hmm, that may not be necessary; var works just fine.) — Eru·tuon 19:42, 26 April 2017 (UTC)

Adyghe ux transliterationEdit

Under the Adyghe word кӏьэрыт there is a usage example containing the word Гонахьхэр which gets transliterated as Γonāḥxăr. Presumably this should be Gonāḥxăr and the capital Γ has just been overlooked somewhere. It also comes out as Γ in the transliteration created by {l|ady|...}, though it is correct in {l|ru|...}. -- 13:02, 26 April 2017 (UTC) —This unsigned comment was added by Hiztegilari (talkcontribs).

No error there. We transliterate Adyghe г, which represents IPA(key): [ɣ], with Greek γ, the capital of which is Γ. See WT:ADY TR. Perhaps we should switch to the Latin pair ɣ/Ɣ. @Adamsa123, what do you think? --Vahag (talk) 14:17, 26 April 2017 (UTC)
The Latin version is a bit problematic and confusing. While the letter Г represents [ɣ], го is [gʷa].--Adamʂa123 (talk) 20:45, 26 April 2017 (UTC)
@Vahagn Petrosyan: Perhaps it would be better to use the characters ɣ and Ɣ? --WikiTiki89 21:25, 26 April 2017 (UTC)
@Wikitiki89: Isn't that exactly what Vahagn himself proposed above? At any rate, I agree. —Aɴɢʀ (talk) 21:32, 26 April 2017 (UTC)
Oh yeah. --WikiTiki89 21:50, 26 April 2017 (UTC)
OK, then I am changing the transliteration to Latin ɣ/Ɣ. The Tower of Babel too uses the Latin version. --Vahag (talk) 05:02, 27 April 2017 (UTC)
Why not just transliterate it as G/g? —CodeCat 21:35, 26 April 2017 (UTC)
Because Adyghe г etymologically does not correspond to the phonemes transliterated as g in other West Caucasian languages. --Vahag (talk) 05:02, 27 April 2017 (UTC)
But it's a transliteration, not an etymology. We don't transliterate Г as G in Ukrainian, either, after all. —CodeCat 13:35, 27 April 2017 (UTC)
I have simply followed the Caucasiological transliteration documented here. It is designed to help comparing cognates in different Caucasian languages. --Vahag (talk) 14:58, 27 April 2017 (UTC)


The documentation of this template says that it must always be substituted, but it is used directly in {{ae-verb}}. Is this a problem? @Aryamanarora. DTLHS (talk) 17:14, 26 April 2017 (UTC)

@Aryamanarora: Would it be possible to enter the root in the Avestan script? --WikiTiki89 17:18, 26 April 2017 (UTC)
@DTLHS, Wikitiki89: This was mostly done for time-saving; I churned out a bunch of Avestan entries this week. The Avestan script is somewhat of an annoyance to type in... I can get rid of the direct transclusion if I have to though. —Aryamanarora (मुझसे बात करो) 17:45, 26 April 2017 (UTC)
You could use the substable version. Just page {{ae-verb|{{subst:chars|ae|transliterated root}}}} in the entry. You could even create a shortcut template and use it like this: {{subst:ae-verb-gen|transliterated root}}. --WikiTiki89 17:48, 26 April 2017 (UTC)

Show translationsEdit

I don't know if something is wrong in Wiktionary or if it's just on my computer. Suddenly I cannot open or view Translation sections. The Translation sections are closed, and in the sidebar at the left margin "Show/Hide translations" does not appear. It's only here on en.wiktionary. When I look at other wiktionaries, such as ca:honor, I can see the Translation sections, and in the sidebar the words "Mostra traduccions" (Show translations) appear. —Stephen (Talk) 05:40, 27 April 2017 (UTC)

I have been having unpredictable problems with the Wikimedia JavaScript functions for a month or two now, including the translation sections, other collapsible content, my TemplateScript functions, the regular editor, and the code editor (Lua, CSS, and JavaScript pages). I just reload or shift-reload (clear cache), and eventually it fixes itself. It's a makeshift solution; I wish I had a permanent one. — Eru·tuon 05:51, 27 April 2017 (UTC)
I tried clearing my cache (a few times), but it didn't help. I logged out and back in again. I also cleared my cookies, but no help there. —Stephen (Talk) 06:56, 27 April 2017 (UTC)
Okay, I think I've found the problem. I don't know about other browsers, but I use Firefox for PC and I have always used Monobook skin. Monobook (as well as all of the other skins except Vector) is not working correctly anymore. The only way I can get Translation sections on en.wiktionary to work is by switching to Vector skin (which I don't like). I don't understand why this only affects en.wiktionary and not the other wiktionaries, but there you have it. —Stephen (Talk) 07:13, 27 April 2017 (UTC)
Is anyone looking at this problem? The toolbar is also gone.--Anatoli T. (обсудить/вклад) 13:56, 27 April 2017 (UTC)
Do you mean the ADVANCED and SPECIAL CHARACTERS that are supposed to appear above the edit window, Anatoli? That's also affected. If you're using Monobook skin, the Special Characters, etc., have vanished. You have to use the Vector skin to see them. Besides that, when you click on WATCHLIST, at the top you should see either a box that explains abbreviations (N m n ! (±123)) or otherwise Legend:[Expand]. Those are gone, too, for Monobook. You have to use Vector to see them. Maybe they will be fixed in a later update, or maybe they won't. It's extremely vexing. —Stephen (Talk) 19:53, 27 April 2017 (UTC)
I can't use Translations table with ANY skin. After a couple of hard refreshes, I can get the table contents displayed but I can't add translations. I can use my iPhone's Safari still but it doesn't work on PC's Chrome or Firefox browser (Firefox has been very unreliable for any Wiktionary work lately). --Anatoli T. (обсудить/вклад) 10:36, 29 April 2017 (UTC)
  • I am on Firefox, Monobook. I cannot expand translation sections. Most of my bookmarklets stopped working as well. From what I remember, I've had this problem only today and yesterday. --Dan Polansky (talk) 13:22, 29 April 2017 (UTC)
This is a serious problem. I wonder why not many editors have these symptoms:
I started having the same problem as of today. I use Firefox, too. It also occurs when I use Chrome. Vedac13 (talk) 03:21, 11 May 2017 (UTC)
Judging by comments in a couple of places, I think everyone has the problem now- this is new. Just now I've tried MS Edge, MS IE and Chrome, with the same results- nothing expands. Chuck Entz (talk) 03:38, 11 May 2017 (UTC)
I am currently using vector in preferences but tried other skins with the same or worse results. The translation adder doesn't work at all (no buttons appear). Translations appear intermittently, after a hard refresh only, both on Chrome and Firefox. --Anatoli T. (обсудить/вклад) 13:59, 29 April 2017 (UTC)
Please make a screenshot of your browser's console.--Dixtosa (talk) 16:09, 29 April 2017 (UTC)
You are using the most recent Firefox, aren't you? (rev. 53.0). As long as I am in Vector, my Firefox (Windows 10) is working as expected. —Stephen (Talk) 21:25, 29 April 2017 (UTC)
Hi all, just advising that I think that one of my gadgets had a conflict with the translation adder. I've disabled them all as I don't have time to check all individual ones. I'm OK for now. --Anatoli T. (обсудить/вклад) 02:21, 1 May 2017 (UTC)
@Atitarev: For me, the Tbot gadget recently broke, and I disabled it. You can probably re-enable everything but Tbot. --WikiTiki89 18:59, 1 May 2017 (UTC)
@Atitarev, Stephen G. Brown: I commented out a custom copy of Tbot.js in User:Dan_Polansky/common.js and I am fine. In User:Stephen G. Brown/monobook.js, I see "importScript('User:Ruakh/Tbot.js');" and "addOnloadHook(function() { Tbot.greenifyTranslinks('ru'); });", so I would try to comment those out. Maybe someone can figure out which part of User:Ruakh/Tbot.js needs an update. --Dan Polansky (talk) 17:59, 9 May 2017 (UTC)
I did the same, and it fixed it for me. —Aryamanarora (मुझसे बात करो) 19:47, 10 May 2017 (UTC)
Yeah, I use vector skin, and today all the collapsible tables stopped working for me. I don't have much in the way of js customization, and so I have no idea how to fix this. I'm using Chrome. Any ideas? —JohnC5 03:39, 11 May 2017 (UTC)
Tabbed languages aren't working either. I don't think the problem is with our individual browsers; there's something wrong serverside. —Aɴɢʀ (talk) 08:18, 11 May 2017 (UTC)
Discussion of the issue which started today is at Wiktionary:Grease pit/2017/May#Show-and-hide_templates_not_working_properly. - -sche (discuss) 08:30, 11 May 2017 (UTC)

Request for Template:inflection ofEdit

Can this be changed so that, when one of the inflection tags (numbered parameters) is just a comma, a space is not inserted before? e.g. nom|,|acc|and|dat should become "nominative, accusative and dative" and not "nominative , accusative and dative". —CodeCat 14:01, 27 April 2017 (UTC)

Are we sure this is the right way to handle syncretism? In Russian what we always do is list each case as a separate definition. Benwing2 (talk) 02:54, 28 April 2017 (UTC)
For languages where a very high number of inflected forms are homographic, it may be. Compare roten, Template talk:inflected form of. - -sche (discuss) 19:50, 29 April 2017 (UTC)
I agree that it's better to list them in one line, as long as it can be done concisely and clearly. --WikiTiki89 19:00, 1 May 2017 (UTC)
I generally use the semicolon, which avoids repeating the lemma form over and over. — Eru·tuon 20:07, 1 May 2017 (UTC)
That's overly repetitive. —CodeCat 20:13, 1 May 2017 (UTC)
Perhaps, but I'm doubtful that listing a gender, three cases, and a number is a good idea either. It might be ambiguous or at least confusing to someone who doesn't know what categories these things belong to (i.e., that one chooses the gender, one of the three cases, and the number in order to get a correct set of inflectional categories for one of the grammatical forms to which the term belongs), and it may not be machine-readable. There ought to be a better of doing this. (Ideally, the module would object if you failed to include one of the necessary grammatical categories: a case and number, but no gender, for instance. That would require part-of-speech information to be supplied to the template, though, and language-specific sets of grammatical categories required for each part of speech. But this is sort of tangential to the topic of this thread...)Eru·tuon 22:17, 2 May 2017 (UTC)
I'm very partial to conflating these things on a single line, especially when the forms in question always or usually pattern together. From the δίκαια (díkaia) example above: in Ancient Greek (indeed, in all IE languages I know of), the nominative, accusative, and vocative of all neuter nouns, singular and plural, are always the same. So conceptually, it's preferable to say that δίκαια (díkaia) is the nominative/accusative/vocative plural, rather than suggesting it's the nominative plural, and coincidentally also the accusative plural, and coincidentally also the vocative plural. In other forms, where it is just coincidence that the same word belongs to two different nonlemma forms, it makes more sense to list them separately. —Aɴɢʀ (talk) 18:30, 9 May 2017 (UTC)
This is the situation in which I'm using it too. I also use it when there is always syncretism between different forms of nouns belonging to a certain inflectional class. For example, Middle Dutch dāge belongs to the a-stem class (or what's left of it) and these three cases are always identical for such nouns. I opted not to use it for the syncretism between masculine and neuter in grôten, though, instead using it for the accusative-dative syncretism. —CodeCat 21:32, 9 May 2017 (UTC)
My other concern is formatting the three-member list correctly. It should have a serial comma ({{,}}) before the and; not sure how to make that happen. — Eru·tuon 19:36, 9 May 2017 (UTC)


Is it possible to have {{trans-see}} improved, so it goes directly to the entry rather than to the top of the page as it does at present? DonnanZ (talk) 21:56, 27 April 2017 (UTC)

  • Isn't that achievable using the following, quoting from the documentation?

Optionally, the second parameter can be used, for example to link to particular etymology or part of speech e.g. {{trans-see|rally|[[rally#Etymology 2|rally]]}}, which yields:

Do you have something else in mind? DCDuring (talk) 22:22, 27 April 2017 (UTC)

I think Donnanz means that the first parameter should link to #English by default (when no second parameter is present). DTLHS (talk) 22:25, 27 April 2017 (UTC)
I don't think {{trans-see}} is used for any language other than English, I did mean a direct to the top of the English entry, in the same way as {{l|en|xxxx}}. DonnanZ (talk) 22:41, 27 April 2017 (UTC)
I was using {{l|en|xxxx}} nested in {{trans-see}} as a workaround, and that worked fine, but these have been nuked by Matthias Buchmeier, so I'm looking for a permanent solution. DonnanZ (talk) 22:51, 27 April 2017 (UTC)
Translation tables could add an anchor to the page, which other pages can then refer to. This would allow a link to go directly to the right translation table, and if I'm not mistaken, it will automatically expand too. —CodeCat 22:58, 27 April 2017 (UTC)
@CodeCat: {{trans-top}} does automatically add an anchor (id), but {{trans-see}} might need to be modified so that it can actually point to it. At the moment, the id is simply Translations- plus an anchor-encoded version of the first parameter supplied to {{trans-top}}. So, the anchor is going to change whenever someone changes the gloss at the head of the translations table. To fix this, there should be a way of specifying a more permanent anchor (id). I like the idea of assigning numbers to each translations table, but those too would end up changing whenever someone added or removed a translations table. — Eru·tuon 00:46, 28 April 2017 (UTC)
Or we could not do any of that. Just linking to #English would be an improvement. This is why we have glosses. DTLHS (talk) 00:51, 28 April 2017 (UTC)
I like the idea of linking to specific translation tables; as with sense ids, it makes navigation much easier. But till that can be done, I agree that linking to the English section is the best solution. — Eru·tuon 00:56, 28 April 2017 (UTC)
Translation tables should match each sense. So preferably the translation tables should have the same sense ids as the senses themselves. The on-page anchors could be English-xxx for a senseid and Translations-xxx for the corresponding translation table. As long as we don't have a language called Translations, that should be ok. :P —CodeCat 01:51, 28 April 2017 (UTC)
  • Having just used {{trans-see}}, I'm tempted to ask if there's any progress with this. DonnanZ (talk) 11:33, 5 May 2017 (UTC)
    • Seems like one solution would be to add a |anchor= parameter to {{trans-see}} and {{trans-top}}, which will remain unchanged even if someone changes the gloss. That can then be used to make {{trans-see}} link directly to the correct translation table. Otherwise, if someone decides to change the gloss in {{trans-top}}, the link from a {{trans-see}} will either break or someone will have to go and change the gloss in {{trans-see}} whenever the corresponding gloss in {{trans-top}} is changed.
    • Or perhaps a bot could automatically change the gloss in {{trans-see}} to match the corresponding gloss in {{trans-top}}, when it has been changed. @DTLHS, what do you think? Could that be done? — Eru·tuon 19:57, 5 May 2017 (UTC)
      • Why not use senseids, as I suggested? They were created specifically for the purpose of pointing unambiguously to one particular sense. {{trans-see}} and {{trans-top}} should both get an |id= parameter. —CodeCat 20:24, 5 May 2017 (UTC)
        • @CodeCat: When you said "sense id", I thought you meant having {{trans-see}} point to a definition in the POS section, because that's where sense ids are used. That would be unhelpful, because {{trans-see}} should be pointing to a translations table. I suppose that was a misunderstanding. Having translation ids that are consistent with sense ids isn't relevant to the current issue, of how to make {{trans-see}} point to a particular translation table. It would, however, be useful if at some point we want to make definitions link to translation tables. Anyway, I suppose |id= would be a pretty good name for the parameter in {{trans-see}} and {{trans-top}} that determines what text to add after Translations-; briefer than the parameter |anchor= that I proposed. — Eru·tuon 18:57, 6 May 2017 (UTC)
      • No I don't think it could be done. I am opposed to senseids or translation anchors from a maintainability perspective. DTLHS (talk) 03:27, 6 May 2017 (UTC)
        • What is your opposition to senseids? Does it also apply to the {{senseid}} template used in definitions? —CodeCat 12:11, 6 May 2017 (UTC)

Getting rid of interwikisEdit

Another vandal meddling with interwiki links reminds me that someone ought to run a bot to remove them all, and we could also use an abuse filter to prevent any rogue bot from trying to add them back. —Μετάknowledgediscuss/deeds 22:11, 28 April 2017 (UTC)

  • I notice OctraBot has been removing what are described as "old interwiki links", but they still appear in the entry's left-hand column. DonnanZ (talk) 14:48, 29 April 2017 (UTC)
    @Donnanz: That's exactly the point. We are removing the old interwiki links because now Wiktionary fetches them automatically. If you create ja:dogless in the Japanese Wiktionary, an interwiki will appear automatically in dogless, here in the English Wiktionary. --Daniel Carrero (talk) 14:51, 29 April 2017 (UTC)
Oh, I wondered why. They are still useful to have. Thanks for the explanation. DonnanZ (talk) 14:59, 29 April 2017 (UTC)
You're welcome. --Daniel Carrero (talk) 15:05, 29 April 2017 (UTC)
@Metaknowledge I am happy to make a bot to remove all the old links, but I gather that there are some which should stay. Also, as the Conflagrate extension is not yet working properly, should we wait a bit longer? - TheDaveRoss 20:29, 5 May 2017 (UTC)
@TheDaveRoss: I would appreciate that. All the mainspace ones can go once we get assurances that they actually know what they're doing and that the extension will continue to be operational. —Μετάknowledgediscuss/deeds 20:42, 5 May 2017 (UTC)
  • I have a serious comment. It's about apostrophes. Some Wiktionaries use different ones to us, we should keep those interwikis. --Celui qui crée ébauches de football anglais (talk) 21:02, 5 May 2017 (UTC)
    Keep for now, and request the fancy new interwiki machine to understand them in the future. - TheDaveRoss 21:10, 5 May 2017 (UTC)
    No, you misunderstand. Our old interwiki system ignored the apostrophe problem, and relied on redirects. The new system ignores the apostrophe problem as well. So there are no exceptional interwikis to keep. —Μετάknowledgediscuss/deeds 22:07, 5 May 2017 (UTC)
    I am not familiar with the apostrophe problem, can you explain it? Perhaps I could do something useful about it while removing the existing ones? - TheDaveRoss 13:00, 6 May 2017 (UTC)
    Some Wiktionaries use curly apostrophes while we use straight ones. This makes interwikis not work if the page name has to match exactly. The solution has been to create redirects from one type of apostrophe to the other, on all Wiktionaries. Since the new Cognate extension still relies on pages having the exact same name, nothing has changed in that respect. —CodeCat 13:16, 6 May 2017 (UTC)
    Ah, thanks for explaining. - TheDaveRoss 13:25, 6 May 2017 (UTC)
I have a bot ready to go to remove these, has anyone heard any objection or should I let it run? - TheDaveRoss 18:01, 6 May 2017 (UTC)
I would think it would be appropriate to hold off on removing interwikis for a few days, at least, given that the devs had to temporarily shut down the extension that automatically supplied the links, as detailed in other threads on this page (Wiktionary:Grease_pit/2017/May#Automatic_interlanguage_links, phabricator report). - -sche (discuss) 18:20, 6 May 2017 (UTC)
@TheDaveRoss: Cágate Cognate (was that too mean?) is working and it seems you're good to run your bot now. —Μετάknowledgediscuss/deeds 23:42, 11 May 2017 (UTC)
Actually not yet, on the some pages it doesn't work yet. There is a bug in phabricator for it already (and a thread in this month's GP). --WikiTiki89 00:45, 12 May 2017 (UTC)
@TheDaveRoss, Wikitiki89: It seems any remaining problems with it in mainspace are resolved, so I think you should run your bot now. —Μετάknowledgediscuss/deeds 19:47, 18 May 2017 (UTC)
@Metaknowledge, TheDaveRoss: There is still the issue of pointing to redirects. Is it worth waiting for that to be resolved? Is it worth writing a bot that will leave links to redirects in place for now? --WikiTiki89 19:58, 18 May 2017 (UTC)
This is something which they are trying to handle through the extension eventually, but cannot yet, right? - [The]DaveRoss 20:15, 18 May 2017 (UTC)
Yes. However, there seems to be some disagreement between us and the French Wiktionary regarding normalization, which may delay or block this feature. See the discussion at phab:T165061. --WikiTiki89 20:43, 18 May 2017 (UTC)
Thanks for standing up for English Wiktionary there. I guess I found the normalization rules here. I would much rather not have them, but at least there are only three of them. — Eru·tuon 21:44, 18 May 2017 (UTC)
I'm tempted to think that having only three is even worse, because it is sorely inadequate on its own and it might block the fixing of the redirect bug, which we would need to fill in the gaps. --WikiTiki89 21:57, 18 May 2017 (UTC)
Is there a subset of pages that we can avoid while removing interwikis from the rest? DTLHS (talk) 21:04, 19 May 2017 (UTC)
How about the pages whose titles would be subject to the normalization: those containing the characters listed in the link above? — Eru·tuon 21:10, 19 May 2017 (UTC)
Ok. It is going to take a while, there are a lot of interwiki links. - [The]DaveRoss 19:54, 18 May 2017 (UTC)
Would you like any help? We could divide up the pages somehow. DTLHS (talk) 19:59, 18 May 2017 (UTC)
Udo has also offered to help. —Μετάknowledgediscuss/deeds 20:06, 18 May 2017 (UTC)
Sure. I was planning on searching the May 1 dump to find instances of interwikis, would you be doing the same or using AllPages from the API? Or something else? Either way we can find a good offset for start points. - [The]DaveRoss 20:08, 18 May 2017 (UTC)
My bot UT-interwiki-Bot uses a customized script ( for Wiktionaries from Hydriz (the owner of HydrizBot, a global bot, too). This pywikibot-script doesn't use a dump and will be started the first time with the option -start:! and then works alphabetically through all entries (only in namespace=0). To divide the work, other bots could start for example at -start:G, -start:m or something else. Greetings --Udo T. (talk) 20:33, 18 May 2017 (UTC)
I'll be using the dump and my own script. DTLHS (talk) 21:36, 18 May 2017 (UTC)
Ok, but it's completely unnecessary to use a dump because a bot has to edit almost all entries. --Udo T. (talk) 21:43, 18 May 2017 (UTC)
There are lots of entries that are only on enwikt. Using a dump means I don't have to query the site until I find a page that needs to be edited. DTLHS (talk) 21:47, 18 May 2017 (UTC)
I also have a custom framework that I use, and it doesn't really go alphabetically (since the dump is in pageid order). Is it possible to have the Python bot run in pageid order instead of alphabetical? I can change the way I am doing it, but as DTLHS mentioned there are hundreds of thousands of pages with no interwiki links, and it would be a bit more efficient to skip them. - [The]DaveRoss 21:53, 18 May 2017 (UTC)
You could generate a list of pages to edit and then sort them alphabetically. DTLHS (talk) 21:57, 18 May 2017 (UTC)
I can do that, just have to rewrite some of the bot. Another question is how many edits per minute we should all have combined, presumably each of these bots could run at least three times as fast as they should run. - [The]DaveRoss 23:47, 18 May 2017 (UTC)
Well I am somewhat limited by slow internet speed so I don't know how fast I could push it. I didn't realize we were in a hurry. DTLHS (talk) 00:01, 19 May 2017 (UTC)
I don't think there is a hurry, except that it would be nice to get the job done. - [The]DaveRoss 00:16, 19 May 2017 (UTC)
I think we could use devs' help by using User:Conversion script or something similar. This way it would be much smoother. Note that 100k articles were renamed in just 30 minutes by Conversion script. --Giorgi Eufshi (talk) 06:37, 19 May 2017 (UTC)

Sorry, but I think then I can not support you. Because my Pywiki-bot runs either on Tool Labs or my own Linux server and I do not waste time downloading a gigabyte-sized dump, which is no longer up-to-date after 1 or 2 weeks. In addition, I have no problems with Internet speed, neither on Tool Labs nor on my own Linux server. With the Pywikibot framework you can, by the way, quietly change every 5 seconds, because a Pywiki-bot can be slowed down via API, if the load on the servers becomes too large. Another last tip: You should first set up a filter that prevents users from continuing to add interwiki links in entries. Take a look at User talk:Udo T.... Greetings from Austria --Udo T. (talk) 09:24, 19 May 2017 (UTC)

Not sure why downloading the entire uncompressed wiki via the API is more onerous than downloading the dump, but that is neither here nor there. I created an abuse filter which tags interwiki links that point at identically titled pages. We can flip it from tag to disallow at some point. - [The]DaveRoss 22:40, 19 May 2017 (UTC)


Something's broken... —Aryamanarora (मुझसे बात करो) 13:52, 29 April 2017 (UTC)

An anon messed with the "return labels" in Module:category tree/poscatboiler/data/terms by usage. I reverted the edit and protected the page. --Daniel Carrero (talk) 13:54, 29 April 2017 (UTC)
Great, seems good now! —Aryamanarora (मुझसे बात करो) 14:02, 29 April 2017 (UTC)

Template:head and Reconstruction pages with slashesEdit

The headword of Reconstruction:Proto-Sino-Tibetan/p(r)an/t ~ b(r)an/t displays as "*t". We could add head=*p(r)an/t ~ b(r)an/t, but it would be better to update Template:head to handle cases where a page in the Reconstruction namespace uses a slash, the way it already handles pages in the main namespace that use slashes, like he/she. I don't think there are pages in the Reconstruction namespace that use slashes to form subpages (which is what the template is currently assuming is happening), are there? - -sche (discuss) 19:41, 29 April 2017 (UTC)

Actually all RC entries use a slash as a subpage. I think what you meant is that none of them have a second level subpage. Still, subpages are enabled in the RC namespace to allow for the first level subpages. I think it would be better not to use slashes in reconstructions, I don't even understand what the slash means here. --WikiTiki89 19:04, 1 May 2017 (UTC)
As a stopgap, it's possible to specify how the headword is supposed to look with head=. I've done that for *p(r)an/t ~ b(r)an/t now. —Aɴɢʀ (talk) 19:45, 1 May 2017 (UTC)
The basic issue is in Module:headword it's using mw.title.getCurrentTitle().subpageText as a starting point for generating the default headword. This is also used for generating various other defaults in modules, such as sort keys. subpageText takes the part after the last slash, but it takes into account whether a namespace has subpages or not, so it still works for the main namespace where subpages are disabled. A possible, but drastic, solution would be to just not use subpages for reconstructions anymore. —CodeCat 20:22, 5 May 2017 (UTC)
Instead of using subpages, we could remove the Reconstruction:language_name/ from the beginning of the pagename. That would solve the problem. — Eru·tuon 01:01, 6 May 2017 (UTC)
Done. Everyone, please let me know if the new code causes any problems. — Eru·tuon 01:18, 6 May 2017 (UTC)
It seems to be working. Excellent, thank you! That's a better and less drastic solution than renaming all the pages to not use [first-level] subpages. - -sche (discuss) 01:55, 6 May 2017 (UTC)
This is perhaps something for BP, ES or WT:About Proto-Sino-Tibetan instead, but I'd like to note that having extensive punctuation in headwords is quite ugly and should perhaps be avoided. OP's example seems particularly egregious, using three different types of punctuation purely to indicate uncertainty in the reconstruction. --Tropylium (talk) 11:06, 8 May 2017 (UTC)
Yes, it's a bit confusing. Is it saying the form could have beem pan, pat, pran, prat, ban, bat, bran, or brat? Then why not write p/b(r)an/t? It would be good if the meaning of the punctuation was at least documented, with examples. - -sche (discuss) 18:47, 9 May 2017 (UTC)
Or better yet, just call it pran and list the alternatives on the page. --WikiTiki89 19:14, 9 May 2017 (UTC)


Hello, I was wondering if Wiktionary had a feature equivalent to wiki-blame or git-blame where we could see the page's text with editor name and edit date on the left, with possibly some color code (the redder the more recent etc). This would greatly improve time for locating editors responsible for certain changes. Thank you. —Julien D. (talk) 20:05, 29 April 2017 (UTC)

The official w:Wikipedia:WikiBlame works for Wiktionary too. I have too written it myself although it does not have that many options and mainly lacks binary search method. On a positive side mine uses newer API to fetch multiple pages (50 AFAICR) at once making it faster when the search method is set to linear.--Dixtosa (talk) 20:28, 29 April 2017 (UTC)
Thank you, your button works very well, but I couldn't make the wiki-blame page work. That said, it seems your button works on selected text only. Do you have a mode where the entire page is annotated line by line with author and date? —Julien D. (talk) 21:20, 29 April 2017 (UTC)

Bot / AWB RequestEdit

Can someone with a bot and/or AWB do null edits on all the categories in CAT:E? I suspect the system isn't going to clear them any time soon. Since this wouldn't constitute making changes to anything and won't show up in edit histories, even an unauthorized bot would do. Chuck Entz (talk) 21:10, 29 April 2017 (UTC)

  Done Either it cleared itself overnight, or someone did the null edits (if someone did- thank you!). If memory serves, it was fine the next day. Chuck Entz (talk) 02:47, 3 May 2017 (UTC)
@Chuck Entz I have a script for this that I can very easily run at any time. You can PM me whenever you need it done. —CodeCat 13:20, 11 May 2017 (UTC)
Sorry for the delay. I ran my bot to clear the category after seeing the request, but forgot to reply here after it finished. Wyang (talk) 13:26, 11 May 2017 (UTC)

Category:No script specified scriptEdit

Is this something we want? —suzukaze (tc) 00:32, 1 May 2017 (UTC)

Obviously not, so I deleted it and protected it so DTLHS's bot doesn't recreate it. I don't know what to do with CAT:No script specified script characters, though, which is a bit more problematic. —Μετάknowledgediscuss/deeds 00:36, 1 May 2017 (UTC)
I mean, we should assign them to their respective scripts — in Module:scripts/data, I guess? Looking at , is the Latin Extended-D block not already marked as Latin (Latn or Latinx) script? - -sche (discuss) 00:46, 1 May 2017 (UTC)
We could have Category:Unspecified script -- I mean, if there's any use for it, at least this name makes sense and can end with the word "script". --Daniel Carrero (talk) 01:24, 1 May 2017 (UTC)
This could be implemented by changing the canonical name for the code None in Module:scripts/data from "No script specified" to "unspecified". Then the category would be CAT:Unspecified script, as you propose. — Eru·tuon 03:44, 2 May 2017 (UTC)
Sure, thanks for linking to the data module. Now I've done just that. --Daniel Carrero (talk) 23:03, 4 May 2017 (UTC)
Would it be worth the trouble to add code suppressing the addition of "Script" when the script name already includes it? I believe we already do something like that with languages- at least I haven't seen anything like "American Sign Language language". Chuck Entz (talk) 03:08, 2 May 2017 (UTC)
At some point, I already added some code to treat "Morse code" as a script like Latin or Cyrillic for categorization and formatting purposes. The main category is Category:Morse code. It does not have the word "script" added, so it's not Category:Morse code script or Category:Morse script. So, we can do the same for other scripts if we want. --Daniel Carrero (talk) 03:14, 2 May 2017 (UTC)

The use of an incorrect parameter name (|script= rather than |sc=) in the Translingual entry for ɓ caused it to be categorized under Cat:Unspecified script characters rather than Cat:Latin script characters. I've fixed that by adding the incorrect parameter to Module:mul-letter as an alternative. Probably should fix the parameter and then remove the alternative. — Eru·tuon 09:10, 11 May 2017 (UTC)

A case for Module:parameters maybe? —CodeCat 13:20, 11 May 2017 (UTC)
@CodeCat: Yeah, that would be a good idea, though after I do an AWB run to change |script= to |sc=. — Eru·tuon 16:53, 11 May 2017 (UTC)
Gah, there are so many cases of {{mul-letter}} that I don't want to do this with AWB. — Eru·tuon 01:00, 12 May 2017 (UTC)

May 2017

Category:langrev subtemplatesEdit

This category contains 8,085 templates, all of which need to be deleted. Can this be done by bot? — I.S.M.E.T.A. 00:50, 2 May 2017 (UTC)

I can do this, but I want to make sure there's consensus for this before doing something major like this. Any objections? Benwing2 (talk) 03:39, 2 May 2017 (UTC)
Where on earth are those templates used? It seems they convert language name to code, which can be done with Module:languages/templates instead. — Eru·tuon 03:46, 2 May 2017 (UTC)
@Benwing2, Erutuon, CodeCat: They can't be deleted because MediaWiki:Gadget-TranslationAdder.js still relies on them, and CodeCat (who marked them for deletion) refused to fix it. —Μετάknowledgediscuss/deeds 04:09, 2 May 2017 (UTC)
CodeCat can't fix this. Only administrators can edit js pages. --Giorgi Eufshi (talk) 05:27, 2 May 2017 (UTC)
She can fix this. If she (or anyone else) wrote out exactly what needed to be changed and pinged me, I'd make the edit. —Μετάknowledgediscuss/deeds 05:29, 2 May 2017 (UTC)
@CodeCat, do you care to explain here the necessary changes that need to be made to MediaWiki:Gadget-TranslationAdder.js in order to obsolete the members of Category:langrev subtemplates completely? — I.S.M.E.T.A. 11:02, 2 May 2017 (UTC)

{{cardinalbox}} should classify into Category:LANG cardinal numbers, and same for {{ordinalbox}}Edit

Any objection if I make these changes? Benwing2 (talk) 02:23, 2 May 2017 (UTC)

The only objection is that we shouldn't rely on the boxes to provide these categories. For languages for which no one has added these boxes, the numbers should still be properly categorized with the headword templates and such. --WikiTiki89 21:25, 2 May 2017 (UTC)

Sauraseni Prakrit transliterationEdit

When I link to a word in Sauraseni Prakrit (psu) written in Devanagari (according to Module:languages/data3/p the only script for this language) with a template like {{l}} or {{m}}, the transliteration comes out in Devanagari as well, which seems counterproductive (e.g. वेदस (वेदस)). Either we should automatically transliterate the Devanagari into the Latin alphabet, or we shouldn't transliterate it at all. But "transliterating" it into the exact same script can't be right. —Aɴɢʀ (talk) 14:06, 2 May 2017 (UTC)

I think the problem is that it invokes Module:Brah-translit as if it were using Brahmi script, when it should (if it is written in Deva) invoke Module:Deva-Latn-translit. Any character that is not recognized by a transliteration module is "transliterated" as itself. ... But having made that change, I see that the instance above now produces a module error, so I undid my edit. - -sche (discuss) 17:21, 2 May 2017 (UTC)
Module:Deva-Latn-translit seems to transliterate from Latin to Devanagari or other scripts. Hindi and Sanskrit each have their own transliteration modules: Module:sa-translit and Module:hi-translit. I suppose Sauraseni Prakrit will have to have a transliteration module created for it. — Eru·tuon 19:50, 2 May 2017 (UTC)
Or at the very least, edit some module so that no transliteration appears at all, as already happens for other Devanagari-script languages like Awadhi and Bhojpuri: {{l|awa|वेदस}} and {{l|bho|वेदस}} simply surface without transliteration, and that would be preferable for Sauraseni rather than this ridiculous "transliteration" into itself. —Aɴɢʀ (talk) 21:19, 2 May 2017 (UTC)
Yeah, I think interlingual script translit modules should check the script before transliterating (and return nil if it's the wrong script). --WikiTiki89 21:24, 2 May 2017 (UTC)
It's quite bizarre that Module:Brah-translit was added as the transliteration module for psu, since the only script listed is Deva. So, I removed the transliteration module from the language data file. — Eru·tuon 21:30, 2 May 2017 (UTC)
I also made Module:Brah-translit return nil if the script code isn't Brah. Not necessary to solve this problem, but probably a good idea anyway. — Eru·tuon 22:31, 2 May 2017 (UTC)

Automatic interlanguage linksEdit

So we have automatic interlanguage links now. I don't know where this is coordinated, but it apparently isn't working for entries containing certain non-ASCII characters. When I tried removing the interlanguage links from mało, łopata, and Sigolène, they vanished. The same problem is occurring in some other languages as well, but not all: cy:łopata is showing the links (although they've been removed from the page by bot), but pl:łopata has no links showing. —Aɴɢʀ (talk) 20:08, 3 May 2017 (UTC)

This has been discussed at length in the BP (see WT:Beer parlour/2017/April#Cognate & automatic interlanguage links for one discussion of it) and I posted it in WT:N4E. Anyway, this looks like a bug, so I'm summoning @Lea Lacroix (WMDE) to explain. —Μετάknowledgediscuss/deeds 20:11, 3 May 2017 (UTC)
The Cognate extension has been discussed at length and announced at N4E, but the problem that it works on some pages and not on others has AFAICT not been discussed yet anywhere. —Aɴɢʀ (talk) 20:30, 3 May 2017 (UTC)
I know, which is why I pinged someone who can address it. My links were in response to your statement "I don't know where this is coordinated". —Μετάknowledgediscuss/deeds 23:07, 3 May 2017 (UTC)
Is it only some articles for which it doesn't work, or did it all work yesterday but is all broken now? LA2 (talk) 23:10, 3 May 2017 (UTC)
Currently it is broken at all: phab:T164407. --Vriullop (talk) 06:13, 4 May 2017 (UTC)

Thanks for your messages. Indeed, if you find some bugs or other things that Cognate doesn't do correctly, you can ping me and I'll transmit it to the developers. I created a ticket with the examples you mentioned.

Right now, like Vriullop mentioned, a problem occurs with the extension. We try to solve it as soon as possible, thanks for your understanding. Lea Lacroix (WMDE) (talk) 07:47, 4 May 2017 (UTC)

Broken script and links in new request categoriesEdit

None of the request categories have links that point to the appropriate language section anymore. They are also no longer formatted with the appropriate script. This was still done when they were implemented by {{poscatboiler}}. —CodeCat 20:51, 3 May 2017 (UTC)

I've added the catfix. It currently adds language attributes, but not script classes. — Eru·tuon 21:05, 3 May 2017 (UTC)
Translation request categories should point to #English. DTLHS (talk) 01:58, 4 May 2017 (UTC)
Okay, I've made that category use an English catfix. If there are other categories like that, it can be done the same way. — Eru·tuon 02:19, 4 May 2017 (UTC)

Cognate Extension Malfunctioning?Edit

Is the Cognate extension really malfunctioning? Or is something else happening? --Lo Ximiendo (talk) 16:40, 4 May 2017 (UTC)

Apparently they have made quite a mess of it. See phab:T164407, mentioned two sections up. —Μετάknowledgediscuss/deeds 16:46, 4 May 2017 (UTC)
I think it can be attributed to the strain of introducing a major new extension at the same time they've been doing major work connected to the new backup-server location. With all that going on at the same time, it's a wonder that WMF's already-overextended technical staff hasn't completely lost it... Chuck Entz (talk) 02:15, 5 May 2017 (UTC)

Listing scripts for etymology languagesEdit

Now that we are using etymology language codes not only in {{etyl}} but also in templates like {{der}} and {{desc}} which take a term, we should list scripts for these languages in Module:etymology languages/data as well. In particular, I wanted to add Zzzz, Mani, Syrc to sog-bud, sog-man, and sog-chr, but I guess there won't be a difference since our modules are developed in a way to fetch data from Module:languages/data2 (etc.) only. --Z 07:55, 5 May 2017 (UTC)

@ZxxZxxZ: It probably wouldn't hurt to add script codes to Module:etymology languages/data, since Module:etymology languages will probably just ignore them. But I can only imagine them being useful if the etymology language uses a subset of the scripts used by its parent language. In that case, they could be used to provide an error message if the script supplied to the template is not used for that etymology language, even if it is used for other varieties of the parent language. I can't think of examples where that would be needed, but perhaps there are some. — Eru·tuon 08:56, 5 May 2017 (UTC)

Make Template:place categorise free countiesEdit

@Daniel Carrero, Ungoliant MMDCCLXIV Middle Dutch hollant is a county that doesn't belong to a larger entity. Countries as such didn't exist yet, and the status of various polities as county, duchy, bishopric and such is largely arbitrary and probably not worth subcategorising. So I made brabant, a duchy, categorise in Category:dum:Polities. Can hollant be also made to categorise in that? I was able to add a new place type (duchy) but since county is already used by existing entries, I don't know how to do it. A thorough documentation of Module:place/data would certainly be appreciated for future reference! —CodeCat 20:57, 5 May 2017 (UTC)

  Done. The documentation for editing the data module is at Template:place/documentation, as I felt it better to keep documentation in a single page at the time. — Ungoliant (falai) 21:04, 5 May 2017 (UTC)

Help needed at is.wiktEdit

We have got a slight issue at the Icelandic Wiktionary. If anyone from here could help us, that would be very much appreciated.

As one can read at this discussion, some pages have some kind of wiki code on top of the page and we have no idea how to fix this... Does anyone know what is wrong here? --Ooswesthoesbes (talk) 13:52, 6 May 2017 (UTC)

@Ooswesthoesbes, is:frakki looks just what it should look like. What's the problem? . There really is HTML as text when I log out. --Dixtosa (talk) 15:19, 6 May 2017 (UTC)
I see it too, even when logged in: <img src="//" alt="" style="width: 25px; height: 20px;" />. A quick guess is that perhaps the person who translated the banner at the top of the page that links to [4] into Icelandic may have messed something up in the code for it. I suggest leaving a post at meta:Meta:Babel asking them to check that everything is alright on their end. Or perhaps a recent change to some is.wikt site-wide .js or .css has done it? - -sche (discuss) 17:10, 6 May 2017 (UTC)

It is fixed now. Thank you for your help! :) --Ooswesthoesbes (talk) 11:01, 11 May 2017 (UTC)

No worries. It was probably caused by a wiki-volcano or something. --Celui qui crée ébauches de football anglais (talk) 11:10, 11 May 2017 (UTC)

Display of vertically written languages (Mongolian, Manchu)Edit

Is it possible to convert a space in terms of these languages to a new line character (while keeping the transliteration unchanged), when they are generated by the link templates?

i.e. on 松花江 (Sōnghuā Jiāng), the code

{{m|mnc|ᠰᡠᠩᡤᠠᡵᡳ ᠪᡳᡵᠠ||Milky Way}}

should generate:

(sunggari bira, Milky Way),

instead of the current

(sunggari bira, Milky Way).

(These languages are written from left to right.)

Thanks! Wyang (talk) 10:24, 7 May 2017 (UTC)

I'll look into it. It should be possible. — Eru·tuon 23:10, 7 May 2017 (UTC)
I've made the change, and it appears to work! Let me know if there are any problems. — Eru·tuon 23:23, 7 May 2017 (UTC)
One problem: it will only transform spacing characters into <br> tags when the space is inside a link. Any spaces outside a link will not be converted to newlines. For instance, {{m|mnc|[[ᠰᡠᠩᡤᠠᡵᡳ]] [[ᠪᡳᡵᠠ]]||Milky Way}} displays as ᠰᡠᠩᡤᠠᡵᡳ
(sunggari bira, Milky Way). There may be a way to fix this. — Eru·tuon 23:27, 7 May 2017 (UTC)
@Erutuon Excellent, thank you! Wyang (talk) 06:26, 8 May 2017 (UTC)
@Wyang: Fixed the problem that I mentioned above. — Eru·tuon 06:34, 8 May 2017 (UTC)
@Erutuon Thanks. One correction is needed though: The character ‹᠎› (U+180E, MONGOLIAN VOWEL SEPARATOR) should not be converted to a line break. An example is at тарвага (tarvaga); ᠲᠠᠷᠪᠠᠭ᠎ᠠ is currently displayed as ᠲᠠᠷᠪᠠᠭ᠎ᠠ (tarbaɣ-a). Wyang (talk) 12:40, 8 May 2017 (UTC)
@Wyang: Ahh, okay. I've now made it so that the function only converts plain spaces (U+20), not other spacing characters. — Eru·tuon 12:52, 8 May 2017 (UTC)
Very nice! Other ideas:
In ᠭᠠᠩᠰᠠ, the first instance of "ᠭᠠᠩᠰᠠ", above the language header displays horizontally, while the headword line displays vertically. I know we can italicize particular pages' titles (see w:Template:Italic title), can we cause these pages' titles to display vertically?
Also at ᠭᠠᠩᠰᠠ, it might be a more economical use of space to display the usexes side-by-side (perhaps in box elements?) instead of one after the other; can/should this be done? Ideally, the boxes would "break" onto new lines/rows based on screen width, or at least the current display would be preserved on the mobile version of the site.
Alternatively, perhaps {{usex}} (or a script-specific template) could take usexes of Mongolian-script and either link each individual word with a "black link" (a link that looks like regular text, as used in e.g. some inflection tables), or else somehow subject them to Erutuon's excellent line-breaking feature without linking anything, to reduce the amount of vertical space the usexes take up.
- -sche (discuss) 06:55, 8 May 2017 (UTC)
@-sche: I think the code that makes Mongolian script display vertically is found in MediaWiki:Common.css:
.Mong {
	-webkit-writing-mode: vertical-lr;
	-moz-writing-mode: vertical-lr;
	writing-mode: vertical-lr;
	layout-flow: vertical-ideographic;
As the class Mong isn't applied to the heading at the top of the entry ᠭᠠᠩᠰᠠ (ɣangsa), the heading displays horizontally instead of vertically. {{DISPLAYTITLE:}} or a JavaScript function can be used to apply the class to the article title (see this edit, for instance). JavaScript would require less editing than {{DISPLAYTITLE:}}, but {{DISPLAYTITLE:}} would work even for readers who don't have JavaScript enabled. — Eru·tuon 08:33, 8 May 2017 (UTC)
Moving the newline-adding code to Module:script utilities would make it apply to usage examples as well as links. I should probably do that. — Eru·tuon 08:36, 8 May 2017 (UTC)
It seems to be possible to obtain verticalization even by transcluding a template that includes {{DISPLAYTITLE:{{lang|mn|{{PAGENAME}}|sc=Mong}}}}. Would it be feasible and desirable to edit the headword-line templates of languages that use Mongolian script to use such an approach (perhaps different templates could be used on Mongolian- vs Cyrillic- pages, or one template could be smart enough to only apply DISPLAYTITLE on Mongolian-script pages), so that rather than separately spelling out {{DISPLAYTITLE:}} on every page, merely adding a standard headword-line template would verticalize the page title? - -sche (discuss) 09:01, 8 May 2017 (UTC)
Hmm, that's an interesting idea. I wonder if a Lua module can use the {{DISPLAYTITLE:}} magic word (or if it can correctly expand a template that contains that magic word). If it can, the headword module could certainly do what you suggest. That would also be nice, though perhaps less important, in entries using other scripts. For instance, it would be great if Ancient Greek entries could apply the class polytonic to the title, though in some cases the Modern Greek entry would be found on the same page, and Modern Greek uses the class Grek instead. — Eru·tuon 09:58, 8 May 2017 (UTC)
It works with Lua, tested in sandbox: Special:Permalink/42835570. --Vriullop (talk) 11:37, 8 May 2017 (UTC)
For line breaks in each word, it works adding display:table-caption in class Mong: Special:Permalink/42835630. --Vriullop (talk) 12:07, 8 May 2017 (UTC)
@Vriullop: I copied your Lua code to Module:User:Erutuon/Mongolian and am testing it at User:Erutuon/ᠭᠠᠩᠰᠠ, but it doesn't seem to be working. In preview mode, it gives the message Warning: Display title "<span class="Mong">Erutuon/ᠭᠠᠩᠰᠠ</span>" was ignored since it is not equivalent to the page's actual title. Rather odd. — Eru·tuon 12:33, 8 May 2017 (UTC)
@Erutuon: It misses the namespace, "Erutuon/ᠭᠠᠩᠰᠠ" is not equivalent to "User:Erutuon/ᠭᠠᠩᠰᠠ". It works on page ᠭᠠᠩᠰᠠ. --Vriullop (talk) 12:42, 8 May 2017 (UTC)
@Vriullop: I see! I changed my code to include the namespace, and now it works. — Eru·tuon 12:55, 8 May 2017 (UTC)
@Vriullop: I find display: table-caption; causes the quotations in ᠭᠠᠩᠰᠠ (ɣangsa) to overlap, and the headword to overlap the bullet that is after it. See the screenshot to the right.
Screenshot of the entry ᠭᠠᠩᠰᠠ on the English Wiktionary, with display: table-caption; applied to the class Mong (for Mongolian script) in my common.css.
Eru·tuon 13:04, 8 May 2017 (UTC)

Thanks to @Vriullop, I tried again and figured out how to make the display title thing work. So the top header in ᠭᠠᠩᠰᠠ (ɣangsa) and other Mongolian-script entries will now have the class Mong and will display vertically. The same can perhaps be done with other scripts. — Eru·tuon 13:26, 8 May 2017 (UTC)

I moved the newline-adding code to Module:script utilities, so now it is applied to the usage examples in ᠭᠠᠩᠰᠠ (ɣangsa). — Eru·tuon 13:45, 8 May 2017 (UTC)

Very cool!
I notice that the entries in Category:Manchu lemmas are vertical (and remain so even when I add testentry to the category, which itself becomes vertical), whereas Mongolian-script entries in Category:Mongolian adjectives are horizontal (probably so that the more numerous Cyrillic entries display correctly?). I suppose there's no way around that.
- -sche (discuss) 17:59, 8 May 2017 (UTC)
What does this newline conversion code do when it encounters spaces in code, like say in a HTML tag or Wikimarkup? —CodeCat 18:05, 8 May 2017 (UTC)
Well, {{usex|cmg|ᠮᠥ<a href{{=}}"">ᠰ</a>ᠦᠨ|ice}} results in the "<a href="">" being broken at the space and displayed as text (see here), but under what circumstances would such a thing occur validly? I had to use {{=}} just to make that "work" (i.e. not just resolve to a Lua "parameter not used" error). (If there are valid usecases, perhaps we could add a switch by which users could suppress space-to-newline conversion in individual instances?) If the concern is that it might sometimes be necessary to call a template that includes a space in its name inside a {{usex}} or the like (as in this contrived example), that could be solved by having a redirect to the template from an unspaced name. - -sche (discuss) 19:54, 8 May 2017 (UTC)
The code I've written assumes that the text being script- and language-tagged only contains wikilinks, nothing else. I'm not satisfied with it, because it's overly verbose. And it should be able to find and ignore anything that should not be transformed (HTML tags, the target part of wikilinks) and then just replace spaces in the rest. That would be much simpler. I'm trying to figure out how to do that. — Eru·tuon 22:17, 8 May 2017 (UTC)
Done. Anything that should not have its spaces transformed (currently, wikilink targets and HTML tags) is escaped before the replacement, then unescaped. — Eru·tuon 22:50, 8 May 2017 (UTC)
This is very cool. Thank you! Wyang (talk) 01:31, 10 May 2017 (UTC)

Category interwiki linkingEdit

It's good that our articles nowadays automatically get interwiki (inter-language) links. But our semantic categories still need manual linking (right?), the way it used to be in Wikipedia. So, once I found out that Category:Hormones should link to ru:Категория:Гормоны and sv:Kategori:Hormoner, is there some tool (on the WMF toolserver) that helps me in interwiki linking all the subcategories such as Category:en:Hormones to their counterparts in the other languages? --LA2 (talk) 21:25, 7 May 2017 (UTC)

That's supposedly the next step that will happen at Wikidata. —Μετάknowledgediscuss/deeds 21:32, 7 May 2017 (UTC)

{{desctree}} changesEdit

I'm working on some changes to {{desctree}} in {{desctree2}}, which I outlined here. I'm trying to logic out how to deal with the alternative forms. I could employ some method using |altN=, but I would prefer it if I could use * {{desctree|goh|apful}} {{l|goh|aphul}}, ... and have the imported list of descendants start on the next line. Is there some way to do this in Lua, like table.insert(arr, currentline+1)? --Victar (talk) 04:37, 8 May 2017 (UTC)

@Victar: I don't think that's possible. A Lua-based template can only insert content at the position where you put it in the text. — Eru·tuon 04:39, 8 May 2017 (UTC)
@Erutuon: Drat. What about getting the current line, surrounding the template? --Victar (talk) 04:59, 8 May 2017 (UTC)
@Victar: The module might be able to grab the content from the {{l}} after the {{desctree}}, but I'm not aware of any way in which it could delete the content of that {{l}}. So, you would still have the alternative form aphul repeated after the descendant tree. — Eru·tuon 05:54, 8 May 2017 (UTC)

Apply a font to cuneiform page titlesEdit

Erutuon, with some help from Vriullop and me, excellently found a way to apply a class to the page titles of Mongolian-script pages so that they display correctly. Can we similarly apply a class to the pagetitles of cuneiform pages, so that they are rendered in the same font as they are when they are linked (𒋼), rather than the default font they are currently rendered in, which displays them as boxes (for me)? More generally, we could perhaps apply classes and hence relevant fonts to many non-Latin scripts which might otherwise display as boxes. - -sche (discuss) 19:39, 8 May 2017 (UTC)

You can add script-tagging to the title for any scripts you want, by adding the script code to the to_be_tagged table near the top of Module:headword. — Eru·tuon 01:27, 10 May 2017 (UTC)
(I've moved the list of scripts to Module:headword/data.) — Eru·tuon 01:33, 10 May 2017 (UTC)
Huh, all the Cuneiform titles show up for me without tofu. —Aryamanarora (मुझसे बात करो) 19:45, 10 May 2017 (UTC)
You mean they do now, or they always did? I think that whether or not they display without script-tagging depends to some extent on whether a user already has a font installed that can display them, and on how recent their operating system and browser are. Script-tagging them helps them display for more people. - -sche (discuss) 00:46, 11 May 2017 (UTC)
How "expensive" is this script-tagging of page titles? Do we know? If it's "inexpensive", perhaps tagging most non-Latin scripts would be appropriate. - -sche (discuss) 00:46, 11 May 2017 (UTC)
I doubt it's very expensive. The script code is already present in Module:headword, and it is quite quick to look it up in the table of to-be-tagged scripts. — Eru·tuon 01:22, 11 May 2017 (UTC)
Something to consider: the software disallows overriding the display title more than once. I believe the second attempt results in an error. That means that any entry with more than one headword line will break. —CodeCat 00:59, 11 May 2017 (UTC)
I don't think it does cause an error. I have added tagging for polytonic, and that would probably make the display title function be called twice in a page such as ὅς (hós), yet there's no error there. — Eru·tuon 01:25, 11 May 2017 (UTC)
Yes, 𒈗 has a number of language sections, each with their own headword line, and also does not seem to suffer an error. - -sche (discuss) 01:28, 11 May 2017 (UTC)
However, if I tried to add tagging for Grek along with polytonic, on a page like λόγος (lógos) that has an entry for Modern Greek as well as Ancient, I suspect the <span class="Grek"></span> added by the Greek headword template would override the <span class="polytonic"></span> added by the Ancient Greek one, because the alphabetization makes it be the last on the page. It seems the last display title on the page is what is actually used. I tested this by adding {{DISPLAYTITLE:ὅς}} on ὅς (hós): if I place this DISPLAYTITLE parser function at the top, it's overrided by the polytonic-class display title added by the headword template; if I place it at the bottom, it overrides the headword template. So, the last DISPLAYTITLE on the page is the one that wins out, but there is no error. — Eru·tuon 01:33, 11 May 2017 (UTC)
Oops! There is an error, at the bottom of the page, in preview mode at least: Warning: Display title "ὅς" overrides earlier display title "<span class="polytonic">ὅς</span>". When the display titles added by subsequent headwords are identical, there seems to be no such message. — Eru·tuon 01:43, 11 May 2017 (UTC)


This template continually miscategorizes ‘mf’ nouns as having no plural, which is patently false. Please fix this, it’s very annoying. — (((Romanophile))) (contributions) 02:38, 10 May 2017 (UTC)

@Romanophile: I think what "missing plurals" means is that there is currently no entry for the plural. Module:fr-headword, which is used by {{fr-noun}}, checks to see if the entry title for each plural form exists. Feminine nouns without entries for their plurals are also put in this category: see accessoirisation. — Eru·tuon 02:58, 10 May 2017 (UTC)
Indeed. And the only reason you see it is because you've opted to see hidden categories in your prefs. —Μετάknowledgediscuss/deeds 04:42, 10 May 2017 (UTC)

spelling templatesEdit

The current spelling templates produce confusing and misleading entries, at least the one for American spelling. Now almost all users interpret demonize, for example, as saying that its meanings are American, not its spelling (which isn't even true). --Espoo (talk) 07:03, 10 May 2017 (UTC)

I'd thought the spelling e instead of ae might be not in use in UK English, but it seems we have editors who don't even know the basics of UK spelling and think that -ize is not also UK. Is there a bot that can find and fix this kind of nonsense? --Espoo (talk) 07:13, 10 May 2017 (UTC)

RegEx flags in addToToolbarEdit

Hey, how can I add regex flags, like global, to my addToToolbar function? Thanks for any help! --Victar (talk) 17:40, 10 May 2017 (UTC)

That's done by putting g after the slashes of the regex: /\b.*\:\s*\{\{l\|(.*)\|(.*)\b\}\}/g. — Eru·tuon 19:11, 10 May 2017 (UTC)
So weird! It wasn't working for me before. Thanks. --Victar (talk) 19:41, 10 May 2017 (UTC)
Does it work? I thought the curly braces had to be escaped ({}\{\}), as they're used in quantifiers. — Eru·tuon 19:49, 10 May 2017 (UTC)
Sorta! =P Now that global is working, I'll try make it better. --Victar (talk) 19:57, 10 May 2017 (UTC)
@Erutuon: There we go! Thanks again. Feel free to steal. --Victar (talk) 20:27, 10 May 2017 (UTC)

@Erutuon I'm trying to use callback instead, but I can't seem to get it to work. Could you take a peek and see what I'm doing wrong? --Victar (talk) 02:35, 11 May 2017 (UTC)

@Victar: I'm sort of a newbie with JavaScript, but perhaps it's not working because you only escaped the first curly bracket in each group? Each one should be individually escaped. — Eru·tuon 03:02, 11 May 2017 (UTC)
Ohh, the regex shouldn't be enclosed in quotes either. /\b.*\:\s*\{\{l\|([^\}]*)\}\}/gEru·tuon 03:03, 11 May 2017 (UTC)
Good eye, but still no luck. --Victar (talk) 03:10, 11 May 2017 (UTC)
I copied your code to my common.js and correctly escaped the brackets, but it still doesn't add anything to the toolbar while I'm in editing mode. — Eru·tuon 03:33, 11 May 2017 (UTC)
You might have better luck trying to use TemplateScript. That's what I use to create my customized regex tools. — Eru·tuon 03:34, 11 May 2017 (UTC)
Oh!! I see it's being added to the edit toolbar. Duh! But it's not working... — Eru·tuon 03:41, 11 May 2017 (UTC)
The instructions for adding your own toolbar button that uses a JavaScript function leave me at sea as to just how the callable function is supposed to work. — Eru·tuon 03:54, 11 May 2017 (UTC)
@Erutuon: Yeah, the documentation really sucks. Thanks for looking into it. I just reverted it back to my original version so I can at least use it for now. --Victar (talk) 04:17, 11 May 2017 (UTC)

Show-and-hide templates not working properlyEdit

The templates in the "derived terms" and "translations" sections of our entries ({{trans-}} and {{rel-}}) are not working anymore. They normally have a button to show and hide the content inside them, but this button apparently disappeared, making the templates nonfunctional. I've tried different browsers and computers and still get the same problem. What is the matter? - Alumnum (talk) 04:06, 11 May 2017 (UTC)

Whatever this is also breaks tabbed languages. DTLHS (talk) 04:12, 11 May 2017 (UTC)
Additionally with Chrome (but not Netscape or Edge) I have a long blank space between the bottom line and the category section - but only when there is a pull down table (like inflections) present. — Saltmarsh. 04:46, 11 May 2017 (UTC)
It seems to work when I log out. DTLHS (talk) 05:16, 11 May 2017 (UTC)
Really? Not for me. What browser and OS? --Espoo (talk) 08:09, 11 May 2017 (UTC)
I also can't see the quotations I just added when creating the entry κᾰτήγορος (katḗgoros). They just entirely vanish. (Another thread on a similar topic: Wiktionary:Beer parlour/2017/May § cannot open translation boxes.) — Eru·tuon 05:19, 11 May 2017 (UTC)
Using Chrome logging out make the long blank space (see above) disappear, by the show/hide problem is still there — Saltmarsh. 05:22, 11 May 2017 (UTC)
I just added a quote to Kennebec, the only way to display it is by taking out * DonnanZ (talk) 14:20, 11 May 2017 (UTC)

I have filed - -sche (discuss) 08:24, 11 May 2017 (UTC)

Compare the earlier issue described at Wiktionary:Grease pit/2017/April#Show_translations. - -sche (discuss) 08:29, 11 May 2017 (UTC)
Yup, all quotations are no longer visible, and the "Show translations" and "Show quotations" links on the left side of the screen are gone. Quiet Quentin also no longer appears. — SMUconlaw (talk) 08:48, 11 May 2017 (UTC)
Today I had the same problem on ca.wikt. My web console says, among other weird stuff: 'Gadget "LegacyScripts" styles loaded twice. Migrate to type=general. See <>.' Fixing it on gadgets definition has solved the issue. --Vriullop (talk) 08:54, 11 May 2017 (UTC)
Any administrator around? I am pretty sure all the problems reported today are solved fixing MediaWiki:Gadgets-definition. Add type=general in ResourceLoader definition of gadgets loading both js and css: LegacyScripts, TabbedLanguages, DocTabs, DefSideBoxes, aWa, and QQ, as explained at mw:ResourceLoader/Migration_guide_(users)#Gadget_type. --Vriullop (talk) 14:07, 11 May 2017 (UTC)
@Vriullop I have added type=general to the scripts. Tabbed languages appears to still be broken. DTLHS (talk) 15:18, 11 May 2017 (UTC)
But collapsible tables are working again, so that's good. —Aɴɢʀ (talk) 15:20, 11 May 2017 (UTC)
Not loading LegacyScripts was provoking a cascade of errors in unexpected places. Once fixed, the problem with TabbedLanguages is beyond my understanding, but obviously they are related and provoked by last version of Mediawiki installed last UTC night. --Vriullop (talk) 15:57, 11 May 2017 (UTC)

Help, declension tables no longer are openableEdit

I think this applies to all collapsible tables. I see it e.g. on the page любимица, where the declension table is missing the button to open it. User:JohnC5 noted something similar in the April Grease Pit. I don't have any Javascript, and I don't even know what skin I have. (How does one switch skins?) I tried this on Chrome and Safari (on Mac OS 10.9.5), same thing. It even happens when I log out. Any ideas? Benwing2 (talk) 05:58, 11 May 2017 (UTC)

OK, I think the above thing about show-and-hide templates is the same. Benwing2 (talk) 06:01, 11 May 2017 (UTC)
Can someone file an urgent phabricator bug about this? Maybe User:Daniel Carrero, who knows how to do this? Benwing2 (talk) 06:02, 11 May 2017 (UTC)
Is the JavaScript function that handles this collapsible content a local Wiktionary thing or a global MediaWiki feature? — Eru·tuon 06:06, 11 May 2017 (UTC)
So, I believe all the code for this is housed at MediaWiki:Gadget-legacy.js, but nothing has changed recently to cause these problems. —JohnC5 07:38, 11 May 2017 (UTC)
I have filed Let me know if I should add anything to the report, or comment on it yourself! - -sche (discuss) 08:24, 11 May 2017 (UTC)

translation drop-down function broken?Edit

Is it my phablet or is there a bigger problem? I restarted the phablet, but nothing happens when i click on a translation box in Android Chrome and Firefox. It worked yesterday. --Espoo (talk) 07:40, 11 May 2017 (UTC)

Same problem here, I can't get it to work with any browser and it worked fine yesterday. --Bricklayer (talk) 07:52, 11 May 2017 (UTC)
Just discovered that all other drop-down boxes are broken too, f.ex. conjugations. Also discovered it's only broken in desktop view, not mobile -- both on phablet. Will now test on laptop. --Espoo (talk) 07:58, 11 May 2017 (UTC)

I have filed - -sche (discuss) 08:24, 11 May 2017 (UTC)

Translation js drop downs stopped workingEdit

Checked with 3 browsers. Arrows do not appear, nor selected language translations. When inspecting pages I can see:

Gadget "LegacyScripts" styles loaded twice. Migrate to type=general. Gadget "DocTabs" styles loaded twice. Migrate to type=general. <>. VM60:243 This page is using the deprecated ResourceLoader module "es5-shim". Use of the "es5-shim" module is deprecated since MediaWiki 1.29.0--Spiros71 (talk) 09:38, 11 May 2017 (UTC)

Thank you, this is informative. Vriullop describes the same message on ca.Wikt, and a fix which could be tried. I wonder what caused the gadgets to break / to 9apparently) need |type=general] to be declared... - -sche (discuss) 09:51, 11 May 2017 (UTC)

NEC is not working either. DonnanZ (talk) 10:10, 11 May 2017 (UTC)

Tabbed languagesEdit

Tabbed languages also broke, which makes Wiktionary completely unnavigable. —CodeCat 12:36, 11 May 2017 (UTC)

I've turned my tabbed languages off, which helps. —Aɴɢʀ (talk) 14:13, 11 May 2017 (UTC)
Apparently there is a general issue where "Gadgets that use both scripts and styles, but do not specify type=general, are never loaded (JS file not loaded but CSS file is)" (per a report on Phabricator). But type=general appears to have been set for TabbedLanguages in this diff; does the problem persist? - -sche (discuss) 19:02, 11 May 2017 (UTC)
PS, Aklapper mentions on Phabricator that "on an unrelated note, is broken (link is undefined". - -sche (discuss) 19:06, 11 May 2017 (UTC)
This was one of the collateral effects by LegacyScript not loading. Once fixed, this error message does not appear any more and purgetab is working fine. But the problem with TabbedLanguages persists. --Vriullop (talk) 20:21, 11 May 2017 (UTC)

CSS classes for transliterationsEdit

It would be beneficial to have CSS classes for transliterations. Many transliteration systems use characters that will not display well in all fonts. With predictable classes, fonts could be specified in MediaWiki:Common.css to ensure they display well. Or users can set whatever fonts they like in their common.css. I've wanted to do the latter. Or users can write JavaScript functions that convert one transliteration system to another, allowing people to see whatever transliteration system they prefer.

Currently, all transliterations are tagged with class="tr", if generated by {{l}}, or with class="tr mention-tr", if generated by {{m}}. So, there is no way to distinguish between transliterations of different languages when using JavaScript, and absolutely no way when using CSS. They are all identical.

I was thinking the class names could be tr- plus the language code. Then, the transliteration class for Ancient Greek (language code grc) would be tr-grc. That would be following the tradition of using |tr= for transliteration, and of using the class tr to mark transliterations in general. Or perhaps translit- plus the language code could be used instead (translit-grc). Or the order could be reversed (grc-tr or grc-translit). This reversed order would resemble a language code combined with script code (fa-Arab), though translit isn't a script. Not sure which of these ideas is best.

These class names would be added on to the default ones: thus, the class for an Ancient Greek transliteration in the {{m}} template would be class="tr mention-tr tr-grc". So, no existing functionality would be broken.

This idea is perhaps not absolutely necessary, but it would allow for easier customization of transliterations with CSS and JavaScript. — Eru·tuon 05:49, 11 May 2017 (UTC)

I don't think this is necessary, as it is possible with CSS selectors to style by language (e.g. .tr:lang(grc)). This was added in CSS2 and has wide support. – Krun (talk) 11:28, 11 May 2017 (UTC)
@Krun: But at the moment there's no language attribute (lang="grc") added to a language's transliteration, so that selector wouldn't work. For instance, in the headword of ἀρχιμανδρῑ́της (arkhimandrī́tēs), the transliteration is coded as follows: <span class="tr" lang="" xml:lang=""><span class="tr" lang="" dir="ltr" xml:lang="">arkhimandrī́tēs</span></span>. This can only be selected with .tr or :dir(ltr). Perhaps Module:links (which currently handles transliterations) should add the language attribute to the transliteration. This would be fine since MediaWiki:Common.css currently doesn't use language codes alone to set fonts (if it did, adding language attributes to transliteration might cause the wrong fonts to be applied to transliteration). — Eru·tuon 16:43, 11 May 2017 (UTC)
On the other hand, it might cause problems for screen readers, which would try to read the transliteration because it was tagged with a language code, and would likely fail because they would only be able to read the language's native script. Hence, separate classes for each language's transliteration might be a better idea. — Eru·tuon 16:45, 11 May 2017 (UTC)
@Erutuon: Ah, I didn't realize the language code was missing. The transliteration should definitely be tagged with the relevant language code (in this case grc), as it is text in that language, whatever the script. It's definitely a problem if it isn't, because in that case it inherits the language designation of a parent/ancestor tag or the entire page, namely en, and would e.g. be read by a screen reader as text in English! When the script is different, as in this case, that can and should be indicated in the HTML (lang="grc-Latn"). – Krun (talk) 10:17, 12 May 2017 (UTC)
@Krun: Hmm. lang="grc-Latn" sounds reasonable, but what about class="(tr mention-tr )Latn" lang="grc"? Putting in Latn as a class would be more consistent with the way we usually handle scripts. — Eru·tuon 01:20, 14 May 2017 (UTC)
I've gone and done the script class and language attribute solution. Now a language's transliteration can be selected with, for instance, :lang(grc).Latn. — Eru·tuon 02:03, 14 May 2017 (UTC)

What annoys me about adding language attributes to transliterations is that my browser (Chrome) adds undesirable styling to them: for instance, full-width font to transliterations of Japanese. That is what I hope to avoid by naming the classes tr-language code. — Eru·tuon 01:52, 16 May 2017 (UTC)

I agree we have to figure out how to fix that. --WikiTiki89 15:03, 16 May 2017 (UTC)
This is also happening to me in Safari. The transliteration for Japanese, e.g. is being displayed in Hiragino rather than the basic site-wide font. I tried changing the language code on the page (using the browser inspector) to ja-Latn and that worked (i.e. that makes it use the site-wide font). I really think it's more appropriate to append the script tag in this way in every case where we are using something other than the regular script for the language, and, in any case, it seems to work styling-wise. – Krun (talk) 16:03, 17 May 2017 (UTC)
@Krun: Changes to transliteration tagging can now be done quickly and easily by editing code in Module:script utilities or Module:script utilities/data. I think I will the change you suggest; it's the most immediate solution to the problem. — Eru·tuon 22:55, 17 May 2017 (UTC)

I've added script classes and language attributes to the transliterations generated by Module:headword, Module:usex, and Module:ru-adjective as well as Module:links. It would be an improvement if a single function tagged transliterations in all modules. — Eru·tuon 02:14, 16 May 2017 (UTC)

@Justinrleung mentioned on Module talk:links § Script tags for transliterations that for him, lang="language code-Latn" still applies incorrect fonts to the transliteration. It seems his browser (Firefox) ignores the -Latn part and applies fonts based on the language code. This could be solved by replacing the language attribute with the class I suggested above: class="tr-language code". However, I tried using Firefox and didn't see the same problem. Not sure why that would be. — Eru·tuon 05:57, 19 May 2017 (UTC)

Automatic sortingEdit

Greetings. Is there any way to sort lists automatically in wiki? It would be useful as it is painstaking to sort long lists by hand (lets say without text editor). Perhaps something like this could be enabled? Another option I can think of could be the table sorting Javascript ("wikitable sortable") Anyone care to find the best way and implement it (in case we have nothing)? --Hartz (talk) 06:03, 11 May 2017 (UTC)

It is possible to make a list auto-sorted by Lua modules. However, every language is alphabetically ordered in its own way, so it must be per-language concept. The extension just globally sorts them out in one way which might not be preferable. --Octahedron80 (talk) 11:52, 11 May 2017 (UTC)

New Entry CreatorEdit

Possibly allied to the problems outlined above, NEC has been disabled. DonnanZ (talk) 11:13, 11 May 2017 (UTC)

  • Fixed now. Cheers. DonnanZ (talk) 16:23, 11 May 2017 (UTC)
  • I just tried to create a new entry and the preloaded template did not come up. SpinningSpark 17:49, 11 May 2017 (UTC)
That's odd. I just used it for Westchester County. DonnanZ (talk) 17:51, 11 May 2017 (UTC)
It also works for me. Try a w:WP:REFRESH. --Vriullop (talk) 18:03, 11 May 2017 (UTC)
Possibly I'm doing something wrong. I'm typing a new word into the search box, eg ghzz. Then I click on the "create it" link in the search results. This takes me to this page, which the url claims to be the User:Yari_rand app for new creations, but the edit box is completely blank and there is no template for selecting entry parameters. Monobook, Firefox 53.0.2, Windows 7 SP1 64bit. SpinningSpark 18:10, 11 May 2017 (UTC)
Update, it's only broken in Monobook, Vector works fine. SpinningSpark 18:13, 11 May 2017 (UTC)
Looking at this further, it seems that it is something in my own monobook.js that is breaking it. Since I haven't changed anything in my personal js recently, I guess this must be an old script-pocalypse issue. SpinningSpark 21:05, 11 May 2017 (UTC)

Translation pop-ups not opening?Edit

When I checked a word today (11 May), the translation pop-ups did not display an 'open' button. The html text of the translations is still there, if I click on 'edit', so I am assuming a technical problem of some sort. I checked a number of other words, and they are all doing the same thing. —This unsigned comment was added by 2602:302:D10C:83B0:226:8FF:FEEB:4F85 (talk) at 13:44, 11 May 2017 (UTC).

Categorise JavaScripts?Edit

Is there a way to place site-wide JS pages in a category? I think this would be useful as half the time I can't find them. —CodeCat 19:20, 11 May 2017 (UTC)

I second that. — Eru·tuon 19:29, 11 May 2017 (UTC)
Apparently, Mediawiki pages can be categorized, because some are in Category:Wiktionary scripts. We could add others. (If Mediawiki pages couldn't be categorized, the talk pages could stand in for them.) - -sche (discuss) 21:18, 11 May 2017 (UTC)
Yeah, you apparently just add documentation pages like MediaWiki:Common.js/documentation. —JohnC5 22:12, 11 May 2017 (UTC)
I'm not able to create or edit such documentation pages, which seems kind of counterproductive. Could someone else categorise all gadgets in Category:Wiktionary gadgets? —CodeCat 12:21, 13 May 2017 (UTC)
I'm putting every *.js in the Mediawiki namespace that begins with "Gadget-" in Category:Wiktionary gadgets, and every other *.js in that namespace into its parent category, Category:Wiktionary scripts, except MediaWiki:Gadgets-phantom.js which I left uncategorized because it seems to be intentionally blank. Some pages do not appear in the categories yet due to the usual issues with caching. - -sche (discuss) 17:36, 13 May 2017 (UTC)
If this is of interest to anyone, the following pages consist exclusively or almost exclusively of importing other sites' javascript:

And the following pages consist of extremely short text for disabling various things:

- -sche (discuss) 17:36, 13 May 2017 (UTC)


I created Module:translit-redirect to do the work of choosing between transliteration modules, for languages written in several different scripts. It replaces modules such as Module:pa-translit and Module:khb-translit (Punjabi and Lü), which simply redirect to another module, depending on which script is being used. The other module does the actual work of taking the native script and generating a transliteration. The redirecting code in these two modules is remarkably similar. It seems simpler to centralize all this transliteration-redirecting in one module. So far, I've made Punjabi use the redirecting module, and it appears to work. — Eru·tuon 04:04, 12 May 2017 (UTC)

Bot request: External links → Further reading Edit

Can a bot do this, please?

  • Change all instances of the heading "External links" into "Further reading".

See this diff for an example.

This action was voted and approved at Wiktionary:Votes/2017-03/"External sources", "External links", "Further information" or "Further reading". Thanks in advance. --Daniel Carrero (talk) 09:31, 12 May 2017 (UTC)

While someone is running a bot doing this, you could also check for any instances of "Future reading". I may have made that typo from time to time when renaming the sections manually. —Aɴɢʀ (talk) 09:47, 12 May 2017 (UTC)
I just grabbed the latest dump and can work on this. TheDaveBot has started running, if anyone wants to look at the changes. And I am looking for "Future reading" as well. - TheDaveRoss 15:04, 12 May 2017 (UTC)
I finished everything in NS:0 from the latest dump, there may be a few remaining. Wasn't sure if non-NS:0 pages should be updated, but I updated a few of those before I thought better of it. - [The]DaveRoss 12:41, 16 May 2017 (UTC)

Wrong Greek transliterationEdit

νηῦς (nēûs) is being transliterated with a short e, but it should be a long ē. —CodeCat 14:17, 12 May 2017 (UTC)

Also, it's being transcribed as a two-syllable word, but it's a monosyllable with a long diphthong. The 5th-century BC pronunciation should be /nɛ̂ːu̯s/, not /nɛː.ŷːs/. —Aɴɢʀ (talk) 14:56, 12 May 2017 (UTC)
Pinging @Erutuon and @JohnC5 as the people most likely to be able to help. —Aɴɢʀ (talk) 14:58, 12 May 2017 (UTC)
I've fixed the transliteration. The IPA transcription may be harder to fix. — Eru·tuon 16:30, 12 May 2017 (UTC)

Hi , Is there a tool that check loops in wiktionary definitions ?Edit

that is two terms each defined by the other. I was asked to write such a bot to the hebrew wiktionary so I better first check if such a bot exist already. —This unsigned comment was added by Shavtay (talkcontribs) at 21:07, 12 May 2017 (UTC).

I am not aware of one. It sounds useful! Please let us know if you do design one. - -sche (discuss) 04:06, 13 May 2017 (UTC)

Hi, Yes I'm thinking of writing one, you know any tools that I can use ? I know of Dbnary [5] Shavtay (talk) 12:10, 13 May 2017 (UTC)


{{calque|zh|mnc|ᠵᡠᡵᡠ ᡥᠣᡨᠣᠨ|t=two cities}} doesn't display the gloss on 雙城子双城子 (Shuāngchéngzǐ). Please help. Wyang (talk) 07:00, 13 May 2017 (UTC)

@Erutuon Something seems to have stopped working since March 25. —suzukaze (tc) 20:11, 13 May 2017 (UTC)
@Wyang, Suzukaze-c: Fixed. Problem related to parameter aliases. Thanks for pinging me. — Eru·tuon 22:23, 13 May 2017 (UTC)
@Erutuon Thanks! Wyang (talk) 02:12, 14 May 2017 (UTC)


Do we still need this? It claims "This script changes timestamps such as those in comments to be relative to the local time", but all it does is import MediaWiki:Gadget-TranslationAdder.js. (Is this a reminder that the "editor" functions need to be split out of the "translation adder", and if so, can someone do that?) Also on the subject of gadgets which seem to only load other gadgetry: MediaWiki:Gadget-WiktBlockedNotice.js. - -sche (discuss) 16:51, 13 May 2017 (UTC)


Do we still need this .js page? It consists exclusively of a note that everything should be placed on a different page instead! See also MediaWiki:Monobook.js/sv. - -sche (discuss) 17:31, 13 May 2017 (UTC)

Category:English nouns with irregular pluralsEdit

A discussion from 2010, archived on the talk page, suggests this category should be renamed, but a bigger issue IMO is that it should be generated automatically in entries that use {{en-noun}}, rather than being added manually to such entries. (Then we have to decide what is "irregular": any plural other than "s" or "es"?) - -sche (discuss) 20:03, 13 May 2017 (UTC)

I'm ok with this. I also think we should get rid of Category:English irregular plurals. —CodeCat 20:13, 13 May 2017 (UTC)
Yes, the only cases that come to mind where a plural could be in the "irregular plural" category while the singular was not in the "nouns with irregular plurals" category are cases where the plural is too nonstandard and uncommon to give in the headword of the singular, like dogz, but I wouldn't expect casual users to notice such a distinction and I'm not convinced it'd be useful. (Plus it could be argued dogz isn't even irregular, but a regular eye-dialectal change.) So I'd be OK with getting rid of Category:English irregular plurals. - -sche (discuss) 04:08, 14 May 2017 (UTC)

De-link transliterations pleaseEdit

Please see Lao entry ເງິນຕາ (ngœn tā). The transliteration is currently displayed as ngœn, which is wrong. --Anatoli T. (обсудить/вклад) 02:07, 14 May 2017 (UTC)

@Erutuon... —Μετάknowledgediscuss/deeds 02:09, 14 May 2017 (UTC)
@Atitarev, Metaknowledge: I was puzzled at first, because Module:headword removes links before generating a transliteration. The problem was in Module:lo-headword, which was unnecessarily generating an automated transliteration. Fixed. — Eru·tuon 03:37, 14 May 2017 (UTC)
Thanks! —Μετάknowledgediscuss/deeds 03:42, 14 May 2017 (UTC)

"Lua error: not enough memory" at man, tooEdit

Like water did before we split its translations onto a subpage (see GP, BP), man is now running out of memory.
I've null-edited the page several times and the error is consistently in the Swedish etymology section (whereas the error in water would move several sections up or down after null edits), but it does display a small amount of randomness: sometimes the memory runs out right at Proto-Germanic, sometimes it runs out at PIE.
I have a Phabricator report ready to file about water and man, but before I file it, are we still suspecting that individual tasks like instances of {{t}} not releasing memory after they finish is a cause? And what assistance would we want from the folks at Phabricator if they say they can't change their implementation of Lua? - -sche (discuss) 06:44, 14 May 2017 (UTC)

I don't have answers to your questions, but I changed {{t-simple}} so that it frees up a little memory, pushing the error to the Declension section for Volapük. Strangely, when I switched more translations to {{t-simple}}, it made the problem worse. — Eru·tuon 08:23, 14 May 2017 (UTC)
I think there may be some wasted memory in our language and script objects, though I'm not sure how to confirm that. Each language object contains one or more script objects. This probably results in duplication. For instance, when we have many languages in the translations list that use the Latn script, the Latin script object will be repeated inside each of those language objects. That duplication could account for part of the memory problem.
(I don't know about the whole memory-releasing thing, but I'm imagining there's a counter that tracks how much memory is used, whether or not it is released when the functions have done their work.) — Eru·tuon 08:34, 14 May 2017 (UTC)
After recent edits, the page consistently makes it as far as the Volapuk Coordinate terms section before running out of memory. Interesting that the error on this page is so much more consistent than the error on water, and that adding t-simple to this page apparently makes it worse, apparently unlike water. - -sche (discuss) 03:28, 15 May 2017 (UTC)
I don't see the same increase- I was able to decrease the memory to 45 MB with {{t-simple}}. DTLHS (talk) 03:34, 15 May 2017 (UTC)
Quite odd. The edit with the memory increase is linked above. You added {{t-simple}} to non-Latin-script terms; do we want that? — Eru·tuon 03:39, 15 May 2017 (UTC)
If that's the only way to fix it. I imagine non-Latin script languages use a lot more memory, since they require script classes and transcription. DTLHS (talk) 03:45, 15 May 2017 (UTC)
Re "able to decrease the memory": but not by adding t-simple to the same terms. In theory, adding it to Latin-script terms should either simplify things slightly or have no effect, but instead it had a bad effect (when tried).
Adding it to non-Latin-script terms is not a good fix, since it breaks script support and transliteration. We could try simplifying t-simple further to allow script to be set manually the same way it allows langnames to be set. And, of course, we could try to simplify our modules. I am revising the bug report I intend to file on Phabricator to see if folks there have suggestions. 04:49, 15 May 2017 (UTC)
I've created a light_link function in Module:links, hopefully as barebones as possible. I tested it with {{t-simple/test}} and User:Wikitiki89/water, but it doesn't free up near enough Lua memory. I guess that proves the template can't be Lua-based. — Eru·tuon 07:57, 15 May 2017 (UTC)

I kind of wish there were a function to create a "cache" of language and script objects that can be used by multiple functions. It would be similar to mw.loadData, but for tables that include functions. So, then, before calling getByCode, you could check if the language or script object has already been loaded to the cache, and use that instead. Or getByCode could check for the existence of that function. Not sure if this is possible programming-wise. mw.loadData requires the tables that it loads to be static, not containing any functions. The caching function I'm envisioning would have to allow functions to be within the tables. Perhaps it would be possible for language and script objects, because all of their variables stay the same, except for the variables supplied as arguments. Or maybe not. — Eru·tuon 16:48, 19 May 2017 (UTC)

So let's write down our options. Thing we can do:

  1. Ask for an increase of max memory.
    It is quite possible they would let us
  2. optimize every bit our of lua.
  3. write an extension. Something along the lines with mw:Extension:Transliterator
  4. Make some or all part of rendering js-based.
  5. Or similar to above - let translation tables be ajax-based (per-request/per-click)
  6. use t-simple or even simpler template while we can (and the number of problematic articles are handful) and hope something will change.

Is there anything else? --Dixtosa (talk) 19:18, 19 May 2017 (UTC)

Also the idea above, of a new Scribunto function, similar to mw.loadData, to cache language and script objects so they're not duplicated in memory on a given page. Again, not sure if it's possible. — Eru·tuon 19:25, 19 May 2017 (UTC)
Probably asking for an increase of Lua memory would be the simplest option, and it would probably suffice for quite a while. However, it would be good to pursue another option even if we get an increase in memory, to prepare for the ideal future, in which every translation table for basic words like water would contain every attested translation in every language possible (and be as full as or fuller than the water-translations are now). It's conceivable that we increase memory now, and then our pages get longer and longer, and we end up needing a further increase of memory because we haven't done anything to optimize the memory-hogging modules. — Eru·tuon 21:01, 19 May 2017 (UTC)
Any JS-based rendering needs to degrade gracefully to non-JS. Equinox 21:08, 19 May 2017 (UTC)
I filed T165935 about this. - -sche (discuss) 04:33, 21 May 2017 (UTC)
The ticket has been closed as not something they will resolve, because it quite plausibly could be our modules which are the issue. They will also not increase the amount of memory pages can use, because "at some point in the future you'll probably wind up with an even-huger page that would exceed the new limit." They note that transliteration does seem to eat up a lot of memory. Perhaps deploying t-simple even on languages that would otherwise be transliterated — possibly simplifying t-simple to not even call modules, but have the script class (needed so the correct fonts are picked) input manually — is the way to go. Perhaps translations do not absolutely need to have transliterations? Or they could be supplied manually? - -sche (discuss) 22:01, 21 May 2017 (UTC)
I find the response somewhat frustrating. @Anomie suggests that somehow our modules are being cached, but it would help to have more explanation on how that can happen and how that could cause the problem. And he does not respond to the request for help with determining which modules or functions are using so much memory. Perhaps there is another place to submit a request for help so that they will actually respond to it, but I don't really understand the Phabricator framework enough to determine where that would be.
I think inputting manual transliterations with {{subst:xlit}} would be a good idea. Of course, the transliterations would not be updated when the module is changed, but the same will happen with the manually inputted language names. We can modify {{t-simple}} to add transliteration and gender annotations if they have been supplied as parameters.
Manually inputting script codes should be possible, if we add a findBestScript function in Module:languages/templates. — Eru·tuon 22:19, 21 May 2017 (UTC)
Wait, why would a module need to be involved at all if we input the script code manually? The template would just tag the translation as being whatever script was input, and common.css would apply the right font. (Or would that not work?) Of course, this would mean we would need to tightly control how many pages used t-simple, and periodically manually- or by-bot- check that only valid codes were being supplied. - -sche (discuss) 22:32, 21 May 2017 (UTC)
I mean, we'd use the module function once, when adding the script codes. Something like {{subst:#invoke:languages/templates|getByCode|language code|findBestScript|text}}. — Eru·tuon 22:52, 21 May 2017 (UTC)
Huh. What was I thinking? The findBestScript function is in Module:scripts/templates. — Eru·tuon 03:49, 22 May 2017 (UTC)
That would ensure that a valid script code was being supplied, and maybe we could do it "inexpensively" enough for it to be (to extend the metaphor) affordable. OTOH, we could save memory by not invoking a module at all: the template could just apply the supplied script code to the translation, like templates did before we had Lua. - -sche (discuss) 06:22, 22 May 2017 (UTC)
Okay, I guess I am being unclear. I am not proposing that the module be invoked, except when saving the page. I would just put a parameter such as |sc={{subst:#invoke:scripts/templates|findBestScript|eau|fr}} into {{t-simple}}. This would transform to |sc=Latn when the page is saved, and no template would be invoked once substing has happened. Then the script code in the wikitext will be valid unless someone changes the term or the language code on the page, or gives the script a new code in the script data module. findBestScript is the function by which {{t}} and other linking and tagging templates get script codes, so the output will be identical to the equivalent instance of {{t}}. — Eru·tuon 07:17, 22 May 2017 (UTC)

Adding ids to enable linking to headwordsEdit

I think we need ids in headwords, for form-of templates to link to.

Form-of templates currently allow an |id= parameter to link to a sense id. The need for some kind of id is clear, when there are multiple POS sections each with their own alternative forms. But using a sense id implies that an alternative form or inflected form only belongs to one sense. That's usually not true. Alternative or inflected forms generally apply to all senses inside a particular POS section. In order to use a sense id in a form-of template, you have to arbitrarily choose a sense to link to.

Ideally, we would link to the POS header itself. That's currently impossible, because sections for the same part of speech often occur multiple times in the same page. For instance, the page set has no less than 16 Noun sections, two of which are inside the English section. Adding the anchor #Noun will link to the first Noun section on the page, which is not necessarily correct. There is no way to add unique anchors to POS headers. It could be done by putting {{anchor}} within the equals signs of the header (for instance, ===Noun{{anchor|English noun 1}}===), but that's not currently allowed, and for good reason: it makes the anchor template display in the edit summary when you edit that section, and it breaks the link from the edit summary to the section.

The current solution is to link to a sense id in one of the definition lines in the desired POS section. This does not make sense for a form-of template. Forms generally apply to all or most definitions within the POS section, not to only one.

A better solution would be to link to an anchor within their headwords. We could add a |id= parameter to the headword template, and have Module:headword add id="headword id" to the first form in the headword. The form-of templates could then link to this id, instead of linking to the POS header directly above the headword.

(An alternative would be to place {{senseid}} in the same line as the headword template. That's sloppy, because it's called a sense id, not a headword id. As a sense id, it should only be used in senses [definition lines].)

To implement this, we would have to replace the existing |id= parameter in existing form-of templates with |senseid=. Then we would decide on a format for the headword ids, and allow Module:headword to create these ids, and Module:links to link to them. This may be complicated, but I am interested in making it happen. — Eru·tuon 22:07, 14 May 2017 (UTC)

Why does it have to be that complicated? Just add the id= parameter to {{head}} and that's it. —CodeCat 22:17, 14 May 2017 (UTC)
Huh? Add a parameter to headwords and do nothing to the form-of templates? — Eru·tuon 22:19, 14 May 2017 (UTC)
Yes. The form-of templates already have an id= parameter, they don't need changing. —CodeCat 22:22, 14 May 2017 (UTC)
Well, that means the headword ids have to be formatted identically to the sense ids. I didn't want to do that because it could result in a conflict, if a sense id had the same string as a headword id. — Eru·tuon 23:02, 14 May 2017 (UTC)
Ids of individual senses could also conflict with each other, but that doesn't seem to happen. I don't think it's an issue, unless I am missing something. —CodeCat 23:07, 14 May 2017 (UTC)
Hmm, you're right. So just the headword modules or templates have to be modified. — Eru·tuon 23:09, 14 May 2017 (UTC)
How are we going to name these headword ids though? We can't name them by sense or by part of speech (which isn't guaranteed to be unique). Adding a number can work, but of course the sections may be reordered later and then the number no longer matches its order on the page. This isn't necessarily an issue and highlights a strong point of ids, but if there's a better option that would be nice too. —CodeCat 23:19, 14 May 2017 (UTC)
That's a thorny question. Using a keyword from one of the most common senses would be easiest. As you say it might result in conflicts, but it might not be all that hard to avoid a conflict: an editor might be able to see both the id in the headword and any sense ids in the definitions while editing, unless the conflicting sense id was in another POS section. — Eru·tuon 00:52, 15 May 2017 (UTC)
This is why creating entirely separate ids, despite the complexity, would be better for editors. No need to worry about conflicts between headword and sense ids. — Eru·tuon 01:01, 15 May 2017 (UTC)
Like CodeCat, I think we should use the existing id= framework. Let's not make things unnecessarily complicated! We should probably add "have a bot check for duplicate ids" to the list of semi-regular tasks at WT:TODO, even to check for duplicate senseids under our already-existing system, like if someone put the senseid "pair" at a sense of the noun couple, and someone else put the same senseid at a sense of the verb couple. - -sche (discuss) 01:49, 15 May 2017 (UTC)
Okay, I'll work on making Module:headword add ids then. — Eru·tuon 02:05, 15 May 2017 (UTC)

in t-check categories, "Unspecified is an invalid script"Edit

Category:Requests for review of Lü translations and Category:Requests for review of Punjabi translations are displaying errors, apparently because the default text they create gives users an example of how to use {{t-check}} to put an entry into the category, but that example uses the Latin-script word "example" as the Lü/Punjabi translation. If there is no easier way of resolving the error, I suggest just dropping "It results in the message below:" and the displayed example after it, because it does not seem to be helpful. The wikitext to copy and paste seems to be all that a casual reader would need. - -sche (discuss) 01:43, 15 May 2017 (UTC)

Also, all the pages in the categories link to the #Lü and #Punjabi L2 (of library, etc) for some reason. - -sche (discuss) 01:44, 15 May 2017 (UTC)
That's an error message generated by the transliteration module, which in this case is Module:translit-redirect. I can disable the error message, either in non-entry namespaces or everywhere. — Eru·tuon 01:51, 15 May 2017 (UTC)
Eh, for the transliteration module to check that it is getting valid input, and to display an error if it is not, seems fine. So far, it seems to be only this edge case where there is a problem, and it would seem easier (or maybe not easier! but maybe better) to solve it by removing the actual display of "this is what it would look like if you put Latin script into a Punjabi t-check for some reason". - -sche (discuss) 02:49, 15 May 2017 (UTC)
Added English catfix to "requests for review of translations" categories, as I did before for "requests for translations". Now those categories will link to the English section of the entry. Thanks for noticing that error. — Eru·tuon 02:59, 15 May 2017 (UTC)
Thanks for fixing it! :) - -sche (discuss) 00:35, 16 May 2017 (UTC)

German attention neededEdit

There are over 200 entries in Category:Requests for attention in German entries. Some of these need attention before the German bot runs again - otherwise it might generate lots of rubbish. SemperBlotto (talk) 10:26, 15 May 2017 (UTC)

Oh, I'm glad to hear the bot will run again soon. :) I will start looking over these. - -sche (discuss) 21:37, 15 May 2017 (UTC)
@SemperBlotto I checked with AWB and found that there were only ~30 entries in both the "attention" category and Category:German terms with red links in their inflection tables, i.e. entries where the bot would be creating inflected forms for an entry with an attention tag. Of those, the inflection tables were correct in most of the entries: the attention tags were only asking for the definitions to be expanded, or in the case of a few adjectives, for "verb form" sections to be added. I will keep working to address and remove the attention tags, but I think that if your bot runs, the only entry it would create a wrong inflected form for is Wikiwörterbuch, where the inflection table lists a form Wikiwörterbuche which it should not list. - -sche (discuss) 23:01, 20 May 2017 (UTC)

Modified Russian translitEdit

I've created a JavaScript function that modifies Russian transliteration to show vowel reduction and other things: User:Erutuon/modifyRussianTranslit.js. So, for instance, the transliteration of Воро́неж (Vorónež) shows up as Varóniž: a little more representative of the actual pronunciation [vɐˈronʲɪʂ]. Kind of silly, but I like the more transcription-like transliteration variant.

I've wanted to do this for a while, but it wasn't possible until I added tagging for transliterations, as discussed above. — Eru·tuon 22:16, 15 May 2017 (UTC)

There is a longstanding disagreement between those who want transliterations of Russian to be transliterations, letter for letter, and those who want them to be like a secondary IPA. It has occasionally been suggested that both could be displayed, first the actual transliteration and then the "pronounced as". - -sche (discuss) 23:55, 15 May 2017 (UTC)
I just want to warn you that your tool probably makes a lot of mistakes. The reduction rules are not as regular as they may seem at first. --WikiTiki89 15:04, 16 May 2017 (UTC)
Probably. For instance, it transliterates ви́део (vídeo) as v̦íd̦ia when it should be v̦íd̦io. — Eru·tuon 19:11, 16 May 2017 (UTC)

Accel template for German diminutives needs updatingEdit

The accelerated-creation script for German diminutives uses outdated syntax in the declension-table it generates ([6]). I would fix it myself, but I don't recall where the relevant text that needs to be changed is located. - -sche (discuss) 00:43, 16 May 2017 (UTC)

@-sche, it's here: User:Conrad.Irwin/creationrules.js. —Μετάknowledgediscuss/deeds 00:48, 16 May 2017 (UTC)
Thanks! Fixed. - -sche (discuss) 01:04, 16 May 2017 (UTC)

Qualifying comparative and superlative forms in Template:de-decl-adjEdit

I suggest Template:de-decl-adj should accept optional parameters comp1_qual=, comp2_qual=, sup1_qual=, and sup2_qual= (or whatever names would be better) which, if present, would add a qualifier after the phrases "comparative"/ "superlative forms of x" that form the titles of the tables of forms. Then it could be explained why there are two tables of comparative forms on rot (one is for the inflection with umlaut, one without) and why there are two tables of superlative forms on blau (one with epenthetic -e-, one without). This could also be accomplished by repeating the tables with semicoloned headers, like this, but comp1_qual= would be neater. - -sche (discuss) 02:06, 16 May 2017 (UTC)

strang headerEdit

What's up with undetermined [Term?] at the beginning of the templates inherited, derived, and borrowing? --Espoo (talk) 11:00, 16 May 2017 (UTC)

Formatting for individual Japanese readingsEdit

There are several formatting issues with Japanese readings (yomi). The readings are displayed (collectively) by {{ja-readings}}, which provides fields for classes of readings (such as Goon, Kan’on, Kun, etc.). Each field may contain multiple readings (see e.g. ), but there is inconsistency in how the individual readings are formatted. The readings currently use plain wikilinks, so neither the linked hiragana nor the transliterations are currently tagged with lang=ja or classes Jpan or tr. Furthermore, there is inconsistency in how readings with okurigana are presented (sometimes the kanji spelling with furigana is included, sometimes not; sometimes there is a dot in the hiragana, etc.). When historical readings are thrown into the mix, things get more complicated, and other information is also sometimes supplied, such as rarity, and if the reading has been excluded from the Jōyō kanji table, i.e. it is 表外 (hyōgai). See , for some of the variety of display approaches. I think it is time we figured out how to present all this information and format it properly so that fonts are consistent on the site and language/script tags are properly applied. We could include this functionality in {{ja-readings}} (i.e. code it in the readings section of Module:ja), or we could create a new template for a single reading with its historical form (and automatic transliteration). I rather lean toward the latter route, as it would continue to allow extra information to be supplied alongside the readings as needed, while standardizing the display of modern/historical pairs and their transliteration. I also think it is particularly important to divorce the categorization of the historical readings from that of the modern readings, because they overlap, and it is useful to be able to search for kanji with a particular historical reading. – Krun (talk) 15:53, 17 May 2017 (UTC)

Input from editors of Japanese and also from Lua-savvy contributors would be much appreciated. @Eirikr, @Hippietrail, @Nibiko, @Haplology, @エリック・キィ, @TAKASUGI Shinji, @Nbarth, @Stephen G. Brown, @Wyang, @Atitarev, @suzukaze-c, @kc kennylau, @Erutuon, @CodeCat, any ideas?
I think it would be fairly easy to write a function to search for the wikilinked Japanese words and create a {{l}}-style link for each, without transliteration since the transliteration seems to be written out manually. It would also be possible to search for the italicized transliterations and add the correct formatting to them. If there are tables with transliteration missing, it would probably be possible to search for that and add automatic transliteration generated by the transliteration module. Is that the kind of thing you want? — Eru·tuon 00:32, 18 May 2017 (UTC)
Just to clarify: these are my ideas after looking at the sample input on the template page for {{ja-readings}}. I'm somewhat bewildered by your post because I know very little about Japanese and its entries (aside from the fact that there's one ideographic script and two syllabic ones). — Eru·tuon 00:36, 18 May 2017 (UTC)
Well, I was looking for technical input as well as linguistic, and you seem to manage well with the Lua module coding. I haven’t really gotten into it myself and don’t understand it very well. Anyway, about the transliterations: those should probably be removed and autogenerated instead. – Krun (talk) 01:49, 18 May 2017 (UTC)
I guess what we need might be a template, say ja-y that took a modern reading, its corresponding historical reading (optionally for now due to lack of data, but preferably always included), an optional more ancient reading (such as くゐやう for ) and potentially more, e.g. a parameter to indicate presence or absence in the Jōyō kanji lists. I’m not sure how it should be presented, but the connection of historical readings to the modern counterpart should be clearly indicated, all readings must be transliterated (there needs to be a separate automatic transliteration for historical/ancient readings from the modern ones), and the readings should be labeled succinctly, preferably with links to Wiktionary appendix pages explaining things like historical kana usage, Jōyō kanji, etc. – Krun (talk) 02:04, 18 May 2017 (UTC)
I've done a restructuring of the readings function, so that each reading can be handled in the same way (links redone using Module:links, for instance). If you notice any problems (such as readings in the template code vanishing from the displayed list), please let me know. — Eru·tuon 02:08, 18 May 2017 (UTC)
Hmm, I don’t really notice anything different now from before, but anyway, here is a stab at what I mean for each individual reading: Something like
which would yield something like:
きょう (kyō) (Jōyō reading; historical きやう (kyau), ancient くゐやう (kwyau))
– Krun (talk) 02:40, 18 May 2017 (UTC)
@Krun: Right, it shouldn't look different. I was restructuring to make consistent script and language tagging or linking possible. — Eru·tuon 23:56, 19 May 2017 (UTC)
(i don't think the ping worked the first time. @Eirikr, @Hippietrail, @Nibiko, @Haplology, @エリック・キィ, @TAKASUGI Shinji, @Nbarth, @Stephen G. Brown, @Wyang, @Atitarev, @suzukaze-c, @kc kennylau, @Erutuon, @CodeCatsuzukaze (tc) 22:12, 19 May 2017 (UTC))
I've been thinking about the template too, but my own idea I had in mind was to keep the general structure but make more of it automated, like
which would produce the same thing we presently have at .
I think Krun's idea is interesting too, since it allows for detail to be added easier.
Formatting of kun'yomi should definitely be solidified. 結#Readings is comprehensive but intimidating. —suzukaze (tc) 22:12, 19 May 2017 (UTC)
Suzukaze's suggestion is what I had in mind too. Wyang (talk) 00:18, 20 May 2017 (UTC)
結#Readings is indeed hard to read. Do you have an ideas for how it could be entered using the more brief input format that you are suggesting (or how it could be made more readable)? — Eru·tuon 00:21, 20 May 2017 (UTC)
My suggestion:
|kun=結(むす)ぶ, 結(むす)び, 結(むす)ばる, 結(むす)ばわる, 結(むす)ぼる, 結(むす)ぼうる, 結(むす)ぼれる, 結(ゆ)う, 結(ゆ)い, 結(ゆ)わう, 結(ゆ)わえる, 結(いわ)える, 結(いわ)く, 結(す)く-“to knit a net”, 結(かた)なす-“to gather or tie together into one bunch”, 結(かた)める-“to bind together; to open and read out the content of official documents”, 結(かた)ぬ
Jouyou readings should be handled by a backend data module. Of course, the automatic link formatting algorithm should be disabled if any of the parameters is formatted as a link (e.g. by {{ja-r}}). Wyang (talk) 00:34, 20 May 2017 (UTC)
I've disabled the link-formatting thingy whenever "<span" is found in the parameter, which indicates that {{ja-r}} (or another linking template that adds language and script tagging) has been used. — Eru·tuon 01:16, 20 May 2017 (UTC)
@Wyang: How will information like いわんや<いはんや be handled in your approach? --kc_kennylau (talk) 03:37, 20 May 2017 (UTC)
@Kc kennylau As 況(いわ)んや<況(いは)んや - so the algorithm for generating the link(s) would be (1) split by dash; (2) split by the less-than symbol; and (3) analyse parentheses. Wyang (talk) 11:39, 20 May 2017 (UTC)

(unindent) Nice. After seeing your suggestions, I really like them, @suzukaze-c and @Wyang, particularly since a way to add extra info has been envisioned. My original suggestion mostly has merit for making it easier for editors to add extra info, but if everything necessary is provided for, I actually prefer the single template solution. The code is then also shorter and easier to read without all the pipes and stuff in there. I still wonder how specific things like qualifiers about context of readings, rarity, classical Japanese only, etc. would be put in, and of course about the implementation of Jōyō readings. I do very much like the idea of having the Jōyō status of readings be automatically determined by lookup in a data module. I guess that would be very similar to how {{ja-kanji}} automatically determines the grade (Kyōiku (1–6) / Jōyō / Jinmeiyō / Hyōgai) of the kanji itself, which I also like. One change from Wyang’s example I would like to make is to remove the kanji (it is, after all, always the same kanji). That would also make the input simpler and easier to read:

|kun=むす.ぶ, むす.び, むす.ばる, むす.ばわる, むす.ぼる, むす.ぼうる, むす.ぼれる, ゆ.う, ゆ.い, ゆ.わう, ゆ.わえる, いわ.える, いわ.く, す.く-“to knit a net”, かた.なす-“to gather or tie together into one bunch”, かた.める-“to bind together; to open and read out the content of official documents”, かた.ぬ

I still think the spelling with kanji and the plain hiragana spelling should both be displayed in full, though, when the page is rendered. – Krun (talk) 00:28, 22 May 2017 (UTC)

@Krun, Erutuon, Wyang, Kc kennylau: 鬱 is a placeholder since using PAGENAME in links would look stupid in the sandbox. The broken appearance of きょう<きやう<くゐやう is on purpose for now since I want to see more evidence that we should add/support more than one layer of historical kana readings ([7] only has きょう<きやう). —suzukaze (tc) 07:09, 22 May 2017 (UTC)
Looks great. Question: are there any circumstances in which {{ja-r}} may be invoked with the kanji in a non-initial position? Wyang (talk) 07:13, 22 May 2017 (UTC)
@Wyang I am not aware of such. The only thing I could think of is things like お母さん, but then the かあ part seems to be considered the reading. – Krun (talk) 15:29, 22 May 2017 (UTC)
@Suzukaze-c Pretty good. I particularly like the special formatting for the historical readings. As for the additional layer, it is certainly true that dictionaries will normally not include it (like the one you linked to, which I believe is the 2nd edition of the Daijirin. Wiktionary is special, however, as we are not bound by the same restraints. I also think it’s a very good thing that we can offer easy access to otherwise obscure information. In any case, these readings have already been added to Wiktionary pages, and I do believe they are authentic, if rare. There are several sources for them; this page has a nice overview, with reference to several printed sources at the bottom; see also this one.
I am a little bit concerned with the furigana/ruby though; I think I prefer the full on plain kana spelling accompanied by the kanji-with-kana spelling for several reasons:
1. To have a link to both (the kanji spelling links to the main entry for a word, where the senses, pronunciation, etymology, etc. are to be found, but the plain kana spelling links to the page that gives the different kanji spellings for that reading).
2. With ruby, unfortunately, the kanji-with-kana spelling is not searchable (e.g.  (おく)れる (okureru) is 遅 followed by おく followed by れる in the HTML text. In my browser (Safari), a page search will find “おくれる”, but not “遅れる”. This is of course a wider issue with our use of ruby, and in cases where multiple kanji are used, often neither the spelling with kanji nor the plain kana can be searched for. It will presumably become less of an issue as our Japanese coverage gets better and we get individual entries for everything (then the headword line has both spellings in full), but it would be nice to help users to make the most of the information we currently have.
3. The kana are more readable when written in full. After all, in this particular page section the kana are all-important, as people are looking in it specifically for the reading; it’s not just a reading aid or extra information in this case.
I would also like to have consistency in the appearance of readings that have okurigana and those that do not, e.g. 行う (おこなう (okonau)) and (くだり (kudari)), rather than having the latter show only the plain kana spelling. We already have it e.g. at . I want to make the presence of okurigana explicit like that in every case, as it isn’t otherwise obvious whether there are no okurigana or the information is merely missing. There probably are cases where we cannot be certain for a while what the okurigana are, and not specifying (until someone figures it out) would be desired in those cases. There is always a question of whether the kanji or the kana spelling should come first; I don’t really have a strong opinion on that.
Another thing we need to be prepared for is variations in the okurigana. How should we format e.g. おこなう for , which has the variants 行う and 行なう?
Then there are readings that are words normally spelled with two kanji, like the kun-reading さとう for . This is, of course, a word which is normally spelled 砂糖 (including the kanji , but with another kanji as well). Has this word really been spelled with alone, or do kun-readings of this sort perhaps only serve as glosses or as standard word transformations for reading kanbun and the like? Perhaps you know something about that, @Eirikr, TAKASUGI Shinji, Nibiko?
– Krun (talk) 15:29, 22 May 2017 (UTC)

Combining table utiliesEdit

@CodeCat, Wikitiki89, Benwing2, Erutuon, I18n: I notice that we have several modules (mod:table tools, mod:table, mod:TableTools) which all contain, you guessed it, tools for tables. Could we combine these into one module so that we don't have to keep reïnventing the wheel? —JohnC5 04:07, 18 May 2017 (UTC)

I can't understand what Module:table tools does, but the module I just made, Module:table, could certainly be merged with Module:TableTools. There might be a duplicate function in the latter. — Eru·tuon 04:46, 18 May 2017 (UTC)
Module:table tools was created originally by User:Wikitiki89 and may be misnamed, but it has functionality orthogonal to the other modules -- it is for handling footnotes in table entries. OTOH, Module:utils overlaps heavily with Module:table and Module:TableTools and the three should probably be merged, perhaps into Module:utils since many of the things in the other two aren't specific to tables. Benwing2 (talk) 05:08, 18 May 2017 (UTC)
Speaking of Module:utils, does anyone know what @Vitalik was up to with Module:inflection and Module:inflection-docs? —JohnC5 05:22, 18 May 2017 (UTC)
Module:inflection was invented as some universal platform for inflection modules. Firstly it was implemented and used for Uzbek nouns, and then was started implementation for Russian nouns. But other users asked me to stop that implementation, so fill free to do with them anything you want. Vitalik (talk) 23:27, 19 May 2017 (UTC)
Module:table tools does not only handle footnotes. It contains functions that linkify and format comma-separated lists, and footnotes are only a part of that. Overall, it's meant to be a set of tools for making inflection table templates without dedicated modules. --WikiTiki89 14:35, 18 May 2017 (UTC)

Bot request: delete 600+ "Translations to be checked" categoriesEdit

Bot request:

Please delete all the "Translations to be checked" categories. For example:

I guess a bot can delete categories, right? If any of these categories has a couple of entries, a null edit in the entries should un-categorize them.

This action was voted and approved at Wiktionary:Votes/2017-03/Request categories 2. These categories were superseded by Category:Requests for review of translations by language.

Thanks in advance. --Daniel Carrero (talk) 13:54, 18 May 2017 (UTC)

A bot can do it, but it has to be logged in as an administrator. Not that it matters, because logged events cannot be flagged as bot edits in most cases (so will show in RC). Also, not all of these categories are empty, wouldn't it be easier to clean them up before deleting? - [The]DaveRoss 14:28, 18 May 2017 (UTC)
@TheDaveRoss: Do you think you can make the bot delete ONLY the categories that don't have any pages? This is just to be sure, because actually I believe I successfully emptied all the categories now. I did null edits where needed, and also removed a few entries that were categorized manually (i.e., without using templates).
Some categories have a reported number of entries like "Translations to be checked (Tupinambá)‎ (0 c, 1 e)" (emphasis mine) but they are actually empty. --Daniel Carrero (talk) 14:56, 18 May 2017 (UTC)
Yes, I can check if a category has members before deleting it. I'll delete all of the empty ones first and then check back. - [The]DaveRoss 15:02, 18 May 2017 (UTC)
Sounds great to me, thanks. --Daniel Carrero (talk) 15:03, 18 May 2017 (UTC)
It looks like the couple with members got cleaned up between then and now. The category is empty. - [The]DaveRoss 17:56, 18 May 2017 (UTC)
Great, thanks. I cleaned up Estonian at the last second when you were working on this. --Daniel Carrero (talk) 21:10, 19 May 2017 (UTC)


This template is failing in the Compounds section of by running out of Lua memory. It is powered by Module:zh and Module:columns. I tried turning off sorting (by previewing the page while editing Module:zh), but that doesn't fix it. It does have a huge number of links: 1275. — Eru·tuon 00:27, 19 May 2017 (UTC)

I (indiscriminately) removed some “compounds of compounds” to fix it. Wyang (talk) 00:23, 20 May 2017 (UTC)
It can avoid error by partitioning to many smaller zh-der as I did long ago somewhere. --Octahedron80 (talk) 04:01, 21 May 2017 (UTC)
Ah! I found it . It used to have the same error before. With , we can do this. --Octahedron80 (talk) 04:07, 21 May 2017 (UTC)

Function for inserting Template:t-simpleEdit

I've created a JavaScript function, User:Erutuon/simpleTranslations.js, to quickly convert {{t}} to {{t-simple}} for Latin-script translations with no parameters besides lang and term. (The function creates a link just above the edit box to allow you to trigger the function, if it finds the Translations header on the page.) I had been using regex in gedit (which I had to retype each time); might as well automate it. This will allow quicker fixing of Lua memory errors related to huge translations sections. I just had to do this in I, which recently developed a Lua memory error. So I decided to make a function. — Eru·tuon 03:44, 20 May 2017 (UTC)

Edit tag for missing headword templateEdit

Would it be possible to create an edit tag for missing headword templates? I've seen many edits like this, which have a definition and no headword template. They would be easier to find if they were tagged.

Perhaps the tag could be applied if there is a header containing one of the allowed parts of speech, but something other than a newline and a template is found after it, or if there is a POS header, newline, and #, as is true in the edit I linked above.

I don't know how edit tags work, so perhaps this is impossible. — Eru·tuon 00:43, 21 May 2017 (UTC)

They use regular expressions. It's technically possible, but the regular expression would have to match on a location where a headword-line template should be placed, but isn't. Both of these things run into problems: where does a headword-line template go, and what is a headword-line template to begin with? The answer to the first is a rather long list of valid POS headers, which makes for a very long regular expression. The second is even harder to answer, as it's essentially an open set; people create new headword-line templates all the time. At best, it could match for a template immediately following one of a long list of headers. —CodeCat 01:34, 21 May 2017 (UTC)
I think the location of the headword template is defined: one line below the POS header (though rarely someone might place it two lines below, which is incorrect). Yes, there are lots of headword templates. Checking for any template in that position would be easiest. (Could compile a full list from all the templates listed in Category:Headword-line templates and its subcategories, but I imagine that'd be a very long list, and quite frequently people don't add a category when creating a new template.) — Eru·tuon 01:47, 21 May 2017 (UTC)
There is no canonical list of parts of speech that appear in headers. DTLHS (talk) 03:03, 21 May 2017 (UTC)
What do you mean? What about the lists in WT:POS? — Eru·tuon 03:33, 21 May 2017 (UTC)
That's not a formal policy. In practice the set of all parts of speech in use is much larger. DTLHS (talk) 03:40, 21 May 2017 (UTC)
So, it would be impossible to generate a list of all the POS headers in use, and it is probably impossible to generate a list of all headword templates. But at the very least the filter could search for more commonly used POS headers, and then search for any template at the beginning of the first or second line below the header, and add a filter if there isn't a template there. That would be incomplete, but might not result in any false positives. — Eru·tuon 20:24, 21 May 2017 (UTC)
It must be possible to generate a list of POS headers (or a list of L3 headers from which non-POS headers could be sifted out manually), since lists of headers have been generated before and used to clean up errors like "Etmology". The list of POS headers would be large, but probably not larger than 300, especially once errors (like "Nouns" for "Noun") are removed. Then we could update WT:POS, with the understanding that new headers are not forbidden, but should be discussed. An edit filter checking so many things might be too expensive, though. - -sche (discuss) 22:24, 21 May 2017 (UTC)
Another idea: listing all the non-POS headers and assuming something is a POS header if it isn't a level 2 header (language) and isn't one of the non-POS headers? That would only be tenable if the list of non-POS headers is smaller than the list of POS headers. — Eru·tuon 01:17, 22 May 2017 (UTC)
I edited the shortcut WT:POS to point to WT:EL#Part of speech, which is the actual voted and approved policy. We do have a comprehensive list of parts of speech. (New parts of speech may be added depending on the needs of each language, of course.) --Daniel Carrero (talk) 01:33, 22 May 2017 (UTC)
For anyone curious about why this is a non trivial thing to analyze I suggest you download a dump and try to do it yourself. DTLHS (talk) 01:40, 22 May 2017 (UTC)
A possible approach: all headword templates should add a category in one of the following formats: [language name] lemmas or [language name] non-lemma forms. It should be possible to use the regular search to find entries that have no headword templates at all. As for entries with headword templates for some, but not all language sections: do the dumps include categories generated by templates, or are they all pre-transclusion? If they do have such categories, it would be a simple matter of comparing category names with L2 headers. If not, it might be possible to go through the subcategories of Category:Lemmas by language and Category:Non-lemma forms by language and create a list of language headers to compare with the list of L2s in the dumps. That still won't find cases where there's at least one headword template in the language section, but one or more headword templates are missing. It's a start, though. Chuck Entz (talk) 06:04, 22 May 2017 (UTC)
There is a category dump, but it's separate from the main dump, is in SQL instead of XML and is somewhat hard to work with. DTLHS (talk) 06:24, 22 May 2017 (UTC)
This filter might do the trick, it looks for the "known" POS headers and checks to see if there is any sort of template used before the definition line.
rx := "(s?)([=]{3,7})(Adjective|Adverb|Ambiposition|Article|Brivla|Circumfix|Circumposition|Classifier|Cmavo|Combining form|Conjunction|Contraction|Counter|Determiner|Diacritical mark|Gismu|Han character|Hanja|Hanzi|Infix|Interfix|Interjection|Kanji|Letter|Ligature|Lujvo|Noun|Number|Numeral|Participle|Particle|Phrase|Postposition|Prefix|Preposition|Prepositional phrase|Pronoun|Proper noun|Proverb|Punctuation mark|Rafsi|Romanization|Root|Suffix|Syllable|Symbol|Verb)\1([^{]*?)#(.+)";
new_wikitext rlike rx
Not sure how many false positives this would result in, but we can try it out and if it proves unhelpful amend or disable it. Added it as AF #68, tagging with "no head temp". - [The]DaveRoss 15:54, 22 May 2017 (UTC)

Edit request for language dataEdit

Please add a rule to replace ë with e for dum. —CodeCat 16:29, 21 May 2017 (UTC)

@CodeCat: Like this? —Aɴɢʀ (talk) 17:11, 21 May 2017 (UTC)
Yes, thank you. —CodeCat 17:12, 21 May 2017 (UTC)

Working with CategoriesEdit

I recently added "Category:English words prefixed with de-"to the page for "decant", but decant doesn't now show up on the list of words. Where is the documentation for this particular aspect of working with categories? Thanks! —This unsigned comment was added by Raspberrybeloved (talkcontribs).

  • It takes a few minutes for the category-mechanism to catch up. And I'm not totally convinced that decant has that prefix (it certainly starts with "de"). SemperBlotto (talk) 14:01, 22 May 2017 (UTC)
    • These categories are automatically added by etymology templates like {{affix}}, {{prefix}} and such, so you never need to add them manually. —CodeCat 14:17, 22 May 2017 (UTC)