Wiktionary:Grease pit/2018/January

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.

--Aearthrise ^{(Ⲁⲉⲁⲣⲑⲣⲓⲥⲉ)} 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?

--Aearthrise ^{(Ⲁⲉⲁⲣⲑⲣⲓⲥⲉ)} 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)

I've decided to leave categories as they were for the time being. --Per utramque cavernam (talk) 13:42, 24 January 2018 (UTC)

Solved. --Per utramque cavernam (talk) 13:42, 24 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)? -84.161.39.40 06:18, 6 January 2018 (UTC)

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)

• We get rubbish ASL entries added very frequently. Could someone prevent the addition of such entries whose name does not include an "@" character? SemperBlotto (talk) 06:04, 6 January 2018 (UTC)
• @Chuck Entz? —Μετάknowledge^{discuss/deeds} 23:54, 7 January 2018 (UTC)

For those who come after, it looks like Chuck did update the filter and it is catching things. - TheDaveRoss 13:38, 24 January 2018 (UTC)

The French Wiktionary has entries of the form 1^er, 2^e 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 1^er, 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^er}}. -84.161.39.40 09:07, 6 January 2018 (UTC)

Solved. Per utramque cavernam (talk) 21:45, 19 January 2018 (UTC)

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

Solved. --Per utramque cavernam (talk) 13:42, 24 January 2018 (UTC)

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)

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 (t・c) 04:11, 9 January 2018 (UTC)

I agree. --Anatoli T. ^{(обсудить}/^вклад) 04:28, 9 January 2018 (UTC)

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:

Currently, "surjo" would be colored the same as the various forms of "haber". — This unsigned comment was added by RoseOfVarda (talk • contribs) 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)

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

{{desc|sog|-}}
: 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}}

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|-}}
: {{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, Syrc → sog-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 (t・c) 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. —Aryaman^{A (मुझसे बात करें • योगदान)} 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)

Solved. --Per utramque cavernam (talk) 13:42, 24 January 2018 (UTC)

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. —Aryaman^{A (मुझसे बात करें • योगदान)} 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:  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)

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

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)

Added. - -sche (discuss) 06:40, 31 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)

This problem doesn't seem to happen on Wikipedia, even though there is some content that is modified by JavaScript after the page loads, so I guess they must have a solution. But I couldn't spot anything in w:MediaWiki:Common.js that looks like it snaps the page to the anchor after the rest of the JavaScript has finished. — Eru·tuon 00:17, 27 January 2018 (UTC)

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

Resolved. ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:00, 26 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 (t・c) 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)

It does categorize entries in Category:Requests for review of X translations. Redboywild (talk) 11:41, 20 January 2018 (UTC)

I could swear it wasn't working the other day. Thanks. Ultimateria (talk) 16:50, 20 January 2018 (UTC)

Solved. --Per utramque cavernam (talk) 13:42, 24 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 (t・c) 21:14, 18 January 2018 (UTC)

Solved. Per utramque cavernam (talk) 21:44, 19 January 2018 (UTC)

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)

Hi there, I am an admin from Turkish Wiktionary. Recently, I have been working on this module which deals with declension of Turkish nouns all automatically, with no extra parametres needed. It is completed now (tr:Modül:tr-ad) and we started using it yesterday with the template tr-ad which is an equivalent of the template tr-noun exists here. But also, there are so many different declension templates on English Wiktionary and this causes some wrong outcomes such as on arı (tr:arı) entry, its not "arını" the definite accusative of the word, it is "arıyı".. Example: hava yastığı (tr:hava yastığı) I am suggesting that the module should also be used here. But I don't know where should I put this suggestion, and what to do exactly in these kind of situations. If someone could help and lead me the way, I'd be glad. :) ~ Z (m) 12:26, 21 January 2018 (UTC)

That is excellent work. It looks like Rua is working on a Module:tr-nouns here to copy the success of yours. —Μετάknowledge^{discuss/deeds} 20:58, 21 January 2018 (UTC)

I'm finding a lot of errors in our existing inflection tables, most of them apparently from User:Sae1962. This is far from the first time that we'd have to clean up after this user. —Rua (mew) 23:02, 21 January 2018 (UTC)

Wow, Rua. I’m fascinated with your work. I am a starter to Lua, so don’t know it very well. But if you don’t mind I am gonna copy some of your codes into Turkish Wiktionary’s module. The first time, I completely understand a module (which part handles which) on here. ~ Z (m) 23:55, 21 January 2018 (UTC)

