Wiktionary:Grease pit/2018/October

Changing the order of the characters for category sorting

Is creating a sortkey module the only way to do this, or is there a better option? (Apart from or perhaps even a hacky solution like using a specific sort_key replacement).

The order change in question is for Finnish, where "Å" should be before "Ä" and not after it. SURJECTION _{·talk·contr·log·} 14:50, 3 October 2018 (UTC)[reply]

You can have the sort_key table replace Ä and Å with arbitrary characters that have the right Unicode order, but that means that those characters will be shown in the headers on category pages. (Though if you used the Cyrillic Ӓ in place of the Latin Ä, that would at least not be visually confusing.) This seems like something too simple for a dedicated sortkey module. But you can also have Module:columns use a custom sortkey function, and the sortkey wouldn't be visible as it would be in categories. Then templates such as {{der3}} will have the correct sorting. Egyptian is the only language that makes use of this; see Module:egy-utilities. — Eru·tuon 19:58, 3 October 2018 (UTC)[reply]

Terms using å are very uncommon in {{der3}} or other table templates anyway, so categories are really the only place where this would need to be fixed. The sort_keys replacing the headers makes it seem unattractive as a solution to me, even if we use homoglyphs, which means that creating a sortkey module might be the only real way to fix it properly right now. SURJECTION _{·talk·contr·log·} 20:40, 3 October 2018 (UTC)[reply]

@Surjection: But what could a sortkey module do that the sort_key table can't? — Eru·tuon 20:47, 3 October 2018 (UTC)[reply]

Does using a sortkey module also affect what shows up in the header? If so, this will be more tricky than I thought. SURJECTION _{·talk·contr·log·} 20:49, 3 October 2018 (UTC)[reply]

@Surjection: Yeah, a sortkey module just lets you do more complicated things when the language object from Module:languages generates a sortkey. It doesn't change the behavior of the server, which always shows the first letter of a sortkey in category headers, uses sortkeys when paging through a category, etc. There've been requests for more sophisticated category features, but so far nothing has been done. — Eru·tuon 21:02, 3 October 2018 (UTC)[reply]

I could try some ideas I have - for that, I'd need some way to test different values for the sort_key variable, but it seems the module preview does not allow me to list the contents of a category. I wonder if I just have to publish the test somehow... SURJECTION _{·talk·contr·log·} 21:11, 3 October 2018 (UTC)[reply]

If it's just sort order that you're trying to test, you could adapt the code from Module:egy-utilities that sorts a list of words. — Eru·tuon 21:20, 3 October 2018 (UTC)[reply]

The issue is that I'd need to test whether some tricks would work for sorting in categories specifically - the insane idea I had was to use leading spaces and seeing if the MediaWiki code trims them away when sorting the categories. SURJECTION _{·talk·contr·log·} 21:21, 3 October 2018 (UTC)[reply]

You can create your own test categories, just delete them when you're done. DTLHS (talk) 21:28, 3 October 2018 (UTC)[reply]

One leading space is retained at least. For instance, in the category All topics, the subcategories List of topics, Body, and so on have a space as sortkey. — Eru·tuon 21:29, 3 October 2018 (UTC)[reply]

Category:Categories with invalid label

There are over 400 entries in this category. Would anyone like to fix them? SemperBlotto (talk) 09:37, 5 October 2018 (UTC)[reply]

Anything with 0 members can just be deleted. DTLHS (talk) 16:52, 5 October 2018 (UTC)[reply]

West Frisian (fy) in MediaWiki:Gadget-TranslationAdder-Data.js

Can somebody add the following line on line 294: g: ["c", "n", "p"],

This will add checkboxes for West Frisian in the gadget TranslationAdder. Robin van der Vliet (talk) (contribs) 09:50, 5 October 2018 (UTC)[reply]

Added. DTLHS (talk) 16:42, 5 October 2018 (UTC)[reply]

Thank you. Robin van der Vliet (talk) (contribs) 13:28, 7 October 2018 (UTC)[reply]

Number of equal signs for sections such as 'related terms', 'derived terms', and 'synonyms'

