Wiktionary:Grease pit/2017/July

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
discussion rooms: Tea roomEtym. scr.Info deskBeer parlourGrease pit ← June 2017 · July 2017 · August 2017 → · (current)

Puzzling error in template[edit]

{{itc-conj-3rd}} displays the 3pl pres. subj. pass. as *-ām(e?)n(ai?), like the 2pl, instead of as the correct *-āntor. However, looking at the source code, I can't figure out what's going wrong. --Florian Blaschke (talk) 23:17, 2 July 2017 (UTC)

Fixed, I think. --Barytonesis (talk) 23:24, 2 July 2017 (UTC)
Thank you, that seems to have done the trick! I should have looked at the beginning of the code, realised that the template is calling another template and looked there! D'oh. --Florian Blaschke (talk) 00:45, 5 July 2017 (UTC)
It's common for inflection tables to be made of two pieces, one to show the table, and another to provide the contents. —CodeCat 00:48, 5 July 2017 (UTC)

Request for CSS help[edit]

Can anyone come up with a CSS rule that allows content in <hiero> tags to be displayed inline? The tag generates a table that can be wrapped with a div element. The rule needs to allow the table to be on a line with preceding and following content and not affect subsequent lines. DTLHS (talk) 00:08, 4 July 2017 (UTC)

Isn't it already inline? Like
n M1
this. —suzukaze (tc) 00:54, 4 July 2017 (UTC)
I wonder how do you get it inline. All other wikis I tested do not display it inline. --Vriullop (talk) 10:42, 15 July 2017 (UTC)
I'd like to also be able to control the image sizes. DTLHS (talk) 00:55, 4 July 2017 (UTC)

Below is the thing that isn't displaying inline. I'm experimenting with it at the moment. — Eru·tuon 03:32, 4 July 2017 (UTC)

V17 w A3

 f (zꜣw)

1. I looked into the image sizes and I don't think it's possible with CSS. Maybe with JavaScript, by manually changing image dimension attributes.
2. <div>s are not inline by nature; you have to tell them to be inline!
V17 w A3
 f (zꜣw)
(Without the <div> on the outside, it seems like the MediaWiki software puts "f (zꜣw)" in its own <p>.) —suzukaze (tc) 03:53, 4 July 2017 (UTC)

An additional problem is hiero included in head template. Appart from the need of solving hiero line breaks, for example the gender in ꜥwꜣy, the page appears in Special:LintErrors/misnested-tag, see link https://en.wiktionary.org/w/index.php?title=%EA%9C%A5w%EA%9C%A3y&action=edit&lintid=634632. The misnested tag is strong tag surrounding headword with a hiero table. --Vriullop (talk) 10:13, 15 July 2017 (UTC)

Passing sortkey generation to a dedicated sorting function (recorded in Module:languages/data2)[edit]

for languages with difficult scripts (e.g. Tibetan, Chinese, etc.) - could this be implemented? Wyang (talk) 22:30, 4 July 2017 (UTC)

