Open main menu

Wiktionary β

Wiktionary:Grease pit

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

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

The Grease pit is a place to discuss technical issues such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit

July 2017

Puzzling error in templateEdit

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

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


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

@Wyang: I'm working on Module:zh-sortkey. It uses data submodules for the sortkeys, so it probably won't cause memory errors. It's functional, as you can see on the documentation page, but the data submodules have to be created from the list at Module:User:Erutuon/zh/documentation, which in turn is compiled from @Suzukaze-c's module Module:User:Suzukaze-c/zh/data/skeys. If you or anyone else can help, that would be great. They are placed at Module:zh-sortkey/data/zero-padded number: for instance, Module:zh-sortkey/data/001. — Eru·tuon 18:56, 30 July 2017 (UTC)

Actually, with DTLHS's help, all the data modules have been created! (Thanks again!) The function should be ready to deploy. [edit: Implemented.] — Eru·tuon 20:11, 30 July 2017 (UTC)

Thanks, @Erutuon! Your work is much appreciated. Has it been implemented on articles using {{lb|zh}}? I see that entries Category:zh:Chinese mythology are still not correctly sorted- is there a way to solve this? Wyang (talk) 07:53, 31 July 2017 (UTC)
@Wyang: Yes, {{lb}} handles categories with Module:utilities, which in turn uses the language's sortkey-generation setting. It may be that the entries just haven't updated yet. It takes a while. (I wonder how exactly it works.) Doing a bunch of null edits would make the sorting show up more quickly. — Eru·tuon 08:00, 31 July 2017 (UTC)
I went through the category you mentioned and did null edits with AWB. I find the sorting quite fascinating, even though I can't read Chinese. — Eru·tuon 08:25, 31 July 2017 (UTC)
It looks great and correctly sorted now. Thank you! Wyang (talk) 08:45, 31 July 2017 (UTC)

I fixed a problem in Module:zh-pron, which was using pinyin as the sortkey for "Chinese" categories, rather than the sortkey module. Hence 阿坝 was sorted under A. Also updated Module:zh-cat, which was using a partial sortkey from the skeys function in Module:zh. There may be other modules using outdated or incorrect sortkeys. — Eru·tuon 16:22, 31 July 2017 (UTC)

@Erutuon: Very nice!
@Wyang: What is the future of {{zh-cat}}? —suzukaze (tc) 19:38, 31 July 2017 (UTC)

Question: should other languages using the Han script use Module:zh-sortkey? Japanese, Vietnamese, etc.? Or do they have their own individual ways of sorting Han characters? — Eru·tuon 19:56, 31 July 2017 (UTC)

I think Japanese and Vietnamese should use sorting by reading. Radical+stroke sorting is needed for Chinese because of dialectal words that don't have Mandarin pronunciations. I think that if we didn't have dialectal words, I would support sorting by pinyin for "Chinese". —suzukaze (tc) 20:13, 31 July 2017 (UTC)
Hmm, for Japanese at least, that begs the question: which reading should the entry be sorted by, if there's more than one? — Eru·tuon 20:15, 31 July 2017 (UTC)
Pinging @Eirikr because actually I don't use {{{sort}}} much (it's hard to remember which templates need it...) —suzukaze (tc) 00:27, 1 August 2017 (UTC)

Clipping of a foreign wordEdit

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 categoryEdit

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 oddityEdit

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 pagesEdit

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 lineEdit

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)

  DoneEru·tuon 10:09, 9 July 2017 (UTC)

Issues with {{lang|ar}} and rtl formattingEdit

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 PersistingEdit

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 editEdit

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 tableEdit

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

  DoneEru·tuon 21:29, 12 July 2017 (UTC)

"Terms with IPA pronunciation" categories being subcategories of entry maintenance categoriesEdit

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" templateEdit

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)
@TheDaveRoss: Would you still like to do this? --Daniel Carrero (talk) 06:17, 17 August 2017 (UTC)
Sure, should I do as CodeCat suggested and just do number one for now? - TheDaveRoss 11:53, 17 August 2017 (UTC)
Daniel said he was fine with that, so I suppose so. Perhaps you could add a dot at the end if one is missing, too. —CodeCat 12:57, 17 August 2017 (UTC)
I have started going on these, feel free to take a look at recent edits and let me know if there is anything amiss. If not I am going to switch it over to the bot soon. - TheDaveRoss 13:05, 18 August 2017 (UTC)
I haven't noticed any problems so far. —CodeCat 13:15, 18 August 2017 (UTC)
Same here, the entries edited look OK to me so far. I see you've been adding the dot at the end when needed, which I agree is a good thing. --Daniel Carrero (talk) 13:31, 18 August 2017 (UTC)

Changes to affix categoriesEdit

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 CSSEdit

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 categoriesEdit

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 problemEdit

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 listEdit

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, 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 itemsEdit

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)
I disabled Javascript in Firefox, now I can see everything expanded. --Wanjuscha (talk) 09:37, 31 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 WikidataEdit

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)

  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)
  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)
@Erutuon All right, I think I’ve generally figured it out. The basic alphabetical order is ⲁⲃⲅⲇⲉⲍⲏⲑⲓⲕⲗⲙⲛⲝⲟⲡⲣⲥⲧⲩⲫⲭⲯⲱϣϥⳉϧϩϫϭ, with ⲉⲓ treated as ⲓ, ⲟⲩ treated as ⲩ, ϯ treated as ⲧⲓ, and ⳤ treated as ⲕⲉ. With this order in mind, the following steps are applied:
  1. All vowels except those which constitute the first letter of a word are completely ignored, and the resulting word skeletons are alphabetized. The vowels are ⲁⲉⲏⲓⲟⲩⲱ, except that ⲟⲩ/ⲩ is a consonant whenever it’s adjacent to another vowel.
  2. Whenever this would result in multiple words being alphabetized at the same place, the words ending in a consonant are alphabetized before those ending in vowels.
  3. If any words are still being alphabetized at the same place, then, to sort amongst them, all consonants are completely ignored, and the words are sorted alphabetically according to their vowels (ignoring the first letter if it’s a vowel).
For example, here’s how the words with the skeleton ⲁⲗⲕ are alphabetized:
  • ⲁⲗⲁⲕ
  • ⲁⲗⲟⲕ
  • ⲁⲗⲕⲉ
  • ⲁⲗⲓⲕⲓ
  • ⲁⲗⲕⲟⲩ
Another example — the words with skeleton ⲩⲣ (= ⲟⲩⲣ):
  • ⲟⲩⲣ
  • ⲟⲩⲏⲣ
  • ⲟⲩⲱⲣ
  • ⲟⲩⲉⲓⲣⲉ
  • ⲟⲩⲟⲣⲉ
  • ⲟⲩⲣⲱ
