Wiktionary:Grease pit/2019/January

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← December 2018 · January 2019 · February 2019 → · (current)

---

Stripping of diacritics in word links

The page Reconstruction:Proto-Germanic/þeubaz contains a list of descendants of the Proto-Germanic noun *þeubaz, meaning "thief", and in that list, the following code appears:

** Old Danish: {{l|gmq-oda|thiūf}}

This outputs the line:

• • Old Danish: thiūf

As is seen, the link is red, although the page thiuf actually exists. Shouldn't the linking template automatically strip the macron and similar diacritics? Certainly that's the common practice with other languages. I'm aware that one could use {{l|gmq-oda|thiūf|thiuf}} as a workaround, but I see no reason why the template should not strip the macron. —Pinnerup (talk) 15:58, 1 January 2019 (UTC)

That would be controlled under gmq-oda in Module:languages/datax. As you can see there are no entry name rules. If you understand the orthography of Old Danish and want that behavior it could be added. DTLHS (talk) 16:00, 1 January 2019 (UTC)

I've added the entry name replacements for Old Swedish, which remove macrons, to Old Danish. Let me know if that is incorrect or if something more is needed. — Eru·tuon 20:56, 1 January 2019 (UTC)

Looks good. Thank you! —Pinnerup (talk) 03:47, 3 January 2019 (UTC)

@Erutuon I'm not sure if tying the data of two languages together like that is a good idea in the long term. A person wishing to edit the Old Danish diacritics in the future will not be aware that they are also used for Old Swedish. —Rua (mew) 14:31, 3 January 2019 (UTC)

@Rua: I'm guessing there won't be a problem in this case, but I've added a note. — Eru·tuon 20:20, 3 January 2019 (UTC)

Sorting Old Irish verbs into cats based on future, preterite, and subjunctive paradigms

So I attempted to modify Module:sga-verbs to categorize based on preterite class, subjunctive class, and future class, but I believe I botched it and now the categories won't show the pages that are categorized in them. mellohi! (僕の乖離) 22:01, 5 January 2019 (UTC)

Could you point to some pages that should have these categories but don't? — Eru·tuon 22:03, 5 January 2019 (UTC)

@Erutuon: I have created Category:Old Irish é future verbs, Category:Old Irish f future verbs, and Category:Old Irish s preterite verbs so far. mellohi! (僕の乖離) 23:12, 5 January 2019 (UTC)

@Mellohi!: Okay, but please give me some entries that should be in those categories so I can test the module and figure out what's wrong. I'm not familiar with Old Irish. — Eru·tuon 23:18, 5 January 2019 (UTC)

@Erutuon: dogní, etarscara, lingid, canaid, adsuidi, actually pretty much any Old Irish verb, e.g. the many in Category:Old Irish simple verbs. Go to those entries, click on the future/preterite/subjunctive verb categories, and right now they contain zero pages. mellohi! (僕の乖離) 00:03, 6 January 2019 (UTC)

@Mellohi!: As far as I can tell, your changes are working. You need to look at the list of categories in the entries, not at the category pages. When I look at dogní, it has a bunch of categories like Category:Old Irish é future verbs on it. The category pages will eventually update. Category updates take a while. If you do a null edit on one of these entries (I just did one on dogní), it will show up on the category pages. — Eru·tuon 00:12, 6 January 2019 (UTC)

Ah, I initially thought that slow-updating cats were the reason when filing this question, and indeed it is. Thanks for confirming. mellohi! (僕の乖離) 00:23, 6 January 2019 (UTC)

They've broken the Delete page again

Now, if you have the input focus on the Reason text box, and press Enter, instead of the natural behaviour of submitting the form (by activating the Delete button), it instead — bizarrely — drops down the Reason list box to show the list of reasons! I have never before seen a UI where you could drop down a list using the keyboard when the list wasn't focused! And as usual this needless change violates my operating system's UI laws; they should always, always use standard GUI components unless absolutely necessary. Equinox ◑ 01:49, 10 January 2019 (UTC)

