Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of “all words in all languages”.

Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.

Grease pit archives edit
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021


August 2021

same page and year but different publishers[edit]

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

Invalid ISSN (but the Link Works!)[edit]

An ISSN is being called an "Invalid ISSN"[1] 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)[]

IPA headword images[edit]

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

Add a new function deprecate() to mod:debug[edit]

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

Category:Calculator words[edit]

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

Optimize the display of {{zh-pron}}[edit]

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) [more▼] 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)[]

Quotation syntax not working in Kashmiri Wiktionary[edit]

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

Recent changes on Talk pages[edit]

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

We sure like quoting ourselves[edit]

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

Worst attempt ever at saving Wiktionary[edit]

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 [[a/Old_Irish]] or similar? I ken that’s the best solution. ·~ dictátor·mundꟾ 12:20, 2 September 2021 (UTC)[]

Template for plural-only proper nouns?[edit]

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)[]
Yes check.svg Done Yes, didn't exist before but has been added now. Thanks for your work. Equinox 04:04, 4 September 2021 (UTC)[]

Noun is countable and uncountable, but plural is unknown[edit]

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

Find elements of a category with a given ending using API[edit]

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:/[ai]d[ao]s?/ 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:/[ai]d[ao]s?/ -intitle:/[ai]d[oa]s?[a-zç]+/ 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)[]

Lua memory errors are down[edit]

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

Macedonian pronunciation module[edit]

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 [[2]]. 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[-syllabic]_C[-syllabic] and C[-syllabic]_#. 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[-syllabic]_# but in a C[+syllabic]_# context. Therefore, it does not meet the criteria for becoming syllabic and the correct transcription is [ˈtr̩n]. Martin123xyz (talk) 07:18, 10 August 2021 (UTC)[]

Module:labels/data/subvarieties[edit]

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

Template:noncog versus Template:m+[edit]

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

Macedonian phrase template[edit]

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

Color of red links[edit]

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

Macedonian reference templates[edit]

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

o͞o[edit]

Hello- on page 866, we get an English language pronunciation for Wuhan, China. In this edit, I try to reproduce that pronunciation: [3]. 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)[]

Module:ru-adjective needs declension type "non-declinable in the feminine"[edit]

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

Pointed Hebrew characters[edit]

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 [sc|=Hebr], 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)[]
Shokolad Mahagaja screenshot 2021-08-17.png
@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 [5] 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 multiword nouns of unclear gender[edit]

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

Macedonian inflection headers[edit]

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

{{rom-decl-noun}}[edit]

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

Template:rgn-adj[edit]

BandiniRaffaele2 (talkcontribs) 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)[]

Template:former name of[edit]

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

How to indicate space in IPA module[edit]

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, "([bdɟɡzʒv" .. TIE .. "]*)(ˈ?[ptcksʃfx#])", function(a, b)

The # apparently indicates the end of a word boundary (it says so inside the code of the module), so [bdɟɡzʒv] get devoiced at word boundaries just as they do before [ptcksʃfx].

However, [bdɟɡzʒv] should stay as they are if the following word starts with [bdɟɡzʒvmɱnɲvrɫljʎ]. To solve this problem, I removed the # from the initial rule and changed the code as follows:

text = rsub(text, "([bdɟɡzʒv" .. TIE .. "]*)(ˈ?[ptcksʃfx])", 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 [t] across a word boundary if the following word starts with [t]
text = rsub(text, "d(#)(n)", "d%1%2") - /d/ stays [d] across a word boundary if the following word starts with [n] (again, this was just a test with individual consonants)

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

  • одстапи > [ˈɔtstapi]
  • од тукашниот > [ɔd tuˈkaʃni(j)ɔt]
  • од нигдешниот > [ɔd niɡˈdɛʃni(j)ɔt]
  • од > [ɔt]

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

Stress exceptions in Macedonian module[edit]

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, "#ˈ([oɔ])([dt])#", "%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)[]

List of entries using specific headword parameters[edit]

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|}}}|[[cat:Prakrit nouns with gendered forms]]}} 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)[]

Quotations with —[edit]

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

Creating blank page is not vandalism.[edit]

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