If anything needs clarification, I’ll do my best to make it clear. Thanks for offering to try to make this work! — Vorziblix (talk · contribs) 04:54, 28 July 2017 (UTC)
@Vorziblix: Do you know if the letters in the basic alphabetic order are already correctly alphabetized when they're on their own? (That is, if you had a Wiktionary category of all the Coptic letters, they'd be in the correct order? Maybe this depends on their Unicode codepoints.)
I think this sort order sounds doable, aside from the parts about "if words are still alphabetized at the same position", because a sortkey function can't look at the contents of a category and figure out if any existing Coptic entries have the same sortkey. But I could add a number at the end of the sortkey for a word ending in a vowel to make it automatically sort after any word ending in a consonant that otherwise has the same sortkey. — Eru·tuon 05:24, 28 July 2017 (UTC)
Never mind, the function would not have to look at the contents of the category to implement the sort order you described above. I think it all can be done. — Eru·tuon 05:27, 28 July 2017 (UTC)
@Erutuon: To your first question, the Coptic letters are currently not in the correct order. They follow the Unicode codepoints, which put the Demotic-derived letters ϣϥⳉϧϩϫϭ before the Greek-derived ⲁⲃⲅⲇⲉⲍⲏⲑⲓⲕⲗⲙⲛⲝⲟⲡⲣⲥⲧⲩⲫⲭⲯⲱ, when it should be the Greek first, followed by the Demotic. If you were to treat the Greek-derived letters as Greek αβγδεζηθικλμνξοπρστυφχψω rather than Coptic, however, then the order would become correct. Thanks again, — Vorziblix (talk · contribs) 05:47, 28 July 2017 (UTC)
@Vorziblix: I'll use that workaround, if I can't think of anything more simple. (It would require replacing a lot of letters, but probably wouldn't cause memory or Lua processing problems in Coptic entries, which aren't as long as Latin-script entries.) — Eru·tuon 06:22, 28 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)

@Vorziblix: I've created Module:cop-sortkey. I tried sorting the examples you gave above on the documentation page, and so far, I think it's giving the right order. But I would appreciate it if you would add some examples of consonantal (u) (not at the beginning of a word) to the documentation page, because it's probably not handled correctly yet. Oh, and the order of the Greek-derived and Demotic-derived letters won't be correct. — Eru·tuon 05:40, 29 July 2017 (UTC)

@Erutuon: I’ve added one example, and I’ll look for more. Besides the consonantal (u) handling, another trouble spot is that words with final vowels can get sorted after words with extended consonantal skeletons, e.g. ⲁⲗⲧⲏⲁⲥ before ⲁⲗⲱ; I think this would be resolved if a 2 were added after the final consonant in words that have final vowels. — Vorziblix (talk · contribs) 07:01, 29 July 2017 (UTC)
@Vorziblix: I had to add , because 2 sorts before all the Coptic letters, and it made ⲁⲗⲱ sort before ⲁⲗⲧⲏⲁⲥ. I've added code that converts (u) to w if it neighbors a vowel while generating the sortkey, to differentiate it from vocalic (u). Take a look at it now and see if it gives the right result.
I'm curious, how do multi-word sequences sort? Do the same transformations apply to each word in the sequence that apply to individual words? — Eru·tuon 16:23, 29 July 2017 (UTC)
@Erutuon: Ah, sorry for being unclear; I meant that the sorting ⲁⲗⲧⲏⲁⲥ before ⲁⲗⲱ, as it was doing, was incorrect. Sorting before all the Coptic letters produces the desired order; I’ve changed it to a 2. The w-conversion is working great! As for multi-word sequences, in the standard dictionaries they’re usually just entered as subentries of single words, so one can’t really tell what their sort order should be. We could settle on anything that seems reasonable. — Vorziblix (talk · contribs) 21:11, 29 July 2017 (UTC)
@Vorziblix: Well, there are two options: remove all spaces (or hyphens) and sort the multi-word sequence as if it were a single word smushed together, or create an individual sortkey for each word and concatenate each one. The first option is easier, but the second is probably better.
A similar question: how should punctuation characters be handled? Right now, the hyphen (and the character , which I'm not familiar with) are accidentally repeated. Perhaps they should be added to the very end of the sortkey. — Eru·tuon 21:29, 29 July 2017 (UTC)
@Erutuon: Punctuation characters should just be ignored (the ⸗ is used when the word must attach to a pronoun). As far as spaces go, I’d say go with the second one, but I don’t have a strong opinion either way. — Vorziblix (talk · contribs) 21:45, 29 July 2017 (UTC)

@Vorziblix: What does the initial mark in ˋϣⲗⲏⲗ (ˋšlēl) mean? Should it just be removed like the hyphen and the ? — Eru·tuon 22:51, 30 July 2017 (UTC)

@Erutuon: It indicates syllabicity or a (non-phonemic) schwa preceding the consonant it’s above. (Correctly, it should be above the letter as a diacritic U+0300, not before it as a separate character.) However, it’s only used in the Bohairic dialect; all other dialects use a macron U+0304 for the same purpose. Most of our entries right now don’t display this mark at all, and every dictionary I can find doesn’t display it in entry names. I would suggest using an entry_name value in Module:languages/data3/c to get rid of them in entry names but display them in the headword line, as we do with macrons in Latin or stress marks in Russian. — Vorziblix (talk · contribs) 02:39, 31 July 2017 (UTC)
@Vorziblix: Okay, that's done, and I've removed it from sortkeys too. There are a few entries titled with the spacing grave accent, which should be moved to the corresponding title without it. — Eru·tuon 03:18, 31 July 2017 (UTC)

I went through the existing Coptic lemmas with null edits. Created a category table of contents template, {{cop-categoryTOC}}. It displays the Coptic letters, but pages through to the Greek ones because those are the ones used in sortkeys. — Eru·tuon 04:06, 31 July 2017 (UTC)

@Erutuon: Thanks, it’s looking great. I’ll go move all the entries with the spacing grave accent. Could you also add the combining grave and macron to entry_name? I think all you’d need is from = {"ˋ", GRAVE, MACRON},. — Vorziblix (talk · contribs) 05:06, 31 July 2017 (UTC)
@Vorziblix:   Done. — Eru·tuon 05:10, 31 July 2017 (UTC)
(Generated a list with AWB, if that's helpful: ˋϣⲗⲏⲗ, ˋϩⲙⲟⲧ, ˋⲁϧⲱⲙ, ˋⲉϩⲟⲟⲩ, ˋⲉϫⲱⲣϩ, ˋⲉⲙⲉⲛⲧ, ⲙⲁˋⲛϣⲁⲓ, ⲣⲉϥϯˋⲥⲃⲱ.) — Eru·tuon 05:17, 31 July 2017 (UTC)
@Erutuon: Thanks again! — Vorziblix (talk · contribs) 05:21, 31 July 2017 (UTC)

Improved search in deleted pages archiveEdit

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

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 fontsEdit

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)
Huh. I guess I don't know how this stuff works. — Eru·tuon 22:53, 30 July 2017 (UTC)

Template:module catEdit

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 memoryEdit

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)

label American spellingEdit

When using this label, the printed result is (American), which can be misleading. On the other hand the label "British spelling" is printed as (British spelling) which is quite satisfactory. Can the "American spelling" label be altered to match the one for "British spelling"? DonnanZ (talk) 22:15, 27 July 2017 (UTC)

Examples are enameled wire and enamelled wire. DonnanZ (talk) 23:20, 27 July 2017 (UTC)

e is in CAT:EEdit

e currently runs out of memory part way through Spanish. No idea why other than possibly sheer length. KarikaSlayer (talk) 22:24, 27 July 2017 (UTC)

