Wiktionary:Grease pit/2021/August

(@Benwing2, @RichardW57) i created Template:R:si:Carter, which has been publisht twice, but in the same year and even there page numbers are similar. is it possible to, show year only once, and also the page number ? see මධු (madhu) , the page number is being displayed as if it is only for the first published edition. — Svārtava • 09:34, 2 August 2021 (UTC)

I agree the page number is in a bad position. I don't know how one should fix that. For this particular case, I don't think you need to mention republication, as the date is the same. You might want to use two different templates, one for each publisher. It is not a satisfying solution, but it would avoid confusing those who had both editions. --RichardW57 (talk) 19:14, 4 August 2021 (UTC)

If the content is different between the two editions (including, if a given entry is on different page numbers in different editions), then I would think you would need to either use two templates, or program the template to accept publisher as a parameter (like some reference templates accept edition) so people could specify which edition they're citing...? If you make a template that combines the two editions and requires someone to input what page number the entry they're citing is on in each edition, and someone only has one edition, they won't be able to say what page number the entry is on in the other edition. - -sche (discuss) 18:34, 10 August 2021 (UTC)

An ISSN is being called an "Invalid ISSN" but the link to worldcat.org works. Not sure how this would be best handled. --Geographyinitiative (talk) 13:00, 2 August 2021 (UTC)

@Geographyinitiative According to the Module history of Module:check isxn, it was taken from Wikipedia. Their code also says it's wrong. You should ping the editors there. —Suzukaze-c (talk) 03:49, 3 August 2021 (UTC)

Unfortunately, I am currently trying to get unblocked on English Wikipedia, and I think they would react rather badly if I tried ping someone over there. --Geographyinitiative (talk) 23:19, 4 August 2021 (UTC)

The validation code is correct, the final digit should be 3, see w:International_Standard_Serial_Number#Code_format. DTLHS (talk) 23:37, 4 August 2021 (UTC)

Okay, that gets rid of the "Invalid ISSN", but then worldcat.org says: "The page you tried was not found. You may have used an outdated link or may have typed the address (URL) incorrectly." --Geographyinitiative (talk) 23:40, 4 August 2021 (UTC)

I noticed some translingual pages use images to display headwords/links, for example this one. Is this still necessary with unicode? The images are old and look blurry on modern hardware, if they are necessary they should be replaced with hi-res/SVG versions. – Jberkel 13:12, 2 August 2021 (UTC)

The alternative is to use the dotted circle, e.g. |head=◌̟. —Mahāgaja · talk 14:50, 2 August 2021 (UTC)

Good point, but in this particular case it overlaps with the symbol, so it's not much better. Maybe that's font specific? – Jberkel 15:11, 2 August 2021 (UTC)

I installed Symbola as hinted in the CSS, looks better now. – Jberkel 15:21, 2 August 2021 (UTC)

(Notifying Dixtosa, Kc kennylau, Rua, Ruakh, ZxxZxxZ, Erutuon, Jberkel, JohnC5, Benwing2):

function export.deprecate(id, key)
    if mw.title.getCurrentTitle().id <= id then
        export.track(key)
    else
        error(key)
    end

This can deter editors from using something deprecated in new pages, while having old pages unaffected. -- Huhu9001 (talk) 03:16, 3 August 2021 (UTC)

@Huhu9001 What would this be used for? Also I would rather not add to Module:debug as it's used in a zillion other modules for tracking and adding a function might increase memory usage. Benwing2 (talk) 03:44, 3 August 2021 (UTC)

@Benwing2: For example, Special:WhatLinksHere/Template:tracking/ja-kanjitab/incorrect yutou or juubako. Some kind of wrong information is given in these 299 pages and cleanup is likely to take a lot of time. To make things worse, various editors are still adding the same wrong information to newly created pages like 四輪車, and there is no really effective way to tell them to stop it other than raising an Lua error. -- Huhu9001 (talk) 04:01, 3 August 2021 (UTC)

@Huhu9001 If you think it's important, it's fine to put it in a new module, e.g. create a Module:deprecated. Benwing2 (talk) 04:27, 3 August 2021 (UTC)

That's not going to help much. It's not going to stop people from adding "deprecated" stuff to older existing pages. — surjection ⟨??⟩ 10:46, 3 August 2021 (UTC)

@Surjection: From my experience that is not a problem. The adding of "deprecated" stuff almost never happens to old entries. If you are really worried about that, you can set up an interval that allows these deprecated things, and then gradually narrow it until it eventually becomes empty. 15:33, 3 August 2021 (UTC)

I think you'd be interested to know that Category:Calculator words actually exists. Queenofnortheast (talk) 14:08, 5 August 2021 (UTC)

bless. – Jberkel 14:34, 5 August 2021 (UTC)

It should be moved to CAT:English calculator words and be a subcat of CAT:English terms by orthographic property, shouldn't it? —Mahāgaja · talk 14:58, 5 August 2021 (UTC)

We might want an entry for calculator word too, if anyone cares enough Queenofnortheast (talk) 16:13, 5 August 2021 (UTC)

Cute but pointless IMO. Are we gonna create categories for every random type of wordplay that someone thinks up? While we're at it, let's create a new language code for Ubbi dubbi words! Benwing2 (talk) 01:11, 6 August 2021 (UTC)

In the discussion at Wiktionary:Beer_parlour/2021/August#Vote_to_prioritize_definitions_in_entry_layout it is mentioned that a very tall Pronunciation section would show up rather poorly on mobile display, e.g. the page at 水.

Is there something we can do to make it less tall while retaining most of the the informative content? Currently there are already multiple (but not nested) menus. Is making things even more "foldable" a good idea? Can the vertical spacing between lines be reduced without hurting readability inside the Pronunciation section?

cc. @Justinrleung, Suzukaze-c, Erutuon, Surjection --Frigoris (talk) 08:48, 6 August 2021 (UTC)

For everyone's convenience, here is a list of things that currently show up by default (nothing expanded) on mobile on that particular page:

