Wiktionary:Grease pit/2020/June

From Wiktionary, the free dictionary
Jump to navigation Jump to search

Broken Indic Fonts for Pali[edit]

The Windows 10 font Nirmala UI looks broken for Pali. If we can find suitably licensed replacements for the afflicted scripts, can we still serve them, or will readers have to download them individually?

The first problem is that it appears to have no support for touching consonants in the Sinhalese script, which appears to be the way clusters are mostly written in Pali. The Windows 8 font Iskoola Pota supported them, but it may be incompatible with the USE, making it of limited use on windows 10, even if it be legal.

The second problem occurs in the Bengali script. The font not only normally renders U+09B0 BENGALI LETTER RA at the start of a consonant cluster as a repha, but also U+09F0 BENGALI LETTER RA WITH MIDDLE DIAGONAL. The latter is being used by some on the Internet as the letter for Pali /v/ (no evidence for citations that I am aware of). The default font on Ubuntu (at least, at 16.04) only converts U+09B0 to repha. There is a work around for this problem, which is to insert w:ZWJ in front of the virama (a.k.a. hasant), but this will need spellings without ZWJ to redirect to spellings with ZWJ. Fortunately, they're fairly rare, so long as we don't start systematically creating entries for the second person present middle of the verb. @Octahedron80 has been adding the fix of inserting ZWNJ to the transliteration and inflection modules. --RichardW57 (talk) 13:07, 1 June 2020 (UTC)[reply]

I changed ZWNJ into ZWJ already and I forgot to shortnote. --Octahedron80 (talk) 13:35, 1 June 2020 (UTC)[reply]
Sorry, 'ZWNJ' was a typo for 'ZWJ'. --RichardW57 (talk) 13:57, 1 June 2020 (UTC)[reply]
At the moment Wiktionary doesn't serve fonts to users. They would have to download them. — Eru·tuon 23:10, 1 June 2020 (UTC)[reply]
I must say that ZWNJ & ZNJ are already ignored when searching, so redirection may not need. --Octahedron80 (talk) 04:11, 2 June 2020 (UTC)[reply]
They aren't always ignored. When I did a 'full text search' for Pali අන‍්වාස‍්සවති (anvāssavati) with touching 'nv' (non-existent), I didn't find අන්‍වාස‍්සවති (anvāssavati) with conjunct 'nv'. The difference is that the letters are joined by <ZWJ, virama> in the touching case, and <virama, ZWJ> in the conjunct case. I now have a font that shows the difference, but I haven't tested it on Windows. --RichardW57 (talk) 17:12, 9 June 2020 (UTC)[reply]
Transliteration and conjugation have now been fixed so that 'nv' forms a conjunct rather than touching. Declension didn't break. --RichardW57 (talk) 20:50, 9 June 2020 (UTC)[reply]
The Sinhala font (provisionally named LKLUG_T) has now been tested on IE11. It works in IE11 on Windows 10 but has some issues on Windows 7. It goes incredibly wrong in Safari on iPhone 6 and 7. MS Edge seems to have switched to the HarfBuzz renderer, and it works fine with that renderer. --RichardW57m (talk) 22:22, 12 June 2020 (UTC)[reply]
Safari exhibits a low-level bug in AAT that can afflict any script. I need to decide which way to work round it. --RichardW57 (talk) 17:06, 15 June 2020 (UTC)[reply]
Basic problems now fixed, at Version 0.002. Worst are now that NFD vowels don't render properly in Windows/iOS renderers, but Wiktionary is stored in NFC; and that Windows 7 won't handle touching consonants before e/o. I've even added support for the stem vowel in words like brūti - other Sinhala fonts don't seem to support it! --RichardW57 (talk) 09:10, 17 June 2020 (UTC)[reply]

Lao script also needs new letters published in Unicode 12 to display Pali/Sanskrit that general fonts do not provide. Very few fonts are available. I currently use Lao Pali Alpha. --Octahedron80 (talk) 05:07, 2 June 2020 (UTC)[reply]

Fix categorization of US standard spellings as "American English forms"[edit]

Currently the code {{standard spelling of|en|term|from=US}}, see for example dishonor, places terms in Category:American English when it should actually place them in the more specific Category:American English forms. I personally, don't know how to make such a change because the category placement isn't coded locally into Template:standard spelling of. A similar problem does not seem to exist for the code {{standard spelling of|de|term|from=SLDE}}, see for example Fussnähe, the reason for which is unclear to me. Given that the template is only used ~800 times, the change isn't a high priority. Many thanks. —The Editor's Apprentice (talk) 01:05, 3 June 2020 (UTC)[reply]

I believe this has to do with the fact that the "SLDE" label is used only for forms, while the "US" label is used primarily in sense-line context labels and is set up for that, rather than for forms. There is a label "American spelling" which forces terms into "Category:American English forms" instead of "Category:American English", including if used as a sense-line context label. Whether it's better to attempt to monitor the usage of the various labels to ensure {{standard spelling of}} and various occurrences of the {{label}} use "American spelling" while other occurrences of the label use "US", or to set up {{standard spelling of}} to treat "US" as an alias of "American spelling" (which I think we could do), I'm not sure (because in the latter case, we might still want to use "American spelling" / "Category:American English forms" on some sense lines). - -sche (discuss) 19:55, 4 June 2020 (UTC)[reply]
The fact that Template:standard spelling of seems to use information from Module:labels/data and its sub-modules makes sense to me in terms of efficiency, but still comes off as counterintuitive because it and Template:label service different purposes. Regardless, your later suggestion to create an alias seems reasonable to me, but I don't think I understand your reservation about it in the way that you've conveyed it. Could you clarify what possible problem your referring to in "we might still want to use 'American spelling' / 'Category:American English forms' on some sense lines"? Thanks. —The Editor's Apprentice (talk) 21:51, 4 June 2020 (UTC)[reply]
@-sche: It has been about a month at this point since this thread has seen activity, so I'm following up to see if you can clarify the meaning of your previous statements and to see what the next steps in resolving the issue might be. Thanks again. —The Editor's Apprentice (talk) 21:03, 6 July 2020 (UTC)[reply]
@The Editor's Apprentice A more ideal solution would be for the "standard spelling of" template, and others like it that take from= parameters, to know to strip the "spelling" from the display text of the "American spelling" type labels; however, we'll have to ask people more technically adept than me to do that. In the meantime, I have implemented the gross kludge I suggested in Wiktionary:Tea_room/2020/June#travelled, which does work, bringing about the right combination of display and category. - -sche (discuss) 08:26, 7 July 2020 (UTC)[reply]

Udmurt inflection table[edit]