How large are the sortkey functions going to be? Is this going to increase the number of pages that run out of memory? DTLHS (talk) 22:37, 4 July 2017 (UTC)
The Tibetan one will be like Module:bo-translit, and the Chinese one Module:zh-cat. Wyang (talk) 22:39, 4 July 2017 (UTC)
It might not be a problem at the moment, because the pages running out of memory tend to be titled with Latin script, and the sortkey functions will probably be running on pages with non-Latin scripts. — Eru·tuon 23:30, 4 July 2017 (UTC)
We've had some Chinese entries running out too. —CodeCat 13:38, 6 July 2017 (UTC)
The harm is minimal compared to the benefit of having properly sorted entries in all the categories of that language. At the moment Category:Tibetan lemmas is basically unusable. I might write Module:bo-sort etc. soon. Wyang (talk) 02:18, 7 July 2017 (UTC)
Only hanzi entries have been running out. I think that those could benefit from DEFAULTSORT implemented inside {{Han char}} or something, using the radical sort (魚02). —suzukaze (tc) 02:30, 7 July 2017 (UTC)
@Wyang: Since I've just made it possible for Module:languages to use a sortkey-generating module for Vietnamese, the same can be done for Tibetan, Chinese, and other languages. I am sure it will increase the memory load, but having entries properly sorted is worth it.
I also like @Suzukaze-c's idea of using a default sortkey. When I had Module:vi-sortkey log the entry title and the resulting sortkey, I saw multiple entries in the Lua log and realized that the module was running several times in a given entry. That's wasteful. (I don't know if it increases memory usage, but it would definitely increase processing time.) If the module can run just once, that would be great. Obviously, in entries with titles in Latin script with diacritics and with several different languages on the page, that isn't possible, but maybe it is with Tibetan, Chinese, and other scripts. — Eru·tuon 06:00, 23 July 2017 (UTC)
Thank you! Wyang (talk) 06:06, 23 July 2017 (UTC)

Clipping of a foreign word[edit]

See maître d'#Etymology. Is there any way to get the word "French" deitalicized, or is there a better way to use both {{clipping}} and {{der}} to show that this is a clipping of a foreign word? We don't have an English entry for maître d'hôtel, so I'm not sure the unclipped form is used in English. —Aɴɢʀ (talk) 10:29, 6 July 2017 (UTC)

Fixed. Wyang (talk) 10:34, 6 July 2017 (UTC)
Thanks! —Aɴɢʀ (talk) 16:53, 6 July 2017 (UTC)


Could someone please add a restriction to Module:links (mw.title.getCurrentTitle().nsText ~= "Category") so that Category:Terms with manual transliterations different from the automated ones is not flooded by Arabic root categories? Thanks. Wyang (talk) 10:29, 6 July 2017 (UTC)

Done. DTLHS (talk) 18:11, 6 July 2017 (UTC)
Thanks. Wyang (talk) 23:07, 6 July 2017 (UTC)

Cantons of Luxembourg category[edit]

Would somebody be able to create the categories Category:en:Cantons of Luxembourg and Category:lb:Cantons of Luxembourg please? I've created entries for all twelve of the cantons in both languages, so it would make sense to categorise them as such. I tried making the category pages using {{topic cat}} (based on Category:en:Cantons of Switzerland) but got an error. Thanks, BigDom 18:09, 6 July 2017 (UTC)

Done. DTLHS (talk) 18:12, 6 July 2017 (UTC)
Thanks. BigDom 18:36, 6 July 2017 (UTC)

Search oddity[edit]

Why doesn't "hordeic acid" show up on the first page of search results for "hordeic"? It seems more relevant than the suggested horde etc. Equinox 18:26, 6 July 2017 (UTC)

Another example: a search for "graphity" doesn't find "quantum graphity" on the first page, but does find many far less relevant entries. Equinox 20:20, 12 July 2017 (UTC)
I agree. Additionally, when you press enter in the search box on the search page, it defaults to the first suggestion, rather than to what you typed in the box. That shouldn't happen unless you've explicitly selected something. --WikiTiki89 21:01, 12 July 2017 (UTC)
I raised this on Wikipedia (same search engine, same behaviour) and was pointed to Help:Searching#Stemming. It is necessary to place a search term in quotation marks to prioritise exact matches. I don't think this is ideal for us. Equinox 13:46, 13 July 2017 (UTC)
I wonder if Cirrus search can be tuned locally to change that behavior, I am guessing it would require an extension. You are right that this is not optimal for our project. - [The]DaveRoss 17:15, 13 July 2017 (UTC)
I have a different complaint: when searching the transliteration of a Russian word, I usually get everything except the lemma that has that transliteration. For instance, when searching "ruka russian", I get the nominative plural руки (ruki) as the first result, several other inflected forms, and some other entries that mention рука́ (ruká), but not рука́ itself. It's quite bizarre. Ideally, рука́ (ruká) would appear as the first result when searching "ruka russian", or at least before all of its inflected forms. I'm not sure if that's possible to program into the search engine, though. — Eru·tuon 18:44, 13 July 2017 (UTC)
I share Equinox's and Wikitiki's specific objections. Wikitiki's problem bothers me more. I have learned to put MWEs in between quotation marks by default. DCDuring (talk) 21:39, 13 July 2017 (UTC)
Cirrus Search is very highly configurable. You should file a Phabricator task and see if they can adjust the algorithm for this site. The search team is usually pretty responsive to such requests. This, that and the other (talk) 22:10, 13 July 2017 (UTC)

Script classes on automatically generated category pages[edit]

Up till now, categories that are created by category boilerplate templates would not have script classes applied to their links. Now it is possible, if you add a language code and script code to the table in Module:utilities/data. Hypothetically, this could be moved to the language data modules, but that would make it harder for people to edit.

I created this capability because I was frustrated that categories like Requests for etymologies in Ancient Greek entries weren't displaying with my preferred Ancient Greek font.

I considered simply having the catfix pick the first script for the language, but that would create problems for languages like Serbo-Croatian that are commonly written in two scripts. — Eru·tuon 21:16, 6 July 2017 (UTC)

I also added a display title to page titles in affix categories: so, for instance, the title of Category:Ancient Greek words prefixed with εὐ- displays as Category:Ancient Greek words prefixed with εὐ-, and that of Category:Proto-Indo-European words suffixed with *-sḱéti displays as Category:Proto-Indo-European words suffixed with *-sḱéti.

This is a natural extension of the earlier change, discussed at Wiktionary:Grease pit/2017/May § Display of vertically written languages (Mongolian, Manchu) and Wiktionary:Grease pit/2017/May § Apply a font to cuneiform page titles, in which script tagging was added to some entry titles using Module:headword. — Eru·tuon 05:14, 9 July 2017 (UTC)

Linking of individual words in the headword line[edit]

Usually when a headword consists of multiple words, each one is automatically linked in the headword line, e.g. at ethnic cleansing, ethnic and cleansing are linked separately without {{en-noun}} explicitly doing so. However, {{de-noun}} appears not to do that: at ethnische Säuberung the two words are not linked separately. Of course I could go in and add |head=[[ethnische]] [[Säuberung]] to force it, but I'd rather it did it automatically. Can someone please edit Module:de-headword to fix this behavior? Thanks. —Aɴɢʀ (talk) 09:31, 7 July 2017 (UTC)

Fixed. Module:de-headword was coded to use the page name as the default headword, instead of leaving it empty so that Module:headword could generate its own. —CodeCat 15:27, 7 July 2017 (UTC)
@CodeCat: Your fix just broke all the templates that use |head=. —JohnC5 17:24, 7 July 2017 (UTC)
I just removed the default headword, which seems to fix the problem. — Eru·tuon 18:06, 7 July 2017 (UTC)

Extend mention template to include language name display?[edit]

Can we extend {{mention}}, or provide a new template with this functionality, that allows you to easily mention a word with the name of the language displayed, as {{inherited}} and others do? Sometimes it would be handy to be able to write {{x|vi|gà}} and get "Vietnamese ". There could be a parameter, or an additional template, that suppresses/omits the link to the language article on Wikipedia. --Florian Blaschke (talk) 06:20, 8 July 2017 (UTC)

{{cog|vi|gà}} = Vietnamese --Daniel Carrero (talk) 06:21, 8 July 2017 (UTC)
I know, but {{cog}} has a specific purpose (displaying cognates) and behaviour (adding categories, IIRC, like {{etyl}} does?). I'd like something I can use anywhere. --Florian Blaschke (talk) 06:25, 8 July 2017 (UTC)
OK, I just saw it doesn't add categories, so it technically works as the desired all-purpose mention-plus-language-name template, but it still feels like a kludgy misuse to use {{cog}} when you merely want to mention a word without implying anything about cognacy. --Florian Blaschke (talk) 06:31, 8 July 2017 (UTC)
@Benwing2 created {{noncog}} for this purpose. It is currently exactly the same as {{cog}} in the Lua functions it uses and the output it yields, but has a different name. (I would like a different, more intuitive name, but don't have any good ideas. Either that or a parameter could be added to {{m}} to display the language name, but people might object to that and it might add Lua memory on the high-memory pages.) — Eru·tuon 06:38, 8 July 2017 (UTC)
Please do not use cog directly if the context does not expect a cognate word. What's the context you want to use cog?--Dixtosa (talk) 06:40, 8 July 2017 (UTC)
That's the point, I do not want to use cog when the context doesn't fit. @Erutuon, Benwing2: Thanks! How about "ml" ("mention with language name")? Whatever its name, {{noncog}} could definitely use a parameter that suppresses the Wikipedia link. --Florian Blaschke (talk) 10:06, 11 July 2017 (UTC)
Doesn't {{borrowing}} do what's requested? If not, couldn't a similarly constructed template do what's being asked and categorize appropriately? DCDuring (talk) 12:05, 11 July 2017 (UTC)
I don't know if I like the name {{ml}}, but I can create a module function that does that. [Edit: Done.] — Eru·tuon 22:45, 11 July 2017 (UTC)
I created {{langname-mention}}. It's a long name, but you can create {{ml}}, or something else, as a redirect if you want. By default, Wikipedia linking is turned off. This behavior can be reversed if desired, but I'm not sure what the parameter to turn off Wikipedia linking should be: |nowiki=1 would be confusing. — Eru·tuon 23:18, 11 July 2017 (UTC)
Thank you! How about |nowplink=1? That said, I think making the default behaviour no link is good, because the languages in mentioned words are typically not that obscure, or are proto-languages without dedicated Wikipedia articles.
{{langname-mention}} is really a long name and neutralises the point of the template. If you have reservations about {{ml}}, can you think of any better name? Or anyone else? By the way, are one-letter template shortcuts reserved in any way? If I went on to create {{x}}, {{y}} or anything like that, would anyone mind? Oh, I just saw that we have {{t+}}, which makes me wonder about {{m+}} as a shortcut. What do you think of that idea? --Florian Blaschke (talk) 08:36, 12 July 2017 (UTC)
@DCDuring: The template is also or even mainly intended for discussions about words outside of articles. Sometimes you can also use this is etymology sections, however, for example when mentioning a parallel example for a semantic change, where there is no formal connection at all, or when an etymological link has been suggested but is dubious or has been refuted. --Florian Blaschke (talk) 08:41, 12 July 2017 (UTC)
It seemed to me that all that is required is a different template name that uses the same engine as {{cog}}. It seems even a template-level redirect would work. If the requirements subsequently diverge, that should be easy to manage then. DCDuring (talk) 08:57, 12 July 2017 (UTC)
True. I wonder if it wouldn't make sense to fold {{cog}}, {{noncog}} and {{langname-mention}} into a single template ({{langname-mention}} sounds like the best title for it to me), with redirects to it, given that they don't seem to display significantly different behaviour (the only minor exception being that {{langname-mention}} doesn't link the language name by default, currently, but this difference is subject to revision and best handled with a parameter anyway). --Florian Blaschke (talk) 20:53, 14 July 2017 (UTC)
Or, in fact, go back to my initial suggestion to let {{mention}} handle it all by introducing |langname=1 and |Wikipedia=1 parameters, with {{cog}}, {{noncog}} and {{m+}} all redirects to {{mention}} with langname set to display the name. --Florian Blaschke (talk) 21:01, 14 July 2017 (UTC)
{{cog}} and {{noncog}} add class="etyl" to the language name. I'm not sure the purpose of that, but it is probably unnecessary on talk pages. Hence, to merge these two templates with the new one, we either have to remove this class from the two templates or remove it from the new one.
On the whole, I'm hesitant to remove the template {{cog}}, because it is potentially useful to have cognates be formatted with a different template: we can add CSS classes to distinguish cognates from other words mentioned in etymologies, add categories for words that have a certain word mentioned as cognate, add categories for words that have a cognate in a given language, or whatever else. If the templates are merged, no special treatment of cognates is possible. However, I'd be fine with merging {{noncog}} into {{langname-mention}}. — Eru·tuon 17:02, 15 July 2017 (UTC)
It would help to know what the original purpose of class="etyl" is. I agree that it's unnecessary for plain mentions, whether on talk pages or in etymology sections. I don't know for sure if it's a good idea, because I'm not a tech wiz, but to me merging {{noncog}} into {{langname-mention}} sounds sensible. What do you think about {{m+}} as a shortcut? --Florian Blaschke (talk) 11:33, 20 July 2017 (UTC)
OK, I've created the redirect. Test: Vietnamese , Proto-Indo-European *ḱwṓ. Excellent! --Florian Blaschke (talk) 10:38, 21 July 2017 (UTC)
That redirect should be fine. If someone wants to create a different augmented version of {{m}}, it will have to have a different name. — Eru·tuon 17:21, 21 July 2017 (UTC)

Can someone please add "Arab" as a script for xqa in Module:languages/data3/x (اِكّٖى)[edit]

Wyang (talk) 08:59, 9 July 2017 (UTC)

Yes check.svg DoneEru·tuon 10:09, 9 July 2017 (UTC)

Issues with {{lang|ar}} and rtl formatting[edit]

If I understand properly {{lang}} is supposed to correct for all script formatting issues but I'm noticing some problems in mobile safari (iOS) using Arabic.

  1. In desktop view it seems to do everything right except that characters are rendered in independent form. So for example فعل would appear as ف‌ع‌ل which is annoying.
  2. In mobile view it doesn't have this problem but it fails to set the whole block to rtl. So for example مرحبا.‏ appears as مرحبا‎. with the period on the wrong side.

I'm also wondering if it makes sense to add these non-printing bidi control characters to the special character menus for rtl scripts (which shouldn't really be necessary if {{lang}} is working). On a somewhat unrelated note does anyone know if there's a way to user sandbox a template or how should one go about testing templates? Radixcc 📞 17:43, 9 July 2017 (UTC)

(edit conflict) The text directionality markers can be added automatically by Module:script utilities (which creates the content for {{lang}}, and is used by other templates that output text in a specific language, such as {{m}}, {{l}} and {{ux}}). I had the module do this at one point, but then undid my change because I thought it wasn't necessary. I can add that feature again, if it would help to make right-to-left scripts display correctly in mobile view. — Eru·tuon 17:47, 9 July 2017 (UTC)
Okay, I've done that. Could you check again and see if the display problem remains? — Eru·tuon 18:11, 9 July 2017 (UTC)
Unfortunately it still looks the same to me. Here's what I get [1]
Radixcc 📞 19:44, 9 July 2017 (UTC)
That's weird. You put the &rlm; at the end and it displays correctly for you, and I put it at the beginning because I thought it had to go before the right-to-left text. I must be understanding how the right-to-left mark works. — Eru·tuon 20:03, 9 July 2017 (UTC)
There are two ways to do it and they use different characters. The RLM (right to left mark) is just an invisible RTL character. If you are in LTR mode as is usual with English and you have a sequence like (R = RTL, L = LTR type characters) R3R2R1 then you type a L1 and end there, you end up with R3R2R1L1. But if you then type a R4, the L1 is now surrounded on both sides by R characters which pushes it into the RTL subsequence. So you then get R4L1R3R2R1. So for example you can force the correct sequence by adding another random R character like مرحبا.ء but you don't really want that extra ء to display so you replace it with the the &rlm; which is an RTL character but doesn't display.
The other way to do (which I think you were trying to do) it is to use the RLE character which actually switches the span directionality to RTL until a PDF character is encountered which restores the previous bidi mode. Basically the "mark" characters dont switch the bidi mode, but the "embedding" characters do. — Radixcc 📞 21:13, 9 July 2017 (UTC)
Ahh, thanks for the explanation. That makes it much more clear to me what the right-to-left mark actually is. And yes, the RLE and PDF characters sound like what I thought the RLM and LRM were. — Eru·tuon 21:19, 9 July 2017 (UTC)
(edit conflict) @Radixcc: Okay, I've added a final right-to-left mark after a final punctuation mark (if there is one). That should give the same result as the version that displayed correctly in your sandbox. — Eru·tuon 21:16, 9 July 2017 (UTC)
Ok that does seem to work. After digging around a bit though it seems like the more correct HTMLish thing to do might be to enclose everything in the template output in <span dir="rtl" /> or something with a CSS style of "direction: rtl;" but in practice the main problem seems to be with final punctuation marks (mostly . and !) so the final RLM will probably solve most cases. Maybe this is already done for the desktop view but I haven't gotten on to a real computer to look at the HTML.... Anyway, thanks! — Radixcc 📞 22:03, 9 July 2017 (UTC)
@Radixcc: The CSS style direction: rtl; is added to all right-to-left scripts by MediaWiki:Common.css, but unfortunately this stylesheet is not used in the mobile version of the site. So far, nothing has been done to fix that. — Eru·tuon 22:06, 9 July 2017 (UTC)
@Erutuon: Ok started talk page asking if I could go ahead and do this. MediaWiki talk:Mobile.cssRadixcc 📞 01:39, 10 July 2017 (UTC)

Sessions Not Persisting[edit]

My enwiktionarySession cookie is set to expire as soon as I've logged in, so every request after logging is only performed as a guest user. -- 14:56, 10 July 2017 (UTC)

It is weird and I do not know the cause but anyways, try these:
  1. update your browser
  2. change startup behaviour on the browser to "Continue where you left off"
  3. use Google Chrome.
Are you getting logged out immediately from other projects like Wikipedia too? --Dixtosa (talk) 16:11, 10 July 2017 (UTC)
Have you actually inspected the cookies to see when they are set to expire, or are you describing the effect? Are you on Firefox and do you use many Wikimedia sites on a regular basis? - [The]DaveRoss 17:32, 10 July 2017 (UTC)


{{lb}} (Module:labels) broke I think. —Aryaman (मुझसे बात करो) 17:13, 10 July 2017 (UTC)

@ErutuonAryaman (मुझसे बात करो) 17:15, 10 July 2017 (UTC)
Symptom: glosses are showing as red text: "Lua error in Module:labels at line 152: attempt to concatenate field 'display' (a nil value)". Equinox 17:17, 10 July 2017 (UTC)
I reverted my edit, then repaired it. The module errors should begin disappearing. I really need a test page for Module:labels.... — Eru·tuon 17:24, 10 July 2017 (UTC)

Oldest pages ordered by last edit[edit]

This box appears on category pages, but the contents in my experience are never accurate when the category contains more than ten entries. On the other hand the box containing "Recent additions to the category" is accurate in my experience. If "Oldest pages ordered by last edit" can't be rectified, can it be removed? I wouldn't mind at all if that happened. DonnanZ (talk) 12:28, 12 July 2017 (UTC)

I wouldn't mind either. --Barytonesis (talk) 21:03, 12 July 2017 (UTC)
For many categories the page is accurate. It may have to do with when the category was created or whether it is filled by operation of a template. If the display offends and is grossly inaccurate, pluck it out. I find the Translingual ones useful. DCDuring (talk) 22:18, 12 July 2017 (UTC)

Someone seems to have improved it, but one problem caused by the boxes is that they usually prevent a category page from forming two columns, unless a spacer is inserted, creating a gap which is not always desirable. DonnanZ (talk) 08:58, 13 July 2017 (UTC)

Does widening the window help? I was very happy getting a bigger (mostly wider) screen a couple of years ago. Samsung et al now sell "ultrawide" monitors, which tempt me. DCDuring (talk) 17:06, 13 July 2017 (UTC)
I have an 18.5" monitor, which I thought was big enough, but I tried reducing the zoom from 150% to 100%, and category pages then appear with two columns. The downside is that the print is too small to read comfortably - I prefer 150% zoom. Oh well, I'll have to live with it. DonnanZ (talk) 18:27, 13 July 2017 (UTC)
I have the same kind of issues. For a while, with two windows side-by-side on my ~25" monitor, in each window I could both read text and have frames that allowed for editing and display of multiple columns. I'm seriously considering the "ultrawides" now. DCDuring (talk) 20:44, 13 July 2017 (UTC)

Would it be possible to provide a show/hide facility for these boxes? It seems to be a good idea. DonnanZ (talk) 07:24, 15 July 2017 (UTC)

@Donnanz: I don't know how to make a JavaScript function to show or hide the boxes, but I could add a CSS class to the rows of the table to allow you to hide the oldest additions (or newest additions, or both) by adding code to your Special:MyPage/common.css. That would turn it off for all category pages, and you couldn't turn it on without editing your CSS page again, though. — Eru·tuon 23:08, 15 July 2017 (UTC)
@Erutuon: Don't worry if it's too difficult, I thought something like that used for derived terms templates could be used. DonnanZ (talk) 06:27, 16 July 2017 (UTC)

Sorting of "Oldest pages" seems to have gone haywire again, it's definitely not stable. DonnanZ (talk) 23:14, 23 July 2017 (UTC)

Broken table[edit]

This didn't work properly; the boxes aren't aligned. Could someone fix it? --Barytonesis (talk) 21:21, 12 July 2017 (UTC)

Yes check.svg DoneEru·tuon 21:29, 12 July 2017 (UTC)

"Terms with IPA pronunciation" categories being subcategories of entry maintenance categories[edit]

What's the rationale for this? Should it be changed? Wyang (talk) 01:28, 13 July 2017 (UTC)

I think it should probably be changed. Same with Category:English terms with usage examples. --Daniel Carrero (talk) 01:34, 13 July 2017 (UTC)
I was wondering about this myself just the other day! :) I agree it should probably be changed, because these seem like "user-facing" categories, for readers to use, not internal maintenance categories. The pronunciation categories could go in Category:Terms by phonemic property by language, maybe? Or its parent, Category:Terms by lexical property subcategories by language? I don't know. - -sche (discuss) 01:59, 13 July 2017 (UTC)
It is a maintenance category, it has nothing to do with phonemic properties or lexical properties. A Wiktionary entry having an IPA transcription is not a property of a word, it's a property of the entry itself. —CodeCat 12:01, 13 July 2017 (UTC)
But why is it a maintenance category? Maintenance categories keep entries that require some sort of cleanup. It would make more sense to have a category for pronounceable entries that don't an IPA pronunciation. Why do we need to categorize entries that do have an IPA pronunciation at all? —Aɴɢʀ (talk) 13:47, 13 July 2017 (UTC)
Maintenance entries aren't just for cleanup, but for all maintenance. This particular category maintains a list of entries that have IPA. —CodeCat 15:40, 13 July 2017 (UTC)
maintenance: "Actions performed to keep some machine or system functioning or in service". If no action needs to be performed to keep Wiktionary functioning or in service, no maintenance (and thus no maintenance category) is required. —Aɴɢʀ (talk) 15:56, 13 July 2017 (UTC)
As I implied above, I agree that the IPA categories are not about maintenance. When Wiktionary is "done" (which would be never, apparently), all true maintenance categories will be empty, and all the pronunciable entries will be in the "entries with IPA pronunciation" categories, which will basically become redundant to a list of all entries of each language. --Daniel Carrero (talk) 16:22, 13 July 2017 (UTC)
Exactly. The IPA category is a list of all entries that already have IPA, thus leaving the remainder as those that need IPA. —CodeCat 16:29, 13 July 2017 (UTC)
But if the whole idea is finding the entries that lack IPA, you won't find them just by navigating the category. Wouldn't you have to use some external tool to do it? And can't you parse dumps or something to do it without the category?
Also, if an entry only has IPA marked for one specific country or dialect, it would probably need IPA for the other countries or dialects. So the set of entries having IPA intersects with the set of entries needing IPA. --Daniel Carrero (talk) 19:10, 13 July 2017 (UTC)
I also think that both these categories (IPA pronunciation and usage examples) don't really make sense in "entry maintenance". I mean, what maintenance needs to be done with those entries because they have IPA? I think we should have a separate umbrella category for categories for entries that contain a particular type of information: "Entries by the type of information they contain"? — Eru·tuon 17:11, 13 July 2017 (UTC)

Bot request: "bor" template[edit]

The proposal 1 of Wiktionary:Votes/2017-06/borrowing, borrowed passed.

It is about the template {{bor}} ({{borrowed}}, {{borrowing}}, {{loan}}, {{loanword}})

What is the best way to implement that project? I suppose a bot can't do everything, but perhaps it can do at least this:

  1. If the etymology section contains only "{{bor|xx|yy|word}}." (with or without a dot in the end), change it into "Borrowed from {{bor|xx|yy|word|notext=1}}."
  2. Change all other instances of "{{bor|xx|yy|word}}" into "Borrowing from {{bor|xx|yy|pizza|notext=1}}"
  3. Change all instances of "{{bor|xx|yy|word|nocap=1}}" into "borrowing from {{bor|xx|yy|pizza|notext=1}}"
  4. All entries with "borrowing" that can't be edited by bot may have to be edited manually to change it to "borrowed" or whatever makes sense in the entry.
  5. Naturally, don't touch any entries that already have "notext".
  6. After all instances of bor use "notext", the template/module can be edited to remove the default text altogether, and the "notext" can be removed from all instances of {{bor}}.

Feel free to use these categories to navigate the entries.

--Daniel Carrero (talk) 01:02, 14 July 2017 (UTC)

I am about to leave on vacation, but if nobody has taken care of this in a week or so I can probably work on it. - [The]DaveRoss 02:18, 15 July 2017 (UTC)
I would propose doing step 1 first, and then re-evaluating what is left. In particular, I'm not sure if step 2 is necessary. —CodeCat 18:01, 21 July 2017 (UTC)
I would be fine with that. --Daniel Carrero (talk) 10:36, 23 July 2017 (UTC)

Changes to affix categories[edit]

Yesterday, I modified the structure and breadcrumbs of the affix categories. I shortened the breadcrumbs that are redundant, and added intermediate breadcrumbs. The overall layout is affix » POS or affix » affix (ID) » POS. (Here POS is shorthand for a part of speech that is not the default "words". For an example, see below.)

As for category structure, I've put non-"words" POSes under the corresponding "words" category, and non-"words" POSes that have an ID under the corresponding category without the id. (The latter is not reflected in the breadcrumbs.)

category breadcrumbs
earlier version current version
Category:English words suffixed with -er Words by suffix » Words suffixed with -er Words by suffix » -er
Category:English words suffixed with -er (action noun) Words by suffix » Words suffixed with -er (action noun) Words by suffix » -er » -er (action noun)
Category:English adjectives suffixed with -en Words by suffix » Adjectives suffixed with -en Words by suffix » -en » Adjectives
Category:English adjectives suffixed with -en (made of) Words by suffix » Adjectives suffixed with -en (made of) Words by suffix » -en » -en (made of) » Adjectives

I think this structure makes more sense. If there are widespread objections, my edit can be reverted. — Eru·tuon 22:49, 14 July 2017 (UTC)

Italics vs plain text as contrast in CSS[edit]

Taxonomic names are supposed to contrast with the surrounding text in the sense that, if the matirx text is plain, then the taxon should appear in italics and, if the matrix text is italic, then the taxon should appear plain. Many of our templates seem to have formatting that overrides any plain wikiformatting that I can apply to conform to the standard. I have guessed that it is the use of CSS that has this result. How can I force the formatting taxons are supposed to have, preferably without having to use ad hoc CSS or set a parameter in a template each time. Even worse, arbitrary "tidying" of the various templates may force revisiting each instance or class of instances of correct taxon formatting. DCDuring (talk) 14:35, 15 July 2017 (UTC)

It is apparently possible to do this with the not: property ([2]) DTLHS (talk) 15:58, 15 July 2017 (UTC)
Thanks. I'll be getting into those out-of-my-depth waters shortly. DCDuring (talk) 17:07, 15 July 2017 (UTC)

Bot request: null edits in ~12,000 categories[edit]

Can someone please do null edits in the ~12,000 categories listed in Category:Pages with module errors?

Apparently they had some problem that someone already fixed. --Daniel Carrero (talk) 07:38, 17 July 2017 (UTC)

Running. --Thibaut120094 (talk) 09:28, 17 July 2017 (UTC)
And done. --Thibaut120094 (talk) 16:06, 17 July 2017 (UTC)

Search problem[edit]

I'm trying to find all pages which end with the character ά. But when I search intitle:*ά, I only get a few pages, not all of which end in ά. Does anyone know what I'm doing wrong? —CodeCat 18:36, 18 July 2017 (UTC)

You may be hoping for more than our search can deliver. I don't think that "*ά" is supported, though "ά*" is. DCDuring (talk) 19:25, 18 July 2017 (UTC)
But that's not the whole problem. DCDuring (talk) 19:31, 18 July 2017 (UTC)
You can use User:Dixtosa/SuffixIndex to find all pages which end with the character ά. I tried and it returned 1245 results. --Daniel Carrero (talk) 19:34, 18 July 2017 (UTC)
From w:Help:Searching#Syntax: "The two wildcard characters are * and \?, and both can come in the middle or end of a word". So, Special:Search/intitle:α*ά works but it is only a partial search for endings. --Vriullop (talk) 08:21, 19 July 2017 (UTC)
@Dixtosa That tool is very nice, I only have one request: that the results actually link to the Wiktionary pages. —CodeCat 08:55, 19 July 2017 (UTC)

Frequency list[edit]

User:Rajasekhar1961 is looking for a Telugu word-frequency list. I've searched but could not find one. There is a Wikimedia page about Telugu dumps at dumps.wikimedia.org, but I can't make sense of it. Is there something on that page that User:Rajasekhar1961 could perhaps use? Is there any way to extract a frequency list from such a dump? —Stephen (Talk) 22:16, 18 July 2017 (UTC)

I could extract words from the text of the articles, if that's what you want. I don't think it would be very representative of the language as a whole though. DTLHS (talk) 22:18, 18 July 2017 (UTC)
It sounds like it would be useful. Since I could not find any Telugu frequency list, I don't think we can be choosy. —Stephen (Talk) 22:25, 18 July 2017 (UTC)
Wiktionary:Frequency lists/Telugu DTLHS (talk) 22:45, 18 July 2017 (UTC)
Thank you very much for your timely help DTLHS sir. This greatly helps me in prioritizing my work in Wiktionary.Rajasekhar1961 (talk) 12:48, 19 July 2017 (UTC)

Cannot see "show" label in expandable items[edit]

When I open a page with expandable areas, like Translations or Declension I most times don't see "show" labels.

And, when editing, in the special caracters setion I see not the combobox for choosing the sets and pressable buttons, but a full list of character sets with unpressable characters.

Both issues appear only when I'm logged in. --Wanjuscha (talk) 11:45, 19 July 2017 (UTC)

Seems like the maddening, intermittent, recurring problem of not all of the Javascripts being run completely. I've not heard of a definitive solution. DCDuring (talk) 19:22, 19 July 2017 (UTC)
That often happens to me, though it's become less common (except when I press the back button to go to a page with expandable content). — Eru·tuon 19:25, 19 July 2017 (UTC)
I think this is a problem that relates to Wikimedia software updates, your Operating System updates, and your browser updates. Are you using the Firefox browser? If yes, you should try this: Look at the top of your screen and you should see the symbol Ξ, which opens your Firefox menu. Click on that, then click on OPTIONS, PRIVACY, HISTORY, "USE CUSTOM SETTINGS FOR HISTORY", and under "ACCEPT COOKIES FROM SITES", click "KEEP UNTIL" and change it to "I CLOSE FIREFOX". Close Firefox and restart it. Note: this will delete your cookies and you will have to log onto the sites again that you use, such as Wikipedia, Youtube, etc. The next time that you turn your computer off and then reboot, you can return to Ξ and change "I CLOSE FIREFOX" back to "THEY EXPIRE". This should fix your problem. —Stephen (Talk) 19:29, 19 July 2017 (UTC)
I did so. No use. --Wanjuscha (talk) 21:46, 21 July 2017 (UTC)
There is one other thing that I can think of. Recently I started having problems again, and deleting my cookies did not help. I have always used the MONOBOOK skin (PREFERENCES, APPEARANCE, SKIN), so I changed to the VECTOR skin. That fixed my problems. —Stephen (Talk) 12:14, 22 July 2017 (UTC)
I still get the problem in Vector sometimes. Underlying problem might be too much reliance on JS that is not professionally written. DCDuring (talk) 18:12, 22 July 2017 (UTC)

This action has been automatically identified as harmful, and therefore disallowed.[edit]

I got this message: "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: JSky". What exactly happens here? What rule did I abuse? What is JSky? ばかFumikotalk 07:32, 20 July 2017 (UTC)

It looks like User:Chuck Entz is working on a way to counteract this guy, but something went wrong. —suzukaze (tc) 07:35, 20 July 2017 (UTC)

Importantion of categories to Wikidata[edit]

Dear Wiktionarians,

I am importing some 10000 categories from Wiktionary to Wikidata. Just a heads up! [[User:PokestarFan|<font face="Tahoma" color="purple">PokestarFan</font>]] [[User Talk:PokestarFan|<font face="Tahoma" color="blue">(talk)</font>]] [[Special:Contributions/PokestarFan|<font face="Tahoma" color="green">(My Contribs)</font>]] (talk) 21:21, 22 July 2017 (UTC)

For what purpose? DTLHS (talk) 21:23, 22 July 2017 (UTC)
@DTLHS: The goal of Wikidata is to provide data on everything. Categories are included as part of that data. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 21:40, 22 July 2017 (UTC)
That's not an answer. Will we be able to use this for category interwikis? We have way more than 10,000 categories, so which categories are being imported? DTLHS (talk) 21:44, 22 July 2017 (UTC)
@DTLHS:Yes, that is exactly why categories are imported. I plan to import every single category into Wikidata. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:20, 22 July 2017 (UTC)
Could you clarify what importing categories to Wikidata means? — Eru·tuon 21:25, 22 July 2017 (UTC)
@Eruton: It means making an item for every page in wiktionary that is a category (in the category namespace). PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 21:40, 22 July 2017 (UTC)
@PokestarFan: Ahh! Is that related to adding interwikis for categories? — Eru·tuon 23:35, 22 July 2017 (UTC)
Didn't we already do that a month or so ago? —CodeCat 10:40, 23 July 2017 (UTC)
@CodeCat: Well it wasn't throughly done yet. I still have like several tens of thousands of categories. This is only step 1, with categories. Step 2 with all words will begin at a later date. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 13:09, 24 July 2017 (UTC)
I don't really know what you mean by "Step 2 with all words", but it sounds like the distasteful Wikidata plan that does not have consensus around here... —Μετάknowledgediscuss/deeds 13:16, 24 July 2017 (UTC)
I don't think it matters what we think of how Wikidata is using "our" data, because it isn't ours. OTOH, we don't have to use "their" data until it is clearly advantageous to this project and we can use it however we want. DCDuring (talk) 14:10, 24 July 2017 (UTC)
Well, we want them to use our data in such a way that it is mutually beneficial, rather than competitive. —Μετάknowledgediscuss/deeds 14:37, 24 July 2017 (UTC)
A month ago it was ready. Since then bots are moving interwiki links to Wikidata. See among others Special:Contributions/JAnDbot and d:Special:Contributions/JAnDbot. Not sure how many links may still remain. Users, like myself, have been resolving interwiki conflitcs, merging Wikidata items and adding missing links. It is not really done at all. --Vriullop (talk) 16:19, 24 July 2017 (UTC)


Could an admin add sit-tan-pro, Proto-Tani, to MOD:languages? It is the reconstructed ancestor of the Cat:Tani languages. —Aryaman (मुझसे बात करो) 21:58, 23 July 2017 (UTC)

Yes check.svg Done. Also adding Proto-Tani as ancestor of those Tani languages that don't already have an ancestor. — Eru·tuon 22:17, 23 July 2017 (UTC)
@Erutuon: Thanks! Can you add tbq-pro as an ancestor of Proto-Tani? —Aryaman (मुझसे बात करो) 02:47, 24 July 2017 (UTC)
Yes check.svg Done; I gather the canonical name should be Proto-Tibeto-Burman. — Eru·tuon 03:04, 24 July 2017 (UTC)
Facepalm. Misread the request. Moved Proto-Tani to the Tibeto-Burman family. — Eru·tuon 03:55, 24 July 2017 (UTC)

Coptic ⲉⲓ[edit]

Traditional Coptic sort order treats ⲉⲓ as equivalent to ⲓ (particularly given that ⲉⲓ in Sahidic corresponds to ⲓ in Bohairic); could an admin add

   sort_key = {
                from = {"ⲉⲓ"},
                to   = {"ⲓ"}},

(with the tabs fixed) to Coptic in Module:languages/data3/c? Thanks. — Vorziblix (talk · contribs) 23:15, 24 July 2017 (UTC)

Added. DTLHS (talk) 23:22, 24 July 2017 (UTC)
Thanks! — Vorziblix (talk · contribs) 23:26, 24 July 2017 (UTC)
@Vorziblix: Where is this "Traditional Coptic sort order" attested? --WikiTiki89 18:48, 25 July 2017 (UTC)
Crum’s Coptic dictionary, as well as Černý’s Coptic etymological dictionary, which are generally considered the two standard academic reference works on Coptic lexicography. (By ‘traditional’ I meant academically traditional; sorry, I should’ve made that clear!) Of course, their sort order is a bit more complicated, since they also sort by consonants first (ignoring vowels) and only then by vowels, but I assume that would be much harder to implement. Edit: Having now checked Vycichl’s Coptic etymological dictionary, it also treats ⲉⲓ as ⲓ, but otherwise sorts alphabetically, so it actually matches our current order. — Vorziblix (talk · contribs) 21:31, 25 July 2017 (UTC)
@Vorziblix: If you wanted to go with the more complicated sorting, I may be able to write a module that does that. You'd have to explain to me how it works though. — Eru·tuon 22:25, 25 July 2017 (UTC)
That might make sense, as it’s followed by the standard references. If other editors would prefer a more strictly alphabetical order, though, I wouldn’t object to that either. In any case, I’ll try to work out the sort order’s details and post them. — Vorziblix (talk · contribs) 05:30, 26 July 2017 (UTC)
Are there any alphabetized lists in Coptic from a time when Coptic was still in use as literary language? --WikiTiki89 22:27, 25 July 2017 (UTC)
Yes, there are Coptic ‘dictionaries’ from that time, but when they alphabetize at all they usually alphabetize by last letter, then first letter, then second letter, based on Arabic practice. It would probably be unhelpful to implement such a scheme here; anyway, the surviving ones all use Bohairic dialect, not Sahidic, so they can’t help with the question of ⲉⲓ/ⲓ. There’s a Greek-Bohairic-Arabic vocabulary from the 14th century that alphabetizes by first letter, but its dialect is again Bohairic. A Sahidic glossary does exist but goes through the Gospels word by word instead of alphabetizing. — Vorziblix (talk · contribs) 05:30, 26 July 2017 (UTC)

Improved search in deleted pages archive[edit]

During Wikimedia Hackathon 2016, the Discovery team worked on one of the items on the 2015 community wishlist, namely enabling searching the archive of deleted pages. This feature is now ready for production deployment, and will be enabled on all wikis, except Wikidata.

Right now, the feature is behind a feature flag - to use it on your wiki, please go to the Special:Undelete page, and add &fuzzy=1 to the URL, like this: https://test.wikipedia.org/w/index.php?title=Special%3AUndelete&fuzzy=1. Then search for the pages you're interested in. There should be more results than before, due to using ElasticSearch indexing (via the CirrusSearch extension).

We plan to enable this improved search by default on all wikis soon (around August 1, 2017). If you have any objections to this - please raise them with the Discovery team via email or on this announcement's discussion page. Like most Mediawiki configuration parameters, the functionality can be configured per wiki. Once the improved search becomes the default, you can still access the old mode using &fuzzy=0 in the URL, like this: https://test.wikipedia.org/w/index.php?title=Special%3AUndelete&fuzzy=0

Please note that since Special:Undelete is an admin-only feature, this search capability is also only accessible to wiki admins.

Thank you! CKoerner (WMF) (talk) 18:21, 25 July 2017 (UTC)

Loading web fonts[edit]

What is the situation for loading web fonts? What's the policy regarding this? The reason I ask is that a number of system fonts, especially with Arabic, don't handle diacritics properly and it seems like the best way to deal with this would be to use an appropriate Google Noto font (in the case of Arabic, Noto Arabic Naskh) since that project has the explicit purpose of rendering everything properly. This seems like the most foolproof way to deal with the issue but if it isn't being done already then I'm concerned that there is some sort of objection to using web fonts or some lack of support in MediaWiki for doing it efficiently. (Apparently loading them from a Common CSS file is bad because they won't be loaded in parallel so they need to be loaded from link tags in the HTML somehow.) Another vaguely related question: is there a way to create a page-specific CSS file for testing? — Radixcc 📞 20:30, 25 July 2017 (UTC)

We have our own web fonts, and I remember trying to figure out how to get more fonts included in it, but without much success. But I do remember there was a decent Arabic font available in it. I can't remember the details, but you can probably find the past discussions we had if you search around. As for testing, you might be able to create User:<username>/foo.css and explicitly load it from another page. --WikiTiki89 20:37, 25 July 2017 (UTC)
You can load a CSS file on a specific page with JavaScript. I can show you how, if there's no easier way. — Eru·tuon 20:41, 25 July 2017 (UTC)
That wouldn't work exactly right though. You'd want it to load like any other CSS page, and not after the page is loaded and the JS is run. --WikiTiki89 20:50, 25 July 2017 (UTC)

Template:module cat[edit]

This template can categorize some of the predictably titled modules: for instance, it categorizes Module:ru-headword as a headword-line module and Russian module.

It's now transcluded by {{translit module documentation}}, where it adds categories for any languages that list the module in their language data modules. For instance, Module:sa-translit is used for Old Hindi and Old Marathi in addition to Sanskrit, so it is categorized as an Old Hindi and Old Marathi module as well as a Sanskrit module.

The list of module keywords with their associated categories is found at Module:module categorization. If there are ones that I've missed, please let me know or add them yourself. — Eru·tuon 21:21, 25 July 2017 (UTC)

lua error: not enough memory[edit]

There is a bunch of errors on page egg, not sure why. Maybe someone can help. Epantaleo (talk) 00:26, 27 July 2017 (UTC)

@Epantaleo: Well, the first Translations section (for the noun) is using 40 something MB of Lua memory. That's a big part of it. (I moved this discussion from the Etymology Scriptorium to the Grease Pit because it isn't about etymology.) — Eru·tuon 00:37, 27 July 2017 (UTC)
I guess it was related to my experiment in Module:Cyrs-Glag-translit. Undid my edit. Now the error is gone (though the page is really close to the limit, and will probably go over it eventually). — Eru·tuon 00:42, 27 July 2017 (UTC)