• Mandarin: Standard Mandarin romanization in Pinyin, spelling in Zhuyin and an audio clip; Chengdu Mandarin romanization in Sichuanese Pinyin, Dungan spelling in Cyrillic
• Cantonese: Guangzhou romanization in Jyutping, audio clip, Taishan romanization under Wiktionary's own transcription scheme
• Gan: romanization under Wiktionary's own transcription scheme
• Hakka: Sixian romanization in Pha̍k-fa-sṳ, Meixian romanization in Guangdong Romanization
• Jin: romanization under Wiktionary's own transcription scheme
• Min Bei: romanization in KCR
• Min Dong: romanization in BUC
• Min Nan: Hokkien romanization in Pe̍h-ōe-jī, Teochew romanization in Peng'im
• Wu: romanization under Wiktionary's own transcription scheme
• Xiang: romanization under Wiktionary's own transcription scheme
• Box to expand dialectal data
• Middle Chinese pronunciation
• Old Chinese reconstructed pronunciation

— surjection ⟨??⟩ 09:06, 6 August 2021 (UTC)

The syntax for quotations as given in Wiktionary:Quotations does not seem to work on the Kashmiri Wiktionary as evident on the page be, where I have quoted and translated Shakespeare's "to be or not to be". Is there a setting that has to be enabled in the website? Or is there something else I'm missing? I realise this might be irrelevant to enwikt. But please help. Thanks.
Rishabhbhat (talk) 14:22, 6 August 2021 (UTC)

Hello,

I couldn't find a why to list all recent changes to Talk pages of a given language's lemmas, the same way we already can for the lemmas themselves ("Recent Changes" box in the upper right corner). Any idea? Thx.

Sitaron (talk) 14:42, 6 August 2021 (UTC)

I can't think of a way to do that. Some MediaWiki special pages have an "associated namespace" feature for including the corresponding talk or non-talk namespace, but RecentChangesLinked does not seem to be one of them (and it wouldn't probably include only talk pages either way). — surjection ⟨??⟩ 10:29, 9 August 2021 (UTC)

Initially I commented on this at talk:Raj, and then Template talk:short for, but now I realize it's a problem throughout. Today's word of the day is strimmer, defined as:

1. (Britain, horticulture) Synonym of string trimmer (“a powered, hand-held garden implement that uses a rotating monofilament line to cut grass, etc., without damaging other objects”)

Why isn't this:

1. (Britain, horticulture) Synonym of string trimmer; a powered, hand-held garden implement that uses a rotating monofilament line to cut grass, etc., without damaging other objects.

or similar? In other words, why are we putting glosses (or worse, entire definitions) in quotation marks? DAVilla 05:49, 7 August 2021 (UTC)

Because we use the same syntax for English terms as for non-English terms. In a non-English entry,

1. Synonym of Band (“volume”)

would make sense, especially since Band has multiple etymologies and senses, and we need to let the reader know which one the current entry is a synonym of. In the case of "string trimmer" it doesn't seem necessary, since that has only one meaning anyway. —Mahāgaja · talk 09:24, 7 August 2021 (UTC)

...but might develop further meanings in future! (Suggestions on a postcard.) Equinox ◑ 10:06, 7 August 2021 (UTC)

Cases like this call out for a template to hold the summary meaning. If we can't find a snappy summary, another solution is not to give a gloss. With a convoluted target entry (sensu lato), sense IDs can also work. --RichardW57 (talk) 11:34, 8 August 2021 (UTC)

But that's not how we do glosses. For instance, banda is defined in Spanish as:

1. (music) band (musical group)

This formatting is pretty universal. There aren't any quotes around "musical group" because it's not a translation, unlike for instance the translations at when pigs fly. DAVilla 08:27, 10 August 2021 (UTC)

So, I nominated myself as the person to solve the persistent problem of Lua memory errors. After about 16 years working on this website, my best suggestion was a crappily-named template and major failing of readability. It was so bad I actually lol'd at my inferior computing skills, and decided to fix it tomorrow. Technically, however, I did actually manage something - I reduced the number of pages in Category:Pages with module errors by 2 (yay!). Anyway, sorry for leaving you that big pile of shit, I was actually trying to help. Queenofnortheast (talk) 23:38, 7 August 2021 (UTC)

That will break all the incoming links and gawd knows what else. I have undone what you did at a and o. Equinox ◑ 23:50, 7 August 2021 (UTC)

We do have a/Old Irish as an experiment, and yes, we have to fix incoming links manually. —Mahāgaja · talk 08:55, 8 August 2021 (UTC)

In the longer term, we can always get Module:links to fix most of them at source. That still leaves problems with categories. --RichardW57 (talk) 11:37, 8 August 2021 (UTC)

Maybe the lower language headers could be made into links to their respective subpages, e.g. ==Old Irish== links to a/Old_Irish.

Just a suggestion. Rishabhbhat (talk) 12:16, 17 August 2021 (UTC)

@Rishabhbhat: That would be brilliant!!! @Mahagaja, RichardW57, could we replace the entry’s contents with the link ] or similar? I ken that’s the best solution. ·~ dictátor·mundꟾ 12:20, 2 September 2021 (UTC)

Is there one? for e.g. Anunnaki and all its alt forms. Equinox ◑ 09:55, 8 August 2021 (UTC)

@Equinox See {{en-plural proper noun}}. Benwing2 (talk) 01:41, 9 August 2021 (UTC)

 Done Yes, didn't exist before but has been added now. Thanks for your work. Equinox ◑ 04:04, 4 September 2021 (UTC)

(The word is cryptorchis.) So I wanted to write {{en-noun|~|?}}, but that literally produces a question mark as the plural. What is the correct way? Equinox ◑ 15:39, 8 August 2021 (UTC)

@Equinox This should be fixed now. Benwing2 (talk) 23:45, 8 August 2021 (UTC)

Hi, I was using API Sandbox to search for elements in Category:Portuguese verb forms that should be instead in Category:Portuguese past participles. I'm not very skilled at using API, so I was ctrl+f'ing the list with a maximum of 5000 elements in order to find, for instance, elements ending in "ado", "ada", "ido", etc. I was wondering if there's a way to find those elements automatically so that I can find quicker which elements should be corrected. - Sarilho1 (talk) 16:10, 8 August 2021 (UTC)

Template:pinf See User:Benwing2/pt-verb-forms-past-participles. User:Erutuon might know how to do this using the built-in search functionality. Benwing2 (talk) 23:56, 8 August 2021 (UTC)