Hi! I am trying to create a collapsible inflection table for an Udmurt noun, but I cannot find how to do this as there seems to be language-specific code that automatically creates it by providing the noun class and such, and Udmurt doesn’t have such a system in place. I could just insert a table but I would like to do this the right way ;)🙂 Can anyone help? I am aware of the existence of this page, and I've browsed through this help page for templates, but it doesn't say how to add a language that isn't in the list (or maybe it does but I didn't understand). Thanks in advance — This unsigned comment was added by AengusB (talk • contribs) at 15:11, 3 June 2020 (UTC).[reply]

You'll need to create a new template (and perhaps a module). There are several existing inflection table templates which can serve as an example, but many of the more complicated ones will use modules, particularly if the forms could be generated automatically. Would this be possible and desired? — surjection ⟨??⟩ 23:14, 5 June 2020 (UTC)[reply]
This would be desired. How do I create a new template? — This unsigned comment was added by AengusB (talk • contribs).
By creating a new page in the Template namespace. It's probably better to prototype the template first in user space, such as perhaps under Template:User:AengusB/udm-decl. You can use existing inflection templates, such as Template:vot-decl, as a base. The template syntax can be a bit daunting, so this page can be helpful. — surjection ⟨??⟩ 23:23, 28 June 2020 (UTC)[reply]
If the template syntax comes across as too difficult, I can create the template and module, but I'd need to know how Udmurt inflection works. — surjection ⟨??⟩ 23:25, 28 June 2020 (UTC)[reply]

Lua memory error[edit]

The si article has a memory crash after the letter R. Unlike the cases of water and wind, the translations of the word aren't what's causing these errors, but the sheer amount of languages the word exists in. I think we should split the article into circa three parts, alphabetically. — This unsigned comment was added by ComradeDiana (talk • contribs) at 17:48, 4 June 2020 (UTC).[reply]

How do you propose handling the links to the word 'si'? The easy option, for now, is to restrict each entry to being a soft redirect to one of the three parts. That forces extra clicks on users. The hard option is to have a central database of pages treated thus, so that at least templates {{l}} and {{r}} redirect to the new page. Perhaps we want {{l|exx|si}} to redirect to si/exx#exx, with si/exx being either the page for the word in language exx, or a redirect to one of the three parts. What other templates would need to be fixed? --RichardW57 (talk) 01:57, 5 June 2020 (UTC)[reply]
Correction: Language code 'exx' should be expanded to the language name in those page names and links. --RichardW57 (talk) 08:52, 5 June 2020 (UTC)[reply]
On general principle, English and Translingual should probably be made exceptions. Sense definitions are supposed to reference English lemmas without any qualification for language, so in particular, the English entry should remain in full on the page si. Having exempted English, it seems silly not to exempt translingual. --RichardW57 (talk) 08:52, 5 June 2020 (UTC)[reply]
I have never done any large changes like this to Wiki, so I don't really have a design in mind, nor do I know how to put one into practice. I did try to create a new article with A-E in it, but the site rejected my request, probably because I have a new Wiki account and haven't done any other changes with this one. I would appreciate it if a more experienced Wiki user could make this split article into a reality, or come up with and execute some other solution. ComradeDiana (talk) 16:50, 9 June 2020 (UTC)[reply]
Serious surgery on the page si should have community acquiescence. Modification of {{l}} and {{m}} would almost certainly require it simply be reasons of permissions. Now, someone who frequently makes accepted edits to the pages for Welsh might get away with replacing the Welsh section with --RichardW57 (talk) 00:47, 10 June 2020 (UTC)[reply]
==Welsh==

Please see overflow page si/Welsh instead.  This page (si) is unusable for the Welsh word.

----

and putting what should have gone in the Welsh section of si in the new page. It needs an extra click from the user, but it's probably better than what he gets nowadays. --RichardW57 (talk) 00:47, 10 June 2020 (UTC)[reply]

@RichardW57: The problem with doing that is that we have so many templates and modules that refer to the pagename. In the case of si#Welsh, for example, if we moved the content to si/Welsh, then {{cy-noun}} would output "si/Welsh m (plural sïon)" in the headword line. Yes, that could be overridden by adding |head=si to {{cy-noun}}, but how often will people remember to do that? And other languages have inflection tables that take the pagename as their basis; those templates and the modules they're based on would all have to be rewritten. I'm sure it's a solvable problem, but it will be much more work than simply moving the content to subpages and calling it good. —Mahāgaja · talk 08:54, 10 June 2020 (UTC)[reply]
@Mahagaja: How many times? In the near future, 3 or 4 pages per language is all it takes. And as you've noted, many templates and modules already have a parameter that overrides the page name. There's one problem that would have to be solved more centrally - categories. When one expects to find a word in a list, it will be disconcerting to see a file name like 'si/Welsh'. Or is this solved already? --RichardW57 (talk) 12:30, 10 June 2020 (UTC)[reply]
@Mahagaja, RichardW57: That's not a real problem. Those templates should already be using {{SUBPAGENAME}} {{BASEPAGENAME}} in place of {{PAGENAME}}, and can easily be modified. —Μετάknowledgediscuss/deeds 19:28, 11 June 2020 (UTC)[reply]
@Metaknowledge: Isn't the {{SUBPAGENAME}} of si/Welsh "Welsh" rather than "si"? —Mahāgaja · talk 19:40, 11 June 2020 (UTC)[reply]
@Mahagaja: Yes, sorry. I meant to say {{BASEPAGENAME}}, and have fixed my comment above. —Μετάknowledgediscuss/deeds 19:43, 11 June 2020 (UTC)[reply]
@Metaknowledge: Actually, I just checked. In mainspace, slashes aren't treated as creating subpages anyway, so {{PAGENAME}}, {{BASEPAGENAME}}, {{ROOTPAGENAME}}, and {{SUBPAGENAME}} all return "si/Welsh". —Mahāgaja · talk 19:47, 11 June 2020 (UTC)[reply]
@Mahagaja: Thank you! This is news to me, and I apologise for the misinformation above. —Μετάknowledgediscuss/deeds 19:56, 11 June 2020 (UTC)[reply]
You're addressing the mostly solved problem, at least, while overflow pages are the exception. How about the problem of putting the word in a category? We want 'si', and not 'si/Welsh', to appear in the lists of Welsh nouns, Welsh lemmas and Welsh terms with IPA pronunciation. --RichardW57 (talk) 20:27, 11 June 2020 (UTC)[reply]
Is there a planned long term solution? Or are we hoping to accommodate a thousand or more languages on a page? It does seem that Lua processes aren't being managed as envisaged. --RichardW57 (talk) 12:30, 10 June 2020 (UTC)[reply]
The problem isn't this page, it is overuse of overbuilt templates. Let's reconsider whether we really need thousands of lines of code to generate what is effectively [[si]]. - TheDaveRoss 15:35, 10 June 2020 (UTC)[reply]
If we reckon on eventually documenting at least a thousand languages, each in a fairly uniform style, then we do. We can either use just templates, which will require lots of lines of fairly obscure code, or use modules, which are snappier and easier to understand, but are rationed and tempt people to do more, such as creating automated categories. One of the usual big usages is transliteration of translations, and that is wanted for uniform appearance. That is currently being addressed by hiving it off to separate pages. --RichardW57 (talk) 19:17, 11 June 2020 (UTC)[reply]
We have a hammer-nail problem here, the only tool we regularly use is modules, so we try and solve every problem with modules. Bots, Wikidata and toolserver tools are also effective ways of maintaining things, and they suffer far fewer limitations than modules do. Wikipedia has much larger pages and diverse needs, and I have yet to ever encounter a Lua error when browsing one of their pages. I am not claiming it doesn't happen, but it doesn't need to happen here. - TheDaveRoss 13:05, 12 June 2020 (UTC)[reply]
From previous investigations, it seems that at present the problem with modules is not lines of code in them (that affects time), but rather the number of modules. Is this correct? Pali has four commonly used modules, for transliteration from the Latin script (called by almost every Pali entry), for declining substantives, and for conjugating verbs. The latter two share non-trivial utility routines; they are stored in the more frequently used declension module. The declension module also loads the inflectional ending from a script-dependent data module. I had been thinking that for speed and symmetry, I should take the utility routines out of the declension module and make a separate utility module. It looks as though rather we should combine the three and the Latin script data module into a single module. --RichardW57 (talk) 11:23, 12 June 2020 (UTC)[reply]
The way we use "data modules" is what leads to the memory issues, the parser can't pull just the "Pali" section of a huge module it has to pull the whole thing and parse it, reading the entire contents into memory. Modules do not have a reasonable data structure associated with them (like Wikidata does) and using them as lookup tables is foolish. - TheDaveRoss 13:05, 12 June 2020 (UTC)[reply]
@TheDaveRoss: Is one of these 'huge modules' Module:languages/data2? If it is,you're implying that we would do better if it were split up, perhaps even merely by the first letter of the 2-letter language code and perhaps similar splitting for the three level codes. (We use about 20 such data modules for 69 languages.) Has anyone done the experiment? I vaguely recall something along the lines of using smaller modules making matters worse - but perhaps I'm getting confused with mw.loadData not helping. --RichardW57m (talk) 23:58, 12 June 2020 (UTC)[reply]
The merger of the four modules is repugnant to me:
  1. I believe Wikidata is using the declension data modules, which causes some tension with @Octahedron80, as I want to retire the non-Latin declension data modules for maintainability reasons and transliterate out of Latin on the fly. (There are issues as to whether textbooks are treating aberrant forms as applicable to any noun of the same declension - we need to build up data on actual usage. We have no mechanism for RfVing mere inflections.)
  2. It slows down the rendering of individual pages. (I suppose we eventually do hit time-space tradeoffs.)
  3. It seems contrary to good software practice and causes conflicts. For example, Octahedron80 was changing Bengali script spelling while I was orthogonally working on extending the conjugation tables to cover the future, conditional and aorist tenses. --RichardW57 (talk) 11:23, 12 June 2020 (UTC)[reply]
