Wiktionary:Grease pit

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

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

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

The Grease pit is a place to discuss technical issues such as templates, Lua modules, 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.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit


December 2017

Automatic links to fr.wikt in French conjugation tables[edit]

Would it be conceivable/desirable to somehow add automatic links to French conjugation appendices (such as fr:Annexe:Conjugaison en français/avoir) in our own French conjugation tables? A little revert war at sourdre makes me think that it would be good to have a conspicuous link to fr:Annexe:Conjugaison en français/sourdre, which is much more complete and nuanced. --Barytonesis (talk) 16:53, 1 December 2017 (UTC)

If it's automatically linkable, why not? As as side note, there's a proposed project to share conjugation code in this year's community whishlist. – Jberkel (talk) 09:21, 5 December 2017 (UTC)

Oddity with standardChars for German[edit]

The entry ſs is being categorized in Category:German terms spelled with S, I believe since "ſ" is considered the lower case form of "S". This seems undesirable. DTLHS (talk) 15:12, 2 December 2017 (UTC)

To fix this, I've added a special case to Module:headword so that the category for the lowercase version (German terms spelled with ſ) would be added, and Module:category tree/charactercat to prevent an error being returned because the letter in the category name is lowercase. There was already a special case for dotless i, ı. — Eru·tuon 19:15, 2 December 2017 (UTC)
@Erutuon Possibly you could make the code more general by doing this test: if the uppercase version is in the StandardChars, then use the lowercase version. —Rua (mew) 12:00, 4 December 2017 (UTC)
@Rua: That's a clever idea. It does work for these two cases, so I'm implementing it. — Eru·tuon 04:26, 5 December 2017 (UTC)

Templates for DOI, JSTOR, etc.[edit]

I just started to create Template:doi to link automatically to article DOIs in quotations, similarly to the way that the "doi" parameter to "cite" on Wikipedia does, or the way Template:ISBN handles ISBNs. I aborted the creation when I saw a warning that the page had been previously deleted, and an administrator note from 2014 that it had been "Migrated to Module:languages and data submodules". Is there any reason why there should not be templates to link to DOI, JSTOR, etc.? If not, what pitfalls exactly was that message trying to warn me about?

Syrenka V (talk) 01:43, 3 December 2017 (UTC)

Template:doi used to refer to a language code (for "Dogri"). That has been moved to Module:languages/data3/d. Shouldn't the template be at Template:DOI? I don't see a problem with creating such a template. DTLHS (talk) 01:45, 3 December 2017 (UTC)
@DTLHS: Thanks! I was using lowercase the way the Wikipedia {{citation}} template's parameters do (or, as I discovered just now, Wiktionary's own{{cite}}template's parameters). Since each template in effect has its own namespace for its own parameters, name collisions between parameters are unlikely. The Wiktionary Template namespace is much larger, so it's probably a better idea to use all caps (DOI, JSTOR, etc., similar to the existing{{ISBN}}template), to avoid name collisions like the one with the old Dogri language code template. But maybe the{{cite}}template will serve my purposes; I see now that it has lowercase "doi" and "jstor" parameters.
Syrenka V (talk) 17:31, 3 December 2017 (UTC)

{{IPAchar}} doesn't allow colons, which makes {{IPAlink}} display an error[edit]

{{IPAlink}} works by putting a link inside an {{IPAchar}}, like so:

{{IPAchar|[[w:voiced bilabial plosive|b]]}}

The colon in [[w:voiced bilabial plosive]] makes {{IPAchar}} display an error on preview (but not when viewing the page) because colons aren't allowed in IPA. A naive solution would be to simply allow colons, but in that case people might accidentally use them instead of ː. A better solution would be to ignore the destination of a link and only process the display text, but I don't know enough about MediaWiki or Lua scripting to do that, thus the post here. Nloveladyallen (talk) 16:16, 3 December 2017 (UTC)

@Nloveladyallen: Sounds like a good idea. Done. — Eru·tuon 19:17, 3 December 2017 (UTC)
@Erutuon: Why not change IPAlink to do [[w:voiced bilabial plosive|{{IPAchar|b}}]]?suzukaze (tc) 00:58, 16 December 2017 (UTC)
actually, that doesn't currently work because {{IPAchar}} outputs an error category too: [[w:voiced bilabial plosive|<span class="IPA">b</span>[[Category:IPA pronunciations with invalid representation marks]]]]
Also, the current version of {{IPAlink}} doesn't even link to Wikipedia in the first place... —suzukaze (tc) 01:12, 16 December 2017 (UTC)
@Suzukaze-c: It turns out I broke the linking in {{IPAlink}}. It's now restored. Good thing you mentioned it. — Eru·tuon 02:10, 16 December 2017 (UTC)

Eliminating deprecated parameters from Template:calque[edit]

I've gotten rid of all uses of the old deprecated parameters |etyl lang=, |etyl term=, |etyl tr=, and |etyl t= from {{calque}}. Can someone (e.g. @Rua, Crom daba, Erutuon, Victar) please edit Module:etymology/templates so that those templates don't work at all anymore? Ideally any attempt to use them would result in one of those "this template doesn't use that parameter" module error messages. Thanks! —Mahāgaja (formerly Angr) · talk 23:53, 4 December 2017 (UTC)

@Mahagaja: I made the edit, but reverted it because I still see entries linking to the tracking template calque/etyl, which tracks these parameters. Apparently some have evaded the means that you used to find the deprecated parameters. — Eru·tuon 00:14, 5 December 2017 (UTC)
I figured it out. CAT:calque with terms tracked {{calque}} templates with multiple terms, which is a subset of those with deprecated parameters. — Eru·tuon 00:22, 5 December 2017 (UTC)
@Erutuon: OK, Template:tracking/calque/etyl now has no pages linking to it. Anything else? —Mahāgaja (formerly Angr) · talk 01:11, 5 December 2017 (UTC)
@Mahagaja: No, that should be all. I'll remove the parameters and we'll see what happens. — Eru·tuon 01:41, 5 December 2017 (UTC)

Struck this out as solved. --Per utramque cavernam (talk) 13:32, 4 January 2018 (UTC)


when you use {{rfinfl|hy|noun}} as here, you're invited to choose a template from the nonexistent Category:Armenian noun inflection-table templates. but the real category is Category:Armenian declension-table templates. this should be fixed. --2A02:2788:A4:F44:B41C:6EB2:E4BA:9F35 11:39, 5 December 2017 (UTC)


Needs a documentation and as far as I see another parameter. F.e. {{R:Duden|DUDENSPELLING}} produces "[https://www.duden.de/rechtschreibung/DUDENSPELLING PAGENAME] in Duden online". There should be a way to do something like {{R:Duden|DUDEN-SPELLING|WHATEVER}} to produce "[https://www.duden.de/rechtschreibung/DUDENSPELLING WHATEVER] in Duden online". - 17:33, 5 December 2017 (UTC)

I ran into this recently, will take a look. The template is documented though. – Jberkel (talk) 17:52, 5 December 2017 (UTC)
My bad sry, I corrected the above. - 18:00, 5 December 2017 (UTC)
This was already possible, just not documented. There's a parameter w: {{R:Duden|DUDEN-SPELLING|w=WHATEVER}}. – Jberkel (talk) 20:54, 5 December 2017 (UTC)

Alphabetization in "Template:der3" and others[edit]

It's not necessary to place terms included in a {{der3}} template (and similar templates such as {{der4}} and {{rel3}}) inside {{l}} templates or to hyperlink them using [[ ]], unless one wishes to indicate multiple terms on a line, such as "{{l|en|jumboise}}, {{l|en|jumboize}}". However, I've noticed that if this is done, the template no longer alphabetizes such terms correctly, probably because it is arranging them according to the braces ({{ }}) rather than the terms within them – for example, see "jumbo#Derived terms". Can {{der3}} and similar templates be tweaked to ignore {{l}} and brackets for alphabetization purposes? — SGconlaw (talk) 17:15, 5 December 2017 (UTC)