I'm confused as to what the standard is (if there is one) for formatting the section heads of sections such as 'related terms', 'derived terms', and 'synonyms' for entries. I have seen them as regular subheadings with three = on either side, but also on other pages I will see them as sub-subheadings with four = on either side. I'd like to know if there's a standard for the whether these should be subheadings or sub-subheadings for when I add them. If there isn't a standard, maybe one should be established so that different pages' formattings match up. If anyone knows please let me know and ping me. I hope the Grease Pit is the right place for this question, if not, also please let me know and I will move it to the correct discussion section. Thanks! 2WR1 (talk) 21:41, 9 October 2018 (UTC)[reply]

If they go under a particular part of speech they should use 4. Sometimes there is no particular part of speech they can be assigned to and then they can use 3 (this is rare). Many editors either do not understand or do not notice header levels so there are a lot of mistakes. DTLHS (talk) 21:42, 9 October 2018 (UTC)[reply]

As a general rule they are one level "lower" or more indented than the PoS to which they apply. The exceptions occur if no one has troubled to split them by PoS, which occurs only(?) for related and derived terms (etymological relations), not for the semantic relations (synonym, antonym, hypernym, hyponym, etc.). DCDuring (talk) 13:01, 10 October 2018 (UTC)[reply]

I’ve sometimes wondered whether it is appropriate in some cases to place derived and related terms at the end of an entry under a level-3 heading if it’s difficult to tell which part of speech the terms relate to. — SGconlaw (talk) 14:12, 10 October 2018 (UTC)[reply]

It's certainly better than omitting them. It seems to me that the uncertainty is mostly between adjective and noun PoSes, though I could see uncertainty occurring between prepositions and adverbs, etc. But, to take an example I am a little familiar with, I don't think it would be hard to split the level-three derived terms at Chinese into level-four noun and adjective derived terms, at least not the blue-linked ones. DCDuring (talk) 14:57, 10 October 2018 (UTC)[reply]

At least in the case of Indo-European languages, adverbs are always primary over prepositions, so the derived terms should probably go there. Synonyms are specific to a sense, not even a POS, so they should use {{syn}}. —Rua (mew) 12:46, 17 October 2018 (UTC)[reply]

Wiktionary:Per-browser preferences and audio

phabricator:T206942

