Wiktionary

Wiktionary:Grease pit/2017/July

< Wiktionary:Grease pit

Puzzling error in template edit

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

Fixed, I think. --Barytonesis (talk) 23:24, 2 July 2017 (UTC)[reply]
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)[reply]
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)[reply]

Request for CSS help edit

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

Isn't it already inline? Like
Sn
 nM1
this. —suzukaze (t・c) 00:54, 4 July 2017 (UTC)[reply]
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)[reply]
I'd like to also be able to control the image sizes. DTLHS (talk) 00:55, 4 July 2017 (UTC)[reply]

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)[reply]

Egyptian:
V17wA3

 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!
Egyptian:
V17wA3
 f (zꜣw)
(Without the <div> on the outside, it seems like the MediaWiki software puts "f (zꜣw)" in its own <p>.) —suzukaze (t・c) 03:53, 4 July 2017 (UTC)[reply]

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

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)[reply]

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)[reply]
The Tibetan one will be like Module:bo-translit, and the Chinese one Module:zh-cat. Wyang (talk) 22:39, 4 July 2017 (UTC)[reply]
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)[reply]
We've had some Chinese entries running out too. —CodeCat 13:38, 6 July 2017 (UTC)[reply]
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)[reply]
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 (t・c) 02:30, 7 July 2017 (UTC)[reply]
@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)[reply]
Thank you! Wyang (talk) 06:06, 23 July 2017 (UTC)[reply]

@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)[reply]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
It looks great and correctly sorted now. Thank you! Wyang (talk) 08:45, 31 July 2017 (UTC)[reply]

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)[reply]

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

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)[reply]

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 (t・c) 20:13, 31 July 2017 (UTC)[reply]
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)[reply]
Pinging @Eirikr because actually I don't use {{{sort}}} much (it's hard to remember which templates need it...) —suzukaze (t・c) 00:27, 1 August 2017 (UTC)[reply]

Clipping of a foreign word edit

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

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

Module:links edit

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)[reply]

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

Cantons of Luxembourg category edit

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

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

Search oddity edit

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Script classes on automatically generated category pages edit

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

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

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

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)[reply]

Linking of individual words in the headword line edit

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

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)[reply]
@CodeCat: Your fix just broke all the templates that use |head=. —JohnC5 17:24, 7 July 2017 (UTC)[reply]
I just removed the default headword, which seems to fix the problem. — Eru·tuon 18:06, 7 July 2017 (UTC)[reply]

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 gà". 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)[reply]

{{cog|vi|gà}} = Vietnamese gà --Daniel Carrero (talk) 06:21, 8 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
{{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)[reply]
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)[reply]
OK, I've created the redirect. Test: Vietnamese gà, Proto-Indo-European *ḱwṓ. Excellent! --Florian Blaschke (talk) 10:38, 21 July 2017 (UTC)[reply]
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)[reply]

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

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

  Done — Eru·tuon 10:09, 9 July 2017 (UTC)[reply]

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

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

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

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

(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)[reply]
Okay, I've done that. Could you check again and see if the display problem remains? — Eru·tuon 18:11, 9 July 2017 (UTC)[reply]
Unfortunately it still looks the same to me. Here's what I get [1]
— Radixcc 📞 19:44, 9 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
@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)[reply]
@Erutuon: Ok started talk page asking if I could go ahead and do this. MediaWiki talk:Mobile.css — Radixcc 📞 01:39, 10 July 2017 (UTC)[reply]

Sessions Not Persisting edit

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

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)[reply]
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)[reply]

CAT:E edit

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

@Erutuon —Aryaman (मुझसे बात करो) 17:15, 10 July 2017 (UTC)[reply]
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)[reply]
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)[reply]

Oldest pages ordered by last edit edit

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

I wouldn't mind either. --Barytonesis (talk) 21:03, 12 July 2017 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

@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)[reply]
@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)[reply]

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

Broken table edit

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

  Done — Eru·tuon 21:29, 12 July 2017 (UTC)[reply]

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

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

I think it should probably be changed. Same with Category:English terms with usage examples. --Daniel Carrero (talk) 01:34, 13 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Bot request: "bor" template edit

Discussion moved to Template talk:bor#Bot cleanup.