Defect in Devanagari input aid in source editor[edit]

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

Can't add vote to list[edit]

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? —Μετάknowledgediscuss/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.org/wiki/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. —Μετάknowledgediscuss/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. —Μετάknowledgediscuss/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)[]

Missing parameter[edit]

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

ecqui has identical forms listed twice in inflection table from la-adecl[edit]

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

quote-book Citation Looks Wrong To Me[edit]

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:

1988, Stevens, K. Mark; George E. Wehrfritz, Paddy Booz, editor, Southwest China: Off the Beaten Track[6], Passport Books, →ISBN, OCLC 838954029, OL 8244037M, 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.


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, Stevens?, K. Mark; George E. Wehrfritz?, Paddy Booz?, editor, Southwest China: Off the Beaten Track[7], Passport Books, →ISBN, OCLC 838954029, OL 8244037M, 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)[]

September 2021

Macedonian redlinks[edit]

I tried to create a category for Macedonian redlinks but it is not being populated, even though I saved it as {{auto cat}}. Can someone help populate it? I'm still trying to view all the Macedonian words that are somehow referenced within Macedonian entries. Jberkel already created a list of wanted Macedonian words, and it has been helpful - I have created many new entries based on it - but it covers only a small portion of the total redlinks. For example, until today, лепне (lepne) was provided as a perfective form of лепи (lepi), but it was not on Jberkel's list even though there was no page for it (I have now created one). Martin123xyz (talk) 08:35, 1 September 2021 (UTC)[]

"mk" had to be added to the list of language codes at {{redlink category}}. We do it that way because this involves every templated link in every entry on Wiktionary, and loading Module:redlink category takes a lot of resources for the benefit provided. It's less of a problem in Cyrillic entries, though, because there tend to be fewer language sections and thus less system overhead per page. Chuck Entz (talk) 14:47, 1 September 2021 (UTC)[]
Thank you.
Martin123xyz (talk) 07:09, 2 September 2021 (UTC)[]
Yeah, the problem there is that JBerkel's wanted lists don't look into headword-line templates, like the headword line in лепи (lepi) where лепне (lepne) was linked. It would be hard for the wanted link collector to incorporate forms from all of the headword-line templates because some of them have complicated rules or require template expansion, and their behavior is changed or new ones are created quite often, and they may not always be categorized correctly in subcategories of Headword-line templates by language, but {{mk-verb}} in that entry would be quite easy. — Eru·tuon 17:33, 2 September 2021 (UTC)[]
Thank you for the explanation. Have you now added {{mk-verb}} to Jberkel's list? Will the aspectual pairs be there in the September edition? Martin123xyz (talk) 06:40, 3 September 2021 (UTC)[]

Macedonian entry maintenance needed[edit]

Since no one was able to provide with me a list of Macedonian entries lacking an IPA transcription, I have opened just about every Macedonian entry that I or one of the other Macedonian users had created or edited to check whether it had a transcription or not and I added it where I could. The number of Macedonian entries with an IPA transcription thus rose from about 8000 to about 28000. I am almost done with the manual checking so I would like to draw the community's attention to some of the problems that need to be fixed in the work already performed:

Because of the repetitive and laborious nature of the activity, it was inevitable that I should at times place the pronunciation header before the etymology header in some entries. In such cases, the two headers should be inversed, except where there is one pronunciation for multiple etymologies. In those cases, it is more economical to have the pronunciation at the top as a level-three header rather than repeating the same pronunciation as a level-four header under each etymology (since with very few exceptions, a Macedonian orthographic sequence only has one pronunciation regardless of how strikingly its homonymous meanings may differ, unlike in English, where contrasts such as "rEcord" and "recOrd" abound).

There are also some entries where I have put the symbol | inside the pronunciation template even though I did not provide a manual respelling after it. It should be removed in such cases ({{mk-IPA|}} needs to become {{mk-IPA}}). Care should be taken not to remove the | where a respelling is present, to avoid reverting to an automatic rendering or breaking the template.

Finally, there are cases where the * has been omitted before {{mk-IPA}}, causing the pronunciation to appear below the header without an indentation and a bullet point.