The audio recording option for Firefox is amazing in theory but it never seems to actually save the .ogg files at Commons. Can someone fix this? I would love to use it and have tried many times to no avail (e.g. https://en.wiktionary.org/w/index.php?title=mompreneur&diff=prev&oldid=50483825) This would be a hugely valuable tool if it worked. —Justin (koavf)❤T☮C☺M☯ 18:21, 13 October 2018 (UTC)[reply]

It looks like the script is User:Yair rand/AddAudio.js. @Yair rand: can you help here? —Justin (koavf)❤T☮C☺M☯ 18:30, 13 October 2018 (UTC)[reply]

Cf. Commons thread (permalink). —Justin (koavf)❤T☮C☺M☯ 18:30, 13 October 2018 (UTC)[reply]

Also reported by me earlier at "Wiktionary:Grease pit/2018/September#"Add audio pronunciation" still not working". — SGconlaw (talk) 20:45, 13 October 2018 (UTC)[reply]

On a separate note: I'm not happy with doing on-the-spot recordings due to inevitable background noise (and I worry about fuzzy recordings other people will make, frankly). I have a good tool where I can edit out the noise, but that will never be part of wiki workflow. It would be good to reduce the "file upload" audio approach as much as possible (APIs? tick a box for licence?) for this reason. Equinox ◑ 06:48, 14 October 2018 (UTC)[reply]

an exceptional Latin declension

The Latin noun supellex can't properly be said to be a regular noun of the third declension, because it has an anomalous extra formant -il- in its oblique~plural stem. It's close, though, close enough that it has been bodged into the standard Template:la-decl-3rd. I wanted to edit the text "Third declension." appearing above the inflection table to say something to this effect, but learned that that line is emitted by the Lua module and so this is impossible to do easily. What's the best thing to do here? It doesn't really seem sensible to go and make a new subdeclension template (like Template:la-decl-3rd-I-ignis) given that as far as I know only one word would use it. 4pq1injbok (talk) 09:44, 16 October 2018 (UTC)[reply]

The stem is unusual, but the declension is determined by the desinence, which in this situation mark it as unambiguously part of the third declension. The template output is therefore fine as is. —Μετάknowledge^{discuss/deeds} 22:04, 17 October 2018 (UTC)[reply]

I agree, but I am curious where the abnormal inflection comes from. That's something the etymology section should explain. —Rua (mew) 10:30, 18 October 2018 (UTC)[reply]

Ehhh, "unambiguously" is a strong word. (If we imagine that say the oblique stem of 2nd decl humus had been supplanted by that of humilis, the result wouldn't belong to any one declension unambiguously. Viewed in that light, the fact that we have a 3rd decl nom sg and a 3rd decl oblique paradigm here looks more accidental.) But that aside, if even a normal and well-represented subdeclension like the i-stems can get "i-stem" appended to the "Third declension" in the line above the declension table (Template:la-decl-3rd-I), I think an oddity like this deserves some text appended in the same place.

I'd also like to know (if there's a good answer to) how this came about, but that's a tea-room question... 4pq1injbok (talk) 10:52, 19 October 2018 (UTC)[reply]

Again, this is a matter of the stem and not of the declension. The i-stem paradigm does affect the desinence (e.g., in the gen.pl.). —Μετάknowledge^{discuss/deeds} 15:28, 19 October 2018 (UTC)[reply]

Humus, humilis would be more irregular than supellex, because humus looks like a second- or fifth-declension nominative singular. (If it were neuter, it would be expected to have humor- as its stem, like tempus.) The nominative singular form supellex on the other hand looks like a third declension masculine or feminine nominative singular because it has the ending -s. (It resembles lex.) Third-declension nouns often have a nominative singular with a stem different from that of the other forms, like tempus, temporis or lumen, luminis. Supellex, supellectil- doesn't conform to any of the common patterns of the other third-declension nouns with two stems (such as e in the last syllable of the nominative singular alternating with i in the other forms), but that doesn't mean it's not third-declension; the irregular nominative singular still looks like it belongs to the third declension. Maybe it is suppletive though? — Eru·tuon 19:05, 19 October 2018 (UTC)[reply]

Creating a new Spanish Reference: RANM

I have been adding some entries about Medical terms in Spanish which are not present in general dictionaries like DRAE. They exist, though, in the dictionary of the Real Academia Nacional de Medicina (RANM), which is an official Spanish scientific institution. I think it could be useful to add a template such as {{R:DRAE}}, but for RANM. I personally don't know how to do this, so I'm either asking for help or for someone to do it, if anyone feels like it. I'll leave the URL to RANM's Medical Terms Dictionary here: http://dtme.ranm.es/index.aspx Pablussky (talk) 12:33, 17 October 2018 (UTC)[reply]

@Pablussky: I created a reference template for it at {{R:DTM}}. I'm not sure how useful the dictionary will be, however, because it seems that you need an account to access it. —Μετάknowledge^{discuss/deeds} 22:02, 17 October 2018 (UTC)[reply]

@Metaknowledge It should be {{R:es:DTM}} – no camping on three-letter acronyms, especially with a reference not likely used. Fay Freak (talk) 22:04, 17 October 2018 (UTC)[reply]

Fair point. I've moved it. —Μετάknowledge^{discuss/deeds} 22:06, 17 October 2018 (UTC)[reply]

Template:affix doesn't support term requests

There are a few Proto-Samic entries in Category:Pages with module errors, because of an error message that appears from {{affix}}. I left the second argument empty, to indicate a request for someone to provide it (like {{m}} does), and only provided the third. But this doesn't seem to work, so can someone please make it work? —Rua (mew) 12:45, 17 October 2018 (UTC)[reply]

@Rua: Done, for {{affix}} and for {{compound}} because maybe it could be useful there. I saw the module errors but didn't know what you meant to do there. — Eru·tuon 19:37, 17 October 2018 (UTC)[reply]

Thank you! —Rua (mew) 21:54, 17 October 2018 (UTC)[reply]

Reason dropdown list when deleting a page is broken

The Reason dropdown list when deleting a page is broken. (Well, actually it's just a custom GUI component that doesn't support basic vital functionality.) Specifically: F4 doesn't pop it open like a normal combo box, and also you can't type a letter on it to make a selection (e.g. "V" for "vandalism"): it is deeply crippled compared to the proper Windows GUI control, and has no keyboard support. Can this be fixed? Equinox ◑ 18:06, 19 October 2018 (UTC)[reply]

Typing letters works for me. Is F4 a standard key shortcut that should be expected to work in all browsers? DTLHS (talk) 18:10, 19 October 2018 (UTC)[reply]

On Windows yes. That's the native behaviour for dropdown lists. This is latest Chrome on Win64. Might try Firefox later. Anyway it worked until very recently, probably today. Equinox ◑ 20:22, 19 October 2018 (UTC)[reply]

Update: this started working again recently, it seems. Equinox ◑ 21:07, 10 November 2018 (UTC)[reply]

Remove template testcases from CAT:E

Could an admin change the line

-->|Module={{#ifeq:{{SUBPAGENAME}}|testcases<!--

in MediaWiki:Scribunto-common-error-category to

-->|Template|Module={{#ifeq:{{SUBPAGENAME}}|testcases<!--

to remove template testcases (like Template:quote-journal/testcases) from CAT:E? As with module testcases (which aren't added to the category when they have module errors), sometimes the desired outcome of a template testcase is a module error. — Eru·tuon 19:50, 19 October 2018 (UTC)[reply]

Done. I had to read through the documentation for the {{#switch}} parser function to understand why I was doing it before I felt comfortable doing it- I don't like making changes on a system-wide level that I don't fully understand. Chuck Entz (talk) 04:30, 20 October 2018 (UTC)[reply]

Sinhala Fonts

How does one fix the selection of fonts for the Sinhala script? For headwords some style sheet is imposing the ordering:

Sinhala Sangam MN,KaputaUnicode,KandyUnicode,Dinamina,DinaminaUniWeb,Potha,Madhura,sans-serif;

I think the offender is MediaWiki:Common.css.

The problem is that I don't have Sinhala Sangam MN, KaputaUnicode has very poor support for 'touching letters', and I would like to see by reading whether a link to a Pali entry is to the spelling with or without touching letters. (I'm lucky that hovering over a link displays the URI in a better font.) I would like to have the Windows 7 (and later?) font Iskoola Pota added in first or second place - it has a good coverage of touching letter pairs for Pali. RichardW57 (talk) 13:37, 20 October 2018 (UTC)[reply]

"Lua error in Module:category_tree/poscatboiler/data at line 38: attempt to index field '?' (a nil value)"

... is displayed in some categories, e.g. Category:English list templates. --Der Jud (talk) 11:31, 21 October 2018 (UTC)[reply]

See Wiktionary:Information desk/2018/October#URGENT: Category tree not working. SURJECTION _{·talk·contr·log·} 11:56, 21 October 2018 (UTC)[reply]

Merging of Template:t-needed into Template:t

A little while ago I proposed merging {{t-needed}} into {{t}}, by making use of the fact that linking templates request a term if you don't provide one. There was no objection to that, so I want to get it done, but I'm not sure how the end result should be. [Term?] and please add this translation if you can obviously don't look the same, so should we just use the standard "term?" text that Module:links produces? Modifying Module:links so that it displays something else, for this specific template only, would involve a lot more work. There is a technical aspect too: the current translation adder gadget may require the format that {{t-needed}} currently displays (in particular the span tags surrounding the text), and could break if the format is changed even if the wikicode in the entry stays the same. @Erutuon maybe you can help with this. —Rua (mew) 11:52, 23 October 2018 (UTC)[reply]

please add this translation if you can appears more mannerly to me – [Term?] lets it appear as though there were a lacuna. You could stick with {{t-needed}} though, there aren’t catchy reasons to do anything. You can spare workforce too and save the modules from complexity (it becomes increasingly hard to read the module code, no?) by keeping the templates split. Fay Freak (talk) 17:25, 25 October 2018 (UTC)[reply]

Perhaps, but people do already use {{t}} without a term, simply because other linking templates already work that way. Special:WhatLinksHere/Template:tracking/translations/no term. Making such usage generate an error seems counterintuitive to me. —Rua (mew) 17:29, 25 October 2018 (UTC)[reply]

My first instinct is not to modify Module:links at all and to have Module:translations output the text of {{t-needed}} when a condition is met. What should the condition be: when only a language code has been supplied to {{t}}? — Eru·tuon 19:18, 25 October 2018 (UTC)[reply]

I think this change might result in less Lua memory usage, which is a good thing. At the moment {{t-needed}} invokes two separate module functions that use language data (via {{categorize}} and {{#invoke:languages/templates|getByCode}}); this would be reduced to one if it's merged into {{t}}. As each invoked module function adds a little overhead, fewer of them might mean less memory usage, even when they are doing roughly the same work. — Eru·tuon 19:46, 25 October 2018 (UTC)[reply]

Now that’s what I call a reason to merge. Fay Freak (talk) 20:26, 25 October 2018 (UTC)[reply]

I realize I misunderstood you, Rua, when I wrote my first post (as I guess I'm wont to do), so now Module:translations/sandbox outputs the text of {{t-needed}} under certain conditions, which isn't what you were proposing. Oh well. I'll have to look into your actual proposal. — Eru·tuon 00:17, 26 October 2018 (UTC)[reply]

I looked at the translation adder gadget, and it does mention the class name that is added by {{t-needed}}. I don't really understand the gadget though (yet?) so I can't say whether it needs the class or whether it could be changed to look for the term request instead. — Eru·tuon 23:52, 26 October 2018 (UTC)[reply]

te

This page te has "not enough memory" Lua errors. I have already added it to the exclusion list in the source code of {{redlink category}} and it helped a little. Are there any other tricks to make these errors go away? —Internoob 04:57, 25 October 2018 (UTC)[reply]

Probably replace the uses of {{der3}} and {{rel3}} with manually balanced and sorted lists. DTLHS (talk) 05:01, 25 October 2018 (UTC)[reply]

Removing the linking templates from inside {{der3}} reduced memory enough to remove the module errors for now. {{der3}} creates the same links as {{l}} but with less overhead. In general it's a good idea to reduce the number of linking templates if you can, because each one adds a bit of overhead. Another way to reduce memory is to replace {{der3}} with {{der3-u}}, which doesn't alphabetize the words. — Eru·tuon 05:53, 25 October 2018 (UTC)[reply]

Missed masculine and feminine counterpart parameters in some headword templates

Pray, can someone add |m= and |f= to {{sh-noun}}/Module:sh-headword (@Vorziblix?)? I would have used it often already, like adding poslanica to poslanik, as is done with {{pl-noun}}, {{uk-noun}}, {{be-noun}}, {{ru-noun}}, {{sl-noun}}, {{dsb-noun}} and others, to name only the Slavic, I have checked all: {{bg-noun}}, {{mk-noun}} (Martin123xyz would surely have used them heavily already), {{cs-noun}}, {{cu-noun}}, {{sk-noun}}, {{rue-noun}} lack them too, {{hsb-noun}} does not even exist, ignoring some less well known languages … I wish the head templates would be unified a bit more, one would learn and use them faster. At least this random defect can be remedied. Fay Freak (talk) 18:04, 25 October 2018 (UTC)[reply]

@Fay Freak Unfortunately I still haven’t gotten around to learning Lua properly, so it might take me a good while to figure out what’s going on in the code of Module:sh-headword and add the missing parameters. You might have more success asking Erutuon or Rua, since they’re the ones who worked on the module, although perhaps it’s best not to pester Rua given that she says she ‘will not solve technical problems’ on her user page. — Vorziblix (talk · contribs) 08:47, 26 October 2018 (UTC)[reply]

@Vorziblix: Done, I think. — Eru·tuon 20:05, 26 October 2018 (UTC)[reply]

Thanks! — Vorziblix (talk · contribs) 20:20, 26 October 2018 (UTC)[reply]

Thanks! — Fay Freak (talk) 20:31, 26 October 2018 (UTC)[reply]

Can not interwiki link categories

When I want to interwiki link a category such as sv:Kategori:Kroatiska/Djurungar (Croatian words for baby animals; in Swedish Wiktionary) and its counterpart in Russian Wiktionary, I click "add links" in the left margin and the normal pop-up appears, but when I try to enter the language code (sv or ru), this is just dead text. No text completion happens and the next target field is greyed-out. This has been so for a full day now. What's wrong? --LA2 (talk) 19:11, 26 October 2018 (UTC)[reply]

[1] DTLHS (talk) 22:27, 26 October 2018 (UTC)[reply]

恩-- 周恩恩來; 陶-- 陶行行知; 賈-- 賈平平凹; 路過-- 終有一日，村子裡來來了一個天文學家。他在我家門前路過，突然發現發現了這塊石頭，眼光立即就拉拉直了。

There is a problem with zh-x that is causing a duplication of 恩, 行, and 平. It happens when I add the dash between 恩 and 來, 行 and 知, and 平 and 凹. I don't think I'm making any mistakes. Conversation moved here from Beer parlor. --Geographyinitiative (talk) 02:06, 26 October 2018 (UTC) (modified)[reply]

You can see a similar, probably related problem in the second quotation for 人, sense #4. Maybe more an issue for the Grease pit. --Lambiam 09:43, 26 October 2018 (UTC)[reply]

I very distinctly remember being able to use this...

CHAR-CHAR
(Mandarin) Produce pinyin of CHARCHAR but link to CHAR and CHAR.

...dash between characters without causing this appalling duplication of characters! I don't think I'm making any mistakes, but look at the new example I added at 路過- truly 'sad'! --Geographyinitiative (talk) 03:35, 27 October 2018 (UTC)[reply]

了不起-- 他跑完完了馬拉松 Tā pǎo wánle mǎlāsōng --Geographyinitiative (talk) 03:52, 27 October 2018 (UTC)[reply]

佘-- 佘賽賽花 Shé Sàihuā --Geographyinitiative (talk) 07:04, 27 October 2018 (UTC)[reply]

@Geographyinitiative: Okay, I think I found the reason for the problem. Let me know if it's fixed. — Eru·tuon 07:37, 27 October 2018 (UTC)[reply]

Whoops, other freaky stuff is happening. I'll work on it. — Eru·tuon 07:42, 27 October 2018 (UTC)[reply]

As far as I can tell, you have solved the problem. Thanks! --Geographyinitiative (talk) 08:16, 27 October 2018 (UTC)[reply]

The problem at 人 remains. {{zh-x|人手.一冊|It's a bestseller}} produces “人手一冊 / 人手一册 ― rénshǒu yīcè ― It's a bestseller”. It is not obvious, but there are four red links there. --Lambiam 11:09, 27 October 2018 (UTC)[reply]

@Lambiam: I added that to the informal list of testcases on Module:zh-usex/documentation. If you note any other buggy examples, please add them there. — Eru·tuon 20:03, 27 October 2018 (UTC)[reply]

Fixed. It was because of my changes. — Eru·tuon 20:19, 27 October 2018 (UTC)[reply]

@Erutuon Seems to be still broken on 武林 .. thanks! Wyang (talk) 05:28, 3 November 2018 (UTC)[reply]

@Wyang: The hyphen isn't being removed by the module because it's not between two Han characters after the module has added bolding around the term in the pagename (internally, <b>武林</b>-高手. Do you know if all hyphens (-) in {{zh-x}} mean "link separately but don't add a space to the pinyin"? That would make this easy to fix: all hyphens can be removed. — Eru·tuon 06:07, 3 November 2018 (UTC)[reply]

Oh, actually this version from this summer assumed that all hyphens can be removed. So I can proceed. — Eru·tuon 06:10, 3 November 2018 (UTC)[reply]

Thanks! Wyang (talk) 06:43, 3 November 2018 (UTC)[reply]

@Erutuon: I don't think we can assume that all hyphens can be removed. I was trying to look for an example, but I couldn't until @Mar vin kaiser edited 阿啄仔 recently. The word chit4-tho5 needs its hyphen retained in the example there. — justin(r)leung _{{ (t...) | c=› }} 17:37, 9 November 2018 (UTC)[reply]

@Justinrleung: I checked and the previous version of the module linked above did manage to keep those hyphens. It only removed all hyphens from a word if that word contained a pair of bold tags, or if it contained a hyphen between two Han characters. I'm not satisfied with that solution because it doesn't seem to get at why the hyphens should be kept. Is it that hyphens should be kept if they're a part of romanization? I'm not totally sure how to determine that reliably, but maybe by checking if the hyphens touch a Latin letter or a digit, or are separated from one by bolding. — Eru·tuon 20:04, 9 November 2018 (UTC)[reply]

@Erutuon: I think hyphens should be retained only if both characters surrounding the hyphen (not including bolding) are non-Chinese (i.e. Latin letter or digit). — justin(r)leung _{{ (t...) | c=› }} 20:30, 9 November 2018 (UTC)[reply]

@Justinrleung: Okay, done, I think. — Eru·tuon 00:26, 10 November 2018 (UTC)[reply]

@Erutuon: Looking good! Thanks! — justin(r)leung _{{ (t...) | c=› }} 03:57, 10 November 2018 (UTC)[reply]

文 Lua error: bad argument #1 to 'match' (string expected, got boolean)

--Geographyinitiative (talk) 07:20, 27 October 2018 (UTC)[reply]

Reduplication template? (continued)

Continued from Wiktionary:Grease_pit/2015/May#Reduplication_template?.
Is there any template for reduplication for Wiktionary:Grease_pit/2015/May#Reduplication_template? I will be grateful if someone can make a template {{reduplication}} to be used in etymology sections (not a definition-line form-of template, though, which is why it probably shouldn't be called {{reduplication of}}) that will categorize terms into the language's reduplication category. --Xbypass (talk) 05:31, 28 October 2018 (UTC)[reply]

Done. It does not take the terms however as templates like {{affix}} does, so you will use {{m}}, but one likely writes some additional words between the terms and the word “reduplication” anyway or maybe there isn’t even a known term where the reduplication is from (often it certainly was a reduplication from the beginning). In other words I don’t know what they tossed around in 2015, I have created the template in ten minutes. @Xbypass Fay Freak (talk) 20:33, 28 October 2018 (UTC)[reply]

Thanks a lot. Is it possible to make the {{reduplication}} like {{calque}} which has source word, translation and transliteration? Regardless of that, this is pretty helpful than before. --Xbypass (talk) 16:03, 29 October 2018 (UTC)[reply]

Egyptian hieroglyphs in etymology

Is there a way of making these smaller, and so a large gap is not created beneath them? For instance, see all the entries for basalt. DonnanZ (talk) 12:09, 28 October 2018 (UTC)[reply]

As far as I know, not really, unless we use images in place of WikiHiero. —Μετάknowledge^{discuss/deeds} 19:28, 28 October 2018 (UTC)[reply]

There is Unicode, which looks better on my machine (and for search engine optimizers …). I cannot say how much is covered by Unicode however. Fay Freak (talk) 20:35, 28 October 2018 (UTC)[reply]

There is no large gap with the English example, which is odd, it may be something to do with the added reference. DonnanZ (talk) 21:02, 28 October 2018 (UTC)[reply]

I had not counted Unicode, given that the encoding does not allow for arranging the characters properly, but I just remembered that Unicode is expanding the Egyptian blocks, so that may be (or will soon be) an option as well. —Μετάknowledge^{discuss/deeds} 21:24, 28 October 2018 (UTC)[reply]

Unicode will be able to properly stack hieroglyphs starting in March 2019, if I’m not mistaken. (Its repertoire of glyphs will still be small, but then, so is WikiHiero’s.) Until then we’ve got to make do with WikiHiero. I tried an extremely ad hoc solution using images over at basalt, which seems to work at yielding smaller glyphs, but I don’t think it’s sensible to do that and make a mess of code every time Egyptian hieroglyphs appear. In any case, the ‘large gap’ under the glyphs was not much larger than the gap before any other L3 header (28 pixels for glyphs versus 25 for Latin-alphabet text in my browser). — Vorziblix (talk · contribs) 22:01, 28 October 2018 (UTC)[reply]

Oh, never mind, I misinterpreted what you were saying; I see the problem (you were talking about the non-English entries primarily, and I was just looking at the English one). The full stops after the glyphs are the issue. Because glyphs aren’t rendered inline unless the block of text containing them is enclosed in a <div> element, the periods are getting placed on their own separate lines. I’ll go fix that. — Vorziblix (talk · contribs) 22:04, 28 October 2018 (UTC)[reply]

The unsightly huge gap should be gone now. (I’ve switched back to using WikiHiero glyphs, though, as I don’t think the ad hoc image solution is the right way to go.) — Vorziblix (talk · contribs) 22:11, 28 October 2018 (UTC)[reply]

I'll be damned, simple full stops were the spanners in the works. That's something to remember, I'm sure there's more like that. Anyway, thanks a lot, that leaves the question of hieroglyph size... DonnanZ (talk) 22:30, 28 October 2018 (UTC)[reply]

WikiHiero just broke

The inline display of WikiHiero hieroglyphs inside divs and tables has been repeatedly breaking and unbreaking over the past few hours. It’s currently broken. (See, for example, the ‘alternative hieroglyphic writings’ templates and quotes at jz.) Does anyone know what’s going on? — Vorziblix (talk · contribs) 22:24, 31 October 2018 (UTC)[reply]

Ah, I figured it out; the MediaWiki devs have inexplicably removed .mw-hiero-outer { display: inline-block; } from the WikiHiero css. I’ve raised a concern over at Phabricator, but if they don’t get around to fixing it in a few days over there, I’ll re-add that to the common css over here instead. — Vorziblix (talk · contribs) 00:28, 1 November 2018 (UTC)[reply]

@Vorziblix I just noticed that the Hieroglyph script broke. Thank you Vorziblix, I really appreciate your help. Aearthrise (talk) 14:45, 1 November 2018 (UTC)[reply]

@Aearthrise: No problem! Until it gets properly fixed for everyone, you can fix it for yourself alone by adding .mw-hiero-outer { display: inline-block; } to User:Aearthrise/common.css. — Vorziblix (talk · contribs) 15:53, 1 November 2018 (UTC)[reply]

Fixed now. — Vorziblix (talk · contribs) 16:12, 2 November 2018 (UTC)[reply]

NEC not working

Not the only thing that's broke (referring to the above), New Entry Creator isn't working when I click on "Create entry". It's not the first time this has happened. DonnanZ (talk) 23:04, 31 October 2018 (UTC)[reply]

I think the New Entry Creator code is located here. When I click the "create it using the New Entry Creator" link on the search page, I'm seeing a message in the browser console Error: "Unknown dependency: mediawiki.toolbar". mediawiki.toolbar is mentioned in MediaWiki:Gadgets-definition as a dependency of MediaWiki:Gadget-legacy.js, and MediaWiki:Gadget-legacy.js loads the new entry wizard, so I guess the inability of the JavaScript apparatus to load mediawiki.toolbar is preventing the new entry wizard from being loaded. Why mediawiki.toolbar can't be loaded, I don't know. — Eru·tuon 23:35, 31 October 2018 (UTC)[reply]

Other things may have been fixed, this may have been forgotten about. It's still not working. DonnanZ (talk) 13:30, 2 November 2018 (UTC)[reply]
@DonnanZ: Could an interface admin remove mediawiki.toolbar from the dependencies for "LegacyScripts" at the top of MediaWiki:Gadgets-definition? I can't figure out how that could be causing the problem with the New Entry Creator, but it's the only place where I can find mediawiki.toolbar in the MediaWiki namespace. — Eru·tuon 15:48, 2 November 2018 (UTC)[reply]

@Erutuon: I’ve removed it. — Vorziblix (talk · contribs) 16:15, 2 November 2018 (UTC)[reply]

@Vorziblix: Thanks! That fixed the NEC. — Eru·tuon 16:38, 2 November 2018 (UTC)[reply]

@Erutuon, Vorziblix: The ping didn't work, wrong address but not to worry. Yep, up and running again, it makes the task of writing ==Norwegian Bokmål== easier for a start. Thanks chaps. DonnanZ (talk) 18:09, 2 November 2018 (UTC)[reply]

Edittools is broken

Unable to insert characters ... today. (Chrome) Wyang (talk) 23:42, 31 October 2018 (UTC)[reply]

@Wyang: MediaWiki:Edit.js handles Edittools. It uses mw.toolbar, which has been removed, so maybe that is why it's not working, or maybe the JavaScript error mentioned above is causing a crash even before Edit.js is loaded. — Eru·tuon 00:23, 1 November 2018 (UTC)[reply]

Same problem on ca.wikt I solved it just removing mediawiki.toolbar from MediaWiki:Gadgets-definition and a hard purge of my brower. Not sure of collateral effects. --Vriullop (talk) 12:16, 1 November 2018 (UTC)[reply]

Fixed it. The devs have removed classic toolbar and the javascript libraries it used. Dixtosa (talk) 21:04, 1 November 2018 (UTC)[reply]
Works now. Thanks! Wyang (talk) 23:05, 1 November 2018 (UTC)[reply]

General, serious sluggishness in basic functionality

Using Chrome, sometimes for hours at a time:

When I click on a Citations tab, I am unable to access it, or to stop downloading using the browser. My only recourse seems to be to close the browser tab. The option of then reopening the tab is not available.
The edit window is sluggish and sometimes requires that I click to make visible the characters that I have entered.
Some pages take very long to load.

Have others had similar problems? DCDuring (talk) 12:17, 1 November 2018 (UTC)[reply]

Problem has gone away without any action on my part. DCDuring (talk) 17:12, 1 November 2018 (UTC)[reply]

Wiktionary is broken

Everything on the site broke. I can't even edit the Grease Pit. --XY3999 (talk) 18:11, 2 November 2018 (UTC)[reply]

It is the website finally pushing back against your relentless campaign of new/blocked usernames. - TheDaveRoss 18:17, 2 November 2018 (UTC)[reply]