Why do these templates alphabetise to begin with? I think that "feature" should be removed. I often group derived terms based on the type of derivation. —Rua (mew) 18:21, 5 December 2017 (UTC)
I totally rely on these templates to alphabetize words, especially in a language like Burmese where no one really knows how it's supposed to be alphabetized. —Mahāgaja (formerly Angr) · talk 20:42, 5 December 2017 (UTC)
Then how does the template know? —Rua (mew) 20:47, 5 December 2017 (UTC)
These templates use Module:columns, and Module:columns sorts by the official sortkey (with some other processing). — Eru·tuon 20:52, 5 December 2017 (UTC)
Also note that sorting can be turned off (though it can only be done when invoking the module on the template page), and there are unsorted equivalents for most of the templates: {{der3}}{{der3-u}}, for instance. Any that does not have an unsorted equivalent can have one. — Eru·tuon 20:54, 5 December 2017 (UTC)
@Rua: I'm not sure, but I think the template uses Unicode order. —Mahāgaja (formerly Angr) · talk 21:43, 5 December 2017 (UTC)
Yes, Unicode order after each term has been processed into the form used for sorting. — Eru·tuon 21:45, 5 December 2017 (UTC)
I agree with Rua, these templates should not reorder data, we should store the data ordered. - TheDaveRoss 13:48, 6 December 2017 (UTC)
Is this a problem if there are versions of the templates like {{der3-u}} which do not sort? Alternatively, the templates could be tweaked so that by default they do not sort, but sorting can be ordered using a parameter. — SGconlaw (talk) 15:43, 6 December 2017 (UTC)
I agree with Rua and TheDaveRoss. And having yet another template for such a minor difference in behaviour is a poor idea, in my view. --Barytonesis (talk) 13:25, 7 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── So it is better just to use {{der3-u}} and manually sort the list in such cases, rather than updating {{der3}} (and related templates) so that {{ and [[ are ignored? — SGconlaw (talk) 04:10, 6 December 2017 (UTC)

@Sgconlaw: No, that was a separate discussion. Regarding your original problem, it needs to be reframed a little. What {{der3}} actually sees when you supply link templates to it, like {{l|en|word}}, is the wikitext that is generated by the template: in this case, <span class="Latn" lang="en">[[word#English|word]]</span>. You can view the wikitext generated by the template by using Special:ExpandTemplates.
To answer your question, it would be possible to filter this stuff out when sorting the words. It would add some processing time and memory. It might be worth it if it is often that a single column template contains both plain words and words formatted with a linking template. If all words use linking templates, they are likely to sort correctly, as they will all start with the same HTML tag and double bracket.
Another option if you want to link multiple words is to use plain wikilinks: [[jumboise]], [[jumboize]]. Those will be converted into language links with language tagging: <span class="Latn" lang="en">[[jumboise#English|jumboise]], [[jumboize#English|jumboize]]</span>. And I think that would sort as jumboisejumboize in the current version of the module. The sorting is done before the language tagging and link piping. — Eru·tuon 04:51, 6 December 2017 (UTC)
Thanks, using plainlinks solved the issue. I think this should be documented on the template documentation pages of {{der3}} and related templates. — SGconlaw (talk) 07:10, 6 December 2017 (UTC)
For future reference, {der3} alphabetizes incorrectly for several languages, so there needs to be a non-reordering option.__Gamren (talk) 15:55, 3 January 2018 (UTC)
@Gamren: There is: {{der3-u}}. —Mahāgaja (formerly Angr) · talk 16:29, 3 January 2018 (UTC)
{{der3-u}} was introduced specifically for languages such as Danish, Norwegian, and Swedish because of the sorting problem, but it can be used elsewhere, I have used it for Faroese. There is also {{der4-u}}, but no {{der2-u}} yet, which would be handy. DonnanZ (talk) 16:46, 3 January 2018 (UTC)
Yes, I know. I made {der5-u} myself. I just wanted to tell future readers why there needs to be non-alphabetizing templates, so they don't get tempted to delete them.__Gamren (talk) 09:36, 4 January 2018 (UTC)
That idea makes me shudder! There may also be a case for {{rel2-u}}, {{rel3-u}} etc. DonnanZ (talk) 18:37, 4 January 2018 (UTC)
Why all these different templates? Can there not just be a single {{rel}} with a parameter to specify how many columns? —Rua (mew) 18:59, 4 January 2018 (UTC)
I agree. — SGconlaw (talk) 19:09, 4 January 2018 (UTC)
You will have to ask a template expert like @Erutuon. There may be a technical reason. DonnanZ (talk) 19:19, 4 January 2018 (UTC)
I don't see any reason why not. — Eru·tuon 19:43, 4 January 2018 (UTC)
Ok then, how should the parameters be? {{rel|lang|cols|...}}, {{rel|cols|lang|...}}, cols with a named parameter, or something else? —Rua (mew) 20:14, 4 January 2018 (UTC)
The language code being in the first parameter has the advantage of being similar to most other templates in which the language code is found in a numbered parameter. I'd favor {{rel|lang|cols|...}}, or maybe {{rel|lang=lang|cols=cols|...}}, which is closer to how the existing column templates do it. One way that {{rel|lang|cols|...}} could malfunction is if someone mistakenly entered a three-letter related term that happens to be a language code, followed by a number that is somehow also a related term, but that is pretty unlikely. — Eru·tuon 22:45, 4 January 2018 (UTC)
So how would you deal with the -u, in say {{der3-u}}? DonnanZ (talk) 12:41, 5 January 2018 (UTC)
That would become the default. To sort, you'd specify sort=1. —Rua (mew) 14:34, 5 January 2018 (UTC)

my user page[edit]

Hello! So I tried to create my user page but anything I do it says it's harmful. All I put was: Hello So, I don't know what to do. Can you let me know please? Thanks! —This unsigned comment was added by Booksssss (talkcontribs).

@Booksssss: What are you trying to put in it? (please don't forget to sign your messages with ~~~~) --Barytonesis (talk) 23:22, 5 December 2017 (UTC)

I put in "Hello" and it said it was harmful. Booksssss (talk) 23:26, 5 December 2017 (UTC)

There's really no reason someone who hasn't made any edits needs a user page. How about you try contributing to the dictionary first, and then create a user page when you have something useful to put on it. —Μετάknowledgediscuss/deeds 01:24, 6 December 2017 (UTC)
OK. Per utramque cavernam (talk) 21:46, 19 January 2018 (UTC)

Some links not being language tagged[edit]

On Reconstruction:Proto-Indo-European/kʷis in the etymology section, the links *kʷi- and *kʷe- aren't being tagged as PIE, although the following link to *éy is. Any idea why? —Rua (mew) 00:44, 7 December 2017 (UTC)

Apparently ''{{m|ine-pro|*kʷi-}}'' results in <i><i class="Latn" lang="ine-pro">[[Reconstruction:Proto-Indo-European/kʷi-|*kʷi-]]</i></i> and then the inner i tag is deleted, leaving the one that doesn't have class or language attributes. — Eru·tuon 00:56, 7 December 2017 (UTC)
Whose dumb idea was that? Ugh. —Rua (mew) 13:43, 7 December 2017 (UTC)

Bring Serbo-Croatian entry and translation additions technically up to date to accelerate the treatment of the language[edit]

1. We have a lot of pronunciation templates already, including Slavic ones. Can somebody make a Serbo-Croatian IPA module? It’s the easiest, one letter is one phoneme in Serbo-Croatian Cyrillic and almost the same is the case in Serbo-Croatian Roman where there are just two digraphs.

2. Something has to be done to keep the Serbo-Croatian translations in English lemmata in the best state. The best current practice looks as follows in the code, for the entry hatred:

* Serbo-Croatian:
*: Cyrillic: {{t|sh|мр́жња|f}}
*: Roman: {{t+|sh|mŕžnja|f}}

The visual translation adder should automatically add the entry in the other alphabet if an editor adds an entry in one alphabet to facilitate the addition of Serbo-Croatian translations (else one is forced to edit the source code when one would otherwise use the visual editor for all other languages one knows). Alternatively a bot could fix the entries, but of course it is better if they are just added correctly. Though a bot has to fix older entries anyway. Palaestrator verborum (loquier) 11:13, 7 December 2017 (UTC)

We call it Latin script on Wiktionary, not Roman script: Category:Latin script. —Rua (mew) 13:44, 7 December 2017 (UTC)
I know how it is called. But currently all translations into Serbo-Croatian write “Roman”. I don’t care if it is changed, but it can be solved as I have described. @Rua. Palaestrator verborum (loquier) 14:02, 7 December 2017 (UTC)
They say "Roman" because the translation adder got them confused with the Latin language when they said "Latin". Ideally we should go back to calling them "Latin" and have a more intelligent translation adder. —Μετάknowledgediscuss/deeds 10:13, 11 December 2017 (UTC)
We apparently already have an (unused) module for Serbocroat pronunciation: Module:sh-IPA. Still needs some work, though. — Vorziblix (talk · contribs) 15:31, 11 December 2017 (UTC)
Well, I’ve gotten the module to a functional state and made a corresponding template, {{sh-IPA}}. Some quick test cases are available here. It seems to be working well as far as standard Serbo-Croatian goes, but if you see anything that needs fixing/changing, I’ll see what I can do. — Vorziblix (talk · contribs) 17:41, 11 December 2017 (UTC)

Etymology templates and artificial languages[edit]

At [[silflay]] I wanted to change {{etyl|art-lap|en}} to {{der|en|art-lap}}, but {{der}} doesn't like artificial languages. If I leave |3= empty it says "[Term?]" and adds the entry to CAT:Lapine term requests, which is how {{der}} behaves with normal languages. If you don't want to specify a term with {{der}} and a normal language, you put |3=-. However, if I do that with art-lap, I get a module error saying "A term was provided but the given code 'art-lap' is not a language, and therefore cannot have terms or dictionary entries", which is the usual behavior with language families. So if I don't specify a term, the template asks me to supply one, and if I do specify a term (or a hyphen), the template complains that art-lap isn't allowed to have entries! But note that other templates like {{m}} do not object to having terms in art-lap: {{m|art-lap|silf}} is a well-behaved link. —Mahāgaja (formerly Angr) · talk 17:33, 10 December 2017 (UTC)

@Erutuon, Rua, this problem still needs to be solved. —Μετάknowledgediscuss/deeds 07:00, 15 December 2017 (UTC)
@Metaknowledge: Thanks for the ping. I didn't see this post. The problem is fixed now. For some reason, the module did not allow derivation from appendix-constructed languages; this example seems to indicate that was misguided or an oversight. — Eru·tuon 07:16, 15 December 2017 (UTC)

Struck this out as solved. --Per utramque cavernam (talk) 13:33, 4 January 2018 (UTC)

Old Cyrillic characters[edit]

Why are U+A651 [CYRILLIC SMALL LETTER YERU WITH BACK YER] () and U+A657 [CYRILLIC SMALL LETTER IOTIFIED A] () such an eyesore? I mean, look at велиѥꙗдъ (velijejadŭ) or благостꙑни (blagostyni), it's ugly as hell. I wouldn't be bothered if all the characters had this handwritten feel to them, but here it sticks out like a sore thumb. Is this a problem on my part, on Wiktionary's part, or on Unicode's part? --Per utramque cavernam (talk) 18:57, 11 December 2017 (UTC)

It sounds like it's a font issue. Your browser is using one font for most of the characters, but another font for the two characters you point to. So you probably need a font that contains all the characters alike. I use Monomakh Unicode TT, and the words look fine. — Eru·tuon 19:14, 11 December 2017 (UTC)
I see them all in the same font, and it looks fine. —Rua (mew) 19:20, 11 December 2017 (UTC)
Yes, almost definitely a font issue; these characters, unlike the rest, are in the Unicode block Cyrillic Extended-B, which probably isn’t supported by whichever font the browser is defaulting to. The font used for Old Cyrillic at Wiktionary attempts to default to one of the options listed under Old Cyrillic (Old Church Slavonic, Old East Slavic) at MediaWiki:Common.css, so installing any one of them would probably solve the problem. (For me all Old Cyrillic defaults to the BukyVede font, which looks nice enough.) — Vorziblix (talk · contribs) 19:26, 11 December 2017 (UTC)
Monomakh Unicode.png
@Erutuon, Vorziblix: thanks, it's a font issue indeed. However I installed Monomakh through a browser extension (Stylish for Safari), and it's completely messing up the display (see image), so I'm stuck with the out of touch characters for now... I guess I just don't know how to install a font properly :3 --Per utramque cavernam (talk) 22:30, 18 December 2017 (UTC)
@Per utramque cavernam: Ouch. It seems like it is being used for all text. I would recommend using it only for Old Cyrillic by adding .Cyrs { font-family: BukyVede; } to your common.css. I don't know what's causing the overlapping text though. — Eru·tuon 22:49, 18 December 2017 (UTC)

Struck this out as solved. --Per utramque cavernam (talk) 13:34, 4 January 2018 (UTC)

quote templates[edit]

Something is wrong there, valid dates produce "(Can we date this quote?)". Got lost in the template soup so not sure where to fix it. – Jberkel 00:16, 16 December 2017 (UTC)

@Jberkel: Fixed! — Eru·tuon 00:26, 16 December 2017 (UTC)

Moving entries without logs[edit]

PIE *dṓws was moved to *dóws, which was a good edit, but how was this done without leaving a move log? Is this a bug? --Victar (talk) 15:36, 16 December 2017 (UTC)

Are you sure it was ever at *dṓws? That page has no history at all. Is it possible you created it directly at *dóws and just thought you were creating it at *dṓws? —Mahāgaja (formerly Angr) · talk 20:36, 16 December 2017 (UTC)

wrong pinying tone displayed depending on page zoom[edit]

For example, show the following mismatch when zoom is normal, 100%, using chrome (from 125% correct tone): (Pinyin): gōng, góng (gong1, gong4)--Backinstadiums (talk) 23:05, 16 December 2017 (UTC)

@Backinstadiums: I see it too when I view the page in Chrome, but at 75% and 80% zoom level. Must be a font glitch. The codepoint is correct. — Eru·tuon 23:16, 16 December 2017 (UTC)
I don't see this problem on Chrome for me, but I do see another problem. It's applying the Hani or Hans style on the pinyin, while Firefox applies the tt style. @Suzukaze-c, any thoughts? Also, I've always wondered why the pinyin is in a different font from other romanizations in the template. — justin(r)leung (t...) | c=› } 23:28, 16 December 2017 (UTC)
@Justinrleung: I don't see the Hani class in the HTML, though I do see the cmn language code. To answer your question, the tt tag is added by Module:cmn-pron. That makes the pinyin display in a monospace font. (Tangentially, the tt tag is deprecated and should be replaced with code or kbd.) The other romanizations use Consolas, a monospace font that must not be the default monospace font in your browser or mine. — Eru·tuon 23:36, 16 December 2017 (UTC)
@Erutuon: The cmn language code gets its font from its script, which would be Hani. I just wanted to know the rationale behind using tt for pinyin and Consolas for other romanizations, not the technical details, which I was kind of aware of. Shouldn't we be using Consolas for all of the romanizations, including pinyin? @Wyang, Kc kennylau, perhaps you may know why? — justin(r)leung (t...) | c=› } 23:58, 16 December 2017 (UTC)
@Justinrleung: I can't answer the question about the fonts chosen. But to clarify the other issue, script and language are entirely separate. The script class attribute class="Hani" has to be in the HTML source code of the page for the font styles associated with .Hani in MediaWiki:Common.css to apply. The language attribute lang="cmn" doesn't affect font because MediaWiki:Common.css doesn't have any styles for [lang=cmn] or :lang(cmn). So, you don't have to worry about inappropriate fonts being applied in this case. — Eru·tuon 00:39, 17 December 2017 (UTC)
@Erutuon: Ah, thanks for clarifying. No wonder it's going to the default Chinese font SimSun, which is not on the list for .Hani but terrible for pinyin. — justin(r)leung (t...) | c=› } 00:43, 17 December 2017 (UTC)
because lol (中易宋体垃圾西文点阵) —suzukaze (tc) 00:02, 17 December 2017 (UTC)

Is it possible to solve it then? --Backinstadiums (talk) 11:25, 18 December 2017 (UTC)

Traditional/Simplified grid[edit]

The table appearing on the right of the etymology section, which contains the traditional/simplified character(s), usually shows the simplified version on green in two lines, even for just two characters, distorting its comprehension, for example in chrome 供给 100% zoom --Backinstadiums (talk) 00:45, 17 December 2017 (UTC)

Newline distortion.jpg
Didn't you say that this was due to the zoom in your browser? Why are you bringing this up again? —Μετάknowledgediscuss/deeds 17:20, 18 December 2017 (UTC)
@Metaknowledge: My post right above this one is also related to zoom, but as you can see it's a real issue, so I thought this one could logically be related; the absence of replies must mean it is just for me, yet I do not know the reason for it yet, so I still need some help --Backinstadiums (talk) 18:14, 18 December 2017 (UTC)
@Backinstadiums: You know there are things like parsing bugs in browsers? Sometimes one codes the markup correctly and the browser messes it up. The fact that all looks smooth on my machine and apparently the other machines of the editors indicates strongly that this is such a case. Maybe you should free yourself from the Scroogle and use a browser that is not made to sell advertising to you. Google software is not made for advanced language dealing. Until four years ago there were not even polytonic Greek glyphs in their garbage mobile OS – there would be a link here to their issue tracker, but now it requires a login to see the issues, what a joke.
So why should anyone on en.Wiktionary or MediaWiki have done wrong? Comparing with the free software minds, it has to be presumed that if you use Google software, all bugs come from Google. Proprietary software is made to abuse you. Palaestrator verborum (loquier) 19:47, 18 December 2017 (UTC)
@Palaestrator verborum: I totally disagree... Google is great at fonts. My Android phone even renders Brahmi script without my having to install fonts, which is immensely useful for Prakrit on Wiktionary. And Chrome has this cool extension for per-language font settings. Not to mention the Noto Fonts project. And btw Chromium, the base for Chrome, is open source.
But yeah, that's probably a browser problem, not a Mediawiki problem. —AryamanA (मुझसे बात करेंयोगदान) 21:24, 18 December 2017 (UTC)
@AryamanA: But fonts aren’t software. And Noto is only partially Google. (I actually did not evaluate any font itself, but the implementation in Android, if you think I am contradicting.) Point is, whoso uses proprietary software of corporations which have even the issue trackers closed is godforsaken. Palaestrator verborum (loquier) 21:37, 18 December 2017 (UTC)
@Palaestrator verborum: Fair enough. The Chromium issue tracker is accessible btw. —AryamanA (मुझसे बात करेंयोगदान) 21:58, 18 December 2017 (UTC)
@Backinstadiums: A solution is to apply the CSS white-space: nowrap; to the text that's wrapping. But I'm not seeing the problem unless I zoom the page up to like 300%, at which point the table is squished by the width of the content section of the page. — Eru·tuon 20:13, 18 December 2017 (UTC)
(please don't use no-wrap. we have fairly long entriessuzukaze (tc) 20:24, 18 December 2017 (UTC))

How to note the absence of a translation in translation sections[edit]

It happens not rarely that I want look into a request for translations or else a translation table and have to hold that no translation exists. Examples include heifer or hinny for which no Arabic translations exist or ear bud for which no German or Russian translations exist (and yet ear bud calls for translations). What happens particularly often is that where English resorts to an adjective to denote a concept German habitually forms compounds, there being intercalary an example. A similar problem that has been touched at some occasions is that a language uses a different part of speech whilst this is hard to note in the translation tables.

It would be of splendor if one were able to note such absence and the need of compounding or the need of using a different PoS in a standardized manner. Palaestrator verborum (loquier) 14:06, 18 December 2017 (UTC)

There’s {{not used}}, which is currently only used with function words and an affix. For adjectives whose German equivalent is a noun in a compound, I think the usual practice is to use something like {{t|de|Nounincompound}}-. For translations that are not idiomatic in the target language, we use wikilinks: {{t|ar|[[arabic for young]] [[arabic for cow]]}}. For distinctions that are not made in the target language, you can use a qualifier: {{t|pt|fone de ouvido}} {{q|Portuguese does not distinguish earphones from earbuds}}. — Ungoliant (falai) 14:22, 18 December 2017 (UTC)

An interesting and underdeveloped template you have mentioned – on eight pages it is used, and I see somebody has asked this in June 2015 and apparently nothing has improved since. But when it comes to the clutch, the important information is not only that a term is not used, but what can be used. It should support more statements, as: “Use … instead” – “circumscribe instead” – “compound with …” – etc. It is a bit unlucky to first state a translation and than retract it with a qualifier. And of course there is still the problem left of terms that can very well be translated but only in a different POS – that maybe could be a parameter for {{t}}. Palaestrator verborum (loquier) 14:35, 18 December 2017 (UTC)

Regarding at least one subset of terms that translate to a different POS (or terms that have one POS in English but translate into multiple POS in other languages, when e.g. an attributive noun in English is an adjective in another language), DCDuring and I mulled over some ideas here (see also the translations-tables and talk pages of cork, brass and mushroom); there's no easy/great fix, but putting them in the "best fit" translation-table with qualifiers seem like the best approach. I agree with what Ungoliant has said. It might be useful to expand {{not used}} to say something like "describe/circumscribe instead", but then it should probably allow for or be accompanied by a sample description/translation, in which case why not just provide that (potentially [[individually]] [[wikilinked]]) SOP description as the translation? (That may be why the template isn't used more...) - -sche (discuss) 21:37, 28 December 2017 (UTC)

Design change for translation only entries[edit]

Discussion moved from Wiktionary:Requests for deletion/Others#Template:translation only.

Propose to replace this template with a {{phrasebook}}-like template. See here for an example. This will make the entry more usable as it contains real definitions rather than this template.--2001:DA8:201:3512:F0D2:BCEA:BF85:63BB 13:57, 19 December 2017 (UTC)

"This entry is a translation target, which presents criteria for inclusion based on for hosting translations." seems ungrammatical; what does it mean exactly?
Also, if we do this, the point you make here seems moot. --Per utramque cavernam (talk) 14:03, 19 December 2017 (UTC)
  • Why? I'm sure not everything that is "translation only" comes from a phrasebook. DonnanZ (talk) 14:06, 19 December 2017 (UTC)
    • The icon and text is not final and may be discussed. Probably a better wording is "This entry is a translation target, which presents criteria for inclusion based on its usefulness for hosting translations, even if it is not usually considered idiomatic." The category name (Category:English non-idiomatic translation targets) can also be discussed.--2001:DA8:201:3512:F0D2:BCEA:BF85:63BB 14:34, 19 December 2017 (UTC)

The design I like though the grammar not and though there are surely better designs. However it is of course not the formally correct approach to place the template for the old way for deletion; it cannot yet be deleted, and nobody will argue for it so far. First you ask around in Wiktionary:Beer parlour or if it is too trivial (because it is mostly a design question) Wiktionary:Grease pit, then if we have a solution it will be deleted. Palaestrator verborum (loquier) 16:33, 19 December 2017 (UTC)

The point of the template as it is now, is to not have to write any definition. Since the term is by definition unidiomatic, it should not need a definition, its meaning should be obvious from the page title alone. —Rua (mew) 18:08, 19 December 2017 (UTC)
Yes. But independent of this the English sections which are translation-only can be highlighted somehow so they do not look like “real” entries. Palaestrator verborum (loquier) 19:43, 19 December 2017 (UTC)
I think translation-only entries should be removed from the lemma categories, for a start. --Per utramque cavernam (talk) 19:57, 19 December 2017 (UTC)

Derived terms assistance[edit]

Is there some semi-automated tool or script I can add to make it so I can add in derived terms in a similar way to the translations box? It'd be nice if a machine would automatically sort them all and put them in Template:l(|da) for me. I know it might be a bit silly to ask this if I was doing English or similar, but in Germanic languages like Danish, there are so many terms derived from just about any basic, commonly used word that it's ridiculous. Furthermore, it's very frustrating for a perfectionist like me who wants to add as many (attested ones) as possible in there. Plus I think a script like this would be useful for general purposes too anyway.

What I'm suggesting, by the way, is something like this corresponding to Template:der-top (and others); maybe not small derived terms sections, since they generally don't get the template. PseudoSkull (talk) 06:48, 21 December 2017 (UTC)

There are cases where "Special:WhatLinksHere/" eliminates the need for entering any links. One advantage is that one has the reasonable assurance that the entry is not SoP. If SoP items are desired for Derived terms then I would want them to appear without wikilinks or with piece-wise wikilinks. IMO, reliance on templates can reduce the quality of our content and typically has some bias, usually toward inclusion, built in. DCDuring (talk) 14:41, 21 December 2017 (UTC)

Category:Missing Danish plurals[edit]

Created by an anon, but it has a flaw where it doesn't recognise indefinite plurals which are the same as the indefinite singular, mainly in neuter nouns. DonnanZ (talk) 10:48, 21 December 2017 (UTC)

Fixed. Though the template should probably be updated to check for any missing forms, not just the plural. Redboywild (talk) 11:15, 21 December 2017 (UTC)
@Redboywild: What you have done has certainly added more genuinely missing plurals to the category, but it's still falsely including plurals like anfald and babyboom. Unless I should give it more time to sort itself out. DonnanZ (talk) 11:28, 21 December 2017 (UTC)
@Donnanz: I think the category page needs more time to update. If you actually go to those entries you'll notice the category isn't listed at the bottom. Redboywild (talk) 11:33, 21 December 2017 (UTC)
It's a hidden category, but yes, it's now gone in those cases. Cheers. DonnanZ (talk) 11:42, 21 December 2017 (UTC)

Struck this out as solved. --Per utramque cavernam (talk) 13:34, 4 January 2018 (UTC)

Template:contraction of[edit]

I thought I would try {{contraction of}} for the first time, but in the end I gave up. Not only does it use a capital letter for "contraction", but has a full stop, which means you have to mess around with nocap=1 and nodot=1 or dot= if you want to eliminate both. I realise a capital letter may be desirable in some circumstances, but I feel the full stop could be eliminated, and added by the user if needed. DonnanZ (talk) 13:44, 25 December 2017 (UTC)

Forget it, the resulting word is in bold, which isn't what I wanted. DonnanZ (talk) 16:57, 25 December 2017 (UTC)


This and other gerunds are currently given as lemmas, but they seem straightforwardly like nonlemma forms to me. Can this be fixed? —Rua (mew) 19:32, 27 December 2017 (UTC)

Input troubles[edit]

A problem has appeared on my account on Wiktionary where, for example, typing two ] after another results not in ]] but in ʼ, and = after g does not give g=, but ɣ. Some characters like { I am not able to type, as they appear as other characters. What could be the cause of this? — Knyȝt 20:08, 27 December 2017 (UTC)

Have you replicated this problem in more than one browser? —Μετάknowledgediscuss/deeds 00:39, 28 December 2017 (UTC)
Yes, although I can write some characters like { in Chrome but still not *, while I can write neither in Firefox. — Knyȝt 12:00, 30 December 2017 (UTC)
Additionally, I noticed normal typing is enabled for about half a second on a page before it switches to whatever this other system is. — Knyȝt 22:10, 9 January 2018 (UTC)

Andamaanit ja Nikobaarit[edit]

I'm puzzled. This entry appears in the category "Requests for attention concerning Finnish" [1]. Yet I don't see an attention-tag on the page, nor don't I understand what could possibly be the problem with the entry. --Hekaheka (talk) 02:31, 28 December 2017 (UTC)

Template:fi-decl has several #ifeq clauses that generate the attention category. Is the declension correct? DTLHS (talk) 02:34, 28 December 2017 (UTC)
Yes, the declension is correct. I thought it might be the non-cap "ja" in the middle of a proper noun, but Antigua ja Barbuda is ok. I'll check the template fi-decl for a clue. --Hekaheka (talk) 02:40, 28 December 2017 (UTC)
It was the first #ifeq. One must use the qualifier "n=sg" "nosg=1" for plural only -terms. Thanks for the hint! --Hekaheka (talk) 02:48, 28 December 2017 (UTC)

Easy way to check all translations in a language?[edit]

Is there an easy way to check all translations in a language, to make sure they are correct? —Rua (mew) 16:11, 28 December 2017 (UTC)

Parsing the dump seems like the most straight-forward way to me. - TheDaveRoss 16:14, 28 December 2017 (UTC)
Any way that someone without technical skills could do it? It seems like a fairly basic task. —Rua (mew) 16:23, 28 December 2017 (UTC)
One method which I do not think we should do would be to add some categorization to {{t}} which would create categories of all words translated into the language in question, I don't think the overhead is worth it. A better way would be to create a tool on toolserver which created tables of translations and then check those, or to parse the dump. - TheDaveRoss 16:33, 28 December 2017 (UTC)
What overhead would that be? I doubt that a single category is going to make much of a difference. An alternative would be to use tracking templates, that way the category listing isn't going to be spammed to uselessness. —Rua (mew) 16:43, 28 December 2017 (UTC)
For some reason there is already Category:Translingual translations. Palaestrator verborum sis loquier 🗣 16:58, 28 December 2017 (UTC)
There are already three categories in {{t}}, Translingual as mentioned, English and Undefined. {{t}} is likely the single most transcluded template we have, and any additional work that its millions of invocations require is significant overhead. Even a small language requires that every invocation perform the language check, and as we have seen over and over again changes to {{t}} can have page-breaking consequences. - TheDaveRoss 18:32, 28 December 2017 (UTC)
Some pages would end up with several thousand categories. DTLHS (talk) 00:41, 29 December 2017 (UTC)
What about generating dummy links to some page title per language? You could then use the what links here functionality. DTLHS (talk) 00:49, 29 December 2017 (UTC)
@Rua: If I were to check Dutch translations, I would start with Category:Requests for review of Dutch translations, that's what {{t-check|nl|...}} is for. To see all Dutch translations from English from a dump, you can use User:Matthias_Buchmeier/en-nl-a, User:Matthias_Buchmeier/en-nl-b, etc. for each English letter. No technical knowledge is required. --Anatoli T. (обсудить/вклад) 02:10, 29 December 2017 (UTC)
@DTLHS That's what tracking templates are. See Template:tracking. —Rua (mew) 15:36, 29 December 2017 (UTC)
  • How does one learn about which translations don't need checking or, at least, have been checked by a qualified checker (presumably with a datestamp)? DCDuring (talk) 15:50, 29 December 2017 (UTC)
A simple Cirrus Search ('incategory:"English lemmas" Translations insource:/\{\{t-check/') rapidly (< 10 seconds) generated a list of 6000 entries.
Another ('incategory:"English lemmas" Translations insource:/\{\{t\|ru/') took less than 10 seconds to generate a list of 16000 entries with Russian translations.
For the {{t-check}} replacing {{t-check}} with {{t}} prevents one kind of duplication. Replacement with a new template {{t-checked}} or, better, {{t-checked18}} would allow exclusion of checked translations from any such search list. Would this work? DCDuring (talk) 16:01, 29 December 2017 (UTC)
People are already complaining about two many new templates being in use, and this surely blows heads off. Palaestrator verborum sis loquier 🗣 17:22, 29 December 2017 (UTC)
I doubt that additional templates in the {{t}} family would be a large problem for the regular contributors who would be the one's working on checking translations. Another approach is to add a named parameter to {{t}} to indicate when it had been checked. CirrusSearch's 'insource' capability would allow exclusion of items using the parameter from subsequent searches for entries needing checking. Of course, I expect there will be no new templates or changes to existing templates if there are substantial objections from likely users. I made the suggestion only because I have had to introduce something special, a named parameter, to indicate to me that I have already verified the spelling of taxonomic names. I have other categories that show other deficiencies in such entries. I also test for missing templates, which leads be to add multiple reference templates, eliminating the entry from subsequent re-checkings. DCDuring (talk) 19:21, 29 December 2017 (UTC)
Above User:TheDaveRoss suggested that complicating {{t}} was a bad idea. Manual substitution of one template for another would keep {{t}} simple. DCDuring (talk) 19:21, 29 December 2017 (UTC)
We could also add a kind of template near the current translation templates. Something like {{tverf|es}} and {{tverf|es|checkedby=DCDuring|checkedby2=TheDaveRoss}}, for which I have proferred names that can serve exclusion in CirrusSearch well. Then we can couple the names with the Babel scores on the user pages and generate lists ranking translations by their amount of trustworthy verification; maybe such a template would wrap {{t}} inside its arguments, maybe not. Unless of course this makes us look like Urban Dictionary where translations get upvoted. However it seems to me that this is unfeasible chiefly because of our numerable amount of editors. Palaestrator verborum sis loquier 🗣 20:43, 29 December 2017 (UTC)
I'd not be a likely user because of my very limited translation skills, but the approach might work if the need to type could be minimized. DCDuring (talk) 00:39, 30 December 2017 (UTC)
Sounds like a lot of bullshit for no real benefit. I have no idea why you want to add a "checked" translation template. If a template isn't in a TTBC box or template it is assumed to be checked. DTLHS (talk) 00:59, 30 December 2017 (UTC)
Without control of who adds/removes it, anything like this is useless for quality control. Judging by what happens with {{t+}}, people will copy the template/parameters from other translations without knowing what they mean. For those who know what they mean and use them anyway, they're all experts- just ask them... Chuck Entz (talk) 03:55, 30 December 2017 (UTC)
I agree with Chuck; using template parameters/names is completely unreliable (and unwieldy, and unsightly...). We need an external tool for this. —suzukaze (tc) 04:28, 30 December 2017 (UTC)
I'm glad I helped forge a consensus on this. DCDuring (talk) 04:38, 30 December 2017 (UTC)

A new approach to errors[edit]

Right now we have two basic ways to automatically deal with bad content:

  1. Lua, which can do an incredible amount of sophisticated logic, but is limited by cumulative resource burdens of being invoked multiple times on one page, and has no access to most user/edit history information. It has relatively few options when detecting an error, since it can't prevent anyone from saving a bad edit.
  2. Abuse filters, which can use their own sophisticated logic which accesses user and other information, have options forbidden to templates and modules, but are executed on every page and so are limited to a total number of conditions checked overall.

I would like to propose a third option: have Lua modules generate hidden text that abuse filters use to know when to apply their own logic and perform their own actions. We could have a different filter for each combination of conditions and actions, and have a specific hidden text to trigger each of those. The conditions include classes of users, edit rate and other system information, and the actions include preventing saving of the edit, which templates can't do.

One of those potential actions is to display a system message page that admins can create/configure. If we can figure out a way for the message page to know which page triggered it, we could have a template that extracts details from the page to decide what to say. Since this is only executing once on a special page, we wouldn't have to worry as much about memory, time and expensive-function-call restraints. Being able to customize the message this way would cut down on the number of filters needed.

Another unanswered question is how to keep vandals from reverse-engineering the system and using it for their own ends.

This idea occurred to me as I was trying to figure out how to keep module errors from rendering old edits unreadable. Since a message could be set to be triggered only during an edit, we could have deprecated templates and parameters only cause problems when people try to actually use them, and otherwise simulate older template behaviors. There would still be cases where too much has changed for an accurate simulation, but it wouldn't be as all-pervasive a problem as currently. Just moving Module:parameters to this system would make a huge difference, if we could manage it. Chuck Entz (talk) 07:55, 30 December 2017 (UTC)

What do you mean by "hidden text"? DTLHS (talk) 18:41, 30 December 2017 (UTC)
A hidden category would work. An HTML comment would be better, but I don't know if those are accessible to the abuse filters (I suppose even something hidden by CSS or JS might do). It wouldn't show up in the edit box or on the preview, though I'm sure someone who knew how to look for it could find it. Chuck Entz (talk) 20:09, 30 December 2017 (UTC)
I'm looking at https://www.mediawiki.org/wiki/Extension:AbuseFilter/Rules_format to see if there's anything that's of use here. Mostly, the variables refer to wikitext-related things, which is no good for this purpose. I'm not sure what added_lines_pst actually refers to, but it may be worth investigating. —Rua (mew) 20:52, 30 December 2017 (UTC)

Unicode blocks in script categories[edit]

I thought that script categories needed some information on the characters found in the script, so I added a list of the Unicode blocks, generated from the character pattern in Module:scripts/data.

As far as display goes, there's a bug: the "Expand" or "Collapse" button is pushed down by the "Recent additions to the category" table. It has something to do with the float: right; CSS property that applies to both of these elements. I don't know how to fix this, so suggestions are welcome. In fact, the display could be totally changed, as long as the list is collapsible when there are more than a few Unicode blocks. — Eru·tuon 23:00, 30 December 2017 (UTC)

I fixed the problem by changing the collapsible <div> to a table. — Eru·tuon 19:42, 3 January 2018 (UTC)

Special:AbuseFilter/1 and Special:AbuseFilter/2[edit]

Can these be modified to allow zh-see entries?--Zcreator (talk) 12:59, 31 December 2017 (UTC)

January 2018

Dalmatian Language Conjugator[edit]

Happy New Year to you all!

I, Aearthrise have been working on Dalmatian language entries (the language of the Ancient Roman province of Illyricum/Illyria, modern day Croatia, Montenegro) and have created templates for Dalmatian verbs.

Dalmatian is NOT just a random dialect of Romance languages, it is the the fifth and least known out of the five groups of modern Romance: Hispanic(Spanish, Portuguese, etc.), Italic(Italian, etc.), Gallic(French, etc.), Illyric(Dalmatian, etc.), and Dacic(Romanian, etc.)

There are four verbal stems in Dalmatian which compare to Latin forms, -ur(-āre),-ar(-ēre),-ro(-ere), and -er(-īre).

Here are examples of each normal conjugation form: -ur favlur, to speak; -ar vular, to want; -ro crescro, to grow; and -er contribuer, to contribute.

To be perfectly honest, I attempted creating the module for conjugation myself by copying the Spanish template, but I created a mess of it. If you are up to the task, I beg you to help the Dalmatian wiki.

Please, you are our only hope.

(Ⲁⲉⲁⲣⲑⲣⲓⲥⲉ) 09:07, 1 January 2018‎(UTC)
Do you really need to use a module? If you just have these four patterns, you should just make a base template, {{dlm-conj}}, then call that for the four patterns with template parameters. DTLHS (talk) 21:00, 1 January 2018 (UTC)
@DTLHS: Could you elaborate on how to make a base template and how to call for template parameters?
(Ⲁⲉⲁⲣⲑⲣⲓⲥⲉ) 17:51, 1 January 2018‎(UTC)
For example, instead of {{dlm-conj-favlur}}, which works for only one verb, you could create {{dlm-conj-ur}}, which would work for all verbs of the conjugation class. In the template itself you would simply replace favl with {{{1}}}; then you could write {{dlm-conj-ur|whatever}} to generate a table for the verb whateverur. You should also use {{l-self}} instead of bare links to create links in an inflection table template. —Mahāgaja (formerly Angr) · talk 16:12, 2 January 2018 (UTC)


As a follow-up to this conversation, I've tried to make {{zh-psm}} a language-agnostic template. I think my attempt has been successful: see {{psm}} and its backend (I've stolen the code of {{semantic loan}}, essentially.)

However, as you can see at 萬維網, {{psm}} is adding categories of the type CAT:xxx phono-semantic matchings of xxx terms (parallel to CAT:xxx terms borrowed from xxx and the like, but I preferred to avoid CAT:xxx phono-semantic matchings from xxx, which sounded clumsy), while {{zh-psm}} only add a CAT:xxx phono-semantic matchings (for example: CAT:Chinese phono-semantic matchings). Is that a desirable feature, or should I remove it?

@Wyang, what do you think? --Per utramque cavernam (talk) 00:43, 3 January 2018 (UTC)

Thanks for the work. I'm not fussed; either is fine with me. Wyang (talk) 13:31, 4 January 2018 (UTC)
@Justinrleung, Tooironic? --Per utramque cavernam (talk) 14:48, 5 January 2018 (UTC)
@Per utramque cavernam: Maybe there should be CAT:xxx terms phono-semantically matched from xxx for consistency with borrowings and calques, but it really doesn't matter to me. — justin(r)leung (t...) | c=› } 14:55, 5 January 2018 (UTC)


It's the big hot ball in the sky. —Rua (mew) 19:47, 3 January 2018 (UTC)

Solved by Wyang yesterday. --Per utramque cavernam (talk) 13:28, 4 January 2018 (UTC)


Like I said at the entry Pfefferkorn, I noticed something strange going on with the reference template {{R:DWDS}}. If anyone can notice it, good. --Lo Ximiendo (talk) 13:00, 4 January 2018 (UTC)

It looks OK to me. Can you be more specific? —Mahāgaja (formerly Angr) · talk 13:08, 4 January 2018 (UTC)
I also see no problem, except that I would probably italicize the title of the work.__Gamren (talk) 14:38, 4 January 2018 (UTC)
If {{R:DWDS}} (“Term” in Source) and {{R:Duden}} (Term in Source) appear together, it looks strange, but that's not just a matter of the DWDS template.
Could the link, http :// www.dwds.de/?kompakt=1&qu=Term (template link) vs. https :// www.dwds.de/wb/Term (visited page), be a matter?
Or could the interwiki link be a problem (should be fixed with diff)? - 06:18, 6 January 2018 (UTC)

Special:AbuseFilter/74 -- default ASL template unfilled[edit]

My efforts to block these edits have failed. Bad edit example: م_أغاني_رتةرزذطلنرو_دديييفهمذبز_ءذانناتنتتيثقغروًع. They are frequent. Anyone able to fix? Equinox 14:17, 5 January 2018 (UTC)

1er (French adjective)[edit]

The French Wiktionary has entries of the form 1er, 2e where we are limited to the incorrect "1er", "2e" &c. Why is this? Can we fix it? SemperBlotto (talk) 07:36, 6 January 2018 (UTC)

It's 1er (fr:1er) but with templates to display another title: {{titre mis en forme|1{{er}}}} (fr:Modèle:titre mis en forme, fr:Modèle:er). If there is both, 1er and 1er, be it in different style conventions or in different languages, then it's a bad idea to manipulate the overall title. Best that could be done would be using something like {{head|fr|numeral|head=1<sup>er</sup>}}. - 09:07, 6 January 2018 (UTC)
Solved. Per utramque cavernam (talk) 21:45, 19 January 2018 (UTC)

Auto-capitalizing the first letter in a link[edit]

In working with templates, {{ucfirst: }} is nice for capitalizing the first letter of some variable phrase, but if the first word is a link, it fails to capitalize. So, for example, {{ucfirst: [[a]]}} fails to capitzalize the a (presumably because it’s trying to capitalize the bracket). Is there a simple workaround for this? — Vorziblix (talk · contribs) 13:31, 7 January 2018 (UTC)

The link should be "outside" {{ucfirst:}}, like this: [[a|{{ucfirst:a}}]]. In that way, you are only formatting the text ("a"). — SGconlaw (talk) 15:09, 7 January 2018 (UTC)
Thanks. Unfortunately I have several {{#switch:}} statements inside the {{ucfirst:}}, where some of the possible text fragments generated have links and others don’t, so I don’t think that solution can be made to work for the particular template I’m looking at ({{egy-verb form of}}). — Vorziblix (talk · contribs) 23:43, 7 January 2018 (UTC)
I've created a function in Module:sandbox that correctly capitalizes a single wikilink. It won't work if there are two or more wikilinks, or regular text preceding a wikilink. That might be sufficient, depending on what the content in your template looks like, or it might need further development. — Eru·tuon 01:21, 8 January 2018 (UTC)
Thanks, I’ll keep that on hand if this problem comes up again. (The current template’s been rewritten from scratch, so this is resolved.) — Vorziblix (talk · contribs) 23:28, 8 January 2018 (UTC)

Autodetection failing for Japanese ruby annotations - strip HTML?[edit]

Module:ja-link creates specially annotated "ruby" links, which appear as mini Hiragana on top of Chinese characters, like at 一夫多妻制 in the Synonyms section. The module makes some changes and HTML additions to the alt display of the link, and then forwards it on to Module:links. What actually gets provided is this: <span style="font-size: 1.2em"><ruby>一夫多妻<rp> (</rp><rt>いっぷたさい</rt><rp>)</rp></ruby></span>. This causes problems with script detection, because there's lots of Latin characters in the HTML which throws it off (Module:ja-link solves this by providing sc=, but we're trying to eliminate that). However, if the HTML tags could be stripped, you'd end up with 一夫多妻 (いっぷたさい) which script detection would almost be happy with, if not for the HTML entity.

So, I wonder how feasible it is to strip HTML tags from text before doing script detection. If that could be done, then autodetection would work for ruby text as well and no longer need an explicit script. —Rua (mew) 12:34, 8 January 2018 (UTC)

Hani script for Korean, is it necessary?[edit]

There are a lot of entries, even templates, that specify sc=Hani for Korean text. The character ranges for Kore already include Chinese characters, so it seems redundant to explicitly specify Hani, script detection can handle this. Is it ok to remove explicit Hani from Korean? —Rua (mew) 13:12, 8 January 2018 (UTC)

I think Korean should uniformly use Kore all the time, similar to Japanese and Jpan. I don't know what others think. —suzukaze (tc) 04:11, 9 January 2018 (UTC)
I agree. --Anatoli T. (обсудить/вклад) 04:28, 9 January 2018 (UTC)

Romance conjugation templates[edit]

I noticed that the Spanish conjugation template has color coding, when the verb form varies from the norm. Verbix also does this, although they distinguish orthographic changes and others which aren't technically irregular from actual irregular changes. I propose adding this sort of color-coding to the Spanish conjugation template, and possibly extending it to other Romance languages, because I know that at least Italian and French have similar. For example, comparing the present indicative of cantar, surgir, and haber:

Verb yo él nosotros vosotros ellos
cantar canto cantas canta cantamos cantáis cantan
surgir surjo surges surge surgemos surgéis surgen
haber he has ha hemos habéis han

Currently, "surjo" would be colored the same as the various forms of "haber". —This unsigned comment was added by RoseOfVarda (talkcontribs) at 01:21, 10 January 2018 (UTC).

I like the idea. A combination of bold and italics could also work. — Ungoliant (falai) 20:19, 10 January 2018 (UTC)
Maybe use CSS classes so it can be restyled if needed? – Jberkel 00:03, 11 January 2018 (UTC)
CSS classes would be a good idea. I just defaulted to blue-ish and reddish, because those are the colors Verbix uses. It also adds gray for forms which are grammatical, but don't make pragmatic sense, like non third person singular forms of "nevar", although I think that's less important to mark. If we did want a third class, I either introduce Both, like how "negar" experiences both diphthongization and orthographic changes, or Irregular Stem with Regular Ending, like how haber and avere both experience syncopation in the future tense, but otherwise conjugate regularly. --RoseOfVarda (talk) 01:43, 11 January 2018 (UTC)

Script-based variants[edit]

I've been mulling around how display script-based variants better in descendents trees. Right now for Sogdian, I do this:

: Buddhist: {{l|sog|tr=δs}}, {{l|sog|tr=δsˀ}} {{l|sog|tr=δsh}}
: Christian: {{l|sog|tr=dsˀ}}
: Manichean: {{l|sog|tr=δs}}, {{l|sog|tr=δsˀ}}
: Sogdian: {{l|sog|tr=δs}}, {{l|sog|tr=δsˀ}} {{l|sog|tr=δsh}}
>> Sogdian:
Buddhist: [script needed] (δs), [script needed] (δsˀ) {{l|sog|tr=δsh}
Christian: [script needed] (dsˀ)
Manichean: [script needed] (δs), [script needed] (δsˀ)
Sogdian: [script needed] (δs), [script needed] (δsˀ) [script needed] (δsh)

I think the ideal solution would be that if |sc= is set, then the language name is replaced by the script name. Also, we'd either need to have a data module for {{desc}} with language-specific names, ex. |lang=sog + |sc=Syrc = Christian, or language-specific subcodes, ex. |sc=sg-Syrc. Probably would need a |nosc=1 override param as well.

: {{desc|sog|tr=δs|sc=Soyo}}, {{l|sog|tr=δsˀ}} {{l|sog|tr=δsh}}
: {{desc|sog|tr=dsˀ|sc=Syrc}}
: {{desc|sog|tr=δs|sc=Mani}}, {{l|sog|tr=δsˀ}}
: {{desc|sog|tr=δs|sc=Sogd}}, {{l|sog|tr=δsˀ}} {{l|sog|tr=δsh}}

Other example uses would be for Serbo-Croatian and Middle Persian. @-sche, Erutuon, Tropylium, Crom daba, Rua, any thoughts? --Victar (talk) 02:29, 10 January 2018 (UTC)

I think it would be unnecessarily confusing to use |sc=. In most templates it simply means "text in one or more of the other parameters of the template is in this script", but this proposal would add the meaning "the link will be labeled by a script or religion name". And these two things should be separate, so that you can use the script or religion label without manually supplying the script code, and you can supply the script code without replacing the language name with a script or religion. Anyway, the parameter would be misnamed when the label is actually a religion.
I vote for having a data module with a table for each language, containing the special prefix used for each script. A boolean parameter could turn on the special prefix, and the module wouldn't have to concatenate the language and script code (sog, Syrcsog-Syrc). — Eru·tuon 04:04, 10 January 2018 (UTC)
@Erutuon: I think you're right in that it shouldn't be on by default. I suggest |sclb=1. That way, we actually wouldn't even need to use |sc= most of the time, as the script would be automatically detected, and the only time we would need it is if you aren't entering the native script, i.e. using |tr= instead. Sogdian is the only example of a script alias I can think of, so I think better to just piggyback on the script data module and filter it with a aliases data module. How does that sound? --Victar (talk) 05:50, 10 January 2018 (UTC)
@Victar: Hmm, actually, since only one language needs special labels, there really doesn't need to be a data module; perhaps a small if-block would be the most efficient. I guess |sclb= is okay if there's not a better option; it'll only be a misnomer for the religion labels of Sogdian. — Eru·tuon 07:42, 10 January 2018 (UTC)
@Erutuon: Cool, cool. --Victar (talk) 15:21, 10 January 2018 (UTC)
Sounds good, I always have to look up how to spell Phags-pa and Uyghur when making Proto-Mongolic entries. Crom daba (talk) 09:24, 10 January 2018 (UTC)
@Crom daba: Yeah, me too. It wastes so much time. --Victar (talk) 15:21, 10 January 2018 (UTC)

I always dreamed to use language/script subtags as in BCP 47 (it is the linked list which is the standard). There are even such dope uses as ru-petr1708 and ru-luna1918 for Russian in Zarist and Bolshevik spelling. And Chinese could differentiate too with Hans and Hant. I would expect that this is what people expect to be supported, or no? Well, web developers do. Palaestrator verborum sis loquier 🗣 06:28, 10 January 2018 (UTC)

@Palaestrator verborum: Fancy subtags are not the topic of this thread, but you can use all the subtags you want on English Wikipedia now, after the creation of w:Module:Lang. I'm not sure how they could be integrated into Wiktionary's system of language codes or whether they would be useful. (Regarding Hans and Hant, they're are officially allowed, but they may be only rarely used. {{zh-l}} doesn't use them.) — Eru·tuon 07:27, 10 January 2018 (UTC)
("Hant" is not a simple concept, because of the way Unicode did stuff. —suzukaze (tc) 07:40, 10 January 2018 (UTC))
I've considered including script tags in language codes as well, and it can be done under a few conditions.
  • getByCode in Module:languages would first have to parse this two-part code, and separate the script from the rest.
  • Then, when constructing the language object, it would have to include the script among the properties of the object, like the language code is currently.
  • Of course, a method is needed to query this script. findBestScript would also need to be modified to return this script rather than doing automatic detection.
  • Any other code must not use the language code directly, but always first acquire a language object and then call getCode.
Rua (mew) 14:29, 10 January 2018 (UTC)
Well the topic is how to display script versions, isn’t it. And as there are quite some thoughts with potential of serious consequences about script labels I reminded about the internet standard for this, which is also more readible and which many people have surely forgotten. And people think that I make complicated proposals … Palaestrator verborum sis loquier 🗣 18:08, 10 January 2018 (UTC)
The title of the section is "script-based variants", which sounds like it could be talking about IETF script subtags, but the actual topic of the original post was labels in descendant trees. — Eru·tuon 19:58, 10 January 2018 (UTC)


The template {{quote-book}} is throwing up vertical bars in dun. Lingo Bingo Dingo (talk) 13:26, 10 January 2018 (UTC)

It's been edited a few minutes ago. Fumiko Take is probably still working on it. --Per utramque cavernam (talk) 13:27, 10 January 2018 (UTC)
Solved. Per utramque cavernam (talk) 21:43, 19 January 2018 (UTC)


Where is the code that converts {{head|en|noun}} to Category:English nouns (appends the final "s")? I'm trying to use the template on Hindi Wiktionary. —AryamanA (मुझसे बात करेंयोगदान) 11:33, 11 January 2018 (UTC)

@AryamanA Lines 58-68 in the current code of Module:headword/templates, I think. Wyang (talk) 11:39, 11 January 2018 (UTC)

Flesh out MediaWiki:Mobile.css so RTL and unitalicized languages display well[edit]

Because it's loaded for all mobile users, we've been rightly loath to fill MediaWiki:Mobile.css (currently 909 bytes) with everything that's in MediaWiki:Common.css (46,082 bytes), but there've been discussions of adding the parts that ensure certain languages display correctly RTL and/or unitalicized. I'd like to follow through and do at least the first of those. Can I just list all RTL languages in one big list and set direction: rtl; and then list all unitalicized languages and set font-style: normal; font-weight: normal;? - -sche (discuss) 18:24, 11 January 2018 (UTC)

I think font-weight: normal; is set for a smaller number of scripts than font-style: normal;; for instance, Greek script is unitalicized, but is allowed to be bolded (as in αδιασταύρωτος (adiastávrotos)). — Eru·tuon 19:23, 11 January 2018 (UTC)
Oh, duh; OK, scratch font-weight: normal;. - -sche (discuss) 19:32, 11 January 2018 (UTC)
Is there any other styling that it would be vital to add for mobile users? (We probably don't want to get into fonts, lest the amount of stuff that's getting downloaded for all mobile users grow too large.) - -sche (discuss) 19:35, 11 January 2018 (UTC)
Maybe not essential, but the rules that replace bolding with larger font-size in certain scripts (Han and Japanese, for instance) would make usage examples more legible once you remove bolding. — Eru·tuon 22:43, 11 January 2018 (UTC)
Mobile seriously needs the js for vsSwitcher inflection tables. They are a mess without it. —AryamanA (मुझसे बात करेंयोगदान) 13:54, 12 January 2018 (UTC)
Thanks for bringing that up; (if no one else gets to it first,) I'll look into it and other .js issues after this thread about .css issues is resolved. :) - -sche (discuss) 17:19, 12 January 2018 (UTC)
OK, I propose to add roughly this (~2,880 bytes, but I think whitespace will be stripped) to MediaWiki:Mobile.css to fix the previously-highlighted problem of RTL scripts displaying problematically, and to stop italicization of scripts that are not italicized on the computer (non-mobile) version of the site. Will there be any problems? I am particularly interested in whether or not it is necessary to include MediaWiki:Common.css's "empty" definitions of certain scripts. (I also included the language that supports display of vertical Mongolian and Phags-pa, and Tangut, which seemed to be the same type of thing as supporting RTL scripts.) - -sche (discuss) 17:19, 12 January 2018 (UTC)
Seeing no further comments in two days: Yes check.svg Done. After clearing my cache, I find that it works: Cyrillic is as unitalicized on mobile as it is on the main site, and vertical Mongolian displays correctly, too. The mobile version still looks awfully sparse and full of whitespace around headers, etc. - -sche (discuss) 15:43, 14 January 2018 (UTC)

Script tagging in Template:also[edit]

{{also}} now automatically detects the script of links in many cases and adds script tagging, using the same function that detects script to {{character info/new}}. So exotic scripts will look nicer now.

The script detection is language-agnostic: Arab, not fa-Arab or ur-Arab; Hani, Hira, Kata, or Hang (Han, hiragana, katakana, Hangeul), not Jpan or Kore (Japanese, Korean). However, Grek (monotonic Greek) is automatically upgraded to polytonic if the link contains any polytonic Greek characters. So also with Latn and Latinx, Cyrl and Cyrs (Latin, Latin extended, Cyrillic, Old Cyrillic).

This adds a bit of memory because it uses Module:Unicode data and Module:Unicode data/scripts. A few pages went over the memory limit, so I added the possibility of manually supplying scripts using |sc= and |scN=. Probably I should add another parameter for disabling it altogether, but for now it's okay. — Eru·tuon 12:55, 12 January 2018 (UTC)

This seems like a good thing, although I'm wary of how many things we keep doing that take up a little more memory, a little more memory... - -sche (discuss) 17:52, 12 January 2018 (UTC)

unicode-bidi: embed for Samaritan script[edit]

Is it intentional, or an oversight, that every other RTL script in MediaWiki:Common.css has direction: rtl; unicode-bidi: embed;, but Samr only has direction: rtl;? - -sche (discuss) 17:10, 12 January 2018 (UTC)


I am having trouble getting {{trans-see}} and {{senseid}} to generate a jump from give someone a break to the marked sense at rest. I think I followed the documentation, but the jump doesn't leave me a the marked definition. In some cases the marked definition isn't even visible. Has anyone else been using this combination? Has anyone had a similar problem? DCDuring (talk) 22:05, 15 January 2018 (UTC)

It correctly links to the translation table with the matching id, for me. —Rua (mew) 22:16, 15 January 2018 (UTC)
Yes, this seems to be instance of the general issue that if tables collapse or expand or other things happen after the viewer lands on the target page, the page 'jumps' so it's no longer at the anchored section. - -sche (discuss) 22:22, 15 January 2018 (UTC)
Then, because longer pages are more likely to have more collapsible tables etc. and those are the very pages for which users most need the help that {{senseid}} is intended to offer, it is a lot less useful than we have wanted it to be.
Should we push this kind of thing as a major bug or is it our "fault" for overusing JS? Are there other ways to achieve the results we want using other technical tools? DCDuring (talk) 22:40, 15 January 2018 (UTC)

Template:rfe won't display comment if it contains a hyperlink[edit]

Over at cachila, I'd added an rfe tag with a comment that includes a link to a site with some relevant information. The template categorizes correctly, but it won't show the comment -- unless I remove the link.

Is this intended behavior? If so, why? ‑‑ Eiríkr Útlendi │Tala við mig 21:18, 16 January 2018 (UTC)

@Eirikr: It's because of the equals sign in the URL. That gets misinterpreted as marking off a parameter name (i.e., a parameter named Cannot find a source for the ''bird'' sense. http://www.laluneta.com.ar/nota?id). Use an explicit |1=, or replace the equals sign as {{=}}. — Eru·tuon 21:40, 16 January 2018 (UTC)
Huh. I'd naively thought that [links in brackets] would not be subject to parsing as params. Thank you! ‑‑ Eiríkr Útlendi │Tala við mig 21:57, 16 January 2018 (UTC)
@Eirikr: I might've thought the same. I mean, you can include piped links in template parameters: piped. Maybe external links are parsed at a different point in the process than internal links. — Eru·tuon 23:27, 16 January 2018 (UTC)


The Japanese etymology links to "勿論#Literary Chinese". Shouldn't it just link to the Chinese section, like Medieval Latin? Ultimateria (talk) 23:24, 16 January 2018 (UTC)

Pinging @Wyang, suzukaze-c -- is "literary" here a meaningful distinction for Japanese etymologies? I find the term in the Tale of the Heike of 1330, and also a quote in the KDJ attributed to the 名語記 (Myōgoki) dating to 1275. Would that qualify as Middle Chinese? ‑‑ Eiríkr Útlendi │Tala við mig 01:17, 17 January 2018 (UTC)
@Eirikr Those timepoints are around the transition of Middle Chinese to Old Mandarin, etc. "Literary Chinese" (linking to #Chinese) would be a better option IMO, corresponding to kanbun in Japanese. Wyang (talk) 08:09, 17 January 2018 (UTC)
In my understanding of things, Middle Chinese is a theoretical phonological system, and Literary Chinese is the established written language. I suppose the pronunciation comes from the former, while the rest of the word comes from the latter. —suzukaze (tc) 09:06, 17 January 2018 (UTC)


I know we're phasing this template out, but can someone at least make it add entries to the same categories as t-check? It's used in several hundred entries but has no function. Ultimateria (talk) 17:35, 18 January 2018 (UTC)

@Ultimateria: You have to add this somewhere, but I don't know exactly where.

-->{{categorize<!-- -->|{{{1}}}<!-- -->|Requests for review of {{#invoke:languages/templates|getByCode|{{{1}}}|getCanonicalName}} translations<!-- -->}}<!--

Could you unlock the template? --Per utramque cavernam (talk) 18:32, 19 January 2018 (UTC)

You can see the code, right? There's a line in there that looks exactly the same to me. Ultimateria (talk) 19:15, 19 January 2018 (UTC)


Does someone what's happening with {{R:ru:Vasmer}}? --Per utramque cavernam (talk) 20:57, 18 January 2018 (UTC)

It seems like this edit by @Sgconlaw caused it. The link brackets are being wrapped in HTML spans. —suzukaze (tc) 21:14, 18 January 2018 (UTC)
Solved. Per utramque cavernam (talk) 21:44, 19 January 2018 (UTC)

Cross categories[edit]

I often wonder how much sense it makes to hard code new subcats, such as CAT:English compound adjectives (which I'm adding in the least efficient way possible: by hand).

Is there no easy way to cross categories (CAT:English compound words + CAT:English adjectives) and get the same result? --Per utramque cavernam (talk) 21:10, 18 January 2018 (UTC)

Well, you can search incategory:"English compound words" incategory:"English adjectives". — Eru·tuon 21:15, 18 January 2018 (UTC)
AutoWikiBrowser can also compare the contents of two categories and find pages that are in both, though there is a limit to how many pages it will pull from a category. And PetScan may work for this (I haven't tried it out). - -sche (discuss) 22:02, 18 January 2018 (UTC)
@-sche: Hmm, I looked at AWB before posting but didn't see an obvious way to do that. Is it somehow possible with the "set operations" in the "filter" dialog? — Eru·tuon 22:12, 18 January 2018 (UTC)
In "Tools", there's a feature called "List comparer", which gives the option of generating lists based on categories (optionally including subcategories) or other criteria, and then comparing them. But it maxes out at 25,000 pages. - -sche (discuss) 22:41, 18 January 2018 (UTC)
PetScan gives 2268 results for the intersection of the categories. I wonder how many of the words that would belong in the category you are trying to populate do not have etymologies (eg, third-person) or have etymologies not using {{compound}} or hard categorization into Category:English compound words. DCDuring (talk) 22:56, 18 January 2018 (UTC)
Many, if not most of them, I'd say. --Per utramque cavernam (talk) 12:49, 19 January 2018 (UTC)
@Erutuon, -sche, DCDuring: Thanks! So I gather there are relatively easy ways to do that.
Would there be ways to convert the results in hard data, and if yes, would we want to do it? In other words, do you like having hardwritten subcats like CAT:English compound adjectives, or do you find it totally expendable? --Per utramque cavernam (talk) 12:49, 19 January 2018 (UTC)
@Per utramque cavernam: I have no objection to a separate category. None of these methods are terribly convenient or obvious, and we already have categories that are the intersection of two or more other categories. I do wonder how to easily add words to this category. At the moment, {{affix}} has a |pos= parameter, which puts words in part-of-speech subcategories of affix categories (English adjectives suffixed with -en). That would be the natural name for the parameter that puts words in a "compound adjectives" category, but using it might create a mess in affix categories. — Eru·tuon 19:55, 19 January 2018 (UTC)
Another name should be preferable, because {{l}}'s pos= means something completely different. It's not the same as {{affix}}'s pos=, which entirely replaces the main derivation category, and I'm trying to deprecate it as it is. —Rua (mew) 20:41, 19 January 2018 (UTC)
Can't we put a link to a special search of the members of the intersection of the two categories on the category page, pending some way of autocategorizing the terms that ought to be in the category? DCDuring (talk) 22:55, 19 January 2018 (UTC)