I am reporting this so that users who know how to code and make bots can fix the layout issues swiftly and efficaciously. I cannot manually reopen all 29700 Macedonian lemma pages to find the 300 or so pages where I have mistakenly inverted the headers or left debris in the template.

Martin123xyz (talk) 08:46, 1 September 2021 (UTC)[]

@Martin123xyz Wow, congratulations. I have done exactly that with Khmer, but not only IPA, I have reviewed the whole entries as well (etymologies, meanings, templates, formatting,... many entry stubs have been left to rot for years) and added affixed derived forms. There was some 4500 entries when I started out, a lot less than your 28k entries and it took me 3.5 months to complete!... I hope it hasn't taken you 2 years to complete :) Sitaron (talk) 07:43, 5 September 2021 (UTC)[]
@Sitaron Thank you and congratulations on your work on Khmer. Since I created most of the Macedonian entries myself, I did not need to check the meanings or templates, but while adding pronunciations (it took me a month for about 22000 entries and I am now done; the entries that don't have a pronunciation are the few that I missed or whose pronunciation I do not know because the words are not in common use and are absent from the Macedonian orthoepic dictionary), I did realize that new templates needed to be created for some rarer inflectional patterns and I also weeded out some of the mistakes that I had made the first time round. As for etymologies, I have not even started adding any yet. I'm leaving that for some undetermined point in the future, since it would require academic research and consequently much more time and effort than anything else that a Wiktionary entry usually includes. Martin123xyz (talk) 02:17, 6 September 2021 (UTC)[]

Macedonian singularia tantum[edit]

When a Macedonian noun has no plural and a user has indicated - in the plural parameter, it is displayed as a link on the page, which leads the user to the page created for the hyphen symbol (see хмељ (hmelj)). I believe that this is undesirable. Could someone fix it, either by removing the feature which creates the link or by adding a feature that prints the hyphen as "no plural"? Martin123xyz (talk) 10:01, 1 September 2021 (UTC)[]

I fixed the immediate problem, but I suspect someone will have to look at how it handles multiple plurals- I don't have the time or knowledge of lua to do anything more. Chuck Entz (talk) 15:03, 1 September 2021 (UTC)[]
@Chuck Entz Thank you for fixing the problem. I am confirming that хмељ (hmelj) with no plural, директор (direktor) with a plural and a feminine equivalent, рака (raka) with a plural and three diminutives, and корен (koren) with two plurals are all correctly rendered. What other problem could there be other than the one you have already dealt with? Martin123xyz (talk) 07:08, 2 September 2021 (UTC)[]

love/translations[edit]

Hello,

I don't know if it's a side-effect of moving translations to separate sub-pages or the use of the t-simple template, but can someone check why the French, Italian... entries look broken? Is that a known issue?

Sitaron (talk) 07:48, 5 September 2021 (UTC)[]

@Sitaron: {{t-simple}} doesn't support embedded links like in {{t-simple|fr|[[aimer]] [[beaucoup]]||langname=French}}. So {{t}}, or {{t+}} if there is |interwiki=1, has to be used instead. Fixed. — Eru·tuon 15:33, 5 September 2021 (UTC)[]

<2 word per line in column in specific circumstance[edit]

The explanation column in Appendix:Glossary, on entries with linked Wikipedia articles, are impractically narrow on a vertically held phone.

In my case, the explanation is constrained to less than 1/8 of the screen width; the rest being empty below the Wikipedia box.

One example is the areal entry, where this:
"Distributed across multiple languages inhabiting a particular area,"

…is presented like this:

Distri
buted
acros
s
multi
ple
langu
ages
inhabi
ting a
partic
ular
area,

It's a relatively minor issue for me, since it can be somewhat alleviated by tilting the phone sideways. But as it seems to be dependent on font size relative to viewport width, I imagine people with certain visual deficiencies would have a bad time using this glossary.

Using my browsers accessibility features to increase font size to 200% gives this atrocity, where any "w" or "m" are not even wholly rendered:

D
i
s
t
ri
b
u
t
e
d
a
c

—⁠This unsigned comment was added by 2A05:9CC4:7A:89CD:1553:F766:8955:581F (talk) at 14:10, 5 September 2021 (UTC).[]

Problem with Preferences[edit]

About 15 minutes ago I lost the use of the Regular expression gadget. I then went to Special:Preferences and found that I could not access any of the tabs there. Does anyone have any idea why this is happening, whether it is temporary, or whether it is a consequence of climate change? DCDuring (talk) 01:58, 6 September 2021 (UTC)[]

Hm, Preferences is working for me. Gadgets and user scripts are disabled on Special:Preferences, so that rules out anything from that end. Does the Javascript console show any errors? (See here for how to open the console.) --Yair rand (talk) 05:18, 6 September 2021 (UTC)[]
Thanks. Both of the problems went away, from which I conclude that they were somehow linked. I will consult the Java console when I have UI problems in the future. DCDuring (talk) 16:03, 6 September 2021 (UTC)[]

Macedonian participles[edit]

When Macedonian participles are defined with the templates {{inflection of|mk|lemma||m|s|adj|part}} {{inflection of|mk|lemma||perf|part}} and {{inflection of|mk|lemma||adv|part}}, they are all assigned to a category called Macedonian participles. Could someone modify the templates so that they assign each participle to an individual participle category corresponding to its type (one for adjectival participles, one for adverbial participles, and one for perfect participles) and make it possible to access the list for each kind of participle from the page for the main participle category? This is what has been implemented for Russian. For example, прочитавший (pročitavšij) is assigned to both Russian participles and Russian past active participles, and when I view the page Russian participles, I can open the list of past active participles from there. Martin123xyz (talk) 13:40, 7 September 2021 (UTC)[]

I wanted to rewrite the following code for Macedonian:

cats["ru"] = {

{"has", "part",

{"multi",

"participles",

"verb forms",

{"cond",

{"hasall", {"pres", "act"}, "present active participles"},

{"hasall", {"pres", "pass"}, "present passive participles"},

{"hasall", {"pres", "adv"}, "present adverbial participles"},

{"hasall", {"past", "act"}, "past active participles"},

{"hasall", {"past", "pass"}, "past passive participles"},

{"hasall", {"past", "adv"}, "past adverbial participles"},

},

}

},

However, the source of Module:form_of/cats has been protected. Therefore, I am unable to solve the problem myself even though I got an idea as to how it could be done. Martin123xyz (talk) 06:51, 9 September 2021 (UTC)[]

Update - the necessary code has now been added by Hazarasp and all is well. Martin123xyz (talk) 14:01, 10 September 2021 (UTC)[]

Two TOC Templates Made[edit]

I made the following templates: {{blt-categoryTOC}} and {{bo-categoryTOC}}. How could they be improved? --Apisite (talk) 01:40, 11 September 2021 (UTC)[]

Tag Weirdness[edit]

When I look at the revision history for āhār, I see a random assortment of abuse-filter tags on the entry creation- none of which should be there. Particularly notable is "WTNoD", which should never have been added to any mainspace edit, and which the abuse log has no record of for this entry. How did those tags get there, and is this a symptom of a larger problem?Chuck Entz (talk) 20:48, 12 September 2021 (UTC)[]

That would be because a vandal added them manually. You can deactivate tags at Special:Tags if people shouldn't be adding them manually. This, that and the other (talk) 01:57, 13 September 2021 (UTC)[]
I see we've got a new bunch of tags with no descriptions. Write your documentation, people! Equinox 20:37, 16 September 2021 (UTC)[]

Indicating multiple languages inside etymology templates[edit]

How do I use the etymological template {{affix}} to indicate a Proto-Slavic root and a Macedonian suffix? I tried writing {{affix|sla-pro|lang2=mk|*kъde|-ка}} for дека (deka), but then it spells out "Macedonian" for the suffix without spelling out "Proto-Slavic" for the root. More alarmingly, it adds the word to a category of Proto-Slavic terms derived from Macedonian rather than the other way around. It seems as if the templates are requiring me to analyze the word as де- + -ка in Macedonian and then add that the first element is from Proto-Slavic *kъde but this is unsatisfactory since the root is unattested in the form де- in Macedonian. I can't treat both elements as Proto-Slavic either because the addition of the suffix is a Macedonian innovation. Could someone please help format the etymology properly? Martin123xyz (talk) 07:33, 15 September 2021 (UTC)[]

I think you'd use a lang parameter for the other element: {{affix|mk|*kъde|-ка|lang1=sla-pro}}. — Eru·tuon 18:20, 15 September 2021 (UTC)[]

Macedonian inflection templates not updating[edit]

I have created three new templates for Macedonian nominalized adjectives, one for each gender, and whereas I created the feminine and the neuter one just now, the masculine one exists since the 3rd of the September, but it still doesn't appear in Category:Macedonian_noun_inflection-table_templates. Does it take a really long time for new templates to appear in their respective categories or is there something wrong with the templates?

The three templates are the following:

  1. {{mk-decl-noun-m-adj}}
  2. {{mk-decl-noun-f-adj}}
  3. {{mk-decl-noun-n-adj}}

Martin123xyz (talk) 08:37, 15 September 2021 (UTC)[]

I did a null edit on the template page, and it's there now. It was displaying on the template page, but the category links didn't get updated until the template was edited. Transclusion of categories doesn't automatically propagate all the way to the end when there's a template in between.
Thank you for taking care of {{mk-decl-noun-m-adj}}. I was able to add the other two templates to the category as well using the null edit technique. Martin123xyz (talk) 09:14, 15 September 2021 (UTC)[]
Is there any way to search for other stray templates that I have created but which have not been added to the appropriate categories? I recently created some verb templates as well for impersonal conjugation and I see that they're not categorized either. Martin123xyz (talk) 09:16, 15 September 2021 (UTC)[]
Contributions pages have the option for filtering by namespace and for page creations only, so it's easy to generate a list of all the templates you've created Chuck Entz (talk) 09:31, 15 September 2021 (UTC)[]
Thank you for the help. Martin123xyz (talk) 09:53, 15 September 2021 (UTC)[]

Blank page for "social"[edit]

When I look up the word "social" I get a blank page. If I look at the source, all the HTML seems to be there but it's not showing.

Pali categories[edit]

Wiktionary:Beer parlour/2021/September is in categories Category:pi-sc-generic and Category:Pali pages using manual Romanisation. This is probably due to a missing namespace check in a module invoked by {{pi-sc}}. Vox Sciurorum (talk) 20:46, 15 September 2021 (UTC)[]

Close. How do I do a namespace check in a template? I designed extensions to the templates {{pi-sc}} and {{pi-nr-inflection of}} to make it easy to avoid the use of modules as much as possible. --RichardW57m (talk) 17:13, 16 September 2021 (UTC)[]
It's not hard at all: you can use either {{NAMESPACE}} to compare with the name of the namespace or {{NAMESPACENUMBER}} to compare with the number of the namespace (see Wiktionary:Namespace for the list of namespaces and their numbers). Namespace checks were standard practice here long before Lua came along. Chuck Entz (talk)
But the obvious examples to ape were long ago converted to Lua. Anyway, I've now inserted the checks.--RichardW57m (talk) 09:57, 17 September 2021 (UTC)[]

- relationship[edit]

Technical Issue: 坵 in traditional Chinese is not being changed over to 丘 in simplified Chinese in a zh-x Wiktionary quotation on 烏坵

Why should it be: the PRC government standards [8] say that 坵 is a variant form (yitizi) of 丘; the official simplified form of the name of Wuqiu is 乌丘 [9] and does not seem to be 乌坵

Why not use a work around or avoid the issue: I am working on cleaning up a quotation at 烏坵 that is intended to show the actual use of the 坵 character (with the tuzipang) by writers native to that island area; I don't think the 坵[丘] is what really needs to be done- the PRC simplified standard should be automatic

--Geographyinitiative (talk) 21:59, 17 September 2021 (UTC)[]

Displaying comparative and superlative forms for Macedonian[edit]

I want to extend the code for the Macedonian adjective declension table so that it also includes comparative and superlative forms, like the Bulgarian one (see бояк for instance). However, I want the template to be able to check automatically whether the adjective is comparable from the headword-line template, which generates comparative and superlative forms by default, unless a dash is indicated in the appropriate parameter. The Bulgarian adjective declension template does not rely on this principle; instead, one needs to manually specify whether the adjective is comparable between the symbols <> (see руски (ruski)). Since I have already specified whether a Macedonian adjective is comparable or not in the headword-line, manually specifying this again in the declension template would be double work. Could someone help? Martin123xyz (talk) 06:28, 20 September 2021 (UTC)[]

I think the method one would use in a normal programming language is alost impossible. As far as I can make out from what I've seen of Wikimedia technical discussions, the conversion of wikitext to HTML includes the division of the pages into independently processed sections. (I'm not sure how that works with <ref> and its scope.) Moreover, there is a prohibition on section headings being generated by templates. As there will be section headers between the headline and the inflection table, I think you're defeated. Now, you might be able to do something with a 'variable extension', but wikimedia doesn't like the versions that allow the setting of variables. You could do something with a database of adjectives and comparative and superlative forms, but that is ugly and the database will need to be split up into multiple small files.
Another possibility is to use the page itself as the relevant database fragment, and read the forms from the header line. The main space pages will be much more maintainable. Thai does something like this for its transliteration data. Homographs would a problem; the easiest solution is to allow the inflection template call to overrule the header line, as Thai does for transliteration when just taking the first Thai pronunciation from the relevant page would deliver the wrong transliteration. --RichardW57m (talk) 16:40, 21 September 2021 (UTC).[]
@RichardW57m Thank you for the reply. Your suggestions sound quite complicated and as I do not how to code beyond modifying simple wikitext, I don't think I could implement any of the solutions. I was hoping that the code for the adjective declension table could be supplemented with rows for comparative and superlative forms and that these could be embedded within a if-then rule which checks whether the first parameter of the headword-line template equals a dash, so that they are not displayed when it does. Rules like this are already used by the inflection templates, but they do not refer to anything outside of the latter. Perhaps it would be best to just open every adjective page and add comparative and superlative tables where appropriate, or just keep tables for the non-lemma pages that will perhaps be created by a bot one day for the comparative and superlative forms. Martin123xyz (talk) 20:05, 21 September 2021 (UTC)[]

I made a design sketch to utilize wide-screen displays better![edit]

Hello, I've noticed that Wiktionary entries barely use half of my screen horizontally and were designed with now uncommon and archaic 4:3 monitors. Here I propose the idea that the page contents and the page could be displayed in two columns instead of presenting the page contents, blank space right to it and then the page.

This is the umfahren page, but I changed the layout.

This way, all information is available without scrolling or with less scrolling. Tell me what you think! I will publish CSS if there is interest! —⁠This unsigned comment was added by BratwurstBaron (talkcontribs) at 15:58, 21 September 2021 (UTC).[]

Symbol support vote.svg Support as the default. A great time-saver. We would have the actual content before the face more often instead of scrolling. Fay Freak (talk) 08:10, 22 September 2021 (UTC)[]
At Preferences Gadgets is the option to put the Table of Contents on the right hand side. I would have liked that as a default for all users, but AFAICR that idea was rejected, but it remains available as an option for registered users. DCDuring (talk) 22:19, 22 September 2021 (UTC)[]
Symbol oppose vote.svg Oppose I find it distracting to view the table contents next to the contents and the blank space below the table of contents is aesthetically displeasing. Martin123xyz (talk) 12:56, 22 September 2021 (UTC)[]

Macedonian abbreviations[edit]

Could someone suggest what the best way to format Macedonian abbreviations would be, with reference to the headword-line template and the definition? Using the usual headword-line templates leads to the abbreviations being categorized in the same way as the full word, e.g. an abbreviation of a masculine noun is assigned to the category masculine nouns, and an abbreviation of a perfective verb is assigned to the category of perfective verbs, but I am not sure that this is desirable, as abbreviations are just orthographic equivalents or the full words and do not have their own grammatical properties. Could something like {{head|mk|abbreviation}} be used, perhaps?

Furthermore, sometimes the abbreviations correspond to inflected forms, e.g. imperative verbs. In that case, some other languages specify "verb form" in the header, e.g. in the entry for Dutch verg.. However, Serbo-Croatian в. has the lemma header {{head|sh|verb}}. Which is preferable and where should the exact form of the verb be specified in the definition? If {{abbreviation of|mk}} is used, there is no room for {{inflection of|mk}}, which would be used to indicate that the non-lemma form is in the imperative mood, for instance. Martin123xyz (talk) 20:12, 21 September 2021 (UTC)[]

If we combine the both templates then it works: {{abbreviation of|mk|tr=-|{{inflection of|mk|X||2|s|imp}}}}. But I'm not sure if this is the best solution!? --Gorec (talk) 18:28, 22 September 2021 (UTC)[]

Macedonian reciprocal verbs[edit]

There is a category called "Macedonian reciprocal verbs", containing only two lemmas, се and си, which are actually reciprocal pronouns. I propose that the category be deleted and the label "reciprocal" be prevented from populating it, since I do not see the need to indicate reciprocal verbs anywhere - any verbs whose meaning allows it can be used reciprocally with the aforementioned pronouns, just like in English with "each other". If reciprocity was indicated through affixes, as in Turkish (e.g. öpüşmek), and displayed anomalies, the label might have been warranted. The label "reflexive", on the other hand, is amply used to categorize the numerous Macedonian reflexive verbs with a non-reflexive, idiosyncratic meaning, which is never reciprocal. Martin123xyz (talk) 10:01, 22 September 2021 (UTC)[]

Macedonian alphabetization[edit]

Could someone fix the alphabetization in Macedonian categories, e.g. at Macedonian lemmas, so that letters such as љ and њ which do not exist in Russian or Bulgarian do not cluster at the beginning before "а"? The order in which they should appear is correctly shown in the horizontal letter bar where one can click on a letter to view entries beginning with it. Martin123xyz (talk) 13:54, 23 September 2021 (UTC)[]

I don't see a way to do this. The order you're seeing is a result of the order of the uppercase letters in Unicode. In Appendix:Unicode/Cyrillic, Љ (U+0409 CYRILLIC CAPITAL LETTER LJE) has a lower code point than А (U+0410 CYRILLIC CAPITAL LETTER A), so it sorts before it. We can change the order by replacing Љ with something else in the category sortkey (which would mean that Љ would be under a different category header), that's it. We can't change the order in which Љ sorts in relation to А. — Eru·tuon 16:50, 23 September 2021 (UTC)[]
Turkish has the same problem. İ is not between I and J in Unicode and all the ornamented characters come after all the ASCII characters. How do category sort keys work? Vox Sciurorum (talk) 23:41, 23 September 2021 (UTC)[]

Brahmi font support[edit]

Could anyone recommend a font for the Brahmi script that actually supports conjunct characters? Whatever I happen to be using on my system doesn't seem to support conjuncts at all, and the bar-like virama sign are all over the place. Thank you! --Frigoris (talk) 08:37, 24 September 2021 (UTC)[]

Transwiki[edit]

Hi, I just closed an en.wiki AfD as Transwiki and followed the instructions at meta:Help:Transwiki to move the page here. I then found Help:Transwiki here which I think has told me I've done it wrong so the page I created probably needs to be deleted. The page is Transwiki:Meal train / w:Meal train. Thanks and sorry --filelakeshoe (holla) 08:52, 24 September 2021 (UTC)[]

@Filelakeshoe: I have deleted it. We don't want transwikis from Wikipedia, and it would be very helpful if you could make it clear over at en.wiki that "Transwiki" is no longer a valid way to close an AfD. —Μετάknowledgediscuss/deeds 16:49, 24 September 2021 (UTC)[]
Okay, I've overturned the AfD to delete (no one voted keep). Thanks for the info. --filelakeshoe (holla) 17:50, 24 September 2021 (UTC)[]

{{lb|LANG|Classical}} not working[edit]

(Notifying Dixtosa, Kc kennylau, Rua, Ruakh, ZxxZxxZ, Erutuon, Jberkel, JohnC5, Benwing2): {{lb|LANG|Classical}} is not working. Svārtava2 • 03:15, 25 September 2021 (UTC)[]