Maybe it's all the letter list templates. Chuck Entz and CodeCat have mentioned on my talk page how they want to remove all the letter list templates and replace them with appendices. — Eru·tuon 00:23, 30 July 2017 (UTC)
Yes, but I also want all the entries for letters to go... —CodeCat 10:21, 30 July 2017 (UTC)

Add m and f genders for Pashto in the translation adderEdit

Which part of MediaWiki:Gadget-TranslationAdder.js controls, what genders are displayed by default for a given language code? I'd like to add Pashto (ps), which has masculine and feminine genders, unlike many language in the region. By default, the tool assumes Pashto has no genders for "ps" but normally knows, what genders are used in a language. --Anatoli T. (обсудить/вклад) 05:48, 29 July 2017 (UTC)

Search for "Metadata dictionaries". There's a long list of language codes with data for each. You can add g:["m","f"], right after ps:{. (Or maybe you already know basic JS syntax...) — Eru·tuon 06:08, 29 July 2017 (UTC)
@Erutuon Thanks! I've added "m","f","m-p","f-p". --Anatoli T. (обсудить/вклад) 06:15, 29 July 2017 (UTC)

Broken links; can't find topicsEdit

Links to old threads in discussion forums such as "Requests for deletion" break too easily, and the old threads are too hard to find. If anyone with technical ability ever has time to look at this, it would be time well spent, I think. Mihia (talk) 00:01, 30 July 2017 (UTC)

I don't understand what your problem is. If you want to see old RFD discussions, they are removed from the page when concluded and archived on the talk page of the relevant entry, which makes them very easy to find. —Μετάknowledgediscuss/deeds 06:42, 30 July 2017 (UTC)
OK, thanks, I didn't know that they were archived to talk pages. (I didn't even know that deleted entries had talk pages.) I see now that this is actually explained at the top of the RFD page, but I never read that ... I have problems sometimes with locating other types of discussion thread too, but I can't remember any specific examples now. I'll ask again if and when they arise. Mihia (talk) 13:14, 30 July 2017 (UTC)
Further to this, what is the expected means of locating the RFD discussions for deleted entries? When I type the relevant word into the search box, it just seems to come up with "There were no results matching the query". Mihia (talk) 00:58, 3 August 2017 (UTC)

Labels not workingEdit

At ϩⲟⲟⲩⲧ, the link in the context label should go to a Wikipedia article specified at MOD:labels/data/subvarieties, but instead it erroneously points to Appendix:Glossary (which should never be a default anyway). @ErutuonΜετάknowledgediscuss/deeds 00:05, 30 July 2017 (UTC)

Ouch. You're right, that shouldn't happen. I'm surprised nobody noticed till now, because I haven't edited the module very recently. It's fixed now. — Eru·tuon 00:10, 30 July 2017 (UTC)
@Erutuon: Thanks for fixing it, but please, please be more careful and check this kind of thing after you mess with it. —Μετάknowledgediscuss/deeds 06:41, 30 July 2017 (UTC)
@Metaknowledge: All right, next time I edit that module I'll come up with a testing system. Apart from that, I'll do my best. — Eru·tuon 17:36, 30 July 2017 (UTC)

August 2017

Alternatives for Template:reconstructed?Edit

Is there any way that we could automatically show the message above all pages in the Reconstruction namespace? Then we wouldn't need to put {{reconstructed}} on all the pages manually anymore. —CodeCat 10:05, 1 August 2017 (UTC)

(Previous discussion: Wiktionary:Grease pit/2016/March#Template:reconstructed.) — Eru·tuon 05:58, 3 August 2017 (UTC)

MediaWiki:Gadget-TranslationAdder.js nests Gujarati under AramaicEdit

diff. --Anatoli T. (обсудить/вклад) 02:22, 4 August 2017 (UTC)

Quite bizarre. Neither the canonical name or the code would explain that. — Eru·tuon 03:27, 4 August 2017 (UTC)
And it's the 2nd it happened to me. Not sure I fixed it correctly the first time it happened. I thought it was replacing one language with another, not nesting. --Anatoli T. (обсудить/вклад) 03:34, 4 August 2017 (UTC)
Ohh, actually... I bet it's trying to put it before "Hebrew" – which it shouldn't, because Hebrew is just a script name nested under Aramaic. — Eru·tuon 03:57, 4 August 2017 (UTC)
@Dixtosa: Can you put this on your list of things to fix? — Eru·tuon 19:54, 7 August 2017 (UTC)
I think this fixed the bug. --Dixtosa (talk) 15:45, 12 August 2017 (UTC)

Maintenance category for quotes with translit but not native-script text?Edit

Currently entries such as jb, which have quotations with transliteration but not the original native-script text, don’t seem to be put in any maintenance category, and they’re not categorized under the category of entries with usexes either (e.g. Category:Egyptian terms with usage examples), making them very hard to find. Could we perhaps make {{quote}}/{{ux}} automatically add them to the ‘… needing native script’ maintenance categories (e.g. Category:Egyptian terms needing native script) or make a new maintenance category for them? — Vorziblix (talk · contribs) 02:31, 4 August 2017 (UTC)

I think the "terms needing native script" is (theoretically) reserved for links to terms that would have entries. I've made Module:usex add the category Egyptian usage examples lacking native script (and the equivalent for other languages). The name can be changed if others object. I'll wait before adding it to the category-handling modules.
I guess the main question is which word we want: "needing", "lacking", "missing", something else? "Needing", which is used in the corresponding "term" category, would imply that ideally we want the native script to be supplied, whereas "lacking" does not. Maybe it would be best to switch, unless there are languages for which getting the native script isn't very important... — Eru·tuon 03:24, 4 August 2017 (UTC)
All right, thanks! I’m indifferent to the naming issue myself, but I’ll wait a while longer to see if anyone else comments before creating the category. — Vorziblix (talk · contribs) 21:24, 4 August 2017 (UTC)
I think "needing native script" is just fine for this. I don't think we need to distinguish links versus usexes. —CodeCat 21:27, 4 August 2017 (UTC)
@CodeCat: Yeah, but the category is "terms needing native script". I assume "terms" would be referring to links to entries, not to any old text. — Eru·tuon 21:32, 4 August 2017 (UTC)
True, maybe. Renaming the category is also a possibility. Is there a reason other than naming that favours splitting the two? —CodeCat 21:33, 4 August 2017 (UTC)
Not really. But subcategories for types of template might be useful, in case for some reason a person particularly wants to improve usage examples or quotes and not other categories of text in that language. — Eru·tuon 21:38, 4 August 2017 (UTC)

Font for Jawi (Arabic-script Malay)?Edit

The current font for Jawi (Arab) doesn't display the Jawi-specific letters well. For example, {{m|ms|تڠن|tr=tangan}} produces تڠن (tangan) with disjointed ڠ, unlike the desired form of تڠن. Is it possible for this to be fixed? (Mac, Chrome) Wyang (talk) 08:28, 4 August 2017 (UTC)

While you're at it. Please check the Uyghur fonts. They are too small on most systems. --Anatoli T. (обсудить/вклад) 08:38, 4 August 2017 (UTC)
Yuck. I created a new script code ms-Arab for Malay in Arabic script, so more appropriate fonts can be selected for it in MediaWiki:Common.css. The typical Arab fonts probably don't have some of the extended characters. (Traditional Arabic, which I use, certainly doesn't.) — Eru·tuon 21:46, 4 August 2017 (UTC)
Woops. Could an admin add ms-Arab to the various lists of all Arabic script codes in MediaWiki:Common.css, so it doesn't display italicized? — Eru·tuon 21:48, 4 August 2017 (UTC)
Added. DTLHS (talk) 05:31, 6 August 2017 (UTC)
Why the heck is Arial Unicode MS so high in the .Arab font stack? There are better fonts out there. Investigating with BabelPad shows that Segoe UI, Tahoma, Microsoft Sans Serif are sans-serif fonts capable of displaying the text تڠن correctly. —suzukaze (tc) 07:04, 6 August 2017 (UTC)
  • Does someone at MW test font appearance on mobile devices, especially for less common languages? How is font delivery handled if the user's mobile device doesn't already have the font? (I focus on mobile devices because I imagine that PCs have abundant resources and techniques to accomplish the result.) DCDuring (talk) 23:38, 6 August 2017 (UTC)
    • MediaWiki has no input in Wiktionary's font choices. All the font-related CSS styles are locally hosted in MediaWiki:Common.css. Unfortunately, none of the script- or language-specific CSS styles apply in the mobile version. MediaWiki:Common.css contains all of them, and it is only loaded in the desktop version. MediaWiki:Mobile.css contains very little, none of it font-related. So, in the mobile version non-Latin-script mentions are italicized (example: أهلا وسهلا), many obscure scripts probably display as boxes, etc. — Eru·tuon 00:34, 7 August 2017 (UTC)
      The question arose in my mind because some anon using a mobile complained rudely about his phone being ruined by something or someone here. But the question of how fonts look on mobile devices is important. If we don't research it, we probably should rely on MW for that for mobile devices. DCDuring (talk) 04:32, 7 August 2017 (UTC)
      I don't understand what you mean. Doesn't a given font (say, Times New Roman) look roughly the same on a computer and on a tablet or phone?
      And as far as I know MediaWiki has nothing to do with font selection. There might be a default font for the site, but besides that and the font selections that we have added to our CSS pages, browsers are what select which fonts are used for which characters. And they in turn can only select fonts that the user actually has on their device (ignoring web fonts). Avestan, for instance, seems to be unrecognized by my browser; I have the right fonts, but they only show up if the Avestan text is explicitly marked as Avestan (class Avst) and if our Common.css is loaded. So, anyway... I'm not aware of anything that MediaWiki can do for us. — Eru·tuon 05:30, 7 August 2017 (UTC)