Oh wow, that's very kind of you to say. Thank you! —Rua (mew) 00:11, 22 January 2018 (UTC)

Hello, I would like a new template to be created for pronunciations of Manchu words in different accents. For example, the word ] is pronounced

• in standard pronunciation: /ap.qʰa/
• in Peking dialect: /ap.qʰa/, /aw.qʰa/, or /aw.χa/
• in Alcuka dialect: /au.χa/
• in Sibe vernacular: /av.qʰa/
• in Ningguta dialect: /ap.qʰa/, or /ap.χa/

Accents of Manchu include standard pronunciation (deduced from its spelling, or recorded in 御製清文鑑), Peking dialect (recorded in 清文啟蒙 and 满语杂识), Sibe vernacular (recorded in 锡伯语简志 etc.), Alcuka dialect, Ningguta dialect, Mukden dialect (all recorded in 满语杂识), and recently recorded Ilan Boo (Sanjiazi) living dialect. I'm not familiar with Wikimedia templates and computer programming, could anyone help to create such a template please? (It doesn't require knowledge in these dialects.)--Pawmot (talk) 09:01, 22 January 2018 (UTC)

I think I can help you with this. It sounds like the standard pronunciation can be inferred from the spelling, but the rest have to be entered manually- is this correct? Wyang (talk) 09:49, 22 January 2018 (UTC)

@Wyang Yes, it is correct. Thanks for your help. --Pawmot (talk) 07:58, 23 January 2018 (UTC)

@Pawmot No worries! I will create it soon. Can you please add more examples of the standard pronunciation to Module:mnc-translit/testcasesModule:mnc-IPA/testcases, in examples under the function tests:test_all? Thanks. Wyang (talk) 08:21, 23 January 2018 (UTC)

@Wyang I don't know much about programming. I have list them at User:Pawmot/mnc-pron. --Pawmot (talk) 10:52, 23 January 2018 (UTC)

@Pawmot Thank you, I have written the template and module structure for it- please see {{mnc-IPA}} and Module:mnc-IPA and let me know if there need to be any changes. Wyang (talk) 14:22, 23 January 2018 (UTC)

@Wyang Thanks, but I think Mukden dialect and Sanjiazi dialect could also be added (though in the example of ] I have yet to find its pronunciation in these two dialects).--Pawmot (talk) 17:34, 23 January 2018 (UTC)

@Pawmot Ok, both are added to the module now. Thanks for the recent Manchu entries by the way! Wyang (talk) 08:28, 24 January 2018 (UTC)

Only of interest to those dealing with non-Latin scripts: I created User:Erutuon/scripts/watchlistScriptTagging.js to script-tag mainspace and Talk namespace links in Special:Watchlist, Special:RecentChanges, and Special:RecentChangesLinked. See above for more information on the script detection. The script detection function in User:Erutuon/scripts/scriptRecognition.js can be used by other scripts.

Unfortunately, the script only runs when the page is first loaded; when the list is refreshed with the "View newest changes" button, the script tagging vanishes. My scant understanding of how enhanced recent changes feature works prevents me from fixing this. — Eru·tuon 22:35, 22 January 2018 (UTC)

Probably it has disappeared only to resurface: at the greek lemma αβγό I cannot see the link for el.wiktionary/el:αβγό (2018.Jan) (at the left hand menu where other-lang-wiktionaries are). Perhaps I missed it. By the way, isn't it there a policy to always have visible the mother language of a word? Thank you. sarri.greek (talk) 19:42, 23 January 2018 (UTC)

It looks like there's definitely something wrong: the el-wiktionary entry has an interwiki link to our entry, but our entry doesn't have a link to the el-wiktionary entry. Looking at the URLs, our entry has it encoded as "%CE%B1%CE%B2%CE%B3%CF%8C", which exactly matches the "%CE%B1%CE%B2%CE%B3%CF%8C" encoding for the el-wiktionary entry- so there are no hidden characters in the entry names to cause a mismatch. The only thing out of the ordinary is an edit on January 18 that converted the el-wiktionary entry to a redirect (to el:αυγό), but that was reverted 6 minutes later

This is now all done automatically by the system, but it's new enough that there could still be a bug or two. Very odd... Chuck Entz (talk) 04:35, 24 January 2018 (UTC)