Changes to affix categories edit

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

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

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

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

Italics vs plain text as contrast in CSS edit

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

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

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

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

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

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

Search problem edit

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

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)[reply]
But that's not the whole problem. DCDuring (talk) 19:31, 18 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]

Frequency list edit

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

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)[reply]
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)[reply]
Wiktionary:Frequency lists/Telugu DTLHS (talk) 22:45, 18 July 2017 (UTC)[reply]
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)[reply]

Cannot see "show" label in expandable items edit

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

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

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

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)[reply]
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)[reply]
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)[reply]
I did so. No use. --Wanjuscha (talk) 21:46, 21 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
I disabled Javascript in Firefox, now I can see everything expanded. --Wanjuscha (talk) 09:37, 31 July 2017 (UTC)[reply]

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? ばかFumiko￥talk 07:32, 20 July 2017 (UTC)[reply]

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

Importantion of categories to Wikidata edit

Dear Wiktionarians,

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

For what purpose? DTLHS (talk) 21:23, 22 July 2017 (UTC)[reply]
@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)[reply]
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)[reply]
@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)[reply]
Could you clarify what importing categories to Wikidata means? — Eru·tuon 21:25, 22 July 2017 (UTC)[reply]
@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)[reply]
@PokestarFan: Ahh! Is that related to adding interwikis for categories? — Eru·tuon 23:35, 22 July 2017 (UTC)[reply]
Didn't we already do that a month or so ago? —CodeCat 10:40, 23 July 2017 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Proto-Tani edit

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)[reply]

  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)[reply]
@Erutuon: Thanks! Can you add tbq-pro as an ancestor of Proto-Tani? —Aryaman (मुझसे बात करो) 02:47, 24 July 2017 (UTC)[reply]
  Done; I gather the canonical name should be Proto-Tibeto-Burman. — Eru·tuon 03:04, 24 July 2017 (UTC)[reply]
Facepalm. Misread the request. Moved Proto-Tani to the Tibeto-Burman family. — Eru·tuon 03:55, 24 July 2017 (UTC)[reply]

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)[reply]

Added. DTLHS (talk) 23:22, 24 July 2017 (UTC)[reply]
Thanks! — Vorziblix (talk · contribs) 23:26, 24 July 2017 (UTC)[reply]
@Vorziblix: Where is this "Traditional Coptic sort order" attested? --WikiTiki89 18:48, 25 July 2017 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]

@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)[reply]

@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]

@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)[reply]

@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)[reply]
@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)[reply]

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)[reply]

@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)[reply]
@Vorziblix:   Done. — Eru·tuon 05:10, 31 July 2017 (UTC)[reply]
(Generated a list with AWB, if that's helpful: ˋϣⲗⲏⲗ, ˋϩⲙⲟⲧ, ˋⲁϧⲱⲙ, ˋⲉϩⲟⲟⲩ, ˋⲉϫⲱⲣϩ, ˋⲉⲙⲉⲛⲧ, ⲙⲁˋⲛϣⲁⲓ, ⲣⲉϥϯˋⲥⲃⲱ.) — Eru·tuon 05:17, 31 July 2017 (UTC)[reply]
@Erutuon: Thanks again! — Vorziblix (talk · contribs) 05:21, 31 July 2017 (UTC)[reply]

Improved search in deleted pages archive edit

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

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

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

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

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

Loading web fonts edit

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

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

Template:module cat edit

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

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

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

lua error: not enough memory edit

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

@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)[reply]
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)[reply]

label American spelling edit

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)[reply]

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

e is in CAT:E edit

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)[reply]

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)[reply]
Yes, but I also want all the entries for letters to go... —CodeCat 10:21, 30 July 2017 (UTC)[reply]

Add m and f genders for Pashto in the translation adder edit

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)[reply]

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)[reply]
@Erutuon Thanks! I've added "m","f","m-p","f-p". --Anatoli T. (обсудить/вклад) 06:15, 29 July 2017 (UTC)[reply]

Broken links; can't find topics edit

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)[reply]

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)[reply]
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)[reply]
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)[reply]

Labels not working edit

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)[reply]

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)[reply]
@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)[reply]
@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)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2017/July&oldid=65118054"