I do not support Arial Unicode MS. Although, it may be useful for basic users but it is created for ages, given free with Office, less glyphes and no any update. Its rendering is also awful. Other fonts like Arial, Microsoft Sans Serif, Segoe UI, Times New Roman are okay. --Octahedron80 (talk) 01:09, 20 August 2017 (UTC)

Automatic listing of languages that use a transliteration moduleEdit

Transliteration module documentation pages will now automatically list all languages that use the module, as long as the module is listed either in the language's data file or in the data module Module:translit-redirect/data. The module will also have a category added for each language. Till now, categorization was inconsistent for modules used by more than one language.

Also, for curiosity's sake, modules are categorized by how many languages use them. The record seems to be held by Module:Ital-translit, which is used by 12 languages.

The system isn't perfect: some languages have a dedicated module for one of their scripts, but also redirect to another module. There's no way for Module:languages/byTranslitModule to detect those, as far as I know. — Eru·tuon 05:19, 6 August 2017 (UTC)

Headword templates that should be converted to use Template:headEdit

{{sco-proper noun}}, {{scn-adj}}, {{sw-inf}}, {{rom-adj}}, {{mt-possessive pronoun}}, {{lv-adj}}, {{kj-noun}}, {{id-proper noun}}, {{hil-verb}}. Some of them have very complicated logic if you're looking for a challenge. DTLHS (talk) 00:34, 7 August 2017 (UTC)

Template:eo-head issueEdit

On damoj, the entry is ending up in Category:head tracking/unrecognized pos because it has "plurale tantum" as part of speech category. This isn't a part of speech category, so it should be changed to "noun". —CodeCat 12:21, 7 August 2017 (UTC)

Fixed. —Aɴɢʀ (talk) 14:27, 7 August 2017 (UTC)
I wouldn't call that a fix. Also, there's many more Esperanto entries in that category with the same issue. —CodeCat 16:24, 7 August 2017 (UTC)
@CodeCat, Mx. Granger: Well, it looks to me like MOD:eo-headword needs to be fixed. It shouldn't be hard for {{eo-noun}} to be able to figure this out without arguments. —Μετάknowledgediscuss/deeds 21:28, 7 August 2017 (UTC)
It could be done that way, or "plurale tantum" could be specified using the label template and not through the headword template. — Eru·tuon 21:35, 7 August 2017 (UTC)
I've reverted Angr's edits, which resulted in displaying incorrect inflection information. I don't have an opinion on what the template syntax should be, but the entry should display something like "accusative damojn", not "accusative singular damoj, plural damoj, accusative plural damoj". —Granger (talk · contribs) 23:24, 7 August 2017 (UTC)

Template:mul-semaphore letter, Template:mul-morse letter and Template:mul-morse number issueEdit

As above. The template is specifying an invalid lemma category. —CodeCat 12:31, 7 August 2017 (UTC)

Applying Vietnamese sortkeysEdit