@Sarilho1 Oops. Benwing2 (talk) 23:57, 8 August 2021 (UTC)

@Sarilho1, Benwing2: A search for incategory:"Portuguese verb forms" intitle:/ds?/ almost gets you there, but it includes matches like adore along with the past participles, and bizarrely ^ and $ for "beginning of title" and "end of title" are disabled in intitle://. A database query works quite well though! — Eru·tuon 00:41, 9 August 2021 (UTC)

@Erutuon Thanks, I didn't even know about those database queries. Benwing2 (talk) 01:37, 9 August 2021 (UTC)

@Sarilho1: no need to use the API. Dixtosa's Suffix Index lets you generate a list of all entries in a given category that end in a given sequence of characters. Chuck Entz (talk) 02:31, 9 August 2021 (UTC)

incategory:"Portuguese verb forms" intitle:/ds?/ -intitle:/ds?+/ yields a list with fewer false positives. Such a search can be further refined to find items in both categories and/or only with N letters preceding the endings, etc. I don't know what needs to be done to make sure all title with diacritically marked characters are included in the search. DCDuring (talk) 05:29, 9 August 2021 (UTC)

It looks like User:Surjection implemented my suggestion of moving aliases/varieties/otherNames out of the main language modules, and also implemented the suggestion (from User:Erutuon?) to put the script into the fourth field of each language table. Thank you! With a little help from {{multitrans}}, we're down to 13 entries in CAT:E, and of those, 2 are not due to memory errors and 1 is a Chinese character that can be fixed by moving the derived terms to a separate page. We may get even more reduction by some of the following:

1. Make the script and ancestors fields not be tables if there's only one item.
2. Move the wikidata field (second numbered field) to the extra-data modules. This requires implementing my suggestion of not linking the language name to the corresponding Wikipedia entry in etymology templates like {{der}} and {{cog}} in high-memory entries, since linking the language name requires fetching the wikidata value. If we do this, we should move the `ancestors` field to the fourth numbered position.

Benwing2 (talk) 20:00, 8 August 2021 (UTC)

The irony is that the first might actually save memory in some cases. I think having a single table with {"Latn"} and referring to it as a variable will result in a reference rather than a new string "Latn" being created for every single language (I don't know if Lua 5.1 does string interning of any kind, but I don't think it does). — surjection ⟨??⟩ 20:11, 8 August 2021 (UTC)

Surjection did some more searching in the Lua 5.1 source code and found luaS_newlstr where string interning is implemented. (I have never dug into the string implementation much myself. I always thought strings were interned though, and wanted to modify the Lua source code to print out all the strings, just to see how many there are at a given moment and how much memory their data takes. Now I could probably do that.) — Eru·tuon 01:20, 9 August 2021 (UTC)

@Erutuon Interesting. I still think we could save some memory by using strings in place of one-element tables; I don't see how this could possibly increase the memory. Benwing2 (talk) 01:40, 9 August 2021 (UTC)

It appears to be about 6 % based on estimates with a Lua 5.1 modded to report total memory usage before and after a require to the two versions of Module:languages/data2 (the current one and one in which all single-element tables, not just scripts/ancestors even though these are probably 90%+ of the cases, have been converted into strings). For some context, converting scripts into 4 was about 3-4 %, while the extradata split was a 75% drop (down to 214K from 374K). — surjection ⟨??⟩ 16:50, 9 August 2021 (UTC)

@Surjection Thanks for the analysis. 6% isn't all that much but still potentially useful esp. as the change shouldn't be very hard to implement. Benwing2 (talk) 02:59, 10 August 2021 (UTC)

The module which automatically generates IPA transcriptions for Macedonian has several issues, specifically relating to the treatment of syllabic sonorants, which are indicated where they do not belong (the rule is not restrictive enough), and syllabification, as stress marks are placed in violation of morphemic boundaries. Presumably, the latter issue cannot be fixed because the module has no way of knowing what the morphological structure of a given word is, but the issue with the sonorant should be easily fixed. The details are described on the talk page of ]. Could someone who knows how to code improve the module? The user who developed it and conferred with me regarding the more alarming problems in the module's functions, Guldrelokk, seems to be away. Martin123xyz (talk) 06:51, 9 August 2021 (UTC)

@Martin123xyz I will look into it at some point, although I have some other tasks needing to be done as well. The issue of syllable boundaries can be handled by having smart rules that work in most cases along with allowing the user to override the syllable boundaries by explicitly respelling the word(s) with periods added to mark syllable boundaries wherever the default algorithm gets it wrong. This is what is done in the various pronunciation modules I've worked on (e.g. Russian, Spanish, Italian, Portuguese). Benwing2 (talk) 02:52, 10 August 2021 (UTC)