"Call me a cab, Blotto!" I cried, and making my way past a flustered Chuck on the stairs, I rushed out of my chambers. I had, of course, realised that the villainous Moriarty was behind the theft of the interwiki, but how to prove it? And how to bring the police to the scene before the interwiki was loaded onto one of the local boats (no doubt concealed in a candlestick or an etymology) and thence transported beyond the reach of the law? "Blotto," I said, "I will only ask you to do this once. Run to the Tea Room and fetch --PLEASE SUBSCRIBE TO READ MORE OF THIS STORY-- Equinox ◑ 05:46, 24 January 2018 (UTC)

Hey, watch what you're doing! You're an "h" and a spoonerism away from something very rude... Chuck Entz (talk) 09:06, 24 January 2018 (UTC)

Gentlemen! Thank you for your help and your sense of humour, suited very well with this case. I guess it was vandalism, and as Chuck pointed out, it happened on the 18th of Jan. I have sent a message to el.wiktionary. We greeks have been fighting over αβγό and αυγό for some decades. It seems that an opponent of αβγό has stricken. Thank you, sarri.greek (talk) 09:32, 24 January 2018 (UTC)

{{affix|ru|ponter|-и́ровать|lang1=fr}}

Why is this template linking to learned borrowing? It doesn't make sense to me. Please see понти́ровать (pontírovatʹ). --Anatoli T. ^{(обсудить}/^вклад) 11:31, 24 January 2018 (UTC)

@Atitarev: It's done in this line of Module:compound, whenever there is a numbered |langN= parameter: return require("Module:etymology").format_borrowed(lang, terminfo, sort_key, false, true). The last parameter, true, makes it be formatted as a learned borrowing. It looks like @Rua added this code in this edit in 2016. — Eru·tuon 21:32, 24 January 2018 (UTC)

I can understand making it a borrowing, but not a learned borrowing. —Rua (mew) 21:39, 24 January 2018 (UTC)

@Rua, Atitarev: I agree, and made it so. — Eru·tuon 21:50, 24 January 2018 (UTC)

@Erutuon, Rua: Now that {{bor}} has no "Borrowing from" text unless it's specified with |withtext=, could {{af|lang1=xy}} please exhibit the same behavior? At the moment you can't even suppress the text with |notext=. —Mahāgaja (formerly Angr) · talk 20:49, 25 January 2018 (UTC)