One unexploited feature is that the results of each call change fairly infrequently. The caching of pages exploits that. Perhaps what we need is the caching of level 2 sections. Alternatively, is there a mechanism we can use so that the results of templates on a page are mostly updated no more than once a week? We would want different bits to be updated at different times. It might be possible to do clever things with templates that are currently just little more than {{#invoke:...}}. --RichardW57 (talk) 19:17, 11 June 2020 (UTC)[reply]
While everyone's been discussing, I cleared the module error at si by commenting out a Latin reference module that was using over 3 MB to list 6 phrases. I also replaced one instance of {{desctree}} with one instance each of {{desc}} for the daughter language and for the granddaughter language (that saved about .3 MB). I don't expect this to last, since it's now at 49.38 MB, but at least people will be able to see the Welsh entry for a while. Chuck Entz (talk) 06:29, 13 June 2020 (UTC)[reply]
Did you chase down what was swallowing up the memory? It looks to me as though an entire book is being loaded, but I may have missed data comprehension tricks. I did see some big indexes being loaded into {{Module:R:M%26A}}. --RichardW57 (talk) 11:26, 14 June 2020 (UTC)[reply]
My technical ignorance is far greater than yours, so it's way over my head, but it looks to me like a case of using complicated data structures designed for other environments with problems we don't have. I know very little about sharding, but it seems like its only effect here is to make the modules incomprehensible and to stymie any attempts to reduce the system load in certain entries. Chuck Entz (talk) 16:53, 14 June 2020 (UTC)[reply]
As to the discussion: one issue that we need to think about as well is modules that access other entries. This often provides functionality that can't be provided any other way, but it also adds the wikitext from an entire entry to the memory total. Then there's the matter of Module:zh-forms, which reads the wikitext from its own page into Lua memory so it can do quality control... Chuck Entz (talk) 06:29, 13 June 2020 (UTC)[reply]
I'm limited by my technical ignorance, but things like trees of descendants look like something that should be handled by a database. The same goes for unpredictable transliterations; I assume CJK is where that is most likely to start causing problems, but I was aghast when I saw that the rendering of Thai quotes (@Octahedron80) now appears to be looking up the page for almost every word in them. My first thought as to an implementation is that a bot could go round updating a family of modules called Module:desc:<langcode>:<lemma> that recorded a list of descendants along with relevant attributes - language and borrowed or not immediately spring to mind. Obviously the call of require() or loadData() would have to be 'protected' by pcall() or similar - I'm not expecting the module to exist for every lemma. --RichardW57 (talk) 10:46, 14 June 2020 (UTC)[reply]
Thai can afford to do that, since its script is only used by a small number of languages and thus the pages are small. Desctree is actually a good idea most of the time, because our other problem is the centralization of ordinary content in specialized templates and modules- which makes it hard for ordinary users to work with. It just has to be avoided in entries with memory problems. If you think about it, most of the entries in mainspace in common scripts have relatively few generations of descendants, so replacing desctree with hardcoded lists in such cases isn't that problematic. It's not that big a part of the problem, anyway. The CJKV entries are where the technique is causing some real damage, but it's also where it's hard for someone with my limited lua knowledge to see a better way to do it. Chuck Entz (talk) 16:53, 14 June 2020 (UTC)[reply]

Broken "newbies" link at top of watchlist[edit]

At the top of my watchlist are some links labelled "Utilities". One of those links has the text "newbies" and points to Special:Contributions/newbies. That page gives the error message 'User account "Newbies" is not registered.' Not sure what the link is supposed to do, but seems like it's probably not working as intended. Colin M (talk) 19:46, 4 June 2020 (UTC)[reply]

Removed, see diff. The devs had broken it on purpose. —Μετάknowledgediscuss/deeds 19:37, 11 June 2020 (UTC)[reply]

Mobile main page special casing will be disabled in July[edit]

EN WT Main Page, as viewed on an iPhone on 2020-06-29.

I was alerted to this by being added to phab:T254287 (I guess because I've edited the Mobile.css/Mobile.js pages?), and mention it here so we can discuss what, if anything, we need to do. - -sche (discuss) 19:47, 4 June 2020 (UTC)[reply]

Here is the link to follow: https://en.m.wiktionary.org/?mfnolegacytransform=1&debug=1. It is definitely inferior on an iPod Touch with large boxes exceeding screen width. Word of the day is invisible off screen to right unless I scroll over to see it. Vox Sciurorum (talk) 12:37, 5 June 2020 (UTC)[reply]
To keep the current behaviour, it looks like we can use option 1 and then then add the nomobile class to all main elements except the WOTD boxes? - Jberkel 13:51, 5 June 2020 (UTC)[reply]
@Erutuon just to be sure you're aware of this in case you have input. (As an aside, our mobile display of dictionary entries is awfully sparse and full of white empty space around headers, etc.) - -sche (discuss) 19:38, 6 June 2020 (UTC)[reply]
Thanks for the ping. The new version of the main page is pretty awful on my phone because the main content area is about half again as wide as it should be. (I'm surprised how spare the current version is: it only shows WotD and FWotD. Seems like it should at least say "free dictionary" somewhere.) I don't know much about mobile-friendly CSS but might try to improve it. — Eru·tuon 08:27, 28 June 2020 (UTC)[reply]
Saw this thread and had a look out of curiosity.
On iOS 13.5.1, the main page looks like the image on the right when viewed on my mobile (stitched together into a full image).
This definitely seems to be lacking some important elements... ‑‑ Eiríkr Útlendi │Tala við mig 00:34, 30 June 2020 (UTC)[reply]

Formatting Chinese articles[edit]

Discussion moved from WT:Beer parlour/2020/June#Formatting Chinese articles.

Since the demise of my old computer, I have been using my phone to look at some articles. I noticed that on my phone, zh-pron is smooshed up against the left hand side of the screen due to zh-wp on pages like 北京 (Běijīng). Terrible user experience. Is there anything that can be done about this? Geographyinitiative (talk) 09:41, 4 June 2020 (UTC)[reply]

On an iPod Touch 7 using Safari it renders fine in portrait mode: character decomposition above wikipedia links above pronunciations. If I rotate to landscape the pronuciation section is slightly squeezed, for example the Taishan pronunciation has a line break between bak2 and gen1. Any CSS hackers here? The box might want more horizontal space for Chinese when there are many dialects (topolects, languages, whatever your favorite term). Vox Sciurorum (talk) 16:51, 4 June 2020 (UTC)[reply]
@Geographyinitiative, Vox Sciurorum: I moved this to where people with the right technical expertise will see it. Chuck Entz (talk) 02:30, 5 June 2020 (UTC)[reply]
I did not get a notice of this ping. I have notification on for mentions and received a notice as recently as June 2. Vox Sciurorum (talk) 12:30, 5 June 2020 (UTC)[reply]
I didn't get a notice either. Geographyinitiative (talk) 01:45, 6 June 2020 (UTC)[reply]

Split alt form/spelling functionality off of T:ja-kanjitab[edit]

Since T:ja-spellings has been deprecated, there has been a push to replace it with ja-kanjitab. As a result, entries that are kana-only (for example, いむ) are now using kanjitab. I think this is counter-intuitive and a kludge; it's like buying a microwave with a time display and only using it as a clock. Alternate forms/spellings is a secondary function of kanjitab, which is unrelated to the primary function of providing information on kanji. Alt forms should be handled by a dedicated template, perhaps incorporating, generalizing and replacing T:ja-forms and/or T:ja-kanji forms as well. — 173.72.25.32 04:29, 5 June 2020 (UTC)[reply]

Regarding the background: {{ja-kanjitab}} is about kanji. Most alt forms are kanji. It made sense to put this information in that template. See, for instance, the katakana entry ビール (bīru), which uses {{ja-kanjitab}} to point to the rare alternative kanji spelling 麦酒.
For spinning this off, I'd suggest that we loop in Nyarukoseijin (talk • contribs), who is (I think) the user most savvy regarding the {{ja-kanjitab}} template and related modules. I think this topic may have even come up before (spinning off the alt form functionality). ‑‑ Eiríkr Útlendi │Tala við mig 06:31, 5 June 2020 (UTC)[reply]
I agree. Let's revive T:ja-spellings and incorporate kanji info into it. If we have a large table of kanji readings built into the module, {{ja-spellings|あぜ,畦,畔}} would need no |yomi=k.
The problem is, I don't have a bot, and the editors who have bots arent interested in improving the Japanese entry layout. --Nyarukoseijin (talk) 07:23, 5 June 2020 (UTC)[reply]

Recording quotes[edit]

I have noticed recently Category:English terms with quotations isn't appearing at the bottom of the page when a quote is added. Yet the quotes are recorded in the category, e.g. matching and drone, so I don't think I have done anything wrong. DonnanZ (talk) 14:42, 5 June 2020 (UTC)[reply]

Nor are usexes being shown at the bottom any more, check matching. DonnanZ (talk) 14:49, 5 June 2020 (UTC)[reply]

Ah, someone turned both of them into hidden categories. Why? DonnanZ (talk) 15:32, 5 June 2020 (UTC)[reply]

@Donnanz: I looked at the histories for Category:English terms with usage examples and Category:English terms with quotations and John Cross was the person who made the changes. At the category for terms quotations John Cross gives the reason "this is a maintenance template". Interestingly, the category for terms with usage examples was originally created as a hidden category by Koavf, but was shortly afterwards made visible. I personally don't know of any policy, official or de facto, concerning which templates should be hidden, but the two users I mentioned might be able to provide some detail. —The Editor's Apprentice (talk) 17:46, 5 June 2020 (UTC)[reply]
@The Editor's Apprentice, John Cross: I would not regard these two as maintenance templates, but as reference categories. A maintenance category is something like Category:etyl cleanup/de and other categories which are hidden (for red links etc.). DonnanZ (talk) 18:06, 5 June 2020 (UTC)[reply]

Hello. These categories sit within Category:English_entry_maintenance. I don't know of any policy on this. I don't feel strongly about this. My thinking was that we should hide categories that are unlikely to be useful to users who are not contributors. John Cross (talk) 21:30, 5 June 2020 (UTC) Pings: @Donnanz:; @The Editor's Apprentice:.[reply]

@John Cross: Looking in that category doesn't answer the question why they are in there. Two more casualties are Category:English terms with IPA pronunciation and Category:English terms with audio links. All four of these I would regard as references rather than maintenance categories (which of course should be hidden). I would prefer these to be shown rather than having to click on "edit" to find them, which is a nuisance. I wonder why Category:English words following the I before E except after C rule (and the other one) missed being treated this way, categories I find irritating. DonnanZ (talk) 22:18, 5 June 2020 (UTC)[reply]
@Donnanz: I don't feel strongly about this. I have unhidden four categories. John Cross (talk) 22:36, 5 June 2020 (UTC)[reply]
@John Cross: Thankyou! DonnanZ (talk) 22:51, 5 June 2020 (UTC)[reply]

Table cell borders disappear in mobile view[edit]

In desktop view, the declension table cells have white borders on a gray or green background. In mobile view, the borders disappear. Example: észszerű. What can I do to keep the cell borders in mobile view? Panda10 (talk) 20:37, 5 June 2020 (UTC)[reply]

"Scene" parameter for Template:quote-video game[edit]

Please see the discussion at Template talk:quote-video game#Scene. Glades12 (talk) 13:42, 9 June 2020 (UTC)[reply]

False alarms from "blank line before first heading" filter with subst:zh-new[edit]

Another case where the filter should look at text after template substitution: https://en.wiktionary.org/wiki/Special:AbuseLog/925955 — This unsigned comment was added by Vox Sciurorum (talk • contribs) at 12:25, 11 June 2020 (UTC).[reply]

@Vox Sciurorum: Fixed. The filter now skips over edits containing a template that looks like a new entry template, with a name consisting of a language code and "-new". — Eru·tuon 02:27, 12 June 2020 (UTC)[reply]

Language-specific categories should link to proper language[edit]

Links from automatically-generated language-specific category pages should add the appropriate language anchor. For example Category fr:Virology should link to virion#French instead of virion and zh:Squirrels should link to 松鼠#Chinese instead of 松鼠. Vox Sciurorum (talk) 12:39, 12 June 2020 (UTC)[reply]

They do link there on my end. Maybe you're missing some gadget? —Rua (mew) 12:52, 12 June 2020 (UTC)[reply]
If a gadget is a JavaScript thingy, I don't let those into my browser. Why can't the language code be embedded into the HTML? Vox Sciurorum (talk) 14:45, 12 June 2020 (UTC)[reply]

{{t-needed}}, {{not used}} in translations[edit]

The translation adder stopped accepting the template {{t-needed}} (with a language code as a parameter). I see there were some welcome changes (maybe unrelated), which allow the full preview of the translations but this little functionality is lost.

An example: I have tried {{t-needed|he}} on Judaization and got the error message: Please don't use wiki markup ({}#) in the raw page name.

Also, it would be good to allow {{not used}} to close pesky translation requests where a language is not used, a good example is the where a number of languages don't have or don't use articles as part of speech at all or abbreviations, such as UK. Asking @Erutuon, hopefully, it's not a very complex task. --Anatoli T. (обсудить/вклад) 04:28, 13 June 2020 (UTC)[reply]

template:zh-forms in 周瑜打黃蓋——一個願打，一個願挨[edit]

一個's gloss is displayed as 

{{n-g|Combination of the numeral 一|one and the generic classifier: a; an; one

. 恨国党非蠢即坏 (talk) 03:59, 14 June 2020 (UTC)[reply]

Other spacenames in other language[edit]

I'm not sure where to ask so I just try asking it here. I edit in Malay Wiktionary and we don't have the Appendix, Rhyme, etc spacename. How to get it? --Tofeiku (talk) 05:47, 15 June 2020 (UTC)[reply]

@Tofeiku: They're called namespaces. They have to be requested specially from the developers, which you can do at Phabricator. —Μετάknowledgediscuss/deeds 06:12, 15 June 2020 (UTC)[reply]

Lua error: not enough memory at page 我[edit]

It begins from 我#Etymology_5_2. --Frigoris (talk) 08:47, 15 June 2020 (UTC)[reply]

Huh. Apparently even {{rfe}} uses Lua now. This might be part of the problem -- lots of Lua in places where it might not be needed...? ‑‑ Eiríkr Útlendi │Tala við mig 16:36, 17 June 2020 (UTC)[reply]

Abuse filter suggestion: confirm bad template name[edit]

A recent change to screen[1] added a reference to an undefined template. Or at least it was undefined when I looked, with bold red text. Seems like this should at least generate a warning. I assume it wasn't vandalism, and if so a request for confirmation before publishing should be sufficient. Vox Sciurorum (talk) 11:24, 15 June 2020 (UTC)[reply]

Custom Conjugation-Template Error[edit]

I've been attempting to create a conjugation template for the word 'wexan' as per the request for inflection template and since the automated table didn't recognize 'wexan' as a strong verb. Upon erasing all unnecessary and extraneous stecks of text in the sandbox it then gave me an anouncement that i had overbroken a rule of some sort. I would like to say that no harm nor overbreaking was meant, just that i wished to include content on a page so lacking. Thank for the time.

Special:Tags, especially "new-IW"[edit]

It doesn't work correctly, e.g. diff is tagged with "new-IW" but it didn't add an InterWiki link but just a Theusaurus link. --Brain-Dwain (talk) 12:57, 18 June 2020 (UTC)[reply]

be careful what you wish for[edit]

Can someone please fix the Spanish link in the translation section? I totally shafted it. --Nueva normalidad (talk) 23:00, 20 June 2020 (UTC)[reply]

create conjugation template for Lombard[edit]

Hello everyone!

I've been looking for resources that would explain how to create a conjugation template, and I found a page in which it said to ask for help in here. I would just like to create a conjugation table for Lombard, possibly basing myself on the ones for Italian, but I can't seem to find a way to do it. Do you know whether there is a simple guide anywhere?

Thanks in advance!

--Nicodebig (talk) 11:27, 22 June 2020 (UTC)[reply]

Perhaps Wiktionary:Templates and Wiktionary:Scribunto (and maybe also w:Help:Wikitext). I don't know but if you are not familiar with this, I think the best way is to make a copy of the template you are basing on (and also, if there is one, the module generating the table) in your sandboxes, and try to learn and modify the code to make the template look like what you want. 恨国党非蠢即坏 (talk) 20:23, 22 June 2020 (UTC)[reply]

Main Page cascade[edit]

Main Page needs to be cascade-protected again, as (F)WOTD templates can be freely edited by anybody. What are the technical reasons to not keep it that way? — surjection ⟨??⟩ 22:28, 22 June 2020 (UTC)[reply]

It's even worse when I just realized that WOTD templates literally have an "edit" link on them. They're practically begging for main page vandalism - what a terrible idea. — surjection ⟨??⟩ 22:30, 22 June 2020 (UTC)[reply]
The templates should be individually protected. @Ungoliant MMDCCLXIV can speak to that. —Μετάknowledgediscuss/deeds 01:41, 23 June 2020 (UTC)[reply]
I've restored cascading protection of the Main Page for now. It can be undone as soon as the (F)WOTD templates are protected. I can't figure out how else to protect each day's template without having to cascade-protect each day's page individually, or at least each month's archive page. I mean, I could cascade-protect Wiktionary:Word of the day/Archive/2020/June for this month, but then someone would have to do that for each month's page, which isn't realisic. —Mahāgaja · talk 05:47, 23 June 2020 (UTC)[reply]
Probably easier and cleaner to do it with an abuse filter. Chuck Entz (talk) 06:09, 23 June 2020 (UTC)[reply]

CJK Unified Ideographs Extension G[edit]

Please make pages for these: https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg51/IRGN2327Codechart.pdf — This unsigned comment was added by 72.76.214.176 (talk).

Why? They will certainly have no useful content besides the usual technical Unicode attributes, and probably so for years. —Suzukaze-c (talk) 06:23, 27 June 2020 (UTC)[reply]
But don't you ever wanted to be able to type Biang Biang Noodles on the computer? — This unsigned comment was added by 72.76.214.176 (talk) at 22:58, 28 June 2020 (UTC).[reply]
To clarify what Suzukaze-c probably intended to say, we don't want to create them all at once because we won't have any content but Unicode data, which is quite useless. We should create entries when we have a proper definition for each character in question. — justin(r)leung { (t...) | c=› } 23:04, 28 June 2020 (UTC)[reply]
Also, we already have entries for 𰻞 and 𰻝. — justin(r)leung { (t...) | c=› } 23:05, 28 June 2020 (UTC)[reply]
Wiktionary entries won't help you type 𰻝 anyway, just copy-and-paste. —Suzukaze-c (talk) 03:16, 29 June 2020 (UTC)[reply]

WOTD and FWOTD Abuse Filter[edit]

I've created an abuse filter that keeps anyone but a bot, admin or autopatroller from editing any page in the Wiktionary namespace that starts with "Word of the day" or "Foreign Word of the Day", with the exception of Wiktionary:Word of the day/Nominations Wiktionary:Foreign Word of the Day/Nominations and Wiktionary:Foreign Word of the Day/Focus weeks. The restrictions can be made different for the WOTD and FWOTD groups if need be.

This should allow the removal of cascading protection from the Main Page once it's enabled (I thought it better to get opinions from people more familiar with such things (@Sgconlaw, Metaknowledge, Erutuon to start with) before doing so. Chuck Entz (talk) 06:32, 25 June 2020 (UTC)[reply]

I'm not entirely familiar with abuse filters, but it sounds good. Are all editors in good standing automatically made autopatrollers, or is this a status that has to be requested and granted on a case-by-case basis? Also, does this mean I need not specifically protect the daily WOTD (i.e., pages in the format "Wiktonary:Word of the day/2020/June 25")? I guess I will still need to protect the actual entry pages from anonymous editing on the day that they appear as WOTDs? — SGconlaw (talk) 08:16, 25 June 2020 (UTC)[reply]
Autopatrollers are nominated and approved via the whitelist. As for what's covered: anything in the format "Wiktionary:Word of the day/..." is protected unless explicitly exempted. The way it's currently written, "Wiktionary:Word of the day/Nominations" is editable by anyone, but "Wiktionary:Word of the day/Nominations/..." subpages are protected. That's the whole point of using an abuse filter: you can use all kinds of programming logic on the page name, the user's account name (including IP addressees) and other information, and even content of the edit or page itself to decide what to do about the edit. Cascading protection is totally indiscriminate- if it's transcluded in the page it gets protected. Chuck Entz (talk) 08:39, 25 June 2020 (UTC)[reply]
@Metaknowledge: so just to be clear, I need not individually protect pages in the format "Wiktionary:Word of the day/2020/July 1" any longer, but I should protect the individual entry pages (e.g., dromedary) that are featured? — SGconlaw (talk) 09:00, 1 July 2020 (UTC)[reply]
@Sgconlaw: I think so, but to be clear, this is something that @Chuck Entz executed, not me. —Μετάknowledgediscuss/deeds 16:02, 1 July 2020 (UTC)[reply]
@Metaknowledge OK, thanks (and thanks to @Chuck Entz as well). — SGconlaw (talk) 16:22, 1 July 2020 (UTC)[reply]

Any means of easily seeing additions to translation lists, filtered by target language?[edit]

An issue came up over at Wiktionary:Requests_for_deletion/Non-English#あなたとその軍隊, and it occurred to me that this is more of a Grease Pit kind of thing.

Basic problem:

  • I focus on Japanese. I can patrol anon edits to JA pages by scanning Special:RecentChanges for Japanese text. However, edits to non-Japanese-script entries to add Japanese translations are largely invisible to me.

Admins / tech-heads, is there any way of flagging translation additions by target language? I suspect such a feature would be useful to all of us who patrol entries for vandalism and other general rubbish.

‑‑ Eiríkr Útlendi │Tala við mig 16:43, 25 June 2020 (UTC)[reply]

There is a straight-forward way, but I don't know what complications it would cause. If {{t}} were allowed to categorize Japanese entries and you watched that category, the entry with such additions would appear in your watchlist.
You could also process the XML dump (run twice a month) looking for instances of {{t|ja}}, subtracting the ones that were in previous dump runs. The limitations of that should be clear, but it might be sufficient.
You would also think that the mechanism used for the input filters could be put to work for your purpose. DCDuring (talk) 23:31, 25 June 2020 (UTC)[reply]
Good thoughts. I'm not a huge fan of XML dump diffs, in part due to complexity and data size, and in part due to the time limitations (only twice a month).
The categorization idea is intriguing.
As is the input abuse filters thought -- however, I know next to nothing about this feature. I don't even know where to look to find out more. Does anyone have a link to such materials? ‑‑ Eiríkr Útlendi │Tala við mig 23:47, 25 June 2020 (UTC)[reply]
You could also search for them with something like this- sorting options include edit date or creation date. DTLHS (talk) 23:54, 25 June 2020 (UTC)[reply]
The help page for Cirrus Search has full instructions for using regular expressions, "explicit sort orders", and ways of making sure your search is not too much of a resource hog. DCDuring (talk) 00:06, 26 June 2020 (UTC)[reply]
The ability to watch category pages has been around for just a year or two, I think. You can get the idea by just putting any category you like (perhaps Category:Japanese nouns) on your watchlist. Then the question is only whether it would be a resource hog or something. You can also add a table to a category that contains the n most recent additions to the category. DCDuring (talk) 23:58, 25 June 2020 (UTC)[reply]

Precautionary log out of all users[edit]

Hi all,

According to the linked mailing list post, everyone on Wikimedia wikis will shortly be logged out and will have to log back in again.

Due to a configuration error, session cookies may have been sent in cacheable responses. Some users had reported that they saw the site as if they were logged in as someone else. The number of affected users is believed to be very small. However, resetting all sessions is done as a prudent measure to ensure that the impact is limited.

See also, the complete mailing list thread.

--Kaartic (talk) 08:25, 26 June 2020 (UTC)[reply]

Ah, so that's what happened. — SGconlaw (talk) 08:38, 26 June 2020 (UTC)[reply]
Yep :) --Kaartic (talk) 19:16, 26 June 2020 (UTC)[reply]

Can someone please semi-protect the offline landing page?[edit]

Hola,

I've finally gotten around preparing a bare-bones landing page that looks better for offline users (try staring at the same Word of the day for 6 months in a row to get an idea). It's at Wiktionary:Offline. Can someone semi-protect it? It's probably not super necessary, but it's a good way to let you guys know the project is circulating well beyond the usual boundaries :-) Thanks The other Kiwix guy (talk) 17:14, 26 June 2020 (UTC)[reply]

"6 months in a row" – is that how often content gets updated? For the WOTD, there's a category with all the previous words, so in theory Kiwix could just randomly pick a new one every day. – Jberkel 18:00, 26 June 2020 (UTC)[reply]
Well we do have a German sailor that picks up a new copy every 3 years, but yeah I would say 6 months is short for updates (more often 1 year, as the new school year starts). I suggested we semi-randomize the WOTD part, but apparently it's more complicated than that. The other Kiwix guy (talk) 18:38, 26 June 2020 (UTC)[reply]
I didn't even know there was an offline version of the project. I've protected it so that only autoconfirmed editors can modify it. Did you want a higher level of protection (template editors and administrators only)? — SGconlaw (talk) 19:06, 26 June 2020 (UTC)[reply]
Thanks. Full protection would prevent me from editing it further, so let's keep it at that. And yeah, the project is pretty popular - mostly in the Global South but I've seen a couple of prison programs use it in rich countries as well. We ought to be better at communicating about it. The other Kiwix guy (talk) 05:17, 27 June 2020 (UTC)[reply]
@The other Kiwix guy: OK, great. Regarding WOTD, the plan is to eventually create a fixed fallback set of 366 entries on pages in the format "Wiktionary:Word of the day/[month] [day]" which would kick in if a new WOTD hasn't been set (which are now on pages with in the format "Wiktionary:Word of the day/[year]/[month] [day]". I don't know if these will be of help to you? I suppose once a full set of these fixed 366 WOTDs has been put in place, you could update Wiktionary:Offline to show a different WOTD depending on which date the offline version is viewed. I'm happy to work with you on this. I have set some of the fallback WOTDs but not all of them, as I'm generally working more on setting the "live" WOTDs that appear on the Main Page. — SGconlaw (talk) 16:32, 1 July 2020 (UTC)[reply]
@Sgconlaw: That would be ideal but I don't know how feasible it is on our end (I'm clearly not the techie in the team). Ping me when you roll out the feature and I'll ask people to look into it. The other Kiwix guy (talk) 09:23, 3 July 2020 (UTC)[reply]
@The other Kiwix guy: could you (or someone else) explain a bit about how the offline version works? For example, if someone runs Wiktionary on a CD, is it possible for the Wiktionary:Offline page to figure out what the current date is (technically speaking, will magic words like {{CURRENTDATE}} work)? If so, I could see if I can put a WOTD on Wiktionary:Offline that refers to the pages in the format "Wiktionary:Word of the day/January 1" to "Wiktionary:Word of the day/December 31". These pages actually already exist; it's just that a lot of them may refer to outdated events because, as mentioned, I haven't had time to set permanent fallback entries. — SGconlaw (talk) 09:42, 3 July 2020 (UTC)[reply]

"Kanji in this term" boxes are placed weirdly, bug?[edit]

Please see the page 因#Etymology_2. The three "Kanji in this term" boxes following that section are positioned like staircases, going from NE to SW. I loaded the page in Firefox and Safari and saw the same thing. --Frigoris (talk) 17:25, 26 June 2020 (UTC)[reply]

I fixed the immediate problem, though there may be better ways. The problem is that the etymology sections are so short that the ja-kanjitab boxes were overlapping slightly. Those are supposed to be aligned to the right side of the page, but if there's something already taking up the right side of the page, they align to the right side of the available space. I'm not sure if there's anything that can be added to the template to keep it from overlapping with other right-aligned objects while still allowing overlap with everything else- but I'm not exactly a wiz at html and css. Chuck Entz (talk) 18:10, 26 June 2020 (UTC)[reply]
@Chuck Entz: thanks! --Frigoris (talk) 18:22, 26 June 2020 (UTC)[reply]

Template (and module) linking to incorrect category[edit]

I'm currently working on expanding Wiktionary's lexicon of Jarai entries, but a problem has popped up; Jarai nouns have classifiers, and as such link to their appropriate classifier categories, though some categories are not linked properly.

Example: 

{{jra-noun|cls=čô}}

should link to Category:Jarai nouns classified by čô, but links instead to Category:Jarai nouns classified by ô (see e.g. amĭ). Currently it only applies to 2 entries, but as more are added, it will become a bigger problem.

Template:jra-noun uses Module:jra-headword, though I don't have the programming know-how to (a) identify the issue, or (b) resolve the issue, so I'd like someone more experienced than me to take a look at it. The module also looks to be copied wholesale from Vietnamese with the names switched out, so there could be some additional cleanup here.

Kind regards, Orcaguy (talk) 00:34, 29 June 2020 (UTC)[reply]

@Orcaguy: The module looks for words that are composed of the characters in p.letters. č isn't in the list so that character is ignored and the module thinks the classifier is ô. (Categorization also fails in aku, with {{jra-noun|cls=ƀĕ}}, because both ƀ and ĕ aren't in the list.) If you add all Jarai characters to the list, categorization will work correctly. — Eru·tuon 04:06, 29 June 2020 (UTC)[reply]
Thanks. I've replaced p.letters with the appropriate character set for the language.
Orcaguy (talk) 13:27, 29 June 2020 (UTC)[reply]

Invisible Module Errors From Bad Roman Numerals[edit]

I've been seeing cases lately of invisible module errors caused by feeding the output of {{R2A}} directly or indirectly into a parser function. This causes the page to show up in CAT:E, but the parser function eats the error message without displaying anything. That means that I have to do some detective work to figure out which template has the error, and which parameter to the template needs to be fixed. It looks like the module has a parameter that can be passed to tell it to return nil instead of an error message, but I'm a bit fuzzy on how one would use it.

Another solution that occurred to me would be to have a dedicated function in the module that would take an alleged Roman numeral expression and return a value that could be used to avoid the {{R2A}} part of the expression (unless it would be preferable to have the template blow up in an obvious and unpleasant manner so @Nueva normalidad... I mean the per[petrator]son who added the template would notice that something was wrong).

Either way, all of these quotation templates should be modified to stop feeding module errors into parser functions. Pinging @Erutuon, Benwing2, Sgconlaw as people who might be able to do something about this. Chuck Entz (talk) 06:46, 1 July 2020 (UTC)[reply]

Module:roman numerals, on which {{R2A}} relies, was developed by @DTLHS and @JohnC5, and also edited by Erutuon. Among other things, it is used by {{quote-meta}} to determine whether a chapter number has been stated in Roman numerals or Arabic numerals, for example:
{{#if:{{R2A|{{{chapter|}}}|no_error=1}}
 | [Result if the chapter number is a Roman numeral]
 | [Result if the chapter number is not a Roman numeral]
}}
Perhaps this is what is generating the error? I'm afraid I do not know how to fix this as I'm unfamiliar with Lua. — SGconlaw (talk) 08:44, 1 July 2020 (UTC)[reply]
Here's an example from shortly after I posted this. You can look through the entire entry (even after you unhide the quotes) and the wikitext without seeing any obvious indication of where the error is. I've learned from troubleshooting these over the years to always look first at the history to see what's been changed, then at the histories of the templates and modules in the transclusion list if the entry itself hasn't changed. In this case, it's obvious that not having a Roman numeral in the volume parameter is causing the error, and the template has a couple of lovely pieces of abstract art:
|volume         = {{#if:{{{volume|}}}{{{1|}}}
    | {{uc:{{{volume|{{{1|}}}}}}}}
    | {{maintenance line|<nowiki>please specify |volume=I, II, or III</nowiki>}}
  }}

|pageurl        = https://archive.org/details/greatexpectation0{{R2A|{{{volume|}}}{{{1|}}}}}dick/page/{{#ifeq:{{{page|}}}{{{3|}}}{{{pageref|}}}|1
    | n{{#ifeq:{{uc:{{{volume|}}}{{{1|}}}}}|I
        | 8
        | 6
      }}
    | {{{page|{{{3|{{{pageref|}}}}}}}}}
  }}/mode/1up
