Wiktionary:Grease pit/2017/December

Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2017/December. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2017/December, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2017/December in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2017/December you have here. The definition of the word Wiktionary:Grease pit/2017/December will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2017/December, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.

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

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.

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

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

{{IPAchar|]}}

The colon in ] 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 ]? —suzukaze (t・c) 00:58, 16 December 2017 (UTC)
actually, that doesn't currently work because {{IPAchar}} outputs an error category too: ]]]
Also, the current version of {{IPAlink}} doesn't even link to Wikipedia in the first place... —suzukaze (t・c) 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

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)

template:rfinfl

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)

Template:R:Duden

Needs a documentation and as far as I see another parameter. F.e. {{R:Duden|DUDENSPELLING}} produces " in Duden online". There should be a way to do something like {{R:Duden|DUDEN-SPELLING|WHATEVER}} to produce " in Duden online". -84.161.39.132 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. -84.161.39.132 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

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

@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">]</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: ], ]. Those will be converted into language links with language tagging: <span class="Latn" lang="en">], ]</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

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 (talk • contribs).

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

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">]</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

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

At ] 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 "" 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

Why are U+A651 (ꙑ) and U+A657 (ꙗ) 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)
@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

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

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

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 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 (t・c) 00:02, 17 December 2017 (UTC)

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

Traditional/Simplified grid

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)

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 entries —suzukaze (t・c) 20:24, 18 December 2017 (UTC))

How to note the absence of a translation in translation sections

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|] ]}}. 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 ] ]) 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

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

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

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

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)

Bringen

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

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

I'm puzzled. This entry appears in the category "Requests for attention concerning Finnish" . 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?

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)
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 (t・c) 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

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.orghttps://dictious.com/en/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

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

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

Wikious
Boobota
Sagapedia