Reporting an error. Quote: "This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Prank vandalism"
Edit I wanted to make: Create gegäten with three citations for attestion.
Alternative edit I wanted to make: Report the error at Wiktionary:Grease pit/2018/January and post the content which should have been in the entry (so the content can be seen and discussed, and so it doesn't get lost). -84.161.53.59 14:48, 24 January 2018 (UTC)

PS: Posting it in several steps (it became 5 edits instead of 1) worked somehow and gegäten does now exist. ... -84.161.53.59 14:52, 24 January 2018 (UTC)

I'm not sure what went wrong, but please (if it will let you) create an entry for the main form gäten and move the citations there. We don't usually list citations for inflected forms unless the existence of that specific inflected form has been called into question. —Mahāgaja (formerly Angr) · talk 15:20, 24 January 2018 (UTC)

Without revealing the details of the filter because it's private, it seems like your edit contained (validly, in this case) two strings that it stops (but some of the edits it did allow seem to also contain both strings?). Looking through the history of edits the filter has caught, I'm surprised that yours appears to be the first non-vandal edit to have triggered it; I would've expected more, given how broad the filter appears to me to be. In the first five months of 2017, it stopped 15 vandals (who often tried to re-edit the same page a couple of times), an average of three a month; after that, nothing triggered it, until earlier this month it stopped four edits which, although vandalism, do not appear to be the kind of vandalism it is aimed at. I wonder if it should be set to only tag and not block, since the problem it is aimed at appears so slight. PS, if you ever make an edit that the abuse filter blocks, it can be recovered from the "abuse log" by an admin, if you lose your local copy of what you were adding. - -sche (discuss) 15:28, 24 January 2018 (UTC)

@Mahāgaja: It was only movable in steps and not in a single edit. (The reasons why I didn't create it as a main entry in the beginning: 1. German verb templates are complicated. 2. I didn't know how it inflects - and I'm still not fully aware of the inflection, namely if gäten, jäten, jeten or maybe geten were fully strong in older NHG.)

@-sche: Could the edit length matter? A single edit was blocked, but split into multiple edits without changing the content it worked. Also I once had the impression that "" with more than 3 dots got blocked, but at Wiktionary:Sandbox it now did work. Maybe it too worked because of the length -- or maybe it worked because the edit was done in the wrong name space or more specific in the sandbox, or because the filter got changed, or the filter blocked something else.

-84.161.53.59 15:54, 24 January 2018 (UTC)

Template:User lang returns the Babel boxes for user pages. The left part of the box links to the appropriate ISO 639 page on Wikipedia for the language code. But this doesn't work for subcategories of languages (such as en-US). Affected pages are: Template:User en-CA-N, Template:User en-GB-4, Template:User en-GB-N, Template:User en-US-N.

The robust fix would be to replace

''']'''

'''*}}|{{{1}}}]]'''

''']'''

Preferences? -Stelio (talk) 16:43, 25 January 2018 (UTC)

I found some more affected language codes: Template:User art-top-4, Template:User cel-pro-1, Template:User gem-pro-1, Template:User gem-pro-2, Template:User gem-pro-3, Template:User ine-pro-1, Template:User ine-pro-2, Template:User roa-tar-1, Template:User sla-pro-1.

Whereas these are not affected: Template:User gmq-bot-0, Template:User gmq-bot-1, Template:User gmq-bot-2, Template:User gmq-bot-3.

So another workaround is to add additional redirects on Wikipedia (which is what has been done for "gmq-bot"). -Stelio (talk) 17:44, 25 January 2018 (UTC)

Actually, the module name is in lowercase on Wiktionary: {{#invoke:string|match|...|...}}. — Eru·tuon 19:01, 25 January 2018 (UTC)

Ha ha! Brilliant. :-D So it is. Well, that makes the whole thing a lot easier to solve, then. Thank you! -Stelio (talk) 21:12, 25 January 2018 (UTC)

Updated request:

• Could someone with the appropriate rights edit Template:User lang to replace:

''']'''

with:

'''*}}|{{{1}}}]]'''

please? -Stelio (talk) 21:12, 25 January 2018 (UTC)

@Stelio (I can implement that if we can't come up with something that will fix even more entries, but) It looks like that change still leaves e.g. Template:User cel-pro-1 linking to w:ISO 639:cel-pro. Is there a way to make it link only to the part before the first hyphen, which should always be a valid ISO language or family code? Alternatively, perhaps we should enable individual languages' templates to suppress the link. (We could, of course, redirect w:ISO 639:cel-pro to w:Proto-Celtic language, but having even a redirect suggest that "cel-pro" is an ISO code seems undesirable, especially from the point of view of a Wikipedian seeing that it only exists to work around a problem in one of our templates.) - -sche (discuss) 16:11, 26 January 2018 (UTC)

It looks fine to me, @-sche. Here is the result of the match statement for "cel-pro-1": cel. For me, that is resolving to "cel" as required. Check the underlying wiki code to verify; the match statement returns the part of the string before the first hyphen. -Stelio (talk) 16:46, 26 January 2018 (UTC)

@-sche You need to update {{User lang-1}}, there is a different template for each language level. The new code works fine on {{User en-CA-N}}. Redboywild (talk) 18:48, 26 January 2018 (UTC)

Aha; well-spotted; thank you! That does the trick. :) - -sche (discuss) 18:56, 26 January 2018 (UTC)

I'm noticing a weird bug when using |pos= in {{l}} in languages that are RTL, ex. {{l|ae|𐬟𐬭𐬀𐬉𐬌𐬱𐬌𐬌𐬁|pos=1sg.pres.}} >> 𐬟𐬭𐬀𐬉𐬌𐬱𐬌𐬌𐬁 (fraēišiiā, 1sg.pres.). @Erutuon? --Victar (talk) 23:52, 25 January 2018 (UTC)

@Victar: It's because of a right-to-left mark at the end of the Avestan-script text in the second parameter. (The experimental wikitext syntax highlighting feature, available in "Beta features" in Preferences, makes this character visible to me.) The mark is carried through into the transliteration, and it makes the text direction change: the sequence of characters ", 1" is displayed right-to-left, then text reverts to left-to-right immediately before the sequence "sg". — Eru·tuon 00:11, 26 January 2018 (UTC)

@Erutuon: Huh, I wonder how that snuck in. Thanks! --Victar (talk) 00:19, 26 January 2018 (UTC)

On Thesaurus:fudge packer,

{{ws beginlist}}

• play hide the sausage {{qualifier|Australia|New Zealand|slang}}

{{ws endlist}}

gets broken into two columns with awkward whitespace between "New" and "Zealand", like:

• play hide the sausage (Australia, New                Zealand, slang)

Is there a way to ensure that an individual line stays in one column? - -sche (discuss) 16:23, 26 January 2018 (UTC)

@-sche: It appears normal on my browser anyway, so I can't test whether this will work, but try {{qualifier|Australia|New Zealand|slang}} and see what happens. —Mahāgaja (formerly Angr) · talk 20:23, 26 January 2018 (UTC)

Then the break happens between "Australia" and "New Zealand". Try changing the text size or the width of your browser window, or previewing the page with several more country names added to the label, and you may be able to trigger it: when I set the text size small enough and my browser window large enough that everything fits on one line, it doesn't get broken, it's only when some text reaches the end of the column's width that instead of wrapping around onto another line, it gets put into the next column (for me, in Firefox and Edge). It seems like whatever function splits the text into columns just sees "text that takes N lines to display" and splits the N lines evenly across the columns, without regard to keeping bullet points together, as would seem sensible. If I set my browser window small enough or look at the mobile version of the site, it looks like:

• play    the             New

hide    sausage    Zealand

           (Australia, slang)

- -sche (discuss) 20:49, 26 January 2018 (UTC)

{{given name|male|or=female}} and {{given name|female|or=male}} should categorize into " unisex given names", right? But on Aaju it does not. I noticed this while looking at entries which are categorized as both male and female given names, but not as unisex. - -sche (discuss) 18:40, 26 January 2018 (UTC)

We already have {{R:SAOL}}, which provides a link to SAOL 13. However SAOL 14 is now available online (since September last year) so no doubt there will be demand for this eventually. It's not a word list like SAOL 13, so I'm not sure how we deal with it. For example frilufts- and friluftsliv. I was accessing it through here DonnanZ (talk) 22:50, 26 January 2018 (UTC)

As pointed out on Talk:anonymous, uses of Template:en-noun and Template:label on that (talk) page were, until until this edit, categorizing the talk page into "English lemmas", "English nouns", "English countable nouns" and "English internet slang" (as well as the expected and desired RFV categories). I fixed that specific talk page, but I thought Template:head (etc) and Template:label had code that stopped them from categorizing pages in the talk namespace. Talk:blag and many other pages are still affected; a general solution is preferable to playing "deploy-{{temp}}"-whack-a-mole. - -sche (discuss) 05:40, 28 January 2018 (UTC)

@Erutuon, Rua, I could've sworn this had been dealt with a while back. What happened? —Μετάknowledge^{discuss/deeds} 08:37, 28 January 2018 (UTC)

Hmm. All these templates use Module:utilities for formatting categories. Categories used to not be added to the "Talk" namespace until this edit by @Daniel Carrero. He also added the Appendix talk, Reconstruction talk, and Category talk namespaces in the next edit. (Later I moved the namespaces to Module:utilities/data.) Maybe there's a case that I can't think of in which categories are added to talk namespaces? — Eru·tuon 08:51, 28 January 2018 (UTC)

The edit should be undone. The whole purpose of the code is to prevent it from being added to random namespaces. —Rua (mew) 12:34, 28 January 2018 (UTC)

I've removed the talk namespaces. I think we should also stop categorizing Citations: namespace pages, right? It seems to me that a citations page with e.g. "{{label|en|computing|slang}} the foobarizer" on it, or even one formatted like a full entry with {{en-noun}} as happens sometimes, should not categorize because it is either storing more citations for a sense which exists on the main page (and thus, duplicating it in CAT:en:Computing etc), or storing citations for a sense which isn't on the main page because it doesn't meet CFI yet (and so shouldn't be in the category). - -sche (discuss) 21:43, 28 January 2018 (UTC)

Are citations pages not categorised at all? —Rua (mew) 22:09, 28 January 2018 (UTC)

Most categories shouldn't be added to citations pages, but looking at a random citations page, Citations:great-grandchild, I see categories that should be there, and they are added with {{cln}} and Module:utilities by {{citation}}. If {{citation}} were Luaified, then category addition can be forced using the force_output flag (which is not available from {{cln}}), and the Citations namespace can be removed from the list. — Eru·tuon 22:43, 28 January 2018 (UTC)

I've created Module:User:Erutuon/citations, and it's being tested in {{citation/sandbox}}. — Eru·tuon 02:09, 1 February 2018 (UTC)

The template {{ux}} should not categorize pages not in main namespace (e.g. Talk:at the time). Please fix it.--Zcreator (talk) 17:06, 30 January 2018 (UTC)

See above. —Rua (mew) 17:09, 30 January 2018 (UTC)

Done. DTLHS (talk) 17:18, 30 January 2018 (UTC)