@Fumiko Take, Wyang: The Vietnamese sortkey module has been created, but there are lots of pages with categories added using wikilinks. If they have any diacritics, they will not be correctly sorted. @DTLHS has said that he has a bot script that can convert all these categories to templates, which would apply the correct sortkeys. Would the Vietnamese editors (I don't know who they are, besides @Fumiko Take) be in favor of that? — Eru·tuon 20:01, 7 August 2017 (UTC)

Yes, absolutely. Wyang (talk) 21:22, 7 August 2017 (UTC)
It's done. DTLHS (talk) 04:11, 11 August 2017 (UTC)

I've made Module:vi-sortkey use Module:zh-sortkey (which should perhaps have been titled Module:Hani-sortkey) when it receives Han characters, because that seems to be the way Vietnamese Han characters and its subcategories are already sorted, for the most part. — Eru·tuon 04:43, 11 August 2017 (UTC)

Interwiki RecentChangesEdit

Some days ago, the interwiki links disappeared from the Special:RecentChanges page on (as far as I can see) all languages of Wiktionary, Wikipedia and other projects. What's up? A bug? --LA2 (talk) 20:49, 7 August 2017 (UTC)

I have not heard anything about this. Also no longer on the Special:Watchlist. Maybe WikiMedia removed the link-hub page (or whatever they call that page, the wikidata site-links). I don't think there is any need for interwikis from Special:RecentChanges or Special:Watchlist, so maybe they simply removed the site-links page. —Stephen (Talk) 18:34, 8 August 2017 (UTC)
I noticed that it's also gone from Wikipedia (I don't often look at their recent changes so I don't know if it was removed at the same time). DTLHS (talk) 18:37, 8 August 2017 (UTC)


Almost every day some version of xxx gets added. Can we automatically prevent the addition of terms containing two or more adjacent x characters? SemperBlotto (talk) 05:04, 8 August 2017 (UTC)

The xx's seem to be from random mobile users in countries that don't use the Latin script- mostly Arabic or Persian, with a few Thai. I suspect that most of it is some kind of misapplied phone-OS navigation commands, but the evidence is inconclusive. It's all in the past year or so, so perhaps there's some kind of new dictionary app that's dumping users here with telling them they're editing a dictionary.
There's already a filter to prevent adding small amounts of text with nothing but x's, but it doesn't seem to catch this. I've now added a separate filter for article creations. Please tweak or fix. Chuck Entz (talk) 13:51, 8 August 2017 (UTC)
It's people in India etc. trying to find porn. The titles often indicate this, "xx video", "xx sex" etc. Equinox 17:33, 8 August 2017 (UTC)

Dutch male/female genderEdit

I think this is the right place. I just edited ex#Dutch and added {{nl-noun|mf|exen|exje}} just like the Catalan entry above it. But unlike the Catalan entry, it now says (question mark) "gender incomplete". It isn't! I entered "mf" (male/female) which is correct! See for evidence. This is not the same as neutral gender. An example of neutral gender is Template:nl-noun seems to have no option to have mf gender. W3ird N3rd (talk) 18:55, 9 August 2017 (UTC)

Fixed. You don't have to flip out when you don't know how to do something. --WikiTiki89 18:58, 9 August 2017 (UTC)
Thanks. I'm not really flipping out, but I suppose it can come across like that. If I'm flipping out at all, it's not towards any person here but just towards the templates which nicely convert mf to "m, f" for Catalan but won't do the same thing for Dutch. W3ird N3rd (talk) 19:11, 9 August 2017 (UTC)
"mf" is a specific exception in the Catalan templates. It's not supported by templates generally. —CodeCat 19:03, 9 August 2017 (UTC)
I think the nl-noun template (and any others for languages where mf is possible) should have the mf option added, or the option should be removed from the Catalan template if it's not standard so you don't get unexpected results like I did. W3ird N3rd (talk) 19:11, 9 August 2017 (UTC)
Isn't c how such things are usually marked? —Aɴɢʀ (talk) 20:10, 9 August 2017 (UTC)
c means that the gender is masculine or feminine, but the creator of the entry doesn't know which because they speak a two-gender variety of Dutch. —CodeCat 20:13, 9 August 2017 (UTC)
Yeah, common gender refers to a merger of masculine and feminine genders, not to nouns that can be either masculine or feminine. --WikiTiki89 20:37, 9 August 2017 (UTC)
There isn't any requirement that template parameters have to be standardized. But it might be easier to add |1=mf as an option for {{nl-noun}} than to remove it from the Catalan template, depending on how much mf option is used. — Eru·tuon 21:47, 9 August 2017 (UTC)
{{es-noun}} accepts the parameter too. —Granger (talk · contribs) 21:51, 9 August 2017 (UTC)
I'd rather remove it from Catalan. —CodeCat 22:19, 9 August 2017 (UTC)
It seems {{pt-noun}}, {{it-noun}}, and {{fr-noun}} accept it too. That makes at least five templates we'd be removing it from, maybe more. Moreover, the syntax "mf" is more intuitive than "m|g2=f", in my opinion. I think we should keep the option for the templates that have it and consider adding it to {{nl-noun}}. —Granger (talk · contribs) 22:39, 9 August 2017 (UTC)
They're all Romance languages. Compare that to the many languages whose templates do not allow it. And the most important of all, {{head}}. I can only support this kind of "standardisation" if it can be applied to {{head}} as well. Otherwise the consistency argument is moot. —CodeCat 22:57, 9 August 2017 (UTC)
"There isn't any requirement that template parameters have to be standardized."
There's no requirement for me to eat pizza either, but it sure would be nice. Since {{nl-noun|m|g2=f|g3=n|g4=p|-en|exje}} is also supported, is there a technical reason not to support any combination like {{nl-noun|pmnf|-en|exje}}? I know this example is nonsense, but so is the variant with g2g3g4, this is just easier for multiple genders. Unless of course combinations other than mf simply don't exist in any language, in that case it's more sensible to just support mf. W3ird N3rd (talk) 22:46, 9 August 2017 (UTC)
I've checked a few. (not all) Besides {{pt-noun}}, {{it-noun}}, {{es-noun}}, and {{fr-noun}} this is also supported by {{lv-noun}}, {{ast-noun}}, {{vec-noun}}, {{cy-noun}}, {{gl-noun}} and {{frm-noun}}.
These require g= for any gender but do support mf: {{yi-noun}}, {{ur-noun}}, {{bg-noun}}
These do not support mf but for I don't know if mf would be valid for these languages anyway: {{la-noun}}, {{lt-noun}}, {{wa-noun}}, {{sv-noun}}, {{sh-noun}}, {{gd-noun}}, {{rom-noun}}, {{ar-noun}}, {{osx-noun}}, {{mt-noun}}, {{lb-noun}}, {{ga-noun}}, {{el-noun}}, {{got-noun}}, {{fur-noun}}, {{fo-noun}}, {{ovd-noun}}, {{cs-noun}}, {{br-noun}}, {{be-noun}}, {{sq-noun}}, {{mk-noun}}
W3ird N3rd (talk) 23:42, 9 August 2017 (UTC)


I have created a new template to categorize prepositions based on which case they govern, as a way to help clean up the "(+ accusative)" stuff lying around. Anti-Gamz Dust (There's Hillcrest!) 02:58, 10 August 2017 (UTC)

We already have {{+preo}} for this purpose. —CodeCat 09:43, 10 August 2017 (UTC)
"Module is unfinished"? Anti-Gamz Dust (There's Hillcrest!) 09:56, 10 August 2017 (UTC)

Template:ga-noun creating spurious "whatlinkshere"s (but only three?)Edit

Check out Special:WhatLinksHere/~a and Special:WhatLinksHere/~e. There are hundreds of pages there, all of which use {{ga-noun}} and the parameter |~a or |~e. However, if you look at the actual pages, they don't have links to ~a and ~e, because the template knows to convert them to [[{{PAGENAME}}a]] and [[{{PAGENAME}}e]]. So why are the "whatlinkshere"s being created? And how can we stop them from being created? To make the phenomenon even weirder, {{ga-noun}} uses other similar shortcuts like |~í, but those aren't creating spurious "whatlinkshere"; Special:WhatLinksHere/~í is empty, even though that parameter is also used on hundreds of pages. What gives?Aɴɢʀ (talk) 14:23, 10 August 2017 (UTC)

Special:WhatLinksHere/~ is also populated by a large number of pages using {{ga-noun}} but without actual links to [[~]]. —Aɴɢʀ (talk) 14:55, 10 August 2017 (UTC)

@Angr: I think it is the line {{#ifexist:{{{2|{{{3|{{PAGENAME}}}}}}}}||[[Category:Missing Irish noun forms]]}}. If the input to {{ga-noun}} is {{ga-noun|m|g2=f|~a|~aí}}, this would mean that the code checks to see if [[~a]] exists (and, it doesn't). —suzukaze (tc) 06:23, 17 August 2017 (UTC)
@Suzukaze-c: I could see that that would populate CAT:Missing Irish noun forms even when the noun forms aren't missing, but it's still weird that it would create imaginary links to [[~a]]. Anyway, I'm not a fan of Category:Missing Irish noun forms anyway (it seems really useless to keep track of that, especially when it only looks at the headword line and not at the inflection table), and the person who created it has been blocked indefinitely, so I'm tempted to just remove that bit of code. —Aɴɢʀ (talk) 08:28, 17 August 2017 (UTC)
I have removed the code. —suzukaze (tc) 08:40, 17 August 2017 (UTC)
@Angr #ifexist counts as a link. The same with its Lua equivalent. —CodeCat 11:14, 17 August 2017 (UTC)

What are the advantages to the Reconstruction namespace?Edit

(Apart from letting us adhere to the letter of the rule "only attested terms in mainspace"). A user on da.wikt may be interested in adding reconstructions (which we currently do not have there), but was unsure how to do so. If we all use special namespaces, we can use sitelinks, but da.wikt and eo.wikt (and probably many other versions) do not even currently have appendices. If we all use mainspace (and the same transcription standards), we can let Cognate do all the work. If neither of those, we need to go back to interwikilinks (which is not currently being maintained, see e.g. Reconstruction:Proto-Indo-European/deywós/es:*deywós).
So, what are the advantages?__Gamren (talk) 14:40, 10 August 2017 (UTC)

We find it useful to have reconstructions in a dedicated namespace; the solution at es.wikt, for example, marks reconstructions with the asterisk in namespace and thus confuses them with something like *band (yes, that is a word in English). For us, linking between Wiktionaries is a somewhat secondary concern, and also one that will probably be solved fairly soon for all namespaces, I think. —Μετάknowledgediscuss/deeds 17:28, 11 August 2017 (UTC)
The original reasoning for not putting reconstructions in the main namespace was that they are not attested and therefore do not pass CFI. --WikiTiki89 17:34, 11 August 2017 (UTC)
The asterisk * is not really a part of the reconstructed word, so it is an improvement to omit it in the article title. If we put Reconstruction:Proto-Indo-European/deywós at *deywós, it could be taken to indicate that the asterisk was part of the orthography, as it is in English words beginning with an asterisk. — Eru·tuon 21:00, 11 August 2017 (UTC)

Some questions about adding audio recording of words pronunciationEdit

Hi, I'm from the Hebrew Wiktionary team. I also took part in writing a site for easy recording of mass of words from a lists: (only French UI at the moment).

I wanted to know whether there is already an extension or a bot for uploading audios of words pronunciation to wiktionaries ? I think that an extension where users can record words and add it directly from the wikitionary page just like with editing, could be really cool.

Also, there is this site of words pronunciation forvo , I wanted to know if it is allowed to write a bot that import audio from there to wikicommon?

Thanks —This unsigned comment was added by Shavtay (talkcontribs) at 12:43, 11 August 2017‎ (UTC).

@Shavtay: Try User:Yair rand/AddAudio.js. --Yair rand (talk) 19:16, 14 August 2017 (UTC)

Editor2 and TabbedLanguages2Edit

What are these? Who uses them? Should they be included in legacyscripts gadget? It says it was added temporarily. @Yair rand, what are the development stages of these two scripts? Dixtosa (talk) 17:21, 11 August 2017 (UTC)

@Dixtosa: TabbedLanguages2 works, editor2 may or may not still work. Both are also available as gadgets. We actually had a vote pass back in 2012 to turn on TabbedLanguages for all users, and that was going to happen as soon as someone could write a bot to make sure that categories were placed in the right sections, so that readers wouldn't have relevant categories hidden in other sections. That never ended up happening, afaik. The (intended to be) temporary script added in Common.js (later moved to legacyscripts) allow adding simple enable/disable buttons so that users could easily test the scripts in the intermediary period. I don't know if anyone still has it enabled only through the legacyscripts mechanism, but I suppose we could change it to just enable the gadgets for any remaining users using it that way, and then remove the bit from legacyscripts. --Yair rand (talk) 18:30, 14 August 2017 (UTC)

Collapsible table initially displaying “Collapse” when it is collapsedEdit

For example, the homophone table inside {{zh-pron}} on 勢力 is displaying “Collapse” when it should be “Expand”. The table makes use of the collapsible element wikitable mw-collapsible mw-collapsed and the code is housed at the bottom of Module:cmn-pron. Is there a way to fix this? Wyang (talk) 22:29, 11 August 2017 (UTC)

It seems the collapsible table of {{zh-pron}} is interfering with this subtable. Perhaps id="..." could fix this. Wyang (talk) 22:52, 11 August 2017 (UTC)

Language-specific alphabetisationEdit

I was about to add the information for how to sort Hausa entries when I realised that I still don't know how to solve a long-running problem. I want the letter ɓ to alphabetise after b but before c; this could be achieved by telling the module to sort ɓ as bz, but I also want it to be in a separate section in the categories, since it is considered a separate letter in Hausa. Is this currently possible? If not, could we submit a Phabricator request to make it possible? It would be useful for a great many languages. @ErutuonΜετάknowledgediscuss/deeds 05:28, 12 August 2017 (UTC)

It is possible with new sortkey functionality (Module:vi-sortkey for example). The main annoyance is you have to make sure all categories are routed through the sortkey module, so categories must be templatised in {{C}}, etc. DTLHS (talk) 05:43, 12 August 2017 (UTC)
@DTLHS: When I look at, say, CAT:Vietnamese verbs, words starting with đ are still under D, despite that being a separate letter. I'm saying that I want there to be a Đ section after the D section, if that makes sense. —Μετάknowledgediscuss/deeds 05:49, 12 August 2017 (UTC)
Sorry I misunderstood. I think that this is not currently supported except as a configuration setting for the entire wiki (see [3]) DTLHS (talk) 06:04, 12 August 2017 (UTC)
Extremely hacky dumb solution: you could create a new alphabet that you would sort under (let a = 0, b = 1, ɓ = 2, c = 3, etc), then everything would be in the correct order but the collation headings would be meaningless. DTLHS (talk) 06:51, 12 August 2017 (UTC)
I think that would be worse. Do you think you could file a Phabricator request for category-specific collation? Even if it's not likely to happen any time soon, it would be good to let them know that we could really use it. —Μετάknowledgediscuss/deeds 06:53, 12 August 2017 (UTC)
I second that. It would be a wonderful feature. Having a way to treat digraphs and trigraphs as single letters and to give them their own sections would also be nice – for instance, for Hungarian. That would probably be more difficult than changing the order of the single letters, though. — Eru·tuon 07:20, 12 August 2017 (UTC)
@DTLHS: Make it even more hackier by making fake entries that will be converted to headers using JavaScript. 👍 —suzukaze (tc) 07:14, 12 August 2017 (UTC)
Maybe we should poke the devs some more. They were supposed to have custom collations done ages ago. —CodeCat 10:22, 12 August 2017 (UTC)
I'm thinking the idea related to digraphs could work. In the sortkey, we would convert each digraph or trigraph (or tetragraph, pentegraph) to an arbitrary character that doesn't appear in entry names. Then the new extension would correctly order the sortkeys using a language-specific collation order, and it would generate the headings by converting the arbitrary characters back into the digraphs and trigraphs that they represent.
For instance, dzsessz (jazz) could have the sortkey ₁e₂₂, in which represents the trigraph dzs and represents the digraph sz. (I'm not sure if this is the way a Hungarian dictionary would handle the double consonant ssz. Maybe the sortkey should use s₂ instead.) would be ranked after e in the extension, while would be ranked after s. And instead of placing the entry dzsessz under the heading , it would convert that symbol back to DZS and use that as the heading instead.
This would require that the collation extension be coordinated with whatever Lua module generates the sortkeys (currently, for most languages, Module:languages combined with the sortkey data from the language's data table). That is, whatever generates Hungarian sortkeys would have a list of correspondences between the digraphs or trigraphs and the arbitrary characters chosen to represent them in sortkeys, and the collation extension would have, in its data for the language code hu, an identical list to convert back from the sortkey characters to the digraphs or trigraphs. — Eru·tuon 18:10, 12 August 2017 (UTC)
@Erutuon: That would be every more amazing. But as I keep saying, I need someone else (like you) who can explain this well to file a Phabricator request... —Μετάknowledgediscuss/deeds 18:50, 12 August 2017 (UTC)
The proper solution is to have custom collation for each category. That way, we don't need to bother with sort keys anymore. —CodeCat 19:23, 12 August 2017 (UTC)
We would still need sortkeys, unless the custom collation can somehow create the same effect as the complex sortkeys that we use for Coptic and Vietnamese (see Module:cop-sortkey and Module:vi-sortkey). — Eru·tuon 20:17, 12 August 2017 (UTC)
Also I think it would be preferable in at least some cases to handle digraphs, trigraphs, etc. through sortkeys, rather than having the collation extension automatically consider all possible instances of the correct group of letters as a letter: I suspect that there are languages in which a sequence of letters is sometimes a digraph and sometimes not.
For instance, Serbo-Croatian nadžíveti and pódzēmlje might have instances of d + ž and d + z rather than the digraphs and dz, as the d is at the end of a prefix. I could be wrong about this specific instance. But if there are any examples like this, they would have to be handled by manual sortkeys. — Eru·tuon 00:07, 13 August 2017 (UTC)

Some help developing my Mongolian headword moduleEdit

Here it is: Module:User:Crom_daba/mn-headword. I'm testing it on User:Crom_daba/Sandbox, but for some reason the noun won't display the given head parameter while the verb seems to work fine. Their implementation looks the same to me, what am I not seeing?

"heads" not "head" on line 75. DTLHS (talk) 20:45, 12 August 2017 (UTC)
Gotta love how a fresh pair of eyes can save hours of debugging. Crom daba (talk) 20:50, 12 August 2017 (UTC)

Bug in "+Add new rhyme" featureEdit

The "+Add new rhyme" feature sorts the words using a case-sensitive (Linux-style) sort, so that when, say, adding "dismember" as a rhyme for "November", "dismember" will be listed after "November" instead of before. The sort needs to disregard case. — Paul G (talk) 15:54, 13 August 2017 (UTC)

Sorting is disregarded on save anyways. It never respected sorting. --Dixtosa (talk) 16:42, 13 August 2017 (UTC)
Fixed it anyways. Dixtosa (talk) 16:49, 13 August 2017 (UTC)

Transliterating inflectionsEdit

Could we allow for a way to have inflections transliterated by Module:headword if so requested? I'm making a Mongolian headword module, and I think it would be nice if I could display the transliteration of Uighur script, compare the current state with my module. Crom daba (talk) 18:59, 13 August 2017 (UTC)

Can't you do this with the f1tr, f2tr... parameters, or am I misunderstanding? DTLHS (talk) 19:04, 13 August 2017 (UTC)
Arabic already does this, so the support for it exists in Module:headword. I'm not sure what's needed to get the transliterations to appear. —CodeCat 19:10, 13 August 2017 (UTC)
Here's how this support looks (line 281) tr = part.translit or ((not (parts.enable_auto_translit or data.lang:getCode() == "ar")) and "-" or nil) Crom daba (talk) 23:15, 13 August 2017 (UTC)
I'll update the documentation. Crom daba (talk) 23:17, 13 August 2017 (UTC)
@Erutuon That specific exception for Arabic should probably go, so it can use the generic code. —CodeCat 19:05, 14 August 2017 (UTC)
@CodeCat: Done. Also, @Crom daba, I made it so that you can enable transliteration for all inflections by placing enable_auto_translit = true in the data.inflections table. That's more convenient than having to add enable_auto_translit = true to every inflected form in the table. — Eru·tuon 19:44, 14 August 2017 (UTC)
It would be preferred to only have one way to do it. Are there any modules that use the "old" code? —CodeCat 19:48, 14 August 2017 (UTC)
From a wikitext search, it looks like Module:yi-headword is the only non-sandbox module to use it. The question is if all inflected forms are supposed to have transliterations or not. — Eru·tuon 19:52, 14 August 2017 (UTC)
In the case of Module:mn-headword, only alternative script should be transliterated. Crom daba (talk) 20:08, 14 August 2017 (UTC)
In that case, I guess both ways of turning on transliteration should exist. — Eru·tuon 20:45, 14 August 2017 (UTC)

Watchlist optionsEdit

I'm using Firefox browser with the Vector skin. For the past week or so, I have had trouble with the Watchlist options (appears at the top of the Special/Watchlist page. In the options, you can select your watchlist according to various lengths of time, such as 1 day, 3 days, 7 days, and so on:
Watchlist options
Below are the last 250 changes in the last 72 hours, as of 14 August 2017, 11:20
The problem that I'm having is that, no matter which number of days I select, 1, 3, 7, or 30, I still get the same "last 250 changes in the last" list. It's the weirdest thing. —Stephen (Talk) 11:28, 14 August 2017 (UTC)
That is a technical limitation. Watchlist and recent changes have always had this limitation. Giorgi Eufshi (talk) 11:57, 14 August 2017 (UTC)
Something has changed. Not sure what it is, but for years I have been able to change my default watchlist of 24 hours to 3 days, and I would always see a list of triple length, with such headers as 14 August 2017 (partial day), 13 August 2017 (full day), 12 August 2017 (full day), 11 August 2017 (partial day). No longer. Now all I get is about 14 hours, regardless of how many days I tick. At this moment, even if I select the last 30 days, all I get are the 13 hours corresponding to 14 August, plus one hour of 13 August, beginning with скорее‎, 23:26 (13 August 2017). No matter how hard I try, I cannot see the full list for 13 August 2017, 12 August 2017, or 11 August 2017. —Stephen (Talk) 13:35, 14 August 2017 (UTC)
Okay, I have figured out the problem. It seems that something (it wasn't me) has changed a quantity in my Preferences. I looked in Preferences > Watchlist, and there is a box called Maximum number of changes to show in watchlist. It was set at 250, which is the number that I have been seeing for the past week regardless of the number of days I selected. I reset it to 1000, and now I'm seeing what I have been accustomed to see. —Stephen (Talk) 13:44, 14 August 2017 (UTC)

Edit filter to block edits that add interwikisEdit

diff. Can we get an edit filter to stop edits such as these? The filter should actually stop the edit, not merely warn. —CodeCat 21:19, 14 August 2017 (UTC)

Category:Plurals with a red link for singularEdit

Would it make sense to split this category into multiple ones - one for each language? SemperBlotto (talk) 13:40, 15 August 2017 (UTC)

Yes, it would make it easier to find entries in the language(s) one is interested in. Each one should go in that languages "entry maintenance" category too. —Aɴɢʀ (talk) 14:32, 15 August 2017 (UTC)

Wanted: Gadget to speed linkificationEdit

As I add taxonomic names, I try to linkify any existing entry (actually L2 section) that uses the taxon, but does not link to it. It would be a help to be able to do that, say, from the entry page or from an entry creation page, without have to type the entry name and to obtain a list only containing the taxon not already linked. It would be nice if not only bare links, but also taxa enclosed in templates such as {{taxlink}}, {{m}}, {{l}} were excluded.

It would seem likely that it be possible. Obviously, it would be a resource hog for terms of wide use, like letters, many short words, and function words. Perhaps short terms in Latin and similar scripts at least could be excluded. Would it still be a resource hog? DCDuring (talk) 21:01, 15 August 2017 (UTC)

Number of modules invoked and Lua memory errorsEdit

Part of the reason for so much Lua memory usage is the number of modules that are required or have their data loaded in another Lua module, because there is additional memory used by the require() or mw.loadData functions beyond the size of the module itself.

I don't know how much memory each one requires. I thought it might be a half megabyte based on a test I did once, but that could be wrong. If anyone more digitally astute can find a way to get a more precise figure, that would be nice.

The memory used to transclude each module might explain why pages like air, which invokes 69 transliteration modules, mostly in the Translations sections, use so much memory. (Air is currently at 47.95 MB, and it went over the limit until recently, when I switched many of the Latin translations to the non-Lua template {{t-simple}}.)

Some of this memory could be freed up, then, by merging some of the transliteration modules, so that fewer modules have to be transcluded. There are some candidates that I noticed when I was going through the transliteration modules reformatting and simplifying the code. First, there are quite a few non-Slavic Cyrillic-script transliteration modules, probably for languages spoken in the former Soviet Union, that have similar code for handling iotated vowels. These could be merged to a single module with a bunch of tables for language-specific replacements. Second, there are a number of modules for languages using Canadian syllabics that are really small; they should be combined with the main module. Third, any modules that simply replace each letter with its Latin equivalent (Module:Phnx-translit, Module:Cher-translit) could be easily handled by a single module.

Merging the modules would make it somewhat harder to find the module for a particular language: instead of typing the language code and -translit, people will have to navigate to the correct module using the Modules by language categories. That's already the case for certain modules that are titled with script rather than language codes (for instance, Module:Armn-translit), so it's not a problem in my opinion.

This proposal wouldn't finally solve the memory problem, but would at least defer the final reckoning. — Eru·tuon 22:13, 15 August 2017 (UTC)

Tabbedlanguages miscategorising at ؟Edit

@Dixtosa On this entry, Category:Arabic block and Category:Arabic script characters are placed under the Arabic tab, but these are actually added by the Translingual section and belong there. —CodeCat 19:34, 16 August 2017 (UTC)

Bot request: remove the |style= parameter from {{ja-kanji}}Edit

It is a deprecated parameter (that was theoretically never necessary in the first place, with clever enough code...). —suzukaze (tc) 06:15, 17 August 2017 (UTC)

I think |rs= can also be removed, since Module:ja now invokes Module:zh-sortkey to get the radical and stroke number, if it wasn't added to the template. — Eru·tuon 06:45, 17 August 2017 (UTC)
Theoretically, yes. Technically, Japanese requires a new module (maybe even all of the 漢字文化圏 languages...) due to Han unification combining codepoints for characters whose local variants may have varying numbers of strokes. —suzukaze (tc) 07:12, 17 August 2017 (UTC)
Removed style= from entries. DTLHS (talk) 19:48, 17 August 2017 (UTC)

"Declension", "Personal forms" or what - a question to grammar wizardsEdit

In Finnish there's a class of adverbs that require a possessive suffix which reflects the person of the subject of the sentence. For example, hyvillään (pleased):

Olen hyvilläni. I'm pleased.
Olet hyvilläsi. You are pleased.
Hän on hyvillään. He/she is pleased.
Olemme hyvillämme. We are pleased.
Olette hyvillänne. You are pleased.
He ovat hyvillään. They are pleased.

A comprehensive list of this type of adverbs can be found here: Special:WhatLinksHere/Template:fi-decl-pred-adv.

On each of these pages there's a table showing these forms. The header for the table is currently "Declension". I wonder if that is the correct term, or should the header be something else, like "Personal forms". --Hekaheka (talk) 07:42, 18 August 2017 (UTC)

"Inflection". It works for everything. —CodeCat 10:04, 18 August 2017 (UTC)
I agree. I don't use "Inflection" much, but I do use it for the inflected prepositions of the Celtic languages (e.g. wrth#Inflection). —Aɴɢʀ (talk) 12:45, 18 August 2017 (UTC)
I use "Inflection" for all situations. There's no need to differentiate when they are the same thing. The division between declension and conjugation is Eurocentric anyway. —CodeCat 12:19, 19 August 2017 (UTC)
Or Indo-Euro-centric? The distinction works for Indo-Aryan languages at least. —Aryaman (मुझसे बात करो) 20:14, 19 August 2017 (UTC)

Current font size for the title of Hani-script entriesEdit

is IMO a bit too big (to the extent that it becomes a little frightening); e.g. 獼猴桃. Wyang (talk) 12:04, 19 August 2017 (UTC)

.firstHeading .Hani { font-size: inherit; }. —suzukaze (tc) 23:44, 19 August 2017 (UTC)

Quotations dropdown has changed appearanceEdit

The quotations dropdown [quotations ▼] has changed somehow, with less horizontal space between it and the preceding line of text. Why is that? Equinox 13:29, 19 August 2017 (UTC)

I have moved toggling functionality from the gadget legacy scripts to the main Common.js and changed them a little bit too. But I do not know why the appearance changed. Anyways, I tried to style it as it was before. Is it better?--Dixtosa (talk) 14:24, 19 August 2017 (UTC)
The only difference I see is it is slightly larger. DTLHS (talk) 21:27, 19 August 2017 (UTC)
Can we convert the display of Module:nyms to a similar dropdown appearance too ([synonyms ▼] or something)? Wyang (talk) 00:45, 20 August 2017 (UTC)
That seems impossible since presumably each different line is its own template invocation (one for synonyms, antonyms, ...). DTLHS (talk) 01:05, 20 August 2017 (UTC)
Perhaps feasible by assigning class to each of the templates and using Javascript to convert it to a dropdown? Wyang (talk) 01:14, 20 August 2017 (UTC)

Module:Quotations and WikidataEdit

Would it be possible for MOD:Quotations to automatically get data from Wikidata if the language's data page does not have metadata for a specific work or author? —Aryaman (मुझसे बात करो) 20:13, 19 August 2017 (UTC)