@Benwing2. Thank you for offering to take a look at the module. I have already been overriding the automatic syllabification by using a symbol (` rather than a period, but it matters little what I use in the code as long as the final output is right) to indicate between which consonants the stress mark should appear. I modified the module myself so this would work, and I think that my solution is satisfactory for the syllabification issue, but as for the syllabic sonorants, all I've been able to do so far is copy the automatic transcription, paste it into the code, and delete the superfluous syllabic diacritics manually. Since the syllabicity of sonorants is predictable in Macedonian (from the orthography at any rate), I think that changing the module would be the best option. Otherwise, some entries will use {{mk-IPA}} and others {{IPA|mk|}} (for the manual transcription), which is inconsistent and might make the management of Macedonian entries less practical.Martin123xyz (talk) 06:08, 10 August 2021 (UTC)

@Martin123xyz Can you spell out exactly what the rules are for determining whether a sonorant is syllabic? I'm not familiar with Macedonian pronunciation and don't know which references are to be used (and would probably have a hard time reading them in any case, as I don't read Macedonian ...). Thanks! Benwing2 (talk) 07:14, 10 August 2021 (UTC)

@Benwing2 The basic rules are already integrated into the module, so you can look at it and the talk page to understand them. What is missing is the rule that prohibits two consecutive syllabic consonants. In a word like трн (trn), the algorithm makes both the rhotic and the nasal syllabic, based on the rule that sonorants become syllabic in the contexts C_C and C_#. However, the rule is cyclical and applies from left to right, so after the rhotic becomes syllabic, the nasal is no longer in a C_# but in a C_# context. Therefore, it does not meet the criteria for becoming syllabic and the correct transcription is . Martin123xyz (talk) 07:18, 10 August 2021 (UTC)

This module is pretty big and probably a good candidate for splitting (by language?). Its memory footprint appears to be about 533K (Module:languages/data2 is currently about 208K). — surjection ⟨??⟩ 16:44, 9 August 2021 (UTC)

@Surjection Seems like a good idea to me. Benwing2 (talk) 02:48, 10 August 2021 (UTC)

My concern with splitting by language is that, in the current system where language-specific labels only get to be used by one set of languages with one meaning, in order to add a label you'd have to edit multiple modules, if the label you want to add is already used by another language. If we decide to split by language, it would be nice to first implement per-language labels (i.e., Doric with the language code for Scots links to w:Doric Scots, Doric with the language code for Ancient Greek links to w:Doric Greek). Then two different per-language label modules can have the same label with different meanings.

I'm not sure how to implement that exactly. It's complicated because resolving the meaning of a label involves label aliases (like English → England). Would aliases be per-language as well? And maybe there are non-language-specific labels that should have one meaning for most languages and another meaning for a specific language. Well, if we can't figure this out before splitting by language, hopefully we can implement the splitting in such a way that it doesn't make it difficult to implement per-language labels. — Eru·tuon 21:06, 19 August 2021 (UTC)

I'm confused by the 500k per module cost against the memory quota. If this is split by language, why don't we incur a cost of 500k per language using labels? That would surely make more pages run out of memory. I've been using this estimate as an argument against splitting up modules. --RichardW57 (talk) 07:10, 20 August 2021 (UTC)

We have two templates {{noncog}} and {{m+}} that, as far as I can tell, serve the same purpose and do the same thing. The only difference is that {{noncog}} is restricted to use in etymology sections, while {{m+}} is not; yet it looks as if {{m+}} is almost exclusively used in etymology sections as well. What is the intended difference in use cases for these two templates? Should we get rid of one and redirect it to the other? — Vorziblix (talk · contribs) 05:19, 11 August 2021 (UTC)

{{noncog}} links the language name and {{m+}} doesn't: {{noncog|en|hand}} → English hand vs. {{m+|en|hand}} → English hand. Personally, I use {{m+}} outside of Etymology sections, but I also use it within Etymology sections for the second and subsequent mention of a language so as to avoid overlinking. If we're going to be reducing template redundancy, I'd rather merge {{noncog}} with {{cog}}, since they have the exact same function. Why have separate templates for cognates and noncognates when making that distinction has no effect on anything? —Mahāgaja · talk 07:10, 11 August 2021 (UTC)

I see, thanks. I missed the linking difference. {{cog}} and {{noncog}} are redundant, but they’re basically already merged anyway (the module function that handles {{noncog}} just returns the results of handling {{cog}}). I guess the idea there is to keep semantic labels distinct in case we want to handle them differently in the future — though at a cursory think-through I can’t imagine what case that would be.

In practice, it looks like the way these three templates are used is often totally haphazard. There are non-cognates labelled with {{cog}}, there are etymologies that list some cognates with {{cog}} and some with {{m+}} without any apparent intended distinction, there are some entries using {{noncog}} and others using {{m+}} in exactly parallel contexts. This confusion seems like the rule rather than the exception. Perhaps it might make sense to either more clearly delineate when to use what, or else reduce them to one (which could itself have an optional nolink= parameter or somesuch). — Vorziblix (talk · contribs) 11:10, 11 August 2021 (UTC)

If I recall correctly, I used {{noncog}} to compare Portuguese and Spanish words that were formed by suffixation in both cases (with the root and suffixes being cognates). - Sarilho1 (talk) 13:42, 11 August 2021 (UTC)

{{cog}} and {{noncog}} should never be merged. I use the latter for noncognates (for comparing similarly formed words by semantics; or false cognates, i.e., ones formed of cognate components but as a whole the words have no common etymon). ·~ dictátor·mundꟾ 12:10, 2 September 2021 (UTC)

The Macedonian phrase template {{mk-phrase}} adds an extra space beneath the header, unlike all the other ones. Consequently, when one blank row is left beneath the header in the code, two appear in the output, as you can see at око не му трепнува (oko ne mu trepnuva). At мува не го лази (muva ne go lazi), the problem has been circumvented by leaving no blank row in the code, but this is not how other headers like {{mk-noun}} are handled, so I think that a fix is in order. Could someone help? Martin123xyz (talk) 06:24, 12 August 2021 (UTC)

@Martin123xyz: Fixed. — Fenakhay ^{(تكلم معاي · ما ساهمت)} 06:46, 12 August 2021 (UTC)

Thank you! Martin123xyz (talk) 06:47, 12 August 2021 (UTC)

Hello,

I don't know if it's me, my browser or what else but I have the impression that red links have changed colors to a flashier / pinker red hue starting yesterday? And today on Wikipedia too. If related to Wikimedia, what was the point of it? Thx Sitaron (talk) 07:59, 13 August 2021 (UTC)

@Sitaron: I saw your message and looked at some redlinks, and yes, they're almost incandescent. This is a Wikimedia or MediaWiki thing and someone has posted about it in Phabricator (phab:T288739), and it looks like they're already working on fixing it. I remember there was another link color kerfuffle in the past (about the purple visited links getting darker?) and they fixed that pretty quick. — Eru·tuon 09:00, 13 August 2021 (UTC)

When did they fix that problem? I had to change it through my common.css :-/ --Robbie SWE (talk) 09:05, 13 August 2021 (UTC)

I'm not sure, because one discussion about the problem was at Wiktionary:Information desk/2020/February § Sudden changes to interface and nobody mentioned a Phabricator task there. I believe there was a task, but I wasn't able to locate it by searching Phabricator because there are so many tasks related to visited links and apparently no way to filter by date! — Eru·tuon 18:07, 13 August 2021 (UTC)

Hello. In the references generated by {{R:mk:Belchev}} and {{R:mk:PRMLJ1999}}, a superfluous space appears between the year of publication and the following comma, as you can see in the usage examples. Can someone remove this space? When I edit the pages and search for a space using Ctrl-F, no space is found apart from the ones between words, so I don't know what's causing the problem. Martin123xyz (talk) 09:27, 13 August 2021 (UTC)

@Martin123xyz: I've fixed it by removing a space in Template:cite-meta, though my edit might cause problems in other reference templates and need to be reverted. Pinging User:Sgconlaw in case he knows the purpose of the space that I removed, as it might have separated some element of the citation that hasn't been supplied in {{R:mk:Belchev}} and {{R:mk:PRMLJ1999}}. — Eru·tuon 18:20, 13 August 2021 (UTC)

The space was introduced at some stage by another editor to fix a different problem, but as you can see it introduced the above issue. I've been meaning to look into it at some stage, and will try and do so … can't promise it will be very soon, though. — SGconlaw (talk) 18:28, 13 August 2021 (UTC)

Hello- on page 866, we get an English language pronunciation for Wuhan, China. In this edit, I try to reproduce that pronunciation: . Please ping me and let me know if there's a better way to do this. Thanks for any help. I ask because this affects maybe a dozen or more entries I work on. --Geographyinitiative (talk) 17:24, 15 August 2021 (UTC)

@Geographyinitiative: If you're using the "‹o› ‹combining double macron› ‹o›" it seems to be fine, the page Appendix:English_pronunciation#Vowels appears to use the same thing. Font support could be choppy though; not everyone has caught on with the Unicode features. --Frigoris (talk) 17:54, 15 August 2021 (UTC)

Thanks for your help. I will start using this. --Geographyinitiative (talk) 18:01, 15 August 2021 (UTC)

I spotted this and thought somebody here might be equipped to do it. Equinox ◑ 06:23, 16 August 2021 (UTC)

What's going on with Hebrew letters with diacritics (vowel points)? Yesterday they suddenly started displaying weirdly for me, with spaces after (i.e. to the left of) every character with a point, e.g. at שאָקאָלאַד, which on my display currently looks like 4 words instead of 1. I even edited User:Mahagaja/common.css to force display in a more Hebr-friendly font, but that did absolutely nothing at all. It seems to happen only when the text is formatted as a language; if I type שאָקאָלאַד as a bare link, or שאָקאָלאַד with no formatting at all, it displays normally (no spaces). —Mahāgaja · talk 09:09, 17 August 2021 (UTC)

@Mahagaja: Well, I made a bunch of changes to the Hebrew fonts recently to prioritize the ones with good support for cantillation marks and meteg. I removed DejaVu Sans and variations on it because it supports vowel points but renders cantillation marks badly, so maybe that was the one that Hebrew was displaying in before. (Maybe I should just add DejaVu Sans back, but at the end of the list.) Otherwise I only added more fonts and changed the ordering, which shouldn't cause a worse font to be used unless there's a bad font on the list, which I hope isn't the case. (And it would have to be very bad to display שאָקאָלאַד badly.)

Hopefully the problem's fixed now; I edited your common.css, which was using , but needed to use .Hebr.

I'm curious what font was being selected; hopefully it wasn't on the .Hebr font list in MediaWiki:Common.css. If the problem isn't fixed or you have a font problem again, could you find out and report exactly what font is being used, and if you can, what font was used before? (I wrote instructions at Wiktionary:Unicode § Identifying a font because this keeps coming up.) That might help indicate how MediaWiki:Common.css is causing the problem. — Eru·tuon 19:58, 17 August 2021 (UTC)

@Erutuon: thanks for fixing my common.css; that fixed the appearance of links and pagenames, but the formatted text on the headword line still has the weird spaces (see screenshot). The fonts used, according to Inspect…, are Arial, Ezra SIL, Gentium Plus, Malgun Gothic, Noto Sans Hebrew, Segoe UI, Segoe UI Bold, Segoe UI Italic, Tahoma. Segoe UI is my default font for the browser I'm using (Firefox on Windows 10). When I deactivate the relevant lines in my common.css, then the problem returns to the pagename and to links; now all of them are in Noto Sans Hebrew and have the weird spacing. However, Noto Sans Hebrew works fine in other applications (e.g. Microsoft Word), and Noto Sans Hebrew was working fine up here at Wiktionary as well until quite recently (and I do have the distinct impression the problem started yesterday, 3 days after your edits to Mediawiki:Common.css, but I could be mistaken about that). —Mahāgaja · talk 21:36, 17 August 2021 (UTC)

@Mahagaja: (edit conflict) That sounds like the list from "All fonts on page" in the Fonts tab, so it's hard to be sure which font is used for which character. If you right-click and inspect the badly-displaying headword, the fonts used only for that text should be listed at the top of the Fonts tab next to "Fonts used". Arial, Segoe UI, Noto Sans Hebrew, and Tahoma all have similar Hebrew letterforms to the headword, but none of them have the gap on my computer. Could be that you and I have different versions of whichever font it is. Hmm, there's a difference between the derived terms font and the headword font. span.Hebr in your common.css won't target the headword so you're probably getting a font from MediaWiki:Common.css or your default sans font for that. Probably Segoe UI then. Replacing that CSS selector with .Hebr in your common.css should give the headword the same font as the derived term. — Eru·tuon 21:58, 17 August 2021 (UTC)

@Erutuon: when I select the badly displaying headword and inspect only that, the problematic font is revealed to be Noto Sans Hebrew. Incidentally, I checked on Chrome, and the same problem exists there, and there too the font used for the headword is Noto Sans Hebrew. —Mahāgaja · talk 22:07, 17 August 2021 (UTC)

@Mahagaja: That's weird! My Noto Sans Hebrew doesn't have the gaps. Maybe yours is an older version that was released even though it had horribly broken vowel points. I could shift it to the end of the list of fonts to make it less likely to be chosen, if this is likely to happen for other people. — Eru·tuon 22:17, 17 August 2021 (UTC)

@Erutuon: I suppose that's possible, but why would the problem just suddenly appear yesterday? I'm pretty sure I've always been using Noto Sans Hebrew on this operating system/browser/website constellation, but the spacing problem only arose in the last few days. According to the Noto fonts haven't been updated since October 2017, and that is the version I have installed on my computer. As I said, NSH is working fine in MS Word, just not at Wiktionary. Anyway, changing "span.Hebr" to ".Hebr" in my common.css, as you recommended, worked. (I also switched from Ezra SIL, which is too bulky for running text, to Segoe UI, which works fine.) Thanks for your help! —Mahāgaja · talk 22:37, 17 August 2021 (UTC)

@Mahagaja: Glad to help! Mystifying that NSH would work elsewhere but not in Firefox. Firefox has pretty good font rendering. Actually you might have had something else for Hebrew script up till I changed MediaWiki:Common.css. Before then, NSH wasn't even on the list, and Firefox would probably have used one of the fonts on the list or your default font if it has the necessary characters. — Eru·tuon 23:19, 17 August 2021 (UTC)

This reminds me in some ways of Wiktionary:Information_desk/2016/August#What_is_this_character?, another situation where text (ɿ) in a font (Times New Roman, in that case) displayed either one way or another for different users (either with or without a descender). (Incidentally, whereas at that time it ended at and not below the baseline for me, it now descends below the baseline for me, in Times New Roman, as it did for Suzukaze.) I don't know what to make of it other than that computers / browsers / fonts just act weird sometimes. - -sche (discuss) 02:26, 18 August 2021 (UTC)

Macedonian вистина или предизвик (vistina ili predizvik) does not really have gender because the first noun is feminine and the second is masculine. However, if I leave the gender parameter blank, a question mark is generated, as if the gender were unknown and someone who knew it could later come and add it. The fact that the term does not really have a gender is demonstrated by the fact that it cannot be modified by adjectives, which would require gender assignment for the purposes of agreement. For this problem to be circumvented, a freely modifiable helping word like "a round of" or "a game of" is used. Even so, I find it counterintuitive to change the term from a noun to a phrase, since it is the name of the game and can be integrated into a sentence as a noun when unmodified, e.g. as the direct object of the verb "to play". Can anyone advise me as to what I should do with the gender parameter? Martin123xyz (talk) 12:56, 18 August 2021 (UTC)

@Martin123xyz: Instead of using {{mk-noun}} you could just use {{head|mk|noun}}. —Mahāgaja · talk 14:34, 18 August 2021 (UTC)

Thank you. I've done that now. Martin123xyz (talk) 05:57, 19 August 2021 (UTC)

Currently, some Macedonian inflection tables are introduced by the generic header "Inflection", whereas others are introduced by the specific header "Declension" or "Conjugation", depending on whether they're nominal or verbal respectively. Could a bot be used to harmonize all the entries? Martin123xyz (talk) 09:28, 19 August 2021 (UTC)

The genitive case on this template should have three sections (masculine singular, feminine singular, and plural), but I don't have the technical knowledge to add them without making it look bad. Can anyone help? --YukaSylvie (talk) 06:50, 22 August 2021 (UTC)

BandiniRaffaele2 (talk • contribs) needs help with his first template, {{rgn-adj}}. Consult him on the nature of Romagnol adjectives, too. --Apisite (talk) 12:12, 22 August 2021 (UTC)

@Suzukaze-c, Apisite: Thank you!--BandiniRaffaele2 (talk) 05:37, 23 August 2021 (UTC)

I would like the dot added by this template to be removed, as I have to add |nodot=1 so I can replace the dot with a comma when I add text after using the template. A discussion with User:Chuck Entz appears here. DonnanZ (talk) 22:00, 22 August 2021 (UTC)

Instead of adding |nodot=1 and a comma outside the template, you can just add |dot=,, which will turn the dot into a comma. —Mahāgaja · talk 11:31, 23 August 2021 (UTC)

I tried it with Hatcham, and couldn't get it to work, so aborted it. DonnanZ (talk) 13:32, 23 August 2021 (UTC)

@Donnanz: I did it; you have to write |dot=,}} Greater with the comma inside the template. —Mahāgaja · talk 13:55, 23 August 2021 (UTC)

Ah, thanks, I can see where I went wrong. But I'm convinced more than ever that removing dots from these templates is the ultimate solution. DonnanZ (talk) 14:10, 23 August 2021 (UTC)

I agree that it would be more straightforward to eliminate the dot in almost every template that has the nodot parameter, possible exceptions being templates that constituted a complete definition, like {{|temp|synonym of}} and {{taxon}}. DCDuring (talk) 15:58, 23 August 2021 (UTC)

Every template, no exceptions. For consistency, first of all. And it's always possible to add more to the line.

This was obvious years ago. DAVilla 18:00, 23 August 2021 (UTC)

I have decided to learn the basics of the code of the Macedonian IPA module myself so that I could fix all the problems with it. I have successfully dealt with several issues but I still cannot figure out how to write a rule that will keep voiced consonants voiced before another word starting with a voiced consonant.

Currently, the following rule devoices word-final consonants:

text = rsub(text, "(*)(ˈ?)", function(a, b)

The # apparently indicates the end of a word boundary (it says so inside the code of the module), so get devoiced at word boundaries just as they do before .

However, should stay as they are if the following word starts with . To solve this problem, I removed the # from the initial rule and changed the code as follows:

text = rsub(text, "(*)(ˈ?)", function(a, b) - only devoices consonants before voiceless consonants

text = rsub(text, "d(##)", "t%1") - only devoices consonants (just /d/ for starters, to keep it simple) at the end of a string of text

text = rsub(text, "d(#)(t)", "t%1%2") - /d/ devoices to across a word boundary if the following word starts with

text = rsub(text, "d(#)(n)", "d%1%2") - /d/ stays across a word boundary if the following word starts with (again, this was just a test with individual consonants)

Unfortunately, the solution doesn't work. The result is:

• одстапи >
• од тукашниот >
• од нигдешниот >
• од >

Only 1, 3 and 4 are right. The rules with "d(#)(t)" and "d(#)(n)" seem to be useless. However, if a write a rule without specifying a following consonant, it works (fixing 2 and breaking 3):

text = rsub(text, "d(#)", "t%1")

I think that the problem is that the module does not read "d(#)(t)" as "d t". I tried with a bare space and no word-boundary markers, but it does not work that way either. Please help. Martin123xyz (talk) 07:54, 24 August 2021 (UTC)

I've fixed the problem: the solution was to write "d# #t" between the words. The IPA module now works as it should and no further changes are required. However, if someone wishes to clean up the code (e.g. to add variables where I've spelled everything out with separate rules), they can do so. Martin123xyz (talk) 08:25, 24 August 2021 (UTC)

I added the following rule to stress even monosyllabic words:

text = rsub(text, "(#*" .. vocalic_c .. "*#)", "ˈ%1")

Then I tried to make the word "од" an exception because it is a monosyllabic preposition, but none of the following workx:

text = rsub(text, "#ˈод#", "#ɔt#")

text = rsub(text, "#ˈɔd#", "#ɔt#")

text = rsub(text, "#ˈɔt#", "#ɔt#")

text = rsub(text, "#ˈ()()#", "%1%2")

However, the following does work for "или", a bisyllabic conjunction:

text = rsub(text, "#ˈiɫi#", "#ili#")

Otherwise, stress is assigned to "или" by the following:

text = rsub(text, "(#*" .. vocalic_c .. ")(*" .. vocalic_c .. "*#)", "%1ˈ%2")

What is the problem and what can be done so that all monosyllabic words are stressed unless listed in a list of exceptions? Martin123xyz (talk) 09:14, 24 August 2021 (UTC)

When I erase the rule for adding stress to monosyllabic words, I can write text = rsub(text, "#ɫɛb#", "#ˈlɛp#") to force stress assignment to a monosyllabic noun ("леб"). However, I do not want to add a rule for every single monosyllabic word that is not a clitic; it would be much faster to do it the other way around, with automatic stress and a short list of exceptions without stress. Martin123xyz (talk) 09:17, 24 August 2021 (UTC)

Discussion moved from User_talk:Benwing2#List_of_entries_using_specific_headword_parameters. (@Benwing2)

At Template talk:pmh-g, @Inqilābī and SodhakSH (now @Svartava2) have stated that placing gender variants of a term on the headword line rather than in a template is more desirable. With a template, Special:WhatLinksHere shows a dynamic list of pages using the template. If |f=, |m= and possibly |n= are used on the headword line instead of template (such as with {{hi-noun}} for Hindi), what needs to be done to emulate Special:WhatLinksHere so that one can see a dynamic list of pages using these parameters? Kutchkutch (talk) 12:00, 16 July 2021 (UTC)

By 'in a template', you meant 'in a table generated by a template'. It took a while to unpack that. The simple answer is get the language-specific noun headword template to add them to a category such as Prakrit nouns with gendered forms. While it might be more intelligible to do it in a module, one can use {{#if|{{{m|}}}{{{f|}}}{{{n|}}}|]}} to populate the category from the headword template. @Benwing2 may be needed to advise on how to stylishly link the new category into the category hierarchy. For a language-specific module, issues may arise with preventing the three parameters descending to Module:headword. One would also pass the parameters down to {{head}} as specified in the templates documentation for display on the headline. (I thinks the module behind {{head}} is robust enough to take empty parameters.) --RichardW57m (talk) 15:25, 24 August 2021 (UTC)

@RichardW57, RichardW57m: Thanks for taking the time to unpack the lack of clarity. Such a category would definitely be helpful for more than just one language, and it’s surprising that it hasn’t been done yet. It’ll be interesting to see what Benwing has to say about this when they get a chance to respond. Kutchkutch (talk) 02:46, 26 August 2021 (UTC)

Hi. Can someone smart make a page containing all quotations containing a dash symbol — and put it at Wiktionary:Todo/Dash quotes? There's probably a bunch of badly formatted quotes out there to fix. Wubble You (talk) 13:38, 25 August 2021 (UTC)

Please clarify: are you referring only to em-dashes?

—DIV (1.145.98.103 02:13, 26 August 2021 (UTC))

Yeah, em-dash please Wubble You (talk) 05:57, 26 August 2021 (UTC)

If a text includes — without spaces between words, you copy that faithfully in the quotation, right? DonnanZ (talk) 08:38, 26 August 2021 (UTC)

Yeah, I guess. I imagine a big bunch of false positives will surface Wubble You (talk) 09:18, 26 August 2021 (UTC)

@Wubble You: Em dashes in the first lines of English quotations here, en dashes added here but that can be reverted if you don't want to eliminate all the false positives (date or page ranges for instance). — Eru·tuon 19:52, 26 August 2021 (UTC)

Oh, and any search requests of English quotes are welcome. I have a file that is really fast to search (under 2 seconds for the dashed quotes thing). It includes anything marked by a line starting in #* (any number of # actually) followed by zero or more lines starting in #*:. — Eru·tuon 20:02, 26 August 2021 (UTC)

No discussion page existed at vasa vasorum.

I click to create a (blank) page. It says click again to confirm — so this message from Wiktionary indicates that creating a blank page is a legitimate action.

I click again, and the message says I have tried to vandalise the page, and so the edit (creating a blank discussion page) was not allowed.

This is confusing and inconsistent behaviour. Please fix.

—DIV (1.145.98.103 02:12, 26 August 2021 (UTC))

Why would you want to create a blank discussion page? Wubble You (talk) 05:58, 26 August 2021 (UTC)

Why would it be offered as a legitimate option by Wiktionary, and then flagged as attempted vandalism?

Why would anyone answer a question with a question?

In my case, because I wanted to hit the button to create a (new) section on the Discussion page, but I cannot do that on a non-existent page.

From the way the "vandalism" message was framed, it seems that Wiktionary is defectively set up to interpret creation of a blank new page (which is legitimate) as the same as blanking an existing page (which is vandalism). Please fix.

—DIV (1.145.61.82 13:30, 26 August 2021 (UTC))

Even uncreated talk pages have the "+" button. —Suzukaze-c (talk) 19:28, 26 August 2021 (UTC)

This confusing experience is probably a downside of planning in advance. Having planned the task as two steps, to create and then to add a section, the ability to do it in one step is then overlooked. --RichardW57 (talk) 20:23, 26 August 2021 (UTC)

@Wubble You: Oh, what was this: diff~diff? ·~ dictátor·mundꟾ 19:19, 29 August 2021 (UTC)

By "input aid in source editor" I mean the panel below the buttons ("Publish changes / Show preview / Show changes / cancel"), where there's a dropdown menu for character types ("Latin/Roman, IPA and enPR, Modifiers and combining diacritics", etc.). I don't know the formal name of this block.

The problem is that, with "Devanāgarī" selected, the letter "DEVANAGARI VOCAL SIGN VOCALIC LL" = ॣ seems to be (improperly) joined together with "DEVANAGARI DANDA" = ।. I presume these two clickable letters should have been separate, each intended for its own codepoint. The current effect is that the clickable unit is the combination, rather two separate letters. Upon clicking it, the sequence ॣ। appears in the text-editing area, which hardly helpful. --Frigoris (talk) 13:47, 26 August 2021 (UTC)

I wonder if someone who understands these things could add Wiktionary:Votes/2021-08/Scope of English prepositions to the list at Wiktionary:Votes/Active. When I try to do it, I get an error "Lua error in Module:votes at line 24: Part of Wiktionary:Votes/ with votes not found." Last time this happened it was something to do with heading levels, I think, but I thought that issue had been fixed. Anyway, if anyone can get it to work I would be very grateful. Thanks, Mihia (talk) 16:31, 27 August 2021 (UTC).

@Mihia: Technical issues aside, why is this a vote? I don't see links to any previous discussions (not even the ones about individual words). Have you considered holding this as a discussion instead? —Μετάknowledge^{discuss/deeds} 19:23, 27 August 2021 (UTC)

This has been touched upon a number of times in discussions, but no conclusion has been reached, at least no conclusion to change what is largely the status quo, though the possibility has been mentioned. I hope you will understand that I cannot immediately locate all of these discussions, but the most recent is at https://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Tea_room/2021/August#behind_(2). It is a vote because it will decide how, or in fact whether to change, the classification of words in the dictionary. For example, whether "behind" in the case "the car behind" can be put under the "preposition PoS" even though it has no object. Surely this is clear, isn't it? Or do you think we should put words in PoS categories on individual editor's whim, so if I think that prepositions need not have objects then I can just go ahead and change existing adverbs to prepositions without obtaining any consensus to do this? Mihia (talk) 19:38, 27 August 2021 (UTC)

@Mihia: You should do your best to link to previous discussions on a vote page. In this case, it appears there hasn't been a discussion about this issue as a whole, rather than for individual words. A vote is not always the best vehicle, and I think you should try seeing if you can get consensus from a discussion first. —Μετάknowledge^{discuss/deeds} 20:53, 27 August 2021 (UTC)

Rather than starting yet another discussion about this that leads to no firm conclusion and may encourage limited participation, this vote is an attempt to encourage wider participation that leads to an actual consensus conclusion, precisely so that we don't have to keep having the same discussion over and over. If, for example, options 2 and 3 are defeated then we (or I at any rate) can stop worrying about it. I do not think it is any more onerous or unreasonable to ask people to cast a vote on this issue, if they have an opinion, than to ask them to participate in a discussion somewhere. If there are concerns about the wording or the options presented then these can be raised at the feedback stage, in the normal way. Mihia (talk) 21:07, 27 August 2021 (UTC)

If you're dead-set on not having a discussion about this, I won't stop you. But you should still link to discussions in your vote. —Μετάknowledge^{discuss/deeds} 21:11, 27 August 2021 (UTC)

I am not "dead-set on not having a discussion about this", I am proposing a vote at this juncture in order to reach a firm conclusion based on wider participation because a number of previous discussions have attracted relatively little participation and have not resulted in a definite conclusion (specifically have not definitely ruled out options 2 and 3 as something that we might want to do). I will try to locate more of the old discussions, but it is not easy. In the meantime, if you are able to figure out what has gone wrong with adding the vote to the list, and are prepared to fix it, I would appreciate that. Mihia (talk) 21:20, 27 August 2021 (UTC)

• We had a period for a couple of months where there were no ongoing votes. I think too many of us have a craving for them TVdinnerless (talk) 16:58, 31 August 2021 (UTC)

Someone please add a parameter |nocap= to Template:&lit. See previous discussion. ·~ dictátor·mundꟾ 19:03, 29 August 2021 (UTC)

I don't think there's any reason to do that. Yes, non-English definitions do start with lower-case letters, but we're inconsistent and one of the exceptions is non-gloss definitions including the text from &lit. Also there's a reason we don't have variations on the definition line with these, as opposed to surnames or place names which have many potential qualifiers. Ultimateria (talk) 17:18, 31 August 2021 (UTC)

The entry ecqui lists ecquam and ecquā twice in the inflection table. These boxes are generated by a template, not manually entered in the code for the page. I'm not sure why this happens, but can it be fixed?--Urszag (talk) 18:15, 30 August 2021 (UTC)

Fixed in Module:la-adj/data. It came from an attempt to use common code for quis and quī; the false assumption had been made that duplicates would be purged. --RichardW57m (talk) 11:04, 31 August 2021 (UTC)

In this edit, I add a citation/quotation. There are two authors and one editor for the book I'm citing. It shows up like this:

To my eye, you can't tell if Wehrfritz is an editor or a second author- in fact, it really looks like there are two editors, Wehrfritz and Booz. (Wehrfritz is a second author.) Is quote-book really set up right? Am I making a mistake? I guess the singular "editor" means it's only Booz, but the semicolon between the first and second author followed by a comma between the second author and editor seems potentially confusing. Please ping me. --Geographyinitiative (talk) 01:09, 31 August 2021 (UTC)

I'd just add a question mark after all the authors names

1988, K. Mark Stevens?, George E. Wehrfritz?, edited by Paddy Booz?, Southwest China: Off the Beaten Track‎, Passport Books, →ISBN, →OCLC, →OL, page 201:

Luzhou 泸州
Luzhou, 143 kilometers east of Yibin, sits at the confluence of the Yangzi and the Tuo Jiang rivers. The main attraction in Lushan is Yunfeng Si (Cloud Peak Temple), (云峰寺) which is said to be large and beautiful. Luzhou is accessible by bus from Yibin and by boat from both Yibin and Chongqing.

Looks awesome to me TVdinnerless (talk) 16:56, 31 August 2021 (UTC)