B-b-but my hipster JS enhancements :^(

Perhaps you could file a bug on Phabricator. —Suzukaze-c◇◇ 04:46, 10 January 2019 (UTC)

 Done [1] Hardly know why I bother though. Bet they will either sit on it for a year or slap a WONTFIX and yell at me. Equinox ◑ 15:32, 11 January 2019 (UTC)

Well, they fixed it very fast and nobody snarked about my (IMO somewhat justifiable) nasty tone. So, double thumbs up. Equinox ◑ 22:18, 21 January 2019 (UTC)

Font size in template:l

In the last few hours some change has taken place that has led items enclosed in {{l|mul}} to display in a larger font than if they were enclosed in {{l|en}}. Why? DCDuring (talk) 04:00, 10 January 2019 (UTC)

An example is [[amaranth]] on which what should (IMO) appear as Amaranthus blitum appears as Amaranthus blitum when presented as {{l|mul|Amaranthus blitum}}. On my screen using FF 64.0.2 the font size seems nearly 50% larger in the second instance on this page. DCDuring (talk) 04:36, 10 January 2019 (UTC)

I have the same version of Firefox, but don't see a difference. I also couldn't spot any recent changes in the module, template, or MediaWiki namespaces that could cause this. — Eru·tuon 04:48, 10 January 2019 (UTC)

In Chrome you can right click and inspect the link and see all the styles applied to it, and toggle them to see which one is causing the font size difference. DTLHS (talk) 04:50, 10 January 2019 (UTC)

The problem includes various other languages.

BUT: It doesn't happen in Chrome.

It doesn't happen if I eliminate FF's zoom (It doesn't happen with Chrome's zoom. I need zoom to read the screen without glasses.)

I hadn't changed zoom for many months. The problem seems specific to the link function only in certain languages. It doesn't happen on Translation tables. Is there a page that has a words linked via {{m}} or {{l}} in lots of different languages? That would be ideal for determining the scope of the problem, however limited the circumstances that trigger it. I know that some languages and/or scripts need to have large font sizes for legibility. I can't see why there should be differences in font size for Translingual and English unless there is something happening in CJKV that led to a non-script-specific change in font size. I presume that CSS could be involved. DCDuring (talk) 13:03, 10 January 2019 (UTC)

Translation adder script stopped working

The translation adder box just disappeared (on both Firefox and Edge). Matthias Buchmeier (talk) 12:38, 10 January 2019 (UTC)

Sorry for the trouble, fixed. — Eru·tuon 12:55, 10 January 2019 (UTC)

New language/family request

I'd like to request that language codes be added for Proto-Otomi, Proto-Otomian, and Proto-Oto-Pamean, as well as family codes for Otomi and Oto-Pamean. There is already a family code for Otomian (oto) but no corresponding protolanguage. --Lvovmauro (talk) 09:19, 11 January 2019 (UTC)

@-sche Can you suggest codes for these? DTLHS (talk) 17:44, 11 January 2019 (UTC)

Proto-Otomian would use the family code plus -pro, thus oto-pro. For the Oto-Pamean family, the code would start with the code for Oto-Manguean (the next level up that has a code), so something like omq-otp, so then Proto-Oto-Pamean would be omq-otp-pro. I think we generally have family codes any time we have proto-language codes, so we'd create a family code for the Otomi languages starting with the nearest (next-highest) family to it that has a code, so something like oto-otm, based on which the code for Proto-Otomi would then be oto-otm-pro. (You don't have to categorize all the Otomi languages into the new "Otomi" family if you'd rather leave them in Otomian, I guess, but this way etymologies can say "from an Otomi language", and the systematic correspondance between family codes and proto-language codes is maintained.) I'll add these codes. (If you would particularly prefer some other abbreviation for the second part of any of these codes, lemme know.) - -sche (discuss) 18:14, 11 January 2019 (UTC)

The ancestors for each (proto)language need to be added too, otherwise Template:inh gives an error (e.g. hme). --Lvovmauro (talk) 07:58, 12 January 2019 (UTC)

Template:zh-der results do not match description

On the template page, the example is given:

垃圾:lājī, lèsè:rubbish

but even this example doesn't actually work on either the 垃 or 圾 pages (at least in preview). It treats the English translation as a Chinese romanization (italicizes it).

--Geographyinitiative (talk) 10:05, 11 January 2019 (UTC)

"etymology-only" script codes

@Erutuon, Octahedron80, -sche, I've talked about this before, but I'm wondering about the feasibility of having "etymology-only" script codes for historical and language specific nomenclature, like we do for language codes. For instance, Avst-paz or paz-Avst for Pazend, which can be used in cases like {{desc|sc=Avst-paz|sclb=1}} and {{sc|Avst-paz}}. It's been noted before that some of the codes in Module:scripts/data shouldn't have proper language codes of their own, like mzn-Arab. --{{victar|talk}} 21:00, 14 January 2019 (UTC)

Alternatively, in the cases of language specific script names, that could be defined with the language code itself. I'm also thinking about cases like {{der|fa|pal|sc=Avst|sclb=1}} => Pazend Middle Persian, instead of creating a language code like pal-paz. --{{victar|talk}} 21:36, 14 January 2019 (UTC)

I think to create "pal-Avst" is enough. (pal = Middle Persian) The language code-script code notation is already used for script variations. It can be used anywhere not limited to etymology. And we can also set a specific (Pazend) font for it. While "Avst" should be generic Avestan script. --Octahedron80 (talk) 01:31, 15 January 2019 (UTC)

@Octahedron80: I would be fine with that, but I was told that that isn't recommended (also note that I linked Module:scripts/data above already). @Erutuon, -sche? --{{victar|talk}} 02:36, 15 January 2019 (UTC)

@Wikitiki89, Erutuon, -sche, have you changed your opinion on this? How should I proceed? --{{victar|talk}} 19:46, 18 January 2019 (UTC)

@Victar: I'm thinking it's best not to add script codes to Module:scripts/data unless they will be used in language-and-script tagging. But what to do is not clear to me, because I'm not aware of all the places where these special script codes or script labels would be used. It would be helpful if you made a page listing the places in entries where you see a need for these special script labels and what templates they would be used in and possible template syntax: etymology section, descendants section, etc.; {{desc}}, {{der}}, etc. Our system of labels is quite baroque and complicated and I am not sure where these script labels would fit in, or if they would at all. — Eru·tuon 22:17, 18 January 2019 (UTC)

@Erutuon: What are your objections? --{{victar|talk}} 23:34, 18 January 2019 (UTC)

@Victar: To what? — Eru·tuon 23:34, 18 January 2019 (UTC)

@Erutuon: What are your objections to adding pal-Avst to Module:scripts/data. --{{victar|talk}} 23:36, 18 January 2019 (UTC)

@Victar: If it's just for a label, then it's different from most of the scripts already there and I guess it would need different data items; for instance, if it's not used in language-and-script tagging it would not need a list of characters because it would never be used in language data modules or returned by script recognition functions, but it would need label-related information. But I dunno; as I said, I need more information. — Eru·tuon 23:55, 18 January 2019 (UTC)

@Erutuon: Is it really "different from most of the scripts already there"? What makes it different from ku-Arab? --{{victar|talk}} 00:02, 19 January 2019 (UTC)

Oops, I didn't notice you said paz-Avest. That's different in that it isn't a combination of a valid language code and script code. paz is the language code for Pankararú, Avest isn't a script code but could be replaced with Avst. It also would be different from ku-Arab if it weren't used in language-and-script tagging (ku-Arab is used). — Eru·tuon 00:13, 19 January 2019 (UTC)

That was a mistype, which I corrected. I'm referring to what Octahedron80 suggested (and my original suggestion), using pal-Avest. How would that be different from ku-Arab? --{{victar|talk}} 00:18, 19 January 2019 (UTC)

Okay though that should be pal-Avst. If pal-Avst would not be used in language-and-script tagging, then it would be different from ku-Arab, which is. — Eru·tuon 00:35, 19 January 2019 (UTC)

@Erutuon: do you have an example of ku-Arab being used in "language-and-script tagging"? --{{victar|talk}} 00:38, 19 January 2019 (UTC)

@Victar: Search : insource:"ku-Arab" or : insource:"ku" insource:/ku\|[؀-ۿݐ-ݿࢠ-ࣿﭐ-﷽ﹰ-ﻼ]+/ to find more than a thousand examples. — Eru·tuon 00:43, 19 January 2019 (UTC)

Is that all you mean? Sure, I could give you dozens of examples of places where I could be doing {{der|fa|pal|𐬞𐬭𐬌𐬭|sc=pal-Avst|tr=prir|ts=parīr}} or {{m|pal|𐬥𐬋𐬭𐬋𐬰|sc=pal-Avst|tr=nōrōz}}, like here. --{{victar|talk}} 06:37, 19 January 2019 (UTC)

Sorry, a script code is used for tagging (i.e., inserted into a class attribute in the HTML) if it is in a language's data table and is returned by the script detection function (findBestScript) or if it is manually supplied to a template or a module function that tags. "Etymology-only script code" suggested to me it wouldn't be used in tagging, just as, when an etymology-only language code is used in a template or module function, tagging uses the code for the first non-etymology-only language in the chain of parent codes. For instance, {{cog|grc-dor|μᾱχᾰνᾱ́}} tags the word with grc (Ancient Greek) instead of grc-dor (Doric Greek). Analogically pal-Avst could be replaced with its parent Avst in tagging. But I guess that is not what you meant and I should have asked for clarification. — Eru·tuon 23:01, 19 January 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Erutuon: Maybe I'm missing something, but I'm just not seeing a good argument of why a pal-Avst script code shouldn't exist. Another important distinction of Avestan script between Middle Persian and Avestan, beside font and ligatures differences, is that MP sometimes wrote the script in the style of an abjad as seen in my {{m|pal|𐬞𐬭𐬌𐬭|sc=pal-Avst|tr=prir|ts=parīr}} example. That makes a huge difference if someone is fulfilling Avestan script requests. --{{victar|talk}} 06:25, 21 January 2019 (UTC)

@Victar: Yes, that's what I meant to imply: whatever I said that assumed pal-Avst wouldn't be used in tagging doesn't apply. I'm not enthusiastic about adding yet another language-code-prefixed script code used for one language; it would be nice to get rid of as many of those codes as possible. A difference in CSS properties does not require a separate script code, but "Pazend" as script label can be most easily achieved that way. (I finally added the CSS properties that you requested on the other thread.) Other solutions would be a map from language code to script label in Module:scripts/data, or a map from script code to label in the language data tables, or a separate table somewhere. Those methods would require modifying module architecture, but adding pal-Avst doesn't. — Eru·tuon 21:29, 21 January 2019 (UTC)

• On the other thread about Pazend, it was proposed that the CSS selectors in MediaWiki:Common.css that use language-code-prefixed script classes could be replaced with a selector that combines a parent script class and language attribute (for example, .fa-Arab with .Arab:lang(fa)). I like this idea, but it means that selectors would be longer. I did a survey of the languages that use each of these script codes. Several of the language-code-prefixed script classes are used by multiple languages. fa-Arab is used by quite a few languages, so the selector .fa-Arab wherever it's used would have to be replaced with a very long list of selectors. So the proposal would greatly inflate some of the selectors in MediaWiki:Common.css (for instance, .fa-Arab → .Arab:lang(fa), .Arab:lang(avd), .Arab:lang(awa), ...). Maybe it would be fine to remove some of the language-code-prefixed script classes though, the ones used by fewer languages. I mention this because it is relevant to the question of whether to have or add more language-code-prefixed script codes, or whether to get rid of them. — Eru·tuon 00:02, 20 January 2019 (UTC)

Category talk

Please see Category talk:German proper noun forms.Jonteemil (talk) 21:57, 16 January 2019 (UTC)

Ping everyone.Jonteemil (talk) 15:27, 25 January 2019 (UTC)

Capitalization in {{causative of}} template

The template {{causative of}} can be used in etymology sections to mark a verb as a causative of another verb, thus furnishing the page with the proper categories for causative verbs (e.g. Category:Proto-Germanic causative verbs). However, the template seems to always result in the text:

 causative of lemma

… even at the beginning of a sentence, where a capital "C" would be required. Is there any way to work around this, say by suppressing the leading text or perhaps coding it to capitalize the first "c" when used at the beginning of a line? Or is there some other method that should be used to mark verbs as causatives of other verbs? —Pinnerup (talk) 12:09, 17 January 2019 (UTC)

This template is meant for use in definitions, which is why it has italic text. Definitions aren't usually capitalised. —Rua (mew) 12:54, 22 January 2019 (UTC)

Many templates have named parameters like i, noi; cap, nocap; dot, nodot. It would be possible, even desirable, to universalize this. The default settings should reflect the most common current usage.

In the case of definitions of non-English words, prevailing practice is not to capitalize the first word of the definition, nor to end with a period ("dot"), contrary to the prevailing practice in English (and taxonomic) definitions. As it also provides a non-gloss definition, its text is italicized. Thus {{causative of}}, by default would have i, nocap, and nodot as defaults in my parameter scenario. DCDuring (talk) 13:29, 22 January 2019 (UTC)

I suppose categorization is also a concern. nocat and cat would be another pair of parameters. In a definition we probably want categorization, we almost certainly don't want {{causative of}} to categorize if it is used in etymology sections. The default would be cat.

The alternative of having pairs of templates with consistent naming, one for use in definitions, another for use in other places seems to me less desirable. DCDuring (talk) 13:37, 22 January 2019 (UTC)

"Pronounciation"

It seems like there are up to 2,524 entries with the following header: ===Pronounciation=== which is a misspelling of ===Pronunciation=== (Search here). KevinUp (talk) 19:22, 18 January 2019 (UTC)

Looks like a job for a bot. --{{victar|talk}} 19:44, 18 January 2019 (UTC)

@Suzukaze-c Maybe you can help with this? There's also ===Reference=== instead of ===References=== (1474 entries, search here)). KevinUp (talk) 06:53, 20 January 2019 (UTC)

Thanks to User:350bot, this job is now  Done. KevinUp (talk) 18:51, 21 January 2019 (UTC)

Category:German redlinks/l

I wish there's a hidden category like Category:Portuguese redlinks/l, but for German entries. --Lo Ximiendo (talk) 22:31, 18 January 2019 (UTC)

Why isn't there one? I don't see any special provision for Portuguese entries in the code. – Jberkel 12:54, 19 January 2019 (UTC)

See {{redlink category}}. The problem with adding a language to this is that it adds system overhead to every linking template (which includes translations), and there are many entries right on the edge of running out of execution time or memory. Chuck Entz (talk) 19:25, 19 January 2019 (UTC)

Oh, I understand now, I hope. --Lo Ximiendo (talk) 03:13, 20 January 2019 (UTC)

Vector hieroglyphs

I asked about SVG support for hieroglyphs in MediaWiki and there's now a ticket: phab:T214232. I'm not really familiar with our requirements so just wanted to post this here in case it needs more input, or if you have any recommendations for fonts to use. @Vorziblix, Aearthrise – Jberkel 11:28, 19 January 2019 (UTC)

@Jberkel: SVG images would be nice. Would they be much slower to load than the current ones?

In the ticket there’s a mention of making ‘a map between our 2004 images and the hieroglyphs that were added to unicode in 2009’ to see what the overlap and discrepancies are. As it turns out, a year ago I made such a map; it’s available at User:Vorziblix/Mismatches between WikiHiero, Hieroglyphica, and Unicode and quite complete in its documentation of mismatches. (Any glyph that doesn’t appear there exists in both sets of glyphs and has the same Gardiner code in each). I hope it can be useful.

As far as fonts go, the Abydos font (which is ‘Free for any use’) is, IMHO, by far the best free font available for hieroglyphs at present. It covers not only the glyphs currently in Unicode but the much larger Hieroglyphica sign-list. Like WikiHiero, it has some mismatches with Unicode; the full correspondence is documented here: Module:Unicode_data/images/013. The Windows font Segoe UI Historic is definitely unusable, as it censors out several hieroglyphs by replacing them with rectangles.

It’s worth noting that the Unicode situation vis-a-vis hieroglyphs will be rapidly changing over the next few years; control characters that allow proper stacking of glyphs will be encoded on 5 March of this year, and there are several proposals floating around for expansions of the Unicode glyph repertoire in the near future as well. — Vorziblix (talk · contribs) 22:49, 19 January 2019 (UTC)

Thanks for the detailed response! I just quoted it verbatim on the ticket, hope that's ok. On disk the SVGs are significantly larger than the PNG files, but they can be optimized and compressed, so I don't think it will be much slower. I had a look the Abydos font, unfortunately it does not seem to be license-compatible. – Jberkel 00:13, 20 January 2019 (UTC)

Automatically expand all Quotations sections and Derived terms sections

 Done Hi. Briefly: How can we make the auto-collapsed "quotations" templates and "Derived terms" templates all automatically expand on page-load?

Notes and example links: In my User:Quiddity/common.js I've got 2 parts.

1. The first part will sometimes successfully auto-expand the "Derived terms" (and similar) templates on page-load, e.g. it works at -logy#Derived terms, but not at time#Hyponyms and the related sections below that. (because of different templates being used in each case)
2. The second parts contain my unsuccessful attempts (re-using code found elsewhere) to get the "Quotations" templates to auto-expand, e.g. at time#Noun or at ology.

Is there a better (more reliable) way to do the first, and is there any way to do the second?

Sidenotes: I tried searching archives, but couldn't see anything. And disabling JS entirely is not an option ;-) Thanks! Quiddity (talk) 22:43, 19 January 2019 (UTC)

@Quiddity: To always display quotations you can just use "Show quotations" on the left sidebar, under "Visibility". This will be stored in a cookie and persist through reloads. – Jberkel 23:27, 19 January 2019 (UTC)

Huzzah! Thank you.

I was sure there had been a gadget to do this, hence was really confused when it wasn't listed there. Of course it's in the mediawiki:sidebar !

(I tend to use multiple browsers/computer/accounts for testing things, so I use userscripts to make things consistent across them all. Your pointer helped me find the appropriate cookie name/value, and it works :). Thanks again. Quiddity (talk) 01:10, 20 January 2019 (UTC)

Latin conjugation template lists wrong forms in ōdī

Hiya. Latin has three defective verbs that are quite similar in many regards and all use perfect forms, having deposed their entire present system, namely meminī, ōdī and coepī. The entry for ōdī seems to use a template designed for meminī and not entirely applicable to other verbs, for it lists mementō and mementōte as imperative forms. Clearly, these are not imperative forms of ōdī (which has no imperative forms), but I've not been able to see how to suppress them. The template seems not to have any relevant documentation. —Pinnerup (talk) 16:59, 20 January 2019 (UTC)

@Pinnerup Try changing the template to read like this:

{{la-conj-4th|ōd|ōd|ōs|type=perf-as-pres}}

Let me know if this generates a correct output. Benwing2 (talk) 02:57, 19 February 2019 (UTC)

nocat=y no longer works in {{affix}}

The template creates red-link categories even when the nocat=y paramter is added. There was a recent change in Module:compound/templates, could that cause this issue? Panda10 (talk) 16:08, 22 January 2019 (UTC)

Yes. User:Victar updated that page without updating the method signature of export.show_compound in Module:compound. DTLHS (talk) 16:13, 22 January 2019 (UTC)

Sorry about that, @DTLHS. I was adding a |g= parameter per this discussion. --{{victar|talk}} 17:23, 22 January 2019 (UTC)

It's ok, I'm just hoping the existing categories will eventually get back to their original state. For example, in Category:Hungarian words suffixed with -a, no words should be there, only the subcategory. Saving each entry without changes would help, but there are thousands of them. Panda10 (talk) 18:43, 22 January 2019 (UTC)

@Panda10, all categories will automatically update once the server cache clears. --{{victar|talk}} 03:58, 23 January 2019 (UTC)

Is it possible to trim images?

I added an image to ballerina, but I would like to trim the right-hand side; normally Commons do it. Is it possible on here? DonnanZ (talk) 00:17, 23 January 2019 (UTC)

Wikipedia has w:Template:Annotated image which appears to do this. We could probably copy / import it. We would need some more global CSS classes. DTLHS (talk) 02:01, 23 January 2019 (UTC)

That looks like a useful tool. I hope it doesn't slow image rendering too much. Can it be substed? DCDuring (talk) 03:08, 23 January 2019 (UTC)

It could be, but you would just get a bunch of raw HTML in the output. DTLHS (talk) 03:11, 23 January 2019 (UTC)

Commons also has a “CropTool“ (or something); it's in-browser and creates a new cropped upload. It might make reuse easier, if any one else also wants a cropped version. —Suzukaze-c◇◇ 03:21, 23 January 2019 (UTC)

• OK, there's nothing at the moment, and I'm not sure how often it would be needed. I think it would need to be something that can added to the uploaded downloaded image, something like crop=right=30px. DonnanZ (talk) 11:11, 23 January 2019 (UTC)

Does anyone know whether w:Template:Annotated image is noticeably slow? DCDuring (talk) 15:35, 23 January 2019 (UTC)

No, it shouldn't be slow- it just looks like it generates HTML with the appropriate CSS classes to apply various image effects, and there are no Lua modules at all. DTLHS (talk) 16:04, 23 January 2019 (UTC)

Thanks. DCDuring (talk) 19:05, 23 January 2019 (UTC)

Wiktionary shows an empty page after searching

Hi. Lately I have been not able to search for words in korean. I look for the word and it appears on the search but when a follow the link to the word's page... it appears empty.

That happens on my android cellphone and tablet. I don't have that problem.

How can I solve it?

Thank you — This unsigned comment was added by 161.18.82.154 (talk).

Mm, could it be the same problem as Wiktionary:Information desk/2019/January#Nearly blank page on m.wiktionary? —Suzukaze-c◇◇ 04:50, 24 January 2019 (UTC)

Generate rhymes from IPA?

Right now, we add rhymes manually to all pages, but it seems to me that these could be figured out automatically from the IPA pronunciation. Of course, there would be different rules for each language, but are there any particular reasons not to be doing this? —Rua (mew) 11:47, 26 January 2019 (UTC)

Well, the scarcity of IPA means that we won't want to get rid of the manual method, but that seems like a good idea, for the most part. The main caveat is that there's some context in the pronunciation sections that needs to be allowed for. The rhymes pages in English, for instance, are regularized to one regional pronunciation. For me, cot and taught rhyme, but the rhymes pages don't have the cot-caught merger.Chuck Entz (talk) 14:05, 26 January 2019 (UTC)

In addition to regional pronunciations, for English there's also the issue of different symbols for the same phoneme, like /ɪi/ or /ɪj/ in place of /iː/. (Not sure how common variant transcriptions are. /ɪi/ and /ɪj/ seem to be used on only a few pages: search incategory:"English terms with IPA pronunciation" insource:/ɪ[ij]/.) But for languages that don't have regional pronunciations or variant transcriptions to deal with and especially for those that have an IPA-generating module, I guess it would be pretty easy to automatically generate the list of rhymes. — Eru·tuon 22:04, 26 January 2019 (UTC)

Blocked, expiring never

XX is currently blocked, expiring never. But only recently did I notice the explanation: (owner is deceased). Could there be a special template for it? For userpages and contributions? sarri.greek (talk) 15:31, 26 January 2019 (UTC)

We don't need a template. See User:Robert Ullmann for example. —Μετάknowledge^{discuss/deeds} 16:49, 26 January 2019 (UTC)

Ow, I see Μετάknowledge. But not similar for others. Thanks. sarri.greek (talk) 08:30, 28 January 2019 (UTC)

Why is every single link to an Alemannic German word yellow (orange)??

If you have OrangeLinks on, just look at Category:Alemannic German lemmas. All yellow. If you click on the words it works fine but no Alemannic German link is not yellow, no matter how it is linked. Aare [[Aare#Alemannic_German|Aare]], Aare {{l|gsw|Aare}}, Alemannic German: Aare, Arm, Are, Arme, {{desc|gsw|Aare|alts=1}} etc. — Julia ☺ ☆ 15:50, 26 January 2019 (UTC)

I've noticed that happening with Old Armenian as well. I think @Erutuon has been working on the gadget recently. Per utramque cavernam 15:55, 26 January 2019 (UTC)

Been looking around, it's also happening with Ancient Greek, Old English, Sami languages, Lower Sorbian, Old Dutch, Tok Pisin, etc. Real random bunch. — Julia ☺ ☆ 16:02, 26 January 2019 (UTC)

Not completely random- they all contain a space in the name. Chuck Entz (talk) 16:13, 26 January 2019 (UTC)

Good catch, never would have noticed. — Julia ☺ ☆ 16:53, 26 January 2019 (UTC)

Fixed, I think! — Eru·tuon 21:08, 26 January 2019 (UTC)

T-needed isn’t removed with Norwegian

If T-needed is placed on only ”Norwegian”, it doesn’t get removed when adding a Norwegian Bokmål or Norwegian Nynorsk translation, even if you fill in both of them. See surströmming for example. Please fix.Jonteemil (talk) 14:48, 28 January 2019 (UTC)

 Done. You could have removed it yourself. DonnanZ (talk) 11:34, 29 January 2019 (UTC)

@Donnanz: Well, no s**t :). But what I meant was that the module be changed. I didn’t remove it so you could see it still being there eventough I added a translation.Jonteemil (talk) 23:33, 31 January 2019 (UTC)

@Jonteemil: The module changed in what way? So the template removes itself? I don't think that's possible, it is added manually, I think (I have never done it), so it has to be removed manually by the editor who adds a translation. Someone will correct me if I'm wrong. DonnanZ (talk) 23:45, 31 January 2019 (UTC)

The module changed so that t-needed is removed when you add a Norwegian Bokmål/Norwegian Nynorsk translatoon, even if it t-needed was placed on Norwegian. If it isn’t possible, it isn’t posssible but it doesn’t hurt asking.Jonteemil (talk) 23:50, 31 January 2019 (UTC)

What if the person who added t-needed for Norwegian really meant Bokmål, and the Nynorsk in that case was different from the Bokmål- would adding Nynorsk be the answer to their request? Chuck Entz (talk) 04:20, 1 February 2019 (UTC)

@Chuck Entz: In that case I think the user should’ve placed it after Norwegian Bokmål and not Norwegian.Jonteemil (talk) 11:46, 1 February 2019 (UTC)

@Jonteemil No doubt, but I would suggest that most non-speakers don't know that what they think of as just plain Norwegian is really Bokmål. How many Norwegian-English dictionaries even have "Bokmål" in the title? Chuck Entz (talk) 19:44, 1 February 2019 (UTC)

A good point, I have Einar Haugen's "Norwegian English Dictionary" on my desk, it actually covers both languages, and I think Haugen was a Nynorsk speaker. DonnanZ (talk) 10:14, 2 February 2019 (UTC)

You probably mean MediaWiki:Gadget-TranslationAdder.js? I may look into it, but I don't understand the gadget very well yet. — Eru·tuon 02:03, 1 February 2019 (UTC)

Flagged for Spam when not spamming

Hi I was trying to make a wikitonary page for "foppington's Law" a phrase which I haven noticed become quite common, and which I believe quite useful, on some parts of twitter, facebook, and reddit. I initally attempted to make a wikipedia page for it and, after realizing that it was better suited for wiktionary instead attempted to make it here. I believe making it first on wikipedia and then, upon realizing my mistake, secondly on wiktionary triggered an automated spam detection, which is funny considering wikipedia itself suggested I post it here on wiktionary. Anyways, I believe this is the proper channel to request that it go forward as I'm clearly not trying to spam folks.— This unsigned comment was added by ErnestBaum (talk • contribs) at 21:23, 28 January 2019.

You attempted to add numerous external links to places such as Reddit, Youtube, and a t-shirt company website as your first edit. This triggered the spam detection. You should try it without those links. These are inappropriate references and you should try to find examples of the term being used in print sources. DTLHS (talk) 21:27, 28 January 2019 (UTC)