Wiktionary:Grease pit/2022/October

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

Proposal for a "Topic Category Bot"[edit]

I'm fairly new here, but i've seen a rather shocking neglect of the topic Categories that probably could be automated. I'm not anywhere close to technically proficient enough to give the attempt of coding a bot that'd pass the standards I'm seeing, but i've got a fair idea how one could go about doing such automation that would pass it:

1. Check if a page already has a lemmas category

2. If the previous check succeeded in finding such, look for a keyword(in this case, "fire", though "flame", "blaze", "burn", and likely a few dozen other keywords would be checked, though this would likely need consensus on what won't cause too many false positives for a given term for the next step)

3. if the last step found something, check the section it was found it(was it English, Tamagario, or Sindarin?)

4. add language code associated with section to the front of the desired category(for example skr:Fire in the case of a fire keyword was found in a section for Saraiki)

with fire related terms alone i imagine this would add over 20 thousand entries to various fire categories, with similar results for Time and a host of other topics Akaibu1 (talk) 21:42, 1 October 2022 (UTC)[reply]

A bot can't do this. Words like "fire" have too many meanings, and an entry containing "fire" doesn't necessarily belong in the fire category at all. Equinox ◑ 22:13, 1 October 2022 (UTC)[reply]
On top of that, topical categories are a navigational tool- if you have lots of minor variations clogging them up, the really interesting stuff gets buried. The display is limited to 200 per page, so 20 thousand entries means clicking through 100+ category pages to see them all. Chuck Entz (talk) 22:53, 1 October 2022 (UTC)[reply]
That would be mostly mitigated by the fact that my "20 thousand" was based on a search basic search, which includes all of the thousands of languages supported here , so it'd still be fairly small for each language and topic. plus "variations"(assuming you mean non-lemmas) aren't actually an issue because it's already policy, iirc, to not put topic category on non-lemmas. Akaibu1 (talk) 23:56, 1 October 2022 (UTC)[reply]
Actually, I didn't mean non-lemmas. Alternative forms of lemmas are generally lemmas. Then there are complications like multiple etymologies: what do you do when there's a lemma that's semantically wrong for the category, while the non-lemma is a fit (good luck programming a bot to sort out wind and wound, for instance). Chuck Entz (talk) 00:53, 2 October 2022 (UTC)[reply]
I think this is most promising for simple entries where the definition line is just # fire. A lot of people who add foreign-language terms are too lazy to deal with categorization (myself included). But anything along these lines must have careful review to catch errors (e.g. confusing the verb "to fire" and the noun "a fire"). 98.170.164.88 02:22, 2 October 2022 (UTC)[reply]
Adding "fire" to a fire category doesn't seem terribly useful and would only handle a tiny fraction of entries. I think this whole area is not bottable. Equinox ◑ 08:17, 2 October 2022 (UTC)[reply]
Right. I also don't know why Ogun was added to fire category. Careful and thoughtful human editing is required here. Blind bot editing based on the presence of a keyword is undesirable, and should not be done manually either. --Dan Polansky (talk) 08:46, 2 October 2022 (UTC)[reply]
I was basing my additions on https://en.wikipedia.org/wiki/List_of_fire_gods, though looking through the actual articles, it seems some of these were merely added on this list on the assumption that blacksmith and lightning deities also have association with fire, though there is the glaring case of Irish underworld god Aed, who merely their name means "fire". So yes i'll agree that it's not perfect, but the issue still stands that there is a definite underutilization of categories that in some matter could be automated, or at least streamlined, even if it's just a bot rounding up a list of articles that it "thinks" needs a given topic category but it's a human that's going through said list Akaibu1 (talk) 20:24, 2 October 2022 (UTC)[reply]

Some questions about general Wiktionary strategy[edit]

I like the idea of Wikimedia sites being a central repository for a wide range of things instead of them being scattered unpredictably across various sites, so one thing I often have a need for is a downloadable dictionary.

There is a website devoted to this (https://freedict.org/documentation/), but I would prefer to be able to download a dictionary from Wiktionary.

First of all, Wikipedia I believe has a set of criteria with which they single out pages as "good articles" (https://en.wikipedia.org/wiki/Wikipedia:Good_articles) and also guidelines for the "perfect articles": https://en.wikipedia.org/wiki/Wikipedia:The_perfect_article.

Does Wiktionary have a similar way of guiding contributors towards an end goal, of understanding what a "complete" entry might look like?

Second of all, is there an easy way to access the inherently structured data that is a Wiktionary entry? I know there is the Wikimedia API. Maybe you can retrieve the wikitext of an entry with the parse action, and parse the fields yourself in some way. I would hope it could be more streamlined than that, though.

First of all, is there any way to iterate over all entries in some subcategory, like all English words?

Second of all, we can imagine parsing the wikitext of an entry could be programmed to just be some parameters in the API.

Any general community plans, mentions, or interest in making the data structured enough to be conveniently downloadable? I think it would really enhance the project, though could be kind of a hard, longterm project.

Thanks very much 2A02:2454:3AB:5B00:4D2C:1E3C:42EE:921D 12:13, 2 October 2022 (UTC)[reply]

Depending on how technically proficient you are this may or may not be useful to you, but you can download Wiktionary data from a Wikimedia database dump. The file with a name containing pages-meta-current will contain the current content of all pages in all namespaces. This does leave templates untranslated, however. I have written some Python scripts to parse this data as well as the category data (in the categorylinks file), but I have not yet organized and documented these scripts as well as I would like. - excarnateSojourner (talk | contrib) 21:30, 2 October 2022 (UTC)[reply]
As to the "good" vs "perfect" entries, that's an interesting concept, however I'm sure there's a lot to be debated on such a thing as different parts of speech, languages, and other factors will shape what is "perfect" for a given entry. Vininn126 (talk) 21:46, 2 October 2022 (UTC)[reply]
We don't even have a style guide to indicate what makes a good definition. DCDuring (talk) 22:40, 2 October 2022 (UTC)[reply]

quote-book Chapters Problem[edit]

The chapters of a book I used for a cite are named after years in the Gregorian calendar, such that '1976' is one of the chapter names. This is ultimately displayed on-entry as "chapter 1976" which misinterprets the intended meaning behind '1976' and makes it the 1,976th chapter in the book. I removed that chapter parameter here: diff. If there's any solution, feel free to take it into your own hands or to ping me about it. --Geographyinitiative (talk) 14:19, 3 October 2022 (UTC)[reply]

@Geographyinitiative: Resolved in a hacky way. The module checks whether the only characters in the chapter title are digits, so I wrapped the chapter title in a span tag as <span>1976</span>, and now it treats it as a regular chapter title and not a chapter number. Is there a better solution? I don't know, but this seems to work for now. 98.170.164.88 17:24, 6 October 2022 (UTC)[reply]
 Done to my satisfaction at least. Thanks! --Geographyinitiative (talk) 17:35, 6 October 2022 (UTC)[reply]

Coolest Tool Award 2022: Call for nominations[edit]

The fourth edition of the Coolest Tool Award welcomes your nominations! What is your favorite Wikimedia related software tool? Please submit your favorite tools by October 12, 2022! The awarded projects will be announced and showcased in a virtual ceremony in December.


MediaWiki message delivery 18:30, 3 October 2022 (UTC)[reply]

Using the thesaurus in other languages[edit]

How to make the {{ws|}} redirect to a specific language section? - Munmula (talk) 21:44, 3 October 2022 (UTC)[reply]

@Munmula: There is no way. You just don’t use this template but probably {{l}}. I think there is no specific point in it anyway—it is a leftover from a time with much more different use of templates and treatment of languages; editors have ignored the Thesaurus namespace for greater things regularly. Fay Freak (talk) 00:00, 6 October 2022 (UTC)[reply]
As said above, that's not possible at the moment. Let me note that {{ws}} has features that {{l}} does not have: it automatically links to other thesaurus entries and it can take a definition as a parameter to show in the tooltip, the mouseover text. {{ws}} is widely deployed in thesaurus, not {{l}}. Chinese thesaurus entries often use their custom {{zh-syn-list}}, which is not very friendly for a unified format, but works for the reader.
The thesaurus has some good content, and some people keep on expanding it, seeing the value of avoiding duplication of synonym lists in the mainspace, and some may like the hyponymic and meronymic network as well: I do. --Dan Polansky (talk) 12:37, 6 October 2022 (UTC)[reply]

Adding a citation: "This action has been automatically identified as harmful" for "various specific spammer habits".[edit]

I am attempting to add the below quote to the empty 'Citations' page of the article "Coug it". 

{{quote-journal|en|title='The big ugly secret' of WSU's stadium |newspaper=Seattle Post-Intelligencer |location=Seattle, Washington |date=May 10, 2005 |url=https://www.seattlepi.com/sports/article/Go-2-Guy-The-big-ugly-secret-of-WSU-s-stadium-1172927.php |text=Did Washington State '''Coug it''' when it named Martin Stadium 35 years ago? Or is everyone all right with the fact that Clarence D. Martin was a Husky?}}

This results in the errors/warnings:

Warning: This action has been automatically identified as harmful.
Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it.
A brief description of the abuse rule which your action matched is: various specific spammer habits. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit.
This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: various specific spammer habits

It does not let me save the edit.

Could someone please tell me why this is flagging me? Thanks PK-WIKI (talk) 17:01, 6 October 2022 (UTC)[reply]

I run into this one all the time. Sometimes it works to remove the URL, save the page, and then add the URL afterwards. I've done that for you and now the Post-Intelligencer quotation is present on Citations:Coug it. Thank you for your contribution! 98.170.164.88 17:17, 6 October 2022 (UTC)[reply]
New and unregistered users have much tighter restrictions when posting links, as a registered user that will go away after a few contributions. Never heard of "coug it" before, but dictionary.com has a slang entry! - TheDaveRoss 19:09, 6 October 2022 (UTC)[reply]

Definitions starting with "when"[edit]

It could be superfun to make a list of all English entries starting with "when", like deadstick landing. It is bad style for definition writing (but may be OK in ). GreyishWorm (talk) 18:09, 8 October 2022 (UTC)[reply]

When is just the most common of the wh- words that indicate a possible weak definition. DCDuring (talk) 18:55, 8 October 2022 (UTC)[reply]
Alright then, let's get a list with all the wh- words GreyishWorm (talk) 22:39, 9 October 2022 (UTC)[reply]
User:JeffDoozan/lists/wh JeffDoozan (talk) 00:17, 10 October 2022 (UTC)[reply]
Heh I also did one, which has nouns only (many adjective glosses start with a relative pronoun), and accounts for context labels: User:This, that and the other/whonderfool (not sorry about the name). Not all of these need fixing; in particular, the "What"s and "Whatever"s seem mostly fine. @GreyishWorm This, that and the other (talk) 03:36, 10 October 2022 (UTC)[reply]

template:en-conj[edit]

I love this template ! is it new ? I don't recall ever seeing it before. It's been recently used at English fortake. If I may, may I suggest one clarity be added? For the archaic/obsolete senses for second person, there should be something indicating that the forms shown are pronoun specific (e.g. fortake goes with 'ye/you', and fortakest with 'thou'; fortook with 'ye/you'; fortook(e)st with 'thou'. Leasnam (talk) 23:22, 8 October 2022 (UTC)[reply]

This only affects the second person. The 3rd person singular forms equally apply to 'he/she/it' Leasnam (talk) 23:34, 8 October 2022 (UTC)[reply]
I think @Theknightwho was looking at this template... This, that and the other (talk) 12:00, 10 October 2022 (UTC)[reply]
@Theknightwho, Sgconlaw, This, that and the other I don't understand the purpose of this template except maybe to display archaic forms. Why are we creating a table that simply duplicates what's already in the headword? English verbs are not complex enough to require such a table. Benwing2 (talk) 05:21, 16 October 2022 (UTC)[reply]
@Benwing2: I have only ever used it to display archaic forms (where these exist) that aren’t displayed in the headword, which is why I was surprised that the template had been altered to turn off archaic forms as the default. I suppose there are a small number of entries (such as those using be or go perhaps) where a separate conjugation table would be desirable, but I’d say that in most cases it would be unnecessary unless there are archaic forms. I would support making the display of archaic forms the default, and requiring |old=no or |old=off to suppress them. — Sgconlaw (talk) 05:29, 16 October 2022 (UTC)[reply]
I concur that this should only be used to display archaic or irregular forms in situations where this is required. It shouldn't be on, for example, nanocrystallize. This, that and the other (talk) 10:45, 16 October 2022 (UTC)[reply]
@Sgconlaw @This, that and the other @Benwing2 In all honesty, my reasoning was that it allows us to expand its use in future if necessary (which is mostly down to the fact that I really don't like the way English verbs are mentioned in headwords, as it's messy - particularly when dialectal variation is involved). Theknightwho (talk) 11:51, 16 October 2022 (UTC)[reply]
@Theknightwho: that sounds like it needs a broader discussion at the Beer Parlour. It seems to me that in general the most common inflections should remain at the headword, and anything else such as archaic or dialectal terms should be reflected only in a conjugation table. — Sgconlaw (talk) 13:18, 16 October 2022 (UTC)[reply]
Agreed on all counts. Benwing2 (talk) 19:21, 16 October 2022 (UTC)[reply]

tiegħek and its link on -k[edit]

In the etymology section of tiegħek, it says it's from ta' + -k. The -k is entered via a module that has this id2 parameter. The result of id2=pronoun is that the link leads to https://en.wiktionary.org/wiki/-k#Maltese:_pronoun where the #Maltese:_pronoun suffix means the link just ignores the prefix, like when you click on a link which should lead you to a language the entry doesn't have. I edited the entry to remove that parameter, thus making the link lead to just #Maltese, which works, and someone just reverted the edit. Why? What do we do? Do we leave a link that doesn't work as it should? MGorrone (talk) 13:09, 9 October 2022 (UTC)[reply]

@MGorrone this looks to have been fixed by Fenakhay in this edit. This, that and the other (talk) 12:00, 10 October 2022 (UTC)[reply]

Bad Webster 1913 links[edit]

Would someone be able to fix all the following links or generate a list containing...

What are we to do when the websters1913 site has an error in their headword that I can only assume to be a scanno? I don't know where to find scans of the 1913 dictionary, so I'm comparing to the 1898 edition. Examples:

98.170.164.88 00:36, 16 October 2022 (UTC)[reply]

I believe that all the Webster 1913 material there and here traces back to something on Project Gutenberg. It's not the original reference, but we might be able to catch some errors that appeared after that version (I'm sure there are also plenty that appeared in the long process of its creation, too). Chuck Entz (talk) 02:24, 16 October 2022 (UTC)[reply]
So on an entry like gibbosity, should I change the link to point to "gibbostity", even though this is an error? That's what I've been reluctantly doing. At least then the link doesn't give a 404 error. Maybe we should have an option to make the link work, but note that it is a scanno somehow. Can we report the errors to Project Gutenberg? 98.170.164.88 03:31, 16 October 2022 (UTC)[reply]
In cases where the headword was misscanned, I think we should add a parameter to {{Webster 1913}}/{{R:Webster 1913}} that allows us to directly link to a scanned page of this dictionary. Such a parameter would only be used in cases where the OCR'd headword is wrong. This will avoid any confusion. This, that and the other (talk) 03:49, 16 October 2022 (UTC)[reply]
I don't know if OCR is involved. As I understand it, much of the content at Project Gutenberg was typed by volunteers. The latest date on any of these is 26 years ago, so there's no point in reporting errors. I just mentioned this in hopes it would help us understand a little better what we're dealing with. I suspect that the presence of the Project Gutenberg version is the reason that there are no scanned versions of this edition online. Chuck Entz (talk) 05:20, 16 October 2022 (UTC)[reply]
I suspect you're right; these errors do have the flavour of typos rather than scannos. And I didn't realise there was no scan of the 1913 edition online; perhaps we should be replacing {{R:Webster 1913}} with {{R:Webster 1898}} in these situations. This, that and the other (talk) 23:30, 16 October 2022 (UTC)[reply]
I'm gonna keep listing these so that eventually they get dealt with properly. 98.170.164.88 07:09, 17 October 2022 (UTC)[reply]

Sorting of Swedish lemmas in categories[edit]

The standard way of sorting Swedish words alphabetically is with the three letters "å", "ä" and "ö" treated as three distinct letters coming, in that order, after "z". Presently, terms in (for example) Category:Swedish lemmas seem to be sorted in some other manner. Can this be fixed? Gabbe (talk) 06:44, 10 October 2022 (UTC)[reply]

I believe it is only possible to enforce a collation (sort order) wiki-wide. That is, the same collation must apply to all categories. I don't know exactly what collation this wiki uses, but presumably it is based on the ordering of characters in Unicode, where å comes after ä. If my belief is true, there's not a lot we can do about this. This, that and the other (talk) 11:57, 10 October 2022 (UTC)[reply]
@Gabbe: Yes, it can. It would be done by setting the field m["sv"].sort_key in Module:languages/data2. I'm not sure of the precise mechanism. It seems to translate the raw word using the 'from' and 'to' subfields, and then doing a sort on the resulting string. You can see a working example with code at m["cy"] and results at cat:Welsh lemmas. The very rare (and somewhat dubious) lemmas starting 'dd' are sorted between lemmas starting with 'd' and lemmas starting with 'e'. Similarly, the words beginning with the letter 'ff' follow the words beginning with just one 'f'.
For Welsh, note that the letter 'ng', which comes between 'g' and 'h', is only set up for the sequence 'ngh', because the sequence 'ng' in a word often consists of two letters rather than one. You really wouldn't want Llangollen to come before Llanberis. RichardW57m (talk) 13:58, 11 October 2022 (UTC)[reply]
I think you will also have to adjust {{sv-categoryTOC}} for the new weights, as has been done in {{cy-categoryTOC}}.
It seems that the capitals in the list change when the initial character of the (NFC) sorted title changes; we don't get any announcement of when we reach a new letter in Welsh, unless there is a change of initial character. I don't think this problem affects Swedish. --RichardW57m (talk) 15:28, 11 October 2022 (UTC)[reply]
The collation order is by using Unicode codepoints by default, and in the Unicode codepoint order, Ä (U+00C4) < Å (U+00C5) < Ö (U+00D6). Unfortunately, there is no way to change this (by category) right now, and MediaWiki developers probably don't even know what Wiktionary is, much less care about it. A workaround is use the sort_key as described above, but this will cause the initial letter (the one you see before the first entry beginning with that letter on the list) shown in the category listing to be incorrect. — SURJECTION / T / C / L / 12:34, 21 October 2022 (UTC)[reply]
@Surjection: So we want something like https://www.mediawiki.org/wiki/Extension:CategorySortHeaders. I haven't studied it, so I don't know far it falls short of our needs and desires, if at all. --RichardW57m (talk) 11:13, 25 October 2022 (UTC)[reply]
I had been puzzling over how our system was integrated. I now see that it's done at the point of adding the page to the category, e.g. in the module code invoked by {{sv-noun}}. --RichardW57m (talk) 11:13, 25 October 2022 (UTC)[reply]

Deletion[edit]

Could someone delete the page aldabra? I just created it by mistake. The correct spelling would be aldraba. Munmula (talk) 21:22, 11 October 2022 (UTC)[reply]

@Munmula please tag it with {{d|created in error}} and somebody will come along and delete it. This, that and the other (talk) 10:22, 12 October 2022 (UTC)[reply]

Lya Wyler --> Lia Wyler[edit]

The name of this translator is incorrect. Can someone change all instances of Lya Wyler to Lia Wyler, please? GreyishWorm (talk) 22:31, 12 October 2022 (UTC)[reply]

 Done JeffDoozan (talk) 19:32, 18 October 2022 (UTC)[reply]

Dark Mode gadget[edit]

I was wondering if en.Wikipedia's dark mode gadget (w:en:Wikipedia:Dark mode (gadget)) can be ported over to en.Wiktionary?

Try it out as http://en.wikipedia.org/wiki/Main_Page?withgadget=dark-mode

-- 65.92.247.226 05:27, 14 October 2022 (UTC)[reply]

Character recognition in templates[edit]

Hello, everyone. I'm not exactly sure this is the right place to ask about this, but I'll try. Is there a way to create a template that bases its output on the page name's characters? For example: an ending determining one declension pattern, and another ending resulting in a different pattern. I know modules can do this, but I don't know the first thing about creating one. Any info would be greatly appreciated. GianWiki (talk) 21:28, 15 October 2022 (UTC)[reply]

Yes, it is possible, but it can be quite complex. What did you have in mind? Theknightwho (talk) 11:53, 16 October 2022 (UTC)[reply]
You can access the page name using {{PAGENAME}} in template code, and match on parts of the page name using invocations of Module:string, as shown in the comments to that module. But as User:Theknightwho notes, it's somewhat complex and painful to do it using pure template code; definitely easier in module code. Benwing2 (talk) 19:33, 16 October 2022 (UTC)[reply]
For example, a template for a declension table of Old Occitan adjectives. It would basically be able to produce one of three inflectional patterns, depending on the ending ("regular" endings, -e endings, and "sibilant" (-s and -z) endings). I figured it might be better to have a single template than three different ones. GianWiki (talk) 10:06, 17 October 2022 (UTC)[reply]

{{rfv-etym}} parameter topic[edit]

This seems to be broken. I used it in the 4th etymology section of Mon မ as {{rfv-etym|mnw|topic=What Burmese word is the source?}}, and the generated subsection header in WT:ES and the generated subsection header is "[[မ#rfv-etymology-notice-mnw-What" (quotes not included). I don't know how I should fix it. I have started populating the section. --RichardW57 (talk) 15:01, 16 October 2022 (UTC)[reply]

I've now added a closing ']]' to the generated header so that the section gets an edit button! --RichardW57 (talk) 19:23, 16 October 2022 (UTC)[reply]
@RichardW57 The issue is that it wasn't URL-encoding the topic, and the spaces in the topic were causing issues. I've tried to fix this, and also changed the ID format slightly so it doesn't output a trailing hyphen if there's no topic; hopefully this won't break anything. Note that the support for topics in rf* is old but almost completely unused currently; I thought at one point of ripping it out entirely. Benwing2 (talk) 19:29, 16 October 2022 (UTC)[reply]
I only tried using the topic because the text inserted by the template is poor, though not bad as a default. It assumes that the problem is a lack of a reference for the etymology is the problem, but doesn't help with other problems. For example, an etymology deriving a word from Proto-World could be referenced, but would not be very useful. In this case, we don't know what the source word is supposed to be. --RichardW57 (talk) 19:41, 16 October 2022 (UTC)[reply]
I think in this case, {{rfe|mnw|What Burmese word is the source?}} is meant to be used. {{rfv-etym}} does seem to have a very narrow zscope. This, that and the other (talk) 07:14, 17 October 2022 (UTC)[reply]

Dealing with Westrobothnian categories[edit]

So there's been discussion laying out how "Westrobothnian" does not exist as either a recognized language or a distinct sub-group of Swedish dialects:

The term has actually been questioned almost as soon as it was introduced, but no proof of widespread usage or recognition have been forthcoming. The reason it has stayed here on Wiktionary is because basically one or two contributors aggressively accusing anyone in opposition of bias against regional languages.

We have a whole bunch of categories related to Westrobothnian that need to be cleaned up. The discussion in Category talk:Westrobothnian language is to transfer everything under Category:Norrland dialects. Can someone help out with tips on how to dismantle and transfer the network of categories under Category:Westrobothnian language?

Peter Isotalo 15:07, 16 October 2022 (UTC)[reply]

"Recent additions to the category" - no longer working[edit]

I really like this function because it helps me to locate new entries but since yesterday it's no longer working. The list contains old entries. Would someone know what happened and how to fix it? Thanks. Panda10 (talk) 17:34, 16 October 2022 (UTC)[reply]

It seems to be working for me, eg, at Category:mul:Taxonomic names (clade). DCDuring (talk) 17:48, 16 October 2022 (UTC)[reply]
That's interesting. I've just checked the English, German and French lemma categories, they all work. But Category:Hungarian lemmas and other Hungarian PoS categories do not. Is that possible? Panda10 (talk) 19:36, 16 October 2022 (UTC)[reply]
I can't answer any truly technical question, but strange things can happen. Category:Hungarian lemmas works for me. I am using Firefox 105.0.2 (32-bit) on Windows 10 ver. 1903. What browser and version and OS are you using? Can you try another browser (eg, Edge, Chrome)? Our techno-mavens would probably want to know. DCDuring (talk) 23:24, 16 October 2022 (UTC)[reply]
FWIW I'm seeing the broken behavior for Hungarian lemmas. This is using Chrome 67 (super old) on an old version of Mac OS X. But I suspect this is not a browser issue, but something that got broken by a back-end MediaWiki change. The difference between English/German/French and Hungarian might be due to some sort of server caching, although that doesn't explain why some people see the broken behavior and some don't. Benwing2 (talk) 06:12, 17 October 2022 (UTC)[reply]
I'm using Firefox 105.0.3 (64-bit) on MacOS 12.6. and also tested Safari 16.0. Same behavior. The lemma list was not updated since yesterday when I last looked at it. Since I can't do anything about it, would you know another method to check for new Hungarian entries? Panda10 (talk) 17:13, 17 October 2022 (UTC)[reply]
I am also seeing this dysfunctional behaviour on Category:Hungarian lemmas, Category:Ukrainian lemmas, Category:Estonian lemmas, Category:Danish lemmas, etc. (viewed in Firefox, Chrome and Edge). Genuine recent additions (still visible via Special:RecentChangesLinked) are being crowded out of the "Recent additions to the category" box by older entries. Is some kind of mass re-indexing of entries going on which is causing them to be misidentified as recent creations (despite their edit history)? Voltaigne (talk) 00:00, 18 October 2022 (UTC)[reply]
What happens if you null-edit or purge the page cache? Or edit and then preview it? 98.170.164.88 22:21, 17 October 2022 (UTC)[reply]
I think browser and null edit are both unlikely to be the problem. The recent additions are tracked in an unreliable way. They use the cl_timestamp field in the database (where this happens in the source code), which is sometimes updated randomly and therefore does not always indicate that a category was added. You can view category additions with Special:RecentChanges thus, but I'm not sure how to restrict it to one category, and it only goes back a month. — Eru·tuon 23:18, 17 October 2022 (UTC)[reply]
Using Special:RecentChangesLinked and restricting to only show page creations may be a good approximation: see here. This won't catch cases where a page already existed, but was only just added to the category, but that should be the less common case. 98.170.164.88 23:24, 17 October 2022 (UTC)[reply]
Just barely for cat:Pali non-lemma forms, where 4 out of the last 10 were for inflected forms that clashed with pre-existing pages. So far, the monitoring seems to be working for Pali categories. --RichardW57m (talk) 12:28, 18 October 2022 (UTC)[reply]

I noticed this and assumed that some module deep in the guts of headword processing changed causing pages to be removed and re-added to categories during regeneration. Vox Sciurorum (talk) 09:01, 18 October 2022 (UTC)[reply]

Today I edited Module:tr-verb form of and now Category:Turkish lemmas has 10 old pages that use the module in the "Recent additions to the category" box. This module is used for non-lemma forms. Each of the 10 "recent additions" has a lemma form that does not depend on the module and a non-lemma form that does. This is undesirable. I do not know if it is fixable. Vox Sciurorum (talk) 20:32, 30 November 2022 (UTC)[reply]
@Vox Sciurorum: My understanding (see also my comment above if you haven't) is that "recent additions" is a misleading name. It does not show the pages that have been most recently placed in the category for the first time. The category page cannot provide that information because the database in the MediaWiki software doesn't record it. A more accurate description is "pages that are currently in this category and have had their category links updated most recently". And I don't know when the category links are updated, but it might happen when a page is re-parsed (like when it is edited, or when someone visits it after it has not been visited for a long time). Perhaps the label of the list should be changed. — Eru·tuon 21:40, 30 November 2022 (UTC)[reply]
I've changed the label of the "recent additions" list to "Newest pages ordered by last category link update". This is a confusing label, but hopefully it is less misleading. — Eru·tuon 00:30, 2 December 2022 (UTC)[reply]

Thank you for all your helpful comments, clarifications and suggestions. The Special:RecentChangesLinked will be very useful. I wasn't familiar with it. Panda10 (talk) 18:16, 18 October 2022 (UTC)[reply]

{{der}} no longer displaying glosses[edit]

Something has happened to {{der}} (and possibly related templates); using the |t= parameter suddenly no longer works. For example, {{der|en|ine-pro|*puḱ-|t=to press together}} only produces "Proto-Indo-European *puḱ- (“to press together”)"; the gloss does not appear. (Pinging @Benwing2, Vininn126 who recently worked on Module:etymology.) — Sgconlaw (talk) 12:17, 20 October 2022 (UTC)[reply]

@Sgconlaw: this is no doubt connected to the work @Surjection has been doing to fight a recent epidemic of memory bloat. On a related note: can someone with a bot do null edits on everything in CAT:E? Although the vast majority of those are bogus, there are a few that aren't, and we need to see which ones they are. After clearing through the letters "a" and "b", it's already apparent that there's something affecting old forum posts that still needs to be fixed. Chuck Entz (talk) 14:52, 20 October 2022 (UTC)[reply]
Fixed — SURJECTION / T / C / L / 14:55, 20 October 2022 (UTC)[reply]
@Chuck Entz, Surjection: thanks! — Sgconlaw (talk) 14:59, 20 October 2022 (UTC)[reply]
@Chuck Entz I just purged CAT:E; it only has 5 entries now. Benwing2 (talk) 03:56, 21 October 2022 (UTC)[reply]

Replacing {{lang}} by {{l}}[edit]

I apologise if I've put this in the wrong place.

In a long-running (or resurrected), recently rejected request to delete {{lang}}, it was urged that {{lang|code|text}} be replaced by {{l|code||text}}, and I recently adopted its use to drill myself in using it. I have just discovered that the advice was WRONG. For non-Latin text in languages with adopted transliteration, it needs to be{{l|code||text|tr=-}}so as to stop empty brackets appearing after the text, e.g. for Thai. They will suddenly appear once the transliteration is adopted, e.g. for Mon. Yet another reason for keeping {{lang}}.

Or is this a bug in Module:links? --RichardW57m (talk) 15:26, 21 October 2022 (UTC)[reply]

@RichardW57m: Can you give an example of the empty brackets? It sounds like not a problem with Module:links, but with the transliteration function for Thai, which should be returning nil, not an empty string, when it fails to generate a transliteration. — Eru·tuon 21:35, 13 November 2022 (UTC)[reply]
ไม่ มี ปัญหา. Curiously, {{l|sa||प्रश्न}} generates प्रश्न (praśna), and Hindi is just as bad.
{{l|th|มี|ปัญหา}} generates ปัญหา (bpan-hǎa), showing which parameter is being worked on.
{{l|th|ไม่ มี ปัญหา}} generates ไม่ มี ปัญหา, showing what happens in the undoubted failure case. Combining the two, {{l|th|ไม่ มี ปัญหา|มี}} yields มี (mii). Now, isn't the correct transliteration of an empty string an empty string? Where is it specified that an empty string should be transliterated as nil? Indeed, where is the transliteration modules' interface carefully stowed away (Anglice: hidden)? --RichardW57m (talk) 09:56, 14 November 2022 (UTC)[reply]
Empty strings are converted to nil by Module:parameters/lite, which is used by Module:links/templates, which is used by {{l}} and {{m}} and {{l-self}}. The transliteration modules are listed in the language data modules and you can locate the correct data module by using the search box in Module:languages/documentation or by clicking the links there. The transliteration modules used by a language are also listed in the language's category page. (For instance, Category:Thai language lists Module:th-translit.)
{{l|th||ไม่ มี ปัญหา}} generating empty parentheses does look like a bug in Module:links. Not sure if it has always done that or if it's a recent change. — Eru·tuon 04:30, 15 November 2022 (UTC)[reply]
Correction, Thai in Module:links doesn't actually use Module:th-translit to generate a transliteration, but rather displays a "phonetic extraction" generated by getTranslit in Module:th. Module:links uses the alt argument (second argument to {{l}}) if it was provided to generate transliteration, but wasn't using it for the phonetic extraction, which somehow caused the empty parentheses. I've made phonetic extraction behave like transliteration, and that somehow fixed the empty parentheses. — Eru·tuon 04:48, 15 November 2022 (UTC)[reply]
I personally find {{lang|code|text}} more readable than {{l|code||text}}. {{lang}} is specifically for tagging text in a given language. It's a little strange to overload {{link}} for something other than linking. More generally, whenever I see template calls that have || (common with etymology templates, but also in other contexts), I get a little confused. Named parameters are much easier to parse than having to count the number of pipe characters and suss out what the nth unnamed parameter is for. It may save keystrokes but it's much less clear. Am I the only one who feels this way? 98.170.164.88 21:42, 13 November 2022 (UTC)[reply]
Is Wiktionary meant to be easy to use?
Seriously, no, you're not alone in your feelings. Indeed, I find the proposal to get rid of template {{lang}} to be wrong. What would make sense is to change its back end, so that an invocation of {{lang}} invokes {{link}} or its back end. There is no current proposal to get rid of {{temp[|lang}}. --RichardW57m (talk) 10:15, 14 November 2022 (UTC)[reply]

Wrong Wikipedia links in etymology templates[edit]

The template {{der|ro|qfa-sub-bal|-}} generates: "Paleo-Balkan", with a link to a Wikipedia article that does not exist. I can see how to edit Module:etymology languages/data to change the linked article, but I was unable to find an appropriate link target on Wikipedia, so I would like to suppress the link altogether. Can anyone help? This, that and the other (talk) 00:23, 22 October 2022 (UTC)[reply]

We should probably add an optional link override in the data files to allow us to bypass Wikipedia, and not just for etymology only languages. We could then drop the pretence that 'Sanskrit' as inherited denotes what the word means in English, and link to a section of our own 'about' page. There are also cases where our usage does not accord with Wikipedia's "XXX phonology" cited for the IPA key. For example, our entry for ຄວາຍ (khuāi) contradicts the tosh about Lao consonants in Wikipedia, for which we can't find a decent reference to remove the hocus pocus about labialised consonants. I've also seen the frightening prospect that the phonology article redirects servicing Wiktionary might be rejected by Wikipedia. --RichardW57 (talk) 04:25, 22 October 2022 (UTC)[reply]
Is w:Substrate in Romanian inappropriate? --RichardW57 (talk) 04:30, 22 October 2022 (UTC)[reply]
Well I'm not sure. To my ear "a pre-Roman substrate of the Balkans" need not be specific to Romanian, but perhaps that is all it is meant to be used for. This, that and the other (talk) 06:55, 23 October 2022 (UTC)[reply]
I think you're confusing the concepts of Wikipedia titles and names of linguistic systems. --RichardW57 (talk) 18:13, 23 October 2022 (UTC)[reply]

Deep links in vector-2022 not working correct when gadgets hide sections by default[edit]

For your interest: phab:T321062 -- Formatierer (talk) 05:30, 22 October 2022 (UTC)[reply]

It looks like an old bug - or perhaps a recurring one. I've had Firefox misscroll when a lot of the page is hidden. --RichardW57 (talk) 06:09, 22 October 2022 (UTC)[reply]

Looking for bot to recategorize terms[edit]

Three weeks ago I started a Beer Parlour discussion concerning cat:English words by number of syllables, and consensus has now been established to implement Option 1 as explained in that discussion. But it involves recategorizing many terms, so I'm looking for someone with a bot to do the following.

For all terms in all subcategories of cat:English words by number of syllables, if a term contains one or more spaces, then:

  • If the term has been manually added to the subcategory (meaning that the category is explicitly mentioned in the source of the entry rather than being automatically added by {{IPA}}), then remove it from the subcategory. For example absolute immunity and algorithmic randomness should be removed from cat:English 7-syllable words.
  • Otherwise, set the nocount parameter of {{IPA|en}} to true. This is to prevent terms that are spelled using spaces from being automatically categorized in these categories (even if they are pronounced as single words). For example, quid pro quo and sub rosa should both have nocount=1, which will remove them from cat:English 3-syllable words.

These two tasks can be done in any order or simultaneously, and it would be good to do one of them even if the other is never done for whatever reason. - excarnateSojourner (talk | contrib) 01:02, 25 October 2022 (UTC)[reply]

Bot/AWB Request[edit]

An IP vandalized one of the submodules used by {{auto cat}}. This was quickly reverted, but it triggered phantom module errors in thousands of categories. While the subcategory section of CAT:E isn't exactly essential to anything on the wiki, having thousands of entries in it is certainly annoying.

Would someone be so kind as to do null edits or the equivalent on all of these? I quite often clear smaller incidents like this myself by hand using tabbed browsing and keyboard shortcuts, but this would take me several hours. Chuck Entz (talk) 18:55, 29 October 2022 (UTC)[reply]

There's an added dimension to this: these categories have dropped out of the category structure, so they don't show up as subcategories in their parent categories. This is something @Benwing2 will need to deal with the next time he runs his category deletion process. Chuck Entz (talk) 19:35, 29 October 2022 (UTC)[reply]
@Chuck Entz Am running a purge now. What was the module in question? I need to look into the category code to see if there's a way of reducing the number of errors when things like this happen, e.g. so that some but not all pages throw errors. Benwing2 (talk) 20:33, 29 October 2022 (UTC)[reply]
@Benwing2: see diff. I would note that the top of the module is where random garbage is most likely to land, since that's where the cursor goes first, and it's also where we put the declarations that the entire module depends on. I realize that's part of the structure of Lua, but we need to think about mitigating it. Chuck Entz (talk) 20:45, 29 October 2022 (UTC)[reply]
As an aside, shouldn’t all modules be protected, at least so that only autoconfirmed editors can modify them (if not only template editors and administrators)? — Sgconlaw (talk) 20:56, 29 October 2022 (UTC)[reply]
The problem is that there may be legitimate reasons for an IP to add new categories. Chuck Entz (talk) 21:01, 29 October 2022 (UTC)[reply]
@Chuck Entz One possibility is to catch errors around the require() of each submodule and skip the submodule in that case. This will likely result in errors on all the categories defined by the submodule but not other categories. Benwing2 (talk) 21:28, 29 October 2022 (UTC)[reply]
I also agree with User:Sgconlaw, autoconfirmation is a pretty low bar (at least I think). Every change to Module:category tree/poscatboiler/data/lemmas, for example, was by someone with an account rather than an IP. Benwing2 (talk) 21:30, 29 October 2022 (UTC)[reply]
If changes to modules and templates are wont to cause a lot of issues, I think at least making them editable only by autoconfirmed editors is a no-brainer. If an IP really needs to add new categories, they can make a request. — Sgconlaw (talk) 21:43, 29 October 2022 (UTC)[reply]

current year[edit]

As an experiment, I tried to include a magic template at anterretrasado involving CURRENTYEAR. Obviously, it failed so here am I asking you to fix my error again. Thanks in advance :) GreyishWorm (talk) 23:27, 29 October 2022 (UTC)[reply]

Permalink to GreyishWorm's broken version which has since been reverted. - excarnateSojourner (talk | contrib) 02:17, 30 October 2022 (UTC)[reply]
You can use {{#expr:{{CURRENTYEAR}}-2}}. 98.170.164.88 02:40, 30 October 2022 (UTC)[reply]

New approach to columnization of translations; please test [[free]], [[dictionary]][edit]

As many of you know, This, that and the other (talk • contribs) made a proposal a while back to eliminate {{trans-mid}} in favor of using CSS to automatically split translation-lists into columns. [link] I eventually deployed that proposal, but it caused problems [link], so I then proposed a slower approach [link] that would allow opportunities for testing before deploying the change sitewide.

Well, I've now done the first few steps of that slower approach, and it's time for testing and refining!

Specifically, I've updated the translation-tables at [[free]] and [[dictionary]] to use the new approach, except for the "Translations to be checked" tables (just because those use a different template, that I didn't bother forking).

Anyone who's interested in this change, could you take a look and make sure those pages look OK to you?

(Pinging, I hope, everyone who participated in the previous conversations: @Apisite @Atitarev @Benwing2 @Chuck Entz @DCDuring @DTLHS @Dan Polansky @Dixtosa @Erutuon @Fay Freak @Fytcha @Imetsia @Inqilābī @JeffDoozan @Koavf @Mahagaja @Rua @Sgconlaw @So9q @Theknightwho @This, that and the other @Ultimateria @Vininn126. I apologize if I've missed anyone.)

—RuakhTALK 02:35, 30 October 2022 (UTC)[reply]

Both entries are displayed without any errors and with 5 columns for me. Thanks for this, it greatly increases navigability on widescreen monitors. — Fytcha〈 T | L | C 〉 02:45, 30 October 2022 (UTC)[reply]
@Ruakh Looks good to me. I see 3 columns and no issues. Benwing2 (talk) 02:49, 30 October 2022 (UTC)[reply]
Same here, but I only see 2 columns on my laptop. Changing the magnification displays 1 column (max) all the way to 9 columns (too small to read), with the transition (on the readable magnifications, at least) perfectly seamless. No irregularities in the order. Chuck Entz (talk) 03:05, 30 October 2022 (UTC)[reply]
I see also three columns; besides, my previous hard drive died along with one of my father's hard drives. --Apisite (talk) 03:12, 30 October 2022 (UTC)[reply]
@Ruakh: I forgot to ping you. --Apisite (talk) 03:13, 30 October 2022 (UTC)[reply]
Thumbs up emoji here, my ghostly friend. Nice job. —Justin (koavf)❤T☮C☺M☯ 02:52, 30 October 2022 (UTC)[reply]
Thanks! But please direct your praise to This, that and the other (talk • contribs), who did most of the work underlying this. —RuakhTALK 06:55, 3 November 2022 (UTC)[reply]
Ah, well thanks for being honest and thanks to my determiner friend for making the dictionary prettier and my ethereal friend for giving credit where credit is due. —Justin (koavf)❤T☮C☺M☯ 06:58, 3 November 2022 (UTC)[reply]
@Ruakh: Thanks, it's looking good in Chrome on Windows and I can zoom in and zoom out and it still works as expected. However, it's just one column if I use Safari on iPhone (desktop version of Wiktionary). Not a big deal for me personally, the display on iPhone. --Anatoli T. (обсудить/вклад) 03:45, 30 October 2022 (UTC)[reply]
@Ruakh: yes, it’s not working on Safari on my iPad, I’m afraid. The translations just appear in one column. (Will have a look on my laptop later.) — Sgconlaw (talk) 04:34, 30 October 2022 (UTC)[reply]
@Atitarev This is likely the expected behaviour on a mobile device. My Android phone, using the Chrome browser, shows a single column of translations even when browsing the desktop site. In general, the desktop site viewed on my phone has a poor look, with wildly varying font sizes, so I'm not sure if it is really something we should try to fix.
@Sgconlaw I assume you are viewing the site in desktop view (en.wiktionary.org, rather than en.m.wiktionary.org)? My comments above likely apply to iPads too. Additionally, if the screen is narrower than the predefined column width, you will only see a single column; you can replicate the effect on a regular computer and zoom in (ctrl+plus) until a single column is seen. This is actually the intended outcome - I assume you would have seen pages where the translation terms were too long to fit into one column, and that will no longer happen with this change.
I would add that, once this change is rolled out, it will be possible to customize the number of columns in translation tables using your personal CSS (Special:Mypage/common.css). This has not been possible until now. This, that and the other (talk) 08:01, 30 October 2022 (UTC)[reply]
@This, that and the other: yes, I was viewing the site using the desktop view on an iPad, which I prefer. — Sgconlaw (talk) 08:36, 30 October 2022 (UTC)[reply]
@Ruakh, This, that and the other: I was looking at free just now. I had a look at dictionary (Safari on iPad, desktop view) and noticed that it did have a two-column view. It seems to be because the latter uses {{trans-mid-multicolumn-css}} – is that intended? — Sgconlaw (talk) 13:17, 30 October 2022 (UTC)[reply]
That's strange. [[free]] and [[dictionary]] both use {{trans-mid-multicolumn-css}}; that's an essential part of this test. The only exception is the "Translations to be checked" tables, which still use the old templates, and therefore should be ignored for purposes of this test (except as a sort of "baseline" if you want to easily compare the new appearance to the old).
Can you confirm that you see two columns in the translations tables at [[dictionary]] but only one in the translations tables at [[free]]? If so, then: can you tell if maybe [[dictionary]] is "wider" than [[free]]? (I'm wondering if some other content on the page is making [[dictionary]] wider, and thereby creating room for a second column in the translations tables?)
—RuakhTALK 06:59, 3 November 2022 (UTC)[reply]
@Ruakh: that’s really strange. Yes, I can confirm that columns do not appear in free (whether the entry is viewed in portrait or landscape mode on the iPad), whereas they do appear in dictionary. As before, I’m viewing the entries in desktop mode. — Sgconlaw (talk) 04:42, 4 November 2022 (UTC)[reply]
The behaviour of the example pages is impeccable from what I can see. In particular it has also been careful to leave just the right size of gaps between the columns that caters to the largest swathe of people, at no times being arguably too small or too large or leaving too short or too long lines. Fay Freak (talk) 05:51, 30 October 2022 (UTC)[reply]
Works well on Chrome 107.0.5304.87 (Official Build) (x86_64 macOS) and Safari 16.1 (18614.2.9.1.12). — Fenakhay (حيطي · مساهماتي) 06:13, 30 October 2022 (UTC)[reply]
Works on Mozilla Firefox 106.0.2 running on Windows 11 Version 22H2. — Sgconlaw (talk) 08:39, 30 October 2022 (UTC)[reply]
@Ruakh, This, that and the other: unfortunately, I have to report that the columns are not showing up properly on Mozilla Firefox 106.0.2 running on macOS Monterey 12.6 (laptop). All the text is appearing in one large column. (Update: OK, it seems to be because I am viewing the screen at a magnification of 133%. If I reduce it to 100% which is a bit small for me, the two columns appear. Seems like there's a lot of wasted space on the right if columns don't appear at a 133% magnification, but I suppose I may have to individually customize the number of columns using CSS.) — Sgconlaw (talk) 15:24, 30 October 2022 (UTC)[reply]
Yes, it uses the column width CSS property, so if your screen is narrow in proportion to the text size, there will be just one column. This is better than using column count as in {{der}} because with that you will get way too narrow columns on a phone. But it's possible that the column width needs to be adjusted to reduce wasted space. — Eru·tuon 20:46, 30 October 2022 (UTC)[reply]
It seems to work as intended! Vininn126 (talk) 10:29, 30 October 2022 (UTC)[reply]
I've been (rarely) removing {{trans-mid}} lately (and more frequently {{rel-mid}} and {{der-mid}} [Is there shared code with {{trans-mid}}?]) whenever there was something odd about the display and have not seen any problems after doing so. DCDuring (talk) 16:41, 30 October 2022 (UTC)[reply]
Tested with Firefox and Chromium on Linux, works as expected and looks great! JeffDoozan (talk) 21:04, 30 October 2022 (UTC)[reply]
I'm only getting one column on Vector 2022, but it works fine on old Vector. Not quite sure why that is. Theknightwho (talk) 22:35, 3 November 2022 (UTC)[reply]
I think that was brought up before and it was because the width of new Vector was under 70em, so two columns didn't fit. — Eru·tuon 01:58, 4 November 2022 (UTC)[reply]
Width of Vector 2022 is set at preferences/appearance: "Enable limited width mode". Vriullop (talk) 16:10, 4 November 2022 (UTC)[reply]
Ah yes, that does make sense. Is it possible to reduce it down from 70em a bit? A lot of users will be using Vector 2022 with limited width on (as it's the default + recommended for that skin), and one long column isn't ideal on PC. Theknightwho (talk) 16:35, 4 November 2022 (UTC)[reply]
@Theknightwho in vector-2022 skin I see two columns of translations at free, but if I have tabbed languages turned on, I only see one column. This latter behaviour is to be expected, because with tabbed languages, the width of the page content can be arbitrarily narrow (see kotor for example). This, that and the other (talk) 01:55, 5 November 2022 (UTC)[reply]
@This, that and the other I think it must be a combination of limited width mode + tabbed languages causing the problem. I've turned off limited width, as it doesn't really serve any useful purpose on Wiktionary for me (unlike, say, WP). I now have two columns. Theknightwho (talk) 02:00, 5 November 2022 (UTC)[reply]
I see only one long column when I use either Vector 2022 or Vector legacy (2010). (I don't have Tabbed Languages enabled.) - -sche (discuss) 21:30, 23 November 2022 (UTC)[reply]
So what are the new rules for adding translation tables? {{trans-top-multicolumn-css}} for everything or only for large ones? Vininn126 (talk) 16:24, 4 November 2022 (UTC)[reply]
Keep using {{trans-top}} when creating new translation tables. When all of the bugs have been shaken out of {{trans-top-multicolumn-css}}, the plan is to replace {{trans-top}} with the contents of {{trans-top-multicolumn-css}} so that all translation tables will use the new CSS columns. JeffDoozan (talk) 18:58, 4 November 2022 (UTC)[reply]
Thanks Jeff! Vininn126 (talk) 19:15, 4 November 2022 (UTC)[reply]
@Ruakh in the above discussion I do not see anything that is holding us back from deploying these changes to the main templates (step 6 and 7 of your original plan). When you have time, I would say - go ahead. This, that and the other (talk) 03:43, 23 November 2022 (UTC)[reply]

There are some minor issues mentioned here, but on balance, this still seems better to me than the status quo. Are there any objections to proceeding? —RuakhTALK 12:13, 23 December 2022 (UTC)[reply]

@Ruakh: I don't think it's ready yet. I just had a look at free and dictionary again on both my laptop (macOS, Mozilla Firefox) and on an iPad (Safari, desktop mode, landscape orientation), and the columns are not appearing at all even though the wide screen width should presumably lead to at least two columns being displayed. Everything appears in one large column with the text being left-aligned. — Sgconlaw (talk) 14:39, 23 December 2022 (UTC)[reply]
It works perfectly for me with both Firefox and Chromium on Linux, and automatically adjusts the column count when zooming in and out. It also works as expected when I'm logged out and using the default skin.
@Sgconlaw:, earlier you mentioned seeing only a single column at 133% zoom and multiple columns when zoomed out. What do you see if you open a "Private" browsing window and visit free and dictionary without being logged in? Since most users will be using whatever the default skin/settings are, it's especially important that it look reasonable with the default settings. What do you see on the translations section on other pages like holiday? Two nice neat columns that sit side by side perfectly without having to scroll horizontally?
@-sche:, you also mentioned seeing only one column, can you mention which browser, operating system, and zoom setting you're using? If you zoom out, do you see more colums or does it only ever show one single column no matter what? Does it behave the same if you're logged out?
@This,_that_and_the_other:, this is really your baby and you probably understand the CSS better than anyone else. Do you think it's just a matter of fine tuning the default column width or is this a fundamental limitation of certain browser/OS combinations? JeffDoozan (talk) 16:39, 23 December 2022 (UTC)[reply]
@JeffDoozan, Ruakh: ah, I forgot about the zoom I was using. When I view free and dictionary on my laptop when not logged in (in a private window) and at 100%, two columns are seen. But the minute I increase the zoom by one step to 120% the columns disappear. On a page like holiday which is not using the test templates, I see two columns without the need to scroll horizontally. However, when I view the first two pages mentioned on my iPad in landscape orientation with no zoom, there’s still only one column shown. — Sgconlaw (talk) 16:49, 23 December 2022 (UTC)[reply]
@JeffDoozan, @Ruakh, @Sgconlaw: There are two separate issues here:
  • Seeing only one column in the browser. The column width of 30em was chosen carefully in order to fit all but the absolute longest translations across Wiktionary - if memory serves me well, this related to only 2 entries. If we make the columns narrower, some of the next longest translations in certain entries (noun phrases with long German translations, most likely) will "crash into" the second column. This is not necessarily a problem, as we can use the "wide" setting on the translation boxes that require it. However, for now, I suggest that we proceed with the change as-is and fine-tune the column width later in response to broader user feedback. Sgconlaw can edit his user CSS in the meantime. Let's not get stuck on fine details.
  • Seeing only one column when using desktop view on an iPad. As I understand it, the use of desktop view on mobile devices like iPads is subject to all kinds of visual weirdness in MediaWiki. I don't think we should attempt to resolve this issue. Mobile devices and tablets are intended to view Wiktionary in mobile view, and if you choose to use desktop view, you have to accept the appearance quirks that come with that.
This, that and the other (talk) 11:57, 24 December 2022 (UTC)[reply]
@This, that and the other: OK, then. Do provide information in the documentation about how to customize the display of columns. — Sgconlaw (talk) 12:06, 24 December 2022 (UTC)[reply]
@Sgconlaw Thanks, I will add this to the documentation at {{trans-top}} after the changes are implemented, unless you can think of a better place. This, that and the other (talk) 09:32, 25 December 2022 (UTC)[reply]
@This, that and the other: perhaps create the documentation at {{trans-top}} and transclude it to {{trans-bottom}}. — Sgconlaw (talk) 15:45, 25 December 2022 (UTC)[reply]
@Sgconlaw please see Special:PermanentLink/70597897 and see if the CSS instructions under "Personal customisation" help to improve the look of the translation boxes at free and dictionary for you. This, that and the other (talk) 11:09, 26 December 2022 (UTC)[reply]
@This, that and the other: thanks – I updated my common.css page as instructed (I removed "!important" as it was throwing an error). After adjusting the column width to 20em, it works fine for me. — Sgconlaw (talk) 18:18, 26 December 2022 (UTC)[reply]
Someone let me know when the change is made, so I know what to add when I add a new trans table to an English page! Vininn126 (talk) 18:38, 26 December 2022 (UTC)[reply]
@Ruakh let's do it, whenever you're ready. Also please revert Template:trans-top/documentation back to revision 70597897 at the same time. This, that and the other (talk) 00:00, 27 December 2022 (UTC)[reply]

I've now done the following:

We should wait a while to make sure we're happy with this, then start deprecating/eliminating usage of {{trans-mid}}.

—RuakhTALK 09:58, 28 December 2022 (UTC)[reply]

@Ruakh and all others: Thank you for your help to test and make this feature a reality. Thanks to our slower approach, we will not have to revert it this time! Let's reassess in a couple of weeks to see if we can get rid of {{trans-mid}} entirely, and listen to any community feedback around column widths. This, that and the other (talk) 11:40, 28 December 2022 (UTC)[reply]
So we currently add all three templates, but they, as of the moment, automatically add columns? Vininn126 (talk) 11:49, 28 December 2022 (UTC)[reply]
Thanks, @This, that and the other! What does “!important” do in the CSS customization? I had to remove it has it was generating an error for me. — Sgconlaw (talk) 16:45, 28 December 2022 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @This, that and the other: I have noticed a new issue. When the template {{trans-top-also}} is used, I see two columns, but all the text is in the left column and the right column is just empty. — Sgconlaw (talk) 12:38, 29 December 2022 (UTC)[reply]

Fixed. {{trans-top-also}} just needed to the code from {{trans-top}} that assigns the multicolumn-list class or a related class to the table cell containing the translations. — Eru·tuon 16:55, 29 December 2022 (UTC)[reply]
@Erutuon: thank you! — Sgconlaw (talk) 16:56, 29 December 2022 (UTC)[reply]

Fix code[edit]

I’m trying to fix up a display problem. — This unsigned comment was added by Kristtorn82 (talk • contribs) at 15:11, 2022 October 30.

Could you be more specific about what you are trying to accomplish? 98.170.164.88 04:42, 31 October 2022 (UTC)[reply]

Module oddity at Reconstruction:Proto-Yoruboid/ɔ́-wɔ́[edit]

This entry is in CAT:E due to {{inh|alv-yor-pro|alv-von|*ɔ́-bɔ́}}, which gives the message "Lua error in Module:etymology at line 184: Volta-Niger languages (alv-von) is not set as an ancestor of Proto-Yoruboid (alv-yor-pro) in Module:languages/datax. The ancestor of Proto-Yoruboid is Proto-Volta-Congo (nic-vco-pro)."

I've looked through the transclusion list, and I can't find anything that has alv-yor-pro or alv-yor in the same record with nic-vco-pro. The only thing I can figure is that the code in Module:languages#Language:getAncestors that skips a level when the language is the proto-language for its family is skipping one level too many. Of course, my knowledge of the finer points of Lua syntax is very limited, so that's just a guess. Can someone with working knowledge of Lua and of our modules take a look? Chuck Entz (talk) 05:15, 31 October 2022 (UTC)[reply]

One problem was that the template was {{inh|alv-yor-pro|alv-von}} instead of {{inh|alv-yor-pro|alv-von-pro}}. The second parameter has to be a (proto-)language, not a family; for example {{inh|en|ine}} would yield the similar error "Indo-European languages (ine) is not set as an ancestor of English (en)", because ine != ine-pro. Changing it to alv-von-pro still leaves an error message, though. I think you may need to add the following to Module:languages/datax, since the proto-language code is not currently defined:
m["alv-von-pro"] = {
	"Proto-Volta-Niger",
	nil,
	"alv-von",
	Latn,
	type = "reconstructed",
}
98.170.164.88 06:19, 31 October 2022 (UTC)[reply]
That fixed the module error, but doesn't address the second part of the error message having the wrong information about the parent. Not that it's urgent: this is the first time I've seen a case like this in the decade I've been patrolling CAT:E, so it may be awhile before it happens again. Chuck Entz (talk) 06:57, 31 October 2022 (UTC)[reply]
@Chuck Entz now that you've added alv-von-pro, if you were to write {{inh|alv-yor-pro|alv-von}} it would still give an error (because it's a family, not a language). However, the error message is now different: "Volta-Niger languages (alv-von) is not set as an ancestor of Proto-Yoruboid (alv-yor-pro) in Module:languages/datax. The ancestor of Proto-Yoruboid is Proto-Volta-Niger (alv-von-pro)." The reason it "skipped a step" is because the error messages only displays ancestor languages, not families, and there was no proto-language corresponding to the alv-von family. 98.170.164.88 07:17, 31 October 2022 (UTC)[reply]

Vulgate Bible quotes in Template:Q[edit]

Is there a way to get {{Q}} to show Bible references properly (i.e. Psalmi 1:1 and not Psalmi.1.1), specifically for Jerome's Vulgate? {{RQ:Vulgate}} does this but it's scheduled to be deleted and replaced by Q. —Al-Muqanna المقنع (talk) 14:52, 31 October 2022 (UTC)[reply]

Yes, and you've got until 2030 to work out how. (Schedule estimated from announcement date of 2015.) The documentation complies with the Wiktionary standard of 'inadequate'. --RichardW57m (talk) 14:06, 1 November 2022 (UTC)[reply]
@Al-Muqanna The way this is handled in Module:Quotations/grc/data is:
-- so that chapter and verse are separated by ":" instead of "."
data['New Testament'].rdFormat = {separator = ":"}
So I thought that adding this to Module:Quotations/la/data might work: 
data['Jerome'].rdFormat = {separator = ":"}
But it actually just changes the format from "Psalmi.1.1" to the slightly better "Psalmi:1:1" instead of the desired "Psalmi 1:1". There seems to be some difference between the way the Greek New Testament and the Latin Vulgate are organized in the module. Compare the number of arguments in {{Q|grc|New Testament|Acts|11|26}} vs. {{Q|la|Jerome|Vulgate|Exodus|20|12}}. I'm not sure if there's a way to fix the display of the latter the way the module is currently written (but I'm not all that familiar with it). Of course, it would be relatively simple to add another parameter to Module:Quotations to handle this specific case. 98.170.164.88 03:30, 2 November 2022 (UTC)[reply]
Implemented a kludge that should fix it. Not sure if there's a better solution. 98.170.164.88 23:42, 2 November 2022 (UTC)[reply]
Thanks a lot (belatedly), looks to be working fine for now. —Al-Muqanna المقنع (talk) 11:12, 15 November 2022 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2022/October&oldid=75407765"