Wiktionary:Grease pit/2021/September

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)

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)

@Martin123xyz Thank you for your enormous effort maintaining the Macedonian entries. On October 1, there were 37859 total Macedonian entries, of which 37016 contained at least one {{mk-IPA}} tag. I cleaned up 154 pages without a leading * and 354 with a trailing |. I also created a page with the 843 entries that don't contain an IPA declaration. JeffDoozan (talk) 17:48, 12 October 2021 (UTC)

Thank you very much for cleaning up the Macedonian entries, which have grown considerably in number since I wrote this post. There might also be trailing | in the inflection templates that need to be removed. Thank you also for the list - it includes some entries for which I don't know the standard pronunciation, but also some entries created by occasional contributors which I had missed, because I added the transcription module by viewing lists of users' contributions and opening the pages one by one from there, rather than from categories like "Macedonian lemmas". Martin123xyz (talk) 06:22, 13 October 2021 (UTC)

I just started a mass cleanup of all {{mk-*}} templates with trailing | characters. It looks like it will affect about 5000 entries. JeffDoozan (talk) 13:23, 13 October 2021 (UTC)

@JeffDoozan Thank you! 👍 --Gorec (talk) 17:11, 13 October 2021 (UTC)

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)

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

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).

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)

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 = {

{"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)

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

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)

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)

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)

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.

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)

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 say that 坵 is a variant form (yitizi) of 丘; the official simplified form of the name of Wuqiu is 乌丘 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)

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)

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 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 (talk • contribs) at 15:58, 21 September 2021 (UTC).

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)

The idea looks very similar and it leaves more horizontal space on 4:3 monitors. That way it could be the new default layout for all screens. Why was the idea rejected, is there any page to discuss it on? BratwurstBaron (talk) 14:02, 2 October 2021 (UTC)

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)

Abstain. Just use Tabbed languages and find your happiness. Allahverdi Verdizade (talk) 21:14, 25 September 2021 (UTC)

It looks similar, but I usually want to navigate between parts of the page, not languages BratwurstBaron (talk) 13:59, 2 October 2021 (UTC)

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)

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)

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)

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)

I believe Segoe UI Historic supports conjuncts. I'm not sure if you can lawfully use it on a machine that has Windows 10 installed, but is running another operating system. It may be worth investigating Selawik as a long shot. Back in 2012 Vinodh Rajan was planning to create a font supporting Ashokan Brahmi, including conjuncts, but I couldn't quickly find that his plans bore fruit. --RichardW57m (talk) 13:41, 27 September 2021 (UTC)

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. —Μετάknowledge^{discuss/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)

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

Caused by this edit by Inqilābī, which set "Classical" as an alias of "Sādhu Bhāṣā" in Bengali and thereby disabled the other Classical label in Module:labels/data/regional. Sorry, language-specific aliases aren't supported. Fixed by removing that alias. Inqilābī, you will have to use a different alias for "Sādhu Bhāṣā". — Eru·tuon 19:58, 25 September 2021 (UTC)

I'd like someone with a bot to scan Category:Azerbaijani terms with archaic senses for terms with only archaic senses and to change the label from {{lb|az|archaic}} to {{tlb|az|archaic}}. That way, entries become re-categorized into Category:Azerbaijani archaic terms. When doing that, please do not move the label to the headword template level (archaicness is a very important type of information that can't be overlooked by the reader, which is likely to happen if it is detached from the definition and moved up). Allahverdi Verdizade (talk) 20:26, 25 September 2021 (UTC)

What, is this a too difficult task to perform? Allahverdi Verdizade (talk) 09:17, 9 October 2021 (UTC)

Did it myself. Allahverdi Verdizade (talk) 17:26, 16 October 2021 (UTC)

I tried to nominate this entry for deletion: https://en.wiktionary.orghttps://dictious.com/en/Erythropoietin This is simply a capitalized duplicate of the entry for erythropoietin.

The documentation here says to add the rfc template: https://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Cleanup_and_deletion_process

Doing that produced the following mysterious message:

A user suggests that this Lua error in Module:languages at line 550: Please specify a language code. The value "{{{1}}}" is not valid. entry be cleaned up. Please see the discussion on Requests for cleanup(+) for more information and remove this template after the problem has been dealt with. — This unsigned comment was added by Fashionslide (talk • contribs) at 20:35, 26 September 2021 (UTC).

It's not enough to add the template, you have to give it the correct first parameter. If you had clicked on {{rfc}}, you would have seen documentation for the template that made it clear that a language code (in this case "en" for English) is required as the first parameter. It would probably be better to have the module check for the language code before starting to display content, and I'm sure the wording at WT:CDP could do a better job of explaining things for people who don't know how template documentation works. Chuck Entz (talk) 20:47, 26 September 2021 (UTC)

{{rfc}} works exactly as documented; you just didn't read the documentation. But an RFC is not the right way to request a deletion, and your request was completely wrong in the first place — German nouns are written with an initial capital letter, and Wiktionary is case-sensitive. —Μετάknowledge^{discuss/deeds} 20:49, 26 September 2021 (UTC)

Hello,

I have changed the code of mk-decl-adj-table, adding sub-tables for the comparative and superlative forms. I wanted to trigger their appearance by writing c=1 inside the template for each relevant entry, just like I use ref=1 to introduce reflexive pronouns in conjugation tables, but even though I wrote an if-then rule around the the code which calls the cells of these sub-tables in mk-decl-adj, they already appear everywhere. Could someone please fix the code so that comparative forms and superlative forms are hidden by default?

Another problem is the fact that the comparative and superlative tables are displayed even for specific templates other than mk-decl-adj, even though I have not called their cells in the code. For example, mk-decl-adj-в generates comparative and superlative tables even though its code does not mention c_ind_m, c_ind_f etc. (I named the comparative forms by prefixing c_ and the superlative ones by prefixing s_)

A third problem is the title of the first table. If there are no comparative or superlative forms, I want the title to be Declension of X, whereas if there are, I want it to be Positive forms of X. I wrote an if-then rule inside mk-decl-adj-table but it does not work.

Thank you in advance Martin123xyz (talk) 10:51, 29 September 2021 (UTC)

Update: I fixed the code of mk-decl-adj so that no comparative or superlative forms are displayed unless I use the parameter c=1 (see паметен vs. градски). However, I still do not know how to hide the tables by default. Martin123xyz (talk) 11:05, 29 September 2021 (UTC)

Update 2: I have fixed the title of the first table also. Martin123xyz (talk) 11:30, 29 September 2021 (UTC)

Update 3: I have fixed everything: паметен, градски and каков are all displayed properly now. There might be redundancies in the code or the relations between the templates that someone might wish to fix. Martin123xyz (talk) 12:02, 29 September 2021 (UTC)

@Martin123xyz 👍 --Gorec (talk) 20:34, 29 September 2021 (UTC)

Can someone fix my Template for the IPA pronunciation of Romagnol?--BandiniRaffaele2 (talk) 13:13, 30 September 2021 (UTC)