One of which has to be the source of the error.
The first one works fine as long as it gets a Roman numeral passed to it, but otherwise either passes the bad input on to the |volume= parameter of {{quote-book}} or passes it a formatted error message when both |volume= and |1= are empty.
Note: After looking closer at the code in writing this up, I'm even less certain of what's really going on here then when I first posted this, so I may have completely misinterpreted something- but I don't have time right now to go further down the rabbit hole to find out. Chuck Entz (talk) 15:17, 1 July 2020 (UTC)[reply]
I hope the other editors familiar with modules can shed some light on what's happening. I'm guessing it's an issue with {{R2A}}, because I'd be really surprised if the mere fact that a parameter like |volume= that is not assigned a value is generating an error. If so, that's really strange programming, because surely we cannot expect editors to be using all the parameters in a template all of the time. — SGconlaw (talk) 16:43, 1 July 2020 (UTC)[reply]
Looks like {{R2A}} normally emits an error when it receives something that can't be parsed as a Roman numeral; with |no_error=1 it instead emits nothing. But templates often use {{R2A}} (search query: template: insource:"r2a") without this parameter, or in positions where the error message from {{R2A}} might be invisible, like in URLs or the undisplayed parts of parser functions (for instance, {{#if: {{R2A|bad Roman numeral}} }}. When the output from {{R2A}} is invisible and it is a Lua error message, the page with the invalid Roman numeral will still be put in CAT:E but there'll be no indication as to why. Templates should always use |no_error=1 in {{R2A}} when it is invisible, or {{R2A}} should be modified to not display an error by default. To display a message when {{R2A}} is invisible, the template can have {{#if: {{R2A|{{{Roman_numeral_parameter|}}}|no_error=1}} | | Error message if {{{Roman_numeral_parameter|}}} is not a Roman numeral. }} in a visible position. — Eru·tuon 19:35, 1 July 2020 (UTC)[reply]
That's helpful. I'll try using the |no_error=1 parameter in {{RQ:Dickens Great Expectations}}. See if it's still generating a module error. — SGconlaw (talk) 20:24, 1 July 2020 (UTC)[reply]
@Sgconlaw: Tested by putting {{RQ:Dickens Great Expectations}} with an invalid Roman numeral in WT:SAND, saving, and seeing if Category:Pages with module errors is in the hidden categories at the bottom: Special:Permalink/59662004. The category isn't there, whew. I've added an error message if the volume number is not a Roman numeral I, II, or III, because in that case the URL is bad. — Eru·tuon 20:54, 1 July 2020 (UTC)[reply]
@Erutuon: great. Do you want to run a bot and replace occurrences of {{R2A|{{{volume|}}}{{{1|}}}}} with {{R2A|{{{volume|}}}{{{1|}}}|no_error=1}}? I noticed that {{R2A}} is also used in different contexts in other quotation templates, so those will have to be fixed manually. — SGconlaw (talk) 21:25, 1 July 2020 (UTC)[reply]
After the edit, it looks like the entry cool mentioned by @Chuck Entz is no longer showing up on CAT:E. — SGconlaw (talk) 20:31, 1 July 2020 (UTC)[reply]
In the case of Template:RQ:Dickens Great Expectations, the template is trying to create a URL and it's expecting a roman numeral as the first parameter. If you pass it a number instead it can't convert that number to another number. Actually throwing a module error with a relevant message instead of silently failing would be great. DTLHS (talk) 17:48, 1 July 2020 (UTC)[reply]
Actually, I thought of a way to eliminate that particular error: see this diff. @Chuck Entz: is the template still generating an error? — SGconlaw (talk) 17:51, 1 July 2020 (UTC)[reply]
That doesn't solve the problem. You can try anything like {{RQ:Dickens Great Expectations|57}}. The template should either raise an obvious error if you give it a number, or it should know how to handle both numbers and roman numerals. DTLHS (talk) 17:55, 1 July 2020 (UTC)[reply]
I see. Can {{R2A}} be tweaked in some way to handle this? The reason why no error message is visible in the quotation template is because |pageurl= is only displayed if |page= or |pages= is also specified. Also, I have a question: does it matter that a template generates a module error? — SGconlaw (talk) 18:07, 1 July 2020 (UTC)[reply]
To your last question: yes, it matters. CAT:E should be kept as clear as possible of unimportant errors so that new and/or important ones are as obvious as possible. Sometimes module errors in CAT:E are the only way we find problems that could quickly spin out of control if not dealt with immediately.
You also see lots of bad edits by vandals and people who have no idea what they're doing, which get missed by patrollers. There may be nothing obvious in Special:RecentChanges and they're not in languages patrollers know well.
WF's edits show up in CAT:E a lot because he doesn't bother to learn to use templates properly. In the case I linked to, he left out the first parameter, which caused the chapter number to be read as the volume number. He also used the chapter number from the 1-volume version at Wikisource with a template designed for the 3-volume version at the Internet Archive- which has separate number for chapters in each volume. Someone would have to know to subtract the chapter totals of the first two volumes from 57 to get the number in that edition, which is 18. I suppose you could add logic to convert numbers over 3 to volume and chapter numbers, but it would be better if WF would RTFM. I'll clean up a few here and there, but after fixing the same error a certain number of times, I start reverting- a useless quotation template is worse than the request it replaces. Chuck Entz (talk) 03:21, 2 July 2020 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2020/June&oldid=65118131"